Design notes for sharing work between multiple independent chains

[BitterTea]

I think you're missing an important point of Mike's: separate chains will have different difficulties.

If you set up Bittimestamp to generate a block on average once per minute, one will be generated once per minute, regardless of Bitcoin's difficulty. This is because for every hash that wins a Bitcoin block, millions are thrown away as "not sufficiently difficult". However, any one of those hashes (or many of them) are sufficiently difficult for the Bittimestamp chain, since there are potentially fewer miners computing for that chain.

So you can put BitDNS (and whatever other alternate non monetary block chains emerge) in the main Bitcoin block chain, but that forces everyone to process and store DNS data. Or you can come up with a robust and extendable way for any and all chains to be mined simultaneously.

[0x6763]

I think you're missing an important point of Mike's: separate chains will have different difficulties.

If you set up Bittimestamp to generate a block on average once per minute, one will be generated once per minute, regardless of Bitcoin's difficulty. This is because for every hash that wins a Bitcoin block, millions are thrown away as "not sufficiently difficult". However, any one of those hashes (or many of them) are sufficiently difficult for the Bittimestamp chain, since there are potentially fewer miners computing for that chain.

So you can put BitDNS (and whatever other alternate non monetary block chains emerge) in the main Bitcoin block chain, but that forces everyone to process and store DNS data. Or you can come up with a robust and extendable way for any and all chains to be mined simultaneously.

How do the Bittimestamp miners get transaction fees for generating Bittimestamp blocks?

[Mike Hearn]

Paying miners for including your NameTx can be done in a straightforward manner. Nothing fancy is required.

Introduce a couple of new fields into the NameTx message, call them:

Code:

  optional string miner_payment_address = 9;
  optional uint64 fee = 10;

When the buyer broadcasts his NameTx to claim a new name, he leaves the miner_payment_address field blank and sets the fee field to be however much he is willing to pay for inclusion into a block.

Miners that receive the transaction and begin working on it create a new BitCoin address for themselves and set miner_payment_address to it. When they solve a block, it is broadcast and the name enters a pending state. It isn't available for purchase anymore but it doesn't resolve to IP addresses either. To complete the purchase the buyer sends the fee to the miners address. Once they do so, each DNS node observes that the BitCoin address in the miner_payment_address field has received 'fee' coins and start serving the name. If insufficient payment is sent within a few days the name becomes available once again. The miner loses but the buyer doesn't get anything either. The pending state ensures that people cannot watch transactions and immediately outbid somebody then try to sell the name back to them at inflated prices.

I'm explaining this as an example of how to link chains together financially whilst keeping them separate. I don't actually think a BitDNS style system makes any sense. The interest seems to come primarily from wanting to prevent your name being seized by governments. If your website is illegal in a particular jurisdiction (like the USA) then there's a simple solution - use a domain name under a different countries TLD, pick a country where your operation is legal. If your operation is illegal everywhere then you have to use Tor which already provides a secure P2P DNS system, but also anonymity for both service provider and clients.

A BitDNS system only makes sense if you're very concerned about your domain name being seized, but not concerned at all about seizure of your servers, your clients identities or yourself. Maybe I missed something, but I can't think of any operations which actually operate under such a threat model.

[BitterTea]

Well, recent history has shown that it's a lot easier for governments (namely the United States) to seize domain names than physical objects. There is also the worry that ICANN will give in to political pressure and play censorship whackamole at the behest of powerful governments.

[0x6763]

Miners that receive the transaction and begin working on it create a new BitCoin address for themselves and set miner_payment_address to it. When they solve a block, it is broadcast and the name enters a pending state. It isn't available for purchase anymore but it doesn't resolve to IP addresses either. To complete the purchase the buyer sends the fee to the miners address. Once they do so, each DNS node observes that the BitCoin address in the miner_payment_address field has received 'fee' coins and start serving the name. If insufficient payment is sent within a few days the name becomes available once again. The miner loses but the buyer doesn't get anything either. The pending state ensures that people cannot watch transactions and immediately outbid somebody then try to sell the name back to them at inflated prices.

And this still leaves open the attack for flood the system with domain name registrations with no intention of buying them or using them...just to fill up space or even DDoS the network, due to the payments not being required at the time of registration.  I think I might see how the shared work can function, but it still leaves your proposal open to a very simple and easy attack unless the alternative block chain also has it's own currency and registrations come with a payment.

