< jonasschnelli>
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see NLockTime).
< jonasschnelli>
I guess this is wrong...
< jonasschnelli>
IsFinalTx first checks the nLockTime (0 or < height/time) before checking the nSequence
< jonasschnelli>
if someone confirms I can update the wiki
< wumpus>
jonasschnelli: the function will always return true when all sequence numbers are SEQUENCE_FINAL
< wumpus>
but yes you're right it seems the other way around
< wumpus>
when locktime is 0, or <height/time, the sequence numbers are irrelevant
< wumpus>
hmm the logic as stated there is correct: *iff* all TxIn inputs have final, then no matter what locktime is, it will always be accepted
< wumpus>
if not all TxIn inputs have final, then it depends on the locktime
< wumpus>
it doesn't matter in what order the checks are for that, it can only return true and false after all, and it doesn't matter through which code path it does that
< jonasschnelli>
wumpus: Indeed. Thanks for checking...
< wumpus>
thanks for checking the docs, subtleties like this could result in lost money if they're wrong
< jonasschnelli>
I guess a confusing element is that a tx can pass IsFinalTx() (in therefore has the term "final") even if it can be replaced by opt-in-RBF/BIP125
< wumpus>
right - opt-in RBF is essentially a separate thing from finalness, even though it uses the sequence field too
< da2ce7>
Is the fact that Bitcoin is under active exploit by the asicboost vulnerably a important consideration for the urgency of BIP148?
< da2ce7>
I would suggest that it should be at least something to consider.
< da2ce7>
Many developers have stated that they think that BIP148 is rushed, but remain silent on the fact that Bitcoin is under active exploit.
< da2ce7>
I have gained no negative responses to my post on the mailing list about classifying asicboost as a Security Vulnerability. Yet BIP148, a rapidly deployed partial-fix is rejected by many for being 'too rushed'. I would suggest that any developers who states why it is 'too rushed' should state how the ongoing exploit of covert asicboost is the safer option.
< wumpus>
it's a difficult compromise
< wumpus>
it can still be too rushed, even if it addresses an immediate vulnerability; it depends on what outcome is worse, having stealth asicboost run for a few months longer (while BIP149 is being deployed) or a game of BIP148 chicken (which seems unavoidable in any case...).
< timothy>
da2ce7: why asicboot is a vulnerability?
< da2ce7>
wumpus, I agree: BIP148 may be, even then, too rushed (but I personally believe BIP148 is the safest option available, as I think there is a dramatic under estimation the damage of asicboost to Bitcoin). However, I haven't seen this considered in any of the significant anti-BIP148 responses to the mailing list. Centrally not an analysis of the tradeoffs available.
< da2ce7>
for example gmaxwell states on multiple occasions "we should not rush", but doesn't expand upon this statement in the context of an actively exploited security vulnerability.
< wumpus>
"I think there is a dramatic under estimation the damage of asicboost to Bitcoin" in what way? because they overrepresent themselves, resulting in more mining centralization than would otherwise be the case?
< da2ce7>
Because it demands that in a short time, the only profitable miners are the miners who implement asicbosot.
< da2ce7>
One of the critical security properties of bitcoin is a well-distributed set of miners. AsicBoost dramatically breaks this assumtion.
< da2ce7>
Not even to mention the perverse incentives by the massive layer violations that asicboost encourages.
< da2ce7>
The choice of the ordering of transactions should have NO effect on the performance of a miner.
< timothy>
I think many ASICBOOST miners doesn't want soft-fork for asciboost itself
< da2ce7>
To me, it is clear why many miners don't like SegWit, because it breaks Covert AsicBoost. This is a feature, not a bug, of SegWit. However it is just the first step of putting AsicBoost into the grave.
< da2ce7>
People will assume, quite correctly imho, that if you mine a non-segwit block, you are using AsicBoost.
< Lauda>
BIP148 is much better due to compatibility, indeed.
< jtimon>
luke-jr: "BIP 149 is the opposite: it leaves the question of successful softfork open until some unknown future point" I don't think this is correct
< bitcoin-git>
bitcoin/master 2a8e35a Russell Yanofsky: Fix importwallet edge case rescan bug...
< bitcoin-git>
bitcoin/master e76a392 Wladimir J. van der Laan: Merge #10410: Fix importwallet edge case rescan bug...
< jtimon>
"BIP 148 is backward-compatible with segwit as already deployed in 0.13.1-0.14.1." so is bip149, bip149 is actually compatbile with pre-0.13 too
< luke-jr>
I think what I said there is perfectly clear.
< jtimon>
luke-jr: hos is 4 July 2018 UTC (Epoch timestamp 1530662400) " some unknown future point" ?
< luke-jr>
jtimon: that's not when you'd find out
< jtimon>
luke-jr: it can be made earlier by miners, that's true for bip148 as well
< luke-jr>
jtimon: with a BIP148-style *UASF*, you don't find out the outcome until a miner tries to steal segwit funds
< jtimon>
"there are plenty of "sharp edges" that could be encountered if we need to do it for segwit" what are those "sharp edges"? how don't they apply with the current bip9 deployment with respect to pre-sw nodes?
< luke-jr>
jtimon: re-deployment
< luke-jr>
pre-sw nodes don't *think* they know segwit
< jtimon>
"Very little research has been done into the work required to successfully and safely re-deploy segwit. " we knew bip9 deployments could be tried again if failed, I don't know what kind of research you want
< luke-jr>
yes, in general; but segwit is more complicated than merely another bip9 deployment
< jtimon>
pre-bip149 won't think segwit is activated
< luke-jr>
you need to ensure that
< jtimon>
I really see nothing special about redeployment
< jtimon>
you need to ensure what?
< luke-jr>
then you haven't thought it through
< jtimon>
happy to learn
< luke-jr>
you need to ensure 0.13.1-0.14.1 never get the witness data
< luke-jr>
which they will try to do
< jtimon>
not until activation
< jtimon>
if the bip9 activation gets in, great, if not, that won't happen for pre-bip149 nodes, what am I missing?
< bitcoin-git>
bitcoin/master 399fb8f Matt Corallo: Add internal method to add new random data to our internal RNG state
< bitcoin-git>
bitcoin/master 888cce5 Matt Corallo: Add perf counter data to GetStrongRandBytes state in scheduler
< bitcoin-git>
bitcoin/master 15254e9 Wladimir J. van der Laan: Merge #10372: Add perf counter data to GetStrongRandBytes state in scheduler...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10372: Add perf counter data to GetStrongRandBytes state in scheduler (master...2017-05-scheduler-rng) https://github.com/bitcoin/bitcoin/pull/10372
< gmaxwell>
Why does the test framework have seperate init code for a 'clean' chain vs not? I would have expected it to have a single clean init and then one or more standard setup functions.
< gmaxwell>
The way it's constructed now makes it hard to use the standard setup but perform some tests before it happens.
< gmaxwell>
E.g. I want to make the gettxoutsetinfo test also run before the setup and verify that the txout set starts empty.
< sipa>
you can write a test that doesn't use the default state, iirc?
< gmaxwell>
yes, but then you can't get the default state. so it's hard to write a test that does both. just seemed odd.
< jnewbery>
probably because _initialize_chain() is copying the datadir from the cache (or creating a new one if it doesn't exist). If you ran it after your initial tests, it'd break all your assumptions
< bitcoin-git>
[bitcoin] gmaxwell opened pull request #10445: Add test for empty chain and reorg consistency for gettxoutsetinfo. (master...test_more_gettxoutset) https://github.com/bitcoin/bitcoin/pull/10445
< gmaxwell>
oh that would be a good reason why, caching.