How many years of relative lock time do we need? It really depends why
we need a relative lock time in the first place, what what does it offer
in addition to CHECKLOCKTIMEVERIFY. The only case I know is when the
confirmation taking too long, CLTV may expire before the tx is
confirmed. For use
On Wed, Sep 16, 2015 at 11:52 PM, Eric Lombrozo wrote:
> The exact numbers (95% vs. 75% etc) don't need to be completely specified
> to start working on an implementation. What really matters for now is
> defining the states and trigger mechanisms. I'd rather we not argue over
> the optimal value
On Thu, Sep 17, 2015 at 12:38 PM, Tier Nolan via bitcoin-dev
wrote:
> The advantage of enforcing the rule when 75% is reached (but only for blocks
> with the bit set) is that miners get early notification that they have
> implemented the rule incorrectly.They might produce blocks that they
> t
Hello,
First of all, I'm not sure if it is the right place to ask for such help.
But, I thought, someone might just help out.
I'm looking for two graphs to analyze the effectiveness of BIP 106, which
can be found at
https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki.
Blockchain.info c
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
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
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
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
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
-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
On Wed, Sep 16, 2015 at 06:29:28PM -0400, Peter Todd via bitcoin-dev wrote:
> I've run into a number of cases where companies were maintaining forks
> of Bitcoin Core unnecessarily, where a different, loosely coupled,
> architecture could do what they needed to do without including the new
> logic
Hello,
At Monday's code sprint we had a good idea to schedule a regular developer
meeting in #bitcoin-dev.
Attendance is of course voluntary, but it may be good to have a time that many
people are expected to be present and current issues can be discussed.
Any preference for days/times?
What
+1
sounds good to me!
On Thu, Sep 17, 2015 at 9:07 PM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> At Monday's code sprint we had a good idea to schedule a regular developer
> meeting in #bitcoin-dev.
>
> Attendance is of course voluntar
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 19:56:17 GMT-07:00, Alex Morcos via bitcoin-dev
wrote:
>+1
>sounds good to me!
+2
My schedule is chaotic, but I'll try to attend.
-BEGIN PGP SIGNATURE-
iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV+5
I am unlikely to attend at that time, but there is no time that will fit
everybody's schedules. I approve of the idea and look forward to reading
the logs.
On Thu, Sep 17, 2015 at 9:07 PM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> At Mon
On Friday, September 18, 2015 1:07:10 AM Wladimir J. van der Laan via
bitcoin-dev wrote:
> At Monday's code sprint we had a good idea to schedule a regular developer
> meeting in #bitcoin-dev.
>
> Attendance is of course voluntary, but it may be good to have a time that
> many people are expected
Correction of a correction, in-line:
On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > - Many interested or at least willing to accept a "short term bump", a
> > hard fork to modify block size limit regime to be cost-based via
> > "n
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
19 matches
Mail list logo
