sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
brimstone1 has quit []
ddustin has quit [Ping timeout: 245 seconds]
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
mauz555 has joined #bitcoin-wizards
tombusby has quit [Remote host closed the connection]
tombusby has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 246 seconds]
mauz555 has quit [Ping timeout: 276 seconds]
davec has quit [Ping timeout: 245 seconds]
_whitelogger has joined #bitcoin-wizards
captjakk has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
mdunnio has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 268 seconds]
mdunnio has quit [Remote host closed the connection]
mdunnio has joined #bitcoin-wizards
lightlike has quit [Quit: Leaving]
Krellan has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
davec has joined #bitcoin-wizards
mdunnio has quit [Remote host closed the connection]
DeanGuss has joined #bitcoin-wizards
mdunnio has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 244 seconds]
Krellan has quit [Ping timeout: 264 seconds]
mackr has joined #bitcoin-wizards
mdunnio has quit [Remote host closed the connection]
jonatack has quit [Ping timeout: 246 seconds]
harrow has quit [Quit: Leaving]
harrow has joined #bitcoin-wizards
emilengler_ has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
emilengler has quit [Ping timeout: 240 seconds]
elichai2 has quit [Quit: Connection closed for inactivity]
AaronvanW has quit [Ping timeout: 276 seconds]
harrow has quit [Ping timeout: 276 seconds]
Belkaar has quit [Ping timeout: 246 seconds]
harrow has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
AaronvanW has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
AaronvanW has quit [Ping timeout: 276 seconds]
mackr has quit []
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 240 seconds]
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 276 seconds]
moriarty has quit [Ping timeout: 264 seconds]
DeanGuss has quit [Ping timeout: 260 seconds]
Livestradamus has quit [Quit: Livestradamus]
Krellan has joined #bitcoin-wizards
Livestradamus has joined #bitcoin-wizards
Livestradamus has quit [Changing host]
Livestradamus has joined #bitcoin-wizards
wallet42 has quit [Ping timeout: 252 seconds]
madflavor has quit [Ping timeout: 252 seconds]
yokwe__ has quit [Ping timeout: 276 seconds]
harding has quit [Ping timeout: 245 seconds]
wallet42 has joined #bitcoin-wizards
madflavor has joined #bitcoin-wizards
yokwe__ has joined #bitcoin-wizards
davec has quit [Ping timeout: 246 seconds]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 276 seconds]
mikerah has quit [Ping timeout: 250 seconds]
davec has joined #bitcoin-wizards
Krellan has quit [Ping timeout: 264 seconds]
jaqque1 has joined #bitcoin-wizards
harding has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 245 seconds]
harding has quit [Ping timeout: 240 seconds]
harding has joined #bitcoin-wizards
davec has quit [Ping timeout: 246 seconds]
davec has joined #bitcoin-wizards
ppisati has quit [Quit: leaving]
davec has quit [Ping timeout: 246 seconds]
davec has joined #bitcoin-wizards
ppisati has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 268 seconds]
harding has quit [Ping timeout: 245 seconds]
queip has quit [Ping timeout: 276 seconds]
harding has joined #bitcoin-wizards
queip has joined #bitcoin-wizards
Krellan has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
jaqque1 has quit []
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
tromp has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
tromp__ has quit [Read error: Connection reset by peer]
tromp has quit [Ping timeout: 246 seconds]
tromp has joined #bitcoin-wizards
tromp_ has quit [Ping timeout: 276 seconds]
mauz555 has quit [Ping timeout: 276 seconds]
Krellan has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
Krellan has quit [Ping timeout: 268 seconds]
mauz555 has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
fixcrypt has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
matael1 has joined #bitcoin-wizards
ddustin has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 276 seconds]
rusty has quit [Quit: Leaving.]
Coupe420 has quit [Read error: Connection reset by peer]
Krellan has joined #bitcoin-wizards
fixcrypt has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
Aaronvan_ has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 245 seconds]
ddustin has joined #bitcoin-wizards
moriarty has joined #bitcoin-wizards
vtnerd has quit [Ping timeout: 246 seconds]
vtnerd has joined #bitcoin-wizards
Krellan has quit [Ping timeout: 245 seconds]
spinza has quit [Quit: Coyote finally caught up with me...]
Aaronvan_ has quit [Remote host closed the connection]
moriarty has quit [Ping timeout: 276 seconds]
spinza has joined #bitcoin-wizards
tombusby has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
jonatack has joined #bitcoin-wizards
Krellan has joined #bitcoin-wizards
<waxwing>
andytoshi, re: 5.2 'amicable pairs', wouldn't secp256k1 qualify? i remember you pointing this pair of curves thing (p/q) applied for secp256k1.
<waxwing>
oh right i just remembered, you called it secq
<andytoshi>
based on the current perf numbers ebfull described in another channel (multisecond verification, worse proving time and larger proof size than BPs) i haven't taken time to read this paper in much detail .. it seems that it won't be practical for a little while at least
Krellan has quit [Ping timeout: 268 seconds]
matael1 has quit []
<waxwing>
thr paper is strange but it does seem rather cool. i like the algebraic trick on page 6 (is that original?) .. don't have the knowledge yet to understand the rest, it seems sketched out (they say explicitly, no soundness proof), but it does look like really interesting work.
AaronvanW has quit [Remote host closed the connection]
<nsh>
heh, Hasse bounds came up recently as someone solved 44-as-sum-of-cubes (after 33 was solved in May) and the algorithm to reduce the search space does a lot of funky stuff, inc. Montgomery batch inversion and integral pointfinding on an EC
<waxwing>
nsh, i think there's only one on page 6? like the second half of the page.
* nsh
nods
<nsh>
also gets a bit Godelian...
<nsh>
*almost
AaronvanW has quit [Remote host closed the connection]
mauz555 has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
mauz555 has joined #bitcoin-wizards
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #bitcoin-wizards
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
spinza has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
mikerah has joined #bitcoin-wizards
Robert3 has quit []
<waxwing>
andytoshi, oh thanks for the link to the baez blog, i read the first part and then totally forgot about it lol.
<waxwing>
that one is really nice. btw i remember i think Washington has a proof of the Hasse bound but it looked really very complicated. that blog gives some very interesting intuitions.
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 240 seconds]
queip has quit [Ping timeout: 258 seconds]
queip has joined #bitcoin-wizards
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
AaronvanW has joined #bitcoin-wizards
fancyremarker has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
rafalcpp has joined #bitcoin-wizards
Krellan has joined #bitcoin-wizards
lightlike has joined #bitcoin-wizards
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #bitcoin-wizards
Krellan has quit [Ping timeout: 264 seconds]
ccdle12 has joined #bitcoin-wizards
emilengler_ is now known as emilengler
AaronvanW has joined #bitcoin-wizards
spinza has quit [Ping timeout: 240 seconds]
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
davec has quit [Ping timeout: 246 seconds]
Giszmo has quit [Read error: Connection reset by peer]
Giszmo has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
Krellan has joined #bitcoin-wizards
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #bitcoin-wizards
mauz555 has quit [Remote host closed the connection]
justanotheruser has quit [Ping timeout: 258 seconds]
Krellan has quit [Ping timeout: 264 seconds]
dgenr8 has quit [Ping timeout: 245 seconds]
Krellan has joined #bitcoin-wizards
davec has joined #bitcoin-wizards
dgenr8 has joined #bitcoin-wizards
mdunnio has joined #bitcoin-wizards
fancyremarker has quit []
captjakk has quit [Remote host closed the connection]
captjakk has joined #bitcoin-wizards
captjakk has quit [Ping timeout: 240 seconds]
JohninLex has joined #bitcoin-wizards
Krellan has quit [Ping timeout: 276 seconds]
davterra has joined #bitcoin-wizards
mdunnio has quit [Remote host closed the connection]
mdunnio has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
mdunnio has quit [Remote host closed the connection]
capitalisnn has left #bitcoin-wizards ["Leaving"]
capitalisnn has joined #bitcoin-wizards
ccdle12 has joined #bitcoin-wizards
ccdle12 has quit [Ping timeout: 240 seconds]
ccdle12 has joined #bitcoin-wizards
nehan has joined #bitcoin-wizards
elichai2 has quit [Quit: Connection closed for inactivity]
vtnerd has quit [Ping timeout: 240 seconds]
vtnerd has joined #bitcoin-wizards
davec has quit [Ping timeout: 258 seconds]
davec has joined #bitcoin-wizards
Krellan has joined #bitcoin-wizards
mdunnio has joined #bitcoin-wizards
Ox207fffff has quit [Quit: Ox207fffff]
davec has quit [Ping timeout: 240 seconds]
Ox207fffff has joined #bitcoin-wizards
davec has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
JohninLex has quit []
Krellan has quit [Ping timeout: 250 seconds]
vtnerd_ has joined #bitcoin-wizards
vtnerd has quit [Ping timeout: 276 seconds]
tromp has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
tromp has quit [Ping timeout: 246 seconds]
tromp has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
mdunnio has quit [Remote host closed the connection]
vtnerd_ has quit [Ping timeout: 246 seconds]
mdunnio has joined #bitcoin-wizards
tromp has quit [Ping timeout: 246 seconds]
vtnerd has joined #bitcoin-wizards
queip has quit [Ping timeout: 258 seconds]
rafalcpp_ has joined #bitcoin-wizards
rafalcpp has quit [Ping timeout: 245 seconds]
harrow has quit [Ping timeout: 276 seconds]
queip has joined #bitcoin-wizards
harrow has joined #bitcoin-wizards
SchwarzeLocke has joined #bitcoin-wizards
mdunnio has quit [Remote host closed the connection]
mdunnio has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp_ has joined #bitcoin-wizards
tromp has quit [Ping timeout: 246 seconds]
tromp_ has quit [Ping timeout: 246 seconds]
captjakk has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
captjakk has quit [Read error: Connection reset by peer]
captjakk has joined #bitcoin-wizards
captjakk has quit [Read error: Connection reset by peer]
captjakk has joined #bitcoin-wizards
captjakk has quit [Read error: Connection reset by peer]
captjakk has joined #bitcoin-wizards
captjakk has quit [Read error: Connection reset by peer]
captjakk has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
captjakk has quit [Read error: Connection reset by peer]
captjakk has joined #bitcoin-wizards
captjakk has quit [Remote host closed the connection]
Krellan has joined #bitcoin-wizards
fox2p has joined #bitcoin-wizards
fox2p_ has quit [Ping timeout: 244 seconds]
rusty has joined #bitcoin-wizards
elichai2 has joined #bitcoin-wizards
davec has quit [Ping timeout: 276 seconds]
mikerah has quit [Ping timeout: 250 seconds]
Krellan has quit [Ping timeout: 250 seconds]
davterra has quit [Ping timeout: 240 seconds]
davterra has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
robin has joined #bitcoin-wizards
robin is now known as LinusK
<LinusK>
Hi!
<LinusK>
I wondered if one can use the bitcoin:URI scheme to define some "payment contact" which is more similar to what people expect addresses to be.In BIP21 bitcoin-URIs are defined to be "Payment identifiers, not person identifiers -- Current best practices are that a unique address should be used for every transaction. Therefore, a URI scheme should
<LinusK>
not represent an exchange of personal information, but a one-time payment.".But with bip32 we could have an URI scheme which _does_ represent an exchange of personal information and meets the users' expectations
SchwarzeLocke has quit []
<LinusK>
maybe I could use an URI scheme extension like this:`bitcoin:<< address_0 >>?xpub=<< extended_public_key >>`such that wallets who don't understand the "payment contact" fall back to using address_0`
<LinusK>
maybe I could use an URI scheme extension like this:`bitcoin:<< address_0 >>?xpub=<< extended_public_key >>`such that wallets who don't understand the "payment contact" fall back to using `address_0`
<sipa>
LinusK: if you share the xpub, it's as bad as reusing keys
<sipa>
tbough you still need to interact with the receiver to know the xpub is still current
<sipa>
they may have migrated to a new wallet or something
<sipa>
given a preexisting business arrangement you can avoid that i guess
<sipa>
but i don't know if it's much of a gain
<LinusK>
the idea is about exchanging a personal contact as users are used to from i.e. Paypal
<LinusK>
for a more Venmo-like wallet experience without sacrificing privacy by reusing addresses
<LinusK>
do you think it is a sound design to extend the uri scheme like this:`bitcoin:<< address_0 >>?xpub=<< extended_public_key >>`
<LinusK>
do you think it is a sound design to extend the uri scheme like this: `bitcoin:<< address_0 >>?xpub=<< extended_public_key >>`
<LinusK>
such that wallets who don't understand the "payment contact" fall back to using `address_0`
<sipa>
that'll still cause reuse reuse if the sender doesn't support the scheme
<sipa>
and otherwise require the sender to keep track of how many payments have been made already
<sipa>
e.g. a hardware wallet can't really show anything useful for such schemes
<sipa>
because it doesn't know many payments have been created already
<LinusK>
A wallet supporting this scheme could just query the derived addresses
<sipa>
what does that mean?
davec has joined #bitcoin-wizards
<LinusK>
From an xpub you can derive address_1, address_2, address_3, ... so a wallet can query these addresses one after another to find the first unused address
<sipa>
the bitcoin protocol has no concept of addresses
ddustin has quit [Remote host closed the connection]
<sipa>
you need an indexing service to "query" used addresses on the network
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
phyll1s_work has joined #bitcoin-wizards
<LinusK>
sure, it's inefficient in core, but in theory one could use ./bitcoin-cli scantxoutset start '["addr(3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy)"]'
ddustin has quit [Remote host closed the connection]
<sipa>
that assumes you have access to a full node
ddustin has joined #bitcoin-wizards
<sipa>
for example, a hardware wallet or any kind of airgapped device cannot do this at all
<LinusK>
sure
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
<LinusK>
most people do use wallets that do query addresses from some server
AaronvanW has joined #bitcoin-wizards
<sipa>
that doesn't mean we should adopt standards that don't support anything else
ddustin has quit [Remote host closed the connection]
<sipa>
so how do you use such an address with a hw wallet for example? the device can't show you anything useful for you to verify the receiver is correct
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
<sipa>
it can show the xpub and index, i guess
ddustin has joined #bitcoin-wizards
<sipa>
and hope you can verify it's not skipping past the gap limit, or reusing an old index
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
<LinusK>
interesting thought. actually the hw wallet would even need to derive the key by itself
mdunnio has quit [Remote host closed the connection]
<sipa>
yes, otherwise it can't show the xpub
ddustin has quit [Remote host closed the connection]
<sipa>
if it only shows the derived address, it's no good
ddustin has joined #bitcoin-wizards
<LinusK>
ok my idea doesn't make much sense in case of hardware wallets
ddustin has quit [Remote host closed the connection]
<sipa>
imho generally (barring specially negotiated exceptions) every payment needs interaction between the sender and the receiver anyway
<LinusK>
though many users use some mobile wallet and they would have better privacy
ddustin has joined #bitcoin-wizards
<sipa>
you think address reuse between end user wallets is common?
ddustin has quit [Remote host closed the connection]
<sipa>
(honest question; i have no idea)
mdunnio has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 240 seconds]
ddustin has joined #bitcoin-wizards
<LinusK>
of course. many wallets have a contacts book which encourages you to reuse addresses
<sipa>
which ones?
ddustin has quit [Remote host closed the connection]
<LinusK>
doesn't even QT have such a "naive" contacts book?
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
<sipa>
i haven't use the Qt GUI for a long time, but i thought it was hidden now
<LinusK>
just checked it
ddustin has joined #bitcoin-wizards
<LinusK>
it has a naive contacts book
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
<LinusK>
I can give you more examples because I analyzed many wallets recently and wondered why so many support such a feature
<sipa>
the green app doesn't
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
<sipa>
(not claiming that's the common behaviour though; just giving a counterexample)
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
<LinusK>
yes, green app's design is much more sound than most others
ddustin has quit [Remote host closed the connection]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
ddustin has joined #bitcoin-wizards
<LinusK>
don't you think a contact book with xpubs would make sense?
ddustin has quit [Remote host closed the connection]
<sipa>
i think it needs to many unstated assumptions to work for end users
<sipa>
like how long is the xpub expected to remain valid
<LinusK>
that is a good question
<LinusK>
in general you could ask the same question for a regular address
<sipa>
"you didn't get my money? i paid to xpub...." - "oh i moved from wallet X to wallet Y a month ago, it's xpub... now" <- money gone
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
<LinusK>
one idea is that the recipient gives the sender an xpub + ( freshness_address, "freshness_address signed by xpub" ). then the recipient can regularly sign the current block hash with the freshness_address and publish it in some centralized archive. then the sender can query the freshness in that archive before making a payment
<LinusK>
the recipient can reuse the same freshness_address for all senders
<LinusK>
of course the recipient derives the freshness_address from the same seed as the xpubs
esotericnonsense has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
Giszmo has quit [Read error: Connection reset by peer]
Giszmo has joined #bitcoin-wizards
<LinusK>
btw: sipa can you estimate when Schnorr signatures will get shipped in testnet?
AaronvanW has quit [Remote host closed the connection]
captjakk has joined #bitcoin-wizards
<sipa>
LinusK: no
<LinusK>
I just checked GreenAddress for desktop and it does use a "naive" address book
<sipa>
in bitcoin core it's moved to a separate "receive addresses" window, and no longer accessible from the receive money tab
<sipa>
and afaik when that happened we already got complaints from people confused how to receive money now
<LinusK>
sorry I don't understand what you mean. I meant the address book
<LinusK>
which stores addresses of other people just like your contacts on your phone
<LinusK>
and I think that is misleading because it encourages people to reuse addresses
justanotheruser has joined #bitcoin-wizards
<LinusK>
that's why I wonder why this feature is prominent both in Core and GreenAddress
<LinusK>
and I think an address book being a collection of xpubs would be much better design
mdunnio has quit [Remote host closed the connection]
<sipa>
i think no address book would be even better :)
<LinusK>
people not using computers would be ideal X-P
<sipa>
what i meant is that we've made small steps towards moving away from having previous addresses show up (they used to be accessible from the receive tab), and even that met with complaints of existing users
<sipa>
it also wouldn't be compatible with software that uses hardened derivation (for which no equivalent xpub exists)
<LinusK>
I disagree with you that no address book is a good idea, because I think that is a concept users are very used to and thus they can use it securely. In contrast, the whole concept of key pairs and changing addresses is highly unintuitive for normal people. We shouldn't try to teach people stuff they won't learn but we should try to come up with
<LinusK>
usable designs
<sipa>
heh, i believe humans should never be seeing cryptographic material in the first place
<sipa>
bip70 was a nice attempt to avoid that, but a very broken design in many ways
<LinusK>
I agree and that is another strong argument for a contacts book.
<sipa>
i believe in practice lightning payment requests are the best hope to deal with that
<sipa>
iirc there is work on reusable ones
<sipa>
but i'm not an expert on that
stevenroose has quit [Ping timeout: 250 seconds]
<LinusK>
interesting! do you have a source at hand?
<sipa>
no
stevenroose has joined #bitcoin-wizards
<sipa>
there also exist "stealth addresses" for bitcoin, though i don't think they're adopted anywhere, which give cryptographically indistinguishable payments on chain with a static address... they have very bad scalability properties though
<LinusK>
and recipients need to scan all new blocks, right?
<sipa>
right
Krellan has joined #bitcoin-wizards
<LinusK>
not very usable for most people
<sipa>
agree
<sipa>
and it equally suffers from the "making sure the address is current" problem
<LinusK>
what do you think about my idea?
<LinusK>
"one idea is that the recipient gives the sender an xpub + ( freshness_address, "freshness_address signed by xpub" ). then the recipient can regularly sign the current block hash with the freshness_address and publish it in some centralized archive. then the sender can query the xpub's freshness in that archive before making a payment"
<sipa>
i don't think we should be adopting or encouraging standards that are incompatible with good practices like hardware wallets or hardened derivation
<sipa>
as that may cause an incentive for people to not adopt those practices
<LinusK>
why is this incompatible with hardened derivation?
<sipa>
because hardened derivation doesn't have a corresponding xpub
<LinusK>
okay I didn't understand hardened derivation then. I'll read it up now
<sipa>
bip32 explains it
<sipa>
i think a standard based on xpub derivation may make sense, but only in very restricted use cases, like recurring business-to-business payments
<sipa>
where you can have a contract and whatever that clearly defines how to use them
<LinusK>
I think I understood my misconception: you can not derive non-hardened keys from a hardened key, right?
<LinusK>
more precise: you can not derive non-hardened xpubs from a hardened xpriv, right?
<LinusK>
...which isn't a crypto issue it's just because the standard doesn't allow that, right?
<sipa>
it's not the key that's hardened
<sipa>
it's the derivation
stevenroose has quit [Ping timeout: 276 seconds]
<sipa>
given an xprv, you can derive a nonhardened pubkey, or a hardened pubkey
<sipa>
the xprv also has a corresponding xpub
<sipa>
but with the xpub you can only discovered the unhardened pubkeys (and thus addresses), not the hardened ones
<sipa>
the hardened ones are more secure
<LinusK>
of course, but the standard doesn't allow that. So If I just derive non-hardened keys from the hardened path, then this is incompatible with the standard other wallets are using
<sipa>
no
<sipa>
it's cryptographically a different scheme
stevenroose has joined #bitcoin-wizards
<sipa>
that does not support deriving pubkeys from xpubs
<sipa>
so software that uses hardened derivation does not have any meaningful xpub (there is one, but it doesn't let you find the public keys used by the software)
<LinusK>
yes, I think I understand that
<sipa>
so your scheme would force the receiving wallet to use unhardened derivation, which would be bad
<LinusK>
yes
<sipa>
maybe a more meta comment... i'd very much have liked have seen a version of bitcoin history in which addresses and their common reuse was different
<LinusK>
in most simple terms my idea was: derive a private key with the hardened derivation to protect your key tree and then use that privateKey to derive an xPubKey for me to derive more public keys for you
<sipa>
in 2011 i helped push for payment protocols etc to get rid of the notion that addresses should be seen as accounts
<sipa>
but i think it was already too late back then
<sipa>
i wonder if having them be called "invoice ids" or something instead of addresses would have led to a different history
<sipa>
so personally my best hope now is in fact in new layers where the concept of addresses simply doesn't exist
<sipa>
there are probably places where xpubs can have some use... but i think they'
<sipa>
re very limited
<sipa>
and probably impossible to find critical mass for now
<LinusK>
but don't you think it's cumbersome not to have the concept of "sending money to a person" ?
TheoStorm has joined #bitcoin-wizards
<sipa>
no, not really... but i believe you that you have another impression
<sipa>
generally payments are expected
<LinusK>
I think people misuse addresses as accounts because it fits their mental model
<sipa>
yes
meshcollider has quit [Ping timeout: 268 seconds]
<LinusK>
it is what they're used to from fiat payment apps and these apps just mimic physical payments
<sipa>
i've had discussions with people in the past where they argued address reuse was great because it let them check their balance on a block explorer :S
<sipa>
i think the widespread use of bip32 (internally in wallets) actually improved the situation significantly there, but it took a long time, and we're not there yet
<LinusK>
'=D
<LinusK>
I think it is not a good idea to try to break the mental model people have but to adapt our designs to it
<sipa>
i think that's a noble cause, but a broken solution to it :)
da2ce7 has joined #bitcoin-wizards
meshcollider has joined #bitcoin-wizards
<LinusK>
I think something like
<LinusK>
bitcoin:<<address>>?xpub=<<xpub>> could help improve the situation
<sipa>
good luck
<sipa>
i've given my opinion :)
<LinusK>
but as far as I understood, your opinion ignored the fact of address books being an industry standard
Krellan has quit [Ping timeout: 245 seconds]
stevenroose has quit [Ping timeout: 245 seconds]
stevenroose has joined #bitcoin-wizards
lightlike has left #bitcoin-wizards ["Leaving"]
captjakk has quit [Remote host closed the connection]
captjakk has joined #bitcoin-wizards
elichai2 has quit [Quit: Connection closed for inactivity]
captjakk has quit [Remote host closed the connection]
<LinusK>
Nevertheless, much appreciation for sharing your opinion!
<sipa>
LinusK: i personally think the existence of block explorers is a much bigger contributor to the mindset of address == account than address books are
<LinusK>
I disagree again, because I think people think in terms of paying other people
<sipa>
i don't disagree that it's a problem that address books make it too easy to reuse addresses, but you won't fix that up with a patch to introduce some kind of addresses that are in some cases ok to reuse, but come with significant technical drawbacks and little chances of widespread adoption
<sipa>
what does have a chance of actually changing that is moving to different solutions that don't have addresses at all
<sipa>
it's a slow process, but that kind of evolution is already happening
<sipa>
just to tease your brain, some more issues:
<LinusK>
do you think a different solution could make people stop thinking they're paying some other person instead of an anonymized invoice?
<sipa>
no, i don't see the problem with that
<sipa>
but it's not a good match with the address model
<LinusK>
yes
<LinusK>
I think we should take it as given that people expect to pay a person or account and we can not change that mindset
<sipa>
i don't disagree, but i don't think xpubs are a good solution to that problem
<LinusK>
this forces us to adopt the tech to how people use it
<sipa>
* hardware wallet verification
<LinusK>
okay so we need something better than xpubs to give people an "avatar" they can give their money to
<sipa>
* what if the sender wants to use something more advanced than a single key (e.g. multisig, has a wallet with timelocks, ...); the recipient shouldn't need to know or care about this, but inherently allowing the recipient to derive the address means that information needs fo be conveyed
<LinusK>
because if we don't, they'll keep misusing addresses and then we keep building address books =D
<sipa>
* how do you communicate gap limit
<sipa>
* what if you accidentally shared the xpub with two people, and the next index you'd want to use is already used, but the sender doesn't know about it
<LinusK>
isn't it conveyed in the resulting utxo?
<sipa>
wut?
<LinusK>
if the sender creates some more advanced payment
<sipa>
it's the reciever who decided what kind of script he accepts money at
<sipa>
and communicates that to the sender in the form of an address
<LinusK>
gotcha
<sipa>
since p2sh, they can send a hash of the script, so the sender does not need to know the details about the script
<sipa>
but with your scheme and related ideas, you must expose you personal wallet policy to the sender
<sipa>
that's a technical challenge for sure, but also a privacy issue on its own
Belkaar has quit [Ping timeout: 276 seconds]
<LinusK>
most simple solution is to restrict the scheme to simple payments. for advanced payments you need to interact with the recipient
<sipa>
i think tha5 would be an enormously deplorable state of affairs
<sipa>
and create a crazy incentive against adoption of multisig etc
<sipa>
standards for payment should not care about the recipient policy
<LinusK>
can't you build a key derivation scheme for multisigs? at least with schnorr?
<sipa>
yes, but you'd need to know multiple xpubs
<sipa>
and expose the policy
<sipa>
something the sender has no business with
<sipa>
even if you somehow accomplish that, you'd end up with mobile wallet X that only supports descriptions of addresses up to 255 characters
<LinusK>
with schnorr you could theoretically add them together, right? but the de-linearization makes this impossible in practice, right?
<sipa>
that's correct but irrelevant
<sipa>
in order for the sender to derive the addresses they'd still need to know the "source" for all the contribiting keus
<sipa>
*contributing keys
<sipa>
and now X becomes very popular and noone wants to adopt a custody solution that is incompatible with X
<sipa>
that's my reason for saying standards should not care about the receiver policy
<sipa>
it's too eay to make hidden assumptions about the receiver when creating sender software if it's visible at all
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
<sipa>
thanks for the discussion, but i have some other things to do now :)
<LinusK>
thank you for the discussion! you helped me a lot!