< jl2012>
just want to confirm: during bip9 locked_in, blocks with any nVersion >=4 are valid?
< btcdrak>
jl2012: what do you mean? once lockin is reached signalling is no longer required but recommended.
< jl2012>
btcdrak: you have answered my question: no longer required
< jl2012>
i think certains pools are setting their version manually
< jl2012>
they have to turn it back to 0x20000000 at or before 419328
< jl2012>
or that may trigger the unknown softfork warning
< jl2012>
should we ask miners (who are manually setting the version) to change the version to 0x20000000 *at* or *before* 419328?
< jl2012>
I think it'd be better if they change it before 419328. Otherwise, if they keep signalling 0x20000001 after 419328, Bitcoin Core clients will think there is an unknown softfork
< jl2012>
"csv": {
< jl2012>
"status": "locked_in",
< jl2012>
"startTime": 1462060800,
< jl2012>
"timeout": 1493596800
< jl2012>
},
< btcdrak>
how many 0x20000001 blocks?
< jl2012>
In the last difficulty round, CSV had 1946/2016 (96.53%)
< jl2012>
0x20000001 is 1916/2016 (95.04%)
< jl2012>
so we could have a locked_in just with only standard Bitcoin Core 0.12.1 blocks
< gmaxwell>
if the signaling goes away now we will panic
< gmaxwell>
because it will suggest the network state will diverge if a CSV violation is mined.
< btcdrak>
the spec says should but not must continue to signal during locked in state.
< gmaxwell>
the purpose of the continued signaling is to let us humans see that the consensus state hasn't changed. it's not enforced by anything, thus not must.
< jl2012>
after activation of CSV, how many blocks are needed to trigger the unknown softfork warning?
< gmaxwell>
50 out of 100. is the lower threshold.
< jl2012>
so they have to react in less than one day if we ask them to change it after it is active
< gmaxwell>
Since we're now aware of miners manually setting version bits we should start work on a new deployment mechenism and depricate BIP9. :(
< gmaxwell>
I think BIP9 is too unsafe to use with parties manually setting the bits. The issue is if they have old nodes that don't enforce the consensus rules and they're failing over to them and getting work from them it can split the network, and it would be completely silent.
< btcdrak>
well it is just f2pool and antpool afaik
< gmaxwell>
if it's most of the hashpower it means that BIP9 is a currently failed design. The initial switch to signal CSV was _Exactly_ at the starting time, so I felt confident that the version numbers weren't being faked.
< jl2012>
gmaxwell: the same problem applies to ISM
< gmaxwell>
I'm really crestfallen to find that it's being faked now.
< gmaxwell>
jl2012: yes, and we had a failure with ISM, we hoped that the new mechenism which did not orphan non-conforming blocks would not be faked.
< gmaxwell>
the fact that that failure involved empty blocks is the only thing that prevented there from being large doublespending losses.
< gmaxwell>
jl2012: in any case, if we know now that they're turning the bit off, we can not freak out when it happens.
< gmaxwell>
but we should urge them to check very carefully that _all_ of their infrastructure is upgraded and that there are no old nodes that might come back up, e.g. after a power cycle.
< btcdrak>
i am sure we can solve the problem by talking with them. i think we should advice them to stop signalling before activation
< gmaxwell>
the problem is likely that version is something exposed to front end mining equipment, and if they are doing 'fake' block generation then they need to have the block version succession logic in their own software, or configure it manually.
< btcdrak>
the general public just need education
< gmaxwell>
btcdrak: we can educate around risk people impose on themselves, for risk they impose on others we should strive towards designs that are hard to misconfigure.
< gmaxwell>
I thought BIP9 got us there, but apparently I was mistaken. An intended feature of the design isn't working.
< btcdrak>
the website faq advises miners to stop signalling before activation for those manually setting the bit
< gmaxwell>
...
< btcdrak>
gmaxwell: i dont see how the issue is any different than ISM. it is better under VB since there is a two week period before enforcement.
< gmaxwell>
This is seriously fucked up, miners signaling versions inconsistent with the consensus rules they were running already forked the network once and narrowly avoided an incident. BIP9's design was partially motivated in avoiding that. (with no "set version or get orphaned" the beliefe was there would be no reason to fake it.
< btcdrak>
miners have been manually setting bloxk version long ago
< gmaxwell>
yes, and it already caused one ~6 block deep chain fork!
< btcdrak>
right. VB is better because of grace period. but maybe I am not explainimg well. when I talked to ant and fish they said they upgraded first and then changed the version number.
< btcdrak>
so they are not putting anyone at risk by doing it in that order.
< gmaxwell>
btcdrak: the grace period doesn't help this issue. The issue is that we don't get any strong, hard to screw up, indication that their upgrades were effective. This depends on their internal monitoring being effective, which it is not historically for many mining operations, and we shouldn't expect it to be because the risk is predominantly not held by them.
< gmaxwell>
btcdrak: only if they made no errors.
< gmaxwell>
and it's hard to tell, because the manual setting covers up the indicator.
< btcdrak>
it is true. they do forget nodes... i dont see how you can get around this problem. miners need to change their habits.
< jl2012>
Let's assume a miner is not setting manually, and some how fall back to 0.12.0 after activation. What will happen?
< gmaxwell>
jl2012: won't be detected anymore, the tradeoff for getting the bit back is that you only learn about the status during the month of signaling and grace period.
< gmaxwell>
But even that is meaningless if manually overridden.
< btcdrak>
jl2012: they could mine an invalid block.. except their relay policy is unlikely to accept an invalid tx.
< gmaxwell>
btcdrak: they'll extend an invalid chain when someone else mines an invalid block.
< btcdrak>
truee
< btcdrak>
well i dont see a solution other than education. it is why we wrote the FAQ
< gmaxwell>
jl2012: in theory the mandatory version increase protected against downgrades, but in practice we found it did the opposite, since miners manually set the version to avoid being orphaned... so not only did it not protect against downgrades, it concealed a lack of true enforcement.
< gmaxwell>
So the expectation with bip9 was that since it was no longer forced there would be no incentive to lie, and at least the measure of upgrade status would be faithful.
< jl2012>
This could be corrected only with education
< btcdrak>
jl2012: i agree
< gmaxwell>
We could introduce signaling elsewhere in the block in locations that miners have not already built infrastructure around faking the values.
< jl2012>
Some miners didn't really understand bip9
< gmaxwell>
This would be systematically safe.
< jl2012>
nlocktime, maybe
< gmaxwell>
Expecting education to work is a losing fight... because we can educate but the parties will continue to rotate out.
< gmaxwell>
nlocktime in coinbase txn perhaps, yes.
< gmaxwell>
(which is where height should have gone, but oh well. :) )
< gmaxwell>
Not that I don't think that we should educate, of course. But its risky to count on that for safty.
< jl2012>
But nlocktime is determined by stratum
< btcdrak>
gmaxwell: in any case for csv miner have upgraded to 0.12.1.
< gmaxwell>
Then can't use that either.
< jl2012>
So they will fake it again
< gmaxwell>
In any case there are many potential places to put it, not something that needs to be figured out now. Any solution would need to be carefully evaluated.
< gmaxwell>
avoiding interaction with any customized infratructure is one reason why mark advocated the dummy transactions for additional commitments.
< btcdrak>
yes was about to say use first tx.
< gmaxwell>
Really the major loss with stratum is that we lost the clean domain of authority layering in the system. Now there isn't a nice boundary where complex consensus details are hidden behind, and where people who don't care about them don't have to worry about them.
< gmaxwell>
With getwork nothing that was up for adjustment really mattered much except changes that would just make your block invalid even to SPV nodes.
< jl2012>
btw, we also need to warn the miners who are using coinbase nSequence as mining nonce
< jl2012>
they must keep the coinbase nVersion as 1 or the block might be orphaned
< sipa>
or above 2^31
< jl2012>
sipa, i.e. negative?
< sipa>
right
< jl2012>
we may need a email to miners to tell them what to double check in the coming 2 weeks
< jl2012>
1. make sure every nodes are upgraded to 0.12.1, and won't somehow fall back to an older version
< jl2012>
2. make sure they will stop signalling CSV at or before block 419328
< jl2012>
(if they are doing that manually)
< jl2012>
3. make sure the coinbase tx compiles with BIP68
< jl2012>
4. make sure the coinbase tx compiles with BIP113 (in case someone use nLockTime for mining --> unlikely)
< jl2012>
anymore?
< jl2012>
s/compiles/complies/
< sipa>
i don't think 68 applies to coinbase inputs
< jl2012>
really? let me check the code
< sipa>
oh, i mean 113
< jl2012>
nlocktime of coinbase is not checked?
< sipa>
it's not an input
< sipa>
and not validated as one
< sipa>
(i think)
< jl2012>
113 is the median-time-past, not OP_CSV
< sipa>
yes, so 113 does not apply to coinbases
< jl2012>
so i can put whatever value in the nLockTime of coinbase and it is still valid?
< sipa>
i am only half awake and should shut up
< sipa>
i may be confusing things
< jl2012>
that's fine :)
< jl2012>
i think all transactions including coinbase are subject to nLockTime and BIP113 rules
< GitHub112>
bitcoin/master fa3b379 MarcoFalke: [qa] pull-tester: Fix assertion and check for run_parallel
< GitHub198>
[bitcoin] laanwj closed pull request #8216: [qa] assert 'changePosition out of bounds' (master...Mf1606-qaFundrawtransaction) https://github.com/bitcoin/bitcoin/pull/8216
< GitHub95>
[bitcoin] jonasschnelli opened pull request #8231: [Qt] fix a bug where the SplashScreen will not be hidden during startup (master...2016/06/qt_min_fix) https://github.com/bitcoin/bitcoin/pull/8231
< MarcoFalke>
./boost/config/posix_features.hpp:18:15: fatal error: 'unistd.h' file not found
< MarcoFalke>
or just merge into master :) if we are confident that the pull is what we want
< MarcoFalke>
it is still running for 30 min
< MarcoFalke>
prob communication overhead with wine?
< MarcoFalke>
but when we get rid of java-blocktester, we need to turn on rpc test for windows in any case
<@wumpus>
I'm confident it is what we want, but I'm afraid of making travis more flakey that's why I'm testing on the pull insted of in master
<@wumpus>
the last thing we want is a flakey travis in the stabilization phase of a release
<@wumpus>
so I'd prefer to merge it later
<@wumpus>
also with cfields_ not here to solve our build system/travis howlers :-)
<@wumpus>
yes, wine clearly has some overhead, it's not clear where and why
<@wumpus>
maybe it's just the bitcoind startup overhead, maybe it's some other delay introduced somewhere
<@wumpus>
(e.g. a polling loop in the test that either connects immediately, otherwise waits a few seconds before trying again)
<@wumpus>
java-blocktester is a worry after the 0.13 release
<@wumpus>
re-based the pull to master
< GitHub137>
[bitcoin] laanwj opened pull request #8233: Mention Linux ARM executables in release process and notes (master...2016_06_release_process_arm) https://github.com/bitcoin/bitcoin/pull/8233
< sipa>
wumpus: there is the abcore project, which uses the arch or debian built arm binaries for bitcoin core on android
< sipa>
wumpus: they cheat, by copying the libstc++ and a few more files from those distributions as well
< sipa>
but still, it seems common arm binaries seem to work with such hacks on android
<@wumpus>
ok, well we'll have to see, I just want to warn people to not get their hopes up that it will work out of the box with android
< sipa>
yes, warning that it's expiremental is obviously needed
<@wumpus>
probably if you 'disguise' your android as a debian box by providing the preerquisite libraries and /etc/ files you can get it to work
< sipa>
right, i'm not suggesting you change the text
<@wumpus>
I'm fine with changing the text, just wouldn't know how to incorporate this without making it too technical
< sipa>
but maybe you were unaware of the approach they used
< sipa>
agree
< sipa>
just giving some background
<@wumpus>
yes, thanks for the background, I didn't know they emulalated
<@wumpus>
"expected to work on Android." -> maybe add as-is in there?
<@wumpus>
pretty clever, it just uses compiler's -ffunction-sections to generate the necessary ELF data, then slices the program up at load time based onthat
< GitHub30>
bitcoin/master e5a680d fanquake: [Doc] Update OS X build notes for 10.11 SDK
< GitHub30>
bitcoin/master 8ccdac1 Wladimir J. van der Laan: Merge #8229: [Doc] Update OS X build notes for 10.11 SDK...
< GitHub127>
[bitcoin] laanwj closed pull request #8229: [Doc] Update OS X build notes for 10.11 SDK (master...osx-build-notes-new) https://github.com/bitcoin/bitcoin/pull/8229
< JackH>
!seen maaku
< gribble>
maaku was last seen in #bitcoin-core-dev 6 weeks, 4 days, 1 hour, 19 minutes, and 54 seconds ago: <maaku> yeah but still, we should try not to add to the noise