From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5xJL-0007YC-W4 for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 14:30:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinbase.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=adrian@coinbase.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5xJH-0004W1-6n for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 14:30:27 +0000 Received: by wicnd19 with SMTP id nd19so20841532wic.1 for ; Fri, 19 Jun 2015 07:30:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eod5m2fmsZW6/mTMuPeVhAWXC33YRRo2oO62Ilx6kzc=; b=BfddzwuziRuJ9FiA4Rcvdn193ls9RXgAeiJ+pFH7UmMbdZ8vlyIVy2eTY4aVu+fhsq /9k78nkL0yVyowgdvSeLLdEt1CVll8SY3SrPvjC3+jBqwnnbbcodxCSR/FStm/8v4j/w 3CaZz9RTutuhMqt2ZmOj5DmaUXuBb2MGwNi2AiPbLuw/dZyP0JRFsIYj24fCcjOlsxDN HnxemfXfrysayNDFojT73ETeZHQKkQ9jEzUs3LPR8H5btIUixPr9Xhw154I+0o/d68Rq nPIj5662ypZsyOqR0Fg/juH8i/i1ObxsM4LC66BowJcmzDSc34Jg8jxnFfctkNjsAIzg scww== X-Gm-Message-State: ALoCoQnhQRXVVdivi2NlmMBcN4pEBqYVJnRIWA9Hg6/PCOx8YP4HUhGx/HPzICkeOA1Et4oS2LLI MIME-Version: 1.0 X-Received: by 10.180.37.230 with SMTP id b6mr7320040wik.14.1434724217179; Fri, 19 Jun 2015 07:30:17 -0700 (PDT) Received: by 10.27.177.99 with HTTP; Fri, 19 Jun 2015 07:30:17 -0700 (PDT) In-Reply-To: <20150619140815.GA32470@savin.petertodd.org> References: <20150619103959.GA32315@savin.petertodd.org> <20150619135245.GB28875@savin.petertodd.org> <20150619140815.GA32470@savin.petertodd.org> Date: Fri, 19 Jun 2015 07:30:17 -0700 Message-ID: From: Adrian Macneil To: Peter Todd Content-Type: multipart/alternative; boundary=e89a8f64701d50f0620518dfc3be X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z5xJH-0004W1-6n Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee 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: Fri, 19 Jun 2015 14:30:28 -0000 --e89a8f64701d50f0620518dfc3be Content-Type: text/plain; charset=UTF-8 > > > We have no contracts in place or plans to do this that I am aware of. > > > > However, we do rely pretty heavily on zeroconf transactions for merchant > > processing, so if any significant portion of the mining pools started > > running your unsafe RBF patch, then we would probably need to look into > > this as a way to prevent fraud. > > What happens if the mining pools who are mining double-spends aren't > doing it delibrately? Sybil attacking pools appears to have been done > before to get double-spends though, equally there are many other changes > the reduce the reliability of transaction confirmations. For instance > the higher demands on bandwidth of a higher blocksize will inevitably > reduce the syncronicity of mempools, resulting in double-spend > opportunities. Similarly many proposals to limit mempool size allow > zeroconf double-spends. > > In that case would you enter into such contracts? > We take it as it comes. Currently, it's perfectly possible to accept zeroconf transactions with only a very small chance of double spend. As long as it's only possible to double spend a small fraction of the time, it's an acceptable cost to us in exchange for being able to provide a fast checkout experience to customers and merchants. If the status quo changes, then we will need to investigate alternatives (which realistically would include mining contracts, or only accepting instant payments from other trusted hosted wallets, which would be a net loss for decentralization). Long term we would prefer to see an open, decentralized solution, such as payment channels / green addresses / lightening networks. However, I think as a community we are a long way away from choosing a standard here and implementing it across all popular wallet software and merchant processors. Adrian --e89a8f64701d50f0620518dfc3be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> We have no contracts in pl= ace or plans to do this that I am aware of.
>
> However, we do rely pretty heavily on zeroconf transactions for mercha= nt
> processing, so if any significant portion of the mining pools started<= br> > running your unsafe RBF patch, then we would probably need to look int= o
> this as a way to prevent fraud.

What happens if the mining pools who are mining double-spends aren&#= 39;t
doing it delibrately? Sybil attacking pools appears to have been done
before to get double-spends though, equally there are many other changes the reduce the reliability of transaction confirmations. For instance
the higher demands on bandwidth of a higher blocksize will inevitably
reduce the syncronicity of mempools, resulting in double-spend
opportunities. Similarly many proposals to limit mempool size allow
zeroconf double-spends.

In that case would you enter into such contracts?

=
We take it as it comes.

Currently, it&#= 39;s perfectly possible to accept zeroconf transactions with only a very sm= all chance of double spend. As long as it's only possible to double spe= nd a small fraction of the time, it's an acceptable cost to us in excha= nge for being able to provide a fast checkout experience to customers and m= erchants.

If the status quo changes, then we will = need to investigate alternatives (which realistically would include mining = contracts, or only accepting instant payments from other trusted hosted wal= lets, which would be a net loss for decentralization).

=
Long term we would prefer to see an open, decentralized solution, such= as payment channels / green addresses / lightening networks. However, I th= ink as a community we are a long way away from choosing a standard here and= implementing it across all popular wallet software and merchant processors= .

Adrian
--e89a8f64701d50f0620518dfc3be--