1 2015-09-30 00:00:33 <maaku> jgarzik: set the most significant bit and you'll be fine
  2 2015-09-30 00:00:44 <maaku> let me know if you need a review on anything
  3 2015-09-30 00:04:07 <jgarzik> maaku, well that doesn't work for deployed software ;p
  4 2015-09-30 00:04:37 <jgarzik> maaku, not a NAK by any stretch, just data point.  most likely ACK as I said
  5 2015-09-30 00:13:11 <phantomcircuit> jgarzik, you're using the sequence number field for something other than sequence numbers?
  6 2015-09-30 00:51:05 <rusty> maaku: UpdateTime sets block timestamps to  std::max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime()) so blocks are always valid.
  7 2015-09-30 00:51:43 <rusty> maaku: so, in practice blocks may be in the "future" already.  I will do proper math in my script based on best block timestamp, see if thaat helps.
  8 2015-09-30 00:52:19 <maaku> rusty: let me know how it goes
  9 2015-09-30 00:52:34 <maaku> I'm surprised that you were getting blocks with the same timestamp however..
 10 2015-09-30 00:54:45 <rusty> maaku: easy, just generate more than 1 per second.
 11 2015-09-30 00:56:35 <maaku> rusty: ah right of course, you'd get 6 consecutive blocks before the GetMedianTimePast()+1 forces an increment
 12 2015-09-30 00:56:48 <maaku> silly me for thinking it would happen every block
 13 2015-09-30 00:57:05 <rusty> maaku: yeah, I got suspicious when I dumped everything and saw it aways *just* missed violating...
 14 2015-09-30 00:57:14 <maaku> potentially more than 6 if your timestamps are out of order..
 15 2015-09-30 01:08:34 <rusty> maaku: got it!  That 13/14 seconds is how far ahead the block timestamps are from reality after generating ~100 blocks (so I can spend the first coinbase).
 16 2015-09-30 01:09:35 <maaku> rusty: sounds about right -- 100/6 = 16
 17 2015-09-30 01:10:16 <rusty> maaku: thanks for the clue donation; without your hint who knows how long it would ahve taken me!  Running final checks now.
 18 2015-09-30 01:16:21 <rusty> maaku: posted retraction and added Tested-by to PR.
 19 2015-09-30 01:16:28 <maaku> thanks!
 20 2015-09-30 01:17:16 <rusty> maaku: sorry for false alarm.  Alpha didn't have this problem, because I didn't generate 100 blocks on alpha: didn't need to, to spend coinbase.
 21 2015-09-30 01:17:31 <maaku> right. no worries!
 22 2015-09-30 01:20:26 <rusty> CodeShark / CodeShark_: sipa talked versionbits with me.  Will post on ML, but I like the idea of continuing to set the bit until activation.  At least that gives us visibility into how the last 5% are going with their upgrades.
 23 2015-09-30 01:21:22 <rusty> And also will clarify, that if top bits are not 001, all version bits should be considered unset.
 24 2015-09-30 01:46:27 <CodeShark_> hey rusty
 25 2015-09-30 01:46:39 <rusty> CodeShark_ Hey, how's versionbits?
 26 2015-09-30 01:46:44 <CodeShark_> it's going pretty well
 27 2015-09-30 01:47:15 <CodeShark_> so I'm thinking there are a total of five possible states: enum { DEFINED, LOCKED_IN, ACTIVATED, FINAL, FAILED };
 28 2015-09-30 01:47:44 <rusty> CodeShark_: FINAL?
 29 2015-09-30 01:48:17 <CodeShark_> during DEFINED, it's entirely optional whether or not to set the bit - once we transition to LOCKED_IN, activation is imminent...but setting the bit is still not enforced
 30 2015-09-30 01:48:40 <CodeShark_> once we reach ACTIVATED, setting the bit is required for one full interval (2016)
 31 2015-09-30 01:48:48 <jgarzik> phantomcircuit, I know of software using it for monotonically increasing sequence numbers.  As I noted to maaku I just don't know enough to know about the impact yet.
 32 2015-09-30 01:48:56 <CodeShark_> then after that it goes to FINAL, where the bit is available to be reuse
 33 2015-09-30 01:48:58 <CodeShark_> *reused
 34 2015-09-30 01:49:17 <CodeShark_> it can only be set if there's another soft fork defined that uses that bit
 35 2015-09-30 01:49:59 <CodeShark_> we should also define a DEFINED height
 36 2015-09-30 01:50:05 <CodeShark_> the point at which it's ok to start setting the bit
 37 2015-09-30 01:50:33 <rusty> CodeShark_ sipa told me that suggestion, so we deprecate blocks from non-upgraded nodes.  I'm not convinced.
 38 2015-09-30 01:50:51 <CodeShark_> what do you mean?
 39 2015-09-30 01:51:34 <rusty> CodeShark_: He suggested that activation create a consensus rule that the bit must be set.
 40 2015-09-30 01:52:01 <CodeShark_> upon activation, I think we should require the bit be set for at least a little while
 41 2015-09-30 01:52:18 <CodeShark_> consider BIP66...imagine if right after activation the version would have reverted to 2
 42 2015-09-30 01:52:41 <CodeShark_> it would have taken us some time to realize that miners were not enforcing the new rule
 43 2015-09-30 01:52:57 <CodeShark_> and it might have required engineering a block to detect it
 44 2015-09-30 01:53:04 <maaku> CodeShark_: rusty makes a good point that the most straightforward implementation would make this a consensus rule when in fact BIP 9 otherwise has no consensus changes
 45 2015-09-30 01:53:06 <rusty> CodeShark_: well, I'm optimistic that the 2 week delay will catch the laggards.  But I do approve of modifying BIP to set bit during LOCKED_IN, so we can tell.
 46 2015-09-30 01:53:31 <CodeShark_> not that we can really check whether the rule is being enforced - but at least we can check whether they are acknowledging that a rule change occured
 47 2015-09-30 01:54:15 <CodeShark_> problem with requiring setting during LOCKED_IN is that the LOCKED_IN transition becomes a soft fork in itself
 48 2015-09-30 01:54:16 <maaku> one possible way around that technicality is to make it enforcement of the locked-in bit setting to be an optional command line flag
 49 2015-09-30 01:54:27 <rusty> CodeShark_: we can add this in future if we find that actually, miners are ignoring all warnings and we want to get harsher.
 50 2015-09-30 01:54:40 <CodeShark_> what's the downside to having this feature?
 51 2015-09-30 01:54:41 <rusty> CodeShark_: no, you keep setting it, but don't enforce it.
 52 2015-09-30 01:55:06 <maaku> fwiw this basically is saying we'll pre-emptively fork off laggards at a known time, rather than at an unknown time when when a previously valid, now invalid tx is mined
 53 2015-09-30 01:55:10 <rusty> CodeShark_: adds complexity, introduces a new consensus rule, and it can be added later.
 54 2015-09-30 01:55:48 <rusty> maaku: well, if it's current best practice, new txs will be non-standard, so miner will just not be fully validating.  They won't fork off.
 55 2015-09-30 01:55:59 <maaku> CodeShark_: having this feature, as suggested by sipa where it is actually enforced, means implementation of BIP 9 now touches consensus code -- not setting the bit is a reason block validation can fail
 56 2015-09-30 01:56:17 <maaku> rusty: non-standard doesn't mean it can't appear in a block
 57 2015-09-30 01:56:27 <CodeShark_> the requirement doesn't occur until the soft fork is activated
 58 2015-09-30 01:56:48 <CodeShark_> so the requirement to set the bit occurs at the same block as the soft fork is activated...so it's not two separate soft forks
 59 2015-09-30 01:56:57 <rusty> maaku: yeah, but if you don't understand a soft fork, your only danger is that *you* might mine an invalid block.
 60 2015-09-30 01:57:36 <rusty> maaku: this suggestion would break them deliberately, and I think that's  a little harsh.  We can always do that in future (hey, using a version bit!)
 61 2015-09-30 01:58:46 <CodeShark_> the other alternative is to not require setting the bit during LOCKED_IN...but strongly encourage it...then if suddenly the support apparently drops below 95% perhaps we should start worrying...but I like the idea of forking off anyone who doesn't acknowledge the rule change
 62 2015-09-30 01:58:56 <CodeShark_> at ACTIVATION
 63 2015-09-30 01:59:32 <CodeShark_> why do you think it's too harsh?
 64 2015-09-30 01:59:42 <CodeShark_> it's really no different than requiring version 3 after BIP66
 65 2015-09-30 01:59:47 <rusty> CodeShark_: too harsh for now.  But yes, implementation should set bit during LOCKED_IN so we can measure uptake.
 66 2015-09-30 01:59:53 <CodeShark_> except that after 2016 blocks we turn off the bit so it can be reused
 67 2015-09-30 02:00:59 <CodeShark_> remember that the BIP66 fork occured not because miners weren't setting the bit - it occured because they DID set the bit...but continued to mine on top of blocks that didn't
 68 2015-09-30 02:01:40 <rusty> CodeShark_: yeah, which points to it being silly to insist on the bits since they'll just set the bit blindly to keep mining, so we've added complexity for no win.
 69 2015-09-30 02:01:47 <maaku> it may actually be more useful to have it be non-enforced -- absentee mining pools might not notice a stale block
 70 2015-09-30 02:02:19 <maaku> but everyone will look for and complain loudly if someone is still making non-commitment blocks post-fork
 71 2015-09-30 02:03:12 <rusty> CodeShark_: it's a line ball, and so I'm calling in favour of the current version.  But am preparing patch to bip to keep setting bit during locked-in, for better monitoring.
 72 2015-09-30 02:03:27 <CodeShark_> ultimately, we don't really have a way of making sure miners are enforcing the new rules...which is the real problem
 73 2015-09-30 02:03:30 <rusty> gmaxwell / petertodd / sipa may disagree.
 74 2015-09-30 02:03:52 <rusty> CodeShark_: pay miners to generate bad blocks, but yeah...
 75 2015-09-30 02:04:59 <maaku> well for what it's worth, my vote is on 2016 block window where setting the bit is requested but not enforced, just to measure uptake
 76 2015-09-30 02:06:12 <CodeShark_> we have that regardless - I think even if we require setting the bit for a full interval after activation we should request but not enforce the bit during LOCKED_IN
 77 2015-09-30 02:06:59 <CodeShark_> I would like miners to explicitly acknowledge the transition somehow, though - but I'd like to hear others' opinions
 78 2015-09-30 02:07:18 <CodeShark_> either way, I can still make progress on implementation
 79 2015-09-30 02:07:31 <CodeShark_> it's really not that hard to change that one way or another
 80 2015-09-30 02:09:05 <rusty> CodeShark_ thanks... am posting now.
 81 2015-09-30 02:10:55 <CodeShark_> rusty, I think we should start the document with a list of parameters that define the fork
 82 2015-09-30 02:11:16 <CodeShark_> one that I think is missing is the definition height - that's to say, the height after which it's ok to start setting the bit
 83 2015-09-30 02:11:29 <rusty> CodeShark_: BTW, we don't need a defined start.  That's implied by drafting.
 84 2015-09-30 02:11:45 <CodeShark_> implementations have to know about it, though
 85 2015-09-30 02:11:55 <rusty> Or whatever out-of-band mechanism is used to choose bits.
 86 2015-09-30 02:12:06 <rusty> (Currently, I'm happy to volunteer)
 87 2015-09-30 02:12:22 <CodeShark_> and we cannot start setting a bit until it's already been retired - so I think it would be a good idea to specify a definition height to ensure we don't overlap any bits
 88 2015-09-30 02:12:28 <aj> bits have to be assigned / globally coordinated like BIP numbers, right?
 89 2015-09-30 02:12:32 <CodeShark_> yes
 90 2015-09-30 02:12:46 <CodeShark_> unfortunately we don't have a decentralized solution for that, aj ;)
 91 2015-09-30 02:13:45 <maaku> ultimately it is humans and human coordination that moves bitcoin forward
 92 2015-09-30 02:13:53 <maaku> solving that is an AGI-complete problem ;)
 93 2015-09-30 02:14:16 <rusty> CodeShark_: We need to watch the network, too, to judge the noise floor.  IT's not currently definable.
 94 2015-09-30 02:15:00 <CodeShark_> so if we do not define a minimum height, basically immediately upon assignment of a bit anyone can start setting it?
 95 2015-09-30 02:15:10 <CodeShark_> might not give everyone enough time to upgrade
 96 2015-09-30 02:16:07 <rusty> CodeShark_: well, they'll have at least 4 weeks (block time), right?
 97 2015-09-30 02:16:41 <rusty> CodeShark_: and almost by definition, if 95% of miners have set the bit, they had enough time :)
 98 2015-09-30 02:17:04 <CodeShark_> I figure after the assignment is accepted by the community, we specify a height after which people can start setting it. 2016 blocks is around two weeks in theory, no?
 99 2015-09-30 02:18:25 <CodeShark_> we should have miners start setting it at the start of a 2016 interval
