Design notes for sharing work between multiple independent chains

[BitterTea]

No, it's absolutely nothing like that at all. I suggest you read up some more on the function of the block chain, and the proposed alternate block chains, so you can get a sense of how much data might have to be stored by all Bitcoin nodes if people were to start storing arbitrary data in the main block chain.

[1715394156]

1715394156

[1715394156]

1715394156

[unk]

i have never seen a project that so readily assumes ignorance in newbies! (maybe the typical newbies are more ignorant here than elsewhere?)

you appear to have misunderstood my message. my analogy was not meant to compare the stakes, only the futility and arbitrariness of the exercise.

you cannot prevent people from 'storing arbitrary data in the main block chain', so at best the present attempt is to get a few people to coordinate their efforts to reduce the size of the block chain by not including things that the group of people doesn't want to include. as i already noted, 'even if you solve the design problem to your satisfaction, it resurfaces as a security problem'. at best you're seeking a gentleman's agreement, analogous to advisory locking in a filesystem.

[ByteCoin]

I have never seen a project that so readily assumes ignorance in newbies!

I think that certain people have conclusions they like to jump to and they do so without properly reading the post they are replying to. It's also easy to infer criticism or an attack where none is meant.

Nobody is seriously suggesting anymore that one can prevent using the bitcoin chain to store data. People want to store data in the block chain to implement certain functionality and if we can facilitate the functionality by some other more convenient method then they will use that instead. Alt-chains attempts to do that.

[mike]'s proposal boils down to having miners who support alternative block chains incorporating a hash for one or more block chains in the coinbase transaction for the bitcoin blocks they're mining.

One drawback is that the people distributing the generic bitcoin client could pull the plug on all the alternative block chains by having their client reject blocks which have a non-standard coinbase. As alt-chain-compatible blocks would not be accepted and relayed by clients, the alt-chain supporting miners would essentially drop off the network. The bitcoin network would experience a drop in hashing power as these clients left but would otherwise continue unaffected.

I don't know whether the possibility of this kill-switch would be acceptable for the alt-chain users.

ByteCoin

[BitterTea]

One drawback is that the people distributing the generic bitcoin client could pull the plug on all the alternative block chains by having their client reject blocks which have a non-standard coinbase. As alt-chain-compatible blocks would not be accepted and relayed by clients, the alt-chain supporting miners would essentially drop off the network. The bitcoin network would experience a drop in hashing power as these clients left but would otherwise continue unaffected.

Hmm... I'm not sure this would be an issue as long as large or lots of miners adopted this method. I imagine a pool that offered mining of all complementary block chains would be quite popular, and it would be in the best interest of everyone who wants to receive confirmations that they accept these types of blocks.

[Mike Hearn]

Why would anyone want to kill off alternative chains so badly?

And yeah I agree with ByteCoin. "Preventing" abuse is really hard, often impossible. Making it senseless or pointless is quite easy and how nearly all abuse control works. Bitcoin will never be a good way to store arbitrary data just because it wasn't meant for that. There's almost always a better tool for your problem.

[xf2_org]

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.

If you try to stuff data through the existing system, it's like TCP-over-DNS:  possible, but so not designed for that purpose that it is slow, inefficient, limited and problematic.

It also impacts existing currency users, who probably don't want their currency use to be slowed or impacted by DNS data.  That will potentially slow or damage bitcoin-the-currency, which is what most people here are interested in.

[JohnDoe]

I'm not proficient with low-level bitcoin stuff yet, but... is such a transaction possible then?

in: 0.01 from a valid bitcoin address
out: 0.00 to arbitrary data / public key
(induced fee: 0.01 to the miner)

Yes -- that's how it would be done. 0-value outputs are valid.

OK, some people might hate me for this:...

If it's OK to store a hash that way... It should also be OK to store a small simple NS record, right? :->

I think so. Take a look at the DNS proposal that nanotube an I made, which stores records in that area:
http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

Sorry, I'm not a very technical person. Are you saying that a DNS system can be implemented on top of Bitcoin without needing to make any changes to the protocol or ask for permission from anyone? If so then doesn't that make Namecoin worthless or is a new block chain with new transaction types still technically superior than this method?

[theymos]

Are you saying that a DNS system can be implemented on top of Bitcoin without needing to make any changes to the protocol or ask for permission from anyone?

Yes.

If so then doesn't that make Namecoin worthless or is a new block chain with new transaction types still technically superior than this method?

Some people think that a separate system is better. I think combining DNS into Bitcoin's block chain (not into the Bitcoin software) is better because the incentive problem is already solved, it's easier to do, and it would give some intrinsic value to bitcoins.

[JohnDoe]

Some people think that a separate system is better. I think combining DNS into Bitcoin's block chain (not into the Bitcoin software) is better because the incentive problem is already solved, it's easier to do, and it would give some intrinsic value to bitcoins.

Yeah, I know the opposing views on the subject. I'm asking purely from a technical standpoint if your system has any limitation that Namecoin doesn't have, thus making the existence of Namecoin still worthwhile even if bitDNS is implemented. I ask because I was planning on investing in Namecoin but I'm afraid that if it becomes a threat to Bitcoin (which I think it will if Bitcoin remains purely for financial transactions forever) then your system will be widely supported and implement, thus crashing the value of namecoins.

[BitterTea]

How would Namecoin become a threat to Bitcoin?

[theymos]

Yeah, I know the opposing views on the subject. I'm asking purely from a technical standpoint if your system has any limitation that Namecoin doesn't have, thus making the existence of Namecoin still worthwhile even if bitDNS is implemented.

BitDNS can't use Bitcoin's lightweight client mode, so in the future it will always be rare for people to run their own BitDNS resolvers. I don't know if Namecoin is set up to use client mode, either, though. BitDNS probably requires more resources, too, since servers need to scan all non-DNS transactions.

I think Namecoin is broken for other reasons, though:
https://forum.bitcoin.org/index.php?topic=7244.msg106438#msg106438

[jtimon]

As most miners will forget old transactions, you would have to renew the transactions from time to time with BitDNS.
Am I right, theymos?
Maybe BitDNS clients could act like archivers.

[theymos]

As most miners will forget old transactions, you would have to renew the transactions from time to time with BitDNS.
Am I right, theymos?

Yes. Our spec handles this by requiring DNS renewals. There are ways to handle it more elegantly, though (using multiple 0-value outputs, for example). The spec was written a while ago.

[jtimon]

There are ways to handle it more elegantly, though (using multiple 0-value outputs, for example).

Can you explain (or give a link on) the "multiple 0-value output" solution?

[theymos]

An output with 0 value is valid, and these outputs can't be forgotten by the network until they are spent (which is also valid). So you can stuff all of the DNS data into several of those outputs.

When the bitDNS spec was written, having more than two outputs was not considered standard; therefore, it was difficult to get those transactions into blocks. Now they are standard.

[jtimon]

An output with 0 value is valid, and these outputs can't be forgotten by the network until they are spent (which is also valid). So you can stuff all of the DNS data into several of those outputs.

When the bitDNS spec was written, having more than two outputs was not considered standard; therefore, it was difficult to get those transactions into blocks. Now they are standard.

So people would put the DNS info in one output and would send bitcoins to the other to lock the transaction.
But in the demurrage fees thread has been said that miners can forget transactions even if they're not spent.

[theymos]

But in the demurrage fees thread has been said that miners can forget transactions even if they're not spent.

That's only if >50% of the mining power agrees to do that. I doubt it will ever happen.

[jtimon]

But in the demurrage fees thread has been said that miners can forget transactions even if they're not spent.

That's only if >50% of the mining power agrees to do that. I doubt it will ever happen.

No.
The demurrage fee will be charged only if the network agrees, but miners can forget transactions without asking permission. This was an argument against the need of demurrage fees. Most miners will forget old transactions, and only "archivers" (specialized miners) will get the fees for transactions that contain an "old account" as input.

[theymos]

No.
The demurrage fee will be charged only if the network agrees, but miners can forget transactions without asking permission. This was an argument against the need of demurrage fees. Most miners will forget old transactions, and only "archivers" (specialized miners) will get the fees for transactions that contain an "old account" as input.

I argued against that notion in the thread:

If miners with your rules don't have >50% of the network, you can't safely forget unspent transactions. If you are unable to find the transaction when it is needed for verification, you have only two bad choices:
- You can accept the transaction without checking it after it gets in a block. Every time one of these blocks ends up getting rejected by the majority of the network due to its invalid transaction, you will lose all of your hashing work since the last block. (This is even worse if you wait a few blocks before accepting it.)
- You can reject the transaction. Some important part of the network might accept the transaction, and you will be isolated from them unless you have more than 50% of the network.

[jtimon]

No.
The demurrage fee will be charged only if the network agrees, but miners can forget transactions without asking permission. This was an argument against the need of demurrage fees. Most miners will forget old transactions, and only "archivers" (specialized miners) will get the fees for transactions that contain an "old account" as input.

I argued against that notion in the thread:

If miners with your rules don't have >50% of the network, you can't safely forget unspent transactions. If you are unable to find the transaction when it is needed for verification, you have only two bad choices:
- You can accept the transaction without checking it after it gets in a block. Every time one of these blocks ends up getting rejected by the majority of the network due to its invalid transaction, you will lose all of your hashing work since the last block. (This is even worse if you wait a few blocks before accepting it.)
- You can reject the transaction. Some important part of the network might accept the transaction, and you will be isolated from them unless you have more than 50% of the network.

So you don't think miners will forget DNS transactions.
I think bitDNS could be good for bitcoin if there's a way to prevent DNS transactions to last forever. If bitDNS prevents miners from forgeting the DNS data by parking (or worse, burning) bitcoins in one of the two outputs (the other contains the DNS map), bitDNS service is taking a service from the bitcoin chain for "free" (everlasting storing). I don't think that's fair for the bitcoin network.
With demurrage, bitDNS would need to renew DNS transactions from time to time and would pay miners for the service (through demurrage or transaction fees).
Although I see the problems Namecoin can have, I think it would be interesting to develop the work sharing software for it, since it's the only other block chain in place right now.