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
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 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
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
-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
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
+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
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
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
-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
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
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
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
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
19 matches
Mail list logo
