< midnightmagic>
sipa: I'm trying to figure out whether we did in fact break 100eH or not, and because everyone else is basically useless I only ever refer to your graphs.
< midnightmagic>
also, like 8 of the bitcoin hashrate graphs in the top google results are broken too to varying degrees, so ..
< sipa>
midnightmagic: re-ran an update manually
< midnightmagic>
\o thanks
< sipa>
i don't understand why it's not happening automatically
< sipa>
anyway, 94 EH
< midnightmagic>
sipa: It *appears* as though on your graphs we never bumped above 100eH. But news as of short time ago asserts we did.
< midnightmagic>
sipa: I'm about to go tell all those people they're stupid and point them at your graphs.
< sipa>
the 1-day estimate did go above 100 eH, but it has really high variance
< midnightmagic>
(I understand you're doing averages. I don't think semi-random spikes count.)
< sipa>
they're actually all extrapolations
< sipa>
not averages
< midnightmagic>
Hrmm..
< midnightmagic>
sipa: How are you doing the extrapolation? Can I see the equations?
< sipa>
midnightmagic: i uh... forgot them
< midnightmagic>
lol
< midnightmagic>
Do you vaguely recall doing averages and then projecting on a line, or are you using a curve or something?
< sipa>
you measure the average hashrate using an exponentially decaying window
< sipa>
and then measure the average *time* when blocks were mined, using the same exponentially decaying window
< midnightmagic>
hrmm..
< sipa>
and then some simple formula involving those two gives you the estimated hashrate at the end of the window, assuming an exponential growth before that
< sipa>
the code used on the site does some smoothing over those results and they're very jittery
< warren>
wumpus et al. One of Transifex's engineers will be attending Thursday's weekly meeting. Please think of questions you may have by late Wednesday.
< warren>
He has a few recommendations for the project to make better use of Transifex
< bitcoin-git>
[bitcoin] theStack opened pull request #16892: validation: find witness commitment header using memcmp() instead of byte-by-byte comparison (master...20190917-validation-find_witness_commitment_with_memcmp) https://github.com/bitcoin/bitcoin/pull/16892
< wumpus>
fanquake | I'll never merge a whitespace related PR ever again. <- same
< wumpus>
provoostenator: nice!
< provoostenator>
I did it mostly to see if I was missing anything in the single-key setup, but I think that works fine as is.
< provoostenator>
I still haven't read up on miniscript / policy language. I wonder how that fits into things.
< provoostenator>
sipa: would each hardware wallet provide its own "policy" that when combined results in a multisig (or something equivalent but more efficient)?
< instagibbs>
it would be helpful for the hww to report what it type of policies it can sign
< instagibbs>
right now that kind of list is assembled by hand
< instagibbs>
e.g., does the Trezor allow 2of3 or csv and 1of1 type policies to be signed
< instagibbs>
of just twist people's arms until it'll sign generic scriptcodes like ledger...
< provoostenator>
So something similar to the getdescriptors call, which currently returns the list of single-signature descriptors it likes (although we hardcoded that in HWI)
< sipa>
provoostenator: i haven't really thought about hos to assess compatibility of hardware wallets
< sipa>
hopefully if miniscript becomes a bit more common, hw wallets will just support all of it
< provoostenator>
We can manually tell HWI what each hardware wallet is capable of.
< provoostenator>
But to communicate that, maybe we need some sort of wildcard in miniscript / policy language level.
< sipa>
miniscript; not policy
< sipa>
policy is compiled to miniscript, which is a many-to-many relation
< provoostenator>
Plus one flag to indicate that the hardware wallet understands miniscript, which then implies the other wallets in a "multisig" can do whatever they want.
< sipa>
miniscript is just a different way of representing script
< provoostenator>
If one of the wallets doesn't support miniscript, then that constrains the others, depending on the sequence.
< provoostenator>
The policiy language seems a more useful level of abstraction, e.g. and(pk(hww1_key),pk(hww2_key))
< provoostenator>
Though that compiles to something no current hardware wallet will understand: <key_1> OP_CHECKSIGVERIFY <key_2> OP_CHECKSIG
< provoostenator>
But in miniscript it does make sense: and_v(vc:pk(key_1),c:pk(key_2))
< provoostenator>
So I guess the hardware wallet itself needs to understand miniscript, whereas the tools we use to setup should understand the policy language?
< sipa>
only the compiler needs to support the policy language
< sipa>
provoostenator: different compilers can map the same policy to distinct miniscripts
< sipa>
as there are various optional optimization steps involved
< provoostenator>
So what is a hardware wallet that sees the above miniscript supposed to do? It knows it has key_1, so it infers that it can sign the first part of the AND condition.
< provoostenator>
As for the second part, I guess it's happy as long as the change output has the same policy?
< sipa>
change detection is a hard problem
< provoostenator>
Indeed, it's pretty poorly supported by hardware wallets at the moment.
< sipa>
and detecting that something is the same policy is not enough; there may be dozens of ways to implement a particular policy in script
< sipa>
using an unusual one may be indiscoverae
< sipa>
*indiscoverable
< sipa>
non-discoverable?
< sipa>
undiscoverable?
< provoostenator>
I think this conservative rule is fine though: it's OK if the policy for the change address doesn't change and derives from the same set of xpubs.
< sipa>
it should just be the same miniscript
< sipa>
with different pubkeys from the same xpubs
< provoostenator>
* not policy but script
< provoostenator>
Oh and the derivation index should be identical for all signers and not a crazy high value.
< sipa>
in short: same descriptor, different index
< provoostenator>
yes
< provoostenator>
So what is it that each hardware wallet should communicate during the setup? "pk(key_1)"
< sipa>
what is setup?
< provoostenator>
E.g. in the draft PR I made, Bitcoin Core could call HWI on all wallets
< sipa>
nothing except compilers should deal with policies
< provoostenator>
Asking each to return a piece of miniscript, then combine those with AND.
< sipa>
generally it's the user or the software tha5 chooses the desired policy/script
< sipa>
and the HW wallet supports it or not
< instagibbs>
yes I'd expect Core/user to determine what type of policies it supports, then a "whitelist" of hww that support such a configuration
< sipa>
the hardware wallet is a signer device, it supports signing
< sipa>
it's not "exposing" a policy or a script; that's up to its user
< provoostenator>
I'm thinking of two use cases: 1) I have a bunch of hardware wallets, plug them all in at once to setup some multisig
< sipa>
then you should just use multisig
< provoostenator>
2) I and my "friends" each run Bitcoin Core with one or more wallets and want to setup a joint thing
< sipa>
no need for miniscript in that case
< sipa>
yes
< sipa>
in which case you'd gather the xpubs, every user constructs a policy they like
< sipa>
share the policy with others
< sipa>
run the compiler once
< sipa>
everyone can see that the policy of the output matches their part
< sipa>
and then import a descriptor for it in their wallets
< sipa>
i don't expect stuff like that to be usable or user friendly anytime soon
< achow101>
provoostenator: half of the comments that you made on #16341 are on comments that I can't figure out whree they are, so I'm not going to respond to them unless we can figure out an easier way to make these conversations easier to find and respond to
< gribble>
https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
< bitcoin-git>
bitcoin/master 8573429 soroosh-sdi: test: add some unit tests for merkle.cpp
< bitcoin-git>
bitcoin/master b3067f4 MarcoFalke: Merge #16865: test: add some unit tests for merkle.cpp
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16865: test: add some unit tests for merkle.cpp (master...13-09-19-merkle-unit-tests) https://github.com/bitcoin/bitcoin/pull/16865
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16900: doc: Fix doxygen comment for SignTransaction in rpc/rawtransaction_util (master...1909-docRpcUtil) https://github.com/bitcoin/bitcoin/pull/16900
< cubancorona>
sipa: May I message you privately about a possible vulnerability in the bitcoin light client neutrino?
< sipa>
i'm not the right person to talk to
< achow101>
any idea why changing mapWallet from std::map to std::unordered_map would cause the qt wallet tests to fail? afaict, we don't rely on the order of txs in mapWallet ever
< phantomcircuit>
achow101, possibly the tests do
< achow101>
the tests don't access mapwallet directly
< achow101>
and the order would be based on txid, which changes with each run, so depending on that order doesn't make any sense
< phantomcircuit>
achow101, neat, you found a bug then
< achow101>
ffs the gui relies on the list of txs to be sorted
< meshcollider>
lol
< promag>
achow101: where?
< achow101>
transactiontablemodel. See cachedWallet
< achow101>
I'm making it not sorted
< promag>
achow101: sort them in WalletImpl::getWalletTxs
< promag>
anyway this might be something worth improving
< promag>
it shouldn't be necessary a copy of the wallet in the model
< promag>
just those that are displayed
< achow101>
i've added a sort
< achow101>
I put it in TransactionTablePriv::refreshWallet rather than getWalletTxs since that's where the sorting matters. nothing else uses getWalletTxs, and if we add something that does, I would prefer that it not rely on sorting
< promag>
ok
< promag>
why the change to mapWallets btw?
< promag>
performance improvement?
< achow101>
yeah
< achow101>
I made a large wallet for testing my memory reduction stuff, and I decided to take a look at the loading times too
< achow101>
noticed it spent quite a while inserting things into various maps
< promag>
for daemon only then :P because I guess that change only has impact with big wallets, and that new sorting probably makes it worse
< achow101>
right, which is why I was thinking about making it non-sorted