"tinted coins"?

"tainted coins" is most accurate... if right out.

Agreed.

At the very least, even if enough pool op's don't get on board, if the first usable software to do this is written as a service, rather than a purpose-built client, hopefully using it in the former mode rather than the latter will be more common.

OpenSSL implements a strong PRNG-based random pool, so in addition to other entropy gathering why don't we seed the random number generator at startup with all the private keys in the wallet? That'd quite effectively act as a persistent entropy source with protections just as good as the wallet it's trying to protect in the first place. It's also perfectly safe:

http://www.openssl.org/docs/crypto/rand.html

as the data added is hashed into the pool using a cryptographically strong hash function. Equally hashing in the user's decryption password, if the wallet is encrypted, is also safe. Of course, this won't happen until the wallet is decrypted, but random bytes aren't needed until the wallet is decryption anyway. Even with a really broken entropy source, you'll eventually accumulate enough that subsequent keys are safe. Also, if we accidentally release a version with a broken source, that won't immediately break key generation for users who already have wallets.

I could probably cook up a patch sometime after next week if no-one beats me too it.

Edit: come to think of it, if people are worried that inserting keypairs could somehow leak data in the event of a break in the OpenSSL library or something, insert half of each key, the same half each time. Even cracking a key with half the bits known is approximately a formidable 2^128 problem. I dunno exactly how the ECC key format works, so maybe I should pick specific bits, any insight on that?

I'll keep that in mind. I'll let you known when I have something concrete to try out.


Credit where credit's due: chronobit https://github.com/goblin/chronobit does timestamping by inserting data into the p2pool share chain, which winds up in p2pool blocks. Unfortunately the share chain is a linear blockchain, so the resulting timestamps are much larger than optimal if you need to store the whole set of data required to verify them. Still, it's where I got the itch to find a better timestamping solution, and the additional side-chain application makes it all the more interesting.

Thanks! I was looking at your eloipool software, and I see it has a setworkaux RPC method. From what I can tell simply adds data directly to the coinbase. So I take it you're additionally running something like merged-mine-proxy from namecoin? Or a helper that calls setworkaux appropriately? I could write a daemon that speaks the RPC interface the merge mining proxy expects if this is what most pools ops use.

If I understand the namecoin and merged-mine-proxy code correctly what happens is that the proxy calls the namecoind RPC interface, which supports the extension getauxwork. This essentially returns what data the alt-chain needs linked to the proof of work, as well as the target difficulty for the alt-chain. In my case that is the top merkle hash and the target can be hardcoded at zero. The target difficulty can be set by copying the target seen in the Bitcoin block header, divided by 4+n to ensure we don't miss a difficulty change. (assuming we don't get told the most up-to-date Bitcoin block regularly, I'll have to check those semantics exactly)

Every time a solution is submitted that meets the target difficulty it looks like getworkaux is called again, this time with the full information needed to reconstruct the PoW. It's OK if the daemon always claims that the target was met. Internally though it'll check to see if a new Bitcoin block might have been generated, and if so take appropriate measures. Chain re-orgs are of course an issue; probably best to assume the usual six blocks deep rule before removing submitted hashes from the tree we're trying to insert. I'll look into getauxblock later; I think that can be just a pre-defined header given there isn't a concept of the previous block or anything else. I also gotta figure out what the hell is going on with that slot_id crap...

Anyway this can all be packaged up into a Python script and either it'd be run on your server, (is the webserver enough?) or you can have your merged-mine-proxy contact my server for new PoW instead. (after trying it all out on testnet locally obviously) Either way I intend to essentially a dead-simple "pool-op" version first with the minimum of external dependencies (flat-file database with simple expiration rules for instance) to act as a proxy between the pool and more sophisticated merkle servers to be written later.

(putting this in it's own thread as I'm not really talking about sidechains anymore)


I've heard this argument come up multiple times when stuff like timestamping or side-chains comes up. The problem is adding extra data is only possible at all if you are a miner, and if you want your data to be added in a reasonable amount of time, a pool op. Given that limitation I suspect both timestamping and sidechain concepts will wind up stuffing data into transactions, bloating up the blockchain. I've mentioned before how this can be done right now, without a special transaction type.


