* [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
@ 2012-04-12 18:38 Jeff Garzik
2012-04-12 19:19 ` Alan Reiner
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: Jeff Garzik @ 2012-04-12 18:38 UTC (permalink / raw)
To: Bitcoin Development
Not sure whether this rises to the level of a BIP or not, as it is
largely an implementation change.
One of my From-Day-One complaints about bitcoin is that transactions
behavior could be far more deterministic (predictable), from a user
standpoint. Transactions in the current system can easily remain in
limbo forever.
One big step in making transactions behave more predictably would be
to remove transactions from the memory pool, if they have not made it
into a block for a couple days. i.e.
1. N = 1 or 2 or whatever the community prefers. Ideally enough time
for a third-tier miner, mining strange TXs, finds a block.
2. H1 = height of block chain, when a TX is received
3. H2 = H1 + (144 * N)
4. If block chain height reaches H2, and TX has not made it into a
block, drop TX from memory pool
Although this only impacts a small amount of TX's ultimately, what it
does do is give us the ability -- once miners have upgraded to this
rule -- to tell bitcoin users that their transactions "expire" after N
days.
Backwards compatibility should not be an issue; clients are free to
retransmit their TX at any time, as usual, thereby "resetting the
clock" for all peers who have forgotten the TX in question.
Once in place, clients may then implement code that notices a TX has
expired (read: likely to have been forgotten by the network, assuming
they themselves have stopped retransmitting it). Then you can start
working on wallet/coin recovery, perhaps resending with a higher fee
etc.
The above change is not really "fill-or-kill" but it should be a big
step, opening the door to deterministic TX behavior.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-12 18:38 [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior Jeff Garzik @ 2012-04-12 19:19 ` Alan Reiner 2012-04-12 19:26 ` Jeff Garzik 2012-04-13 8:35 ` Andy Parkins ` (2 subsequent siblings) 3 siblings, 1 reply; 13+ messages in thread From: Alan Reiner @ 2012-04-12 19:19 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 2887 bytes --] My one big concern about this that users find a way to exploit this behavior for themselves. If it's too easy for users to create tx they know will get stuck and expire, it's no different than letting them cancel their zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so I send it using a combination of inputs and fees that I know will lead to it being stuck and expire. On the other hand, if such conditions are deterministic enough, it could be detected by the recipient and flagged. It's not a huge deal, but it's something to consider. -Alan On Thu, Apr 12, 2012 at 2:38 PM, Jeff Garzik <jgarzik@exmulti•com> wrote: > Not sure whether this rises to the level of a BIP or not, as it is > largely an implementation change. > > One of my From-Day-One complaints about bitcoin is that transactions > behavior could be far more deterministic (predictable), from a user > standpoint. Transactions in the current system can easily remain in > limbo forever. > > One big step in making transactions behave more predictably would be > to remove transactions from the memory pool, if they have not made it > into a block for a couple days. i.e. > > 1. N = 1 or 2 or whatever the community prefers. Ideally enough time > for a third-tier miner, mining strange TXs, finds a block. > 2. H1 = height of block chain, when a TX is received > 3. H2 = H1 + (144 * N) > 4. If block chain height reaches H2, and TX has not made it into a > block, drop TX from memory pool > > Although this only impacts a small amount of TX's ultimately, what it > does do is give us the ability -- once miners have upgraded to this > rule -- to tell bitcoin users that their transactions "expire" after N > days. > > Backwards compatibility should not be an issue; clients are free to > retransmit their TX at any time, as usual, thereby "resetting the > clock" for all peers who have forgotten the TX in question. > > Once in place, clients may then implement code that notices a TX has > expired (read: likely to have been forgotten by the network, assuming > they themselves have stopped retransmitting it). Then you can start > working on wallet/coin recovery, perhaps resending with a higher fee > etc. > > The above change is not really "fill-or-kill" but it should be a big > step, opening the door to deterministic TX behavior. > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@exmulti•com > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 3763 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-12 19:19 ` Alan Reiner @ 2012-04-12 19:26 ` Jeff Garzik 0 siblings, 0 replies; 13+ messages in thread From: Jeff Garzik @ 2012-04-12 19:26 UTC (permalink / raw) To: Alan Reiner; +Cc: Bitcoin Development On Thu, Apr 12, 2012 at 3:19 PM, Alan Reiner <etotheipi@gmail•com> wrote: > My one big concern about this that users find a way to exploit this behavior > for themselves. If it's too easy for users to create tx they know will get > stuck and expire, it's no different than letting them cancel their zero-conf > transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so I send it > using a combination of inputs and fees that I know will lead to it being > stuck and expire. > > On the other hand, if such conditions are deterministic enough, it could be > detected by the recipient and flagged. > > It's not a huge deal, but it's something to consider. Do you have a -specific- concern that you feel may be exploited? Expiration already occurs at random, as nodes shut down and restart, log on and log off the network. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-12 18:38 [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior Jeff Garzik 2012-04-12 19:19 ` Alan Reiner @ 2012-04-13 8:35 ` Andy Parkins 2012-04-13 10:04 ` Mike Hearn 2012-04-15 10:54 ` Jorge Timón 3 siblings, 0 replies; 13+ messages in thread From: Andy Parkins @ 2012-04-13 8:35 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 1243 bytes --] On 2012 April 12 Thursday, Jeff Garzik wrote: > One of my From-Day-One complaints about bitcoin is that transactions > behavior could be far more deterministic (predictable), from a user > standpoint. Transactions in the current system can easily remain in > limbo forever. > > One big step in making transactions behave more predictably would be > to remove transactions from the memory pool, if they have not made it > into a block for a couple days. i.e. A change I've wished for for a while (but I suspect it is too big a change to ever make it) is that a transaction announcement include the block the user wants to base on. It would only be in the protocol message, not the transaction stored in the blockchain. The advantage is that (1) it protects against double spends without needing a confirmation period; as a merchant I can instantly spend a 1-confirmation transaction by creating my transaction with that 1-confirm as its "base". (2) your expiry from memory pool becomes easy -- if the "base" is more than N blocks below the current head, then that transaction won't be included. Retransmission is possible with the base updated. Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-12 18:38 [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior Jeff Garzik 2012-04-12 19:19 ` Alan Reiner 2012-04-13 8:35 ` Andy Parkins @ 2012-04-13 10:04 ` Mike Hearn 2012-04-13 16:41 ` Jeff Garzik 2012-04-15 10:54 ` Jorge Timón 3 siblings, 1 reply; 13+ messages in thread From: Mike Hearn @ 2012-04-13 10:04 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Development It sounds OK as long as you exclude nLockTimed transactions. That said, if you broadcast a transaction that does not meet the fee rules, you should be able to notice that it wasn't accepted by your peers immediately. Today it's painful because the protocol isn't very chatty - in bitcoinj I plan to do this by announcing to half the connected peers and waiting to see if the transaction comes back on the other half. Getting a response from a peer that the TX was dropped for reasons {x,y,z} is a better design but needs another protocol change. So having transactions expire would address the case where somebody broadcasts a transaction that successfully propagates across the network, but then isn't actually accepted by miners for some reason. For instance due to a change in the default fee schedules. That risk can be mitigated somewhat by being careful about such changes (timed phase ins set multiple months out so people have time to upgrade, alerts announcing it, etc). I'm not sure we should be encouraging users to attach fees to transactions though. Even if you can replace a transaction after a couple of days, the user experience of trying to get the fee "right" is atrocious. I don't think any sensible merchant will actually be willing to put their customers through this nonsense. If somebody broadcasts a transaction that successfully propagates across a big chunk of the network but then gets stuck due to lacking sufficient fees, the best fix is for the merchant to broadcast another transaction that spends the first and increases the fees on it that way. After this happens a few times, if I was a merchant I'd be tempted to just ask buyers to submit the TX to me directly and I'll handle keeping up with what miners currently charge and attaching fees. I don't want my customers to have to think about this and have trades spuriously fail when they forget. That design requires a minor change to how fees are calculated inside the memory pool, to include fees on un-included dependencies. But that seems fairly uncontroversial to me. It's best for users, merchants and miners to not leave chains of transactions in limbo when together their fees add up to the minimum required amount. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-13 10:04 ` Mike Hearn @ 2012-04-13 16:41 ` Jeff Garzik 2012-04-14 15:13 ` Mike Hearn 0 siblings, 1 reply; 13+ messages in thread From: Jeff Garzik @ 2012-04-13 16:41 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Development On Fri, Apr 13, 2012 at 6:04 AM, Mike Hearn <mike@plan99•net> wrote: > It sounds OK as long as you exclude nLockTimed transactions. ACK, agreed > That said, if you broadcast a transaction that does not meet the fee > rules, you should be able to notice that it wasn't accepted by your > peers immediately. Today it's painful because the protocol isn't very > chatty - in bitcoinj I plan to do this by announcing to half the > connected peers and waiting to see if the transaction comes back on > the other half. Getting a response from a peer that the TX was dropped > for reasons {x,y,z} is a better design but needs another protocol > change. > > So having transactions expire would address the case where somebody > broadcasts a transaction that successfully propagates across the > network, but then isn't actually accepted by miners for some reason. Correct. As mentioned, this change should impact few TXs on the existing network. It's mostly about getting everyone to collectively agree that transactions should expire, if they don't make it into a block. (excl. nLockTime stuff) A minor technical step, but also a useful policy step. > For instance due to a change in the default fee schedules. That risk > can be mitigated somewhat by being careful about such changes (timed > phase ins set multiple months out so people have time to upgrade, > alerts announcing it, etc). > > I'm not sure we should be encouraging users to attach fees to > transactions though. Even if you can replace a transaction after a > couple of days, the user experience of trying to get the fee "right" > is atrocious. Yes -- I think there is near-universal agreement on this user experience point. > I don't think any sensible merchant will actually be > willing to put their customers through this nonsense. If somebody > broadcasts a transaction that successfully propagates across a big > chunk of the network but then gets stuck due to lacking sufficient > fees, the best fix is for the merchant to broadcast another > transaction that spends the first and increases the fees on it that > way. After this happens a few times, if I was a merchant I'd be > tempted to just ask buyers to submit the TX to me directly and I'll > handle keeping up with what miners currently charge and attaching > fees. I don't want my customers to have to think about this and have > trades spuriously fail when they forget. > > That design requires a minor change to how fees are calculated inside > the memory pool, to include fees on un-included dependencies. But that > seems fairly uncontroversial to me. It's best for users, merchants and > miners to not leave chains of transactions in limbo when together > their fees add up to the minimum required amount. So, to be specific... a A->B chain of transactions, that collectively meet the network's fee requirements? It seems quite reasonable to accept that, sure. ACK on concept. A chain of length 2 seems like it would be most common, and limiting total chain length (to 10? 100?) for any one chain in the memory pool seems prudent. As to the larger issue of fees... I will readily admit I have no good ideas. The user's experience is pretty poor: while it might make economic sense, from the network's standpoint, to charge for the service of verifying and storing a transaction, the user has limited means to determine an ideal fee. There are also other valid economic models (receiver pays fee) out there that may successfully sustain the network. Ideally the fee, if any, is market based and negotiated. The current method is loose-consensus, mainly aimed at (a) combating dust spam or (b) ensuring it becomes increasingly more expensive to fill a block, up to the current 1MB maximum. I think almost everyone agrees the current fee system is an ugly, warty hack. Problem is... like democracy, no matter how ugly it is, people have trouble finding a better system :) Furthermore, many of these ideas -- like sending TX's directly to the merchant -- involve far more direct payee<->payer communication on the part of the wallet client than is currently envisioned by the bitcoin P2P network design, which is broadcast-oriented. So, it remains an open question whether we want the base bitcoin layer to even worry about real-time fee negotiation and direct TX transmission. It is possible that an instant-payments layer evolves on top of the base bitcoin block chain layer, with bitcoin transactions evolving largely into settlements between instant-payment intermediaries large and small. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-13 16:41 ` Jeff Garzik @ 2012-04-14 15:13 ` Mike Hearn 2012-04-14 20:20 ` Jeff Garzik 0 siblings, 1 reply; 13+ messages in thread From: Mike Hearn @ 2012-04-14 15:13 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Development > So, to be specific... a A->B chain of transactions, that collectively > meet the network's fee requirements? Yes. > Ideally the fee, if any, is market based and negotiated. Problem is... like > democracy, no matter how ugly it is, people have trouble finding a > better system :) I think this is something we can explore over the coming years. I favor having people commonly pass transactions around outside the broadcast network with the transactions and their dependencies being broadcast only when there's a lack of trust between recipient and sender. The block chain is an optional service after all. > Furthermore, many of these ideas -- like sending TX's directly to the > merchant -- involve far more direct payee<->payer communication on the > part of the wallet client than is currently envisioned Yes, though it's worth remembering that the original Bitcoin design did have participants communicate directly. When I talked with Satoshi in 2009 he saw the pay-to-IP-address mode imagined as the normal way to make payments, with pay-to-address being used as a kind of backup for when the recipient was offline. In the end that's not how things evolved, but it the pendulum could easily swing back the other way. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-14 15:13 ` Mike Hearn @ 2012-04-14 20:20 ` Jeff Garzik 2012-04-14 21:27 ` Pieter Wuille 2012-04-15 8:12 ` Andreas Schildbach 0 siblings, 2 replies; 13+ messages in thread From: Jeff Garzik @ 2012-04-14 20:20 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Development On Sat, Apr 14, 2012 at 11:13 AM, Mike Hearn <mike@plan99•net> wrote: >> So, to be specific... a A->B chain of transactions, that collectively >> meet the network's fee requirements? > > Yes. ACK on the concept >> Ideally the fee, if any, is market based and negotiated. Problem is... like >> democracy, no matter how ugly it is, people have trouble finding a >> better system :) > > I think this is something we can explore over the coming years. I > favor having people commonly pass transactions around outside the > broadcast network with the transactions and their dependencies being > broadcast only when there's a lack of trust between recipient and > sender. The block chain is an optional service after all. Agreed. A TX is just a signed message. No reason why it -must- use mainnet's distributed notary service. >> Furthermore, many of these ideas -- like sending TX's directly to the >> merchant -- involve far more direct payee<->payer communication on the >> part of the wallet client than is currently envisioned > > Yes, though it's worth remembering that the original Bitcoin design > did have participants communicate directly. When I talked with Satoshi > in 2009 he saw the pay-to-IP-address mode imagined as the normal way > to make payments, with pay-to-address being used as a kind of backup > for when the recipient was offline. > > In the end that's not how things evolved, but it the pendulum could > easily swing back the other way. IIRC pay-to-IP was removed because it was unreliable -and- detrimental to privacy? ISTR Satoshi specifically disliking the privacy elements of p2ip. But I also have a "gut feeling" that these sorts of payments and direct communication should be done via a wholly separate protocol than the bitcoin P2P protocol. Doing p2ip as it was done originally, inside the bitcoin P2P protocol, was a mistake. Extensible as it is, I think a better job -- and faster evolution -- can be done with a separate protocol on a separate port. Some HTTP derivative would probably make life easier for mobile payments and firewalled scenarios, and for client->merchant communications, for instance. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-14 20:20 ` Jeff Garzik @ 2012-04-14 21:27 ` Pieter Wuille 2012-04-14 22:49 ` Jeff Garzik 2012-04-15 8:12 ` Andreas Schildbach 1 sibling, 1 reply; 13+ messages in thread From: Pieter Wuille @ 2012-04-14 21:27 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Development On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote: > >> Furthermore, many of these ideas -- like sending TX's directly to the > >> merchant -- involve far more direct payee<->payer communication on the > >> part of the wallet client than is currently envisioned > > > > Yes, though it's worth remembering that the original Bitcoin design > > did have participants communicate directly. When I talked with Satoshi > > in 2009 he saw the pay-to-IP-address mode imagined as the normal way > > to make payments, with pay-to-address being used as a kind of backup > > for when the recipient was offline. > > > > In the end that's not how things evolved, but it the pendulum could > > easily swing back the other way. > > But I also have a "gut feeling" that these sorts of payments and > direct communication should be done via a wholly separate protocol > than the bitcoin P2P protocol. Doing p2ip as it was done originally, > inside the bitcoin P2P protocol, was a mistake. Extensible as it is, > I think a better job -- and faster evolution -- can be done with a > separate protocol on a separate port. > > Some HTTP derivative would probably make life easier for mobile > payments and firewalled scenarios, and for client->merchant > communications, for instance. Have you ever read https://gist.github.com/1237788 ? -- Pieter ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-14 21:27 ` Pieter Wuille @ 2012-04-14 22:49 ` Jeff Garzik 0 siblings, 0 replies; 13+ messages in thread From: Jeff Garzik @ 2012-04-14 22:49 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Development On Sat, Apr 14, 2012 at 5:27 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote: > On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote: >> Some HTTP derivative would probably make life easier for mobile >> payments and firewalled scenarios, and for client->merchant >> communications, for instance. > > Have you ever read https://gist.github.com/1237788 ? Looks like you're already headed in the right direction :) -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-14 20:20 ` Jeff Garzik 2012-04-14 21:27 ` Pieter Wuille @ 2012-04-15 8:12 ` Andreas Schildbach 1 sibling, 0 replies; 13+ messages in thread From: Andreas Schildbach @ 2012-04-15 8:12 UTC (permalink / raw) To: bitcoin-development On 04/14/2012 10:20 PM, Jeff Garzik wrote: >>> Furthermore, many of these ideas -- like sending TX's directly to the >>> merchant -- involve far more direct payee<->payer communication on the >>> part of the wallet client than is currently envisioned >> >> Yes, though it's worth remembering that the original Bitcoin design >> did have participants communicate directly. When I talked with Satoshi >> in 2009 he saw the pay-to-IP-address mode imagined as the normal way >> to make payments, with pay-to-address being used as a kind of backup >> for when the recipient was offline. >> >> In the end that's not how things evolved, but it the pendulum could >> easily swing back the other way. > > IIRC pay-to-IP was removed because it was unreliable -and- detrimental > to privacy? ISTR Satoshi specifically disliking the privacy elements > of p2ip. > > But I also have a "gut feeling" that these sorts of payments and > direct communication should be done via a wholly separate protocol > than the bitcoin P2P protocol. Doing p2ip as it was done originally, > inside the bitcoin P2P protocol, was a mistake. Extensible as it is, > I think a better job -- and faster evolution -- can be done with a > separate protocol on a separate port. Just to let you know, Bitcoin Wallet for Android already supports directly sending transactions via NFC and QR-Code. Currently, receiving such a transaction is handled the same way as if it was received via P2P. This means the sender does not need to have internet access the moment he pays. The transaction is being broadcast into the P2P network by the receiver. Cheers, Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-12 18:38 [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior Jeff Garzik ` (2 preceding siblings ...) 2012-04-13 10:04 ` Mike Hearn @ 2012-04-15 10:54 ` Jorge Timón 2012-04-15 15:17 ` Jeff Garzik 3 siblings, 1 reply; 13+ messages in thread From: Jorge Timón @ 2012-04-15 10:54 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Development On 4/12/12, Jeff Garzik <jgarzik@exmulti•com> wrote: > 1. N = 1 or 2 or whatever the community prefers. Ideally enough time > for a third-tier miner, mining strange TXs, finds a block. > 2. H1 = height of block chain, when a TX is received > 3. H2 = H1 + (144 * N) > 4. If block chain height reaches H2, and TX has not made it into a > block, drop TX from memory pool Why not just adding a field expiration_block = H2? It seems more explicit and flexible than using a 144 * N constant. You're changing the protocol anyway, right? Another question, aren't different peers going to get different H1 for the same tx? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 2012-04-15 10:54 ` Jorge Timón @ 2012-04-15 15:17 ` Jeff Garzik 0 siblings, 0 replies; 13+ messages in thread From: Jeff Garzik @ 2012-04-15 15:17 UTC (permalink / raw) To: jtimonmv; +Cc: Bitcoin Development 2012/4/15 Jorge Timón <timon.elviejo@gmail•com>: > On 4/12/12, Jeff Garzik <jgarzik@exmulti•com> wrote: >> 1. N = 1 or 2 or whatever the community prefers. Ideally enough time >> for a third-tier miner, mining strange TXs, finds a block. >> 2. H1 = height of block chain, when a TX is received >> 3. H2 = H1 + (144 * N) >> 4. If block chain height reaches H2, and TX has not made it into a >> block, drop TX from memory pool > > Why not just adding a field expiration_block = H2? > It seems more explicit and flexible than using a 144 * N constant. > You're changing the protocol anyway, right? No, not changing the protocol. Further, adding a field to TX would imply the client needed to rewrite the TX for each retransmit, changing the hash. Not good at all. > Another question, aren't different peers going to get different H1 for > the same tx? Typically no, because 99.9% of TX's make it throughout the network in seconds. But yes it is possible, just like it is possible today to receive a TX at various times. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-04-15 15:17 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-12 18:38 [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior Jeff Garzik 2012-04-12 19:19 ` Alan Reiner 2012-04-12 19:26 ` Jeff Garzik 2012-04-13 8:35 ` Andy Parkins 2012-04-13 10:04 ` Mike Hearn 2012-04-13 16:41 ` Jeff Garzik 2012-04-14 15:13 ` Mike Hearn 2012-04-14 20:20 ` Jeff Garzik 2012-04-14 21:27 ` Pieter Wuille 2012-04-14 22:49 ` Jeff Garzik 2012-04-15 8:12 ` Andreas Schildbach 2012-04-15 10:54 ` Jorge Timón 2012-04-15 15:17 ` Jeff Garzik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox