Message-ID: <52B0D4CE.9020108@monetize.io>
Date: Tue, 17 Dec 2013 14:48:46 -0800
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20131217224130.GC3180@nl.grid.coop>
In-Reply-To: <20131217224130.GC3180@nl.grid.coop>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] RFC: MERGE transaction/script/process for
 forked chains
Precedence: list

-----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-----