Over the weekend I implemented a SuperNET agent that implements coinshuffle, a fully decentralized mixer, called Jumblr. It has no central server and you always control your coins at all times. for BTCD there is no fee other than the txfee which is set to 0.01, for BTC the cost is 0.1%. https://bitcointalk.org/index.php?topic=1179305.msg12407691#msg12407691Looking for peoples for the GUI and also testing. bounties available James |
|
|
|
I just verified a 5 node shuffle. start to finish was about 12 seconds http://explorebtcd.info/tx/8cfcfba6ef25443c5e9b9c0de5706f0809e9bd559dfbe072ef31d1239b2af41eThe most time is due to the serial nature of getting the full transaction to the final node. However, once the unsigned rawtx is broadcast, all nodes calculate their sigs and broadcast them, so the phase of collecting the sigs and constructing the fully signed tx will take about the same time, regardless of 3 or 13 nodes. All these comms are happening offchain without any financial cost, so even if it is disrupted, then it is not a big loss. Of course, if somebody is actively sabotaging things, there would need to be a layer to blacklist the bad actors. But that sort of thing i will save for another weekend. Once there are significantly more than 13 nodes available to shuffle with, then it will be possible to generate historical statistics on the effect a specific node has on the success rate. Granted it isnt as elegant as the conflict resolution with fancy math, but with extra rounds it would be possible to statistically identify the bad actors. newbie accts would then be added to the shuffle group at the lowest priority. For now, it would be nice to get some people testing this a bit more. James |
|
|
|
|
turned out it wasnt a bug, just make sure when testing that you dont use a copy of the same wallet on two nodes!
I hope that others can test as I can only test with 5 nodes and it is better to be doing 13 nodes at once and I want to make sure that works
If anybody can work as a tester, I will be able to pay for time.
James
|
|
|
|
|
its a good thing I added duplicate checking!
found a bug with 4 participants with a duplicated input. considering I started coding this last Friday, I am pleased at how fast it has come together. 3-way shuffles seem to work for both BTC and BTCD and should work for any bitcoin fork as I only use standard pay to pubkeyhash
./BitcoinDarkd SuperNET '{"plugin":"InstantDEX","method":"placebid","base":"BTCD","exchange":"jumblr","volume":0.01}'
using the github.com/jl777/btcd , the above will add an entry to the InstantDEX orderbook for "BTCD" in the meta-exchange "jumblr"
this propagates to all the SuperNET nodes with InstantDEX active.
./BitcoinDarkd SuperNET '{"plugin":"InstantDEX","method":"orderbook","base":"BTCD","exchange":"jumblr","allfields":1}'
the above is a way to see how many different nodes are ready to shuffle
./BitcoinDarkd SuperNET '{"plugin":"jumblr","method":"start","dotrade":1,"volume":0.01,"base":"BTCD","timeout":20000}'
the above starts a shuffle round.
For now, only up to 3 has been verified and 4 had a bug. by changing "base" to "BTC" or any other coin, it will shuffle that coin. For coins I dont have the address type and script type for, just get me that info and I will add it to the list of supported coins
James
|
|
|
|
|
pushed a fix so that if any vout or vin is duplicated, it is rejected
Let me know if there are any other issues.
I use a broadcast protocol for all the comms, so correlating IP addresses will require packet level analysis, but even this will be close to noise level once there is significant network activity as the response time for all broadcast packets is randomized via the anti-Ddos mechanism built into SuperNET
What is known about the participants are their NXT addresses, but these are likely to be a onetime or temporary address. Using this, we get the curve25519 pubkey to do the encryption with. Only the destination's pubkey is known, the sender uses a randomly generated onetime (per packet) keypair. So no way to link the data to the published address.
The destination addresses are also fresh never before used addresses.
I am seeing a small round of 3 nodes complete in ~5 seconds. With 13 participants, I hope to achieve ~30 seconds per shuffle. So if one is messed up, it is no disaster.
James
|
|
|
|
I'm one of the authors of the CoinShuffle paper. Really fantastic to see that people are interested in the protocol! I had a brief look at the code and I think there are several severe problems: - You use authenticated public-key encryption (from the NaCl library). It has the property that a recipient can be sure who created a given ciphertext. This is exactly the opposite of what we need in CoinShuffle. In fact, the whole point of shuffling is to hide that information from the recipient.
We need normal IND-CCA encryption, e.g., or DHIES.
So your implementation does not provide anonymity (or unlinkability as dubbed in the paper).
- Each peer must check that there are no duplicate plaintexts after decrypting. Otherwise attacks on unlinkability are possible.
- The whole blame phase is missing, so there is no robustness against DoS attacks as described in the paper. This is actually not a huge problem for a first implementation for a first implementation but should be noted because you implemented currently only a subset of the full CoinShuffle protocol.
(The list is not necessarily complete; these are just the problems that I've seen immediately.) The problem is that the paper as-is is written for crypto researchers and is quite high-level. I think the protocol is not overly complex but the devil is in the details as with all crypto. I've just started a collaboration with Kristov Atlas. We will write a BIP draft including a more detailed, development-oriented specification of the protocol including all the nitty-gritty details. We also plan talk to wallet developers and I will definitively write some code as soon as a reasonable version of the BIP is there. Contributions and collaborations are welcome in all stages, of course.  There are also some open questions, e.g., how to find participants for the shuffling, and what to use for communication (on a network level). How is that done in your implementation? I think you missed that I am generating onetime keypair from the sender side. Only the receiver's pubkey is known. crypto_box_keypair(onetime_pubkey.bytes,onetime_privkey.bytes); if ( (cipher= encode_str(&cipherlen,src,len,destpubkey,onetime_privkey,onetime_pubkey)) != 0 ) Since this onetime keypair is generated for each packet, I do not see how this is linkable. As far as conflict resolution, I use the ethernet method, ie. if something goes wrong, try again with a different set of participants. Since I am using a realtime network to do the comms, a full round will finish in less than a minute. i use InstantDEX orderbook to establish the list of participants. James P.S. I will add check for no duplicates |
|
|
|
|
Jumblr implements a fully decentralized coinshuffle. The fee is 0.1% for bitcoin, it should work for other coins also, but bitcoin shuffling is the only one that matters.
I am looking for someone to head up the marketing for this. It just went into testing this weekend.
It uses the InstantDEX/SuperNET network for the directory, but the actual coinshuffle is all between the participating nodes.
James
|
|
|
|
You need to have a bitcoin RPC available locally and at no time do you lose control of your funds. I searched, but I could not find any other decentralized bitcoin mixer, so maybe mine is the first?
I wonder how you missed JoinMarket?  Following. I am assuming joinmarket is a coinjoin implementation, not a coinshuffle. |
|
|
|
...
jl777
Please post some more details of your project. There are many of us interested in the topic of how to better to hide BTC transactions (to improve financial privacy).
I am not expert by any means. But, I have found both bitmixer.io and SharedCoin (blockchain.info's mixing service) to be pretty good services, both charge under 1%. And, importantly, are not scams.
[Unfortunately, I do not code, I cannot read C. But, that is why we are a community here. Good luck, keep us posted.]
https://blockchain.info/search?search=18144ad2e7c4f6ab8cd5b85fb794d943099085d50e4fcc1de6de3d11fc597531 the above is the first jumblr shuffle when the shuffle starts, all participants create a brand new keypair they also know all the participants NXT addresses let us say A, B and C are shuffling A would then encrypt his data using layered encryption so vin and vout in 2 separate blobs of data first it is encrypted to C, then that data is encrypted to B this is sent to B, who peels off one layer notice that now what B got from A is encrypted to C, but B cant see what the data is B encrypts his data to C and then shuffles his data and the received data and sends it to C C now receives and decrypts it and has the real data, but other than his own data he doesnt know if it was from A or B now he broadcasts the full transaction to everyone everybody verifies his data wasnt changed and signs it and broadcasts the signature everybody constructs the full transaction from all the incoming signatures and they all submit to the network The above process is fully automated, so you just need to issue an API call to allow the coinshuffle. there is also an API call that lets you initiate a shuffle round. James |
|
|
|
I am not sure if this is the right place to post about this, but this weekend I wrote a SuperNET agent which implements the coinshuffle ( http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf) using realtime offchain broadcast packets. Once there are enough participants, the privacy achieved will be close to using bitmessage for mixing, eg very, very good. You need to have a bitcoin RPC available locally and at no time do you lose control of your funds. I searched, but I could not find any other decentralized bitcoin mixer, so maybe mine is the first? Since there are no servers to manage, the costs are low, but it does use the network and so I set the fee at 0.1%. This allows many rounds of shuffling for the same cost as the centralized mixers without any third party risk. This all came together so fast ( https://github.com/jl777/btcd/blob/master/libjl777/plugins/agents/shuffle777.c) it doesnt even have a name yet! I am looking for people to help test this and also to market this service. It is implemented as a meta-exchange called "shuffle" within InstantDEX, but it really is a totally different type of function and it works with bitcoins or any bitcoin fork without any changes needed. To go from the low level API to a usable service, I think the following things are needed: 1. Name 2. GUI 3. Testing 4. Marketing I hope to find people that can help as the only thing I can do well is write C code. James |
|
|
|
I am not sure if this is the right place to post about this, but this weekend I wrote a SuperNET agent which implements the coinshuffle ( http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf) using realtime offchain broadcast packets. Once there are enough participants, the privacy achieved will be close to using bitmessage for mixing, eg very, very good. You need to have a bitcoin RPC available locally and at no time do you lose control of your funds. I searched, but I could not find any other decentralized bitcoin mixer, so maybe mine is the first? Since there are no servers to manage, the costs are low, but it does use the network and so I set the fee at 0.1%. This allows many rounds of shuffling for the same cost as the centralized mixers without any third party risk. This all came together so fast ( https://github.com/jl777/btcd/blob/master/libjl777/plugins/agents/shuffle777.c) it doesnt even have a name yet! I am looking for people to help test this and also to market this service. It is implemented as a meta-exchange called "shuffle" within InstantDEX, but it really is a totally different type of function and it works with bitcoins or any bitcoin fork without any changes needed. To go from the low level API to a usable service, I think the following things are needed: 1. Name 2. GUI 3. Testing 4. Marketing I hope to find people that can help as the only thing I can do well is write C code. James |
|
|
|
From the readme: If you are on Linux, MAC OS, or are just paranoid, you can always build all of this yourself. You must build on a Linux
host machine, even if you are building for Windows!
Instructions at github.com/jl777/btcd/libjl777 I think the correct link is https://github.com/jl777/btcd/tree/master/libjl777 but there don't seem to be any build instructions. Does anybody know how to build this for Linux? git clone git://github.com/jl777/btcd git clone git://github.com/veririchd/btcd-web-wallet cd btcd/libjl777 make dependencies make onetime make libccoin make make btcd (Let me know if this doesn't work exactly, I'll fix the instructions) Then there should be a BitcoinDarkd binary in btcd/libjl777. Set up SuperNET.conf in the same dir with any api keys and/or your nxt passphrase, or just {} ./BitcoinDarkd Open a new terminal cd /path/to/btcd-web-wallet node app.js 127.0.0.1:8080 The wallet unlocking is a little tricky, it will be simplified. You can only run idex if your wallet is unlocked for good. So you'll need to lock it if it's unlocked for staking only (click the left gear icon->Lock Wallet) then click on console and type walletpassphrase <yourpassword> 6000 false 127.0.0.1:8080/IDEX Matthew Thanks for your help. It all seemed to go well until this line: Set up SuperNET.conf in the same dir with any api keys and/or your nxt passphrase, or just {} I simply used the provided SuperNET.conf and now BitcoinDarkd is not happy: curl_easy_perform() failed: Couldn't connect to server curl.(http://127.0.0.1:7876/nxt (null)), retries: 1
Maximum number of retries exceeded!
127.0.0.1:8080 and 127.0.0.1:8080/IDEX are not available. Do I need to put my NXT passphrase into the SuperNET.conf? How? curl_easy_perform() failed: Couldn't connect to server curl.(http://127.0.0.1:7876/nxt (null)), retries: 1
indicates that NXT is not running |
|
|
|
would you consider BTC a limited resource?
it is the BTC that is the resource needed to buy the stake that creates the PoS blocks.
In a sense, PoS could not exist before PoW.
You buy BTC/NXT/BLAH to acquire your stake, yes... But producing a block after you own the stake costs nothing. It seems you are fixated on "producing a block after you own the stake costs nothing" Why cant the same logic be used for "producing a block after you own the mining gear costs nothing"? I dont understand why it is such an important thing where you draw the line of incurring costs. Regardless of when the cost is incurred, it is still a cost. So the one advantage PoW has over PoS is that once PoS is 51% attacked, then it cant escape, while a PoW being 51% attacked is a temporary problem. OK, so if somebody buys up half a PoS coin, then he can create whatever blocks he wants from then onward without any incremental cost. However, who in their right mind would spend multiples of marketcap, just so they can create new blocks without cost? You seem to ignore the PoS characteristic of getting people who have more of it being more vested in it and less likely to attack it. To put in perspective, if BTC was a PoS coin, it would probably take billions to get to a controlling stake. And for all that cost, it is not clear that even millions could be made and if any sort of attack is made from the controlling stake, the value will drop far in excess of any gains from an attack. So I will give to you the point that once a PoS is controlled, it will be a permanent thing and PoW has an advantage here. However, I do not see it as any practical problem as it does not make economic sense to conduct such a financial attack |
|
|
|
Vitalik claims that he has solved this Nothing at Stake problem!!
What are your thoughts about this?
Thanks!
Unless you expend some limited resource when producing a block, you have not addressed the key problem with POS. would you consider BTC a limited resource? it is the BTC that is the resource needed to buy the stake that creates the PoS blocks. In a sense, PoS could not exist before PoW. |
|
|
|
2015-09-07 16:23:58 ERROR: AcceptToMemoryPool : not enough fees 3b90916d8442342813c4b6415f699cdd2846f668881c7ce8f5966a16a3bf47f3, 100000 < 200000 It is not propagating because it has insufficient fees. There is no bug here. Can you dumprawtransaction and paste the output here? If you do I can explain why the fees are insufficient. I'm guessing it has an output that is too small and thus triggering the fee penalty? BTW, what client created this transaction? I generated this tx with my code, but it was an earlier version and might have had some problems. I was not awareof a fee penalty, it is as follows: {
"txid": "3b90916d8442342813c4b6415f699cdd2846f668881c7ce8f5966a16a3bf47f3",
"version": 1,
"locktime": 0,
"vin": [
{
"txid": "13a791824888a75cda2ed94b39c3ced90a06624d294084a0afd738d765525683",
"vout": 1,
"scriptSig": {
"asm": "304402205b06b4a4471314cc423214088bd6c75546a0c3765d61405e6e2550674a474e17022043b73e6357381fbd9c8ac81dcc364e34d46560983bfdb08b162f54f019ec3b1801 031e8ab7edc770169773bb1716904b70ed79a171d11e9af75340949c8949d72a26",
"hex": "47304402205b06b4a4471314cc423214088bd6c75546a0c3765d61405e6e2550674a474e17022043b73e6357381fbd9c8ac81dcc364e34d46560983bfdb08b162f54f019ec3b180121031e8ab7edc770169773bb1716904b70ed79a171d11e9af75340949c8949d72a26"
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.00020000,
"n": 0,
"scriptPubKey": {
"asm": "OP_HASH160 557ae5bf81ec20138026548ddca5654ac8af27cf OP_EQUAL",
"hex": "a914557ae5bf81ec20138026548ddca5654ac8af27cf87",
"reqSigs": 1,
"type": "scripthash",
"addresses": [
"39UzauyJ9iDQy4wS1UFDx1LUFP48HnMYsY"
]
}
},
{
"value": 0.50854610,
"n": 1,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 1c660332b01b497e9f3e8a04da866e66bd99505e OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9141c660332b01b497e9f3e8a04da866e66bd99505e88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"LMp7PY4ymHLnaECvbWxZB245uKsr3jK9zz"
]
}
}
]
}
I used the latest QT Litecoin Core version v0.10.2.2 (64-bit) I guess my question is how did this tx get accepted locally (and in other nodes) if it has insufficient fees to be confirmed? And why isnt 0.001 enough of a fee? Are you saying that if the output was bigger, the fee would have been enough? James |
|
|
|
PoW does have an easier time, but what do you think of querying 50%+ of nodes during bootstrap?
What trust is needed in that case?
The valid nodes would all be on the same chain and the attacker a different chain, the assumption is that the attacker chain has less weight from genesis than the main chain (otherwise the attacker's chain would technically be the main chain). You still would not need any trust as a PoW cryptocurrency. Even if you started up your client and you happened to query 100% nodes at the time and they were all the wrong chain, the node can self-correct once it receives a block from the proper chain that reveals that higher work is occurring. It would reorganize and be fine from that point on. Proof of Stake can't do that. If it gets bootstrapped without any kind of checkpoint then it will simply be wrong until a human intervenes. A new bootstrapping Proof of Stake software cannot detect a Sybil attack. And why cant a PoS node validate the main chain? If there is a requirement that all nodes eligible for staking have a registered pubkey, then for each block, the bootstrapping node can calculate which account should have generated a block. Sure, yes. If you have a centralized authority that keeps a register of valid pubkey's, then as long as you can trust that authority, you'll be able to bootstrap the correct PoS blockchain. Granted there wont be a way to know which nodes published the blocks that it could have, but this is also an issue for PoW as it would be possible for a fake PoW chain to have omitted valid hashes and in the absence of them in the blockchain, the bootstrapping node wont have a way to know it existed. Again, of course a PoW blockchain can't figure out it's wrong if it never communicates with valid nodes, but once it does it can reorganize itself once that communicate does occur based purely on whichever chain has the most work. I think the bootstrapping PoS node is in a similar situation. Mathematically, it can rank the winning block being 1st, 2nd, 198th on the list of eligible accounts to stake. So if it is always the 1st, then there is no issue and if there is some crazy low account with a block, it would be detectable and require some additional correlations.
I am not saying it is easy, but if all the nodes are in consensus, then PoS vs PoW does not seem to matter so much. And resolving attack scenarios is a messy complex thing, regardless of how new coins are minted. It is not only messy with Proof of Stake, it's impossible without breaking the fundamental security model that Proof of Work has. As an aside, I find that Proof of Work deals with attacks in ways that are elegant and very well understood whereas Proof of Stake is replete with ad-hoc rules and behaviors that I find highly arbitrary and difficult to follow, but your mileage may vary I guess. what if the PoS network uses a PoW network as the trusted authority? Then as long as the PoW network is secure, the PoS can bootstrap using data from the PoW network Maybe this hybrid mode is a good way to get the security of PoW in a PoS chain |
|
|
|
OK, so query 60%, or 70% or 90% at some point you have to admit that the sybils are detected (unless the entire network is sybils)
If this policy is valid, why bother with any proof of stake at all in the main protocol? All you'd need would be to validate transactions against 60%, 70% or 90% of the nodes in the network, and bob's your uncle? this is only needed for bootstrap |
|
|
|
Is any PoW needed to be a node on a network? I thought PoW is only used to create new blocks
Tier Nolan is proposing a QoS to create a PoW requirement to be a node, but to my knowledge this is not done yet. I have added such an anti-ddos to supernet protocol, but being a node on the network is independent from generating new blocks, so it has no relation to whether a coin is PoW or PoS or if it isnt even a coin
No POW is need to be a node. Not sure what your point is? You were suggesting that querying 50% of the network is trustless, because that is a majority - however, that is prone to sybil attack, since pretending to be a node costs nothing. OK, so query 60%, or 70% or 90% at some point you have to admit that the sybils are detected (unless the entire network is sybils) |
|
|
|
PoW does have an easier time, but what do you think of querying 50%+ of nodes during bootstrap?
What trust is needed in that case?
It is prone to sybil attack - the cost of pretending to be N nodes is tiny, so you can pretend to be 50% of the nodes on the network at very little cost. Is any PoW needed to be a node on a network? I thought PoW is only used to create new blocks Tier Nolan is proposing a QoS to create a PoW requirement to be a node, but to my knowledge this is not done yet. I have added such an anti-ddos to supernet protocol, but being a node on the network is independent from generating new blocks, so it has no relation to whether a coin is PoW or PoS or if it isnt even a coin |
|
|
|
So if a new PoW node is bootstrapping and it is only connecting to sybil nodes that have created a totally fictional (but technically accurate) blockchain, there is some magic that PoW node can do that PoS cannot do?
I cannot imagine any such thing is possible
James
Producing a totally fictional blockchain is computationally equivalent to outpacing the network. Not impossible, but it requires 51% of the hashing power of the network to produce a chain longer than the best chain. How so? You can just make the hashrate constant and very low. Remember this is totally fictional chain, so the real network has nothing to do with it. I am pretty sure that with a bit of tweaking, you can generate blocks very quickly and still have it pass all the PoW verifications If the only chain a new node sees is this one, then i dont see how it can differentiate it from the real chain, which it cant connect to in this hypothetical. James You're correct that in a hypothetical scenario where a user has no access to any other valid peer then it obviously can't validate it's version of events with a peer. However, PoW can trivially bootstrap itself in the face of an overwhelming majority of hostile nodes. All it needs to find is a single node with proof that it has a blockchain with greater work on it and it's good to go. The valid chain has the most work. No human intervention required. PoS cannot bootstrap itself in this manner. Even when there are valid nodes available, you would have to find somebody you trust and manually add a checkpoint. PoW does have an easier time, but what do you think of querying 50%+ of nodes during bootstrap? What trust is needed in that case? The valid nodes would all be on the same chain and the attacker a different chain, the assumption is that the attacker chain has less weight from genesis than the main chain (otherwise the attacker's chain would technically be the main chain). And why cant a PoS node validate the main chain? If there is a requirement that all nodes eligible for staking have a registered pubkey, then for each block, the bootstrapping node can calculate which account should have generated a block. Granted there wont be a way to know which nodes published the blocks that it could have, but this is also an issue for PoW as it would be possible for a fake PoW chain to have omitted valid hashes and in the absence of them in the blockchain, the bootstrapping node wont have a way to know it existed. I think the bootstrapping PoS node is in a similar situation. Mathematically, it can rank the winning block being 1st, 2nd, 198th on the list of eligible accounts to stake. So if it is always the 1st, then there is no issue and if there is some crazy low account with a block, it would be detectable and require some additional correlations. I am not saying it is easy, but if all the nodes are in consensus, then PoS vs PoW does not seem to matter so much. And resolving attack scenarios is a messy complex thing, regardless of how new coins are minted. James |
|
|
|
|
Show Posts
