Yeah, I understand your proposal. It's a lot more efficient than putting all data into the block chain, but it still involves "fake" transactions that look like financial transfers but actually aren't. I feel the design is still inferior to letting miners choose which chains they work on.
There's another downside I don't think you considered. It means Namecoin miners must interact with Bitcoin (keep up with the network, have coins, broadcast transactions). That's not a burden today, but if Bitcoin traffic continues to climb the burden will become higher. Merged mining allows people to mine only on the alt chain if they wish. The mining power can merge or split as miners see fit.
Topic: Oblivious merged mining, or getting miners to work for free (Read 2465 times)
There are many things that can be done if you assume the block chain is basically a global scribble-board, but I'd like to think most of us here have some sense of systems design. I wrote the alternative chains page because people were discussing fairly mind-bending hacks in order to encode a DNS system into the existing financial chain, which quite beyond the ethical/systems design issues inherent in that approach would have led to a completely crazy protocol and unmaintainable code.
So yes, obviously, you can do alternative chains in other ways. It seems better to do it that way though, in the long run. That's the whole point of alternative chains.
So yes, obviously, you can do alternative chains in other ways. It seems better to do it that way though, in the long run. That's the whole point of alternative chains.
Er the purpose of your alt chain doc was to point out to people they need not store their data in a block, just a hash. Thus less info bitcoin miners need to understand or even see. I am not proposing storing data in the chain, just a hash as well. In some sense what I am asking is how can we design a system that burdens bitcoin miners *even less*, by not even requiring them to know about any alt chain.
The system I proposed is identical to yours except for one crucial point: the link is made from another TX rather than coinbase. But this change now requires reasoning about what if a malicious party adds a second link. Perhaps that is what was unclear? I do not WANT to spam the block chain with multiple links. They would only arise only by result of someone trying to be malicious to both alt chain and bitcoin. Under "honest" operation, there would only be one such link TX.
My proposed solution was break ties by higher TX fee. IE link with higher fee is valid. My question was, is there a better way?
aha! you get it now, great.
Yes it sounds impossible at first, but I think it's naiive to immediately dismiss it as a non-starter. There can be very clever ways to do things.
In particular, the "break ties using TX fee" approach I described IS a solution; whether it is the best is what I was asking, perhaps there is a better one. Note that you can think of my scheme as trading paying to secure with hash power for paying to secure with already existing bitcoins.
In fact, a "bidding war" is actually not much of an issue here because the auction will end up being an ALL PAY auction, where even the losers pay.
In other words, this scheme allows an auxilliary block chain to literally pay miners/"transaction builders" for securing their chain with bitcoins, rather than by contributing hash power.
This is actually quite nice! It means you could do merged mining without requiring the pool owners/miners to update their software at all. Instead, namecoin enthusiasts would just be paying TX fees for the "winning" namecoin root.
Note also you could essentially simulate the existing system with my system. The "merged miners" would basically set the TX fee in such a way that it costs them an expected value of zero: because they are mining, they have some chance of getting that massive TX fee, while on the other hand otherwise they just pay a small portion of it (the namecoin root TX would have many inputs so many would pay).
Yes it sounds impossible at first, but I think it's naiive to immediately dismiss it as a non-starter. There can be very clever ways to do things.
In particular, the "break ties using TX fee" approach I described IS a solution; whether it is the best is what I was asking, perhaps there is a better one. Note that you can think of my scheme as trading paying to secure with hash power for paying to secure with already existing bitcoins.
In fact, a "bidding war" is actually not much of an issue here because the auction will end up being an ALL PAY auction, where even the losers pay.
In other words, this scheme allows an auxilliary block chain to literally pay miners/"transaction builders" for securing their chain with bitcoins, rather than by contributing hash power.
This is actually quite nice! It means you could do merged mining without requiring the pool owners/miners to update their software at all. Instead, namecoin enthusiasts would just be paying TX fees for the "winning" namecoin root.
Note also you could essentially simulate the existing system with my system. The "merged miners" would basically set the TX fee in such a way that it costs them an expected value of zero: because they are mining, they have some chance of getting that massive TX fee, while on the other hand otherwise they just pay a small portion of it (the namecoin root TX would have many inputs so many would pay).
Except that your scheme will never catch on because it won't work for reasons that I think you've pointed out. I mean, essentially, you are describing a system that does not exist and is in no danger of actually getting built, and then knocking down your own straw man.
So, yeah, you can make whatever transactions you want, even encoding hashes for other systems, and miners will blindly include whatever garbage you put into the script and "work for free". But you can't turn that into a useful system that other people will use because the thing that would make it useful would also make your hypothetical problem impossible.
There are many things that can be done if you assume the block chain is basically a global scribble-board, but I'd like to think most of us here have some sense of systems design. I wrote the alternative chains page because people were discussing fairly mind-bending hacks in order to encode a DNS system into the existing financial chain, which quite beyond the ethical/systems design issues inherent in that approach would have led to a completely crazy protocol and unmaintainable code.
So yes, obviously, you can do alternative chains in other ways. It seems better to do it that way though, in the long run. That's the whole point of alternative chains.
So yes, obviously, you can do alternative chains in other ways. It seems better to do it that way though, in the long run. That's the whole point of alternative chains.
That's not true
After wasting a good hour or two of my life arguing with the proposer I think I'm in a better position to talk about what he is and isn't proposing.
He's got a fetish for attacking bitcoin— after talking about this his next grand idea was to embed child pornography in the block-chain.
aha! you get it now, great.
Yes it sounds impossible at first, but I think it's naiive to immediately dismiss it as a non-starter. There can be very clever ways to do things.
In particular, the "break ties using TX fee" approach I described IS a solution; whether it is the best is what I was asking, perhaps there is a better one. Note that you can think of my scheme as trading paying to secure with hash power for paying to secure with already existing bitcoins.
In fact, a "bidding war" is actually not much of an issue here because the auction will end up being an ALL PAY auction, where even the losers pay.
In other words, this scheme allows an auxilliary block chain to literally pay miners/"transaction builders" for securing their chain with bitcoins, rather than by contributing hash power.
This is actually quite nice! It means you could do merged mining without requiring the pool owners/miners to update their software at all. Instead, namecoin enthusiasts would just be paying TX fees for the "winning" namecoin root.
Note also you could essentially simulate the existing system with my system. The "merged miners" would basically set the TX fee in such a way that it costs them an expected value of zero: because they are mining, they have some chance of getting that massive TX fee, while on the other hand otherwise they just pay a small portion of it (the namecoin root TX would have many inputs so many would pay).
Yes it sounds impossible at first, but I think it's naiive to immediately dismiss it as a non-starter. There can be very clever ways to do things.
In particular, the "break ties using TX fee" approach I described IS a solution; whether it is the best is what I was asking, perhaps there is a better one. Note that you can think of my scheme as trading paying to secure with hash power for paying to secure with already existing bitcoins.
In fact, a "bidding war" is actually not much of an issue here because the auction will end up being an ALL PAY auction, where even the losers pay.
In other words, this scheme allows an auxilliary block chain to literally pay miners/"transaction builders" for securing their chain with bitcoins, rather than by contributing hash power.
This is actually quite nice! It means you could do merged mining without requiring the pool owners/miners to update their software at all. Instead, namecoin enthusiasts would just be paying TX fees for the "winning" namecoin root.
Note also you could essentially simulate the existing system with my system. The "merged miners" would basically set the TX fee in such a way that it costs them an expected value of zero: because they are mining, they have some chance of getting that massive TX fee, while on the other hand otherwise they just pay a small portion of it (the namecoin root TX would have many inputs so many would pay).
Basically the purpose of this thread is to illustrate what is wrong with just simply moving the coinbase link in the existing merged mining scheme to a link somewhere else (e.g. in another TX rather than coinbase, so the miner need not put it in himself and anyone else can instead).
I see. You mean merged mining where not only is the miner oblivious but the entity that builds the transaction set to be included in the block is oblivious as well.Yeah, that's a non-starter. There would be no proof of work in that case since no work was done. The idea is to pile proof of work on top of provably valid blocks.
The miners can be oblivious, but the entity that forms the transaction set cannot be.
I think you're still missing the point that a person doing merged mining is simultaneously attempting to mine both a bitcoin block and a namecoin block. If he succeeds, he will introduce two *different* blocks (but with the same proof of work), one to the bitcoin system and one to the namecoin system. Either block may or may not take in either block chain based on that system's rules.
This confirms you completely misunderstood the post. I am not talking about the existing merged mining AT ALL. I am talking about designing a NEW system for doing merged mining where the person doing the mining is NOT attempting to mine both blocks. Not only that, but the miner does not even know what namecoin is, much less that they are being used to verify a namecoin block. Reread the thread with this in mind and I think it will all make sense to you.
Basically the purpose of this thread is to illustrate what is wrong with just simply moving the coinbase link in the existing merged mining scheme to a link somewhere else (e.g. in another TX rather than coinbase, so the miner need not put it in himself and anyone else can instead).
I am not discussing a scheme where a miner is aware of both namecoin and bitcoin but rather one where the miner is only aware of bitcoin.
I understand that.Quote
1) "Is that data valid": What about the case where you *do not know* if that data is valid? I.e., the data is not provided? Sure you go ahead and build on the one that you have data for. But then magically you get the data for the other one, and a reorg occurs
It doesn't matter if non-namecoin clients don't know if the data is valid in the namecoin system. They don't care, nor need they care.Quote
2) "The longest chain wins" The ENTIRE PROBLEM is that if there are TWO valid namecoin roots in a block there can be TWO longest chains.
Then the one you saw first wins until and unless the other one becomes longer. No problem.Quote
To prevent this, you must not allow a single bitcoin block to count for any more than one chain. But you can't do this just by saying "ok if a block has more than 1 namecoin ref, noone of them are valid", because then anyone can DOS the namecoin proof-of-work. So you need a precise semantics for deciding which namecoin reference is the canonical one for a given bitcoin block.
I don't understand. How can someone DOS the namecoin proof-of-work? If they introduce an invalid block, the namecoin system simply ignores it. No harm done.Quote
If you do not still see the issue I can't say anything else, hopefully others will see this thread and understand and perhaps explain better. It would be nice if those who worked on mergedmining can think about it.
It's entirely obvious why this is not a problem. I can't imagine how you don't see it. If a block is introduced in the bitcoin system that is invalid in the namecoin system, the namecoin system simply ignores that block, now and forever.The only reason your cases seem to be a problem is that you're conflating the test to determine if the block is valid for bitcoin purposes with the test to determine if the block is valid for namecoin purposes. They are two independent tests. A block can be valid for one purpose and not for the other. At any time, the valid namecoin chain is the long one that consists of only blocks that are valid by namecoin rules.
I think perhaps you are misunderstanding in that you think I am discussing the current merged mining scheme. I am not. I am discussing an alternate scheme that has not been discussed before the OP. Is that clear?? The assertions you are making about my scheme don't make sense because I haven't even fully specified the scheme, so it sounds like you are arguing I am misunderstanding merged mining when the system in this scheme is not at all the existing merged mining scheme. I am not discussing a scheme where a miner is aware of both namecoin and bitcoin but rather one where the miner is only aware of bitcoin.
I guess I will try this precisely one more time and if you can't understand I'll just hope someone else sees this post who does.
1) "Is that data valid": What about the case where you *do not know* if that data is valid? I.e., the data is not provided? Sure you go ahead and build on the one that you have data for. But then magically you get the data for the other one, and a reorg occurs
2) "The longest chain wins" The ENTIRE PROBLEM is that if there are TWO valid namecoin roots in a block there can be TWO longest chains.
To make this abundantly clear, here is an explicit example.
AGAIN THIS IS IN A NEW SYSTEM NOT MERGED MINING AS IT IS NOW
Do you see the problem? If a single bitcoin block can "count" as a proof-of-work for two distinct namecoin blocks, then there will never be a longest chain! You just have a big puddle of chains, all of the same length. If you just then break ties arbitrarily by say, order in transaction, you are just going to switch between chains every block!
To prevent this, you must not allow a single bitcoin block to count for any more than one chain. But you can't do this just by saying "ok if a block has more than 1 namecoin ref, noone of them are valid", because then anyone can DOS the namecoin proof-of-work. So you need a precise semantics for deciding which namecoin reference is the canonical one for a given bitcoin block.
If you do not still see the issue I can't say anything else, hopefully others will see this thread and understand and perhaps explain better. It would be nice if those who worked on mergedmining can think about it.
I guess I will try this precisely one more time and if you can't understand I'll just hope someone else sees this post who does.
1) "Is that data valid": What about the case where you *do not know* if that data is valid? I.e., the data is not provided? Sure you go ahead and build on the one that you have data for. But then magically you get the data for the other one, and a reorg occurs
2) "The longest chain wins" The ENTIRE PROBLEM is that if there are TWO valid namecoin roots in a block there can be TWO longest chains.
To make this abundantly clear, here is an explicit example.
Code:
Bitcoin block 0
-> pointer to Namecoin block 0A
-> pointer to Namecoin block 0B
Client has data for block 0a but not 0b. "Hmm I'll just assume 0A is the valid chain then.."
Bitcoin block 1
-> pointer to Namecoin block 1A
-> pointer to Namecoin block 1B
Again, client has data for block 1A but not 1B. Does same as before, assumes 1A is valid
Bitcoin block 2
-> pointer to Namecoin block 2B
Now client finally can get data for 0B,1B,2B. This is now a longer chain so switch occurs.
Bitcoin block 3
-> pointer to Namecoin block 2A
Two chains of same length.
-> pointer to Namecoin block 0A
-> pointer to Namecoin block 0B
Client has data for block 0a but not 0b. "Hmm I'll just assume 0A is the valid chain then.."
Bitcoin block 1
-> pointer to Namecoin block 1A
-> pointer to Namecoin block 1B
Again, client has data for block 1A but not 1B. Does same as before, assumes 1A is valid
Bitcoin block 2
-> pointer to Namecoin block 2B
Now client finally can get data for 0B,1B,2B. This is now a longer chain so switch occurs.
Bitcoin block 3
-> pointer to Namecoin block 2A
Two chains of same length.
AGAIN THIS IS IN A NEW SYSTEM NOT MERGED MINING AS IT IS NOW
Do you see the problem? If a single bitcoin block can "count" as a proof-of-work for two distinct namecoin blocks, then there will never be a longest chain! You just have a big puddle of chains, all of the same length. If you just then break ties arbitrarily by say, order in transaction, you are just going to switch between chains every block!
To prevent this, you must not allow a single bitcoin block to count for any more than one chain. But you can't do this just by saying "ok if a block has more than 1 namecoin ref, noone of them are valid", because then anyone can DOS the namecoin proof-of-work. So you need a precise semantics for deciding which namecoin reference is the canonical one for a given bitcoin block.
If you do not still see the issue I can't say anything else, hopefully others will see this thread and understand and perhaps explain better. It would be nice if those who worked on mergedmining can think about it.
So the "legitimate" namecoin chain block header will be linked off some bitcoin TX. But the problem is anyone can add such a "namecoin block header pseudo-TX" to the bitcoin block pointing to whatever they want. Remember, miners have no idea what is going on, and in particular they are not verifying namecoin for us. So there must be some way to distinguish the "winning" branch from all the others.
The longest valid chain wins. Period.Quote
The point of the OP is the only way I can see to do this is for the "honest" namecoin participants to add a large TX fee to their favored "namecoin block-header pseudo-TX", and decide the "winning" branch is the one with largest TX fee. This has a problem though in that malicious people can just arbitrarily bid up the TX fee knowing honest namecoin participants will try to outbid them...
I don't know why you think this. The longest valid chain wins, period. Ties are broken by the chain seen first. Period.Quote
But because we are just sticking data in transactions, anyone can do this, and we could end up with this picture if anyone decides to add such a tx for fun:
No problem. Either that data is valid or it's not. If it's valid, no harm is done. If it's invalid, it will be ignored by every namecoin client so, again, on harm done.Code:
Bitcoin Block
->Some bitcoin TX
-> IAMANAMECOIN magic string
-> hash of namecoin block header
->Some other bitcoin TX
-> IAMANAMECOIN magic string
-> hash of another namecoin block header
->Some bitcoin TX
-> IAMANAMECOIN magic string
-> hash of namecoin block header
->Some other bitcoin TX
-> IAMANAMECOIN magic string
-> hash of another namecoin block header
Quote
The problem is there is no "50% of hashing power" because the whole point of this scheme is that the hashing power/miners have absolutely no idea what is being stored, and hence are not actually verifying anything beyond the blocks they form are valid BITCOIN blocks. In particular, they are NOT checking that the links to namecoin blocks are valid, because they don't even know what they are or that they are there.
No, you are incorrect. Every namecoin client will validate that the block is valid. If not, the fact that it is in the bitcoin chain is irrelevant -- it will be completely ignored by the namecoin system.A bitcoin miner can include any garbage they want in a bitcoin block. If it's valid per the bitcoin specification and broadcast to the network at the right time, it will be accepted as a node in the bitcoin block. If it's valid according to the namecoin specification and broadcast to the namecoin network at the right time, it will be accepted as a node in the namecoin block. Whether or not it's accepted into the bitcoin chain has no effect on whether or not it's accepted into the namecoin chain and vice versa. In fact, they are completely different blocks. Only the proof of work is the same.
I think you're still missing the point that a person doing merged mining is simultaneously attempting to mine both a bitcoin block and a namecoin block. If he succeeds, he will introduce two *different* blocks (but with the same proof of work), one to the bitcoin system and one to the namecoin system. Either block may or may not take in either block chain based on that system's rules.
As I said in #bitcoin-dev:
This is a crap scheme which will burden every financial user of bitcoin which tons of crap data which is pointless for their financial transactions.
Quote
Bitcoin users should aggressively block to the maximum extent possible (e.g. by refusing to forward transactions and blocks with large amounts of garbage data stuffed inside them).
That would have no effect since the scheme doesn't involve forwarding any transactions or putting large amounts of data in bitcoin blocks.A lot of people had similar objections before they understood what was actually being proposed. All that would go in the bitcoin chain is the merkle root -- it's smaller than a single transaction. And it would only go in if someone doing merged mining happened to mine a bitcoin block.
It is fundamental to the logic of bitcoin that a miner gets to choose which transactions he puts in his block. It is, of course, antisocial for a miner to cram his block with garbage transactions, but a single transaction per block hardly qualifies. In exchange, the bitcoin system becomes more secure.
As I said in #bitcoin-dev:
This is a crap scheme which will burden every financial user of bitcoin which tons of crap data which is pointless for their financial transactions. Bitcoin users should aggressively block to the maximum extent possible (e.g. by refusing to forward transactions and blocks with large amounts of garbage data stuffed inside them). Anyone engaging in this crap should be forced to burn coins, by the network imposing minimum output sizes, thus compensating all bitcoin users by increasing scarcity.
The 'officially enforced' alternative chain scheme has nice O(1) scaling properties: One additional hash is added to each block to enable a practically infinite number of alternative chains. With that, people have no real excuse to fill the blockchain with garbage data.
No, they won't stall or DOS the namecoin chain because that block will be completely ignored by namecoin -- as if it doesn't exist.
Right, but so will the legit block! I think your confusion is due to my OP which was admittedly not very clear at all. Let me try again.The plan is to do something like the AlternativeChains protocol on the wiki without the miner's needing to know about it. So this means we must link the namecoin block off another bitcoin TX, not the coinbase.
So the "legitimate" namecoin chain block header will be linked off some bitcoin TX. But the problem is anyone can add such a "namecoin block header pseudo-TX" to the bitcoin block pointing to whatever they want. Remember, miners have no idea what is going on, and in particular they are not verifying namecoin for us. So there must be some way to distinguish the "winning" branch from all the others.
The point of the OP is the only way I can see to do this is for the "honest" namecoin participants to add a large TX fee to their favored "namecoin block-header pseudo-TX", and decide the "winning" branch is the one with largest TX fee. This has a problem though in that malicious people can just arbitrarily bid up the TX fee knowing honest namecoin participants will try to outbid them...
To reiterate:
The proposed structure is
Code:
Bitcoin Block
->Some bitcoin TX
-> IAMANAMECOIN magic string
-> hash of namecoin block header
->Some bitcoin TX
-> IAMANAMECOIN magic string
-> hash of namecoin block header
But because we are just sticking data in transactions, anyone can do this, and we could end up with this picture if anyone decides to add such a tx for fun:
Code:
Bitcoin Block
->Some bitcoin TX
-> IAMANAMECOIN magic string
-> hash of namecoin block header
->Some other bitcoin TX
-> IAMANAMECOIN magic string
-> hash of another namecoin block header
->Some bitcoin TX
-> IAMANAMECOIN magic string
-> hash of namecoin block header
->Some other bitcoin TX
-> IAMANAMECOIN magic string
-> hash of another namecoin block header
Quote
It's not a problem. I'm not sure how I can more clearly explain why it's not, but it's not.
Imagine if someone generated a bitcoin block and revealed the headers but not the transactions. Everyone would simply act as if that block didn't exist. Sure, someone who has the transactions could extend that chain all by themselves, but it doesn't matter, the public chain will outpace them.
All of the things you are worrying about are non-issues. If you have any suspicions about a block, ignore it. So long as everyone follows the same rules, the chain ignoring the suspect blocks will outpace the chain with them.
If someone adds a namecoin block to the bitcoin chain, it will be honored as a namecoin block if, and only if, it follows all the namecoin rules to perfection. If so, it cannot hurt anything because it follows all the rules. If not, it cannot hurt anything because it will be ignored.
So long as more than 50% of the hashing power follows the agreed-upon rules, the rightful chain will always outpace any other chains. If less than 50% of the hashing power follows the rules, you are screwed no matter what.
Or, to put it another way, any mined block will either eventually wind up in the public hash chain or it won't. If it doesn't, then who cares what rules it follows or breaks? It will be ignored anyway. If so, it must eventually convince the majority of the hashing power that it follows the rules.
Imagine if someone generated a bitcoin block and revealed the headers but not the transactions. Everyone would simply act as if that block didn't exist. Sure, someone who has the transactions could extend that chain all by themselves, but it doesn't matter, the public chain will outpace them.
All of the things you are worrying about are non-issues. If you have any suspicions about a block, ignore it. So long as everyone follows the same rules, the chain ignoring the suspect blocks will outpace the chain with them.
If someone adds a namecoin block to the bitcoin chain, it will be honored as a namecoin block if, and only if, it follows all the namecoin rules to perfection. If so, it cannot hurt anything because it follows all the rules. If not, it cannot hurt anything because it will be ignored.
So long as more than 50% of the hashing power follows the agreed-upon rules, the rightful chain will always outpace any other chains. If less than 50% of the hashing power follows the rules, you are screwed no matter what.
Or, to put it another way, any mined block will either eventually wind up in the public hash chain or it won't. If it doesn't, then who cares what rules it follows or breaks? It will be ignored anyway. If so, it must eventually convince the majority of the hashing power that it follows the rules.
The problem is there is no "50% of hashing power" because the whole point of this scheme is that the hashing power/miners have absolutely no idea what is being stored, and hence are not actually verifying anything beyond the blocks they form are valid BITCOIN blocks. In particular, they are NOT checking that the links to namecoin blocks are valid, because they don't even know what they are or that they are there.
Again, the whole point of the OP is that you cannot simply do what you suggest.
I don't consider that reasonable..
No, they won't stall or DOS the namecoin chain because that block will be completely ignored by namecoin -- as if it doesn't exist.Such a block is invalid. Pretend it doesn't exist.
So you suggest anyone be able to stall the network/DOS the namecoin chain by adding an extra namecoin-tagged tx to the bitcoin chain?I don't consider that reasonable..
Quote
Quote
Then pretend you didn't see the namecoin header in the block. Until it's presented to you as a namecoin block you should assume it's not a namecoin block unless you mined it. It's the miner's responsibility to submit the block to the network in complete, valid form.
What would you do if you found a bitcoin block with a valid header, without the transactions, on a web site somewhere? You would ignore it.
What would you do if you found a bitcoin block with a valid header, without the transactions, on a web site somewhere? You would ignore it.
But that might come back to haunt you if that chain gets longer. Since the miner isn't verifying things, anyone can easily add a namecoin-root TX to the bitcoin blockchain.
The two problems are related, both stemming from the fact that anyone can easily add a namecoin-root TX.
Imagine if someone generated a bitcoin block and revealed the headers but not the transactions. Everyone would simply act as if that block didn't exist. Sure, someone who has the transactions could extend that chain all by themselves, but it doesn't matter, the public chain will outpace them.
All of the things you are worrying about are non-issues. If you have any suspicions about a block, ignore it. So long as everyone follows the same rules, the chain ignoring the suspect blocks will outpace the chain with them.
If someone adds a namecoin block to the bitcoin chain, it will be honored as a namecoin block if, and only if, it follows all the namecoin rules to perfection. If so, it cannot hurt anything because it follows all the rules. If not, it cannot hurt anything because it will be ignored.
So long as more than 50% of the hashing power follows the agreed-upon rules, the rightful chain will always outpace any other chains. If less than 50% of the hashing power follows the rules, you are screwed no matter what.
Or, to put it another way, any mined block will either eventually wind up in the public hash chain or it won't. If it doesn't, then who cares what rules it follows or breaks? It will be ignored anyway. If so, it must eventually convince the majority of the hashing power that it follows the rules.
Again, the whole point of the OP is that you cannot simply do what you suggest.
I don't consider that reasonable..
But that might come back to haunt you if that chain gets longer. Since the miner isn't verifying things, anyone can easily add a namecoin-root TX to the bitcoin blockchain.
The two problems are related, both stemming from the fact that anyone can easily add a namecoin-root TX.
Such a block is invalid. Pretend it doesn't exist.
So you suggest anyone be able to stall the network/DOS the namecoin chain by adding an extra namecoin-tagged tx to the bitcoin chain?I don't consider that reasonable..
Quote
Then pretend you didn't see the namecoin header in the block. Until it's presented to you as a namecoin block you should assume it's not a namecoin block unless you mined it. It's the miner's responsibility to submit the block to the network in complete, valid form.
What would you do if you found a bitcoin block with a valid header, without the transactions, on a web site somewhere? You would ignore it.
What would you do if you found a bitcoin block with a valid header, without the transactions, on a web site somewhere? You would ignore it.
But that might come back to haunt you if that chain gets longer. Since the miner isn't verifying things, anyone can easily add a namecoin-root TX to the bitcoin blockchain.
The two problems are related, both stemming from the fact that anyone can easily add a namecoin-root TX.
I think you missed the point. That is obvious. What is not obvious is (1) what to do if two namecoin block headers appear in a single block
Such a block is invalid. Pretend it doesn't exist.Quote
and (2) what to do if you see a namecoin header in a block but can't get the actual namecoin data its referring to.
Then pretend you didn't see the namecoin header in the block. Until it's presented to you as a namecoin block you should assume it's not a namecoin block unless you mined it. It's the miner's responsibility to submit the block to the network in complete, valid form.What would you do if you found a bitcoin block with a valid header, without the transactions, on a web site somewhere? You would ignore it.
I think you missed the point. That is obvious. What is not obvious is (1) what to do if two namecoin block headers appear in a single block and (2) what to do if you see a namecoin header in a block but can't get the actual namecoin data its referring to.
Sure, there's a way. It has two requirements though:
1) The transactions that constitute the namecoin blocks must be valid bitcoin transactions, and
2) The namecoin block chain must support block that have an arbitrary header and where the namecoin merkle data is embedded in a bitcoin transaction.
So here's how it works:
The pool syncs to both block chains. The pool generates the hash of the namecoin chain and transactions and embeds it in a valid bitcoin transaction. The pool assigns work units to its miners.
When a miner submits proof of work, the pool checks if the PoW meets the bitcoin difficulty. If so, it combines the block with the bitcoin header and transactions and publishes it to the bitcoin network.
The pool then checks if it meets the Namecoin difficulty. If so, it combines the block with the namecoin header and namecoin transactions, the bitcoin dummy transaction, header, and the rest of the merkle tree for all bitcoin transactions except the coinbase and namecoin transaction.
Namecoin clients would have to validate this block a bit differently. After validating the namecoin transactions, they'd have to confirm that the bitcoin dummy transaction contained the correct merkel data for the namecoin block and that bitcoin block contained the correct merkle data for the bitcoin transactions. There would be no need to check that the block is valid in the bitcoin block chain, it would prove work either way.
The miners could only find out if they successfully mined a block. Then, of course, they would see the very same hash they had generated.
1) The transactions that constitute the namecoin blocks must be valid bitcoin transactions, and
2) The namecoin block chain must support block that have an arbitrary header and where the namecoin merkle data is embedded in a bitcoin transaction.
So here's how it works:
The pool syncs to both block chains. The pool generates the hash of the namecoin chain and transactions and embeds it in a valid bitcoin transaction. The pool assigns work units to its miners.
When a miner submits proof of work, the pool checks if the PoW meets the bitcoin difficulty. If so, it combines the block with the bitcoin header and transactions and publishes it to the bitcoin network.
The pool then checks if it meets the Namecoin difficulty. If so, it combines the block with the namecoin header and namecoin transactions, the bitcoin dummy transaction, header, and the rest of the merkle tree for all bitcoin transactions except the coinbase and namecoin transaction.
Namecoin clients would have to validate this block a bit differently. After validating the namecoin transactions, they'd have to confirm that the bitcoin dummy transaction contained the correct merkel data for the namecoin block and that bitcoin block contained the correct merkle data for the bitcoin transactions. There would be no need to check that the block is valid in the bitcoin block chain, it would prove work either way.
The miners could only find out if they successfully mined a block. Then, of course, they would see the very same hash they had generated.
Upon reading about merged mining, I was surprised to see it basically assumed that miners and verifiers were one and the same. That need not be the case, and actually distinguishing the two can lead to interesting designs that avoid the need for miners to update software, or even know anything at all about what they're mining.
The goal is to somehow do merged mining completely obliviously to the miners. Note this could potentially mean we need not even pay them for "mining" our alternative currencies (I am interested in this purely from a technical standpoint; the question of if this is ethical is totally orthogonal and so not in scope of this topic), which would be amazing if feasible from a technical standpoint. Curiously though, I can't see a way to get away with being so cheap: this post will describe a basic idea, the problems, and how payment gives a solution.
The obvious strategy is to include the merkleroot as data in a normal transaction, rather than the coinbase, along with some tag saying "i'm really a merkleroot for a namecoin header".
The problem, of course, is what happens when two such transactions appear in a block?
One solution is just take the first in order of appearance arbitrarily.
Another better one is an auction: the tx with largest fee "wins" and is the valid namecoin header. Now consensus in the alternative chain could be achieved by passing around a giant bitcoin transaction with NO outputs, paying everything as a TX fee.
Alas, there is a more fundamental problem. Suppose there are 2 "im a namecoin header" txs in a single block. Suppose further the "winning" transaction is one that noone has any info about: the person who made it chose to keep the block to himself, not giving the data to anyone. So all we have is a merkleroot and no idea what it points to. Maybe the person who made it got disconnected or his computer crashed.
"OK, fine, we'll just use the other one if we don't have the data for the first one then!" We do that, and next block, curiously enough, the same thing happens, we see a mystery merkleroot and have no idea what's inside.
The point is at some point, the person reveals all those historic blocks, and had work done for all of them, so now they instantly become "correct".
The fundamental problem is that a single bitcoin block must only provide proof-of-work for a single namecoin block (this is obvious when namecoin root is in coinbase, but not obvious if its elsewhere). Further, if multiple namecoin roots are provided, it must be clear how to pick a winner, and people must not deviate from that even if the data for the winner is unavailable.
One solution to this problem, in the auction scheme, is if the data is unavailable, then the "honest" network agrees to raise the TX fee they pay for their fake TX, and hopefully outbid whoever is holding block data. So now instead of needing 50% of hashing power, the honest network needs to be able to collectively outbid those colluding/holding blocks for the "highest TX fee namecoin merkleroot".
The question
Is there some way to do this without even paying the miners? Or perhaps less expensively, paying them less?
The goal is to somehow do merged mining completely obliviously to the miners. Note this could potentially mean we need not even pay them for "mining" our alternative currencies (I am interested in this purely from a technical standpoint; the question of if this is ethical is totally orthogonal and so not in scope of this topic), which would be amazing if feasible from a technical standpoint. Curiously though, I can't see a way to get away with being so cheap: this post will describe a basic idea, the problems, and how payment gives a solution.
The obvious strategy is to include the merkleroot as data in a normal transaction, rather than the coinbase, along with some tag saying "i'm really a merkleroot for a namecoin header".
The problem, of course, is what happens when two such transactions appear in a block?
One solution is just take the first in order of appearance arbitrarily.
Another better one is an auction: the tx with largest fee "wins" and is the valid namecoin header. Now consensus in the alternative chain could be achieved by passing around a giant bitcoin transaction with NO outputs, paying everything as a TX fee.
Alas, there is a more fundamental problem. Suppose there are 2 "im a namecoin header" txs in a single block. Suppose further the "winning" transaction is one that noone has any info about: the person who made it chose to keep the block to himself, not giving the data to anyone. So all we have is a merkleroot and no idea what it points to. Maybe the person who made it got disconnected or his computer crashed.
"OK, fine, we'll just use the other one if we don't have the data for the first one then!" We do that, and next block, curiously enough, the same thing happens, we see a mystery merkleroot and have no idea what's inside.
The point is at some point, the person reveals all those historic blocks, and had work done for all of them, so now they instantly become "correct".
The fundamental problem is that a single bitcoin block must only provide proof-of-work for a single namecoin block (this is obvious when namecoin root is in coinbase, but not obvious if its elsewhere). Further, if multiple namecoin roots are provided, it must be clear how to pick a winner, and people must not deviate from that even if the data for the winner is unavailable.
One solution to this problem, in the auction scheme, is if the data is unavailable, then the "honest" network agrees to raise the TX fee they pay for their fake TX, and hopefully outbid whoever is holding block data. So now instead of needing 50% of hashing power, the honest network needs to be able to collectively outbid those colluding/holding blocks for the "highest TX fee namecoin merkleroot".
The question
Is there some way to do this without even paying the miners? Or perhaps less expensively, paying them less?
Jump to: