< shinyg>
so was there a specific reason why new releases stopped coming from bitcoin.org?
< sipa>
they're still published there
< sipa>
but bitcoin core has its own project website now
< achow101>
they're trying to separate bitcoin core from bitcoin.org as bitcoin.org is for bitcoin in general whilst bitcoin core is a specific project
< shinyg>
makes sense, how about is Bitcoin Core a Solution stack or software as some describe it/
< shinyg>
Maybe bitcoin is a software stack but Core is just software
< Squidicuz>
sipa, cool. I take it that site is bitcoincore.org, right?
< achow101>
Squidicuz: yes, bitcoincore.org is Bitcoin Core's site
< Squidicuz>
just double checking. ty
< Squidicuz>
:)
< tulip>
shinyg: with tools like gitian there's no real need for a canonical binary source.
< Squidicuz>
...I'm a little late
< moli>
sipa, hi, could you update your graph?
< sipa>
which?
< achow101>
bip9 bits graph
< sipa>
oh, will do
< sipa>
before the 18th
< moli>
ah still too early? ok, thanks, sipa :)
< sipa>
yes, first retarget after the 15th midnight utc
< achow101>
miners can signal now, right? just that it won't matter because the retarget period is almsot over
< btcdrak>
at this rate of acceleration it might just at the end of 17th...
< sipa>
them signalling right now will trigger the unknown softfork warning
< achow101>
oh, that's interesting
< btcdrak>
sipa: would those trigger while in the defined state?
< btcdrak>
oh nvm, ofc it will trigger, derp
< achow101>
why would it trigger?
< achow101>
oh, is it because it is still in the defined state, not started?
< sipa>
indeed
< sipa>
so it would be seen as signalling for an unrelated fork
< sipa>
which the current software does not know about
< achow101>
why are the two graphs on the segwit adoption page on opposite ends of the page? also, chrome is super not liking that sipa's website doesn't have https for those graphs
< shinyg>
thanks for the replies sipa and wiki contribs achow
< * jtimon>
pushed jtimon/0.13-blocksign-latest on top of jtimon/0.13-blocksign on top of jtimon/0.13-new-testchain on top of jtimon/0.13-chainparams-factory eb6c595e on top of origin/master 924745dd
< gmaxwell>
looks like some folks are signaling segwit prematurely.
< midnightmagic>
:-o
< gmaxwell>
Not harmful, but it's more evidence for my concern that version has been burned for consensus critical use.
< gmaxwell>
I blame Luke. :P
< luke-jr>
☹
< * luke-jr>
doesn't deny being at fault in part.
< gmaxwell>
I think the big interface error is that mining exposes gnarly consensus internals to people who are not primarily interested in them but instead have simpler (though critical) goals like: Get mining working fast and reliably.
< gmaxwell>
E.g. it's not a good seperation of concerns. I don't have any doubt that any of the pool ops couldn't be great consensus plumbers if they wanted to be, but when they're hacking on pool software that isn't what they're trying to do.
< luke-jr>
yes, in hindsight it may have been better to do a more stratum-like getwork replacement in bitcoind (but that had its own share of problems)
< luke-jr>
by separation of this, we did gain a few things: miners can upgrade easier now than with 0.3+tons of patching
< gmaxwell>
We could be much worse off for sure.
< luke-jr>
I tried to make it simpler by having a GBT client library (libblkmaker), but it seems it isn't in any real use outside of BFGMiner
< gmaxwell>
One of the lessons (which I already knew from before) is that having a 'bad' interface, then a 'make it friendly' layer often doesn't work. People will either never find the friendlyness layer, or not use it because your own test cases don't (which they look at to understand the interface), will encounter some limitation in it and go raw, or otherwise insist on doing their own for some better o
< gmaxwell>
r worse reason.
< gmaxwell>
I explirenced this with libvorbis, which had a vorbisfile API which was 100x easier to use right than the raw interface, included with the same library... and mostly used, but still bypassed often enough to cause frequent bogus support issues that would have been avoided by using vorbisfile. ... and especially with liboggz which is a high level interface to many ogg embedded formats and ogg han
< gmaxwell>
dling which handles most of the gnarly stuff, ... and which virtually no one uses... instead implementing the same functionality themselves, usually incorrectly.
< luke-jr>
:/
< jl2012>
which block is signalling segwit?
< gmaxwell>
Then Opus (which has a much more carefully contstructed raw API) didn't ship with a opusfile (analog of the vorbisfile high level API), and relative usage of opusfile is probably 100x lower than vorbisfile. Shipping it with it as a single package makes a big difference.
< gmaxwell>
jl2012: 438958 and 438914 I think.
< jl2012>
oh, slush
< gmaxwell>
luke-jr: in any case, the general advice I think we should follow is whe should always imagine the goals of the person using an API, and them assume that they will only correctly handle any non-trivial steps that were obvious from a statement of their goals.
< gmaxwell>
Like an API for signing should not ask the signer to provide a nonce that must obey some byzantine set of security requirements. Their goal was signing, not generating random numbers. If it's easy to get it working without getting it right, it's a cointoss if they'll get it right or not. (I don't mean this in a superior or condecending way-- it's human nature to get tunnel vision around your o
< gmaxwell>
wn goals).
< gmaxwell>
plus, expecting people to worry about details that aren't related to their goals is a failure to respect their time.
<@wumpus>
it doesn't help that 'friendly' layers have a reputation to increase overhead and make things slower, deserved or not
<@wumpus>
so this may be mainly an issue for cases where there are (perceived) performance concerns, like with media APIs and mining... people always clamoring for a more 'raw' interface instead of a 'friendly' one. Same for 3D rendering with the Vulkan instead of OpenGL interface. "closer to the hardware" etc
<@wumpus>
also some attempts at friendly interfaces have actually made things harder by abstracting away details that matter, causing the API user to do brittle or nonsensical things when you see the whole picture. Or including scope/dependencies which are not necessary for a project (e.g. texture loaders for 33 image formats while the game only needs one). Good API/library design is hard and both
<@wumpus>
commercial projects and open source projects have a lot of sins there
<@wumpus>
the best way of 'imagining the goal of the person using the API' is probably to be a user of the API yourself, instead of just guessing to imagine what the goal of a user of the API could be. With mining we have some issues there because there are so few miners involved with development at any level :(