* [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
@ 2013-12-17 22:41 Troy Benjegerdes
2013-12-17 22:48 ` Gregory Maxwell
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Troy Benjegerdes @ 2013-12-17 22:41 UTC (permalink / raw)
To: bitcoin-development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
2013-12-17 22:41 [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains Troy Benjegerdes
@ 2013-12-17 22:48 ` Gregory Maxwell
2013-12-18 6:03 ` Troy Benjegerdes
2013-12-17 22:48 ` Mark Friedenbach
2013-12-17 22:50 ` Luke-Jr
2 siblings, 1 reply; 5+ messages in thread
From: Gregory Maxwell @ 2013-12-17 22:48 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: Bitcoin Development
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
2013-12-17 22:41 [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains Troy Benjegerdes
2013-12-17 22:48 ` Gregory Maxwell
@ 2013-12-17 22:48 ` Mark Friedenbach
2013-12-17 22:50 ` Luke-Jr
2 siblings, 0 replies; 5+ messages in thread
From: Mark Friedenbach @ 2013-12-17 22:48 UTC (permalink / raw)
To: bitcoin-development
-----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-----
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
2013-12-17 22:41 [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains Troy Benjegerdes
2013-12-17 22:48 ` Gregory Maxwell
2013-12-17 22:48 ` Mark Friedenbach
@ 2013-12-17 22:50 ` Luke-Jr
2 siblings, 0 replies; 5+ messages in thread
From: Luke-Jr @ 2013-12-17 22:50 UTC (permalink / raw)
To: bitcoin-development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
2013-12-17 22:48 ` Gregory Maxwell
@ 2013-12-18 6:03 ` Troy Benjegerdes
0 siblings, 0 replies; 5+ messages in thread
From: Troy Benjegerdes @ 2013-12-18 6:03 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-12-18 6:04 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-17 22:41 [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains Troy Benjegerdes
2013-12-17 22:48 ` Gregory Maxwell
2013-12-18 6:03 ` Troy Benjegerdes
2013-12-17 22:48 ` Mark Friedenbach
2013-12-17 22:50 ` Luke-Jr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox