1 2017-05-23 09:47:33	0|jonasschnelli|The protocol wiki "https://en.bitcoin.it/wiki/Protocol_documentation" says:
 2 2017-05-23 09:47:34	0|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).
 3 2017-05-23 09:47:44	0|jonasschnelli|I guess this is wrong...
 4 2017-05-23 09:48:09	0|jonasschnelli|IsFinalTx first checks the nLockTime (0 or < height/time) before checking the nSequence
 5 2017-05-23 09:48:17	0|jonasschnelli|if someone confirms I can update the wiki
 6 2017-05-23 10:22:05	0|wumpus|jonasschnelli: the function will always return true when all sequence numbers are SEQUENCE_FINAL
 7 2017-05-23 10:23:08	0|wumpus|but yes you're right it seems the other way around
 8 2017-05-23 10:23:40	0|wumpus|when locktime is 0, or <height/time, the sequence numbers are irrelevant
 9 2017-05-23 10:25:18	0|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
10 2017-05-23 10:26:11	0|wumpus|if not all TxIn inputs have final, then it depends on the locktime
11 2017-05-23 10:27:22	0|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
12 2017-05-23 10:31:11	0|jonasschnelli|wumpus: Indeed. Thanks for checking...
13 2017-05-23 10:32:12	0|wumpus|thanks for checking the docs, subtleties like this could result in lost money if they're wrong
14 2017-05-23 10:43:58	0|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
15 2017-05-23 10:59:36	0|wumpus|right - opt-in RBF is essentially a separate thing from finalness, even though it uses the sequence field too
16 2017-05-23 13:34:30	0|da2ce7|Is the fact that Bitcoin is under active exploit by the asicboost vulnerably a important consideration for the urgency of BIP148?
17 2017-05-23 13:34:54	0|da2ce7|I would suggest that it should be at least something to consider.
18 2017-05-23 13:35:30	0|da2ce7|Many developers have stated that they think that BIP148 is rushed, but remain silent on the fact that Bitcoin is under active exploit.
19 2017-05-23 13:38:54	0|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.
20 2017-05-23 13:44:54	0|wumpus|it's a difficult compromise
21 2017-05-23 13:47:10	0|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...).
22 2017-05-23 13:47:58	0|timothy|da2ce7: why asicboot is a vulnerability?
23 2017-05-23 13:49:38	0|da2ce7|timothy please see: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014349.html and the followup: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014353.html
24 2017-05-23 13:55:23	0|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.
25 2017-05-23 13:56:50	0|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.
26 2017-05-23 13:56:58	0|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?
27 2017-05-23 13:57:41	0|da2ce7|Because it demands that in a short time, the only profitable miners are the miners who implement asicbosot.
28 2017-05-23 13:58:35	0|da2ce7|One of the critical security properties of bitcoin is a well-distributed set of miners. AsicBoost dramatically breaks this assumtion.
29 2017-05-23 13:59:33	0|da2ce7|Not even to mention the perverse incentives by the massive layer violations that asicboost encourages.
30 2017-05-23 14:00:01	0|da2ce7|The choice of the ordering of transactions should have NO effect on the performance of a miner.
31 2017-05-23 14:04:26	0|timothy|I think many ASICBOOST miners doesn't want soft-fork for asciboost itself
32 2017-05-23 14:07:18	0|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.
33 2017-05-23 14:08:04	0|da2ce7|People will assume, quite correctly imho, that if you mine a non-segwit block, you are using AsicBoost.
34 2017-05-23 14:08:32	0|da2ce7|Making it quite conspicuous.
35 2017-05-23 14:37:40	0|luke-jr|jtimon: here is where I explain why BIP 149 is less safe (among other issues) vs BIP 148: https://www.reddit.com/r/Bitcoin/comments/69dm8e/what_is_segregated_witness_explanation_for/dh6dg3z/
36 2017-05-23 14:38:39	0|Lauda|BIP148 is much better due to compatibility, indeed.
37 2017-05-23 14:39:02	0|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
38 2017-05-23 14:39:32	0|luke-jr|jtimon: well, it is.
39 2017-05-23 14:39:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e4775167cb4b...e76a3927c3b0
40 2017-05-23 14:39:51	0|bitcoin-git|13bitcoin/06master 142a8e35a 15Russell Yanofsky: Fix importwallet edge case rescan bug...
41 2017-05-23 14:39:51	0|bitcoin-git|13bitcoin/06master 14e76a392 15Wladimir J. van der Laan: Merge #10410: Fix importwallet edge case rescan bug...
42 2017-05-23 14:40:05	0|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
43 2017-05-23 14:40:32	0|luke-jr|I think what I said there is perfectly clear.
44 2017-05-23 14:40:35	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10410: Fix importwallet edge case rescan bug (06master...06pr/scanimp) 02https://github.com/bitcoin/bitcoin/pull/10410
45 2017-05-23 14:41:03	0|jtimon|luke-jr: hos is  4 July 2018 UTC (Epoch timestamp 1530662400) " some unknown future point" ?
46 2017-05-23 14:41:22	0|luke-jr|jtimon: that's not when you'd find out
47 2017-05-23 14:42:05	0|jtimon|luke-jr: it can be made earlier by miners, that's true for bip148 as well
48 2017-05-23 14:42:28	0|luke-jr|jtimon: with a BIP148-style *UASF*, you don't find out the outcome until a miner tries to steal segwit funds
49 2017-05-23 14:43:14	0|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?
50 2017-05-23 14:43:46	0|luke-jr|jtimon: re-deployment
51 2017-05-23 14:43:56	0|luke-jr|pre-sw nodes don't *think* they know segwit
52 2017-05-23 14:44:06	0|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
53 2017-05-23 14:44:39	0|jtimon|pre-bip149 won't think segwit is activated
54 2017-05-23 14:44:39	0|luke-jr|yes, in general; but segwit is more complicated than merely another bip9 deployment
55 2017-05-23 14:45:02	0|luke-jr|you need to ensure that
56 2017-05-23 14:45:12	0|jtimon|I really see nothing special about redeployment
57 2017-05-23 14:45:24	0|jtimon|you need to ensure what?
58 2017-05-23 14:45:26	0|luke-jr|then you haven't thought it through
59 2017-05-23 14:45:36	0|jtimon|happy to learn
60 2017-05-23 14:45:48	0|luke-jr|you need to ensure 0.13.1-0.14.1 never get the witness data
61 2017-05-23 14:45:52	0|luke-jr|which they will try to do
62 2017-05-23 14:46:03	0|jtimon|not until activation
63 2017-05-23 14:46:51	0|jtimon|if the bip9 activation gets in, great, if not, that won't happen for pre-bip149 nodes, what am I missing?
64 2017-05-23 15:10:25	0|bitcoin-git|13bitcoin/060.14 14321419b 15Russell Yanofsky: Fix importwallet edge case rescan bug...
65 2017-05-23 15:10:25	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/321419bc06fdc19e3713b2bcfc10c3c9bbbb8b62
66 2017-05-23 16:45:50	0|bitcoin-git|13bitcoin/06master 14399fb8f 15Matt Corallo: Add internal method to add new random data to our internal RNG state
67 2017-05-23 16:45:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e76a3927c3b0...15254e907e8c
68 2017-05-23 16:45:51	0|bitcoin-git|13bitcoin/06master 14888cce5 15Matt Corallo: Add perf counter data to GetStrongRandBytes state in scheduler
69 2017-05-23 16:45:52	0|bitcoin-git|13bitcoin/06master 1415254e9 15Wladimir J. van der Laan: Merge #10372: Add perf counter data to GetStrongRandBytes state in scheduler...
70 2017-05-23 16:46:24	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10372: Add perf counter data to GetStrongRandBytes state in scheduler (06master...062017-05-scheduler-rng) 02https://github.com/bitcoin/bitcoin/pull/10372
71 2017-05-23 16:46:50	0|bitcoin-git|13bitcoin/06master 14433c57a 15Wladimir J. van der Laan: Merge #10421: [qt] Remove excess logic: Prefer "return foo;" to "if (foo) { return true; } else { return false; }"...
72 2017-05-23 16:46:50	0|bitcoin-git|13bitcoin/06master 14e49b868 15practicalswift: [qt] Remove excess logic...
73 2017-05-23 16:46:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/15254e907e8c...433c57aa6f30
74 2017-05-23 16:47:23	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10421: [qt] Remove excess logic: Prefer "return foo;" to "if (foo) { return true; } else { return false; }" (06master...06if-expr-return-true-else-return-false) 02https://github.com/bitcoin/bitcoin/pull/10421
75 2017-05-23 16:52:35	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10336: Get actual path for EUID instead of HOME dir (06master...06contrib) 02https://github.com/bitcoin/bitcoin/pull/10336
76 2017-05-23 17:12:53	0|bitcoin-git|13bitcoin/06master 14557c9a6 15Matthew Zipkin: RPC: getblockchaininfo: BIP9 stats...
77 2017-05-23 17:12:53	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/433c57aa6f30...46771514fa86
78 2017-05-23 17:12:54	0|bitcoin-git|13bitcoin/06master 144677151 15Wladimir J. van der Laan: Merge #9571: RPC: getblockchaininfo returns BIP signaling statistics...
79 2017-05-23 17:40:13	0|bitcoin-git|13bitcoin/06master 145844609 15practicalswift: [net] Avoid initialization to a value that is never read...
80 2017-05-23 17:40:13	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ce8176d0389c...7e96ecf075e8
81 2017-05-23 17:40:14	0|bitcoin-git|13bitcoin/06master 147e96ecf 15Wladimir J. van der Laan: Merge #9539: [net] Avoid initialization to a value that is never read...
82 2017-05-23 18:44:23	0|bitcoin-git|[13bitcoin] 15pinheadmz closed pull request #10385: RPC: getblock returns coinbase scriptsig (06master...06cbtext) 02https://github.com/bitcoin/bitcoin/pull/10385
83 2017-05-23 19:33:50	0|ryanofsky|could 10244 be swapped for 10295 in the review list https://github.com/bitcoin/bitcoin/projects/8, since 10295 is now merged?
84 2017-05-23 21:36:19	0|bitcoin-git|13bitcoin/06master 14cb184b3 15Gregory Sanders: Add constant for maximum stack size
85 2017-05-23 21:36:19	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f2f7e97e8cc2...4cb8757aae1a
86 2017-05-23 21:36:20	0|bitcoin-git|13bitcoin/06master 144cb8757 15Pieter Wuille: Merge #10313: [Consensus] Add constant for maximum stack size...
87 2017-05-23 21:36:57	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10313: [Consensus] Add constant for maximum stack size (06master...06stackconst) 02https://github.com/bitcoin/bitcoin/pull/10313
88 2017-05-23 21:49:03	0|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.
89 2017-05-23 21:49:21	0|gmaxwell|The way it's constructed now makes it hard to use the standard setup but perform some tests before it happens.
90 2017-05-23 21:50:07	0|gmaxwell|E.g. I want to make the gettxoutsetinfo test also run before the setup and verify that the txout set starts empty.
91 2017-05-23 21:50:45	0|sipa|you can write a test that doesn't use the default state, iirc?
92 2017-05-23 21:51:19	0|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.
93 2017-05-23 22:00:06	0|gmaxwell|I'll just reorg back...
94 2017-05-23 22:09:48	0|bitcoin-git|[13bitcoin] 15jameshilliard opened pull request #10444: Implement BIP91 Reduced threshold Segwit MASF (060.14...06segsignal-v0.14.1) 02https://github.com/bitcoin/bitcoin/pull/10444
95 2017-05-23 22:11:06	0|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
96 2017-05-23 22:11:18	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #10445: Add test for empty chain and reorg consistency for gettxoutsetinfo. (06master...06test_more_gettxoutset) 02https://github.com/bitcoin/bitcoin/pull/10445
97 2017-05-23 22:13:26	0|gmaxwell|oh that would be a good reason why, caching.
98 2017-05-23 22:13:26	0|gmaxwell|okay.