REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.

REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
2015-07-02  4:52 ` Mark Friedenbach
  
From: Dan Bryant @ 2015-07-02  4:44 UTC (permalink / raw)
  To: bitcoin-dev

This is a process BIP request to add functionality to the Bitcoin-Core
reference implementation.  If accepted, this could also add
flexibility into any future fee schedules.

https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki

Note, left the formatting in, since mediawiki is a fairly light markup.
==================================
<pre>
  BIP: nn
  Title: Sweep unconfirmed transactions by including their outputs in
high fee transactions
  Author: Dan Bryant <dkbryant@gmail•com>
  Status: Draft
  Type: Process
  Created: 2015-07-01
</pre>

==Abstract==

This BIP describes an enhancement to the reference client that
addresses the need incentive inclusion of unconfirmed transactions.
This method will create new high fee (or bounty) transactions that
spend the desired unconfirmed transactions.  To claim the high fee
(bounty) transactions, miners will need to include the desired
unconfirmed transactions.

==Motivation==

There are times when an individual receives a payment from someone
that is in a poorly crafted transaction.  This transaction may include
no fees, or insufficient fees to be included by many miners.  The
recipient would be willing to pay a nominal transaction fee to have
the payment transaction swept into the next block, but has no simple
way to craft this incentive.

This BIP could be highly desirable for merchants who may have little
control over the type of wallets their customers use.  A merchant will
want to ensure that all POS transactions to their hot wallet be given
a high probability of inclusion in the next block.  This BIP would
allow the merchant to sweep all their POS transactions currently in
the mempool into one high fee sweep, thus greatly increasing the
chance that they are in the next block.

Although many wallets have the ability to tailor the transaction fees
of payments that are sent, this BIP is unique in the sense that it
allows people to offer a bounty for transactions that are incoming.

==Specification==

This BIP would have two implementations; an automatic sweep of
incoming unconfirmed transaction setting, and a manual sweep of
unconfirmed transaction setting.  Both would have the ability to set
the fee amount the user would like to pay for the sweep.

====Automatic sweep of incoming unconfirmed transactions====

An automatic sweep configuration may be ideal for merchants who want
to ensure that their incoming transactions are not skipped over by
miners.  An automatic sweep setting would consist of four fields,
<tt>'''sweep_fee'''</tt>, <tt>'''skipped_count'''</tt>, and
<tt>'''btc_threshold'''</tt>

Currently, the standard transaction fee is 0.0001 BTC, a generous
sweep bounty would be 0.001 BTC.  Skipped-count will control the age
of unconfirmed transactions to include in the sweep.  If skipped-count
is set to three, then any incoming transaction that remains
unconfirmed for 3 blocks would trigger a sweep.  A skipped-count of 0
would trigger a sweep whenever any transaction is skipped, or if it
reaches an age of 10 minutes, regardless of how long the current block
is taking.

As a safeguard to paying a bounty for small "dust" transactions, a
minimum btc-threshold would be required for any automatic
configuration.  A good starting threshold would be 0.10 BTC.  These
automatic settings would allow a wallet implementing this BIP to
automatically perform a sweep of unconfirmed transactions whenever
more than 0.10 BTC of incoming transactions were detected in the
mempool.  Furthermore, no more than one automatic sweep would be
performed in any 10 minute window.

Whenever a sweep is triggered, all incoming unconfirmed transactions
should be swept, not simply the ones that triggered the sweep.  These
would include new transactions as well as dust transactions.  Each
sweep transaction would go to a new wallet address since recycling
wallet addresses is poor practice.

====Manual sweep of incoming unconfirmed transactions====

A manual sweep of incoming unconfirmed transactions would be a special
type of "Send" in the current reference implementation.  A manual
sweep would auto-fill a send transaction with all currently
unconfirmed incoming transactions in the mempool.  The fee field would
be completely settable by the user and would auto-fill with the
suggestions of 0.001 BTC

A manual sweep would also be available as a context option when
selecting any unconfirmed transaction.

==Compatibility==

Wallet software that does not support this BIP will continue to
operate without modification.

==Examples==

<pre>
 //unconf_tx = ef7c0cbf6ba5af68d2ea239bba709b26ff7b0b669839a63bb01c2cb8e8de481e
 //hifee_tx  = f5a5ce5988cc72b9b90e8d1d6c910cda53c88d2175177357cc2f2cf0899fbaad
 //rcpt_addr = moQR7i8XM4rSGoNwEsw3h4YEuduuP6mxw7 # recipient controlled addr.
 //chng_addr = mvbnrCX3bg1cDRUu8pkecrvP6vQkSLDSou # recipient controlled addr.

 // UNCONF_TX - Assume a zero fee TX that miners are refusing in mempool
 {
     "txid" : "$unconf_tx",
     //...
     "vin" : [
     //...
     ],
     "vout" : [
         {
             "value" : 1.50000000,
             "n" : 0,
             "scriptPubKey" : {
                 //...
                 "addresses" : [
                     "$rcpt_addr"
                 ]
             }
         }
     ]
 }

 // HIFEE_TX - Requires UNCONF_TX to be included in order to claim the
 //  high (0.001 BTC) fee.  Note this transaction is going from one
 //  address to another in the same wallet.  Both are controlled by the
 //  recipient.
 {
     "txid" : "$hifee_tx",
     //...
     "vin" : [
         {
             "txid" : "$unconf_tx",
             "vout" : 0
             //...
         }
     ],
     "vout" : [
         {
             "value" : 1.49900000,
             "n" : 0,
             "scriptPubKey" : {
                 //...
                 "addresses" : [
                     "$chng_addr"
                 ]
             }
         }
     ]
 }
</pre>


 permalink raw reply	[|nested]
2015-07-02  4:44 [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty Dan Bryant

  2015-07-02  4:57   ` Matt Whitlock
  2015-07-03 21:56   ` Peter Todd
  
From: Mark Friedenbach @ 2015-07-02  4:52 UTC (permalink / raw)
  To: DKBryant;  bitcoin-dev

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

This is called child pays for parent and there is a three year old pull
request implementing it:

https://github.com/bitcoin/bitcoin/pull/1647

The points regarding sweep transaction UI is out of scope for a BIP I'm
afraid. I suggest talking with wallet authors, and if agreement can be
found writing a pull request.
On Jul 1, 2015 9:44 PM, "Dan Bryant" <dkbryant@gmail•com> wrote:

> This is a process BIP request to add functionality to the Bitcoin-Core
> reference implementation.  If accepted, this could also add
> flexibility into any future fee schedules.
>
> https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki
>
> Note, left the formatting in, since mediawiki is a fairly light markup.
> ==================================
> <pre>
>   BIP: nn
>   Title: Sweep unconfirmed transactions by including their outputs in
> high fee transactions
>   Author: Dan Bryant <dkbryant@gmail•com>
>   Status: Draft
>   Type: Process
>   Created: 2015-07-01
> </pre>
>
> ==Abstract==
>
> This BIP describes an enhancement to the reference client that
> addresses the need incentive inclusion of unconfirmed transactions.
> This method will create new high fee (or bounty) transactions that
> spend the desired unconfirmed transactions.  To claim the high fee
> (bounty) transactions, miners will need to include the desired
> unconfirmed transactions.
>
> ==Motivation==
>
> There are times when an individual receives a payment from someone
> that is in a poorly crafted transaction.  This transaction may include
> no fees, or insufficient fees to be included by many miners.  The
> recipient would be willing to pay a nominal transaction fee to have
> the payment transaction swept into the next block, but has no simple
> way to craft this incentive.
>
> This BIP could be highly desirable for merchants who may have little
> control over the type of wallets their customers use.  A merchant will
> want to ensure that all POS transactions to their hot wallet be given
> a high probability of inclusion in the next block.  This BIP would
> allow the merchant to sweep all their POS transactions currently in
> the mempool into one high fee sweep, thus greatly increasing the
> chance that they are in the next block.
>
> Although many wallets have the ability to tailor the transaction fees
> of payments that are sent, this BIP is unique in the sense that it
> allows people to offer a bounty for transactions that are incoming.
>
> ==Specification==
>
> This BIP would have two implementations; an automatic sweep of
> incoming unconfirmed transaction setting, and a manual sweep of
> unconfirmed transaction setting.  Both would have the ability to set
> the fee amount the user would like to pay for the sweep.
>
> ====Automatic sweep of incoming unconfirmed transactions====
>
> An automatic sweep configuration may be ideal for merchants who want
> to ensure that their incoming transactions are not skipped over by
> miners.  An automatic sweep setting would consist of four fields,
> <tt>'''sweep_fee'''</tt>, <tt>'''skipped_count'''</tt>, and
> <tt>'''btc_threshold'''</tt>
>
> Currently, the standard transaction fee is 0.0001 BTC, a generous
> sweep bounty would be 0.001 BTC.  Skipped-count will control the age
> of unconfirmed transactions to include in the sweep.  If skipped-count
> is set to three, then any incoming transaction that remains
> unconfirmed for 3 blocks would trigger a sweep.  A skipped-count of 0
> would trigger a sweep whenever any transaction is skipped, or if it
> reaches an age of 10 minutes, regardless of how long the current block
> is taking.
>
> As a safeguard to paying a bounty for small "dust" transactions, a
> minimum btc-threshold would be required for any automatic
> configuration.  A good starting threshold would be 0.10 BTC.  These
> automatic settings would allow a wallet implementing this BIP to
> automatically perform a sweep of unconfirmed transactions whenever
> more than 0.10 BTC of incoming transactions were detected in the
> mempool.  Furthermore, no more than one automatic sweep would be
> performed in any 10 minute window.
>
> Whenever a sweep is triggered, all incoming unconfirmed transactions
> should be swept, not simply the ones that triggered the sweep.  These
> would include new transactions as well as dust transactions.  Each
> sweep transaction would go to a new wallet address since recycling
> wallet addresses is poor practice.
>
> ====Manual sweep of incoming unconfirmed transactions====
>
> A manual sweep of incoming unconfirmed transactions would be a special
> type of "Send" in the current reference implementation.  A manual
> sweep would auto-fill a send transaction with all currently
> unconfirmed incoming transactions in the mempool.  The fee field would
> be completely settable by the user and would auto-fill with the
> suggestions of 0.001 BTC
>
> A manual sweep would also be available as a context option when
> selecting any unconfirmed transaction.
>
> ==Compatibility==
>
> Wallet software that does not support this BIP will continue to
> operate without modification.
>
> ==Examples==
>
> <pre>
>  //unconf_tx =
> ef7c0cbf6ba5af68d2ea239bba709b26ff7b0b669839a63bb01c2cb8e8de481e
>  //hifee_tx  =
> f5a5ce5988cc72b9b90e8d1d6c910cda53c88d2175177357cc2f2cf0899fbaad
>  //rcpt_addr = moQR7i8XM4rSGoNwEsw3h4YEuduuP6mxw7 # recipient controlled
> addr.
>  //chng_addr = mvbnrCX3bg1cDRUu8pkecrvP6vQkSLDSou # recipient controlled
> addr.
>
>  // UNCONF_TX - Assume a zero fee TX that miners are refusing in mempool
>  {
>      "txid" : "$unconf_tx",
>      //...
>      "vin" : [
>      //...
>      ],
>      "vout" : [
>          {
>              "value" : 1.50000000,
>              "n" : 0,
>              "scriptPubKey" : {
>                  //...
>                  "addresses" : [
>                      "$rcpt_addr"
>                  ]
>              }
>          }
>      ]
>  }
>
>  // HIFEE_TX - Requires UNCONF_TX to be included in order to claim the
>  //  high (0.001 BTC) fee.  Note this transaction is going from one
>  //  address to another in the same wallet.  Both are controlled by the
>  //  recipient.
>  {
>      "txid" : "$hifee_tx",
>      //...
>      "vin" : [
>          {
>              "txid" : "$unconf_tx",
>              "vout" : 0
>              //...
>          }
>      ],
>      "vout" : [
>          {
>              "value" : 1.49900000,
>              "n" : 0,
>              "scriptPubKey" : {
>                  //...
>                  "addresses" : [
>                      "$chng_addr"
>                  ]
>              }
>          }
>      ]
>  }
> </pre>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

 permalink raw reply	[|nested]
2015-07-02  4:52 ` Mark Friedenbach

  2015-07-02 13:13     ` Tier Nolan
  2015-07-03 21:56   ` Peter Todd
  
