On Fri, Oct 16, 2015 at 3:26 AM, Rusty Russell via bitcoin-dev
wrote:
> ... Gavin just told me about setmocktime. That's fast service!
Once more functions (specially consensus-critical functions) take
nTime explicitly as parameter instead of relying on the
library-unfriendly GetAdjustedTime(), t
Rusty Russell via bitcoin-dev writes:
>>From a practical perspective: yuck. There's currently no way to play
> with bitcoind's perception of time, so that's a very long sleep to
> blackbox test (which is what my lightning test script does).
>
> So consider this YA feature request :)
... Gavin j
Btc Drak writes:
> Alex,
>
> I am sorry for not communicating more clearly. Mark and I discussed your
> concerns from the last meeting and he made the change. The BIP text still
> needs to be updated, but the discussed change was added to the PR, albeit
> squashed making it more non-obvious. BIP68
Adam, there is really no justification I can see to lower the interblock
interval on the Bitcoin blockchain, primarily due to the effects of network
latency. Lowering the interblock interval and raising the block size are
not equal alternatives - you can always get more throughput in bitcoin by
rai
Adam,
The remaining 14 bits can be used to soft fork in finer granularity in the
future.
Alex
On Thu, Oct 15, 2015 at 12:37 PM, Adam Back wrote:
> Does that pre-judge that block interval would never change from
> 10mins? Eg say with IBLT or fountain codes etc and security arguments
> for the
Does that pre-judge that block interval would never change from
10mins? Eg say with IBLT or fountain codes etc and security arguments
for the current limitations of them are found, such that orphan rates
can remain low in a decentralised way with 1min blocks, then the
locktime granularity would be
Alex,
I am sorry for not communicating more clearly. Mark and I discussed your
concerns from the last meeting and he made the change. The BIP text still
needs to be updated, but the discussed change was added to the PR, albeit
squashed making it more non-obvious. BIP68 now explicitly uses 16 bits
Mark,
You seemed interested in changing BIP 68 to use 16 bits for sequence number
in both the block and time versions, making time based sequence numbers
have a resolution of 512 seconds.
I'm in favor of this approach because it leaves aside 14 bits for further
soft forks within the semantics of
Peter Todd writes:
> On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
>> Peter Todd via bitcoin-dev
>> writes:
>> > However I don't think we've done a good job showing why we need to
>> > implement this feature via nSequence.
>>
>> It could be implemented in other ways, but nSequen
On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> Peter Todd via bitcoin-dev
> writes:
> > However I don't think we've done a good job showing why we need to
> > implement this feature via nSequence.
>
> It could be implemented in other ways, but nSequence is the neatest and
> most
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,
Another issue that came to mind re: CSV review is that there isn't
actually any one pull-req with all the code changes together, making it
hard to
Hi Peter,
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> So we need to make the case for two main things:
>
> 1) We have applications that need a relative (instead of absolute CLTV)
Lightning network needs RCLTV for bidireciontal payment channels without
an explici
On Mon, Oct 05, 2015 at 05:19:06PM -0700, Mark Friedenbach via bitcoin-dev
wrote:
> Alex, decreasing granularity is a soft-fork, increasing is a hard-fork.
> Therefore I've kept the highest possible precision (1 second, 1 block) with
> the expectation that at some point in the future if we need mo
Peter Todd via bitcoin-dev
writes:
> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence.
It could be implemented in other ways, but nSequence is the neatest and
most straightforward I've seen.
- I'm not aware of any other (even vague) propos
Regarding the keeping nSequence for future expansion I believe this has
been covered in the specification section of BIP68[1]: For transaction
version >= 2, if the MSB of nSequence is unset, the field is interpreted as
relative locktime, otherwise no special consensus meaning is attached (and
thus
Alex, decreasing granularity is a soft-fork, increasing is a hard-fork.
Therefore I've kept the highest possible precision (1 second, 1 block) with
the expectation that at some point in the future if we need more low-order
bits we can soft-fork them to other purposes, we can decrease granularity
at
Peter,
Your concern about whether this is the best way to use the nSequence field;
would that be addressed by providing more high order bits to signal
different uses of the field? At a certain point we're really not limiting
the future at all and there is something to be said for not letting the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi aj,
On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:
> On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via
> bitcoin-dev wrote:
>> So we need to make the case for two main things: 1) We have
>> applications that need a relative (i
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> So we need to make the case for two main things:
> 1) We have applications that need a relative (instead of absolute CLTV)
> 2) Additionally to RCLTV, we need to implement this via nSequence
> However I don't think we've
BIP68 allows per-input locktime, though I don't know how this could be
useful.
BIP68 and BIP112 are mostly ready. If we try to reimplement
relative-locktime without using nSequence, we may need to wait for
another year for deployment.
A compromise is to make BIP68 optional, indicated by a bi
BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,
which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY.
However, CSV does define behavior for the previously undefined nSequence
field, which is the only "free-form" field we currently have in the
transaction se
21 matches
Mail list logo
