On Fri, Sep 18, 2015 at 12:44 AM, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev"
> wrote:
>>Fill or kill us normally used for trades and I think it can be
>>confusing.
>>Previous times this has
On 9/17/2015 8:27 PM, jl2012 via bitcoin-dev wrote:
> However, requiring 100 block maturity will unfortunately make the
> system much less appealing since the recipient may not like it.
The maturity requirement can be dropped if the expiration height is more
that 100 blocks after inclusion height.
How them being expensive to generate make them less likely to be reorged?
Would an op_return output used as a nonce to make the hash of the
transaction contain some proof of work make the non-coinbase expirable
transaction more secure against reorgs?
I'm afraid your point is irrelevant.
On Sep 19,
On Thursday, September 17, 2015 7:14:38 PM Jorge Timón via bitcoin-dev wrote:
> As Mark points out this can be made safe by requiring that all the outputs
> of a transaction that can expire have op_maturity/csv/rcltv of 100. That
> makes them as reorg-safe as coinbase transactions.
Not quite as sa
On Sep 17, 2015 6:48 PM, "Peter Todd" wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> >Fill or kill us normally used for trades and I think it can be
> >con
Btc Drak 於 2015-09-18 02:42 寫到:
On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev
wrote:
Btc Drak 於 2015-09-17 15:12 寫到:
Forgive me if I have missed the exact use-case, but this seems
overly
complex. Surely fill-or-kill refers to getting a transaction
confirmed
within a few confirms or
On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Btc Drak 於 2015-09-17 15:12 寫到:
>
>> Forgive me if I have missed the exact use-case, but this seems overly
>> complex. Surely fill-or-kill refers to getting a transaction confirmed
>> within a
Peter Todd via bitcoin-dev 於 2015-09-17 18:44 寫到:
It can be implemented by a "treat like Coinbase" flag in the
UTXO set, set when the output is created.
I think this is the cleanest way to implement the maturity requirement.
I understand why we need maturity, However, requiring 100 block matu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev"
wrote:
>Fill or kill us normally used for trades and I think it can be
>confusing.
>Previous times this has been discussed it has been discussed under
>nExpiryTime or op_heigh
We are currently using nLockTime for share info and nSequence for
extranonce2. I have carefully reviewed the reference implementation of
BIP68 and it should be compatible, but this proposal may break the
implementation unless it does not affect coinbase transactions.
On Fri, Sep 18, 2015 at 2:41 A
Fill or kill us normally used for trades and I think it can be confusing.
Previous times this has been discussed it has been discussed under
nExpiryTime or op_height (which enables expiration), for example, in the
freimarkets white paper.
As Mark points out this can be made safe by requiring that
Forgive me if I have missed the exact use-case, but this seems overly
complex. Surely fill-or-kill refers to getting a transaction confirmed
within a few confirms or to drop the tx from the mempool so it wont be
considered for inclusion anymore. As such, you could just repurpose a small
range of nL
Note that this violates present assumptions about transaction validity,
unless a constraint also exists that any output of such an expiry block is
not spent for at least 100 blocks.
Do you have a clean way of ensuring this?
On Thu, Sep 17, 2015 at 2:41 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lis
Fill-or-kill tx is not a new idea and is discussed in the Scaling
Bitcoin workshop. In Satoshi's implementation of nLockTime, a huge range
of timestamp (from 1970 to 2009) is wasted. By exploiting this unused
range and with compromise in the time resolution, a fill-or-kill system
could be built
14 matches
Mail list logo