From: Matt Whitlock @ 2015-07-02  4:57 UTC (permalink / raw)
  To: Mark Friedenbach;  bitcoin-dev

PR#1647 only addresses miner policy, though, right? I believe the BIP is addressing the user-facing side of this functionality. CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions.


On Wednesday, 1 July 2015, at 9:52 pm, Mark Friedenbach wrote:
> This is called child pays for parent and there is a three year old pull
> request implementing it:
> 
> https://github.com/bitcoin/bitcoin/pull/1647
> 
> The points regarding sweep transaction UI is out of scope for a BIP I'm
> afraid. I suggest talking with wallet authors, and if agreement can be
> found writing a pull request.
> On Jul 1, 2015 9:44 PM, "Dan Bryant" <dkbryant@gmail•com> wrote:
> 
> > This is a process BIP request to add functionality to the Bitcoin-Core
> > reference implementation.  If accepted, this could also add
> > flexibility into any future fee schedules.
> >
> > https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki


 permalink raw reply	[|nested]
2015-07-02  4:57   ` Matt Whitlock

  
From: Tier Nolan @ 2015-07-02 13:13 UTC (permalink / raw)
  Cc: bitcoin-dev

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

I wonder if that would be a viable way for payment services to pay to
protect against double spending.

If the payment processor was handling 1000 BTC every block and was willing
to pay 0.1% fees, then it could create a transaction with 1BTC in fees.

If an attacker tried to double spend a transaction of 0.1BTC, then even if
he was to spend the entire transaction to fees, the payment processor would
be able to out bid him.

It kind of works like insurance.  The payment processor combines lots of
small double spend threats and protects them with a single transaction.

The processor could keep sending out a larger and large transaction (with
fee) until eventually a block is found.

It requires RBF.  First seen safe would be incompatible, if the double
spender gets their transaction into the system first.

A 1BTC fee transaction in nearly every block would also be a boost for
network security.

It avoids Peter Todd's complaint that mining pools might make secret deals
with payment services.  The transaction would be public and all miners
could include it in their block.

On Thu, Jul 2, 2015 at 5:57 AM, Matt Whitlock <bip@mattwhitlock•name> wrote:

> PR#1647 only addresses miner policy, though, right? I believe the BIP is
> addressing the user-facing side of this functionality. CPFP mining policy
> does very little good if wallets don't offer any way for users to goose up
> incoming transactions.
>
>
> On Wednesday, 1 July 2015, at 9:52 pm, Mark Friedenbach wrote:
> > This is called child pays for parent and there is a three year old pull
> > request implementing it:
> >
> > https://github.com/bitcoin/bitcoin/pull/1647
> >
> > The points regarding sweep transaction UI is out of scope for a BIP I'm
> > afraid. I suggest talking with wallet authors, and if agreement can be
> > found writing a pull request.
> > On Jul 1, 2015 9:44 PM, "Dan Bryant" <dkbryant@gmail•com> wrote:
> >
> > > This is a process BIP request to add functionality to the Bitcoin-Core
> > > reference implementation.  If accepted, this could also add
> > > flexibility into any future fee schedules.
> > >
> > > https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

 permalink raw reply	[|nested]
2015-07-02  4:52 ` Mark Friedenbach
  2015-07-02  4:57   ` Matt Whitlock

  2015-07-06  4:14     ` Dan Bryant
  
From: Peter Todd @ 2015-07-03 21:56 UTC (permalink / raw)
  To: Mark Friedenbach;  bitcoin-dev

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

On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> This is called child pays for parent and there is a three year old pull
> request implementing it:
> 
> https://github.com/bitcoin/bitcoin/pull/1647

CPFP probably needs changes to the P2P layer to be able to support RBF
scorched earth well unfortunately, as currently transactions are
processed individually and out of context. In the RBF case you'd need to
keep previously removed transactions in a buffer and evaluate new
transactions against that buffer - relatively complex.

The other big issue is that existing wallets don't appear to be very
good at preventing double-spends. There's lots of edge cases where
transations aren't recorded correctly, like crashes, shutting down
unexpected etc. and in those cases there's a high chance of the wallet
sending a double-spend by accident. There's also coinjoin to consider -
plainly incompatible. With scorched-earth this will lead to losses.

Fortunately you can implement scorched-earth using SIGHASH_ANYONECANPAY
instead on an opt-in basis, which wallets could add only if they've
taken the special engineering considerations into account first:

    "Replace-by-fee scorched-earth without child-pays-for-parent",
    Peter Todd, Bitcoin-development mailing list, Apr 28th 2014
    http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html

For the OP: I'd be interested in pursuing this further.

-- 
'peter'[:-1]@petertodd.org
000000000000000015665ce75a321e5827cdf9af667eaa75aaeefbc315514da5

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

 permalink raw reply	[|nested]
2015-07-03 21:56   ` Peter Todd

  2015-07-06  4:20       ` Micha Bailey
                         ` (2 more replies)
  
From: Dan Bryant @ 2015-07-06  4:14 UTC (permalink / raw)
  To: bitcoin-dev

On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> This is called child pays for parent and there is a three year old pull
> request implementing it:
>
> https://github.com/bitcoin/bitcoin/pull/1647

Understood... When I wrote the BIP proposal I was assuming
(incorrectly) that CPFP TX selection was already being done by miners,
but I see now that certain trees could bloom the TX selection latency
as miners would need to be more dependency aware.  Perhaps the BIP66
orphan block chain shows that some miners may not always be counted on
to ensure that all TX stuffed in a block have dependencies met.
Certainly not until the PR1647 is fully merged and deployed.

On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
> PR#1647 only addresses miner policy, though, right? I believe the BIP is
> addressing the user-facing side of this functionality. CPFP mining policy
> does very little good if wallets don't offer any way for users to goose up
> incoming transactions.

On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> The points regarding sweep transaction UI is out of scope for a BIP I'm
> afraid. I suggest talking with wallet authors, and if agreement can be
> found writing a pull request.

Yes... although I certainly admit, I didn't know about CPFP or I would
have called it out as a requirement for this UI enhancement request.
I'll see if I can't get some wallet authors interested in this as a
feature enhancement when PR1647 commits.

Perhaps there are risks raised if CPFP is not enabled but these sweep
tx enter the mempool.  If miners take the high fee "children" but
ignore the low fee "parents" then the child might enter the blockchain
without the parent.  If miners were light on block validation,
wouldn't it be possible that the child may go forward with many
confirmations, while the parent patiently waits in the mempool?  This
could be bad since spending the child may look good, as it might have
many confirmations, while its parent has few.

On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd <pete@petertodd•org> wrote:
> "Replace-by-fee scorched-earth without child-pays-for-parent",
> Peter Todd, Bitcoin-development mailing list, Apr 28th 2014
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html

Very good!  So if I follow, RPF can work one of two ways:

In the "countermeasure" form, spender gives receiver a partially
signed "countermeasure" transactions with juiced up fees.

In the "anyonecanpay" form, spender signs the transaction with
ANYONECANPAY bit allowing the reviver to add fees at will.

One question I did have about RBF is this.. Is it correct to presume
that the spender doesn't send the incomplete "countermeasure"
transaction to the network?  If they did, wouldn't they get flagged on
DoS code banning them from peers?

Corollary question.  If the "countermeasure" transaction is not
broadcast, is it sent to the receiver via back channel (email, etc)

I'll try to clean up the draft BIP to include CPFP dependencies and
RBF capabilities.  Whether it belongs in a BIP or a PR, its just a doc
to outline my thoughts at this point.  Not burning a whole in my head,
so may take some time.

Thx.


 permalink raw reply	[|nested]
2015-07-03 21:56   ` Peter Todd

  2015-07-06  4:20       ` 
                         ` 
  
From: Dan Bryant @ 2015-07-06  4:14 UTC (permalink / raw)
  To: bitcoin-dev

On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> This is called child pays for parent and there is a three year old pull
> request implementing it:
>
> https://github.com/bitcoin/bitcoin/pull/1647

Understood... When I wrote the BIP proposal I was assuming
(incorrectly) that CPFP TX selection was already being done by miners,
but I see now that certain trees could bloom the TX selection latency
as miners would need to be more dependency aware.  Perhaps the BIP66
orphan block chain shows that some miners may not always be counted on
to ensure that all TX stuffed in a block have dependencies met.
Certainly not until the PR1647 is fully merged and deployed.

On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
> PR#1647 only addresses miner policy, though, right? I believe the BIP is
> addressing the user-facing side of this functionality. CPFP mining policy
> does very little good if wallets don't offer any way for users to goose up
> incoming transactions.

On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> The points regarding sweep transaction UI is out of scope for a BIP I'm
> afraid. I suggest talking with wallet authors, and if agreement can be
> found writing a pull request.

Yes... although I certainly admit, I didn't know about CPFP or I would
have called it out as a requirement for this UI enhancement request.
I'll see if I can't get some wallet authors interested in this as a
feature enhancement when PR1647 commits.

Perhaps there are risks raised if CPFP is not enabled but these sweep
tx enter the mempool.  If miners take the high fee "children" but
ignore the low fee "parents" then the child might enter the blockchain
without the parent.  If miners were light on block validation,
wouldn't it be possible that the child may go forward with many
confirmations, while the parent patiently waits in the mempool?  This
could be bad since spending the child may look good, as it might have
many confirmations, while its parent has few.

On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd <pete@petertodd•org> wrote:
> "Replace-by-fee scorched-earth without child-pays-for-parent",
> Peter Todd, Bitcoin-development mailing list, Apr 28th 2014
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html

Very good!  So if I follow, RPF can work one of two ways:

In the "countermeasure" form, spender gives receiver a partially
signed "countermeasure" transactions with juiced up fees.

In the "anyonecanpay" form, spender signs the transaction with
ANYONECANPAY bit allowing the reviver to add fees at will.

One question I did have about RBF is this.. Is it correct to presume
that the spender doesn't send the incomplete "countermeasure"
transaction to the network?  If they did, wouldn't they get flagged on
DoS code banning them from peers?

Corollary question.  If the "countermeasure" transaction is not
broadcast, is it sent to the receiver via back channel (email, etc)

I'll try to clean up the draft BIP to include CPFP dependencies and
RBF capabilities.  Whether it belongs in a BIP or a PR, its just a doc
to outline my thoughts at this point.  Not burning a whole in my head,
so may take some time.

Thx.


 permalink raw reply	[|nested]
2015-07-06  4:14     ` Dan Bryant
  2015-07-06  4:20       ` Micha Bailey

  2015-07-09  6:17         ` Aaron Voisine
  2015-07-15  8:26       ` Dan Bryant
  
From: Luke Dashjr @ 2015-07-06  4:24 UTC (permalink / raw)
  To: bitcoin-dev, DKBryant

On Monday, July 06, 2015 4:14:14 AM Dan Bryant wrote:
> When I wrote the BIP proposal I was assuming (incorrectly) that CPFP TX
> selection was already being done by miners,

No, this is correct. It's just not included in the reference policy.
Miners are not expected to use the reference policy as-is, and some of them do 
in fact use CPFP.

Luke


 permalink raw reply	[|nested]
2015-07-06  4:24       ` Luke Dashjr

  2015-07-09  6:22           ` Luke Dashjr
  
From: Aaron Voisine @ 2015-07-09  6:17 UTC (permalink / raw)
  To: Luke Dashjr;  bitcoin-dev

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

Do you have any idea how much hashing power is using CPFP? It's a useful
metric for wallet developers to know what sort of confirmation times they
might be able to get when attempting to use it.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Sun, Jul 5, 2015 at 9:24 PM, Luke Dashjr <luke@dashjr•org> wrote:

> On Monday, July 06, 2015 4:14:14 AM Dan Bryant wrote:
> > When I wrote the BIP proposal I was assuming (incorrectly) that CPFP TX
> > selection was already being done by miners,
>
> No, this is correct. It's just not included in the reference policy.
> Miners are not expected to use the reference policy as-is, and some of
> them do
> in fact use CPFP.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

 permalink raw reply	[|nested]
