From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vt3Kj-0000bg-S1 for bitcoin-development@lists.sourceforge.net; Tue, 17 Dec 2013 22:41:45 +0000 X-ACL-Warn: Received: from nl.grid.coop ([50.7.166.116]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Vt3Kc-0005C7-1d for bitcoin-development@lists.sourceforge.net; Tue, 17 Dec 2013 22:41:45 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by nl.grid.coop with local; Tue, 17 Dec 2013 16:41:30 -0600 id 000000000006A32E.0000000052B0D31A.00004ED0 Date: Tue, 17 Dec 2013 16:41:30 -0600 From: Troy Benjegerdes To: bitcoin-development@lists.sourceforge.net Message-ID: <20131217224130.GC3180@nl.grid.coop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1Vt3Kc-0005C7-1d Subject: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 22:41:46 -0000 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