< sdaftuar>
gmaxwell: hah, i made the same patch myself to see how big the changes were, then figured out that this must be exactly what sipa meant about the ever-expanding scope of that PR
< gmaxwell>
sdaftuar: I do feel kinda bad that it takes a mempool lock now several times for each transaction in the queue, but it's negligble. It could be easily optimized later, e.g. to have a function that took the set and populated a vector of {hash, depth, feerate} and dropped evicted transactions, all under a single lock acquisition. But that can be done another day...
< gmaxwell>
the improvement from this for propagation of dependant transactions is really substantial, and I'd rather not delay it.
< phantomcircuit>
wumpus, currently have fuzzing of CDataStream >> CBlock working
< wumpus>
great!
< phantomcircuit>
i figured that would exercise the most of the serialization stuff in one go
< phantomcircuit>
also discovered that combining std::copy with violation of the strict aliasing rule is a bad idea
< phantomcircuit>
(on the latest gcc at least)
< gmaxwell>
violating aliasing rules is always a bad idea. :)
< phantomcircuit>
gmaxwell, i wasn't expecting it to violate the rule though
< phantomcircuit>
(and there's no warning about it)
< phantomcircuit>
ie thought it was char*
< gmaxwell>
ah, no you were copying a vector, no?
< phantomcircuit>
copying from std::vector<char> to uint32_t*
< gmaxwell>
yea... not quite. :)
< gmaxwell>
Have you tried introducing a bug and verifying that it finds it?
< phantomcircuit>
currently im trying to identify which exceptions i should catch as "that's expected"
< phantomcircuit>
gmaxwell, huh memcpy is void*
< phantomcircuit>
i guess this is *also* violating sa
< phantomcircuit>
it seems like catching std::ios_base::failure is enough
< gmaxwell>
phantomcircuit: it isn't the protype that can violate SA, its whats done inside, if you implemented your own memcpy and did your accesses via char pointers you'd be fine.
< phantomcircuit>
gmaxwell, i wonder if glibc memcpy is char* internally or not
< sipa>
phantomcircuit: i assume it's written in asm :)
< gmaxwell>
"lol"
< luke-jr>
phantomcircuit: it's SSSE3 usually :/
< luke-jr>
I had to build my glibc with -mno-ssse3 or stuff crashed
< phantomcircuit>
luke-jr, ha
< * luke-jr>
never figured out why Haswell's SSSE3 seems to be broken in 32-bit mode.
< GitHub187>
[bitcoin] laanwj opened pull request #7927: Minor changes to dbwrapper to simplify support for other databases (master...2016_04_dbwrapper_modernization) https://github.com/bitcoin/bitcoin/pull/7927
< gmaxwell>
you mean 'x32' right?
< luke-jr>
no, regular 32-bit
< gmaxwell>
weird.
< luke-jr>
I suspect x32 would work
< luke-jr>
my best guess so far has been pointer alignment stuff
< gmaxwell>
I assume it's not haswell, but some GCC bug.
< luke-jr>
possible
< luke-jr>
maybe Haswell is stricted on the spec than previous CPUs?
< sipa>
i doubt the spec changed, but perhaps older cpus were more lenient with spec violations :)
< luke-jr>
although it'd be a glibc *and* Mesa bug, as it turned up at least both implementations of memcpy (not sure why Mesa has a separate one, but oh well)
< luke-jr>
or GCC, but I don't see how the compiler could be at fault for this
< luke-jr>
IIRC it's inline asm
< luke-jr>
(but I haven't looked at it in probably a year or so)
< phantomcircuit>
luke-jr, that would explain why it does what i expect it to do
< luke-jr>
?
< phantomcircuit>
gmaxwell, it seems like the only way to ensure sa isn't being violated would be to copy byte by byte
< sipa>
phantomcircuit: void* is allowed to alias any pointer, i think
< luke-jr>
in C, at least; not sure about C++ - it complains if you do it implicitly, at least
< sipa>
i upgraded to xenial, did git -dfx, ccache -C, ./autogen.sh, ./configure, make -j5... and i get util.cpp:817:53: error: ‘COPYRIGHT_HOLDERS’ was not declared in this scope
< * sipa>
tries again
< luke-jr>
stale config.h somewhere?
< sipa>
after git -dfx ?
< sipa>
eh, git clean -dfx
< luke-jr>
hm, assuming our gitignore is okay that should eliminate any
< sipa>
git clean -dfx deletes all files not checked in
< sipa>
including ignored files
< sipa>
but also others
< sipa>
so gitignore is not relevant
< luke-jr>
hm
< sipa>
i think it's working now...
< luke-jr>
what changed?
< sipa>
i did git clean -dfx again...
< luke-jr>
strange
< NicolasDorier>
btw I got also the same error yestersday
< luke-jr>
I don't suppose either of you saved the config.h/log to compare?
< NicolasDorier>
I can reproduce one sec
< NicolasDorier>
luke-jr: right now I have the error, what do you want I do to help fixing it ?
< NicolasDorier>
(I'm not linux wizard so step by step would be appreciated :p)
< luke-jr>
NicolasDorier: ideally, copy the entire bitcoin/ dir somewhere, then re-do it successfully and compare
< NicolasDorier>
k one sec.
< NicolasDorier>
mmh, now getting another error after git clean -dfx... but that might be unrelated to the earrlier copyright error as I'm not on master branch right now
< sipa>
MINIMALDATA includes 2 rules: for every push operation, the shortest possible form must be used 2) whenever a stack element is interpreter as a number, it must be in the shortest possible notation
< sipa>
here, 0x00 is pushed onto the stack with a push operation that satisfies 1)
< sipa>
2) is not applicable, because it is not being interpreted as a number
< Chris_Stewart_5>
Ok that makes sense. Thanks sipa.
< luke-jr>
oops, we released 0.12.1 with no practical way to mine (GBT hasn't been updated for BIP 9) :x
< luke-jr>
well, practical and correct I guess
< luke-jr>
should I de-bundle BIP 9 GBT stuff from segwit, or just figure wait for that?
< luke-jr>
not sure there's a way to support 0.12.1 properly, so basically means the softfork "needs" to be delayed?
< sipa>
how do you mean?
< sipa>
it's already being used by miners
< luke-jr>
sipa: there's no way for GBT clients to know what the rules are
< sipa>
there's no need for that if they're connecting to a trusted bitcoind
< luke-jr>
GBT requires it
< luke-jr>
since it could very well be needed
< luke-jr>
eg, with segwit the handling of txid/hash
< sipa>
so let's say there is a softfork that adds UTXO commitments
< sipa>
what you going to do? provide the entire utxo set in the GBT response?
< luke-jr>
I could hack libblkmaker to understand that the new "version" can be treated as the previous ones, but this will break as soon as that bit is reused
< sipa>
your view of reality is a dream
< sipa>
GBT is not being used the way you envision it
< luke-jr>
in such a case, the GBT client needs to be aware the commitment is required and where
< luke-jr>
so it can place the commitment from the local bitcoind in the right part of the block
< sipa>
or it could just not bother, and use a full node to construct the block proposals, which is in a much better position to do so, and already knows everything necessary (apart from coinbase outputs)
< luke-jr>
sipa: I wouldn't have even noticed this if it wasn't.
< sipa>
but no need to have thing discussion again
< sipa>
i'm fine with reporting what bip9 deployments are active and available in GBT
< sipa>
but please don't go claim that it's not possible to mine without
< sipa>
there is no real world mining now that needs such information
< luke-jr>
per spec, GBT clients cannot work with 0.12.1 as-is today.
< luke-jr>
and de facto miners implementing it do not work with it
< sipa>
why not? all deployed GBT clients in the world work fine with it
< luke-jr>
I'm just trying to find a clean way to fix this real-world problem miners are encountering
< luke-jr>
nope
< sipa>
how so?
< luke-jr>
the version field is unrecognised, so they throw an error
< sipa>
though i think most gbt clients just pass through the version field, and they would be fine, because bitcoind's block template always corresponds to a valid block
< luke-jr>
those would be fine now (albeit not per spec), but they'll break worse with segwit
< luke-jr>
I suppose libblkmaker can treat the case of (currentsoftforkversion && !bip9)
< luke-jr>
as long as the next softfork uses BIP9 GBT changes, that would protect against bit reuse
< sipa>
i think it may be best to disentangle the segwit changes from bip9 changes to gbt
< luke-jr>
does that sound reasonable?
< luke-jr>
ok
< luke-jr>
so today I will focus/prioritise 1) finish revising GBT BIP changes, 2) split BIP9 GBT code from segwit, 3) update libblkmaker to detect 0.12.1 situation
< sipa>
so i think we at least agreed that gbt should report the list of currently active rules, probably by name
< sipa>
(trying to remember the discussion we had before)
< luke-jr>
version: bits the server likes you to set, vbavailable: {name:bit} mapping array the server allows you to set, vbrequired: bits the server demands you to set
< sipa>
apart from that there were two other functions: 1) policy about which bits the server allows you to set/not set, and a suggestion 3) providing information about linkage between available bits and the deployment they correspond to
< sipa>
i'm a bit unconfortable with the last thing, as it's only useful in the case the client trusts the server
< luke-jr>
so libblkmaker will have a special case for 0x20000000 && !vbavailable, to handle 0.12.1 correctly
< sipa>
how will you deal with 0x20000001?
< luke-jr>
hm, I'm confused
< luke-jr>
I pulled 0x20000000 out of a recent block to be lazy, but that indicates no softforks, doesn't it? :x
< luke-jr>
oh, the begin time..
< sipa>
yes, after may 1st it will set 0x20000001
< luke-jr>
so I need to check for & 0xFFFFFFFE == 0x20000000
< sipa>
cfields: ^ relevant discussion
< luke-jr>
sipa: re vbrequired: the server can always reject submissions that clear bits it insists on, so this merely informs clients in advance so they can choose not to use that server
< sipa>
luke-jr: right, no problem with saying "these bits you must set, and these you may set"
< sipa>
i'm unconvinced about providing information about what bits corresponds with whicj deployment, as that is ourely informational with nonrelevance to what answers are acceptable
< sipa>
*which *purely
< sipa>
*no relevance
< luke-jr>
in the sense that you wish to discuss it further before proceeding that direction, or just a comment?
< sipa>
like, we also don't provide information about what the coinbase maturity is, while it could just as easily change in a softfork
< luke-jr>
things like that are why GBT says clients shouldn't make assumptions about block versions they don't understand ;)
< sipa>
my point is that this mapping information is going beyond the scope of the GBT call, and if clients which tovparticipate in voting, well, then they are responsible for knowing what means what
< sipa>
*wish to participate
< luke-jr>
"what means what" depends on blockchain context they lack
< sipa>
nno, it does not
< sipa>
it's in the bips
< sipa>
ah, there is one piece of context information they lack
< sipa>
mediantimepast
< luke-jr>
also testnet vs mainnet, but that's admittedly less important
< sipa>
i see
< luke-jr>
possibly becomes important if we try to use GBT for sidechains (but I'm not convinced that makes sense)
< instagibbs>
sipa, "Otherwise, going from WITNESS->P2SH+WITNESS would be possible, which is not a softfork." I don't grok this. Could you briefly explain it?
< luke-jr>
btcdrak: looks like none of the GBT stuff does, due to GitHub migration
< luke-jr>
btcdrak: fixed by avoiding the templates
< sipa>
instagibbs: say you have a normal P2SH (not witness) output being spent
< sipa>
oh, no
< sipa>
instagibbs: say you have an invalid witness-in-p2sh spending
< sipa>
with just witness enabled, that's valid
< instagibbs>
wait what, is it invalid or invalid?
< instagibbs>
err valid
< sipa>
say you have a p2sh output, and a corresponding input to spend it, which provides redeemscript which is a witness script, and then witness program that corresponds to it, but is invalid (say it's wrong signature)
< kanzure>
why would enabling witness make that valid?
< kanzure>
wrong signatures should always be wrong
< sipa>
if you evaluate that with WITNESS, it is valid, because it's a p2sh outout, which is an anyone can spend
< sipa>
if you evaluate with WITNESS+P2SH, the P2SH evaluation happens, which triggers the witness logic, which is invalid
< sipa>
eh
< sipa>
that's all true, but not the reason why it's not a softfork
< kanzure>
oops just checked context. didn't see the question re: the comment. nevermind.
< instagibbs>
"say you have a p2sh output" are you saying this is a p2wsh or something similar
< instagibbs>
or just a plain p2sh like today
< instagibbs>
oh i see
< instagibbs>
I'm not quite getting the comment then, although I agree with what you're saying here
< sipa>
let me think again
< instagibbs>
it sounds like you're saying SOFTFORK1 this is valid, then adding SOFTFORK2 it's now invalid
< instagibbs>
which is def of softfork?
< sipa>
there is a similar rule for cleanstack, and that one i can explain
< sipa>
no, the problem is that when validation with flags1 fails, but with flags1+flags2 succeeds, then it is not a aoftfork
< sipa>
and all flags should be softforks
< sipa>
mempool validations relies on that
< instagibbs>
I'm clearly missing something important here.
< instagibbs>
probably what the flag semantics are or something
< instagibbs>
oh... it's just talking about the actual implementation and program flow...
< * instagibbs>
smacks forehead
< sipa>
so, for ok, for WWITNESS and CLEANSTACK
< sipa>
any witness spend would fail CLEANSTACK validation
< sipa>
because it is just pushes
< sipa>
so it clearly does not satisfy CLEANSTACK
< instagibbs>
I misunderstood the comment, as I thought
< sipa>
unless when WITNESS is enabled, then we ignore the CLEANSTACK rule
< sipa>
thus, a change in flags from CLEANSTACK to CLEANSTACK+WITNESS is not a softfork
< instagibbs>
I read it as "BIP141 by itself is somehow a hardfork"
< sipa>
oh, no
< instagibbs>
totally get it now
< sipa>
we just make CLEANSTACK without WITNESS invalid, so such a change can never occur
< sipa>
ok!
< luke-jr>
sipa: does BIP68+112+113 have a VB name?
< sipa>
luke-jr: csv
< luke-jr>
k
< instagibbs>
thanks for the explanation!
< luke-jr>
sipa: am I correct in understanding that the block time itself is entirely unrelated to the meaning of bits?
< sipa>
luke-jr: the rules that apply to a block are purely a function of its ancestor block header
< gmaxwell>
luke-jr: it's pointing out that you should use MAX_VERSION_BITS_DEPLOYMENTS instead of MAX_VERSION_BITS_DEPLOYMENTS.
< luke-jr>
am I blind or something? those look the same to me :|
< sipa>
different namespace?
< luke-jr>
aha that could be it
< luke-jr>
yup
< luke-jr>
thanks
< Lightsword>
luke-jr, why not version GBT separately from the block version?
< luke-jr>
Lightsword: it doesn't make sense to do so
< Lightsword>
most of the time soft forks don’t require mining software changes though, so it would be a good way to signal that mining software needs to be upgraded
< Lightsword>
and in general mining software has no reason to care about the rules being enforced on the network since it assumes the template is valid anyways
< luke-jr>
Lightsword: well, previously, GBT had the version/force mutation for that, but nobody ever considered it worth using
< Lightsword>
luke-jr, so the mining software could actually enforce soft fork rules different from bitcoind?
< luke-jr>
the new BIP 9 stuff doesn't really break that either
< luke-jr>
Lightsword: ?
< Lightsword>
what is the purpose of version/force mutation?
< luke-jr>
Lightsword: tells clients to use the provided version despite their ignorance of its meaning
< luke-jr>
so the server could look at what the client supports (in the GBT request), and decide it was close enough
< Lightsword>
oh, is that for GBT pooled mining?
< luke-jr>
mutations are defined in BIP 23, yes, but GBT itself has no distinction between pools and bitcoind
< Lightsword>
luke-jr, so that would allow say embedded GBT clients to mine on a pool without support for segwit or only soft forks that have no GBT format changes like CSV?
< sipa>
Lightsword: the choice that miner clients have is choosing to vote for a deployment or not
< sipa>
not about rules that are actually enforced
< luke-jr>
Lightsword: there is no way to support segwit in GBT clients unless the GBT client is aware of the segwit changes.
< sipa>
those are set by the full node/server that has to accept them
< Lightsword>
so the miners connecting to the pool would be able to modify their block version number to whatever they want?
< Lightsword>
ok, well from a practical point of view why wouldn’t it make sense for GBT to be versioned separately from the block version so that mining clients can easially determine if they have to upgrade or if they can just use the provided block version as is?
< luke-jr>
Lightsword: because that's not a simple boolean question, and provides no benefits over how GBT presently supports it
< luke-jr>
the CSV deployment *could* have used version/force for old GBT clients, but it did not.
< Lightsword>
I’m confused on what the purpose of the “name” field is, if miners have to be updated to recognize it why can’t they just decode the provided block version number and infer it themselves?
< luke-jr>
the block version number indicates the pending proposals, not the ones in effect
< Lightsword>
why would the mining software need to care about that specifically as opposed to just caring about whether it broke compatibility?
< luke-jr>
Lightsword: compatibility is only guaranteed with the known rules
< Lightsword>
luke-jr, but most soft fork rules are enforced by bitcoind by just not including transactions in the template, so in thsoe cases the GBT version would not need to be changed
< Lightsword>
am I missing something here? I don’t see why the GBT client would need to care about those types of rule changes since they are enforced by bitcoind simply excluding invalid transactions
< luke-jr>
Lightsword: eg, when the transactions and generation tx come from different servers
< Lightsword>
luke-jr, wouldn’t both of those be versioned? are you talking about a GBT client mining off of two different GBT sources at once?
< luke-jr>
yes
< Lightsword>
so wouldn’t the client be able to recognize that the GBT version from the transactions server and generation tx server are different?
< luke-jr>
Lightsword: GBT code exists which will merge transaction sets from multiple servers as well, if we want to get pedantic
< Lightsword>
basically what I’m thinking is that we should have a GBT version indicator that should change to signal to the miner that additional rules need to be enforced, but only for rules that aren’t simply enforced by the excluding the transaction from the template
< Lightsword>
since the mining client doesn’t really need to care about a rule that is enforced simply by exclusion of a transaction
< luke-jr>
it might
< Lightsword>
in what sort of situation would that be?
< luke-jr>
[22:57:03] <luke-jr> Lightsword: GBT code exists which will merge transaction sets from multiple servers as well, if we want to get pedantic
< Lightsword>
does anybody actually do that?
< luke-jr>
dunno, doubt it
< Lightsword>
I mean, merging transactions means you have to support a lot of consensus logic within the mining software itself
< luke-jr>
not much
< sipa>
it also means you probably want a GBT that reports the entire mempool (or part of it), instead of something already tailored for a single block
< luke-jr>
perhaps a "rules/force" mutation would make sense
< luke-jr>
then the server can evaluate if the client's supported rules are sufficient and override that check
< Lightsword>
since most mining software wouldn’t have the neccesary consensus logic to actually handle merging to begin with I would say it would be best to ignore that case for having a GBT version
< Lightsword>
basically the issue right now is we don’t have a way to signal when mining software needs to upgrade or even likely needs to upgrade, at least for the most recent soft forks
< luke-jr>
"version" did that pre-BIP9, and "rules" does it with BIP 9
< Lightsword>
if the signaling method gets false positives on telling the mining software that it needs to upgrade then people will ignore those rules, the problem with using rules the way you have it right now is that fairly often the miner doesn’t actually care about the rules since it’s simply enforced by exclusion of transactions
< Lightsword>
IMO we need a way to signal to the miner that they need to enforce a rule that is not simply enforced by transaction exclusion otherwise miners will outright ignore rules all together
< luke-jr>
at their own risk
< Lightsword>
well if we have a soft fork that we know is enforced by transaction exclusion we should have a way to tell the mining client that they are ok as long as they are only including the transaction provided in the template
< luke-jr>
ok, that'd be a "rules/force" mutation..
< sipa>
luke-jr: ext filesystems have an extension mechanism that lists the enabled extensions in an FS in 3 classes 1) if you don't know about this, you're fine 2) if you don't know about this, you can only mount ro 3) if you don't know this, you can't mount
< sipa>
luke-jr: perhaps the active rules can use a similar classification
< Lightsword>
I’m confused on how mutable actually works
< * sipa>
doubts anyone uses mutable at all in GBT
< luke-jr>
server-side, mutable is typically static in practice, but the server could evaluate the client's capabilities and set a rules/force to tell them they're okay
< sipa>
i think you're overdesigning it, trying to cater to every possible use, without any real world demand
< luke-jr>
client-side, it tells the client what they're allowed to do with the template
< luke-jr>
sipa: yes, GBT is overdesigned and should be thrown out, but first we'd need a new protocol
< Lightsword>
well in practical sense bitcoind is the server and the stratum server is the client
< luke-jr>
Lightsword: you're only thinking about your one use case.
< Lightsword>
the use case that basically the entire network runs on though :P
< sipa>
the only one that matters
< luke-jr>
…
< luke-jr>
except the miners who don't.
< Lightsword>
which is almost certainly well below 1% of the network
< Lightsword>
hell, even eligius doesn’t allow GBT mining :P
< luke-jr>
so let's favour the centralised miners abusing their position, at the expense of the 1% who actually care to solo mine?
< luke-jr>
Lightsword: yes it does
< Lightsword>
it just redirects to stratum last I checked
< luke-jr>
you can disable the redirection
< Lightsword>
does anybody actually do that?
< luke-jr>
no idea, ask wizkid057
< Lightsword>
ok, well IMO it’s better to design a signaling method that’s actually going to be useful in practice rather than just getting ignored like it is right now
< luke-jr>
anyone know what testnet blocks made csv change states?
< Lightsword>
huh? i didn’t know it changed status
< midnightmagic>
Much of that ignored stance comes from the undeserved reputational damage that luke's suffered over the years, and the deliberate work that's gone *specifically* into being contrarian.
< midnightmagic>
like, re-written and re-designed *as a specific and incompatible alternative* to things like GBT.
< luke-jr>
Lightsword: splitting the rules list up like sipa suggested sounds like a possible approach, but would require approximately the same code to implement as rules/force would
< sipa>
not sure what you mean by rules/force
< luke-jr>
sipa: server evaluates the client's supported rules, and tells it that it can safely ignore the rules it doesn't know
< Lightsword>
midnightmagic, to be fair GBT is pretty much impractical for pooled mining
< * midnightmagic>
shrugs.
< midnightmagic>
And instead of making GBT better or including it in a superset, people did other things.
< phantomcircuit>
luke-jr, i'm some large % of testnet and running 73fc922ed64333d45f18d8a448f30cfa2ae0281e
< luke-jr>
midnightmagic: meh, GBT is fundamentally incompatible with sidechains, so it needs to be replaced anyway
< luke-jr>
phantomcircuit: ?
< Lightsword>
midnightmagic, well that’s what happens when something doesn’t fit people’s needs and redesigning it is easier than trying to fix it
< phantomcircuit>
you asked about testnet and csv; i did not answer your question but did provide additional information
< luke-jr>
phantomcircuit: I don't see an answer to my question >_
< luke-jr>
>_<
< phantomcircuit>
luke-jr, i'm so helpful right
< gmaxwell>
Lightsword: consider what you're saying, that it's impratical to send the miner the block they're working on, once per block? This should be setting off red alarm bells for you.
< phantomcircuit>
gmaxwell, i think you need more specific nouns
< Lightsword>
gmaxwell, when a “miner” is a server farm with 10k miners all directly connected to a pool…it’s going to be a problem in most cases
< phantomcircuit>
(actually i think this entire conversation needs more specific nouns)
< Lightsword>
even if the block size is 50k
< Lightsword>
it’s really a matter of what can send out the block update faster, miners aren’t likely to give up profit margin unless they have a really good reason to
< gmaxwell>
Lightsword: GBT isn't a protocol for dispatching to random hardware. But at the same time having 50k tcp connections from devices at one site to a pool makes no sense either.
< phantomcircuit>
gmaxwell, (switching topics) i'm finding the afl hang detection to be pretty annoying, it refuses to start a new run if a test case is even 1ms above the hang threshold... which means moving tests between a server and my laptop results in having to purge a bunch of tests (the server being much faster than my laptop)
< phantomcircuit>
any suggestion?
< gmaxwell>
phantomcircuit: up your threshold on the laptop.
< Lightsword>
gmaxwell, well that’s the reason stratum happened, because it was desgined for dispatching to random hardware more or less :P
< gmaxwell>
No, it's a crappy protocol for that too.
< phantomcircuit>
gmaxwell, it would be nice if it counted instructions instead but i assume that would be both harder and more expensive?
< phantomcircuit>
i thought x86 systems had performance counters that could efficiently do that though
< sipa>
phantomcircuit: rdtsc
< Lightsword>
gmaxwell, sure but it was better than GBT for that and there wasn’t an alternative people could choose
< sipa>
doesn't count instructions, just clock cycles
< bitcoinfr>
.
< phantomcircuit>
sipa, that seems better actually
< midnightmagic>
Lightsword: they explicitly ignored most of the feedback about their new design, and in at least one case, it was done in a *trivially exploitable way.*
< luke-jr>
and made no effort to collaborate with others already working on GBT
< luke-jr>
but that's history, and irrelevant to what we do in BIP 9
< luke-jr>
which is something that needs to get wrapped up sooner rather than later so solo mining is practical again
< gmaxwell>
Lightsword: You're suffering history rewrite in terms of the current state of the world, back when these protocols were created the world was very different than now.
< Lightsword>
was there much effort on either side to collaborate? at the time I thought luke was just arguing something along the lines of you shouldn’t use stratum you should use GBT instead
< luke-jr>
Lightsword: GBT was developed and revised over the course of a year or two, before stratum was even mentioned publicly
< luke-jr>
developed openly, with collaboration from multiple people
< midnightmagic>
yes, lots of attempts at collaboration and unification.
< luke-jr>
why does BOOST_FOREACH not work on UniValues? :<