I don't actually think a BitDNS style system makes any sense. The interest seems to come primarily from wanting to prevent your name being seized by governments. If your website is illegal in a particular jurisdiction (like the USA) then there's a simple solution - use a domain name under a different countries TLD, pick a country where your operation is legal. If your operation is illegal everywhere then you have to use Tor which already provides a secure P2P DNS system, but also anonymity for both service provider and clients.

A BitDNS system only makes sense if you're very concerned about your domain name being seized, but not concerned at all about seizure of your servers, your clients identities or yourself. Maybe I missed something, but I can't think of any operations which actually operate under such a threat model.

Some of us don't believe permission from some random person or government is necessary to register a domain name, nor do we believe anyone has a right to take domain names away from us.  I've never (at least knowingly) done anything illegal with a domain name or website, and I don't intend to.  I think the real question is why should anyone else be able to stop me from registering a domain name or be able to take it away from me?  Why should anyone even be in such a position to do that, even if they never do interfere with me?  ICANN is nothing more than government waste, like the central banks.

[Mike Hearn]

And this still leaves open the attack for flood the system with domain name registrations with no intention of buying them or using them...just to fill up space or even DDoS the network, due to the payments not being required at the time of registration.

No it doesn't. There's a separation between coins you park in order to keep the domain - if those coins are spent the domain automatically releases. Then there's the coins you pay to the miner as an incentive to take part in the system. Those you spend when the block is found.

You can't DoS the network because miners wouldn't let you double spend parked coins on multiple domains. If I say output 1 of tx ABCD is the collateral for name mike.bit then I won't be allowed to reuse it to register mike2.bit.

I think the real question is why should anyone else be able to stop me from registering a domain name or be able to take it away from me?

I don't agree with your position because governments and laws do exist regardless of what you might like, and they will happily just seize your servers or throw you in jail if a court gives them permission.

But if you aren't going to do anything illegal, the current DNS works fine. The "D" in it stands for distributed, right? The only reason WikiLeaks had to move to .ch was a DDoS that could have come from anyone. It had nothing to do with governments, who left its infrastructure alone. In fact the parts of DNS controlled by the US Government are remarkably freeform. You don't actually have to be a network to register a .net domain, or a non-profit to register a .org, or a commercial enterprise to register .com even if that's what they're technically meant for. You don't have to be a US citizen or have any US presence, unlike some country TLDs.

If there were examples of DNS actually failing to work well today, BitDNS might be a more compelling proposal.

[HostFat]

I don't agree with your position because governments and laws do exist regardless of what you might like, and they will happily just seize your servers or throw you in jail if a court gives them permission.

There are some situations where the server and admin are out of the country.
Also many situations where the country aren't a truly freedom places.
Laws are subject of the usual human's failure.
It's better to build a system that isn't based on human's rules, as Bitcoin is itself.

[goblin]

Wow, a lot has happened since my last post.

Thanks everyone for insightful comments.

Let me just make something clear:

From [mike]'s standpoint, there's nothing to lose in terms of block storage space if we were to follow theymos's/satoshi's idea of 0-value output transactions with some data embedded before OP_DROP/OP_CHECKSIG. These transactions are already accepted by the stock client (and if anyone argues changing this, well, I think that'd be disastrous as it'd encourage coin burning as the only other alternative). These transactions could be pruned by the clients who are not interested in them! They have 0 output + a fee, so they can be considered spent and pruned (well as long as the miner spends her reward from the fee). Only nodes interested in BitStamp/BitDNS/BitX would keep and verify these transactions. So again, there's no problem to the mainstream clients at all in terms of storage; and in bandwidth, it's pretty much identical to the [mike]'s proposed send-to-self with later release.

[vinced]

Burning coins wasn't very well thought out, I had to get back to doing real work by the end of writing that so it was rushed

A simpler way that's compatible with the BitCoin of today is just to sign the NameTx with a private BitCoin key that has sufficient coins in it. If you spend those coins the name is automatically relinquished. The name network can simply ask BitCoin "what is the balance of this address" to find out if the name is still valid or should be released.

It'd be a bit annoying with todays software because there's no good way to stop BitCoin using some coins to make new spends. But there are patches floating around to let you extract keys out of BitCoin and re-import them, I think sipa was working on it. So to buy a name that costs 10 BTC you'd send that much to a new address owned by yourself, then export that keypair, then import into the NameCoin software which would use it to sign the NameTx. In practice this would be all automated by the NameCoin software that runs alongside BitCoin.

Are you referring to the actual Namecoin project that I started, or to another system?

I intend to implement cross-mining between chains but I don't see the value of sharing keys between the chains.  There will be exchange markets converting btc to nmc.  There were actually already some transactions along these lines.

[Mike Hearn]

I was using BitDNS/DnsCoin/NameCoin interchangably to refer to "people who would like to do DNS on top of block chain technology", sorry for any confusion. I haven't looked deeply at how you implemented it, but it's essentially a separate network with a couple more transaction types right?

Creating an alternative currency just for names then having exchange markets is indeed another way to do it. It's a bit less direct than tying the chains together, but I understand why you did that as I guess it's simpler to implement.

Looking forward to seeing your patches for chain work sharing. It'd be good to get this resolved so there's one less reason to try and abuse the main chain.

[nanotube]

What technical issues are solved by storing DNS data in the main block chain, as opposed to an alternate yet connected block chain, as Mike has proposed?

Incentives. If I want to make an alternative chain for timestamping documents, then no one will ever generate blocks on that chain, since there would be no profit.

If you can easily work incentives into your project, a side chain is better. Then you can do simple payment verification for your chain, too.

theymos, for your consideration:
i think incentives can easily be worked into [mike]'s scheme, if you just change the protocol to require the 'parking' transaction to have X fees. et voila, we have incentives. what do you think?

[goblin]

I intend to implement cross-mining between chains but I don't see the value of sharing keys between the chains.  There will be exchange markets converting btc to nmc.  There were actually already some transactions along these lines.

Well I think we discussed a different approach to yours, vinced. One where the bitcoin blockchain could be used in a simple non-intrusive way.

I have to say I personally don't like the idea of your approach with a separate chain. What you're effectively creating is a currency alternative to bitcoin, with an alternative blockchain. That'll cause competition and basically leave us with two weaker currencies, rather than 1 stronger one. I would prefer to have 1 stronger (mostly for technical reasons - less code duplication, less loss from converting from one to the other), but some people might prefer to have many weaker ones and trade between them -- matter of opinion I guess.

[jtimon]

So to summarize (and anyone correct me if I'm wrong) there's three possibilities:

1) Have the registrations in the bitcoin chain and pay for them with bitcoins
2) Have a parallel chain for name registration and pay with bitcoins for it (parking them as collateral)
3) Have a parallel chain for name registration, with its own currency and pay for registrations with that currency.

