< fanquake>
dongcarl Sorry for the delay, getting to Guix capabilities today. Was sidetracked with other depends stuff.
< jonasschnelli>
I was waiting for Voskuils mailing list reply... *sigh*
< nothingmuch>
while his points are valid, i never quite understood the actual objection is
< jonasschnelli>
his points are valid... but he fails to see the current state as well as the potential of v2 for its future
< nothingmuch>
i'm not sure if that's a charitable interpretation, i just think he interprets the current situation & potential differently, if i'm not mistaken his main objections are to the accompanying peer authentication? maybe more precisely, i don't understand why he predicts censorship as the most likely outcome
< jonasschnelli>
peer authentication is happening and going to happen in future. We currently authenticate with the IP (-connect=IP)... there are many users doing this.
< jonasschnelli>
Also, the opportunistic encryption sets a much higher burden for a MITM... a) active interception rather then just manipulating/listening packages, b) risk of being detected
< jonasschnelli>
Right now, an ISP can spy on your and even tamper and you would have almost zero chance to detect this. The possibility of detection alone is a feature
< echeveria>
you're not wrong.
< echeveria>
in a lot of situations they could just connect back to you on 8333 if they wanted to though.
< nothingmuch>
unauthenticated opportunistic encryption i think can also be argued for empirically, e.g. bittorrent throttling in the past
< nothingmuch>
i guess what i'd better like to understand is why he thinks censorship is any more likely with these features than without, the way i see it there is about as much potential right now
< nothingmuch>
the way i see it, if anything, improving privacy at the p2p level would make censorship harder, but at any rate it's not a 1 dimensional spectrum
< echeveria>
I couldn't work that out. its pretty clear what is running bitcoin, from the traffic or the port number.
< harding>
echeveria: encryption by itself, if we assume no mitm and no eclipse, improves own-transaction relay privacy in combination with Bitcoin Core's existing tx trickling code. Right now when you send your own transaction, spy nodes can't be sure whether you originated a transaction or just relayed it. However, your ISP can see that you never received the tx over clearnet before sending it, so unless your node is also on Tor or
< harding>
otherwise multihomed, the ISP can determine what txes you originated.
< echeveria>
harding: so, they just connect to you directly if you're listening.
< echeveria>
all of this is really difficult to reason about. encryption in networks with anonymous peers.
< harding>
echeveria: yes, but (as I mentioned) Bitcoin Core trickles txes. That is, it doesn't send to each of its peers immediately but separates all of its peers into buckets of peers and maintains a queue of transactions for each bucket, sending to all the peers in the bucket on some schedule. This means a transaction may be propagated to a non-spy node, relayed through the network, and then heard about by the spy node from some other
< harding>
peer before the spy node hears about thet transaction from your peer.
< emilr>
any reason against using ssl Electrum style? Each peer has its own self generated certificate, download the cerfiticate at first connect and then use that certificate to authenticate the peer
< nothingmuch>
emilr: from a trust/security POV, that's essentially what the proposal enables, but with lower complexity than TLS (no crypto agility, no PKI, ...)
< wumpus>
main reason for not using ssl is that it adds too much attack surface, and its complexity makes it hard to be confident in its security
< achow101>
sipa: any ideas on how addmultisig and multisig in general will work with thew plan for the new ismine logic? I've started working on replacing the ismine logic but I ran into some problems with multisig and the current ismine weirdness surrounding that.
< sipa>
achow101: so i think you'd have the "old world state" and "new world state", which are independent, and if either of them says an output is yours, it's yours
< achow101>
my plan was to make it so that what is currently considered ismine wouldn't actually change, but that seems to not be possible
< sipa>
and addmultisig would keep interacting with just the old state
< achow101>
bleh
< sipa>
i don't think there is any other way
< sipa>
in the old mechanism, things interact in stupid and unpredictable ways
< sipa>
that just don't fit in the descriptor based view
< sipa>
at some point it may be useful to try to convert the old state into a new state, and then disable RPCs that interact with the old state
< sipa>
but i think that's better done as a separate thing from actually supporting both
< achow101>
what about getting rid of addmultisig and just make people use createmultisig and importmulti if they want that script and watch it?
< achow101>
the import stuff actually makes sense under the new ismine
< sipa>
in a descriptor based wallet you have no need for either RPC
< sipa>
you can just import a descriptor with the multisig key in it directly
< sipa>
maybe a utility function that has input compatible with createmultisig that spits out a descriptor is useful
< achow101>
i wanted to avoid having two separate ismine logics
< sipa>
i fear that's going to be very hard
< gmaxwell>
I wonder if anyone is actually using addmultisig.
< sipa>
achow101: to be clear, i think it's just hard for compatibility reasons - if you don't, you need to do something like convert an old wallet to the new design on first use with new code... and that will inevitably change the semantics of some existing RPCs
< sipa>
plus that conversion is nontrivial
< sipa>
and presumably that conversion will effectively need a copy of the old ismine logic anyway
< achow101>
From what i've done so far, converting a wallet that doesn't have multisig is pretty straightforward
< achow101>
and afaict it doesn't require the old ismine logic
< sipa>
possibly
< sipa>
though there are weird edge cases around single-key things as well (like requiring a p2sh version imported before native segwit outputs are treated as ismine)
< gmaxwell>
Keeping around the old thing and bolting something new on the side is a fairly simple thing that has some pretty good guarentees for compatibility.
< gmaxwell>
Anything else will take more work and not guarentee compatibility as strongly.
< sipa>
newly created wallets can lack the old state altogether, and just not support addmultisig (and possibly other RPCs)
< gmaxwell>
We could also depricate addmultisig, so you have to set a config option to get access to it, in order to stop people from using it.
< gmaxwell>
(... if any are...)
< achow101>
gmaxwell: I'm tempted to do that
< gmaxwell>
I earnestly doubt anyone is using.
< sipa>
that seems reasonable now we have a more usable importmulti and descriptors... but it doesn't solve the problem of what to do with wallets that have it
< gmaxwell>
sipa: yes, you and I have but we don't count.
< gmaxwell>
(as you and I would just use importmulti...)
< sipa>
importmulti has the same problem
< achow101>
does it?
< sipa>
you can emulate whatever addmultisig does using importmulti
< gwillen>
can someone help me remember / grok the difference between addmultisig and createmultisig+import
< sipa>
gwillen: createmultisig just computed the address/redeemscript you'd import if you would have used addmultisigaddress
< sipa>
but it's a utility rpc instead of a wallet rpc
< gwillen>
interesting
< sipa>
achow101: so there is an open question around importmulti in the new state, i think
< sipa>
importmulti lets you specify exactly which outputs you're talking about... but then effectively imports things in a way that quite possibly affect other outputs as well
< achow101>
sipa: importmulti will explicitly add the script as watchonly if you don't have the keys. I don't think addmultisig does that so spends to the multisig wouldn't be considered ismine or watchonly
< sipa>
achow101: good point; you need addmultisig+importaddress to emulate importmulti
< sipa>
the question is whether in a post-native-descriptor design, importmulti can have its semantics changed to only affect the outputs you're actually talking about
< sipa>
(because i've seen people talk about calling importmulti multiple times taking advantage of the interaction to accomplish missing things... )
< achow101>
imo with the native descriptor design, all existing import rpcs should just not work on those wallets
< sipa>
agree
< sipa>
there should just be importdescriptor or importrecord or something
< sipa>
but then i do think the cleanest design is to just keep the old state around, and as long as you have old state... the old RPC work on that
< sipa>
and new RPCs work on the new state
< sipa>
as otherwise you'd force people to adopt a new set of RPCs whenever their wallet gets upgraded
< gwillen>
let me bang the drum as usual for doing the split at the wallet level
< achow101>
.. right. I see how that is the safest and most compatible way to go about this
< gwillen>
your old wallet has old RPCs, your new wallet has new descriptor-native RPCs
< gwillen>
the two never to mix
< sipa>
gwillen: i think that's fair from a user perspective... but it doesn't really simplify the code (beyond have a restriction that you can't have both states at the same time)
< achow101>
well somethings of the old design might leak into the new design due to use in a lot of places. e.g. isminetypes
< sipa>
those are fine
< gmaxwell>
creating a sharp line between old wallets and new wallets sticks users with old functionality until they create a new wallet (and probably make a privacy destroying sweep-- since we can't spend across wallets).. it also splits up the user/testing base.
< gmaxwell>
it might be justifyable if the new thing were just done, but its constantly advancing, we can't really use 'make a new wallet' as the general upgrade mechenism for each new version.
< achow101>
gmaxwell: there should be someway to upgrade from old to new with some caveats regarding ismine
< sipa>
achow101: i think we want to generalize what "watchonly" means, so it becomes independent from the question whether you happen to have the private key exactly in your wallet.dat file (so for example a HW wallet doesn't need to be marked as watchonly...),
< achow101>
sipa: in my current design, i have watchonly be defined as existing in setWatchonly and mine as existing in a newly introduced setScriptPubKeys
< sipa>
gmaxwell, achow101: i think a correct conversion from old to new is possible, but it will (a) involve the old IsMine logic and (b) preferably something that isn't forced upon you when you upgrade software
< sipa>
i really think watchonly should just be a boolean in the descriptor record
< sipa>
saying "do i want to treat things that match this as really mine, or just something i'm watching"
< gmaxwell>
Why shouldn't the concept of watch only be eliminated and replaced with signing sources, with null a potential signing source.
< gmaxwell>
?
< achow101>
the way I imagined it was that descriptors would be expanded to sets of scriptPubKeys and, depending on that bool, the scriptPubkeys would go into the appropriate set
< gmaxwell>
sipa: that boolean split alone isn't the most useful... esp because it is just a single category.
< sipa>
gmaxwell: for example a multisig you're participanting is may be something you want to watch, but not count as your balance
< sipa>
i expect gwillen to now say "just use a separate wallet for that", and he's probably right
< gmaxwell>
sipa: make a seperate wallet?
< gmaxwell>
The fact that watching has only a single category "watching" makes it much less useful...
< sipa>
true
< achow101>
gmaxwell: that would be ideal, but breaks upgrading I think
< * sipa>
lunch
< gmaxwell>
well let me revise, there is a seperate "non-balance" functionality that is useful: collecting txouts for filling a PSBT.
< gmaxwell>
I agree _that_ kind of watching actually is useful, doesn't need special categories, doesn't interact with balances, etc.
< midnightmagic>
+1 filling txouts for PSBT
< gmaxwell>
achow101: breaking upgrading for more obscure features isn't something we should reject out of hand.
< gmaxwell>
achow101: we could allow an upgrade that stripped out all watching (or converted it into something else)
< achow101>
well I suppose an upgrade could just make two wallets
< gmaxwell>
right.
< gwillen>
yeah, I do maintain "keep separate wallets for separate sorts of funds" is the right call
< gmaxwell>
gwillen: I agree, but I expect that virutally no watchonly use is 'seperate funds' (esp because the user interface for watching is mostly unusable), it does however get used to provide inputs e.g. for multisigs.
< gwillen>
well my thinking is like, if you have your own funds in a wallet, and you also have keys that represent part of a multisig that holds funds
< gwillen>
it's better for those to be two separate wallets
< gwillen>
rather than try to puzzle how how we should define 'watchonly' and 'ismine' to make that scenario work smoothly
< gmaxwell>
another way of looking at this is that provide general random access indexes scriptpubkeys isn't particularly viable, we don't do it, and don't plan to do it... our answer to needing to find inputs for random scriptpubkeys is "add them to a wallet before use so the wallet will track them"
< gwillen>
e.g. you will probably not want to spend "some funds from my wallet and also some funds from the multisig" in the same tx
< gwillen>
although I guess if you did ever want that, it's an argument against separate wallets
< gmaxwell>
I think you're talking past me.
< gwillen>
probably
< gmaxwell>
"some funds from my wallet and also some funds from the multisig" isn't something that is usable with watchonly now.
< gwillen>
mmm, heh, that's a good point
< gmaxwell>
It is one of the problems with the "use lots of wallets for all the things" line of thinking however, but I think that isn't a concern in this discussion.
< gmaxwell>
I think right now the thing watchonly actually gets used for is simply telling the wallet to collect data for providing inputs to transactions, without getting in the way of normal wallet use.
< midnightmagic>
+1 that use; also informational tracking of known addresses.
< gmaxwell>
now, this could be done by just making another wallet, throwing everything you want to collect data on in it and then ignoring it otherwise.
< gmaxwell>
midnightmagic: I don't believe it's used like that right now, there isn't for example, a usable way to get balances, and presumably you want to watch more than one such thing.
< gmaxwell>
It gets used by things like custom wallet software to make bitcoin core track data needed for spending. I assume electrum personal server uses it. Joinmarket uses it.
< achow101>
gmaxwell: instead of a watchonly wallet, use scantxout set :p
< midnightmagic>
gmaxwell: I'm currently using: b -rpcwallet=weirdwallet.dat listunspent|grep -A 2 -i weird|grep amount|awk '{ print $2 }'|sed -e 's/,//g' | paste -sd+ | bc -l
< gmaxwell>
achow101: doesn't work if you need to see past spends, and alsoscantxoutset is pretty slow!
< gmaxwell>
but perhaps the concept should be dropped and replaced with something that better fits how its mostly being used.
< achow101>
if you're just filling psbts, you don't need past spends
< gmaxwell>
midnightmagic: okay, well if you actually want to follow some other wallet I think thats a case where running a seperate wallet file makes sense to me.
< midnightmagic>
Just a hackish informational thing that means I don't have to use bitcoin-iterate
< midnightmagic>
+1 laziness
< gmaxwell>
achow101: yes, but examples I listed do more than just fill out psbts.
< gmaxwell>
But they don't need balances, coinselections, etc.
< bitcoin-git>
[bitcoin] instagibbs opened pull request #15664: change default Python block serialization to witness, test round-trip (master...default_wit_block) https://github.com/bitcoin/bitcoin/pull/15664
< BostX>
Hi, do you know why signrawtransactionwithwallet returns the same hex as entered?
< sipa>
presumably because it couldn't sign anything
< BostX>
sipa: but it was completed with "true"
< sipa>
then it's already fully signed!
< BostX>
sipa: that's impossible
< sipa>
BostX: what's the input?
< sipa>
(you can pm me)
< BostX>
sipa: I created: bitcoin-cli createrawtransaction '[]' '{"unused-new-address": <number>}'
< BostX>
sipa: then I was returned the hex
< sipa>
BostX: you have no inputs, so all inputs are by definition signed
< sipa>
you probably want to call fundrawtransaction first to add inputs and change
< BostX>
sipa: I thought the createrawtransaction '[]' knows automatically how to add an input.
< BostX>
sipa: what is a `change`?
< sipa>
BostX: perhaps you should head to bitcoin.stackexchange.com
< sipa>
you shouldn't be using these RPC functions if you don't know what change outputs are
< BostX>
sipa: Uhm... I'd like to sign my TX on an offline computer where I don't want to install anything other than bitcoin-core.
< sipa>
BostX: yes, this is the wrong place to ask such questions
< BostX>
sipa: not really - I wasn't asking "how" I was asking "why it doesn't work", since I got no(!) errors. I consider this to be a legitimate question for this place.
< sipa>
BostX: well, the answer is that your transaction has no inputs, so signrawtransactions responds by saying all your inputs are signed
< BostX>
sipa: yes yes I was also asking "what is a change" but I'm able to figure it now by myself... don't worry.
< sipa>
which is expected
< BostX>
sipa: maybe some warnings would be helpful. Like "You're signing a TX w/ no inputs". Or maybe a better message in the `bitcoin-cli help signrawtransactionwithwallet`
< achow101>
BostX: If you are planning on using an offline computer, I recommend using the psbt RPCs