100 2015-09-30 02:18:32 <CodeShark_> no?
101 2015-09-30 02:19:13 <rusty> CodeShark_: No, as soon as the software supports the softfork, start setting it.
102 2015-09-30 02:19:47 <rusty> CodeShark_: I'm assuming the bit number will be specified in the corresponding BIP.
103 2015-09-30 02:20:08 <CodeShark_> yes, but it should not be assigned until implementations are ready, in that case
104 2015-09-30 02:20:43 <rusty> CodeShark_: sure, there needs to be some discretion as they are a limited resouce.
105 2015-09-30 02:21:23 <CodeShark_> yes...and there needs to be a decent amount of support from the community (although we have no good metric on this)
106 2015-09-30 02:22:01 <CodeShark_> and preferably it should be basically uncontroversial
107 2015-09-30 02:22:42 <CodeShark_> but that's a very high standard
108 2015-09-30 02:23:05 <CodeShark_> the technical mechanism is the easy part - the hard part is the politics ;)
109 2015-09-30 02:23:09 <rusty> CodeShark_: yeah.  In practice, requirements will be loose until we start running out of bits :)
110 2015-09-30 02:25:41 <CodeShark_> if a particular BIP is unlikely to get 95% support, it could leave us in limbo for a fairly long time...and cost us a bit the entire time
111 2015-09-30 02:26:05 <rusty> CodeShark_ Yes, it would slow us to a soft fork every 5 weeks.
112 2015-09-30 02:26:40 <CodeShark_> has the idea of expiring the BIP early if support drops below a certain amount before a certain time been much discussed?
113 2015-09-30 02:26:47 <CodeShark_> i.e. it can have two expirations
114 2015-09-30 02:26:50 <rusty> CodeShark_: Yeah, again, complexity.
115 2015-09-30 02:28:37 <CodeShark_> but the logic can be nicely encapsulated into a clean library
116 2015-09-30 02:28:52 <CodeShark_> doesn't have to be reimplemented for each BIP :p
117 2015-09-30 02:29:46 <rusty> CodeShark_: In practice, the two thresholds would be the same.  You wouldn't want it less than 2 years, because implementation might be slow.
118 2015-09-30 02:30:16 <CodeShark_> if support levels off at 60% for a period of several months and shows no sign of increasing, do we really want to wait 2 years?
119 2015-09-30 02:30:42 <rusty> CodeShark_: Yes.
120 2015-09-30 02:31:03 <rusty> CodeShark_: And any sane proposal for a timeout would not kick in at 60%, anyway.
121 2015-09-30 02:31:04 <CodeShark_> that means for 2 years we have to design everything taking this limbo into account
122 2015-09-30 02:31:28 <rusty> CodeShark_: Oh yeah.  Failed soft forks are gonna hurt.  But the loss of a bit is the least of it.
123 2015-09-30 02:31:47 <CodeShark_> the way I see it, unless a BIP gains rapid support in a short period of time, it's probably not worth doing - because two years later it's likely we have even better ideas
124 2015-09-30 02:32:38 <CodeShark_> perhaps we figure out a better solution to a problem - and maybe two potential soft forks can be accomplished with one
125 2015-09-30 02:33:15 <CodeShark_> and if even a year from now it continues to be a good idea, we can always reintroduce it
126 2015-09-30 02:35:48 <CodeShark_> or put another way...if it is going to take some time to build consensus on it, perhaps wait to introduce it once we've gotten that consensus
127 2015-09-30 02:36:38 <CodeShark_> I can already see people creating prediction markets on it - lol
128 2015-09-30 02:38:54 <CodeShark_> for highly technical, relatively uncontroversial soft forks, it will mostly amount to default settings
129 2015-09-30 02:39:31 <CodeShark_> the problem is the highly contentious one that never gets above 60% support
130 2015-09-30 02:40:05 <CodeShark_> or worse
131 2015-09-30 02:41:02 <CodeShark_> the miner "voting" mechanism until now has been more a matter of trying to make sure enough people have upgraded than it has been really a matter of giving miners choice
132 2015-09-30 02:42:09 <CodeShark_> if the "voting" were over contentious changes...especially ones with asymmetric economic consequences...I think we're in uncharted territory
133 2015-09-30 02:43:16 <CodeShark_> and having the support swing wildly but never stably approach 100% could be harmful to the network
134 2015-09-30 02:49:10 <CodeShark_> if only the human element were as simple as the coding ;)
135 2015-09-30 02:55:46 <CodeShark_> before version bits, the ability to retire and reintroduce a soft fork was pretty much out of the question because of the pipeline nature of it...but with version bits it seems like an entirely sensible dynamic
136 2015-09-30 02:55:51 <bitcoindoubler> double your bitcoin send any amount to 1DqNhnQFoDueQuHEVf1vv3L8YqLUXmeajX and get double back been working for me all night
137 2015-09-30 02:56:05 <CodeShark_> offtopic...and potentially illegal
138 2015-09-30 02:56:57 <bitcoindoubler> double your bitcoin send any amount to 1DqNhnQFoDueQuHEVf1vv3L8YqLUXmeajX and get double back been working for me all night
139 2015-09-30 07:11:46 <flound1129> does 0.12 support pruning with wallet enabled?
140 2015-09-30 07:12:34 <flound1129> *will
141 2015-09-30 07:18:38 <Luke-Jr> flound1129: likely
142 2015-09-30 07:19:03 <Luke-Jr> (but please use #bitcoin for this kind of question, not #bitcoin-dev )
143 2015-09-30 15:49:18 <jgarzik> warren, any update on list?
144 2015-09-30 15:49:58 <jgarzik> warren, given the creation of #bitcoin-core-dev on IRC, maybe we want bitcoin-dev@ for protocol development and bitcoin-core-dev@ focused specifically on Bitcoin Core reference implementation software technical stuff.
145 2015-09-30 15:50:07 <jgarzik> channel, ^
146 2015-09-30 16:48:05 <maaku> channel proliferation is not good :(
147 2015-09-30 16:48:56 <ProfMac> It seems very quiet at the moment.  Did everybody go somewhere else?
148 2015-09-30 16:52:12 <maaku> ProfMac: yes they all went to #bitcoin-core-dev
149 2015-09-30 16:53:09 <jcorgan> yes, the productive people escaped there to remain productive
150 2015-09-30 17:13:00 <maaku> jcorgan: the osterich approach may be desireable but builds long-term problems
151 2015-09-30 17:20:18 <maaku> communication is hard, but choosing not to communicate is harder
152 2015-09-30 17:32:46 <ProfMac> I joined #bitcoin-core-dev and don't see any traffic.  Is there a secret handshake?
153 2015-09-30 21:28:36 <bad_duck> j'ai vu 2 épisosdes d'uné série qui s'appelle "drug inc"
154 2015-09-30 21:29:25 <bad_duck> c'est "national geographic" qui diffuse ça
155 2015-09-30 21:30:19 <bad_duck> bon j'pense que la moitié des docs c'est sur le paumé qui prend du crack dans les coins défafirisés / quartier pauvres des US
156 2015-09-30 21:31:09 <bad_duck> mais c'est marrant, j'ai vu un épisode sur le jamaique... ça a l'air sympa la bas à kingston (ironie inside)
157 2015-09-30 21:55:51 <fronti> je ne comprend pas "marrent"
158 2015-09-30 22:08:07 <michagogo> bad_duck: Je ne parle pas français, mais en fonction de ce que vous avez dit, je pense que vous êtes au mauvais endroit.
159 2015-09-30 22:08:42 <bad_duck> michagogo: oops, wrong windows...
160 2015-09-30 22:09:13 <bad_duck> sorry :/
161 2015-09-30 22:13:35 <michagogo> Hm, something just occurred to me regarding the version bits
162 2015-09-30 22:13:54 <michagogo> If you're running a version that doesn't know about a given soft fork
163 2015-09-30 22:14:06 <michagogo> And it happens, and stops being set
164 2015-09-30 22:14:52 <michagogo> Does it save state, saying "a softfork using bit x happened at point y", and then when you upgrade, it can understand that?
165 2015-09-30 22:15:04 <michagogo> Or do you need to reindex going back to that point?
166 2015-09-30 22:15:16 <maaku> CodeShark: ^^
167 2015-09-30 22:15:19 <maaku> michagogo: it should
168 2015-09-30 22:15:42 <maaku> michagogo: but I don't think I've seen that edge case considered yet
169 2015-09-30 22:15:53 <michagogo> Actually, you need to reindex anyway to make sure that what you have is valid under the new rules
170 2015-09-30 22:16:13 <michagogo> (It's important that that actually happens, though)
171 2015-09-30 22:17:06 <michagogo> For example if you're offline for a while, and then you come back online, sync up, and find out "oh, there was a fork, I'd better go upgrade"
172 2015-09-30 22:19:06 <maaku> michagogo: it would probably be sufficient to set a dirty bit and the height at which the first changeover happened
173 2015-09-30 22:19:26 <michagogo> Yeah, once you need to reindex anyway
174 2015-09-30 22:19:57 <michagogo> Hm, better hope you don't miss a fork while pruning
175 2015-09-30 22:20:05 <michagogo> (Though that's true now too)
176 2015-09-30 22:56:42 <CodeShark> michagogo: You either save state or recompute. I think it's inevitable we need to save some state at runtime (i.e. as part of the block index)...but we can recompute at startup
177 2015-09-30 23:32:41 <maaku> CodeShark: you may be missing the subtle point -- if you observe a soft-fork vote, continue validating under the old rules for a while, the node is restarted when the user observes the upgrade warning...
178 2015-09-30 23:33:30 <maaku> ...then recomputes to see what rules are active, there is a period of blocks between the vote becoming final and when the user rebooted that were validated under the old rules, not the new rules
179 2015-09-30 23:33:38 <maaku> and you may, in principle, be on an invalid chain
180 2015-09-30 23:34:56 <CodeShark> In that case we should definitely invalidate any blocks that occured after the new rule came into effect
181 2015-09-30 23:35:44 <CodeShark> so yes, a reindex would occur
182 2015-09-30 23:38:34 <CodeShark> And perhaps we need to persist this state at the point where the old version "accepts" a block with an unrecognized version
183 2015-09-30 23:40:49 <CodeShark> We can mark a block as having an unrecognized version - then when reloading the index we can force a reindex from that point
184 2015-09-30 23:43:30 <maaku> This may be enough of an edge case that it is okay to simply tell the user to reindex
185 2015-09-30 23:43:54 <maaku> This situation already involves user intervention (to download the new code)
186 2015-09-30 23:44:21 <maaku> but ideally, you'd remember where the vote happened and mark the block index as dirty
187 2015-09-30 23:44:59 <maaku> then on reboot, you revisit those headers and see if you understand the vote. if you do, reindex from there. if not, leave the dirty bit set and continue
188 2015-09-30 23:45:02 <CodeShark> Well, that would be the simplest approach. Eventually I'd like to see more of this automated and optimized, but perhaps for the first implementation of versionbits we can keep it simple
189 2015-09-30 23:45:11 <maaku> But probably not worth implementing this
190 2015-09-30 23:45:52 <CodeShark> That would be the simplest approach meaning requiring a full reindex
191 2015-09-30 23:47:04 <CodeShark> Ideally, thr only user intervention required would be to either accept or reject the upgrade ;)
192 2015-09-30 23:47:16 <CodeShark> *the
193 2015-09-30 23:48:03 <CodeShark> And the user would suffer the minimum of downtime