Date: Sun, 15 Feb 2015 14:51:54 -0600
From: Troy Benjegerdes <hozer@hozed.org>
To: Tamas Blummer <tamas@bitsofproof.com>
Message-ID: <20150215205154.GQ14804@nl.grid.coop>
References: <20150212064719.GA6563@savin.petertodd.org>
	<7C171F0B-1EF8-4542-8E18-187B2E94DF14@bitsofproof.com>
	<20150212074509.GC4254@savin.petertodd.org>
	<8BFAFE6A-F85B-4B89-98A0-CBBCAA67B30B@bitsofproof.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <8BFAFE6A-F85B-4B89-98A0-CBBCAA67B30B@bitsofproof.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Precedence: list

On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote:
> 
> 
> On Feb 12, 2015, at 9:16 AM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
> > Why don't you use getrawmempool RPC call to synchronize mempool contents?
> 
> 
> 
> Since RPC interface does not scale to serve a multi user service.
> In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus.
> 
> POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only. 
> These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to.
> 

If a proprietary stack has problems with replace-by-fee then it's probably 
succeptible to malicious attack because an attacker could just broadcast
one transaction to the network and then replace it when they are able to
mine a block themselves.

> 
> On Feb 12, 2015, at 8:45 AM, Peter Todd <pete@petertodd.org> wrote:
> > IOW, assume every transaction your "border router" gives you is now the
> > one and only true transaction, and everything conflicting with it must
> > go.
> 
> 
> You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting 
> double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic .
>