Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 87CE420C2 for ; Thu, 8 Oct 2015 06:10:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C82AA31 for ; Thu, 8 Oct 2015 06:10:38 +0000 (UTC) Received: by vkfp126 with SMTP id p126so25702602vkf.3 for ; Wed, 07 Oct 2015 23:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=v20DT2bSmz0T/wQZiuY5Rid7b5iISW4ZdBENtS5zAaU=; b=LfAN5L+9wnnAVTS+O32oW1EzkDR/YREdyruZRuMmDjPazgGeGre1gjC1FpDDSKAhFA DEAai8YcY2ReAKspOI9L42vrP35Eq/+lpEKqZOgl11WkWzLjtX07Q3hB5pbyOb7dl2qw qEKVzrR/iV2sNZhJgLsZ/eBanNR1VNlQFUqS+Bf9GHLH0vT9HU1rO4pxQPgZ7XfyiCrm IfrjesJn3eDHczgyIkBwGFLyew1DJEVYfoLKG2Kjvt7LBPDzPtKSqRCIEp++0z3P+goG Zbhy2OwexS9pQuInkRogsuYsadZex2LFwkAMLbgLhLshNYikSkYTLvQALaeolelmZoGh EgEw== MIME-Version: 1.0 X-Received: by 10.31.41.79 with SMTP id p76mr3885025vkp.149.1444284637771; Wed, 07 Oct 2015 23:10:37 -0700 (PDT) Received: by 10.103.97.199 with HTTP; Wed, 7 Oct 2015 23:10:37 -0700 (PDT) Date: Wed, 7 Oct 2015 23:10:37 -0700 Message-ID: From: Taariq Lewis To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a113edfa6ca044e052191b8a8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 06:10:39 -0000 --001a113edfa6ca044e052191b8a8 Content-Type: text/plain; charset=UTF-8 Our comment was posted to Github: https://github.com/bitcoin/bitcoin/pull/6771#issuecomment-146429708 We, at Serica and DigitalTangible actively use unspent tx chains to allow our customers to speed their bitcoin user-experience without the need for them to wait on blockchain confirmations. These transactions are usually sequential and must happen between our customers and our marketplace of merchants and other customers. For example, a user agrees to place an order to purchase bitcoin and then make a bitcoin payment, for a product or services, with that bitcoin, should their desired price be met while they are unable to actively monitor their transaction. We currently do not have a need to chain more than 5 unspents given our current use cases for onboarding new customers into the bitcoin ecosystem. Given this PR, we agree with its principle, since the proposal aims to limit to MAX_ANCESTORS = 25 and MAX_DESCENDANTS = 25, which we think is reasonable. We have not **yet** seen a use case for more than 25 chains of unconfirmed in our ecosystem. However, we would like to publish our viewpoint that we wish to avoid a slippery slope of restrictions in unspents to fall from from 25 to 2 or even 0. The limits imposed should not prevent, at minimum, 5 step chains of transactions that are needed to give a customer temporary control over funds that they would otherwise not have access to unless they waited for a confirmation before conducting another transaction. In these situations, where an instant purchase must be made with customer control, that btc must be sent to a customers address and then be quickly relayed to a merchant or another party in a transaction to create a seamless experience. All of this must happen within 0 confs because our customers will not wait for a whole confirm and we do not wish to lose the opportunity to make Bitcoin more available and useful to a broader audience with higher performance demands. Zero confirmations, when done properly, help increase adoption of Bitcoin and make it more competitive against other forms of payments. However, we do think it's good to prevent abuse of the system with reasonable constraints for the current ecosystem of applications and wallets. Cheers, Taariq Lewis & Serica/DigitalTangible team. > > ------------------------------ > > Message: 2 > Date: Mon, 21 Sep 2015 11:02:20 -0400 > From: Alex Morcos > To: Danny Thorpe > Cc: Bitcoin Dev > Subject: Re: [bitcoin-dev] Proposed new policy for transactions that > depend on other unconfirmed transactions > Message-ID: > eW-g9F5YZ9EdqXGzpzvs2mQJ8N5wKG15Ofz4cWGaHQ0BQ@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thanks for everyone's review. These policy changes have been merged in to > master in 6654 , which just > implements these limits and no mempool limiting yet. The default ancestor > package size limit is 900kb not 1MB. > > Yes I think these limits are generous, but they were designed to be as > generous as was computationally feasible so they were unobjectionable > (since the existing policy was no limits). This does not preclude future > changes to policy that would reduce these limits. > > > -- *Taariq Lewis* p: +1-646-479-6098 e: taariq.lewis@gmail.com --001a113edfa6ca044e052191b8a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Our comment was posted to Github:

We, at Serica and DigitalTangible actively use unspent tx chains to a= llow our customers to speed their bitcoin user-experience without the need = for them to wait on blockchain confirmations. These transactions are usuall= y sequential and must happen between our customers and our marketplace of m= erchants and other customers. For example, a user agrees to place an order = to purchase bitcoin and then make a bitcoin payment, for a product or servi= ces, with that bitcoin, should their desired price be met while they are un= able to actively monitor their transaction.

We cur= rently do not have a need to chain more than 5 unspents given our current u= se cases for onboarding new customers into the bitcoin ecosystem. Given thi= s PR, we agree with its principle, since the proposal aims to limit to MAX_= ANCESTORS =3D 25 and MAX_DESCENDANTS =3D 25, which we think is reasonable. = We have not **yet** seen a use case for more than 25 chains of unconfirmed = in our ecosystem.

However, we would like to publis= h our viewpoint that we wish to avoid a slippery slope of restrictions in u= nspents to fall from from 25 to 2 or even 0. The limits imposed should not = prevent, at minimum, 5 step chains of transactions that are needed to give = a customer temporary control over funds that they would otherwise not have = access to unless they waited for a confirmation before conducting another t= ransaction. In these situations, where an instant purchase must be made wit= h customer control, that btc must be sent to a customers address and then b= e quickly relayed to a merchant or another party in a transaction to create= a seamless experience. All of this must happen within 0 confs because our = customers will not wait for a whole confirm and we do not wish to lose the = opportunity to make Bitcoin more available and useful to a broader audience= with higher performance demands.=C2=A0

Zero confi= rmations, when done properly, help increase adoption of Bitcoin and make it= more competitive against other forms of payments. However, we do think it&= #39;s good to prevent abuse of the system with reasonable constraints for t= he current ecosystem of applications and wallets.=C2=A0
Cheers,
Taariq Lewis & Serica/DigitalTangible tea= m.

=C2=A0

------------------------------

Message: 2
Date: Mon, 21 Sep 2015 11:02:20 -0400
From: Alex Morcos <morcos@gmail.com<= /a>>
To: Danny Thorpe <danny.thorpe= @gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposed new policy for transactions that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 depend on other unconfirmed transactions
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAPWm=3DeW-g9F5YZ9EdqXGzpzvs2mQJ8N5wKG= 15Ofz4cWGaHQ0BQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Thanks for everyone's review.=C2=A0 These policy changes have been merg= ed in to
master in 6654 <https://github.com/bitcoin/bitcoin/pu= ll/6654>, which just
implements these limits and no mempool limiting yet.=C2=A0 The default ance= stor
package size limit is 900kb not 1MB.

Yes I think these limits are generous, but they were designed to be as
generous as was computationally feasible so they were unobjectionable
(since the existing policy was no limits).=C2=A0 This does not preclude fut= ure
changes to policy that would reduce these limits.





--
*Taariq Lewis*
p: +1-646-479-6098
e: taariq.lewis@gmail.com=
--001a113edfa6ca044e052191b8a8--