< provoostenator>
Tl&dr it would be nice to have a dialog for wallet creation which check boxes for what we have now, i.e. "watch-only" and "blank", so that we can later expand that.
< provoostenator>
In addition I think the same or a similar dialog can be used to recover wallets. Could be loading a wallet dump file, entering some descriptors or even bip39 phrases.
< provoostenator>
Such a recovery also needs some room, e.g. we would could ask the earliest usage day for rescan purposes. We could even ask if the user knows a few random addresses, so we can guess the derivation paths, but that might be a bit too fancy.
< provoostenator>
For using existing hardware wallets I imagine the HWI scripts will give hints of what derivation paths to use, so the UI doesn't have to. Maybe some devices even know what date they were initialized.
< bitcoin-git>
[bitcoin] AkioNak opened pull request #15439: tests: remove byte.hex() to keep compatibility (master...keep_compatiblity) https://github.com/bitcoin/bitcoin/pull/15439
< wumpus>
provoostenator: yes, such a dialog would be nice to have, though probably shouldn't be thrown in the user's face by default (to overwhelm them with choices), more like an 'advanced' wallet creation dialog
< gmaxwell>
A general UI design principle is that if the developer doesn't know, the user also doesn't know. Also if you force the user user to choices they don't understand, they'll frequently set them randomly. If they want to accomplish something specific, they'll go looking for it, and try using the first thing that sounds like it.
< wumpus>
I mean, it would be for people that do know the functionality and want to choose themselves
< gmaxwell>
absolutely. sorry.
< gmaxwell>
My point is that if your usecase is something where the user will know they want it, it's fine to bury it... just make sure they won't find something else first while looking for it.
< wumpus>
I'm also a bit skeptical about, say, the GNOME user interface design where the developer always makes the choices and settings and such are buried deeply in some kind of gconf nightmare tree
< wumpus>
the "all GUI users are idiots" philosophy
< gmaxwell>
oy. "you can edit the code if you are a power user" is not a great UI design principle. :P
< wumpus>
yesss that's what I mean
< wumpus>
even worse :P
< gmaxwell>
(gconf is pretty much that... gconf settings aren't stable across versions... almost as bad as carrying patches)
< gmaxwell>
The user uses the software specifically to avoid writing it and maintaining it themselves. :P
< gmaxwell>
I am just imagining a create dialog with a text entry box where you can enter a seed, and then confused users not realizing they can ignore it, googling bitcoin seed and entering in some example they found online.. :P
< wumpus>
that'd be a good example of terribly unsafe GUI design, yes, meant as useful functionality but it only serves as a trap for the unknowing
< provoostenator>
It helps not to cram too much on a single screen. Instead you can e.g. have a button "Recover an existing wallet" which takes you to another screen which then handles the various options.
< bitcoin-git>
[bitcoin] Sjors opened pull request #15441: [doc] build: warn against spaces in working directory (master...2019/02/build_discourage_space) https://github.com/bitcoin/bitcoin/pull/15441
< wumpus>
eek, kinda unbelievable that spaces in directory names is still a problem in 2019 :/
< wumpus>
this means there's some very unygyenic code somewhere
< wumpus>
unhygienic*
< luke-jr>
maybe we need to use it in test dirs in addition to unicode
< wumpus>
I'd much prefer that solution to "put a warning in all docs", this really doesn't look good on us
< promag>
why this fails? getdescriptorinfo('pk(xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8)')
< wumpus>
what error do you get ?
< promag>
Invalid descriptor
< promag>
thats straight from doc/descriptors.md
< wumpus>
might be it's for the wrong network (regtest/testnet or mainnet)
< harding>
promag: works for me via bitcoin-cli on mainnet using commit 4064d048d6 (master from Sunday). Rebuilding now to try on latest.
< promag>
ok then it's what wumpus said
< wumpus>
might be useful to mention the network that was used for the example, in descriptors.md
< instagibbs>
GAit, I'd be willing to champion 10823 if you don't have the time
< sipa>
promag: xpub is for mainnet
< provoostenator>
Ideally we would have a way for RPC help to spit out correct examples for mainnet, testnet and regtest.
< provoostenator>
I've made this mistake a few times too.
< instagibbs>
:) only returns a result if vanitygen returns something starting with `1Example`
< luke-jr>
otoh, maybe a key/value editor that changes bitcoin_rw.conf would be sufficient? dunno
< wumpus>
well bitcoin_rw.conf overrides bitcoin.conf so...
< wumpus>
could be used for exactly the same
< luke-jr>
yeah, I guess it would work
< luke-jr>
on another note, I wonder if we actually need txindex to require reindex anymore.. now that it's separate, I guess as long as the user hasn't pruned, it could probably be built post-hoc
< wumpus>
there's no conceptual reason why making an index requires wiping all indices, this is just how it happens to be right now
< luke-jr>
I guess -txindex=0 shouldn't destroy an existing index, maybe -txindex=delete
< wumpus>
I'm not sure it's worth changing that at this point
< wumpus>
in principle, if it wasn't bound to reindex, the action of creating/destroying an transaction could even be an RPC command instead of a command line option
< provoostenator>
But not how the random thing was chosen :-) But yes it seems to have been to make collision unlikely enough, but blocks not much bigger.
< cjd>
ahh cool
< luke-jr>
eh, outputs aren't random. a collision is avoided by just not colliding.
< luke-jr>
so long as there's *some* 32 bits there, other proposals just avoid using the same 32-bit value
< provoostenator>
luke-jr the 0xaa21a9ed prefix is random
< luke-jr>
provoostenator: it doesn't need to be, is my point
< jarthur>
I've been meaning to ask about the witness reserved value. BIP 141 seems to indicate that it can be anything, and yet also that it might have future consensus meaning. Is there any way to pick a witness reserved value that won't collide with future soft forks without knowing how those soft forks will use the field?
< sipa>
jarthur: just don't use it for anything and you're fine
< jarthur>
sipa: but if I'm a miner, what should I set it to in my new blocks?
< sipa>
whatever.
< sipa>
that comment means that it shouldn't be used to convey any meaning, because that meaning may be constrained in the future
< sipa>
just set it to zeroes
< sipa>
or to "blahblahblahblah"
< luke-jr>
well, if it's constrained in the future, setting it non-zero may make blocks invalid, no?
< provoostenator>
Oh, the way I read BIP-141 is that it must be exactly 0xaa21a9ed.
< sipa>
provoostenator: jarthur is asking about something unrelated
< luke-jr>
provoostenator: the topic changed
< sipa>
(witness reserved value vs witness coinbase commitment)
< jarthur>
sipa, if we need to constrain its meaning in the future, will we need to look back what what values have been used by miners to make sure there's no collision? Could a miner troll us by incrementing it like a nonce over years to ensure there are less available reserved values for soft-forking purposes?
< sipa>
jarthur: no?
< provoostenator>
jarthur: I assume a future soft fork won't care about historical values before it was activated
< sipa>
the softfork will obviously only affect future values, not ones in the past
< jarthur>
OK, great, thanks :)
< luke-jr>
well, it'd potentially make the code cleaner after the softfork activates, if we can just have it unconditional
< luke-jr>
so it'd be *nice* of miners didn't make blocks with potentially-conflicting values :p
< luke-jr>
jl2012: I don't understand your last email. My point is, if you don't want NOINPUT, it should be sufficient to just not sign with NOINPUT..
< gmaxwell>
luke-jr: unfortunately no. If noinput can show up anywhere, then if you cannot _guarentee_ that you'll never pay to an address twice (e.g. splitting a payment in two in order to pay from both a hot and cold wallet) then you can only pay to 1xxx addresses. Otherwise you risk paying, having the payee noinput spend, and then having funds get lost. Then they get embroiled in some stupid lawsuit
< gmaxwell>
overwhos fault it was. That kind of footgun isn't what you expect from bitcoin engineering, it sounds like something ethereum would do.
< gmaxwell>
(also are you responding to messages that aren't on the list? -- I don't see any really recent message from jl2012)
< luke-jr>
gmaxwell: I guess the list copies are waiting for moderation
< luke-jr>
sending twice to the same address is always the sender's fault and should be considered undefined behaviour
< gmaxwell>
personally I prefer noinput be dropped from the proposal for now-- it's basically caused months of delays now at this point. And the initial schnorr support already doesn't support aggregation or graftroot, so we know there needs to be a subsiquent version regardless.
< gmaxwell>
luke-jr: Perhaps, but thats not relevant. It is bad engineering to make a small (and fundimentally very hard to avoid mistake) into a reckless one. Look at all the extreme money losing things that we've mocked in eth land, almost all of them also involved mistakes on the user's part.
< gmaxwell>
Good engineering isn't just building something that works if you use it perfectly.
< luke-jr>
gmaxwell: it's already reckless. there's no guarantee it works today.
< gmaxwell>
It's also about building something that fails gracefully.
< luke-jr>
IMO it's not much different from accidentally sending with the wrong fee
< luke-jr>
these are things user applications can try to protect, but not things the protocol should be trying to second-guess
< gmaxwell>
and we worked hard to make that less possible, e.g. segwit inputs sign the input amounts now.
< gmaxwell>
luke-jr: and reuse is fundimentally hard to guarentee never happens, you essentially need a consensus system to do so.
< luke-jr>
you could avoid wrong fee without signing input amounts - the benefit there was to avoid the extra data needed for it
< luke-jr>
a person can easily avoid sending to the same address twice, and since addresses aren't meant to be reused, no more than one person should ever be on the sender side
< luke-jr>
you don't need a consensus system to coordinate a single sender's actions
< luke-jr>
(and if someone sees the address on the network and sends to it too - there are obvious ways to deal with that)
< gmaxwell>
People do accidentally double pay, today. It happens, it's not conjecture. People also do intentionally split one payment into two txouts.
< gmaxwell>
"obvious ways to deal with that" is handwaving.
< luke-jr>
you just display only the higher value one as confirmed; or spend them all together and ignore future outputs to that key; etc
< harding>
luke-jr: let's say you design a wallet to always sign noinput, as you've proposed. Alice sends a large payment to Bob with a low fee, accepting that it'll take several days to confirm. Griefer Mallory sees that tx in the mempool and sends a tiny payment with a high fee to the same address. Your wallet receives Mallory's payment and happens to respend it with noinput before Alice's payment confirms. Now Alice's payment can be
< harding>
stolen even though Alice herself didn't engage in address reuse.
< gmaxwell>
If you've even seen the 'higher one' yet. (so your 'obvious way' requires as a starting premise that wallets ignore all unconfirmed transactions, and arguable all non-deeply confirmed transactions, since there still could be a reorg)
< luke-jr>
harding: you're assuming Bob is offline at the time and doesn't see Alice's until after spending Griefer's?
< harding>
luke-jr: we can't guarantee Bob has a complete view of all possible mempools in any case.
< luke-jr>
gmaxwell: I don't see why you say ignoring unconfirmed; just not showing them as confirmed, since they aren't
< gmaxwell>
because if you spend the wrong one you'll burn money. not showing them as confirmed isn't enough.
< luke-jr>
harding: okay, I see how that can be a concern; but it's one easily addressed by just not implementing a wallet using NOINPUT that way
< luke-jr>
arguably if you do so anyway, it's the same as picking the wrong fee would be
< gmaxwell>
(to be clear, I want to have the functionality eventually, but it clearly has risky implications and has now added months of delay to an otherwise mostly complete proposal)
< gmaxwell>
(which was exactly the reason that graftroot and aggregation were left out)
< luke-jr>
harding: (also, actually, since the value in signed, I think I can argue your threat model is not a real issue, but that's beside the main point: that these limits shouldn't be at the protocol level)
< luke-jr>
is signed*
< gmaxwell>
value being signed is just one of the first protections that were added to make this not a complete disaster proposal...
< luke-jr>
(because even if Griefer's UTXO is the one that gets seen/spent first, it still paid the correct amount to the address given to Alice, so it doesn't actually matter if Alice's UTXO gets lost)
< gmaxwell>
unfortunately there are still a lot of really easy loss vectors even with that mitigation. Months have now been spent trying to cook up better mitigations.
< luke-jr>
gmaxwell: but my point is that for a protocol level feature, just saying "don't do that" is a reasonable mitigation
< luke-jr>
these things can/should be addressed by the wallet software
< gmaxwell>
luke-jr: thats like saying ECDSA as it originally was because "use a strong random number and don't repeat it" is a reasonable mitigation.
< gmaxwell>
In reality that approach causes failure after failure after failure.
< gmaxwell>
At some point the designer of a system cannot credibly fob off fault onto the users.
< gmaxwell>
We build systems to be used by real people, not platonic errorless perfectly knowledgable people.
< gmaxwell>
We do know how to make noinput safer but it has been slowing down the work on this functionality.
< gmaxwell>
We already set aside graftroot and aggregation, both of which are significanly more valuable than no input, in the interest of focus and time.
< sipa>
the argument why it was included in the first place also disappears if we're aimimg for output tagging (because doing it separately would inherently require a "tag" as in a separate witness version)
< luke-jr>
gmaxwell: yet we don't try to enforce random number strength in the consensus protocol
< sipa>
luke-jr: can we?
< gmaxwell>
luke-jr: we would if we could but we can't so we don't.
< luke-jr>
sipa: you would know better than me, but not that I'm aware of
< gmaxwell>
But bip schnorr proscibes a secure procedure-- which can be easily followed, it doesn't just say "this has to be random, good luck!"
< luke-jr>
gmaxwell: why don't we enforce the absurd fee policy as a consensus rule?
< booyah>
uhm is this not typical for crypto protocols to start with "we assume you can provide good, unique, randomness"?
< gmaxwell>
luke-jr: because it has to change over time, otherwise I would say we probably should.
< gmaxwell>
booyah: For an academic analysis, sure. For a pratical engineered system for people to actually use-- only incompetent ones that cause misery to their users.
< booyah>
and as separate consideration we could provide algorithms to try to improve on OS-provided random
< gmaxwell>
you won't find any crypto apps that just prompts there user to proide randomness or some such stupid thing. :)
< booyah>
is bitcoin somehow improving strength of normal random as provided by OS specific api?
< gmaxwell>
(or to the extent that they do, like brainwallets tools, they cause continual failure)
< gmaxwell>
booyah: yes, though you're offtopic.
< booyah>
gmaxwell: well not user, I mean the OS random source
< gmaxwell>
booyah: bip-schnorr doesn't need any randomness for signing at all. (nor does our ecdsa implementation... but clasical by the book ECDSA does, and as a result is an ocean of failure)
< luke-jr>
there are lots of easy ways to make mistakes that we can't prevent. I don't see why preventing a few unusual cases by limiting functionality is a good idea.
< gmaxwell>
Whats being limited? there is no way to noinput today. The system was designed otherwise, and having it really throughly breaks assumptions.
< luke-jr>
in this case, going out of the way to prevent me from using NOINPUT the way I intend to
< gmaxwell>
oh so sad poor luke
< * booyah>
quietly pulls out a violin
< sipa>
luke-jr: what do you hope to gain from using noinput as you intend to?
< luke-jr>
sipa: eg, keeping txids for later spends (of unconfirmed change) the same even if the transaction producing the change needs a fee bump; without keeping an exponential number of signed transactions prepared
< gmaxwell>
that only works right if all subsiquent transactions are themselves no-input.
< gmaxwell>
so a katamari of replay attack vulnerablity. :)
< luke-jr>
which they would be in such a wallet where everything is noinput
< gmaxwell>
luke-jr: not the recipents spends.
< luke-jr>
the recipient of the fee-bumped one would be affected, but nothing else?
< luke-jr>
or, what do you mean?
< gmaxwell>
the whole chain is invalidated unless all txn in it use noinput for all of their inputs.
< luke-jr>
but the recipients aren't in the chain of change
< gmaxwell>
they get the payments, not the change itself. (obviously thats why you have change: you made payments)
< luke-jr>
but that doesn't break the chain of change
< luke-jr>
the next transaction would have an unchanged txid
< luke-jr>
(also, unrelated to a mere simple wallet: what if you want someone paying you, to send directly into a smart contract that relies on NOINPUT?)
< gmaxwell>
luke-jr: no input doesn't keep the inputs out of the txids. so if you pay1->pay2->pay3->pay4 all with no input and alter pay2 the txids of all the subsiquent txn (pay3/pay4/ and all their children) change too.
< luke-jr>
hmm, right
< luke-jr>
that only messes up the recipients not using noinput wallets, though
< gmaxwell>
14:46:41 < gmaxwell> so a katamari of replay attack vulnerablity. :)
< luke-jr>
another use case: if the person paying me does some fee bumping, using noinput avoids resigning
< gmaxwell>
Ethereum has better replay prevention than no input, and still replay there has caused massive funds loss, annoying DOS, etc.
< luke-jr>
but in this case, replay isn't a problem since addresses aren't reused
< gmaxwell>
basically noinput = accounts model, instead of utxo model; with the tradeoffs that implies.
< luke-jr>
or unique-script UTXO model
< gmaxwell>
one coulde use ethereum accounts exactly once. but because the system doesn't guarentee it, you can't count on it.
< luke-jr>
since NOINPUT still commits to the amount, it's basically harmless to count on it
< gmaxwell>
that kind of thinking is why it is so unsafe.
< gmaxwell>
So thanks for making the point.
< luke-jr>
am I wrong?
< gmaxwell>
Yes. So for example, the not that uncommon pattern of splitting a payment in half to pay from two different wallets. wham 50% funds loss.
< gmaxwell>
that isn't even 'reuse' thats just two outputs at effectively the same time. That has never before been a problem in the system, so it's a new footgun behavior that arises out of nowhere.
< luke-jr>
that's reuse and undefined behaviour..
< gmaxwell>
according to _you_.
< gmaxwell>
Not according to how bitcoin has always worked.
< gmaxwell>
And certantly not according to what people already do.
< gmaxwell>
Advisable or not, reuse is ubiquitous. The majority of circulating bitcoins are stored in reused addresses.
< gmaxwell>
You are saying that it's just fine to turn something that people ubiquitously do today into a massive footgun.
< gmaxwell>
I can't abide by that.
< luke-jr>
it's already a footgun.
< gmaxwell>
Worse, instead of saying "yes, I know its dangerous and it will cause funds loss, it's worth it" -- instead you argue that it's "basically harmless".
< luke-jr>
nothing obliges the recipient to acknowledge the second payment to the same address
< gmaxwell>
Although its theoretically possible, I am aware of _no_ instance where funds have been loss due to a near term reuse. (like sending again on the same day)
< luke-jr>
that's like when people say light wallets are okay because nobody's ever lost funds due to their lack of security
< booyah>
are you talking about two people sending e.g. 1 btc, on same day, to same one e.g. donation address of someone?
< gmaxwell>
luke-jr: I am not saying that reuse is good. It's inadvisable in most cases. But there is a big difference between something being inadvisable and rigging it to explode.
< luke-jr>
gmaxwell: I've seen it very nearly explode at least once personally.
< luke-jr>
without NOINPUT
< gmaxwell>
luke-jr: you've had years where you could have also written wallet features in bitcoin core to do stuff like pop up a message saying "You're paying to an address you've paid to before. Is this a mistake? Address reuse can be a symptom of a mistaken double payment and can lead to privacy or funds loss". but apparently it wasn't important enough to you to bother.
< gmaxwell>
But now it's important enough to you that you think it's no concern to adjust the consensus rules so that behavior will actually lead to funds loss, and not just a fringe risk.
< gmaxwell>
(or likewise, inbound payments that reused your addresses could get frowny red recycle icons)
< booyah>
I guess, if it is that Alice twice pays to same address of Bob, then it might be impossible to detect in some cases, especially if due to crash and recover from backup she lost local information that she is sending to Bob, and if when she restored then first transaction is in someone's mempool but not yet in block and not visible to it(?)
< gmaxwell>
indeed.
< aj>
luke-jr: noinput sigs sign the amount, so if you feebump the change will be a different value and the noinput sig spending that change will be invalid
< luke-jr>
booyah: that's not a new problem with noinput
< gmaxwell>
luke-jr: but it does invalidate the case you gave for it.
< gmaxwell>
booyah: it's difficult to guarentee that a double payment _never_ happen even if you're trying.
< gmaxwell>
booyah: and in bitcoin today users generally assume addresses can be reused. It's not a great assumption.
< booyah>
I guess instant backups, kind of like watchtowers in a way, could help, where you commit to them first, and on restart of client it queries them to make sure
< gmaxwell>
They also assume you can go pull an address out of a block explorer and pay to it.
< gmaxwell>
booyah: right, with enough protection and complexity you can make it arbritarily rare.
< luke-jr>
gmaxwell: maybe there's too much focus on a specific use case? are you really saying that there is no situation where it would be useful to receive a payment directly into a multi-transaction smart contract that needs noinput?
< gmaxwell>
It's not clear to me that it would, at least the lightning stuff proposed can't work that way.
< gmaxwell>
But even if it is useful, that utility has to be weighed against the risk increase for all other usage.
< luke-jr>
the only reason you can't have someone pay directly into a Lightning channel in such a manner, is because of non-segwit inputs, right?
< gmaxwell>
luke-jr: no, because they have to be able to resign if the transaction fails (even with no-input)
< gmaxwell>
(also, if it became justified to do that, it could be done later... along with whatever was needed to make it safer)
< luke-jr>
gmaxwell: I'm probably not going to object to a neutered noinput being softforked, but I predict in some years we will learn it was a mistake and desire to change it
< sipa>
that's ok
< luke-jr>
(and since we *can* change it in a later softfork, I suppose it isn't worth trying to brainstorm all the possible ideas today; and as you point out, there are things we can do in the meantime to prepare for that being safer by then)
< sipa>
we can learn from experience
< gmaxwell>
luke-jr: as I was pointing out before, we already know the initial v1 segwit script will be not a forever thing.
< gmaxwell>
We've already dropped headline features from it.
< gmaxwell>
including the major source of public hype for it (aggregation).
< luke-jr>
yes, admittedly those are bigger unfortunate-delays
< gmaxwell>
my argument isn't that it's terrible and should never be done, only that there is too much risk that it's terrible and shouldn't be done, and not enough time yet given into how it could best be derisked... and it sould be seperated because it can be seperated.
< gmaxwell>
it's certantly a lot easier to add it later than to deal with the consequence of adding it and wish we could take it back.
< gmaxwell>
e.g. if its added, it can never be removed without risk of confsciating funds.
< luke-jr>
that's a good point
< gmaxwell>
(I mean it could be added with warnings that its provisional and you shouldn't setup things so that you'll lose funds if its turned off... but thats a footgun. which is better avoided)
< gmaxwell>
and the main usecase for it is lightning stuff that ... has a lot of other development work to do anyways.
< luke-jr>
I suppose in theory, a new address format could always also be added later to set the tx version or whatever without another softfork
< luke-jr>
although that runs the risk of getting current addresses labelled "reusable"
< gmaxwell>
luke-jr: Right, at least my preference at the moment is that it just get a different segwit script version so that you know what you're dealing with.
< luke-jr>
well, another script ver number wouldn't be obviously distinguishable in Bech32, would it?
< gmaxwell>
luke-jr: it would be a different third character.
< gmaxwell>
er forth.
< sipa>
fourth.
< luke-jr>
I suspect most users wouldn't notice that, and it might not accomplish the intended goal
< gmaxwell>
the fourth character is the version number.
< gmaxwell>
luke-jr: no but their software could.
< luke-jr>
existing software doesn't; but since I don't really agree with the intended goal, I'm not going to argue too hard that the mechanism here is insufficient ;)