Okay so staking goes like this and its not limited to multisig, it just lets you have more control over staking in general. In this case you put the blocksignature into an output with 6a
Check for a block once per 16 seconds (more often makes no sense) you check your inputs/coins with:
checkkernel [{"hash1":n1},{"hash2":n2},...] which usually returns { "result":false }
or when you are lucky to create new block { "result":true, "kernel":{"hash":"hash", "n":n, "time":time}, "blocktemplate":"hex", "blocktemplatefees":fees, "blocksignkey":"hex" }
Then Halo creates coinstake tx, using info returned by checkkernel, as follows:
create empty tx set time to kernel time add the kernel input if you want add more inputs (this is a bit tricky so don't for now)
Now we need to know reward, so call getstakesubsidy coinstake blocktemplatefees
Continue to build coinstake add output to empty script, 0 coins add output to script "6a + blocksignkey", 0 coins
add outputs to your addr which is staking fees+staked coins+all your inputs
you can even send outputs to voting addresses if you like
Last step you call submitstakeblock blocktemplate, {coinstake} It will add coinstake to block template, recalculate merkle tree, sign block, and announce it to the network
Here is my example on BLK:
https://chainz.cryptoid.info/blk/tx.dws?6ef2849263110c5c6dc6443766be883ea1798851cba45ad6eda9903ba283762c.htmI constructed that one with pyblackcointools although i realize your code is in c++ the theory is the same
Cold staking allows you to stake from multisignatue asynchronously signing. So think "staking device" or "staking with two computers". This would make it harder for keyloggers to get your coins because
there is one key on each computer
Sweet, thanks for the explanation. I will pitch it to Ryno! We've recently implemented some blackcoin code to get this working.
We're looking into a fitting solution that allows anyone to open a multisig wallet through in their contact list. We'll be using our messaging system to transfer the public key(s) and might even send the transactions through it. Group transactions are also possible. But we haven't really started any of that, still working on tasks with a higher priority.
Bitmessage 2 day resending rule is modified by editing class_singleCleaner.py line 94
(216000 max age of object 60 hours) was being multiplied exponentially which can cause gaps and lose messages now we have a linear system
So that is how you fix that. I agree for acknowledgement, your fix is obviously superior. Very simple and elegant concept. Also consider you can just send a public key with each message. In Halo Bob and Alice exchange Halo public keys and they immediately have fully double encrypted messages. Like PGP. I should remind you that Tor exit nodes are currently controlled by nefarious forces. I've heard these attacks are not trivial and some people think Tors security was never jeopardized. However, I think Bitmessage is harder to attack than you are thinking. This assumes more nodes will start to use Bitmessage and I think they will. Ever since I started on markets, I've seen my connections to the network go up, perhaps from Halo users or just a general renewed interest in it. I remember sending many messages to Aetheros asking him to fix the message header mutation attacks that was crippling the network. Very happy he updated it, I've heard a few others also asked him and it prevented it from being abandonware.
I'd like to say that after some more thought we'll be using the HMAC instead of hash of the message. Way more efficient
I think you aren't efficiently using that extra public key. If you are going to go the route of an extra key, then use the double ratchet that Signal made. We'll be implementing this to support forward secrecy.
https://en.wikipedia.org/wiki/Double_Ratchet_Algorithmhttps://whispersystems.org/blog/advanced-ratcheting/https://github.com/trevp/double_ratchet/wiki I should remind you that Tor exit nodes are currently controlled by nefarious forces. I've heard these attacks are not trivial and some people think Tors security was never jeopardized. However, I think Bitmessage is harder to attack than you are thinking. This assumes more nodes will start to use Bitmessage and I think they will. Ever since I started on markets, I've seen my connections to the network go up, perhaps from Halo users or just a general renewed interest in it. I remember sending many messages to Aetheros asking him to fix the message header mutation attacks that was crippling the network. Very happy he updated it, I've heard a few others also asked him and it prevented it from being abandonware.
There are some simple remedies for countering the attacks on BitMessage. The first and most obvious choice is to never ever make traffic go through exit nodes. Bad for business.
On the other hand I haven't really studied BitMessage in depth, only our message format aligns with them, everything else is different.
By the way, is your version of Bitmessage in Python? Do you have your own fork/github? My version of Bitmessage is not online. But I only changed message resending and also made the datadir automatically local since I store everything in C:\BlackHalo including the data files of the blockchain and Bitmessage.
Anyways the security is still pretty tricky to compromise, when there is 100s of nodes on the network, messages will be passed from node to node, if all 100 of them are using the channel for markets, it becomes very hard to find out who the originator of a message really even is. Especially because they can send from the channel to the channel. So its like everyone is shouting in an open forum
ShadowChat is fully written in C++ and depends on the OpenSSL libraries for its cryptographic mutations. It does not however have a separate repo. The system is indeed very resilient to attacks, the confirmation attack can easily be spotted if you program your system to do so. Make sure to add a settings that allows users to turn it off.
I was considering using this for broadcasting transactions to the Bitcoin network as well. Instead of broadcasting directly to Bitcoin nodes, send the raw TX to Bitmessage and let them do it. This makes it harder to tell the originating IP address of the Bitcoin transaction broadcast.
We use the same approach because of the enhanced privacy it offers.
You can combine Bitmessage with Tor. And you are right, that paper is the one I was citing.
Although you may be correct in thinking that IP addresses could be triangulated in Bitmessage.
Implementing a set of trusted nodes and cleaning out any address that isn't trusted on reboot can prevent some attacks but do weaken the decentralized structure. Trade-offs one has to make themselves I assume.
My solution to this I think you will find is awesome and elegant. You force nodes to lock funds per kilobyte using checklocktimeverify.
So Bob wants to send a message to Alice, his message is 100 KB
Instead of some crazy POW, he is asked by the protocol to lock for example 1 satoshi per byte (of course we can increase this or have it based on some global rate set by a custodial wallet)
So he send the coins checklocktimeverify for lets say 24 hours. The coins first go to 6a or the bitcoineater(burn address)... then you "revive" them like a zombie.
So output is 6a checklocktimeverify 24 hours to (your address)
The network can confirm his coins are indeed locked to himself of the blockchain forgoing POW entirely.
I dont have the time to implement this, but would love to see it done because it fixes an obvious problem with Bitmessage. The only drawback is this might make main-net nodes exclude you but perhaps you can still do it on the main-net giving the option to use both methods and ignore POW when using POL (proof of lock?)
Ahhh, that is indeed a good way to go. We're using a slightly different version, it involves actually spending the coins as a fee for a transaction. I really like the idea of your system more to be honest, but the only draw back is that a very rich attacker could still perform it. You'd have to design the timeframe of it so that it would take large amounts of coins to successfully keep a constant stress on the network whilst not having to punish small users. We don't charge anything at the moment for messaging, but we do however plan to have a free limit so messages under say X kb are free but their priority is lower than paid ones. So if a spammer does decide to spam the network, those with a valid payment are the ones that get to cut the line.
Lastly, I spent a lot of time trying to understand zero proof. It was only this amazing little paper that made me "get it". Its called "How to explain zero knowledge to your children".
http://pages.cs.wisc.edu/~mkowalcz/628.pdfSo by your ACTIONS you prove you knew a secret.
Applying this in a meaningful way is the part that I'm not sure of yet. If I prove I know my own age without telling you my age, can this be used for addresses as well? How?
I heard a rumor that you used zknips? But then I heard you had only used ring signatures. Then i heard all kinds of fud. I'm not sure what was true and what wasn't. In any case it would be interesting to know if you guys actually use zero knowledge in your code base? And how did you apply it in a useful way? I really could not understand zerocoins pouring and minting method... and I re-read the paper like 10 times.
We use NIZKPs, Bitcoin also uses ZKPs, asymetric key encryption is pretty much a "zero knowledge proof". It boils down to this: when you sign a message with secret private key s, and you give someone your public key p. He or she can then verify that you have a secret key s for a given p without having to reveal it. We use traceable ring signatures, which is a scheme with NIZKPs at its core, they are basically the same thing. I hope that clears the air.
I haven't read the Zerocoin paper yet, but it seems like they'll have to battle with some big issues.
I have no clue what you ment with applying it to addresses lol.
