< kallewoof>
I'm a little confused by luke-jr's comment on {sign/verify}message replacement thread. He is saying not specific UTXO's but prove that funds are available. How would you do that, if you didn't sign for specific UTXO's?
< kallewoof>
Basically, he wants to be able to prove that funds are available using a signature, since that's often what people do with signmessage today.
< bitcoin-git>
[bitcoin] kallewoof opened pull request #12701: [wallet] importprivkey: explicit rescan for known key (master...importprivkey-explicit-rescan) https://github.com/bitcoin/bitcoin/pull/12701
< bitcoin-git>
[bitcoin] kallewoof opened pull request #12702: [wallet] [rpc] [doc] importprivkey: hint about importmulti (master...importprivkey-importmulti-hint) https://github.com/bitcoin/bitcoin/pull/12702
< bitcoin-git>
[bitcoin] kallewoof closed pull request #12701: [wallet] importprivkey: explicit rescan for known key (master...importprivkey-explicit-rescan) https://github.com/bitcoin/bitcoin/pull/12701
< promag>
kallewoof: IMO all RPC that are a subset of importmulti should be deprecated
< sipa>
well not right now
< sipa>
importmulti can't deal with P2SH-P2WPKH addresses yet
< * sipa>
adds to TODO list
< promag>
sipa maybe never (so it doesn't break anything)
< sipa>
?
< promag>
I mean, existing software would have to change if we deprecated those calls
< sipa>
deprecating doesn't mean removing
< promag>
sipa: means it will be removed
< promag>
no?
< promag>
eventually.. :P
< sipa>
yes, at some point in the future
< sipa>
exactly
< sipa>
we're deprecating and removing things all the time
< promag>
anyway, IMO the note should be "use importmulti instead, even for 1 entry"
< kallewoof>
promag: I'm fine with that, but sipa noted that there are cases where you cannot use importmulti.
< sipa>
well we should fix that :)
< kallewoof>
promag: So I'm keeping it as is. To be updated once P2SH-P2WPKH support is added to importmulti.
< kallewoof>
sipa: Yeah that would be ideal, I suppose
< kallewoof>
Weird that the importmulti says `"rescan": <false> (boolean, optional, default: true)`. Sending mixed signals there lol...
< sipa>
lol
< sipa>
that should be fixed
< kallewoof>
Yeah, it's no biggie, but it had me scratching my head for a sec.
< kallewoof>
Also feels like "scriptPubKey": "<script>" | { "address":"<address>" } could just be... "scriptPubKey" : "<script or address>" since I don't think there's ever a case where you would confuse an addy for a script or vice versa.
< kallewoof>
Or rather, you can always determine which it is, I think.
< sipa>
the design makes things intentionally explicit
< sipa>
to minimize risk for having the RPC doing something other than what you intend
< sipa>
you also have to explicitly say you want something as watch only etc
< kallewoof>
sipa: Gotcha. Yeah, that makes sense.
< sipa>
it's certainly not the easiest thing to use as a human
< sipa>
but for programmatic access, none of these things matter
< kallewoof>
*nod*
< promag>
+1
< promag>
it doesn't try to guess, but it validates the input
< promag>
out of battery o/
< jimpo>
quit
< jimpo>
:facepalm:
< sipa>
hah
< sipa>
jimpo: i just had a look at bip157/158; do you think it's really necessary that the extended filter is mandatory for the p2p protocol?
< jimpo>
There was some discussion about how to do support for multiple filter types
< jimpo>
the first draft had a getcftypes/cftypes message pair where a client could query a node's supported filters
< jimpo>
but BlueMatt pointed out that it is something you want to filter nodes for before connecting (ie. exposed through addr advertisements)
< sipa>
i guess i mostly don't understand why the extended filter is useful
< jimpo>
so that was dropped and the service bit mandates nodes support all currently defined types
< sipa>
so it seems like a waste of space
< sipa>
but maybe i'm just missing the use case
< jimpo>
hmm, I can't remember the reason right now. roasbeef would know.
< sipa>
also, are there some numbers for how large the fikters typically are?
< jimpo>
I'm collecting that data right now actually
< sipa>
cool
< sipa>
ideally it should be some small multiple of 20 bits per element, i expect.
< jimpo>
right, the question is how many elements are expected per tx and how big they are compared to 20 bits
< jimpo>
I should have an answer shortly
< jimpo>
Thx for taking a look at the BIPs
< sipa>
i also suggested before that it may be better to index just the entire scriptPubKey rather than individual pushes in it (every realistic output type these days has just one push, so for practical things it's the same, and has less risk for someone filling up the filter with many tiny pushes)
< sipa>
but maybe that's a bit late to change (or there is another reason i'm missing)
< jimpo>
Regarding the extended filter, it sounds like there aren't concrete applications right now, but it's for more complex contracting applications
< jimpo>
So for example, in a world with MAST, you might want to find all txs with a particular script redeem clause
< sipa>
mhmm
< sipa>
in a world with signature aggregation there may not be anything to match o
< sipa>
i'm not convinced that's useful in the long term
< jimpo>
with sig aggregation aren't all of the pubkeys published?
< sipa>
and in general, when there is, that in itself is sort of a sign that we're regealing too much information
< sipa>
*key aggregation
< jimpo>
I guess I'm not up to date on whether you are planning on using MuSig or Bellare-Neven
< sipa>
BN, but this is orthogonal
< jimpo>
With BN, individual pubkeys are published, right?
< sipa>
yes, but there would generally just be one per output
< sipa>
BN is used across the inputs of a tx
< jimpo>
and regardless of key/sig aggregation, the use case of scanning for MAST redeem clauses still stands
< jimpo>
no?
< sipa>
ideally there would not be something to match on
< sipa>
i do say ideally here - i see how it could be useful
< jimpo>
he's something concrete:
< sipa>
but in general we should aim for systems where all outputs and inouts are indistinguishable
< sipa>
so the only thing to match on would be an exact output script, or an input (based on outpoint) spending iy
< jimpo>
say lightning contracts are implemented with MAST and you want to find the ones that are redeemed with a particular hash preimage (for some reason)
< sipa>
sure, for now
< sipa>
longer term i think we want to avoid having hash preimages?
< sipa>
i'm probably thinking further
< jimpo>
Perhaps
< sipa>
i'm just a bit hesitant about committing to building a filter that only has uncertain use cases now, and is really only usable in situationd that are already undesirable
< jimpo>
Ultimately, this becomes philosophical: do we want to have more options to be future-proof or only support uses cases that we can think of today
< sipa>
hmm, i think it's the other way around
< sipa>
adding a filter is easy if necessary
< jimpo>
I don't have a strong preference as long as the basic filter is in
< sipa>
removing one is hard, if there is an ecosystem that unnecessarily relies on ot
< sipa>
*on it
< sipa>
anyway, thanks for discussing it
< sipa>
and i'm looking forward to seeing some numbers
< karelb>
@spudowiar (not here now) had an idea - that it would be good to separate RPC documentation from the code, so things like https://github.com/bitcoin-core/bitcoincore.org/pull/526 could be generated (and fixed) more easily. I was thinking which format is best
< karelb>
since once you separate it into a format, you need to parse that :) if it isn't a C code
< ossifrage>
Has anyone shone interest in changing outbound rate limit works from a bytes/time interval to something a bit smoother?
< ossifrage>
I added the ability to specify the nMaxOutboundLimit on the command line and I use a 1 hour limit vs the default of 24hrs
< ossifrage>
But I still get these spikes where bitcoind will saturate my gbit connection until it consumes the 1 hour limit
< ossifrage>
I could rate limit at the firewall, but I don't want to slow down normal usage, just serving old blocks
< hkjn0>
hm, when building on armv7l, I a) build depends, b) do ./configure with --prefix set to depends/<arch>, c) make, this works fine, but unexpectedly leads 'make install' to put bins and libs in that prefix
< hkjn0>
i.e instead of bitcoind being installed in /usr/local/bin, I get: 'libtool: install: /usr/bin/install -c bitcoind /usr/local/src/bitcoin/depends/armv7l-unknown-linux-gnueabihf/bin/bitcoind'
< hkjn0>
I found https://cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_PREFIX.html which looked promising, but doesn't quite do it: 'libtool: install: /usr/bin/install -c bitcoind /usr/local/bin/usr/local/src/bitcoin/depends/armv7l-unknown-linux-gnueabihf/bin/bitcoind'
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12707: log: Be less confusing in the way we inform the user that logging has started (master...scrolling-can-be-fun-but-this-is-too-much-fun) https://github.com/bitcoin/bitcoin/pull/12707
< Guest39>
ping
< arubi>
hkjn0, you need to use --exec-prefix to set the install directory
< bitcoin-git>
[bitcoin] sipa opened pull request #12708: Make verify-commits.sh test that merges are clean (master...201803_cleanmerge) https://github.com/bitcoin/bitcoin/pull/12708
< hkjn0>
arubi: oh, so ./configure with both --prefix and --exec-prefix? thanks, will give it a try
< bitcoin-git>
[bitcoin] instagibbs opened pull request #12709: shuffle sendmany recipients ordering, since caller cannot control (master...shuffleoutputs) https://github.com/bitcoin/bitcoin/pull/12709
< provoostenator>
Alright, I went through the list of open Github tickets today. Hopefully helped a few get closed soon, but I may also have awakened a dragon or two.
< jimpo>
That's epic, provoostenator. Thanks!
< Randolf>
provoostenator: Dragons waking up now? Excellent, for cryptocurrencies need more dragons to scare the troublemakers away. :)