< kallewoof>
sipa: I may be slow, but I thought the coinbase transaction contained the witness commitment, so simply getting the hash of everything (including coinbase) should commit to witness commitment as well.
< sipa>
kallewoof: yup, it does!
< sipa>
you're right
< kallewoof>
sipa: OK, then I should be fine without GetWitnessHash, as the witness data is already committed to then, right?
< sipa>
yeah
< * sipa>
zZzZ
< jb55>
lol
< kallewoof>
Thanks :) G'night!
< kallewoof>
Matthew Haywood suggested that a UTXO for an address that was previously spent from should be called "associate". It is currently referred to as a "used" or "reused" address/output/balance. Associate balance. Associate output. I kind of like that.
< sipa>
i would suggested tainted, but that word has another meaning alreadg
< sipa>
not sure i like associate
< sipa>
it doesn't really convey badness
< sipa>
"exposed" ?
< * sipa>
bad at sleeping
< luke-jr>
kallewoof: addresses are never spent from
< kallewoof>
Exposed is nice, too.
< kallewoof>
luke-jr: I am bad at formulating this stuff, but you understand what I am saying.
< luke-jr>
kallewoof: I think the new paradigm you are introducing is harmful.
< kallewoof>
luke-jr: Mind explaining?
< luke-jr>
kallewoof: addresses have nothing to do with when the UTXOs get spent later
< luke-jr>
kallewoof: your new stuff is creating such a link, give credence to the "from address" myth
< luke-jr>
and not really solving more than a very narrow subset of the problems of address reuse
< kallewoof>
luke-jr: that is not my intention. I am trying to address a specific privacy issue where someone can map your UTXO set.
< luke-jr>
it's because it's too specific/special-cased
< luke-jr>
seeking to have a term like "associate" above demonstrates the problem with it IMO
< luke-jr>
no such term should exist, because it's not a real relationship
< kallewoof>
I am a bit confused, to be honest. If I ask you for an address to send you a payment for some service, I then know that this address is with very high accuracy belonging to luke-jr. If you spend from it, I know with reasonable accuracy that you own at least one of the outputs unless you have no change output. If I then send to that address and you use it again with other inputs, I know those inputs are luke-jr.
< luke-jr>
kallewoof: you don't spend from an address, and spending the UTXO is not necessarily the same person you sent to
< luke-jr>
sending a transaction with 1 output pays 1 address and creates 1 UTXO, but the address and UTXO are not inherently related
< kallewoof>
I am a bit confused, to be honest. If I ask you for an address to send you a payment for some service, I then know that the UTXO resulting in me sending money to this address is with very high accuracy belonging to luke-jr. If you spend this UTXO, I know with reasonable accuracy that you own all the inputs unless it's a coinjoin or something. If I then create another UTXO by sending to that address and you use this UTXO
< kallewoof>
with other inputs, I know those inputs are luke-jr as well.
< kallewoof>
Yes, but the normal case is that a UTXO belonging to you does not suddenly change ownership.
< luke-jr>
the address represents the recipient and purpose of the payment; the UTXO controls the actual funds, and may very well be part of a shared wallet
< luke-jr>
there is no assumption of a normal case
< luke-jr>
(and shared wallets are fairly normal too anyway)
< luke-jr>
(shared wallets are also a best practice in custodial situations)
< kallewoof>
luke-jr: I would love to fix this, but I'm not sure what good phrasing would be. Would you be up for making a PR?
< luke-jr>
kallewoof: I don't know what you mean. The problem is the behaviour, not phrasing.
< luke-jr>
(well, maybe phrasing is also an issue, dunno - but it's not the main issue)
< kallewoof>
luke-jr: Why did you not concept NACK either of the PRs? There were two of them. This has been going on for 2 years..
< kallewoof>
luke-jr: I may not agree with you but at least we could have discussed the direction before it was merged.
< luke-jr>
I thought I did and got ignored
< kallewoof>
luke-jr: you said "it does not fully address the problem with address reuse". That's not a concept NACK on the code itself, it's saying "this is not enough".
< luke-jr>
"an address that has been used before, and the UTXOs received at the same time have been spent" should neither have a term nor affect behaviour
< kallewoof>
which I interpreted as "we need to do more beyond this" (but it's a start)
< kallewoof>
luke-jr: Should wallets avoid spending UTXO:s that are associated with a pubkey that is known to have been spent by the wallet itself?
< kallewoof>
luke-jr: Should wallets distinguish between these, and other UTXO:s, in any way?
< luke-jr>
kallewoof: IMO wallets should not accept multiple payments with the same address, and if they do, should flag them all as permanently unconfirmed until the specific UTXOs get spent (which is kinda unrelated to the payment, but confirmations usually are anyway)
< luke-jr>
(or possibly flag one as confirmed, and spend only that one by itself, waiting for it to be confirmed before any others are spent)
< kallewoof>
luke-jr: Since miners can still mine those payments, you are saying that wallets should dinstiguish between them. That is what #13756 does, right?
< luke-jr>
kallewoof: based on the address reuse alone, not address reuse PLUS "the UTXOs created were spent"
< sipa>
what does the utxos being spent have to do with it?
< kallewoof>
luke-jr: So basically, take what I did and add a further restriction where it immediately marks up the 2nd+ payments, even if I ahvent spent the first, right?
< luke-jr>
kallewoof: right
< luke-jr>
sipa: the current behaviour is the same as before, until a UTXO is spent
< sipa>
ah
< sipa>
i don't understand what spending has to do with it still
< luke-jr>
kallewoof: some care may be needed in the case of multiple un-mined transactions paying the same address; you'd probably want to mark the lower value regardless of arrival order
< sipa>
or whether you're talking about behavior in a release, in master, or how you imagine it
< kallewoof>
sipa: idea is, even if you send multiple times, no harm/no foul until i spend it. assuming i spend it all at once, you wont gain anything from giving me extra money.
< luke-jr>
kallewoof: but there IS harm/foul
< luke-jr>
just not that narrow specific case you addressed
< kallewoof>
luke-jr: I mean, yes, but the harm/foul happened before I even spent the outputs.
< sipa>
well the issue is someone *expecting* multiple payments to the same address
< sipa>
that issue is addressed by educating
< sipa>
once the payments have been made, there is a distinct issue, which is a privacy loss
< sipa>
which only manifests if being paid again after already having spent the first utxo
< luke-jr>
the current-master strange behaviour is only going to make education worse :p
< sipa>
i doubt that
< kallewoof>
I need to go, but I will see if I can figure out what the problem is and how to fix it. I am honestly a bit confused. And surprised.
< luke-jr>
it will further the myth that address reuse is only harmful if you "spend from" it first
< luke-jr>
(which will in turn strengthen and for the first time give Core credibility to the "from address" myth)
< fanquake>
meshcollider when thinking about the wallet GUI, what end user do you normally have in mind? Somewhere on the spectrum of "new non-technical user, just downloaded Bitcoin Core" & "one of the engineers that helps build Bitcoin Core"?
< fanquake>
Just trying to figure out who we are targeting in #15450. Seems like it's leaning towards engineers.
< meshcollider>
fanquake: usually the former, I think more advanced users will prefer to use the command line anyway, I think the two main purposes the GUI serves in my mind is 1) for less technical users that just want to start it up and run bitcoin, and 2) for more advanced users to do stuff that would be really painful on the command line like coin selection stuff
< meshcollider>
in that specific case, I think multiwallet is not inherently complicated if create, open, close, whatever are all available in the GUI?
< fanquake>
Fair enough. I think we should really be trying to optimise for 1) (with hidden options/config etc still available for 2)).
< meshcollider>
but at least in my mind, most computer-users are familiar with basic open, close, create commands, it seems natural to have a create command if we already have decent GUI multiwallet support
< fanquake>
Yea I've got no issue with create. I'm thinking in the create flow. In the ideal non-technical user world, we've just got the name field, with those other three options hidden in a "Advanced Users" drop-down (and encrypt wallet checked by default, if that's not too aggressive).
< fanquake>
and there'd be no way to tick encrypt wallet, and actually end up with an unencrypted wallet.
< meshcollider>
yep
< meshcollider>
that would suit the general use case fine IMO
< fanquake>
I'm even concerned "Make Blank Wallet" is going to get ticked quite a lot, when users don't mean it, because the logical non-technical thought will be, why would I want anything other than a blank wallet..
< fanquake>
I'll add my thoughts to that discussion anyways.
< meshcollider>
+1
< achow101>
fanquake: I looked at having the options hidden, but I couldn't figure out how to do it in qt with a lot of hacks and things I don't know how to do
< achow101>
Re blank wallet, do you have any suggestions for a better name?
< fanquake>
achow101: That's fair enough. I'm not sure re "Blank", going to think about it a bit more.
< ossifrage>
I have 'onlynet=ipv4' in my bitcoin.conf, but I saw this today (with 2cbcc55ba) "Error: Couldn't open socket for incoming connections (socket returned error Address family not supported by protocol (97))"
< ossifrage>
Hmm, I looked back over the logs and it has been doing that for a while.
< sipa>
ossifrage: onlynet is about outgoing connections, it does not affect incoming