Please stay on topic.

@genjix, I think you misunderstood my point about multiple parties. Without blinding or ring signatures or other crypto magic, it is not possible to have multiple participants where the other participants don't know which outputs correspond with which participants (the exception for 2 users is simply that if there is only one other person participating, then obviously whatever outputs are not yours are his, not matter what fancy crypto is used). This is important because CoinJoin is useful for far more than mere mixing. Joint transactions are also the mechanism by which matching donations or crowdfund campaigns can be organized (see Mike Hearn's Lighthouse app), exchange transactions of colored coin assets can be arranged, and various cross-chain atomic trade protocols. Scaling up these applications to multiple participants without loss of privacy is very important.

Sharedcoin is a blockchain.info product. You can read about it on their website, but I don't think it was based on any external design, just a mixing service cooked up by one of their engineers.

Darkcoin and darkwallet also have nothing in common either. Despite co-opting the name, darkcoin's darksend doesn't appear to have anything to do with coinjoin. Their description and illustration in their thread shows some sort of centralized mixing service (more akin to sharedcoin), and indeed their distribution mechanism involves a reward for "masternodes" which perform the mixing with these fresh coins. It would be nice if someone from that project could chime in here and explain just what it is trying to accomplish, because the available technical descriptions are scarce and contradictory.

Darkwallet does indeed implement coinjoin, albeit using a centralized matchmaking service to setup the mixes. I have been informed by the developers that this is a temporary mechanism and they are working towards a fully p2p solution. They do not use the blind signing or ring signature mechanisms which are required to scale to more than 2 participants without revealing ownership of outputs.

you cannot assume anything about the values in the scriptSig without knowing the scriptPubKey

Greg has nothing to do with sharedcoin (and sharedcoin has little to do with coinjoin).

To your question, read the op. This whole thread is a description of how to do decentralized, trustless mixing.

That is a terrible idea. It circumvents behavior that is designed to make bitcoin safer for users, and does so in a way which may not be safe when interfacing with other transaction construction protocols. Please don't do it.

But so as to not be a complete jerk, I will answer your specific question: you need the input's referenced output. The transaction intput has a hash and vout index which you can use to lookup the output from the UTXO set (if it exists and is unspent). The scriptPubKey in that output is the "address" you are looking for.

No, that is not accurate. There are an unlimited ways in which this can break (and yes, it does break for SatoshiDice). If it seems relatively safe now, it is because smart contracts, joint transactions, and other on-the-horizon technologies are not being widely deployed. When they are, the assumption that you can simply return funds to a transactions input(s) will be even less valid.

I'm not sure how informed you are about Freicoin, but the underlying purpose and design requirements are to explicitly avoid speculative asset appreciation. I see a very flat and relatively stable graph, minus the deceptive spike around the time of bitcoin's runup. That's a good thing.

so?

That is normal for p2pool, and does not affect your payout. You may also try http://freicoin.us/

Yeah okay. I'll see if I can find time to finish the half-written BIP I've already started.

Why? The interpreter is already protected against this. Once the opcode limit is exeeded, the execution terminates, the transaction is rejected, and the peer is DoS banned.


Stack-based does not mean Forth. Just like LISP does not mean Common Lisp.

I suggest you look into Joy, Cat, Kitten, or one of the many other newer generation "concatenative" languages.

Lisp is actually not ideal here. Some sort of stack-based language with strong static typing would be an optimal choice (see, for example Kitten & Joy). But yes, Ethereum is re-inventing a square wheel here.

This is a classic use case for colored coins. Since the share outputs are themselves bitcoin outputs, you simply look at the utxo set and send dividends to the current owners.

@caedes, why not have a peer-to-peer broadcast-flood channel for announcing joint transaction availability? Maybe even reuse one that is already available, well maintained, and has known security properties, like say the bitcoin network itself? And then do direct connections to the followon stages?

The only way to do that is to 51% attack bitcoin itself. We are talking about soft-fork changes, right?

Not all possible version upgrades are exclusive. You could have a version 3 block which adds an optionally validated field (version 3 blocks have it while version 2 blocks do not).

Is there a central server involved in your implementation? I'm not trying to spread FUD, it's just there is conflicting information out there on the net. What you describe here sounds like it is p2p. Where are the announce messages posted?

Try rounding to 8 decimal digits of precision, like you would with bitcoin.

Peter Todd, could you illustrate how tree chains remain compatible with SPV mode, if they do at all?

Fun fact: JavaScript has MAX_INT equal to 2^53 - 1, for exactly this reason. These days it's all JIT compiled, but back in the early days of JavaScript interpreters, double-precision floating point was used for *everything*. And it worked, precisely and exactly. At least so long as you didn't exceed that range or divide on an intel CPU