Flavien Charlon [ARCHIVE] on Nostr: 📅 Original date posted:2014-08-05 📝 Original message:> It would make more sense ...
📅 Original date posted:2014-08-05
📝 Original message:> It would make more sense to introduce a new script opcode that pushes the
current block height onto the operand stack. Then you could implement
arbitrary logic about which blocks the transaction can be valid in. This
would require that the client revalidate all transactions in its mempool
(really, only those making use of this opcode) whenever the chain tip
changes.
I have to say I like this idea, this would allow someone to prove they
can't spend funds before a given date, and vice versa, prove that the funds
can't ever be spent after a given date (and this is provably prunable,
isn't it?). Of course, there are some risks associated with that, but
nobody is forced to use it.
> flooding the network with unrelated high fee transactions
> in order to push a transaction out to where it can never be mined at
> all.
This becomes increasingly expensive as the deadline is further away, so not
very hard to mitigate.
On Sat, Aug 2, 2014 at 1:36 AM, Tom Harding <tomh at thinlink.com> wrote:
> On 7/31/2014 5:58 PM, Kaz Wesley wrote:
> > 1. start setting nLockTime to the current height by default in newly
> > created transactions (or slightly below the current height, for
> > reorg-friendliness)
>
> Reorg-frendliness is the opposite of the rationale behind #2340, which
> proposes setting nLockTime at current-height + 1 to prevent
> "fee-sniping" reorgs...
>
>
> > 2. once users have had some time to upgrade to clients that set
> > nLockTime, start discouraging transactions without nLockTime --
> > possibly with a slightly higher fee required for relay
> > 3. start rate-limiting relay of transactions without an nLockTime
> > (maybe this alone could be used to achieve [2])
> > 4. add a new IsStandard rule rejecting transactions with an nLockTime
> > more than N blocks behind the current tip (for some fixed value N, to
> > be determined)
> >
>
> One way to proceed is implement #3753 (mempool janitor) in such a way
> that transactions with nLockTime are allowed to live a bit longer in the
> mempool (say 500 blocks) than those without (72 hours). In other words,
> as a first step, just actually start expiring things from the mempool in
> bitcoin core, and leave any relay fee adjustments or rate limiting for
> later. The isStandard change would be a good complement to #3753, to
> avoid relaying a tx that will soon expire by the nLockTime rule anyway.
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> 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/20140805/6b077ada/attachment.html>;
📝 Original message:> It would make more sense to introduce a new script opcode that pushes the
current block height onto the operand stack. Then you could implement
arbitrary logic about which blocks the transaction can be valid in. This
would require that the client revalidate all transactions in its mempool
(really, only those making use of this opcode) whenever the chain tip
changes.
I have to say I like this idea, this would allow someone to prove they
can't spend funds before a given date, and vice versa, prove that the funds
can't ever be spent after a given date (and this is provably prunable,
isn't it?). Of course, there are some risks associated with that, but
nobody is forced to use it.
> flooding the network with unrelated high fee transactions
> in order to push a transaction out to where it can never be mined at
> all.
This becomes increasingly expensive as the deadline is further away, so not
very hard to mitigate.
On Sat, Aug 2, 2014 at 1:36 AM, Tom Harding <tomh at thinlink.com> wrote:
> On 7/31/2014 5:58 PM, Kaz Wesley wrote:
> > 1. start setting nLockTime to the current height by default in newly
> > created transactions (or slightly below the current height, for
> > reorg-friendliness)
>
> Reorg-frendliness is the opposite of the rationale behind #2340, which
> proposes setting nLockTime at current-height + 1 to prevent
> "fee-sniping" reorgs...
>
>
> > 2. once users have had some time to upgrade to clients that set
> > nLockTime, start discouraging transactions without nLockTime --
> > possibly with a slightly higher fee required for relay
> > 3. start rate-limiting relay of transactions without an nLockTime
> > (maybe this alone could be used to achieve [2])
> > 4. add a new IsStandard rule rejecting transactions with an nLockTime
> > more than N blocks behind the current tip (for some fixed value N, to
> > be determined)
> >
>
> One way to proceed is implement #3753 (mempool janitor) in such a way
> that transactions with nLockTime are allowed to live a bit longer in the
> mempool (say 500 blocks) than those without (72 hours). In other words,
> as a first step, just actually start expiring things from the mempool in
> bitcoin core, and leave any relay fee adjustments or rate limiting for
> later. The isStandard change would be a good complement to #3753, to
> avoid relaying a tx that will soon expire by the nLockTime rule anyway.
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> 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/20140805/6b077ada/attachment.html>;