[Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

[Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

[Troy Benjegerdes]

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

Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

[Gregory Maxwell]

On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes <hozer@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.

Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

[Mark Friedenbach]

-----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=84349831&iu=/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-----

Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

[Luke-Jr]

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

Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

[Troy Benjegerdes]

On Tue, Dec 17, 2013 at 02:48:14PM -0800, Gregory Maxwell wrote:
> On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes <hozer@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.