So would pool ops be at all willing to put a merkle tree head into the coinbase's they mine?


From their point of view we can make this pretty easy for them to do technically speaking. Lets suppose I wrote some software that would act as a merkle tree server. It'd accept hashes from anyone, build up a full merkle tree, and provide the top hash to pool ops for inclusion. The interface for them can be just a HTTP GET-able top-level hash that they put directly into their coinbase. My software could even look in coinbases of blocks mined to figure out what ones got into the blockchain. If they aren't willing to put the hash in the coin base directly, or want to stuff it into an existing merge-mine merkle tree, they'd have to additionally send back the merkle leaves required to get to the coinbase by either HTTP RPC back to the sender, or even just publishing the associated data automatically on their website. For redundancy the latter option is probably better anyway, because that way it's fine if multiple people are operating these servers, with pool ops determining what server's they're going to accept top-level hashes from. These merkle servers can submit hashes to each other too. If any server gets a hash into a coinbase, they all do, modulo the longer path get to the top hash. Equally, nothing is stopping a pool op from running the merkle server themselves.

Of course, this kinda looks like we're allowing arbitrary people to use pool hash power to do their own merge mining. I suggest that before a pool op includes the top-level hash into the coinbase or merge-mine tree they do a final "poisoning" step that consists of taking that hash, converting it to hex, pre-pending a known and fixed string, ("This hash is not a proof of work: <hash>") and then hashing that whole string with sha256d. Since the poison step is always the same timestamp and similar uses don't have to record that extra bit of data in signatures, but at the same time it unambiguously distinguishes such merkle trees from legit merge mined ones.

I've been thinking about this stuff in terms of timestamps and have been recently working on a very compact, and extendable, way of storing the resulting merkle paths. The goal here is to be able to timestamp a file and save a path to one or more notaries who guarantee that a hash existed at a given time, with the option of later adding additional paths to other notary signatures as they become available. Notary being a PGP signature, Bitcoin block, commercial timestamping service, dead-tree publication etc. It's a field that doesn't seem to have much open-source software available, probably because the problem isn't really a software problem... but Bitcoin changes that. I've got some Python code (actually Cython) I'm working on in a really early stage; nothing set in stone yet. One key thing I want to do is ensure that servers running the timestamping version of this software widely witness each other with multiple notary methods; the blockchain is an excellent way of doing that if you include Bitcoin block hashes into your own merkle trees.

Regarding scalability lets suppose we would up with a smallish number of people running servers, 8 or 16 or so, that pool ops collectively were querying. If all 16 got into a block the merkle tree is now 4 levels deep. Lets assume each timestamp server operator is running their server on Amazon EC2's free tier, 15GB bandwidth out a month. With 1KiB out/request they can serve up to 6 timestamps/second (3600 in 10minutes) without running out of bandwidth. 2^12=4096 so the path is 16 long, 512bytes + block header overhead. Rate-limiting, if even required at all, can be reasonably done with API keys, CAPTCHAs and asking nicely, with the intention being that heavy users run their own servers. (they probably have their own notaries anyway, with bitcoin as a backup verification) Heck, maybe even monetary payments to deter abuse; if only there was a way to easily accept such payments...

In any case, if pool ops aren't interested, this kind of thing can equally work by dumping the data into specially marked transactions, although having the option of something centralized would be better provided enough pool ops are interested that getting your timestamp/sidechain in a reasonable amount of time is possible. The worst case is if timestamping and sidechains is a common use case, and everyone rolls their own transaction-based system bloating up the chain. As it is with the 1MiB block size limit and an average transaction size of around 256 bytes block's aren't going to have more than 4096 transactions in them anyway, so applications trying to limit the size of their trees are often going to have an incentive to use transactions directly, modulo transaction fees.

Of course one interesting thing about "coin-melting" would be the incentives it'd give to mining. If people handing out 12,000BTC fees was ever common, pools would be willing to stop working on the latest block and work on the second, or even third, latest to attempt to reverse the high-fee mined block and collect the fees for themselves. Of course, you could wait until you got really lucky and found, say, two blocks in a row and spread fees between them. Or just melt a small amount of fees per block, maybe spread over a boatload of transactions to obscure what you were doing.

Now, does the honest miner who takes a risk to steal a thief's fees by working to reverse a block rather than extend the chain deserve to keep those fees as their reward? Some of those fees? How do you know they're an honest miner?

The coinbase transaction is allowed to have a value of up to subsidy+fees; the thief most certainly could move value into it. You aren't proposing blocking the transactions themselves, which would split the network anyway, so any thief, or even a group of them, can get together and buy some mining hardware to find blocks faster. Or rent time on gpumax, or, for now, buy time on a botnet.

On top of this once you can mine some blocks you can also use non-standard transactions to spend your loot, complicating any code designed to taint transactions.

More importantly they can cause miners a lot of pain by simply moving coins around, spending fees, and casting others under suspicion if you start calculating taint on coinbases.


I second Gavin's response: go and implement it for us and we'll see what happens.

Not to mention the thief can turn coins into block rewards by spending them on transaction fees.

Is mining income tainted too now?

Of course, I'm just saying the problem that Bitcoin solves in a novel way with mining is the very specific double-spend problem, everything else it does doesn't need a blockchain. (well, maybe initial coin distribution too)


If you can figure out how to do that and be sybill-attack resistant you can be the next Satoshi.



Expanding on my last message, actually, come to think of it, we don't need a one-to-one relationship... and maybe spam isn't as big of an issue.

Lets suppose we want to start a pure alt-coin. Lets assume the initial coin distribution problem is solved, and multiple participants have coins they want to create transactions for. Like Bitcoin they can broadcast their transactions on a flood-fill P2P network, letting everyone know about them.

Anyone is then allowed to build a block consisting of a merkle tree of transactions, hashed with a header that includes a reference to a parent block. They broadcast this block on the alt-chain P2P network, and simultaneously broadcast a specially marked Bitcoin transaction including the hash of the block on the bitcoin P2P network. Dos attacks can be avoided by dropping nodes that transmit blocks without submitted the associated Bitcoin transactions.

Unlike Bitcoin the rule is that multiple parallel blocks, that is blocks with the same parent block, are allowed. Transaction validity however is defined by being in the block whose marked transaction in the bitcoin block chain is first. Transactions that are found to be invalid can be ignored simply ignored, and blocks with excessively large numbers of invalid transactions can be ignored in their entirety. You'll may also still want some sort of payment-based rule to discourage creating huge numbers of blocks, such as a mandatory fee, maybe tied to the average transaction fee on the bitcoin network. You can determine if your peers are hiding transactions from you by just scanning the bitcoin blockchain, although come to think of it this mechanism is susceptible to griefing by creating bogus marked transactions...

This does do a decent job at minimizing the extra junk left in the Bitcoin blockchain though by allowing transaction combining. It's also possible to "merge-mine" multiple such alt-chains with just one transaction.


Oh, and here's another idea: going back to the "highest-paying block wins" it'd actually be possible to solicit donations to pay the fee. The proposer of a block would create a transaction template and solicit signatures from the donators. The interesting thing here is donators can donate to multiple candidate blocks that they are happy with, and only one block would ever get accepted as the others would look like double spends. Griefing is of course possible, just like similar coin-mixing proposals, but solutions to the latter may be solutions to the former. Again, I dunno if this is actually useful, but maybe someone will come up with an application for the idea.

Also remeber that the content of the blockchain is chosen in a way that's effectively voting, with the vote being calculated proportional to the computer power possessed by the people mining new blocks. Essentially the vote of miners decides what transactions go in the block chain, and very importantly, in what order.

If you could find a trusted centralized entity to determine what transactions, and in what order, should go in the blockchain, you wouldn't need mining at all.


