* [Bitcoin-development] Changing the fee on already sent transactions
@ 2013-03-12 9:47 Peter Todd
2013-03-12 13:06 ` Gregory Maxwell
2013-03-12 13:10 ` Luke-Jr
0 siblings, 2 replies; 3+ messages in thread
From: Peter Todd @ 2013-03-12 9:47 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]
We can allow for transaction replacement for the purpose of adding fees
to existing transactions safely, and while not increasing the risk of
double-spends by taking advantage of the stubbed out replacement code.
Specifically the replacement code allows for the replacement of a
transaction if a transaction spending the tx that is being replaced is
not in the mempool. Specifically:
664 // Check for conflicts with in-memory transactions
665 CTransaction* ptxOld = NULL;
666 for (unsigned int i = 0; i < tx.vin.size(); i++)
667 {
668 COutPoint outpoint = tx.vin[i].prevout;
669 if (mapNextTx.count(outpoint)){
Followed by the actual replacement logic. We could change this logic to
instead evaluate if the candidate replacement does not remove or
decrease the value of any existing outputs. Adding outputs is ok.
Changing the set of inputs is also ok, provided that there are no
conflicts with other spent transactions. DoS attacks would be prevented
by only forwarding/accepting into the mempool replacements that increase
the fees paid by at least MIN_RELAY_TX_FEE * size - essentially the same
decision to allow the broadcast of the transaction in the first place.
Because a transaction can not be replaced if another transaction already
depends on it the change would not increse double-spend risks for
unconfirmed transactions.
Along with this change code can be added to clients to examine the
mempool and recent blocks to determine what fee would be required to get
a transaction confirmed in what time.
Of course, considering our recent "fun" last night, I'll be the first to
admit that this change needs a lot of testing and careful thought.
However the ability to increase fees on already broadcast transactions
would be very valuable to users as competition for blockchain space
increases.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Changing the fee on already sent transactions
2013-03-12 9:47 [Bitcoin-development] Changing the fee on already sent transactions Peter Todd
@ 2013-03-12 13:06 ` Gregory Maxwell
2013-03-12 13:10 ` Luke-Jr
1 sibling, 0 replies; 3+ messages in thread
From: Gregory Maxwell @ 2013-03-12 13:06 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
On Tue, Mar 12, 2013 at 2:47 AM, Peter Todd <pete@petertodd•org> wrote:
> Followed by the actual replacement logic. We could change this logic to
> instead evaluate if the candidate replacement does not remove or
> decrease the value of any existing outputs. Adding outputs is ok.
> Changing the set of inputs is also ok, provided that there are no
> conflicts with other spent transactions. DoS attacks would be prevented
> by only forwarding/accepting into the mempool replacements that increase
> the fees paid by at least MIN_RELAY_TX_FEE * size - essentially the same
> decision to allow the broadcast of the transaction in the first place.
I _strongly_ prefer this method of addressing this concern. I think
you've hit the required requirements: pay at least all the same
inputs, increase fee by at least the min_relay_tx_fee*size.
The discussion we had on IRC where some were proposing fast expiration
would practically lower the security of Bitcoin.
While there is complexity and testing required here, getting full
branch coverage of this code would be fairly straight forward. Doing
this correctly will be easier than child-pays-for-parent and although
it does not replace child-pays-for-parent (the two techniques are
complimentary in my view) it would reduce the urgency of getting
child-pays-for-parent included.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Changing the fee on already sent transactions
2013-03-12 9:47 [Bitcoin-development] Changing the fee on already sent transactions Peter Todd
2013-03-12 13:06 ` Gregory Maxwell
@ 2013-03-12 13:10 ` Luke-Jr
1 sibling, 0 replies; 3+ messages in thread
From: Luke-Jr @ 2013-03-12 13:10 UTC (permalink / raw)
To: bitcoin-development
On Tuesday, March 12, 2013 9:47:00 AM Peter Todd wrote:
> We can allow for transaction replacement for the purpose of adding fees
> to existing transactions safely, and while not increasing the risk of
> double-spends by taking advantage of the stubbed out replacement code.
Side note: Adding fees is already possible by respending change, at least for
miners running an Eligius branch (both 0.6.0 and 0.8.0).
Luke
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-03-12 13:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-12 9:47 [Bitcoin-development] Changing the fee on already sent transactions Peter Todd
2013-03-12 13:06 ` Gregory Maxwell
2013-03-12 13:10 ` Luke-Jr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox