* [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