2 and 3 can share computing power with the bitcoin network.
I don't see 1 as a bad thing, but as has been said, its not suitable for all uses of the block chain.
The technology to share computing power is a necessary thing then. If a bitcoin-like competing currency emerges, it should share computing power with bitcoin (for bitcoin's and its own benefit). It would be also necessary for other services that work as 2. Although 3 could be the only solution for some cases (like other currencies), is it a good enough reason to start a new currency (allow it to pay for names registration instantly) while 2 can be done?
More questions about about namecoin:

Is it already functioning?
Does it have any other difference with bitcoin?
The monetary base will issued in the same way?

[jtimon]

https://github.com/vinced/namecoin/blob/master/FAQ.md

http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

Forget this part:

More questions about about namecoin:

Is it already functioning?
Does it have any other difference with bitcoin?
The monetary base will issued in the same way?

[Mike Hearn]

I've written up the results of this discussion and put it into a (very large) wiki page here:

  https://en.bitcoin.it/wiki/Alternative_Chains

The new page is similar to my original post with the following changes:

• A rewritten section on paying for things in alternative chains that consolidates discussion of paying to no-one (collateral) and paying to miners for both resource-owning chains like DNS, and pure-inclusion chains like timestamping services
• A new section on mining independent of Bitcoin
• A new section on scaling up to millions of alt-chains using merkle trees
• Slightly adjusted to keep mentions of DNS in the payment section and as an example of designing a tx at the start

Hope it helps.

[ByteCoin]

... and then your node makes an RPC to BitCoin telling it what the current extra hash is. When BitCoin finds a bitcoin block of the right difficulty for your network, it informs your software and passes the block header, coinbase tx and merkle branch to it

What stops an attacker who intends to fork your non-bitcoin block chain from sending their incorrect hashes "to Bitcoin"?
What exactly does "make an RPC to BitCoin" mean? What is "BitCoin" in this context? I presume you mean a particular bitcoin miner who has implemented the "support non-bitcoin chains" option.
How does the bitcoin node you're talking to know that it's getting a legitimate extra hash rather than let's say a portion of some illegal kiddie porn?
Who on the non-bitcoin chain has the responsibility for and authority to talk to the bitcoin node?
Everyone? - a lot of spam for the bitcoin node
One node? - single point of failure

The way your explanation is drafted makes it look like the non-bitcoin chain is limited to one transaction per bitcoin block. I presume you mean to expand the scheme to support rolling non-bitcoin transactions into non-bitcoin blocks and then getting hashes of those into the bitcoin block chain somehow. Could you expand on exactly how this would work?

ByteCoin

[Stefan Thomas]

Just read through the whole thing. Brilliant design, being able to share work without bogging down Bitcoin is awesome and the use of the coinbase is very elegant, it's practically begging to be used for this.

I believe the section "Scaling up" should be a normal part of the standard. It just makes sense to include that from the start rather than having two methods (list of hashes vs merkle) floating around later.

What stops an attacker who intends to fork your non-bitcoin block chain from sending their incorrect hashes "to Bitcoin"?

What do you mean by "incorrect"? The custom network would have its own rules on what constitutes a valid block or transaction. For example a DNS system would only allow registration of previously unregistered domains. This can be enforced by the clients of the custom network. The block chain's job is only to solve conflicts between two blocks that are both independently valid. The older block takes precedence over the younger block.

So your attacker could indeed include a hash of an invalid block for the custom network, but it would be rejected by the custom client if it is invalid or conflicts with a block that is referenced in an older Bitcoin block.

What exactly does "make an RPC to BitCoin" mean? What is "BitCoin" in this context? I presume you mean a particular bitcoin miner who has implemented the "support non-bitcoin chains" option.

A miner would run both the normal Bitcoin client as well as the client for the custom network. They would ask the custom client to construct a block, get its hash and send that to the mining Bitcoin client for inclusion in the coinbase using a new RPC command "setextrahashes".

How does the bitcoin node you're talking to know that it's getting a legitimate extra hash rather than let's say a portion of some illegal kiddie porn?

Miners would opt in to a specific custom network and run the software for that network themselves. In other words they know the blocks are trusted, because they have generated them themselves. As for the "transactions" in the blocks, such as name registrations/transfers for a DNS system, they'd have to be validated just like Bitcoin transactions are validated before miners include them.

Who on the non-bitcoin chain has the responsibility for and authority to talk to the bitcoin node?
Everyone? - a lot of spam for the bitcoin node
One node? - single point of failure

The custom network could have whatever architecture you want. Most likely it would be a P2P architecture in order to avoid a SPOF. As for spam - the custom network would have similar antispam measures as Bitcoin does, [mike] included a concept to pay for resources used on the custom network with Bitcoins. The miners that are connected to the custom network would have to bear the burden of receiving messages from it, they would likely require some sort of compensation for that service. Otherwise you could not motivate miners to run your custom network.

Non-mining nodes in the custom network would likely impose limits and restrictions on what it relays, again just like any P2P network.

The beauty of [mike]'s proposal is that he doesn't make any assumptions about the custom network. As long as it produces a hash it can interface with Bitcoin.

The way your explanation is drafted makes it look like the non-bitcoin chain is limited to one transaction per bitcoin block.

Not at all:

Code:

repeated MyTx transactions = 4;

The blocks in [mike]'s example contain an arbitrary number of transactions.

I presume you mean to expand the scheme to support rolling non-bitcoin transactions into non-bitcoin blocks and then getting hashes of those into the bitcoin block chain somehow. Could you expand on exactly how this would work?

That's up to the designer of the custom chain. They could either include all their data in their blocks (as in the example) or - more likely - include a merkle root like Bitcoin does.


Now I have a question for [mike]: The custom network would only get a block whenever a sympathetic miner makes a block for Bitcoin. So the average time for a confirmation would be 10 minutes divided by the percentage of miners supporting the custom network, correct?

Here is an idea: Could the custom network accept blocks of a lower difficulty? So basically you have the current Bitcoin difficulty target and then a lower difficulty target for the custom network. The Bitcoin miner would sometimes generate Bitcoin blocks that are completely valid as Bitcoin blocks, except they don't meet the full difficulty target required for Bitcoin. But they do meet the lower target for the custom network, so the miner would publish them there. That would allow the custom network to have any difficulty it wants and any rate of confirmations it wants while still sharing work with Bitcoin.

[Mike Hearn]

Hmm, it seems I need to make things clearer. Or maybe just shorter, it's a lot to digest all at once.

I believe the section "Scaling up" should be a normal part of the standard.

I put it in a separate section because it's already complex enough and quite a few people have struggled to understand it. Merging it into the first part would result in several independent merkle trees being discussed which is a recipe for confusion. I know that's one of the aspects of Satoshis explanation that foxed me for a long time.

Custom chain difficulties are mentioned already - alt chains will always have their own difficulty. Some other people weren't sure about this so I called it out in bold.

A more complex change is the other new RPC. Because you have your own chain, it has its own difficulty. Most likely it'll be different to Bitcoins own. So you need a way to tell Bitcoin "when you find a block that matches an extradifficulty, please let me know". To mine on multiple difficulties at once, the node vends work (via getwork) matching the easiest difficulty. When a miner reports finding a solution the difficulty is checked to see which chains it is sufficiently difficult for.

... and ....

You can choose your own parameters for the new chain. As an example, Satoshi chose to target one new block every ten minutes as a tradeoff between latency and wasted work. You could choose something much larger (hours, days) or much faster if you're willing to tolerate more splits due to blocks being found simultaneously. Bitcoin retargets the difficulty roughly every two weeks. You could choose some other length of time.

Each alt chain has its own difficulty and can make a new block every 10 minutes regardless of how many people mine on it, if that's what you want. The getwork protocol is already used to vend blocks of incorrect difficulty, it's how pools work. You'd use the same technique so the mining modules like ufasoft or poclbm report back whenever they find a block of sufficient difficulty for either chain.

[Mike Hearn]

What stops an attacker who intends to fork your non-bitcoin block chain from sending their incorrect hashes "to Bitcoin"? What exactly does "make an RPC to BitCoin" mean? What is "BitCoin" in this context?

The software that you download and run from bitcoin.org, ie, a regular (full) node in the Bitcoin P2P network.

Bitcoin already does the work of building bitcoin-format blocks, filling them with transactions and then vending the header to independent mining modules like poclbm. It allows you to talk to it via JSON-RPC, that's how mining modules get work to hash.

How does the bitcoin node you're talking to know that it's getting a legitimate extra hash rather than let's say a portion of some illegal kiddie porn?

Bitcoin doesn't care what the hash is. It just accepts some arbitrary 32 byte value and stuffs it into the current bitcoin blocks coinbase transaction scriptSig.

The only reason we need to get Bitcoin involved is to support simultaneous mining on both Bitcoin and other chains, which basically means finding an overlap point in those data structures. The overlap point is the scriptSig - essentially a scratchpad space where anyone who mines can put arbitrary data that Bitcoin will ignore. For instance the genesis block has a quote from the Financial Times in it.

Who on the non-bitcoin chain has the responsibility for and authority to talk to the bitcoin node?
Everyone? - a lot of spam for the bitcoin node
One node? - single point of failure

Everyone who runs an alt-chain node and who wants to mine also runs a Bitcoin node along side it. They talk over the localhost connection. There are no shared nodes.

The way your explanation is drafted makes it look like the non-bitcoin chain is limited to one transaction per bitcoin block.

Justmoon already mentioned this but to be totally clear, your alt-chain blocks can contain whatever you want, however many transactions you want, etc. To mine on your new DnsBlock you:

• Add a bunch of DNS transactions into your current DnsBlock data structure
• Hash that block (or do what Satoshi does and arrange transactions into a merkle tree, but it's optional)
• Now send that hash via a localhost RPC "setextrahashes" to Bitcoin, which has a bunch of GPU miners attached to it just like you normally would.

The "setextrahashes" RPC doesn't exist today but it's probably only an afternoons work to add.

The miners are now working on Bitcoin and your alt-chain simultaneously.

[unk]

isn't this discussion like the developers of a bittorrent client saying 'how should we design the client so that it lets people share only action movies, rather than comedies'? as theymos and others have implied, you can't stop it, and the principle upon which you'd favour 'finance' isn't clear anyhow.

what is 'nonfinancial' about a dns transaction but 'financial' about a generic multi-party contract? even if you solve the design problem to your satisfaction, it resurfaces as a security problem, for what could ever restrict the block chain to 'financial' information anyway? designing the 'action-movie only' bittorrent client would be a fool's errand.