Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes ho...@hozed.org wrote: I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. We already automatically merge forks that we become aware of simply by pulling in all the novel non-conflicting transactions the fork contains and including them in our next blocks. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Transactions != blocks. There is no need for a merge block. You are free to trade transactions off-line, so long as you are certain the other parties are not secretly double-spending coins they send you on the block chain. When connection to the bitcoin network is re-established, you simply transmit the transactions and in the regular course of things they make their way into one of the next blocks. Any transactions which derive from the double-spent one are invalid. But that's your problem, not the miners - chase after Bob and get him to give you the money he owes. On 12/17/2013 02:41 PM, Troy Benjegerdes wrote: I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. So what's the equivalent of this for Bitcoin or other crypto-currencies? Let's suppose that me and my friends get 'islanded' from the rest of the internet for a week, but we still want to trade bitcoin. It would work if there are local miners, until we reconnect. Suppose we have the main chain (Alice), while bob is on a boat, trading with some friends, but has no network connectivity. When bob reconnects with Alice, a 'Merge' transaction happens where a miner looks at bob's forked blockchain, sees no double-spends, and includes BOTH chains. Now suppose someone on bob's boat has a buggy client, or sent a transaction before disconnect that results in a double-spend on the merge. So we have a merge conflict, which generally requires human interaction, so bob and his friends broadcast a MERGE request with a transaction fee sufficient to cover reconciling the double-spends, AND incentivize a miner to do some extra work to merge. Thoughts everyone? -- Troy -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSsNTOAAoJEAdzVfsmodw4rBUP/jBFvPks4h0k1GQEPQPYvqNa 3OhuSlC9EfHmjXxftj6j0lH6JO60BFIoA3P76oFycQRqzNSw3YoldQ1MttpNAAZg ftiJJjYcuVmDYYWxfWPZN7ZsHrrhGkMn+i0PB1vXU3PB3sStb18vhbIoTZmwH7Rk vaUaX8EKFh6R8Y+6nqFMKu8eALaFQPJFP1aNo31ixsFFJrl02zQeIZiTbrOensEj 6AhXm2oYRqB1aolMmy/m5zcA3IicayJ6seoCQcRhPty6G2l+/4opgATdEBjzgczW Yhw20YkayyvPa+Fsqwad5AzgGYbm7OA0U6mO/pfeNhglNSt/TGfuSPe1oM9hWt9/ 8gP3PG4O4Fxi+gOAlNABgmoRKvQK8T3TX+eoayxPJiLxi+5l3+1CK0FK1+mKPThr heFrc5e9QlUIgATOpLYSs/elgAFM6N2Sez+RNiOg201M10VVKqXzBgZRQ+IYRRk6 jbaBKxsQ/ql5+2vwaUkplg/6Y6rfvRItQ+8xwXEvxazPAAh3Mp0fPbqas+F0e1Ie SwVTq517iV7eu+kMxOJEqaCky8ihbaUmshjeEccXdbodpygxCR2dZ0xAkvwXYtnK +ZjLQ7o8ySZs89Jvdx8H2fsu6m3hS/7Mm+zJVGV/hLHLoL7IrYPzTHcOHv8eT106 IYM30Hv+vDrt+f8ZRZ80 =09Pt -END PGP SIGNATURE- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
On Tuesday, December 17, 2013 10:41:30 PM Troy Benjegerdes wrote: I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. So what's the equivalent of this for Bitcoin or other crypto-currencies? Let's suppose that me and my friends get 'islanded' from the rest of the internet for a week, but we still want to trade bitcoin. It would work if there are local miners, until we reconnect. Suppose we have the main chain (Alice), while bob is on a boat, trading with some friends, but has no network connectivity. When bob reconnects with Alice, a 'Merge' transaction happens where a miner looks at bob's forked blockchain, sees no double-spends, and includes BOTH chains. Now suppose someone on bob's boat has a buggy client, or sent a transaction before disconnect that results in a double-spend on the merge. So we have a merge conflict, which generally requires human interaction, so bob and his friends broadcast a MERGE request with a transaction fee sufficient to cover reconciling the double-spends, AND incentivize a miner to do some extra work to merge. Thoughts everyone? This is interesting, but I'm not sure it has the right incentives. First, it adds more reason for miners to *avoid* including transactions (they might turn out to be double-spends and make merging costly). Second, it gives people reason to double-spend (the miner might cover the cost of it). Finally, you don't appear to address how to deal with the subsidy - do both miners get it? Luke -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
On Tue, Dec 17, 2013 at 02:48:14PM -0800, Gregory Maxwell wrote: On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes ho...@hozed.org wrote: I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. We already automatically merge forks that we become aware of simply by pulling in all the novel non-conflicting transactions the fork contains and including them in our next blocks. Now maybe this is a fatal flaw with Bitcoin's hard upper limit for number of coins, but any miners that with good faith tried to support an islanded bitcoin network now have generate transactions that get clobbered when the network reconnects. I can imagine a way to do this with some freicoin-like demurrage, which would only impact new coinbase based on the percentage of the hashing power that was on the other side of the fork. So if you are with the 95% of hashing power, you keep 95% of the new coins when the other 5% shows back up from being islanded. And this is also way more complicated than what I had first imagined to do securely and reliably. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
