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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5wqy-0000Qp-6M for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 14:01:08 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinbase.com designates 209.85.212.169 as permitted sender) client-ip=209.85.212.169; envelope-from=adrian@coinbase.com; helo=mail-wi0-f169.google.com; Received: from mail-wi0-f169.google.com ([209.85.212.169]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5wqs-0003gn-8j for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 14:01:08 +0000 Received: by wibdq8 with SMTP id dq8so19584170wib.1 for ; Fri, 19 Jun 2015 07:00:56 -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=4rbbCWubBPe9fOja2fxraq/PET2TeYqO+67KahTaFog=; b=kXujNUQgUmz6ujWP8/5uq6MGNh0OORMZch7c1iaBiT5PlH5osiCEX1Aahh2J1WqH8s fhng0O4cp5MlypNLN6HUJgsOdpGowxo/bxKjdC0ntQEP+P4UhMfSy3eAwSqFI5ONyY// osgRJegKHvhZfkxPvaAcx//V+0uvyM8ln2WYdfRd4WJXYsbc9dioyemkF4KOrEudtrSB lN4G+B5jgrr8RfCxtr7XCTih7FEl0nNLr6UcudqoZo02nEdmsbuINpLiayFaqYbU4h0D EcnIQZPwBGJidXNbo7wMwFlR0bn/fAqIp/G8Ob/AUkB4M0sPO4CdjQauSJADzKLDCf2i acIg== X-Gm-Message-State: ALoCoQls7112M7XhHIYiLD63wNK6+BVytt1PiS4YNWrBQvr2qM1oKfdRhbJgrTxeMH+8jRDtQlnb MIME-Version: 1.0 X-Received: by 10.194.187.170 with SMTP id ft10mr26126044wjc.26.1434722456259; Fri, 19 Jun 2015 07:00:56 -0700 (PDT) Received: by 10.27.177.99 with HTTP; Fri, 19 Jun 2015 07:00:56 -0700 (PDT) In-Reply-To: <20150619135245.GB28875@savin.petertodd.org> References: <20150619103959.GA32315@savin.petertodd.org> <20150619135245.GB28875@savin.petertodd.org> Date: Fri, 19 Jun 2015 07:00:56 -0700 Message-ID: From: Adrian Macneil To: Peter Todd Content-Type: multipart/alternative; boundary=047d7bb03a925b66f20518df5a25 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: 1Z5wqs-0003gn-8j 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:01:08 -0000 --047d7bb03a925b66f20518df5a25 Content-Type: text/plain; charset=UTF-8 > > For instance, if Coinbase had > contracts with 80% of the Bitcoin hashing power to guarantee their > transactions would get mined, but 20% of the hashing power didn't sign > up, then the only way to guarantee their transactions could be for the > 80% to not build on blocks containing doublespends by the 20%. > This seems to be more of a problem with centralized mining than zeroconf transactions. Speaking of, could we get a confirmation that Coinbase is, or is not, > one of the merchant service providers trying to get hashing power > contracts with mining pools for guaranteed transaction acceptance? IIRC > you are still an advisor to them. This is a serious concern for the > reasons I outlined in my post. > 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. In the long term, I would love to see a safe, decentralized solution for accepting zeroconf transactions. However, right now there is no such solution supported by any wallets in use, and I don't think breaking the current bitcoin behavior for everyone is the best way to achieve this. Adrian --047d7bb03a925b66f20518df5a25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For instance, if Coinbase had
contract= s with 80% of the Bitcoin hashing power to guarantee their
transactions = would get mined, but 20% of the hashing power didn't sign
up, then t= he only way to guarantee their transactions could be for the
80% to not = build on blocks containing doublespends by the 20%.
= =C2=A0
This seems to be more of a problem with centralized mining= than zeroconf transactions.

Speaking of, could we get a= confirmation that Coinbase is, or is not,
one of the merchant service providers trying to get hashing power
contracts with mining pools for guaranteed transaction acceptance? IIRC
you are still an advisor to them. This is a serious concern for the
reasons I outlined in my post.

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 sta= rted running your unsafe RBF patch, then we would probably need to look int= o this as a way to prevent fraud.

In the long term= , I would love to see a safe, decentralized solution for accepting zeroconf= transactions. However, right now there is no such solution supported by an= y wallets in use, and I don't think breaking the current bitcoin behavi= or for everyone is the best way to achieve this.

A= drian

--047d7bb03a925b66f20518df5a25--