2015-07-09  6:17         ` Aaron Voisine

  2015-07-09  7:19             ` Dan Bryant
  
From: Luke Dashjr @ 2015-07-09  6:22 UTC (permalink / raw)
  To: Aaron Voisine;  bitcoin-dev

On Thursday, July 09, 2015 6:17:03 AM Aaron Voisine wrote:
> Do you have any idea how much hashing power is using CPFP? It's a useful
> metric for wallet developers to know what sort of confirmation times they
> might be able to get when attempting to use it.

Not sure. At least 4% (Eligius)?


 permalink raw reply	[|nested]
2015-07-09  6:22           ` Luke Dashjr

  
From: Dan Bryant @ 2015-07-09  7:19 UTC (permalink / raw)
  To: bitcoin-dev

FYI, looks like someone was trying to boost up a transaction tonight
and managed to get it pushed through.

parent: 4cc3e2b6407ae8cdc1fd62cb3235f9c92654277684da8970db19a0169e44c68c
child: 161b302d1af8b6eacf1140726b26c67fa72ecf4f7f7e6cd8d83ef492b8b490ea
gchld: 4f6821b50c046ae40d488aa18d88d41c9d0686daedf835b68b8c5086b73939fd
ggch: 0c159d19f6452f12512a4ec16868a3af00fe381a0913f4fc69b3fc14c4588aa9
gggch: 4e4f96c5ba416961be347ffc496e8ce12046191ab7fb252e88966ce365d2bc5f

though it's position in the block doesn't seem to be a priority / fee cut line.


 permalink raw reply	[|nested]
2015-07-06  4:14     ` Dan Bryant
  2015-07-06  4:20       ` Micha Bailey
  2015-07-06  4:24       ` Luke Dashjr

  2015-08-26 15:28         ` Aaron Voisine
  
From: Dan Bryant @ 2015-07-15  8:26 UTC (permalink / raw)
  To: bitcoin-dev

Offering a bounty for this feature

Specifically...

Anyone who can put a CPFP transaction creation feature into any wallet
featured on the bitcoin homepage (ref1) can claim this bounty.  The
funds are being raised by donation.  The funds will be dispersed from
the following address when the bounty is claimed:
3FEUByMeaxrNmBCVYjvsnhyAjiUdat5i7M

Currently there isn't much in there, but I welcome angels to fill the bucket.

Here's proof that the multisig address is not 1 of 1:
https://bitcointalk.org/index.php?topic=1122956.0

Bounty announce: https://bitcointalk.org/index.php?topic=1123464.0

ref1: https://bitcoin.org/en/choose-your-wallet


 permalink raw reply	[|nested]
2015-07-15  8:26       ` Dan Bryant

  
From: Aaron Voisine @ 2015-08-26 15:28 UTC ( / )
  To: Dan Bryant;  bitcoin-dev



Breadwallet also implements CPFP when spending unconfirmed non-change
inputs. It was released back in May, but happy to let Andreas have the
bounty:

https://github.com/voisine/breadwallet/blob/v0.5.1/BreadWallet/BRWallet.m#L382


Aaron Voisine
co-founder and CEO
breadwallet.com

On Wed, Jul 15, 2015 at 9:26 AM, Dan Bryant via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Offering a bounty for this feature
>
> Specifically...
>
> Anyone who can put a CPFP transaction creation feature into any wallet
> featured on the bitcoin homepage (ref1) can claim this bounty.  The
> funds are being raised by donation.  The funds will be dispersed from
> the following address when the bounty is claimed:
> 3FEUByMeaxrNmBCVYjvsnhyAjiUdat5i7M
>
> Currently there isn't much in there, but I welcome angels to fill the
> bucket.
>
> Here's proof that the multisig address is not 1 of 1:
> https://bitcointalk.org/index.php?topic=1122956.0
>
> Bounty announce: https://bitcointalk.org/index.php?topic=1123464.0
>
> ref1: https://bitcoin.org/en/choose-your-wallet
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>