[PROPOSAL] The Second Bitcoin Whitepaper

[notme]

In order for the above to work though, our blocks can't have a reward, otherwise people will have incentive to overpower it.  In fact, the block finder should pay the transaction fee to lock the chain to bitcoin.  Then, only those who value the security of the block chain have incentive to mine.

[notme]

We don't need bitcoin other than to allow us to include a block hash to secure our block chain, smaller than a transaction.  Maybe we even kick in a small transaction fee.  Our blocks can be built with cpu miners throttled to 10% of one core, or whatever keeps the CPU in the lowest power state.

And how will you disallow someone from putting whatever they want to into the block hash value that you are piggybacking into the bitcoin block chain?  What's to stop someone from violating all of the rules, whatever those are, in the secondary block chain and getting the hash for that into the bitcoin block chain, thus completely fubar'ing your secondary chain?

The only thing that would stop this is if miners refused to include invalid secondary block hashes in the main bitcoin block chain; and to determine what secondary chain hashes are invalid would require that those miners validate everything in that block chain before including the hash of it into the bitcoin block chain.

Therefore, you cannot simply pickyback on the bitcoin block chain in a meaningful way without adding significant workload to the bitcoin miners, and that is not going to happen without significant recompense to them.  How are you going to manage that?

Our client would still ignore invalid blocks even if they are bitcoin-stamped.

[dacoinminster]

In order for the above to work though, our blocks can't have a reward, otherwise people will have incentive to overpower it.  In fact, the block finder should pay the transaction fee to lock the chain to bitcoin.  Then, only those who value the security of the block chain have incentive to mine.

I think we could give the miner a transaction fee that is only valid if the rest of the nodes running the new protocol accept the hash in the block. That would give the miner a good incentive to get the exchange rates right.

[notme]

In order for the above to work though, our blocks can't have a reward, otherwise people will have incentive to overpower it.  In fact, the block finder should pay the transaction fee to lock the chain to bitcoin.  Then, only those who value the security of the block chain have incentive to mine.

I think we could give the miner a transaction fee that is only valid if the rest of the nodes running the new protocol accept the hash in the block. That would give the miner a good incentive to get the exchange rates right.

But do we need another hash race?  Why compete with bitcoiners for hardware?  You're just driving up costs for everyone.

[bji]

Our client would still ignore invalid blocks even if they are bitcoin-stamped.

So now every client needs to validate every single block just to be able to ensure that transaction that occurred sometime after that block does not rely on something that is invalidated?

Now you're back into the 'validating transactions is so impractical as to be impossible' scenario.

[bji]

In order for the above to work though, our blocks can't have a reward, otherwise people will have incentive to overpower it.  In fact, the block finder should pay the transaction fee to lock the chain to bitcoin.  Then, only those who value the security of the block chain have incentive to mine.

I think we could give the miner a transaction fee that is only valid if the rest of the nodes running the new protocol accept the hash in the block. That would give the miner a good incentive to get the exchange rates right.

Once again you're back to making transactions so hard to verify as to be impractical.  Now everyone who wants to detect whether or not a miner who claimed a transaction fee for a block that included one of your hashes, has to validate your entire secondary database, to determine whether the block is valid.  This is much more expensive than your earlier assertion that all you need "is a slot in the bitcoin block chain for a hash value".

[dacoinminster]

But do we need another hash race?  Why compete with bitcoiners for hardware?  You're just driving up costs for everyone.

I definitely don't want to compete with bitcoin hashing in any way. I just want to give miners an incentive to include an extra hash in the blocks they are already generating.

[notme]

Our client would still ignore invalid blocks even if they are bitcoin-stamped.

So now every client needs to validate every single block just to be able to ensure that transaction that occurred sometime after that block does not rely on something that is invalidated?

Now you're back into the 'validating transactions is so impractical as to be impossible' scenario.

Validation is orders of magnitude easier than discovering proof of work.  Only our client would do it, and it is something every bitcoin client does.  I don't see a problem.

[notme]

Our blockchain will in no way need to be verified by bitcoin, except when bitcoin enters or leaves.  That can happen much less frequently and carry a much larger transaction fee as incentive.

[dacoinminster]

Once again you're back to making transactions so hard to verify as to be impractical.  Now everyone who wants to detect whether or not a miner who claimed a transaction fee for a block that included one of your hashes, has to validate your entire secondary database, to determine whether the block is valid.  This is much more expensive than your earlier assertion that all you need "is a slot in the bitcoin block chain for a hash value"

Yes, fees paid to miners for including the new hash would NOT be backwards compatible with older versions of bitcoin. Only people running updated software would recognize that the miner collected the fee.

Anyone running the new software would have to verify that the hash matched the transactions and exchange rates they cared about. Anybody running a miner would have to check all transactions and exchange rates to decide if they need to reject any previous blocks.

I'm not sure to what extent the new protocol could be backwards-compatible with the old protocol. It seems like a lot of it could be backwards compatible, but you run into problems when you have a miner collect a fee that is only recognized by the new clients, then he tries to spend it. There might be no way to get around it except to get everyone switched to the new protocol.

[bji]

Our client would still ignore invalid blocks even if they are bitcoin-stamped.

So now every client needs to validate every single block just to be able to ensure that transaction that occurred sometime after that block does not rely on something that is invalidated?

Now you're back into the 'validating transactions is so impractical as to be impossible' scenario.

Validation is orders of magnitude easier than discovering proof of work.  Only our client would do it, and it is something every bitcoin client does.  I don't see a problem.

I am not sure about that.  Even validating simple bitcoin transactions requires knowing the entire history of the transaction chain that leads up to the transaction in question.  Except that because bitcoin only allows validated transactions into the block chain, and because each transaction completely spends the output of the prior transaction, you really only need to keep track of the most recent transaction in every chain of transactions.

In your proposal it seems that, since the bitcoin miners aren't doing any work at all to validate your data set before including the block, every client is going to have to evaluate every single data set completely in order to have an accurate picture of what transactions going forward from that point are valid and which ones aren't.  It just seems like an incredible multiplication of the amount of work for everyone.

With bitcoin, a client can keep just the block chain headers and from that, it can query to someone with more resources than itself to validate transactions in a light weight manner, and can verify their results based on the small block chain headers that it stores (~4 MB per year, easily sustainable for every bitcoin peer).  How will such a thing be done in your external block chain, which will have both valid and invalid blocks and for which the client will not know, just from bitcoin block headers, which ones were valid and which ones weren't?

[dacoinminster]

I am not sure about that.  Even validating simple bitcoin transactions requires knowing the entire history of the transaction chain that leads up to the transaction in question.  Except that because bitcoin only allows validated transactions into the block chain, and because each transaction completely spends the output of the prior transaction, you really only need to keep track of the most recent transaction in every chain of transactions.

In your proposal it seems that, since the bitcoin miners aren't doing any work at all to validate your data set before including the block, every client is going to have to evaluate every single data set completely in order to have an accurate picture of what transactions going forward from that point are valid and which ones aren't.  It just seems like an incredible multiplication of the amount of work for everyone.

With bitcoin, a client can keep just the block chain headers and from that, it can query to someone with more resources than itself to validate transactions in a light weight manner, and can verify their results based on the small block chain headers that it stores (~4 MB per year, easily sustainable for every bitcoin peer).  How will such a thing be done in your external block chain, which will have both valid and invalid blocks and for which the client will not know, just from bitcoin block headers, which ones were valid and which ones weren't?

I believe it is the same problem that bitcoin already solves. If somebody puts bad data into a block, the next miner running the new software would reject the previous block as if it had never been created. Normal users could wait for N confirmations on anything they care about, just like they do now.

[hashcoin]

I don't see how you think this can work.  Why would anyone vote for the correct exchange rate?  Any rational person would vote for the option that pays out the escrow funds to their side of the bet.

[cunicula]

3) Most of these ideas completely miss the genius idea of bitcoin which is to produce a system of fully disclosed information that anyone can use to validate any transaction.  People propose all kinds of ways to 'peg' bitcoins value relative to something else, or to modify the number of bitcoins generated, or to introduce esoteric new transaction types that have some secondary effect ("contingent claims"), but without any idea how such things could ever be validated realistically and identically by all bitcoin peers.  Any source of external data, such as a "current value of oil" or "current value of gold", cannot implicity be agreed upon by all bitcoin peers, so immediately the ability for all peers to validate transations goes away.

If you are referring to the specific "contingent claims" that I proposed, your criticism here is very far off the mark. My proposal suggests derivatives based upon mining difficulty precisely because difficulty can "be validated realistically and identically by all bitcoin peers." Difficulty derivatives do not require external data for validation.

If you are referring to "contingent claims" as a general concept, you might choose your language more carefully to avoid confusion.

[bji]

3) Most of these ideas completely miss the genius idea of bitcoin which is to produce a system of fully disclosed information that anyone can use to validate any transaction.  People propose all kinds of ways to 'peg' bitcoins value relative to something else, or to modify the number of bitcoins generated, or to introduce esoteric new transaction types that have some secondary effect ("contingent claims"), but without any idea how such things could ever be validated realistically and identically by all bitcoin peers.  Any source of external data, such as a "current value of oil" or "current value of gold", cannot implicity be agreed upon by all bitcoin peers, so immediately the ability for all peers to validate transations goes away.

If you are referring to the specific "contingent claims" that I proposed, your criticism here is very far off the mark. My proposal suggests derivatives based upon mining difficulty precisely because difficulty can "be validated realistically and identically by all bitcoin peers." Difficulty derivatives do not require external data for validation.

If you are referring to "contingent claims" as a general concept, you might choose your language more carefully to avoid confusion.

I was referring to it in the limited capacity in which I understood it, and in my understanding it introduced transaction chains that require extra work to validate.  But the comments I made in the specific topic never were addressed so I don't know if I was off the mark.

[cunicula]

3) Most of these ideas completely miss the genius idea of bitcoin which is to produce a system of fully disclosed information that anyone can use to validate any transaction.  People propose all kinds of ways to 'peg' bitcoins value relative to something else, or to modify the number of bitcoins generated, or to introduce esoteric new transaction types that have some secondary effect ("contingent claims"), but without any idea how such things could ever be validated realistically and identically by all bitcoin peers.  Any source of external data, such as a "current value of oil" or "current value of gold", cannot implicity be agreed upon by all bitcoin peers, so immediately the ability for all peers to validate transations goes away.

If you are referring to the specific "contingent claims" that I proposed, your criticism here is very far off the mark. My proposal suggests derivatives based upon mining difficulty precisely because difficulty can "be validated realistically and identically by all bitcoin peers." Difficulty derivatives do not require external data for validation.

If you are referring to "contingent claims" as a general concept, you might choose your language more carefully to avoid confusion.

I was referring to it in the limited capacity in which I understood it, and in my understanding it introduced transaction chains that require extra work to validate.  But the comments I made in the specific topic never were addressed so I don't know if I was off the mark.

Oh, you are right. I did fail to respond to you. Your post was unusually thoughtful, so I wanted to take my time in responding. Then I got distracted. Sorry. I will bump the thread with a response soon.

[dacoinminster]

I don't see how you think this can work.  Why would anyone vote for the correct exchange rate?  Any rational person would vote for the option that pays out the escrow funds to their side of the bet.

Again, the external exchange rate voting does not affect what the escrow funds pay out to whom (that is decided by supply and demand). The external exchange rate ONLY affects the fees on transactions, nudging them towards the external exchange rate.

Also, keep in mind that the only real mechanism for "voting" is to reject a block because it doesn't match the exchange rate you calculated. The vast, vast majority of clients have a strong incentive to get it right. It would take massive collusion to get more than 50% of the computing power to accept a different external exchange rate, and that would only accomplish an annoying change in the fee structure. There are a lot more lucrative things you could do with 51% of bitcoin hashing power.

I am totally confident that the distributed exchange rate would work just fine if implemented correctly. The main disruptive idea here is the transfer of volatility risk from the token holders to the hyperbitcoin holders. That is the scary new thing to me, and while it seems like it would work to me, it is not clear what the exact rules should be, or how it could be tested.

[cunicula]

I don't agree with your optimistic assessment of honest exchange rate reporting. You might want to look at my thread on " securing contingent claims" which discusses an alternative mechanism.

[dacoinminster]

I don't agree with your optimistic assessment of honest exchange rate reporting. You might want to look at my thread on " securing contingent claims" which discusses an alternative mechanism.

What, no link?!

Sigh. OK, I'll search for it. Here it is: http://forum.bitcoin.org/index.php?topic=19130.0

[dacoinminster]

Here's a thought experiment for you:

1) Starting condition: escrow fund contains $4T worth of bitcoins, $2T of that is from hyperbitcoin speculators
2) Satoshi sells 10K bitcoins because he wants to buy Australia, instantly driving down bitcoin prices by 10%
3) Protocol: "Escrow fund is 10% below target. Time to steal some hyperbitcoins from the speculators. YOINK!"
4) Speculators: *Jump out the window*
5) Protocol: "Now I'll sell these hyperbitcoins to new speculators. KA-CHING!"
6) New Speculators: Yay!
7) Ending condition: hyperbitcoin prices down some, escrow fund is back to target value, somebody cleans dead speculators off the pavement, new speculators can get rich when bitcoin prices come back

Now here's the important bit, which I just realized: What happens to bitcoin prices when the protocol sells a bunch of hyperbitcoins which it stole from existing speculators? Let's see, we removed a bunch of bitcoins from circulation and put them in the escrow fund. Less bitcoin supply = higher bitcoin prices.

Did the new bitcoin protocol just self-stabilize the price of bitcoins? Did we just create a bitcoin variant that resists price changes??

I'm not saying that bitcoin prices would be immobile, but that they would be inherently less volatile, because hyperbitcoin holders would be absorbing that volatility.