< PRab>
Any idea why "./bin/gbuild -i --commit signature=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml" is giving "fatal: ambiguous argument 'v0.12.0rc3':"?
< PRab>
All of the other gitian stuff worked.
< Luke-Jr>
what is VERSION?
< PRab>
echo ${VERSION}
< PRab>
0.12.0rc3
< cfields>
PRab: sigs aren't posted yet
< cfields>
waiting to see if the new cert comes through
< PRab>
cfields: I thought I was generating my own sigs. What sig needs to be posted?
< cfields>
PRab: win-signer attaches the detached codesign payload to the binaries
< cfields>
same as osx-signer
< PRab>
Oh, gotcha. I didn't realize that what it was doing.
< Luke-Jr>
jtimon: "A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption.
< Luke-Jr>
Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold."
< Luke-Jr>
jtimon: is this clearer?
< PRab>
I thought it was just signing the binary so that it could be checked before somebody preformed the windows signature. This is even cooler.
< PRab>
Out of curiosity, where does the detached codesign payload live?
< PRab>
cfields: Ah, I had looked in there, but I looked at master.
< PRab>
So until that is posted, it sounds like I can't do that part of the gitian build.
< PRab>
No big deal. I can do it later.
< cfields>
PRab: i sign, detach the sigs, and push them up, without posting the binaries anywhere. That way it's nearly guaranteed that the signer hasn't tampered with anything
< cfields>
PRab: yep, this one's going to be delayed a bit. fingers crossed it should be taken care of soon.
< PRab>
Yep, makes sense now. Thanks for all the hard work.
< cfields>
np, sorry for the inconvenience
< Luke-Jr>
cfields: btw, would you be interested in making sigs for Bitcoin LJR as well?
< cfields>
Luke-Jr: sure, though tbh i'd rather put the effort into porting an osx signer
< cfields>
fyi, win is already signed in linux. osx is the only hold-out
< Luke-Jr>
cfields: well, I didn't see any trivial way to get keys to sign with :/
< cfields>
Luke-Jr: oh, no, i wouldn't be comfortable signing with the same keys :)
< Luke-Jr>
do you have an easy way to get another set? XD
< cfields>
Luke-Jr: i'm honestly not sure what the requirements are. we'll be going down that path after 0.12 though, need to get new keys for Core. i can let you know how it goes
< Luke-Jr>
cfields: ok. maybe if you get a convenient opportunity for two key-pairs, get one for LJR? ;)
< jtimon>
3.b) there's not "economic consensus" to revert 1
< jtimon>
ho much time is 2?
< jtimon>
s/ho/how
< Luke-Jr>
that's the "at most three months"
< Luke-Jr>
perhaps I should also clarify that the Final soft-fork can still be moved to a Replaced status should it later gain consensus?
< jtimon>
so if 3.a happens 6 months after 1, the softfork BIP proposing 1 will get to final?
< Luke-Jr>
(maybe not; I guess that's implied in a hardfork anyway)
< jtimon>
oh, I guess that would solve my time concern
< Luke-Jr>
jtimon: Final and then Replaced
< jtimon>
yep, if a softfork that gets to the final state can then be reverted to replaced if it's found to be controversial, then I guess my concern goes away
< Luke-Jr>
What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later?
< Luke-Jr>
* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork.
< Luke-Jr>
^ sound good?
< jtimon>
I would still really like to make uncontroversial soft/hard forks as similar as possible, since I believe philosohpically there's much more difference between controversial/uncontroversial than between soft/hard fork (the latter being just a time/technical/convenience advantage in softforks, but nothing fundamentally different for non-deployment concerns)
< Luke-Jr>
we can't change the nature of the differences. :P
< jtimon>
of course not, we can just change our terms and definitions
< jtimon>
mhmm...so I was, I guess, previously asking that only uncontroversial changes could get to the final state (neither controversial soft nor hard should ever get to final), but you propose that instead controversial softforks can get to final and then reverted to replaced by a hardfork
< Luke-Jr>
even controversial hardforks can get to Final, provided they have de facto destroyed the dissent
< Luke-Jr>
(not to say they *should*..)
< jtimon>
mmhmm, can a controversial hardfork be "replaced" by another controversial hardfork? how does this all look when there's 8 controversial hardforks living in parallel?
< Luke-Jr>
everyone needs to be using the hardforked rules to get to Final
< Luke-Jr>
a controversial hardfork gets there, by forcing everyone else to use its rules
< jtimon>
ok, so if at one point two controversial hardforks coexist (that is, the controversial hardfork and the no-hardfork ruleset) there will never be a final hardfork again?
< jtimon>
no hardfork (controversial or not) can force any user to validate a particular ruleset
< Luke-Jr>
I would think users of a non-Final hard-fork do not count toward subsequent hard-fork proposals
< Luke-Jr>
since they're no longer using Bitcoin
< jtimon>
you said a hardfork is only final if the dissenting branch died, if two branches coexist forever, both of them are non-final forever and this no subsequent hardfork proposal count for any of the two branches!
< Luke-Jr>
hmm
< jtimon>
let's bring my canonical example: let's say some users suddenly decide bitcoin should have 5% annual demurrage
< Luke-Jr>
I don't see a solution for that hypothetical :P
< jtimon>
and we have 2 branches that live forever (let's call them bitcoin and freifork respectively)
< Luke-Jr>
no
< Luke-Jr>
the original is not a branch
< jtimon>
the recommendation in bip99 should be that if freiforkers know beforehand the two branches will never merge, they should consider starting an altcoin instead of a controversial hardfork
< Luke-Jr>
no difference
< jtimon>
but there's theoretically cases for a legitimate controversial hardfork (asic-reset for starters)
< jtimon>
yes, there's a difference: an altcoin gives you far more parameter choosing flexibility (say, you deeply believe that 100 is a more round number than 21 or whatever)
< Luke-Jr>
asic-reset isn't controversial, and still needs consensus
< Luke-Jr>
a non-consensus hardfork that never becomes Final, is literally an altcoin
< jtimon>
Luke-Jr: I already admited we disagree on whether an asic-reset hardfork is intrinsically controversial (as bip99 indicates) or not (as you believe), let's please agree to disagree on that
< Luke-Jr>
well, then don't try to use it as a premise :p
< jtimon>
well the premise in bip99 is that uncontroversial things require bip9 regardless of them being softforks or hardforks
< Luke-Jr>
ewww
< Luke-Jr>
hardforks should never use miner voting :<
< Luke-Jr>
unless maybe it's super clear that miners are only indicating economic consensus
< jtimon>
because "uncontroversial" always means "uncontroversial" (by any defintion), no matter how long you have to wait to deploy it for practical purposes
< Luke-Jr>
ie, they'd manually set the vote and not merely run software supporting it
< jtimon>
Luke-Jr: "hardforks should never use miner voting" as you hopefully know already, bip99 (and I believe petertodd) directly contradicts this, modulo s/miner voting/miner upgrade coordination/
< Luke-Jr>
I have no read BIP 99 yet. Remind me to oppose it I guess >_<
< Luke-Jr>
unless the modulo there changes it
< jtimon>
would you agree that "mining voting" is a confusing term that leads people to talk about "hashing power democracy" and other confusing concepts?
< Luke-Jr>
shrug
< Luke-Jr>
the problem is trying to use a consensus-establishing system for something it cannot establish consensus on
< Luke-Jr>
not the terminology
< jtimon>
Luke-Jr: "I have no read BIP 99 yet. Remind me to oppose it I guess" shrug maybe you should have read it before writting your own
< Luke-Jr>
mine has different goals than BIP 99
< Luke-Jr>
BIP 99 is, as I understand it, aimed at successful deployment of softforks and hardforks
< jtimon>
Luke-Jr: how do you know if you haven't read bip99 yet?
< Luke-Jr>
I did skim it :P
< Luke-Jr>
am I wrong?
< jtimon>
not on the goals, I would complete it with "and deploy an uncontroversial hardfork" and classify not-recommended/unsuccesful soft/hard-forks as well"
< Luke-Jr>
I do think you should split the HF proposal out to another BIP, FWIW
< jtimon>
but really, I was assuming that you had read it all along, that could have probably saved us a lot of terminology discussion...
< Luke-Jr>
I probably should go read it.
< Luke-Jr>
(I had mostly forgotten it even existed when I started this one)
< jtimon>
Luke-Jr: thanks, that's useful feedback I realized conflating "let's clasify uncontroversial hardforks with all the rest of theorethically potential hardforks" and "and let's deploy one of those uncontroversial hardforks, what was the point of putting them in context otherwise" is potentially confusing: I will reaplace the code entire code section with a link to another bip draft
< jtimon>
to reiterate, having a bip in draft state for an undefined amount of time is right, right?
< Luke-Jr>
?
< jtimon>
unless someone complains that it should move to replaced or something, obviously
< jtimon>
last question: is it fine if bip99 stays as a darft while I wait to rebase the informational part on top of yours and move the code/hardfork-proposal part to a different bip to be linked from this one?
< jtimon>
(without knowing when any of those two things may happen)
< Luke-Jr>
jtimon: I don't see why not
< Luke-Jr>
Rejected status has a timeout of 3 years
< jtimon>
oh, I missed that, "not touched in 3 years" -> rejected, I think I have time or it will be replaced by some other first hardfork by that time, great
< jtimon>
Luke-Jr: thanks for answering many questions, this was really helpful (but could have been even more productive if you had read bip99)
< Luke-Jr>
jtimon: np, hopefully I'll get them added to the BIP's Rationale so others get the answers too ☺
< Luke-Jr>
I'll try to read BIP 99 soon, unless you'd rather I wait for you to split it?
< jtimon>
no, the part to be splitted is just the code section (and its respective references)
< Luke-Jr>
k
< jtimon>
please read it, I think you will understand some of my points better
< Luke-Jr>
I will
< jtimon>
in fact the next main change I had plannned was just to add "use a negative block version number after activation" to both of the hardfork recommendations (as explained in the talk), plus incorporate some of the feedback (like incorporate the "let's keep 50 btc subsidy forever" as an example of a failed controversial hardfork)
< Luke-Jr>
eh, negative? just don't interpret it as signed and ignore the first bit :P
< Luke-Jr>
or better yet, set the first bit on the first block, and make a consensus rule that it be clear from that point forward..
< Luke-Jr>
so it can be reused
< Luke-Jr>
frankly, it's pretty dumb that versionbits considers it as a number at all at this point
< jtimon>
yeah, "negative" or "first bit active" mean the seam here: non-upgraded nodes will preceive it as invalid [unless they have a more advanced warning system backported]
< Luke-Jr>
I should assign a number for biprevised so I don't need to keep saying "my BIP" for it..
< jtimon>
in any case we both know what bit we're talking about: the one that would old nodes think a given block is invalid
< jtimon>
Luke-Jr: ack on number, or at least just open a PR to the bips repo
< Luke-Jr>
jtimon: can't open a PR until GitHub fixes their crap :/
< Luke-Jr>
my repo is somehow de-linked so it can't PR to the main on
< Luke-Jr>
one*
< jtimon>
github crap?
< Luke-Jr>
jtimon: try opening a PR from my repo to the main repo, and you'll find it's impossible :<
< jtimon>
mhmm, I believe destroying your repo, forking bitcoin/bips again, etc would solve it
< jtimon>
fair enough, but other people need to open a PR before getting a bip number, someone will accuse you of abusing your power :p
< Luke-Jr>
jtimon: that's not true, people have been assigned numbers without a PR many times
< Luke-Jr>
and I just assigned BIP 74 pre-PR a week or so ago, so that's certainly not changed since I became editor either :p
< jtimon>
oh, I thought the new modus operandis was PR before number
< jtimon>
I was just teasing anyway, assign yourself a number, but at some point you will need to open a PR as well
< Luke-Jr>
anyway, since it's dealing specifically with the BIP process, I was thinking BIP 2
< Luke-Jr>
yes, I am nagging GitHub support to fix the PR stuff
< jtimon>
Luke-Jr: I think bip 2 would be most appropriate
< jtimon>
Luke-Jr: just curious, has the github bug anything to do with the fact that bips is not a "base project" but a fork of ptodd's?
< jtimon>
that way we will be able to say "read bip 1 and 2..."
< Luke-Jr>
jtimon: a few weeks ago it seems they delinked genjix/bips from the rest
< jtimon>
Luke-Jr: what do you mean? the parent of petertodd/bips was genjix/bips in github?
< Luke-Jr>
indeed
< jtimon>
I see
< jtimon>
can't someone create the PR while giving you the rights to force push in it?
< jtimon>
I believe btcdrak somehow took over maaku's bip68/bip112 opened bips with no problem, maybe someone else can create it and somehow transfer control to you or something (random thoughts, who knows how github works inside for this)
< GitHub89>
bitcoin/master d5f4683 Luke Dashjr: Unify package name to as few places as possible without major changes
< GitHub89>
bitcoin/master 1a6c67c Luke Dashjr: Parameterise 2009 in translatable copyright strings
< GitHub89>
bitcoin/master 63bcdc5 Luke Dashjr: More complicated package name substitution for Mac deployment
< GitHub169>
[bitcoin] laanwj closed pull request #7192: Unify product name to as few places as possible (master...single_prodname) https://github.com/bitcoin/bitcoin/pull/7192
< wumpus>
NOTE: if you are building the git master branch, you need to re-run ./autogen.sh after this
< GitHub77>
bitcoin/master 7d0bf0b Jonas Schnelli: include the chaintip *blockIndex in the SyncTransaction signal...
< GitHub77>
bitcoin/master d222838 Wladimir J. van der Laan: Merge #6480: include the chaintip blockindex in the SyncTransaction signal, add signal UpdateTip()...
< GitHub45>
[bitcoin] laanwj closed pull request #6480: include the chaintip blockindex in the SyncTransaction signal, add signal UpdateTip() (master...2015/07/syncsignal_hight) https://github.com/bitcoin/bitcoin/pull/6480
< GitHub148>
[bitcoin] sandakersmann opened pull request #7467: [0.12] Set -mempoolreplacement to false (master...mempoolreplacement) https://github.com/bitcoin/bitcoin/pull/7467