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, 20
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
FYI, looks like someone was trying to boost up a transaction tonight
and managed to get it pushed through.
parent: 4cc3e2b6407ae8cdc1fd62cb3235f9c92654277684da8970db19a0169e44c68c
child: 161b302d1af8b6eacf1140726b26c67fa72ecf4f7f7e6cd8d83ef492b8b490ea
gchld: 4f6821b50c046ae40d488aa18d88d41c9d0686d
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)?
_
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 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-
On Monday, July 6, 2015, Dan Bryant wrote:
> 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 wro
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
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 e
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 transact
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 Fried
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 writin
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 ligh
13 matches
Mail list logo
