public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions
@ 2015-08-14 19:33 Alex Morcos
  2015-08-21 19:22 ` Matt Corallo
  0 siblings, 1 reply; 9+ messages in thread
From: Alex Morcos @ 2015-08-14 19:33 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]

Hi everyone,


I'd like to propose a new set of requirements as a policy on when to accept
new transactions into the mempool and relay them.  This policy would affect
transactions which have as inputs other transactions which are not yet
confirmed in the blockchain.

The motivation for this policy is 6470
<https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit the size
of a mempool.  As discussed in that pull
<https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736>, once
the mempool is full a new transaction must be able to pay not only for the
transaction it would evict, but any dependent transactions that would be
removed from the mempool as well.  In order to make sure this is always
feasible, I'm proposing 4 new policy limits.

All limits are command line configurable.

The first two limits are required to make sure no chain of transactions
will be too large for the eviction code to handle:

Max number of descendant txs : No transaction shall be accepted if it would
cause another transaction in the mempool to have too many descendant
transactions (all of which would have to be evicted if the ancestor
transaction was evicted).  Default: 1000

Max descendant size : No transaction shall be accepted if it would cause
another transaction in the mempool to have the total size of all its
descendant transactions be too great.  Default : maxmempool / 200  =  2.5MB

The third limit is required to make sure calculating the state required for
sorting and limiting the mempool and enforcing the first 2 limits is
computationally feasible:

Max number of ancestor txs:  No transaction shall be accepted if it has too
many ancestor transactions which are not yet confirmed (ie, in the
mempool). Default: 100

The fourth limit is required to maintain the pre existing policy goal that
all transactions in the mempool should be mineable in the next block.

Max ancestor size: No transaction shall be accepted if the total size of
all its unconfirmed ancestor transactions is too large.  Default: 1MB

(All limits include the transaction itself.)

For reference, these limits would have affected less than 2% of
transactions entering the mempool in April or May of this year.  During the
period of 7/6 through 7/14, while the network was under stress test, as
many as 25% of the transactions would have been affected.

The code to implement the descendant package tracking and new policy limits
can be found in 6557 <https://github.com/bitcoin/bitcoin/pull/6557> which
is built off of 6470.

Thanks,
Alex

[-- Attachment #2: Type: text/html, Size: 2767 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions
@ 2015-10-08  6:10 Taariq Lewis
  0 siblings, 0 replies; 9+ messages in thread
From: Taariq Lewis @ 2015-10-08  6:10 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 3403 bytes --]

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 <morcos@gmail.com>
> 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
>         depend on other unconfirmed transactions
> Message-ID:
>         <CAPWm=
> 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 <https://github.com/bitcoin/bitcoin/pull/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

[-- Attachment #2: Type: text/html, Size: 4532 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-10-08  6:10 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-14 19:33 [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions Alex Morcos
2015-08-21 19:22 ` Matt Corallo
2015-08-21 19:52   ` Danny Thorpe
2015-09-21 15:02     ` Alex Morcos
2015-10-05 18:45       ` Alex Morcos
2015-10-05 18:51         ` Danny Thorpe
2015-10-05 20:02           ` Alex Morcos
2015-10-08  3:33             ` Matt Corallo
2015-10-08  6:10 Taariq Lewis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox