Alan Reiner [ARCHIVE] on Nostr: 📅 Original date posted:2012-04-12 📝 Original message:My one big concern about ...
📅 Original date posted:2012-04-12
📝 Original message: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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120412/8ae4ec6d/attachment.html>;
📝 Original message: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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120412/8ae4ec6d/attachment.html>;