Topic: Design notes for sharing work between multiple independent chains - page 3. (Read 15030 times)

Yes.


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.

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?

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.

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.

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.

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

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.

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.

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.

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.


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.


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.


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.

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


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.


... and ....


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.

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 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.



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".



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.



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.


Not at all:


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



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.

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

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.

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

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

Forget this part:

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?

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.

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?

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.

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.