As a thought experiment, you could make an alt-blockchain using the bitcoin blockchain where the order of blocks and transactions was determined by who was willing to spend the most bitcoin to insert a block. The way this could work is like in bitcoin you would have some mechanism to broadcast transactions to everyone in the network, such as a peer-to-peer flood-fill mechanism. Also like Bitcoin someone who wanted to generate a block would collect all the transactions and tie them together in a merkle tree, which when hashed with the block header leaves you with a single cryptographic hash.

Now to propose a blocks you would create a transaction spending bitcoins in a specific way, for instance by giving them back to miners in transaction fees, or by sending them to an unspendable address. Included in this transaction would be your hash of the block, and some special marker so that people can scan the bitcoin blockchain and be assured of finding every such special transaction.

Whoever's transaction spend the most bitcoins wins, similar to how in bitcoin a block wins when it has the most difficult proof-of-work solution. Essentially you're voting not with computer power, but money. This might be a reasonable design decision for specific applications.

Interestingly this system actually has better protection than bitcoin itself from sybill attacks: since every candidate block has been specially marked you can simply scan through the bitcoin blockchain and find every submission. Even if every peer you are connected too lies about the state of the alt-blockchain, you can at least tell their lying because you have proof that an alt-block has been submitted with a higher payment value.


On the other hand alt-chains that don't have a cost associated with proposing a block will find themselves spammed. Lets suppose the transaction in the above example just had to be marked; a winning payment amount wasn't required. While you could still decide on a block order by following the order transactions were seen on the bitcoin block chain, there isn't anything stopping someone from submitting lots and lots of blocks with little or no transactions in them, creating an incentive to spam both Bitcoin and the alt-chain.


Of course systems with marked coins don't have this problem, as there is a one-to-one relationship between alt-coin transactions and bitcoin transactions.

Absolutely. Not to mention how BFL appears to be getting extremely good deals on the FPGAs in their gear. While a BFL Single sells for about $650 the list price on Digikey for the two FPGAs inside of it is $2,000 each. While they're fast FPGAs they are a generation old so it's not unreasonable to be able to get a much cheaper price. However that does mean they have very little room to maneuver if that supply dries up, or if it turns out that some of their parts held in storage from a bulk-buy are broken.

Keep in mind that the rule of thumb in electronics is you should think really hard about what you're doing if you plan to sell your product for less than 10x the parts and assembly cost. Anything less and cost-overruns and engineering time will leave you with a loss. If things work out, only then can you think about lowering the price. I suspect BFL isn't following that rule strictly.

You guys haven't bought much industrial equipment have you?

I work as an electronics designer, and often I wind up ordering components that take months to arrive due to shortages. Accepting payment for something to be delivered in 6 months, or even a year, is not usual in many industries, and yes, those payments wind up getting spent on making and even designing whatever it is that you ordered. Hardware production just doesn't move fast, nor can you scale it up quickly.

Frankly I'm not at all surprised that Butterfly Labs had some major problems with their first product. Designing and building volume electronics is not easy, especially when what you're doing hasn't been done before. Estimating power consumption of any electronic device is tricky, and their explanation that the unusual power consumption in their single-purpose FPGA design overwhelmed standard filtering techniques sounds pretty reasonable to me. Ever looked at a motherboard up close? Notice all those little grey-looking ceramic things about the size of a grain of rice sitting right under your CPU? (and for that matter, scattered all over the board) Those are capacitors, which serve to temporarily provide electricity to the CPU when it turns on a bunch of transistors on at once, too fast for the rest of the power supply system to catch up. A very important part of FPGA design is analyzing how many, and how big, those capacitors need to be, and crypto is unique in that a heck of a lot of transistors can turn on at once, far more than the design tools the manufacturer provides you usually assume. This is hard to predict in advance and eats up power like crazy, as well as making your first try at the design flaky because you just can't feed the FPGA with power fast enough.

The problems Butterfly Labs has had in the past shipping product is not fraud, it's just standard issue teething pains in brand new hardware for a brand new application. If anything I'm impressed that they worked through the problem and got working hardware out, rather than quitting, in the face of a community solidly against them.

