Re: [SDC] ShadowCash | POSV3 | Untraceable E-Cash | NIZKP | HD+BIP32 | ShadowMarket*
Hey just wanted to swing by and say keep up the hard work. From one dev to another. The wallet looks nice. 
If you need any advice on how to use the "cold staking" method of posv3 just lemme know(but via pm or reddit i hardly use bitcointalk). I finally did my first multisig stake last week in BLK(original pos3). Its here:
https://chainz.cryptoid.info/blk/tx.dws?6ef2849263110c5c6dc6443766be883ea1798851cba45ad6eda9903ba283762c.htm
Its pretty straightforward as you can see in the script.
I know how hard it is to code this stuff doing it first hand in Halo and am happy to see you have chosen bitmessage channels for markets. As we have been using them successfully for a few years now. You might want to modify your bitmessage to resubmit messages every 2 days. If you read the fine print, Bitmessage re-sends 2-4-8-16 day intervals or something like this. Which can result in lost messages if parties don't log in frequently. The network needs to always have a copy of outbound messages in contracts or else you can lose coins if the message you are sending is paramount to the transaction. Unless you are using blockchain messaging while in escrow. Anyways, its easy to modify. If I remember correctly it was only a couple lines to change.
Also, you might want to be careful in combining Tor with Bitcoin since I've heard there is a cheap attack that compromises anonymity.
It would be interesting to see how a person could correlate ip addresses that use all 3 (correlate tor, bitmessage and the coin network). I've always liked i2p the best.
I would be interested in reading the NIZKP implementation as I've always wondered how it can be applied proactively in a p2p network. (I'm fully aware of how zkp works and how the setup of nizkp works but am unsure of how tokens are transferred as I read about the minting and pouring process of zerocoin and was a bit confused.) And plus am wondering how the ip of a broadcast of a transaction can be correlated to a proof. (until there is mesh networks and 3d printed open source electronics there may never be true anon)
But I'm just musing aloud as usual...
Good luck y'all
If you need any advice on how to use the "cold staking" method of posv3 just lemme know(but via pm or reddit i hardly use bitcointalk). I finally did my first multisig stake last week in BLK(original pos3). Its here:
https://chainz.cryptoid.info/blk/tx.dws?6ef2849263110c5c6dc6443766be883ea1798851cba45ad6eda9903ba283762c.htm
Its pretty straightforward as you can see in the script.
I know how hard it is to code this stuff doing it first hand in Halo and am happy to see you have chosen bitmessage channels for markets. As we have been using them successfully for a few years now. You might want to modify your bitmessage to resubmit messages every 2 days. If you read the fine print, Bitmessage re-sends 2-4-8-16 day intervals or something like this. Which can result in lost messages if parties don't log in frequently. The network needs to always have a copy of outbound messages in contracts or else you can lose coins if the message you are sending is paramount to the transaction. Unless you are using blockchain messaging while in escrow. Anyways, its easy to modify. If I remember correctly it was only a couple lines to change.
Also, you might want to be careful in combining Tor with Bitcoin since I've heard there is a cheap attack that compromises anonymity.
It would be interesting to see how a person could correlate ip addresses that use all 3 (correlate tor, bitmessage and the coin network). I've always liked i2p the best.
I would be interested in reading the NIZKP implementation as I've always wondered how it can be applied proactively in a p2p network. (I'm fully aware of how zkp works and how the setup of nizkp works but am unsure of how tokens are transferred as I read about the minting and pouring process of zerocoin and was a bit confused.) And plus am wondering how the ip of a broadcast of a transaction can be correlated to a proof. (until there is mesh networks and 3d printed open source electronics there may never be true anon)
But I'm just musing aloud as usual...
Good luck y'all
Hi David,
The team really appreciates your kind words and input. I have noticed that BlackCoin is doing some great improvements too.
We're watching Blackcoin very carefully, everyone here agrees that we wouldn't be anywhere if it weren't for you guys. We're excited about the Blackcoin upgrade to the Bitcoin coinbase 0.11
We followed the Reddit thread about the cold staking, a very interesting read. We were bit confused by the term "cold staking", but multisig staking makes a lot more sense!
Our current implementation does not re-send after two days, I can't say for sure what we'll do to fix this issue but we're not very fond of the current BitMessage approach. We didn't implement the acknowledgment part of the protocol because they open up a gap for traffic correlation and active internal intersection attacks. The acknowledgment messages have a particular size and are easily recognized by an adversary.
There are very effective attacks that can quickly compromise anonymity in the original BitMessage design, we're not having that in ours.
We've made sure that coins can't be lost due to nodes not being online for extended periods of time. The sellers puts all the needed information to make a multisig address in the listing. The buyer then generates the multisig address and includes a signed transaction in the message. When the seller verifies the order he broadcasts all the transactions. No coins will ever be lost this way.
To combat message losses we devised a theoretical model that acts like acknowledgments but is more resilient. Take for example Alice and Bob. Alice sends a message 'Hey Bob' to Bob. When Bob replies he adds the hash of the last message of Alice he had in his message 'Oh hello Alice'.
A->B: message A
B->A: hash(message A) + message B
Now a scenario where multiple messages are lost:
A->B: message A
A->B: message A2 (not received by Bob)
A->B: message A3 (not received by Bob)
B->A: hash(message A) + message B
If Alice receives the message of Bob, she can choose to re-broadcast the messages. If she doesn't receive his messages then the cycle begins again.
When you're expecting an important message then we're generally assuming that you'll be awaiting a response.
Great reads on BitMessage and potential attack vectors:
Traffic correlation attacks: https://www.reddit.com/r/bitmessage/comments/3svc5g/do_confirmation_messages_make_bitmessage/
Forward secrecy: https://www.reddit.com/r/bitmessage/comments/3zzevp/forward_secrecy_for_bitmessage/
More forward secrecy: https://bitmessage.org/forum/index.php?topic=2981.0
Security Analysis of BitMessage: https://bitmessage.org/forum/index.php?topic=1666.0
Tor and Bitcoin indeed form a bit of a troubled relationship, the key element to make it secure is having lots of people running their node as a hidden service. Most attacks with Tor and Bitcoin involve Tor exit relays. I agree that I2P is a better route to take, and we're closely monitoring the Korvi I2P router by Monero.
I'm assuming the cheap attack you are talking about is the one mentioned here: https://arxiv.org/pdf/1410.6079.pdf
Hehehe I'm a newb when it comes down to NIZKP, if you have some good reads for me, ship them over to me!
Thank you for popping by, we greatly appreciate it. It takes great effort to run and maintain open source projects, we recognize your spirit and wish you the best.
Regards,
Kewde and the team.