< achow101>
are the codesigned binary sigs up yet?
< Taek>
I do not know that a proposal which invalidates hardware optimazation has much chance at success
< Taek>
Though there are clear reasons for wanting such optimizations disabled, Bitcoin resists contentious changes, and I think the miners would be able to put up enough of a fight to prevent the change
< warren>
I wouldn't make any assumptions of what is possible. We are yet to see the extent of outrage from the non-boosted miners and user majority and what could happen.
< gmaxwell>
Taek: keep in mind that I have not proposed invalidating an 'optimization'-- it still works, just not in a covert manner.
< gmaxwell>
Taek: also; a strong optimization like this if it cannot be copied will _guarentee_ a mining monopoly eventually.
< Taek>
acknowledged
< gmaxwell>
because at equlibrium only the optimized miner will be turning a profit.
< Taek>
err, maybe I am confused. Does your proposal not reduce the effective hashrate of the hardware you found?
< Taek>
And, fully on board that there needs to be a level playing field.
< sipa>
Taek: not if they switch to nversion grinding
< gmaxwell>
Taek: no because the use of it is optional and just impacts the power consumption. (but I suppose it would likely change the hashrate of a _facility_)
< gmaxwell>
but the optimization could be still used via nversion grinding.
< gmaxwell>
as sipa says.
< gmaxwell>
which is better in every respect except it isn't secret.
< Taek>
and the hardware that exists today is capable of doing the nversion grinding?
< gmaxwell>
it's more power efficient, it doesn't screw up further enhancements.
< gmaxwell>
Yes. (also nversion grinding is basically a subset of root grinding, and the obvious constructions of hardware that can root grind can nversion grind)
< gmaxwell>
obviously someone might do something I didn't anticipate, ... they're free to comment on the proposal.
< Taek>
okay. Thanks for clearing that up. I think that preserving the hardware advantage is going to be critical to getting the proposal accepted
< Taek>
not just that, but segwit, etc.
< gmaxwell>
I'm not confident in that.
< Taek>
Not confident that preserving the hardware advantage would be greatly beneficial to moving forward segwit?
< gmaxwell>
I don't think it's relevant for that.
< Taek>
My understanding right now is that this asic optimization gave very powerful ulterior motives for Bitmain to be politically blocking segwit
< Taek>
and the rest of the dance has really just been about preserving their 30% advantage
< gmaxwell>
Yes. Perhaps I misunderstood you...
< gmaxwell>
I thought you were saying that it was important to block only the segwit incompatible form without blocking it completely. (which is what my proposal works to do because I think it's the right way to handle it)
< gmaxwell>
I think that blocking the optimization completely would be just as good in terms of permitting the protocol upgrades.
< Taek>
My worry is that blocking the optimization completely is going to be a long bloody uphill battle
< Taek>
and, one that I think you could argue is worthwhile
< gmaxwell>
Well I think that the technique will either be opened or eventually blocked.
< gmaxwell>
The third option is that bitcoin will fail due to it, which I don't think we'll accept as a community. But eventually could be a fair while.
< gmaxwell>
I agree that it might take a while, which is part of why I think its best to seperate the concerns.
< gmaxwell>
Also, the impact of my proposal is negligible if the optimization isn't really in use so there is really no grounds to say "sure, we put it in our hardware but arn't using it, we promise, no need for this BIP"...
< Taek>
Miners not benefitting from this optimization certainly have strong motivations to activate the proposal
< Taek>
that much is going for it
< gmaxwell>
Yes, and I think users do too. And I think that would also apply to proposals to eliminate the optimization +/- people who are really confused about the economics of mining and don't realize an advantage like that sustained privately pretty much guarentees a mining monopoly.
< Taek>
Another thought. The community now has an obvious boogeyman. If you wanted to push for something difficult that required consensus, this is probably the best time to do it, leveraging the boogeyman.
< Taek>
At this point I am trying to figure out what all the options are.
< sipa>
start over?
< Taek>
bitcoin2?
< midnightmagic>
starting over would devolve to design-by-committee
< sipa>
i'm not being serious of course
< sipa>
but damn, how i woshed sometimes i'd be working on a system without all this drama and monetary interests
< rabidus>
:(
< midnightmagic>
:)
< jeremyrubin>
w.r.t. nversion grinding; practically speaking couldn't one just switch nonce and nversion and call it a day?
< sipa>
apart from being a hard fork, sure
< jeremyrubin>
Is it a hard fork though??
< jeremyrubin>
I think it's soft...
< jeremyrubin>
just don't use all the bits in nversion of course
< sipa>
well as long as you stick to the bip34 rules
< jeremyrubin>
how does it break bip34?
< jeremyrubin>
just limit your nonce > 2
< jeremyrubin>
still plenty of bits
< gmaxwell>
What do you mean by "switch nonce and nversion" version griding asicboost requires that you have a couple different first compression runs and many different second compression runs, which are all mutually compatible.
< wumpus>
midnightmagic: we've been doing so for a while
< wumpus>
to test that part of the process too
< wumpus>
the last step is very fast though
< midnightmagic>
I thought it was just on a "when cfields or whoever gets around to it, maybe, but for sure for actual releases" :-)
< cfields>
wumpus: sorry for delay. I'm out of town and had to use my laptop, which really really didn't want to cooperate
< cfields>
i think i've learned how to force a tag in the bitcoin repo, though. it seems to be a sure thing as soon as i leave for a few days :)
< wumpus>
cfields: it does seem to always happen in the most inconvenient times for you
< bitcoin-git>
[bitcoin] mrwhythat opened pull request #10161: [WIP] Support for Tor's Single Onion Service (master...tor-single-onion-service) https://github.com/bitcoin/bitcoin/pull/10161
< warren>
For those who can't directly obtain the osx gitian build req, should we recommend that they do not participate in that part of the gitian process?
< jonasschnelli>
sdaftuar: good idea. You start?
< luke-jr>
I'm looking at adding a UTXO index by scriptPubKey for sweeping purposes
< sipa>
kanzure: dinner after FC17 currently ongoing; BlueMatt, roasbeef, ... are here
< jonasschnelli>
warren: It's just an SDK tar.gz?!
< sdaftuar>
jonasschnelli: sure
< wumpus>
luke-jr: there's a pull for that right?
< luke-jr>
warren: I don't see why it should be hard nowadays.. but yes, if you don't want to, feel free to skip
< luke-jr>
wumpus: the current PR iterates over the entire UTXO set
< luke-jr>
what I'm working on uses a RIPEMD160 to index scripts -> txid
< warren>
jonasschnelli: I think a lot of non-Mac users have been sharing that with others instead of going through steps of getting it themselves, which defeats the security goal, so it's misleading if multiple people go through the gitian process unless they obtain it themselves.
< jonasschnelli>
warren: that's true
< wumpus>
luke-jr: not sure how that one is diffrent, but I don't think we need multiple utxo indexes
< luke-jr>
anyone who didn't make it themselves should delete and make it (or not do osx builds) IMO
< jonasschnelli>
I'm working on BFD. roasbeef did inform me in Berlin about the progress they have made for the LND. I'd like to have BFD for the hybrid full block SPV mode.
< jeremyrubin>
I'd like to discuss net_processing refactors. It seems like there is some plan for where that is going, but it's not been made available to me.
< luke-jr>
wumpus: the only UTXO index right now is by txid
< wumpus>
luke-jr: yes, but the pull I referenced adds an index by scriptPubKey
< jtimon>
althought it isn't mine, I think https://github.com/bitcoin/bitcoin/pull/7729 should be added to the list of things to review: that blocks the removal of accounts system
< wumpus>
warren: yes, the only reason I had to copy it (from a person I trust very much) is because it makes it possible for me to actually upload the executables. I don't think it's generally useful to build using someone else's macosx sdk file
< wumpus>
but with luke-jr's instructions to extract it on linux there's not really an excuse anymore
< sipa>
i've been working on database/cache/flush/memory usage things
< wumpus>
jtimon: I tend to agree. though please review the *API*, not the code, the code is extremely outdated on that now
< jtimon>
wumpus: thank you, that helps
< wumpus>
jtimon: however I still stand behind the label API as I wrote it down back then, and that's the important part
< morcos>
i've been coding and recoding fee estimates for months now.. they'll maybe be a tiny smidge better but infinitely more complicated and will annoy the crap out of everyone to review. have a nice day.
< sdaftuar>
i've been working on CreateNewBlock, so that we have a way to skip recently added transactions if the block income from doing so is below some threshold (to model higher orphan risk)
< warren>
wumpus: I'd like for us to be able to hash verify some part of the SDK and add that somewhere in the gitian process, I'm pretty sure this is possible
< wumpus>
warren: if you'd tar it in a deterministic way (like we do in gitian build process itself) that'd be easily possible
< jcorgan>
please correct me if i'm wrong, but #9806 uses hash of the full script as a key, not extracting the embedded push(es) for and addrindex type key, or am i confused
< wumpus>
warren: we'd just need a a script for that
< wumpus>
warren: "normalize mac sdk"
< luke-jr>
jcorgan: problem?
< warren>
wumpus: agreed
< jcorgan>
not a problem, just making sure i have the correct understanding
< wumpus>
the files and file names should definitely be the same for everyone, the differences will be in the metadata such as date/time/user and possibly file order
< jtimon>
I put some more ideas on #7829, not sure what to do about it, a couple of people participated at first, but perhaps the proposed task is too boring, even for newbies, at least I found some functions to make static
< sipa>
it seems we boosted the speed of the meeting significantly
< warren>
overt boost even
< jonasschnelli>
boost(ed),.. I can't read that word anymore
< gmaxwell>
oops
< jeremyrubin>
A [sic] efficiency gain
< jcorgan>
ima go patent it
< wumpus>
isn't meeting speed boost patented?
< jonasschnelli>
Heh,... I'm sure there is one somewhere
< gmaxwell>
Sorry, been caught up in responding to dramaz and missed the meeting entirely! :(
< jonasschnelli>
Well... it was short
< warren>
wumpus: yes, one of the claims is to remove chairs from the room
< jtimon>
gmaxwell: I guess you can bring any topic if you want, we just finished
< jtimon>
most people are probably still around
< wumpus>
warren: hah indeed, to not let people get too comfortable
< gmaxwell>
I didn't want anything.
< gmaxwell>
I'm kind of overwhelmed by this bitmain response. It says a lot of agressive and untrue things, about the BIP proposal, about me personally, about our project.
< luke-jr>
seemed clearly nonsense enough I wouldn't worry over it IMO
< jcorgan>
no good deed goes unpunished
< gmaxwell>
It does a weird mix of confirming and denying.
< wumpus>
they're overwhelmed, and incapable of responding coherently
< CodeShark>
gmaxwell: they will never back down at this point
< luke-jr>
gmaxwell: if Bitmain was innocent, they'd be all supportive of your proposal to stop competition from abusing it
< achow101>
what was Bitmain's response?
< wumpus>
yes, any miners that are not (planning to) use the trick would be supportive, after all no one wants to be secretly screwed out of their reward
< gmaxwell>
E.g. they helpfully confim their hardware implements asicboost, they loudly say they have the right to use it. They claim that they haven't used it on mainnet 'for the good of bitcoin' (how that jives with their claims that they'll make all the empty blocks they want because the protocol allows it, I dunno)
< CodeShark>
if you're expecting a mea culpa you will end up gravely disappointed
< jcorgan>
^
< gmaxwell>
Yes, the proposal is specifically designed to have minimal impact and only interfear with covert asicboost and only to the extent that it gums up protocol extensions (like segwit, utxo commitments, bloom filter commitments, etc.) But in their response they claim that I am trying to harm bitcoin by blocking a valuable optimization. :-/
< gmaxwell>
CodeShark: oh no, I expected them to just deny having used it flat out.
< wumpus>
well denying that their hardware implements it would be pointless, so they fall back to denying they use it
< gmaxwell>
I didn't expect the rant full of trivially falsifyable claims.
< wumpus>
saying they don't use it 'for the sake of bitcoin' can't be jived with saying it's a valuable optimization though
< jcorgan>
very few people to whom that rant was addressed will care to try to falsify them
< CodeShark>
truth isn't the point
< wumpus>
if it shouldn't be used for the good of bitcoin, your BIP is exactly what they should adopt too
< wumpus>
truth is the point, for us
< gmaxwell>
There is so much just simply untrue in it that I don't know where to respond. Baiscally I was prepared for a "We don't use it!" to which my response would be "Great, then you'll support activating this fix so no one else does and gains an advantage on you, right?"
< CodeShark>
yeah, but not for the intended audience
< wumpus>
we're trying to do development here, not politics
< CodeShark>
lol
< wumpus>
the intended audience of this channel is core devs
< sipa>
wumpus: +1
< CodeShark>
yes, so this is not the best place for this discussion
< jcorgan>
yeah, sorry
< wumpus>
well it's fine to mention it. I'm sure we want the BIP implemented in bitcoin core?
< morcos>
wumpus: i'd say we want if if we think there is community support
< morcos>
that should be our stance on all consensus changes
< sipa>
agree
< jonasschnelli>
morcos: how do you measure "community support"?
< jonasschnelli>
reddit?
< sipa>
jonasschnelli: it's complicated
< morcos>
its hard to measure obviously... but letting the dust settle a bit is a starting point
< jtimon>
let's move the discussion to #bitcoin ?
< wumpus>
ok, if we're not sure whether we want it, this is not the place to discuss it
< jtimon>
I mean, I think as a technical proposal it belongs in here
< wumpus>
otherwise the next question would have been how, and who is going to write the code
< jonasschnelli>
And I guess there is great uncertainty in the community.
< wumpus>
well there is quite certainly that the sneaky form of asicboost should be banished
< jonasschnelli>
Yes. Indeed.
< jonasschnelli>
Will it be a miner activated soft fork? :-)
< wumpus>
whether that BIP is the best solution to that is indeed open, indeed makes sense for the dust to settle on that, though it may still make sense to have actual code
< morcos>
i think in a clean room protocol design then, yes it shoudl be banished... it people were using it, and keeping it quiet for competitive advantage, that seems a quasi-reasonable action to me.
< morcos>
so if we want to ban the merkle-root form b/c it isn't good for the protocol (which i agree with), it's fair to give some time to not immediately obsolete hardware made with fair intention (hypothetically speaking)
< wumpus>
if people were using it, it should be banished, if people were not using it, it should also be banished to prevent it from being used. No miner would rationally want another miner to get a sneaky advantage on them.
< morcos>
yes, if no one is using it.. then we don't need to have delay
< jonasschnelli>
It's a sneaky form of optimisation that leads to more centralisation of mining, .. and therefor does not follow the idea of Satoshi IMO.
< morcos>
but in all cases, it seems to me its somethign the community should decide not core
< wumpus>
the BIP doesn't break normal mining hardware does it?
< morcos>
it can be our recommendation that it should be banished at some point, for sure
< wumpus>
unlike a PoW change
< jonasschnelli>
I guess the community will decide if they run Core or no.
< morcos>
but there seems to be no reason to continue to use it (covertly) now that it has been made public
< morcos>
so one question is how compatible existing hardware is with switching to overt
< jcorgan>
hopefully nobody made covert-only hardware
< morcos>
if compatible.. then again , no reason to delay
< morcos>
jcorgan: ha, good poitn i suppose!
< wumpus>
if they did they just screwed themselves
< jtimon>
wumpus: personally I am sure that we want it, because logic tells me that only people that plan to use it would oppose it, but if all miners use it nobody gains anything
< wumpus>
though I'm sure all hardware supports mining without tricks
< jeremyrubin>
I think we need to be very careful with how we brand any changes happening. The reason we would like to ban it is *NOT* because it is covert. It is because it is incomaptible with Bitcoin's incentive systems (e.g., transaction selection to maximiuze fees) and it interferes with protocol development.
< wumpus>
it needs special support to be able to receive multiple roots, and if it can accept multiple roots it can also accept one
< gmaxwell>
you can construct hardware that can ONLY use asicbost (or lose 3/4 of its hashpower) but it would be really stupid to do that, and I have seen no evidence that anyone does.
< jeremyrubin>
In the future, you don't want some regulator charging in requesting feature changes to disable a "covert" bitcoin feature
< gmaxwell>
wumpus: yes, though if you unroll the logic and route it, the getting only one would lose 3/4 of the hashpower. But that is not how Bitmain's is implemented...
< wumpus>
jeremyrubin: again, this is not about branding, this channel is about development
< gmaxwell>
(at least not in the chips they sell to the public)
< wumpus>
gmaxwell: yes I don't think that's anything realistic
< jeremyrubin>
I'm just saying the name "Covert" is misleading and does not lead to good technical undertsanding
< wumpus>
it's pointless to start discussing language here
< rgrant>
morcos: core must protect the protocol. if this subverts it, by creating meaning in bits that should have no meaning, then core should take a stand on that.
< rgrant>
one principled way to proceed would be to say that optimizations that harm intended extensibility will not be respected.
< jcorgan>
i like the restraint in the original proposal, to make the protocol enhancing blockage stuff not do that, and decouple that from the optimization vs. attack discussion
< rgrant>
jcorgan: sme
< rgrant>
same
< jtimon>
so on the developer side, I think we can introduce a per-deployment optional field that makes a given deployment activate instead of expire according to bip9, I guess that deserves it's own bip even if it's a simple extension of bip9, but the code is also easy to add and not very disruptive, and it seems something reasonable to have
< gmaxwell>
jcorgan: Thank you, that is very much intended. And so its frustrating to see bitmain misrepresent it so completely.
< jcorgan>
so i'd recommend that if something is done short term, it be entirely focused on that, with pushback by the team on any enthusiam to address the "overt" asicboost activity
< btcdrak>
morcos: covert boost is switchable so it can, and should be disabled post haste (community willing ofc).
< morcos>
yes, well apparently no one is using either version... so thats probably the biggest argument that no delay is needed
< gmaxwell>
Yes, if the argument is that no one is using it yet, great!
< Chris_Stewart_5>
jcorgan: I agree whole heartedly with *only* focusing on the covert (protocol blocking stuff) right now. Table the other discussion like you said
< Chris_Stewart_5>
Thats going to be a much more interesting debate and I'm not sure where I fall on that one
< wumpus>
that's also the only thing that gmaxwell's BIP covers
< jcorgan>
me neither
< Chris_Stewart_5>
Just to be clear, gmaxwell's BIP can be withdrawn if segwit is activated right?
< Chris_Stewart_5>
if we are focusing on covert usage
< BlueMatt>
Chris_Stewart_5: kinda, segwit is very deliberately designed to allow miners to not mine segwit txn, but the problem is likely self-correcting then - you're losing out on fees for asicboost
< BlueMatt>
(ie you can skip the witness commitment, but only if you dont mine segwit txn)
< gmaxwell>
Chris_Stewart_5: segwit also satisifies my BIP. The bip lets you either include the segwit commitment OR another segwit incompatible commitment.
< gmaxwell>
I structured it this way so parties that already had segwit would need zero additional work, and parties that didn't want segwit could support this bip without supporting segwit in any way.
< gmaxwell>
personally I do not believe these parties exist, but we shouldn't create a vulnerablity in the proposal where people could dishonestly argue against segwit to stop the proposal (which is the problem I think we've been having)
< jcorgan>
perhaps it would be better to move away from overt/covert terminology and use something like 'forward compatible/incompatible'
< jcorgan>
that focuses on the technical side without motivationally tinged wording
< rgrant>
jcorgan: "FairHeader" has gained a following already in #bitcoin. "forward compatible" might stir up big blockers.
< jcorgan>
ugh
< jcorgan>
"fair" is a completely subjective and political term
< rgrant>
so is "forward". got anything more descriptive?
< jcorgan>
but perhaps this particular thing should stay in #bitcoin, sorry guys
< Eagle[TM]>
whether to make it a UASF (not specifically endorsed by core) or to include it in core code is something to consider
< bitcoinreminder_>
could you release a binary for this covert asic boost bug?
< bitcoinreminder_>
i think a lot of people are already waiting for it :D
< Eagle[TM]>
i don't think it's even clear yet whether it's done as an UASF or a MASF
< bitcoinreminder_>
hm ok.. :/
< abpa>
UASF can be done by Core, just not without community support
< abpa>
MASF for fixing AntBleed can't work
< abpa>
Sorry I mean covert asicboost
< bitcoinreminder_>
I also think we should really try UASF this time.. I also think the support is overwhelming
< abpa>
It's really for #bitcoin discussion not #bitcoin-core-dev
< BlueMatt>
lol, lots of new people here tonight
< sturles>
An UASF would need support from a supermajority of exchanges and payment processors, and preferably as many merchants as possible dealing with bitcoin directly.
< sturles>
And I don't think that will be a problem.
< sturles>
Theese days you can buy beer with testnet coins, as long as you use LN..
< BlueMatt>
sturles: nonononono, that was a one-night thing...if it turns into a regular thing we have to reset testnet :(
< BlueMatt>
(and, before you ask, testnet doesnt get consensus-requirements...wumpus is the appointed holy leader and less-than-benevolent dictator for life of testnet :p)
< Eagle[TM]>
BlueMatt: it's just when things are getting really interesting, 2nd tier style reddit doesn't do it anymore. people crawling out of the woodwork
< bitcoinreminder_>
would someone be so nice to create an unofficial UASF implementation? you dont have to sign or compile it, just the code would be fine for me?
< BlueMatt>
less-than-benevolent because he gets to maximize for zero value....
< BlueMatt>
bitcoinreminder_: the proposal is far from done, needs constants, not now, no
< bitcoinreminder_>
damn :D
< bitcoinreminder_>
is there any suggestion already at least for a version string?
< bitcoinreminder_>
sorry for my impatience :D
< jcorgan>
patience is a virtue well-honed by participation in the bitcoin world :-)
< Eagle[TM]>
bitcoinreminder_: give it time. even core devs need sleep from time to time.
< bitcoinreminder_>
unfortunately :D No thanks guys, for your great work.. really :)
< BlueMatt>
yea, at least the folks at fc went to bed an hour ago, and I'm off now
< bitcoinreminder_>
good night you heros of the magic internet money :)