You don't even need to do that actually: outputs are numbered so your standard can be that if there are more than one outputs, the first one is reserved for change. At worst you need to add some extra coins if what you are spending divides exactly.


Actually, this made me realize that for many applications any type of scriptPubKey message opens you to a nasty problem: replay attacks. Let's suppose your "issue a bond" protocol is that any coins from a transaction with the specially marked scriptPubKey are considered to be issued. Now anyone can create a transaction with an identically marked scriptPubKey, creating an output that looks like it's part of the bond issue. Obviously there are lots of ways to mitigate this but...

On the other hand a scriptSig-based issue is protected from this griefing, as only you can issue more bonds from that address as only you have the private key to create a valid scriptSig.

If you were to use my P2SH hack you'd have to go a step further in the protocol, as it's really the act of spending from the special address itself that communicates the information. So just say that only if the last bit of the output amount is 0, one satoshi, is the information valid. Now you can freely any transactions sent to your magic address without communicating anything, at worst by including an extra input to get you an odd number of satoshis.


Of course this is all irrelevant for something like timestamping, where what you're really trying to do is get some data into the merkle tree of a block.

Sure you can. By putting it in the scriptSig we're announcing that the output of the transaction using that scriptSig is special and needs special handling despite being unspent.

This address has 1,100BTC on it:

http://blockchain.info/address/3JV5t22LzpdDmGUWJv2JYixAFgYWMiTbHx

and this one has 107BTC:

http://blockchain.info/address/3KhCQ2hxriLq1ytK5ttLL2Hz96q618tfRg

Note how on the first address the transactions funding it also sent 40BTC to 15ArtCgi3wmpQAAfYx4riaFmo4prJA4VsK, the Bitcoin Faucet donation address...

Speaking of, anyone have P2SH etc. usage stats? Would be interesting to know how many of the more unusual transactions are out there.

Also in biology parlance you would call street protests "honest signalling", in the sense that if you can can get thousands, or in some cases hundreds of thousands, of people to show up in a public area and demonstrate you've convincingly shown, in a way that is difficult to fake, that your viewpoint has tremendous support behind it. In democracies this is obviously important, and even in non-democracies this is still important as no large government can operate without the will of at least a good fraction of their population.

The trend towards non-violent protest that has been going on for decades creates large crowds that say both "we're here and want change", but also very importantly "you don't have to be afraid of us, we (mostly) play by the rules of society". Making sure that your enemies believe have a way out is tremendously important, and showing that you respect individual rights to not have violence used against them is a big part of that. People in the activist communities understand this well enough now that when you do see violent protest usually the question to ask is what authority is instigating the violence and for what aim.

Look into packet radio: http://en.wikipedia.org/wiki/Packet_radio Ham radio enthusiasts have already developed pretty well debugged code and protocols that does the data->audio->data chain over links far worse than any PC audio ever will be.

This has probably been brought up before, somewhere, but Gavin's suggestion is to add a new standard transaction of the following type:


So what's stopping someone from using transactions like the following as an interim measure?


That stores 64 or 128 bytes encoded in the public key(s), or even just 32 bytes with a compressed public key, while still having one real public key that you have a private key too so that you can spend the output of the transaction later. (any 1 of the 3 signatures can be used to spend) The encoded data can still be in the clear as well, for instance one of the two public keys can easily be "BOND", plus padding. (I assume random padding would be required to ensure the secret key can't be forced from an overly-simple public key)

You could also use a P2SH-style transaction, moving the data into the scriptSig:

scriptPubKey:
scriptSig:

On the UI side I'd suggest that when you co-sign the multi-sig transaction, change goes back to the multi-sig address, and the UI presents it as "Transfering xBTC to address foo, bar, etc", just like "basic" transactions work already on the blockchain.info wallet. I think this fits well with people's perception that the multi-sig address is a "vault" that has a slot in the side so you can put money into it, but only with multiple parties can money be taken out of it.

Heck, that'd make for a good icon actually, a vault-looking deposit box with a slot and two rotary combination locks on it.