< * jgarzik>
is a static_cast<> newbie - I wonder if that means an out-of-range behavior is different
< jgarzik>
i.e. static_cast<> triggers "new_type foo(int64)" which results in a INT_MAX value for out of range, versus an exception thrown for univalue
< gmaxwell>
jgarzik: I dunno that changing it is the right thing to do? new behavior might be better?
< jgarzik>
gmaxwell, I think new behavior is better, more type specific
< jgarzik>
gmaxwell, However checking that patch would provide a quick field fix + ascertain that it is indeed the problem
< gmaxwell>
k would be glad to test.
< jgarzik>
gmaxwell, every .get_int() would need to be re-examined
< gmaxwell>
er, I am currently diverged from master; so uh. hm.
< jgarzik>
gmaxwell, the file paths may have shuffled, but the files & code are likely to be applicable
< rusty>
sipa: botbot.me people finally got back to me about logging #lightning-dev; will ping them about this too when we close the loop.
< GitHub13>
[bitcoin] sandakersmann opened pull request #6766: [Trivial] Consistent use of lower case letters (master...lower_case) https://github.com/bitcoin/bitcoin/pull/6766
< morcos>
maaku: i didn't understand your response on email about decreasing granualarity being a soft fork?
< morcos>
maybe i'm confused as to what decreasing granularity means, but it seems to me if you go from 8 second granularity to 1 second granularity, you need 3 more bits and its a soft fork? if you decide you don't need 1 second granularity, and want to use those 3 bits for something else, that would be hard fork
< morcos>
so why not set aside more of the low order bits to start with and use only like 64 second granularity. then we'd have 1 high order bit for a different scheme and 11 or 14 low order bits for soft forking within the scheme
< maaku>
morcos: my terminology was reversed, sorry
< maaku>
but going from 1s -> 2^n seconds is a soft fork
< morcos>
maaku: why?
< morcos>
doesn't that depend on what the interpretation of those bits is in the new rules
< maaku>
morcos: you round up the relative lock-time to 2^n
< morcos>
the new rules will say that
< morcos>
but if the old rules use 1s, then something that was valid under the old rules, may or may not be valid under the new rules
< maaku>
right
< maaku>
that's a soft-fork
< morcos>
oh, did i just confuse myself
< maaku>
i think you're getting tripped up over a different concern -- if you change the meaning of those bits, old clients might be setting them without knowing that they are assigning meaning
< maaku>
but that too can be managed, either by making sure it is relatively harmless under the new rules, or by soft-forking in the "round up" rule, making those bits non-standard, letting infrastructure upgrade, and then soft-forking new meaning
< morcos>
so what exactly is the round up rule?
< morcos>
if we decide to use a few less bits, then you'll shift by less bits and then add 1 and then multiply by 2^n?
< morcos>
less = n
< maaku>
let's say we recover 3 from the time version, then 0 is a lock-time of 0, 1-8 are a lock-time of 8
< maaku>
*recover 3 bits
< morcos>
but how does that work
< morcos>
because don't 1 and 0 look the same
< morcos>
0-7 look the same
< maaku>
the usual bitfiddling (n + 7) & ~0x7
< maaku>
or somesuch
< morcos>
i'll freely admit i'm too tired to convince even myself i know what i'm talking about, but perhaps it would help if you could write up a quick demonstration
< morcos>
also i didn't really think about how it ties into CSV?
< maaku>
python -c 'for i in xrange(16): print "%d\t%d" % (i, (i+7) & ~0x7)'
< morcos>
ha ha, yeah i got what you were saying, but the point is if you're no longer using those low 3 order bits how can you do that, they now mean something different
< maaku>
OH ok. I thought there must be a miscommunication. It's not THAT late there ;)
< maaku>
I mean you would just do that for the purpose of the relative lock-time check
< maaku>
so under the new rules, within LockTime() only, it does this round-up rule when calculating relative lock-time
< morcos>
but you can't, if someone wants to encode 000 in the 3 bits for the new rule and 0 for a lock time. they will have 0000 = 0 for CSV . on the other hand, someone who wanted to encode 111 for the new rule woudl have 0111 = 8 for CSV . but they both wanted 0 for CSV
< morcos>
how could someone encode 111 for the new rule, but still have a 0 for CSV
< morcos>
so perhaps thats a soft fork in that its more restrictive, but they can no longer choose the values they wanted?
< maaku>
you can't. but is that an issue?
< maaku>
i mean you could round up the entire range so 0-7 means 8, 8-15 means 16
< maaku>
but then you lose the ability to specify zero lock time at all
< maaku>
for CSV, it does straight integer comparisons. it doesn't even mask off the unused low order bits
< morcos>
well thats what i'm claiming is that depending on what you wanted to use the other 3 bits for you might lose that
< morcos>
so i agree rounding up is a soft fork
< morcos>
if you lose some bits
< morcos>
why is adding bits for finer time granularity a hard fork
< maaku>
well now that we've had this conversation, I suppose you could add bits, just not to the first range
< GitHub89>
[bitcoin] jmcorgan opened pull request #6768: zmq: update docs to reflect feature is compiled in automatically (master...update-zmq-docs) https://github.com/bitcoin/bitcoin/pull/6768
< morcos>
first range? you mean high order bits?
< maaku>
let's say you went from 8s -> 1s
< maaku>
you could do that by saying 0 is now a relative lock-time of 8, 1 (previously still 0: 0.001) is now a relative lock-time of 9, 2 (0.010) is 10, etc.
< morcos>
i'm not sure i understand why you don't mask off the lower order bits for CSV. wouldn't that make it harder potentially to make some other soft fork out of them later.
< maaku>
the bits were originally added by a suggestion from gmaxwell who was considering them to represent a share chain
< morcos>
i don't understand why you have to round up if you're adding bits... 0 is 0. 0.001 was 0 now its 1 and so on.. why do you have to start at 8?
< maaku>
in that case you could even have sub-block granularity
< maaku>
but you're right, masking them should be strictly safe to do
< maaku>
*safely soft-fork upgradable
< morcos>
i guess i'm viewing the low order bits (if they're masked off for all operations now) as something that is available for any kind of soft fork we want in the future while still have BIP 68 in effect
< morcos>
and the high order bit represents a way to selectively have BIP 68 or some other use of nSequence
< maaku>
correct
< morcos>
so to me, if we're pretty sure we like BIP 68, then having only 1 high order bit is good enough, but we should leave as many low order bits as we can. i hadn't thought about the rounding up to get rid of some bits, but that doesn't work well if CSV is checking them anyway.
< maaku>
morcos: it works the same I think
< morcos>
i'm sorry for chiming in with an opinion late in this process, i wasn't really paying much attention earlier. but to the extent we preserve as much flexibility for the future as we can, it helps address petertodd's concerns
< maaku>
I'm all for increased flexibility
< maaku>
just trying to map out the ramifications here myself
< morcos>
yeah i mean maybe even with CSV checking all the bits, as long as you round up enough you're ok, but i think it makes sense to make sure we're not losing any edge cases. I suppose a relative time lock of 0 seconds has no benefit because you can always use a 0 block lock?
< morcos>
but it just seems cleaner to me to start with less bits and add more if we need the granularity than the other way around
< maaku>
thank you for calling me on this; my thinking on the soft-fork vs hard-fork was backwords
< maaku>
I just worked out some examples and it is a soft-fork to add bits
< morcos>
just glad i wasn't totally off my rocker
< maaku>
morcos: my proposal would then be 16-bits of precision: block-height granularity of 1 block, block-time granularity of 512s
< maaku>
in both cases up to a year of relative lock-time
< morcos>
yeah i mean i think that sounds nicer to me, but i'm not very familiar with the use cases
< maaku>
well sub-600s lock-times are suspect anyway, because block interval and variance
< morcos>
so with CSV it's valid if they are the same right? so yeah then it doesn't matter if you're including all the low order bits when comparing
< morcos>
oh wait
< maaku>
i think you would get the most flexibility by masking there as well
< morcos>
yeah
< morcos>
i wonder if it would be simpler just to reserve all the bits on the high order side
< morcos>
you can always do the same thing with those bits, just a bit more complicated
< morcos>
anyway, got to call it a night
< maaku>
g'night
< GitHub183>
[bitcoin] gmaxwell opened pull request #6769: Test LowS in standardness, removes nuisance malleability vector. (master...no_nuisance_malleability) https://github.com/bitcoin/bitcoin/pull/6769
< btcdrak>
morcos: did you see my ML post? if you set the nSequence MSB then the remaining 31 bits are free entirely.
< GitHub28>
bitcoin/master 58981d4 Arne Brutschy: Changed logging to make -logtimestamps to work also for -printtoconsole
< GitHub28>
bitcoin/master 3b2d37c Wladimir J. van der Laan: Merge pull request #6742...
< GitHub180>
[bitcoin] laanwj closed pull request #6742: Changed logging to make -logtimestamps to work also for -printtoconsole (master...feature-logtimestamps-toconsole) https://github.com/bitcoin/bitcoin/pull/6742
< GitHub73>
bitcoin/master dd28089 Johnathan Corgan: autotools: move checking for zmq library to common area in configure.ac...
< GitHub73>
bitcoin/master bdece50 Wladimir J. van der Laan: Merge pull request #6743...
< GitHub28>
[bitcoin] laanwj closed pull request #6743: autotools: move checking for zmq library to common area in configure.ac (master...fixes/6679) https://github.com/bitcoin/bitcoin/pull/6743