--- Log opened Mon Feb 17 00:00:41 2020 00:09 -!- Kiminuo [~mix@141.98.103.124] has joined #bitcoin-wizards 00:28 -!- marcoagner [~user@bl11-16-246.dsl.telepac.pt] has joined #bitcoin-wizards 00:34 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: Quit] 00:34 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-wizards 00:38 -!- slivera [~slivera@217.138.204.89] has quit [Remote host closed the connection] 00:59 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:f12f:7c70:30d0:dacb] has joined #bitcoin-wizards 01:00 -!- gholms1 [~gholms@176.113.74.179] has quit [] 01:00 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:f12f:7c70:30d0:dacb] has quit [Remote host closed the connection] 01:06 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-wizards 01:13 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: Quit] 01:14 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-wizards 01:16 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 01:18 -!- dfreedm [~dfreedm@195.206.169.238] has joined #bitcoin-wizards 01:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 01:47 -!- jungly [~jungly@37.120.201.236] has quit [Remote host closed the connection] 01:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 01:48 -!- asukan [~jan@183.128.110.62] has quit [Ping timeout: 268 seconds] 01:50 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 260 seconds] 01:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 01:54 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-wizards 01:56 -!- jungly_ [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has joined #bitcoin-wizards 02:04 -!- nick_freeman [~nick_free@92.116.133.33] has joined #bitcoin-wizards 02:08 -!- nick_freeman [~nick_free@92.116.133.33] has quit [Ping timeout: 240 seconds] 02:15 -!- jcoe [seru@gateway/vpn/protonvpn/joncoe] has joined #bitcoin-wizards 02:31 -!- slivera [~slivera@217.138.204.72] has joined #bitcoin-wizards 02:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 02:34 -!- son0p [~son0p@181.58.38.54] has joined #bitcoin-wizards 02:57 -!- nick_freeman [~nick_free@92.116.133.33] has joined #bitcoin-wizards 03:02 -!- nick_freeman [~nick_free@92.116.133.33] has quit [Remote host closed the connection] 03:03 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:1c3:48dd:64bd:c81d] has joined #bitcoin-wizards 03:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 03:07 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:1c3:48dd:64bd:c81d] has quit [Ping timeout: 240 seconds] 03:07 -!- nick_fre_ [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has joined #bitcoin-wizards 03:12 -!- nick_fre_ [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has quit [Remote host closed the connection] 03:12 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has joined #bitcoin-wizards 03:15 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has quit [Remote host closed the connection] 03:15 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has joined #bitcoin-wizards 03:18 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has quit [Remote host closed the connection] 03:18 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has joined #bitcoin-wizards 03:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 03:49 -!- slivera [~slivera@217.138.204.72] has quit [Ping timeout: 272 seconds] 04:00 -!- dfreedm [~dfreedm@195.206.169.238] has quit [] 04:13 -!- son0p [~son0p@181.58.38.54] has quit [Ping timeout: 265 seconds] 04:17 -!- IOMonster1 [~IOMonster@176.113.74.179] has joined #bitcoin-wizards 04:56 -!- CryptoDavid [uid14990@gateway/web/irccloud.com/x-cmmzsyvdcgrakmjj] has joined #bitcoin-wizards 04:59 -!- laurentmt [~Thunderbi@92.223.89.145] has joined #bitcoin-wizards 05:09 -!- jungly_ [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 05:23 -!- kristofferR [~kristoffe@cm-84.209.168.112.getinternet.no] has joined #bitcoin-wizards 05:28 -!- kristofferR [~kristoffe@cm-84.209.168.112.getinternet.no] has quit [Quit: Textual IRC Client: www.textualapp.com] 05:28 -!- laurentmt [~Thunderbi@92.223.89.145] has quit [Quit: laurentmt] 05:34 -!- jungly [~jungly@host97-200-static.8-79-b.business.telecomitalia.it] has joined #bitcoin-wizards 05:35 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 268 seconds] 05:35 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-wizards 05:39 -!- son0p [~son0p@181.58.38.54] has joined #bitcoin-wizards 05:47 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 06:02 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 06:13 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-wizards 06:38 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has quit [Ping timeout: 240 seconds] 06:39 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has joined #bitcoin-wizards 07:00 -!- IOMonster1 [~IOMonster@176.113.74.179] has quit [] 07:18 -!- kerbyu [~kerbyu@141.98.101.133] has joined #bitcoin-wizards 07:37 -!- Kiminuo [~mix@141.98.103.124] has quit [Ping timeout: 260 seconds] 07:54 < mael-rolland[m]> Hello, so some of you may have already noticed that i have try to contact some Bitcoin community members for interviews for my PhD researchs. I just post on bitcoin stackexchange my questionnary (https://bitcoin.stackexchange.com/questions/93343/question-to-marco-falke-and-to-other-bitcoin-core-developpers-and-or-reviewers), so if some of you are want to answer to some of my questions, it' will be a pleasure 07:54 < mael-rolland[m]> to read you or discuss with you. Thanks 08:55 -!- roconnor [~roconnor@host-104-157-187-25.dyn.295.ca] has quit [Quit: Konversation terminated!] 09:03 -!- nuncanada [~dude@187.21.52.222] has joined #bitcoin-wizards 09:07 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 09:09 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 09:14 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 09:15 -!- Kiminuo [~mix@141.98.103.124] has joined #bitcoin-wizards 09:17 -!- bsm1175321 [~mcelrath@2601:196:4902:25b0:3067:a90a:9a06:babf] has joined #bitcoin-wizards 09:17 -!- bsm1175321 [~mcelrath@2601:196:4902:25b0:3067:a90a:9a06:babf] has quit [Client Quit] 09:21 -!- jcoe1 [~seru@195.206.169.231] has joined #bitcoin-wizards 09:21 -!- jcoe [seru@gateway/vpn/protonvpn/joncoe] has quit [Ping timeout: 272 seconds] 09:28 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 09:35 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 09:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 09:57 -!- Intensity [TtL41zGJEk@panix5.panix.com] has quit [Changing host] 09:57 -!- Intensity [TtL41zGJEk@unaffiliated/intensity] has joined #bitcoin-wizards 10:00 -!- kerbyu [~kerbyu@141.98.101.133] has quit [] 10:02 -!- Kiminuo [~mix@141.98.103.124] has quit [Read error: Connection reset by peer] 10:03 -!- Kiminuo [~mix@141.98.103.124] has joined #bitcoin-wizards 10:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 10:05 -!- kayront- [~kayront@zbase.xen.prgmr.com] has joined #bitcoin-wizards 10:05 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds] 10:05 -!- kayront [~kayront@unaffiliated/kayront] has quit [Ping timeout: 240 seconds] 10:05 -!- ryan-c` [ryan-c@znc.rya.nc] has joined #bitcoin-wizards 10:06 -!- rachelfish [~rachel@unaffiliated/itsrachelfish] has quit [Ping timeout: 240 seconds] 10:06 -!- charuto [charutocaf@gateway/shell/matrix.org/x-kblttynihftzvxvk] has quit [Ping timeout: 252 seconds] 10:06 -!- ryan-c [ryan-c@znc.rya.nc] has quit [Ping timeout: 268 seconds] 10:06 -!- ryan-c` is now known as ryan-c 10:06 -!- zkao [zkaomatrix@gateway/shell/matrix.org/x-spughaossbfpoisk] has quit [Ping timeout: 260 seconds] 10:07 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-getudbsqdkdesixh] has quit [Ping timeout: 245 seconds] 10:07 -!- mael-rolland[m] [mael-rolla@gateway/shell/matrix.org/x-bbqnyvsmlyrqmjpy] has quit [Ping timeout: 240 seconds] 10:07 -!- dl3br[m] [dlebrechtm@gateway/shell/matrix.org/x-kyzkeurwkgnpsfsm] has quit [Ping timeout: 260 seconds] 10:07 -!- M7918070_[m] [m7918070ma@gateway/shell/matrix.org/x-dxojcvbjktzqcmag] has quit [Ping timeout: 256 seconds] 10:07 -!- Jeremy_Rand_Talo [jeremyra1@gateway/shell/matrix.org/x-kwqgqgmorslzvtic] has quit [Ping timeout: 256 seconds] 10:07 -!- rachelfish [~rachel@unaffiliated/itsrachelfish] has joined #bitcoin-wizards 10:12 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 10:14 -!- spinza [~spin@102.132.245.16] has quit [Quit: Coyote finally caught up with me...] 10:16 -!- selenamarie [~selenamar@139.28.218.198] has joined #bitcoin-wizards 10:18 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Read error: Connection timed out] 10:20 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 10:21 -!- mael-rolland[m] [mael-rolla@gateway/shell/matrix.org/x-woxnzviitnhwovvx] has joined #bitcoin-wizards 10:25 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has quit [Remote host closed the connection] 10:32 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-wizards 10:32 -!- t-bast [~t-bast@2a01:e34:ec2c:260:6da4:8659:ca3f:b73a] has joined #bitcoin-wizards 10:38 -!- dome [~e-mod@2603:3020:2608:1000:f02a:7b52:489a:ef1a] has joined #bitcoin-wizards 10:43 -!- M7918070_[m] [m7918070ma@gateway/shell/matrix.org/x-bbrtdxpasgjgxsob] has joined #bitcoin-wizards 10:46 -!- zkao [zkaomatrix@gateway/shell/matrix.org/x-bepesagmoblripwj] has joined #bitcoin-wizards 10:48 -!- dl3br[m] [dlebrechtm@gateway/shell/matrix.org/x-dmhamglkviygslac] has joined #bitcoin-wizards 10:50 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has joined #bitcoin-wizards 10:51 -!- nick_fre_ [~nick_free@2001:16b8:3097:f800:29f3:56ea:fa9:9e5b] has joined #bitcoin-wizards 10:54 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:bd37:c3f5:3eed:f709] has quit [Ping timeout: 240 seconds] 10:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 11:13 -!- son0p [~son0p@181.58.38.54] has quit [Quit: leaving] 11:14 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 11:16 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: Quit] 11:21 -!- jungly [~jungly@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Remote host closed the connection] 11:25 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-wizards 11:27 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Client Quit] 11:37 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-wizards 11:38 -!- jcoe1 [~seru@195.206.169.231] has quit [Ping timeout: 268 seconds] 11:39 -!- charuto [charutocaf@gateway/shell/matrix.org/x-fnnxbgfedvyzbexc] has joined #bitcoin-wizards 11:39 -!- charuto [charutocaf@gateway/shell/matrix.org/x-fnnxbgfedvyzbexc] has quit [Excess Flood] 11:46 -!- M7918070_[m] [m7918070ma@gateway/shell/matrix.org/x-bbrtdxpasgjgxsob] has quit [Quit: killed] 11:46 -!- mael-rolland[m] [mael-rolla@gateway/shell/matrix.org/x-woxnzviitnhwovvx] has quit [Quit: killed] 11:46 -!- zkao [zkaomatrix@gateway/shell/matrix.org/x-bepesagmoblripwj] has quit [Quit: killed] 11:46 -!- dl3br[m] [dlebrechtm@gateway/shell/matrix.org/x-dmhamglkviygslac] has quit [Quit: killed] 11:49 -!- sanket1729 [~sanket172@72.36.89.11] has quit [Ping timeout: 250 seconds] 11:50 -!- Kiminuo [~mix@141.98.103.124] has quit [Ping timeout: 268 seconds] 11:51 -!- sanket1729 [~sanket172@72.36.89.11] has joined #bitcoin-wizards 11:55 -!- jimmysong [~jimmysong@65-36-83-142.static.grandenetworks.net] has joined #bitcoin-wizards 11:55 -!- jimmysong_ [~jimmysong@65-36-83-142.static.grandenetworks.net] has joined #bitcoin-wizards 11:57 -!- jimmysong_ [~jimmysong@65-36-83-142.static.grandenetworks.net] has quit [Client Quit] 12:00 -!- jimmysong [~jimmysong@65-36-83-142.static.grandenetworks.net] has quit [Quit: Leaving] 12:02 -!- rafalcpp [~racalcppp@ip-178-211.ists.pl] has quit [Ping timeout: 265 seconds] 12:11 -!- jimmysong [~jimmysong@65-36-83-142.static.grandenetworks.net] has joined #bitcoin-wizards 12:13 < jimmysong> does anyone know of HD wallet standards for creating multisig addresses? 12:13 < jimmysong> the only one I could find was BIP45, but it's horribly outdated and doesn't cover segwit 12:14 -!- Kiminuo [~mix@141.98.103.124] has joined #bitcoin-wizards 12:14 < jimmysong> also, are there any thoughts about using a particular HD path for use to encrypt/decrypt wallet data? 12:15 < jimmysong> It really sucks to have to restore stuff from seed, especially in a multisig context, and keeping utxo/witness/redeem information backed up in an encrypted form seems useful 12:20 -!- M7918070_[m] [m7918070ma@gateway/shell/matrix.org/x-oiyhstejuwchujbw] has joined #bitcoin-wizards 12:22 -!- Guyver2__ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-wizards 12:23 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 268 seconds] 12:23 < harding> jimmysong: sure, LND encrypts its static channel backups by a key derived from its HD wallet, see https://github.com/lightningnetwork/lnd/pull/2370 ("Crypto" section) 12:26 < harding> jimmysong: for HD standards, I think maybe the thing to do these days is to have each participating wallet send its public derivation path to all the other participating wallets and then create a common PSBT describing the combined wallet. E.g., see https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md#multisig-with-multiple-bitcoin-core-instances 12:28 < harding> Oops, I meant to refer to descriptors. 12:29 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 268 seconds] 12:29 < harding> E.g., see the last few examples here: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#examples 12:30 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-wizards 12:32 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Client Quit] 12:33 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-wizards 12:33 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Client Quit] 12:34 < jimmysong> harding: I'm aware of the descriptor language, which is great. I guess I'm asking for some standard derivation path to use. I'd like something like BIP84 so there's a standard path for everybody and not some arbitrary group. Does that make sense? 12:34 < jimmysong> In a sense, I want an opinionated way to use the descriptors =) 12:35 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-wizards 12:36 < jimmysong> Are either of those things worth making a BIP out of? Both are problems that I'm encountering writing a multisig wallet. 12:37 < sipa> i have no opinions 12:38 -!- jungly [~jungly@a-si4-24.tin.it] has joined #bitcoin-wizards 12:39 -!- t-bast [~t-bast@2a01:e34:ec2c:260:6da4:8659:ca3f:b73a] has quit [Quit: Leaving] 12:39 < harding> jimmysong: I'm not sure it makes sense given that people might use the same HD seed to participate in multiple multisigs. E.g. Alice might use a multisig backup recovery scheme for her personal funds while using the same HD seed to also participate in a 2-of-3 for securing funds at her job. I think it's best to just let each wallet say to other wallets participating in the multisig, "here's the info you need to pass back to me in 12:39 < harding> order for me to derive the correct signing key". 12:41 < jimmysong> sure, then you can have something like m/X'/0', m/X'/1' and so on. Every wallet has to create those anyway, it'd be nice if there were a standard 12:41 < harding> jimmysong: a BIP for using an HD wallet to derive a key to use with symmetric encryption for the purpose of creating data and metadata backups sounds reasonable to me. 12:42 -!- dr-orlovsky [~dr-orlovs@ip216.ip-54-36-238.eu] has quit [Ping timeout: 240 seconds] 12:44 < harding> jimmysong: sure, I think it'd be fine if there were a standard, but the problem past standards have had is finding a universally-acceptable balance between hardenend and non-hardened derivation paths (plus the problem of "I already implemented this and I'm not changing my path now"). 12:45 < jimmysong> handing: thanks! I'm currently using ECDH to create a new point, derive a shared secret, use that as the key to an AES cipher. Does that sound like a reasonable thing to do? 12:45 < jimmysong> harding: true, the nice thing is that there really aren't many multisig wallets yet, especially p2wsh 12:45 -!- dr-orlovsky [~dr-orlovs@ip216.ip-54-36-238.eu] has joined #bitcoin-wizards 12:46 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 12:47 < harding> jimmysong: I think you'd want to simplify to avoid using the ECDH. I think I'd just use the chaincode at a particular HD path. 12:47 < harding> (Though maybe some HD libraries don't expose that?) 12:48 < jimmysong> I guess if it's a hardened path no one has access to, that would work 12:48 < harding> Oh, yeah, HD wallets are probably not going to expose the chain code. So maybe just use a hash of pubkey. 12:50 < harding> s/HD/hardware/ 12:50 < jimmysong> it feels a bit weird to me to use a pubkey as a secret, though. 12:50 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Ping timeout: 240 seconds] 12:51 < jimmysong> ECDH is easy enough to implement. prepend the payload with the public point and initialization vector. 12:51 < jimmysong> restoring is more annoying, especially if you want the private key offline 12:52 < jimmysong> so maybe public key is better. 12:57 -!- zkao [zkaomatrix@gateway/shell/matrix.org/x-rnyyhmualxeninuy] has joined #bitcoin-wizards 12:57 -!- Jeremy_Rand_Talo [jeremyra1@gateway/shell/matrix.org/x-tdrxgspccxroisrp] has joined #bitcoin-wizards 12:57 -!- dl3br[m] [dlebrechtm@gateway/shell/matrix.org/x-chwenbpdimfuqosy] has joined #bitcoin-wizards 12:57 -!- mael-rolland[m] [mael-rolla@gateway/shell/matrix.org/x-hybbornnfndepota] has joined #bitcoin-wizards 12:57 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-pvuhrdptiepzivku] has joined #bitcoin-wizards 12:57 -!- charuto [charutocaf@gateway/shell/matrix.org/x-yidsswxhwnjivgeo] has joined #bitcoin-wizards 13:00 -!- selenamarie [~selenamar@139.28.218.198] has quit [] 13:02 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-wizards 13:07 -!- Kiminuo [~mix@141.98.103.124] has quit [Ping timeout: 260 seconds] 13:10 -!- yacg [b9f6d058@185.246.208.88.adsl.inet-telecom.org] has joined #bitcoin-wizards 13:18 -!- unknown1 [~unknown@104.254.90.235] has joined #bitcoin-wizards 13:20 -!- jungly [~jungly@a-si4-24.tin.it] has quit [Read error: Connection reset by peer] 13:20 -!- jungly_ [~jungly@a-si4-24.tin.it] has joined #bitcoin-wizards 13:21 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 13:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 13:27 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 13:28 -!- yacg [b9f6d058@185.246.208.88.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds] 13:29 -!- Guyver2__ [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 13:31 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 13:33 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 13:35 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 13:36 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 13:37 -!- shush [~pawn@cpe-76-176-12-33.san.res.rr.com] has joined #bitcoin-wizards 13:44 -!- jungly_ [~jungly@a-si4-24.tin.it] has quit [Remote host closed the connection] 13:45 -!- jungly [~jungly@a-si4-24.tin.it] has joined #bitcoin-wizards 13:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 13:51 -!- jungly [~jungly@a-si4-24.tin.it] has quit [Remote host closed the connection] 13:52 -!- jungly [~jungly@a-si4-24.tin.it] has joined #bitcoin-wizards 13:54 -!- dome [~e-mod@2603:3020:2608:1000:f02a:7b52:489a:ef1a] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 13:59 -!- jungly [~jungly@a-si4-24.tin.it] has quit [Remote host closed the connection] 14:01 -!- shush [~pawn@cpe-76-176-12-33.san.res.rr.com] has quit [Remote host closed the connection] 14:03 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 14:25 -!- IGHOR [~quassel@93.178.216.72] has quit [Ping timeout: 272 seconds] 14:28 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 14:28 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 14:35 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Ping timeout: 272 seconds] 14:48 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 14:49 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-wizards 14:52 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Ping timeout: 240 seconds] 15:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 15:25 -!- nick_fre_ [~nick_free@2001:16b8:3097:f800:29f3:56ea:fa9:9e5b] has quit [Remote host closed the connection] 15:26 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:29f3:56ea:fa9:9e5b] has joined #bitcoin-wizards 15:36 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Ping timeout: 265 seconds] 15:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 15:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 15:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 15:58 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 260 seconds] 16:00 -!- unknown1 [~unknown@104.254.90.235] has quit [] 16:06 -!- marcoagner [~user@bl11-16-246.dsl.telepac.pt] has quit [Ping timeout: 260 seconds] 16:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 16:18 -!- robwerks1 [~robwerks@139.28.218.198] has joined #bitcoin-wizards 16:23 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 16:23 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Read error: Connection reset by peer] 16:23 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 16:58 -!- tromp [~tromp@2a02:a210:ca3:2800:4843:8941:d47e:436a] has quit [Remote host closed the connection] 17:09 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:29f3:56ea:fa9:9e5b] has quit [Remote host closed the connection] 17:11 -!- tromp [~tromp@2a02:a210:ca3:2800:bd50:bf6e:4948:2600] has joined #bitcoin-wizards 17:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 17:14 -!- asukan [~jan@183.128.110.62] has joined #bitcoin-wizards 17:15 -!- tromp [~tromp@2a02:a210:ca3:2800:bd50:bf6e:4948:2600] has quit [Ping timeout: 246 seconds] 17:21 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:29f3:56ea:fa9:9e5b] has joined #bitcoin-wizards 17:22 -!- nick_fre_ [~nick_free@2001:16b8:3097:f800:2ca3:b0bd:e707:6810] has joined #bitcoin-wizards 17:22 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection] 17:26 -!- nick_freeman [~nick_free@2001:16b8:3097:f800:29f3:56ea:fa9:9e5b] has quit [Ping timeout: 240 seconds] 17:28 -!- bildramer [~bildramer@p200300CF3716B000247F6C468E93C389.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 17:29 -!- bildramer [~bildramer@p200300CF3716B000247F6C468E93C389.dip0.t-ipconnect.de] has joined #bitcoin-wizards 17:45 -!- nick_fre_ [~nick_free@2001:16b8:3097:f800:2ca3:b0bd:e707:6810] has quit [Remote host closed the connection] 17:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds] 17:48 -!- uncleray95 [183dc268@c-24-61-194-104.hsd1.ma.comcast.net] has joined #bitcoin-wizards 18:00 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-wizards 18:02 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-wizards 18:03 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 18:04 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-wizards 18:06 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 18:11 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection] 18:17 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-wizards 18:18 -!- nuncanada [~dude@187.21.52.222] has quit [Quit: Leaving] 18:24 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 18:27 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 18:29 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 18:39 -!- dome [~e-mod@170.250.42.23] has joined #bitcoin-wizards 18:53 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 18:57 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 18:57 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-wizards 19:00 -!- robwerks1 [~robwerks@139.28.218.198] has quit [] 19:00 -!- tromp [~tromp@2a02:a210:ca3:2800:bd50:bf6e:4948:2600] has joined #bitcoin-wizards 19:04 -!- dome [~e-mod@170.250.42.23] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 19:04 -!- tromp [~tromp@2a02:a210:ca3:2800:bd50:bf6e:4948:2600] has quit [Ping timeout: 272 seconds] 19:06 -!- dome [~e-mod@170.250.42.23] has joined #bitcoin-wizards 19:06 -!- dome [~e-mod@170.250.42.23] has quit [Client Quit] 19:08 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-wizards 19:18 -!- SynOps [~SynOps@185.189.112.11] has joined #bitcoin-wizards 19:25 -!- queip [~queip@unaffiliated/rezurus] has quit [Read error: Connection reset by peer] 19:30 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 19:34 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 19:34 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 19:39 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Ping timeout: 240 seconds] 19:39 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #bitcoin-wizards 19:42 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 19:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 19:44 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards 19:50 -!- CryptoDavid [uid14990@gateway/web/irccloud.com/x-cmmzsyvdcgrakmjj] has quit [Quit: Connection closed for inactivity] 20:00 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 20:02 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has quit [Ping timeout: 260 seconds] 20:03 -!- Belkaar [~Belkaar@xdsl-78-35-84-206.nc.de] has joined #bitcoin-wizards 20:03 -!- Belkaar [~Belkaar@xdsl-78-35-84-206.nc.de] has quit [Changing host] 20:03 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has joined #bitcoin-wizards 20:07 < RubenSomsen> For script only taproot spends, has hashToCurve(MAST) been considered as an alternate spend path? This would eliminate the need for a NUMS (saving 32 bytes) and still look like any other output prior to spending. All you'd lose is the ability to claim a valid taproot key path ever existed after spending (the same as if you'd use a publicly known NUMS, which perhaps should be discouraged). 20:08 < zmnscpxj> so there would be 3 spend paths? keyspend, taproot w/ non-NUMS keypair, taproot w/ hashToCurve(MAST)? 20:13 < RubenSomsen> yup 20:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 20:20 < RubenSomsen> So for top level key K you can either just sign with K, reveal K' and MAST (check that K == K' + hash(K'||MAST)G) and script spend, or just reveal MAST (check that K == hashToCurve(MAST)) and script spend 20:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 20:23 < sipa> RubenSomsen: that has the same problems, i think? 20:24 < sipa> people wouldn't be incentivized to build single-key-spendable protocols 20:25 < RubenSomsen> Would they not? Option 1 is still the cheapest. 20:27 < sipa> i think it depends on engineering costs 20:27 < sipa> and how much people care about privacy 20:28 < sipa> the existance of people to whom the engineering costs of building single-key-spendable protocols are not worth it reduce everyone's anonimity set 20:28 < RubenSomsen> If incentives are indeed a concern, it'd be more efficient to just raise the cost of using hashToCurve(MAST) by 32 vbytes. 20:29 < sipa> if after taproot is deployed we realize there is a significant need for things spendable using just mast without taproot, it can just be added as a new output type 20:29 < sipa> at no loss in efficiency or privacy 20:29 < sipa> (compared to having a spend-mast-directly that's output-indistinguishable from taproot) 20:31 < RubenSomsen> Hmm, it'd be indistinguishable assuming everyone upgrades, right? I mean that seems reasonable, just checking if I understood. 20:31 < sipa> no? 20:31 < jeremyrubin> sipa: there is a loss of privacy 20:31 < sipa> things that get spent using a mast-no-taproot construction are obviously distinguishable from taproot ones 20:32 < jeremyrubin> Loss of privacy at create time 20:32 < sipa> that's irrelevant, i think? 20:32 < sipa> outputs get spent 20:32 < jeremyrubin> It can be relevant 20:32 < jeremyrubin> e.g., if I want to censor txns to certain types of wallets? Or flag a wallet as sending to certain types 20:32 < RubenSomsen> sipa: I meant prior to spending 20:32 < sipa> jeremyrubin: then you'd censor them at spend time 20:33 < sipa> RubenSomsen: i don't think policy privacy at creation time matters (except to the extent that it hurts overall policy privacy) 20:33 < sipa> but if you're going to reveal the policy at spend time anyway, then nothing is gained by having it at creation time 20:34 < jeremyrubin> sipa: it just is a concrete observable metadatum 20:34 < jeremyrubin> you can argue it doesn't matter, but it is detectable 20:35 < jeremyrubin> And I think there's reasonable precedant in fin services that you can receive from whomever, but sending to whomever is restricted (e.g., OBL can deposit funds to BOFA but cannot withdraw) 20:35 < sipa> yes, it is detectable - but if spending reveals it, it will be detected anyway 20:36 < RubenSomsen> sipa: Policy privacy at creation time doesn't matter? Hmm, I'd have to think about that but I see what you're saying. 20:36 < sipa> fin? obl? bofa? 20:36 < jeremyrubin> fin = financial 20:36 < jeremyrubin> BoFa = Bank Of America 20:36 < sipa> RubenSomsen: well whatever is revealed at creation time is obviously a privacy loss 20:36 < jeremyrubin> OBL = # 1 most wanted man, thanks obama ;) 20:37 < sipa> jeremyrubin: i don't understand the relevance 20:37 < sipa> and all of this has way too many hypotheticals 20:37 < jeremyrubin> More just making the point that there are real world examples where receive time and send time are treated differently 20:38 < jeremyrubin> So a practical example! 20:38 < jeremyrubin> Here: 20:38 < zmnscpxj> the receive time of one entity is the send time of another entity, so... 20:38 < jeremyrubin> I am going to send to my 100 users 20:38 < jeremyrubin> 1 of them has a banned address type 20:38 < RubenSomsen> sipa: So would you agree that those who use a NUMS should use a non-public NUMS to maximize privacy? Because using a public NUMS seems equally bad to hashToCurve(MAST), privacy wise. 20:38 < jeremyrubin> now my batch won't get mined 20:38 < sipa> i expect that exactly nobody who has legitimately cannot use the key path in taproot will care about an extra 8 vbytes 20:38 < jeremyrubin> However, if it's the redeemers responsibility for the type of address 20:39 < jeremyrubin> Then I make my batch and there's no distinguishing output types 20:39 < jeremyrubin> and 99/100 users are ok 20:39 < jeremyrubin> So not being able to discriminate output types is good, even if the info is eventually revealed 20:40 < sipa> sure, all other things equal, i agree 20:40 < jeremyrubin> I think that as I suggested defining a public nums for use in the BIP might help with some of this... the worst case is if every wallets picks a different public nums 20:41 < jeremyrubin> I think per-address NUMS is relatively unlikely 20:41 < jeremyrubin> Unless it's also one of the leafs of the TapScript as an OP_RETURN script? 20:41 < jeremyrubin> That might be a convenient place to stick the metadata so you'd already need it... 20:42 < sipa> ? 20:42 < RubenSomsen> jeremyrubin: It seems to me that picking a publicly known NUMS reveals more info than strictly needed. It reveals that you were locked into the script spend. 20:43 < jeremyrubin> I agree -- hashToCurve(mast) is roughly equivalent 20:43 < sipa> RubenSomsen: tweak using H(thecript || yourprivkey) or so 20:44 < jeremyrubin> However, if the world doesn't agree on a single public NUMS 20:44 < sipa> so use H + r*G where r is a hash derived from your privkey 20:44 < jeremyrubin> E.g., hashToCurve("lightning user"), hashToCurve("coinbase user") 20:44 < jeremyrubin> Then there would be an addtl metadata leak 20:45 < jeremyrubin> v.s. if the BIP defines hashToCurve("NUMS") then says "use this", it's only a bit worse than hashToCurve(MAST) 20:45 < jeremyrubin> sipa: please no privkey in the nums lol 20:46 < jeremyrubin> if you need to audit the NUMS-ness of the point that's bad :) 20:46 < sipa> jeremyrubin: you can sign with NUMS-H 20:46 < sipa> to prove it's a nums 20:46 < jeremyrubin> NUMS-H? 20:46 < zmnscpxj> In a protocol where "everyone has to agree" anyway (i.e. all trustless ones), the "NUMS point" can be the n-of-n MuSig of all participants; then as long as some participant refuses to sign, you have the same effect (i.e. keyspend is impossible) 20:46 < aj> RubenSomsen: "raise the cost of using hashToCurve(MAST) by 32 vbytes" -- 32 weight units, 8 vbytes; revealing the NUMS point is witness data 20:46 < sipa> jeremyrubin: NUMS minus H 20:46 < jeremyrubin> ah ok 20:47 < jeremyrubin> I'm not sure how that helps without revealing H 20:47 < jeremyrubin> *preimage H 20:47 < sipa> H is a constant 20:47 < sipa> it's in the BIP 20:47 < jeremyrubin> Ah I thought H was the hash here 20:47 < RubenSomsen> aj: Thanks, 8 vbytes, my bad 20:48 < jeremyrubin> zmnscpxj: please no interactivity 20:49 < zmnscpxj> n-of-n MuSig is non-interactive 20:49 < zmnscpxj> and if you are refusing to sign, you are not interacting 20:49 < sipa> without interactivity you cannot have an indistinguishable nums point 20:49 < zmnscpxj> and in practice script paths have to fill in pubkeys of participants anyway, so you need *some* interaction, at minimum to provide pubkeys 20:50 < sipa> zmnscpxj: can be done using xpubs 20:50 < jeremyrubin> zmnscpxj: If i need to audit to the IRS that it was NUMS this is a bad idea 20:50 < sipa> nums point can't be obtained that way 20:50 < jeremyrubin> Because you can't prove it's NUMS 20:50 < zmnscpxj> well, there is that, assuming the IRS can be convinced 20:51 < jeremyrubin> E.g., if I'm making a tax advantaged annuity structure, you need NUMS to prove there was no alt spending path 20:51 < jeremyrubin> zmnscpxj: let's assume you take them to court and have a lawyer worth their salt 20:51 < jeremyrubin> Facts are facts, justice is blind ;) 20:52 < jeremyrubin> zmnscpxj: if it helps, let's assume sipa is the presiding judge 20:52 < zmnscpxj> could use a well-published NUMS point and tweak with the n-of-n MuSig; result is still a NUMS 20:52 < zmnscpxj> and again, n-of-n MuSig does not require interactivity, just pubkeys from all participants, which can also be extracted from xpub 20:54 < jeremyrubin> Ok here's another question then 20:54 < jeremyrubin> So you do this, and then you reuse the same n-of-n MuSig setup 20:54 < sipa> i'm wrong i think; you can have indistinguishable nonce points without interactive setup 20:54 < jeremyrubin> now both outputs have the same NUMS 20:55 < jeremyrubin> sipa: yeah you can just have H(nonce) and send everyone nonce 20:55 < sipa> "send everyone" = interactive 20:55 < jeremyrubin> Ah 20:55 < jeremyrubin> Well everyone has to receive something 20:55 < jeremyrubin> Do they just get the taproot output? 20:55 < jeremyrubin> Taproot Output + Scripts? 20:56 < zmnscpxj> interactivity is a spectrum: how many messages can you send and receive? 20:56 < sipa> by no interactive setup i mean: you can write a function of xpubs that computes the addresses 20:56 < sipa> zmnscpxj: none 20:56 < zmnscpxj> where did you get the xpubs then? 20:56 < zmnscpxj> bleah, semantics 20:56 < sipa> yeah :) 20:56 < zmnscpxj> let us proceed with your definition 20:57 < jeremyrubin> I disagree, but I'm curious where you're going 20:57 < sipa> better definition: no access to private keys is necessary to compute addresses (apart from a onetime get xpub from privkey) 20:57 < jeremyrubin> Assume we have just 1 xpub how does it work? 20:57 < jeremyrubin> it seems any adversary would be able to also run this deterministic function 20:58 < sipa> use MuSig(H,P1,P2,P3,...) with H the constant second generator, and P1...Pn are all the participant pubkeys 20:58 < sipa> not all pubkeys will be revealed to the chain 20:58 < sipa> assuming there are at least 2 branches 20:58 < jeremyrubin> branches = keys? 21:00 < zmnscpxj> Do all participants already pre-know the xpubs of other participants? 21:00 < jeremyrubin> So my general issue with this is there's sort of a baked in assumption that P1, P2... etc are a private group 21:01 < aj> what are y'all actually trying to do? 21:01 < jeremyrubin> I also don't see why we would need more than MuSig(H, P1) for any PN 21:01 < sipa> i don't know anymore 21:01 < zmnscpxj> convince sipa to make taproot more complicated, for nerd points 21:01 < aj> zmnscpxj: we've got entroot for that 21:02 < zmnscpxj> !!!! 21:02 < gribble> Error: "!!!" is not a valid command. 21:02 < jeremyrubin> entroot? 21:02 < zmnscpxj> Ent 21:02 < aj> graftroot, generalised taproot, and cross-input signature aggregation 21:02 * sipa needs to finish up writrup on that 21:02 < jeremyrubin> Ah Ok -- I thought it was a new thing 21:02 < sipa> but maybe taproot firdt 21:02 < jeremyrubin> EntWivesRoot 21:03 * jeremyrubin gets sued by the estate of tolkein 21:03 < zmnscpxj> Should have used a NUMS point 21:04 < jeremyrubin> aj: i think the question we're looking at is how should people be using NUMS point 21:04 < jeremyrubin> And if there isn't a great way of doing it, should we heed this 'group' ENTity and add a bare MAST? 21:05 < sipa> i don't see how those are related 21:05 < jeremyrubin> And if we did add bare MAST, is it bad to do it now, or as something that later splits the anonymity set to add it if NUMS proves hard to do 21:05 < jeremyrubin> sipa: this is at least what I perceived the conversation to be around when I jumped in. 21:06 < aj> jeremyrubin: if bare MAST is fine, then just using the constant H directly as the NUMS point is fine 21:06 < zmnscpxj> using a NUMS point implies you cannot use the keypath 21:06 < zmnscpxj> only advantage is saving 8 vbytes 21:06 < sipa> i think the reduction in incentives of bare mast is undesirable 21:06 < zmnscpxj> conversely, if bare MAST is undesirable, a constant H is also undesirable? 21:07 < sipa> zmnscpxj: no 21:07 < jeremyrubin> Can you restate this I think it was confusing 21:07 < zmnscpxj> ^^ 21:07 < jeremyrubin> [21:06] i think the reduction in incentives of bare mast is undesirable 21:08 < sipa> bare mast will result in plenty of users not bothering to implement key path spending because of engineering complexity - and they don't care enough about the privacy advantages 21:08 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 21:08 < aj> jeremyrubin: generalised taproot lets you have some script for free via the "key path", while still having a MAST-y "script path" alternative, but only works provided your first-priority-script includes a signature (to be key-path-like). if you've got something like CTV then to have an alternative you need to provide 32-bytes somehow, so script-path is already fine; and if you don't want alternatives 21:08 < aj> then a scriptPubKey of "hash OP_CTV" is good enough 21:08 -!- asukan_ [~quassel@ec2-35-180-180-58.eu-west-3.compute.amazonaws.com] has joined #bitcoin-wizards 21:09 -!- asukan [~jan@183.128.110.62] has quit [Quit: Konversation terminated!] 21:09 < jeremyrubin> aj: cf generalised taproot? 21:09 -!- asukan_ is now known as asukan 21:09 < aj> jeremyrubin: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html 21:10 < jeremyrubin> ok there's no way I'm going to grok that in the next 5 minutes 21:10 < aj> jeremyrubin: publish point P as scriptPubKey (segwit v2), and spend via script S and signature against public key "P-hash2curve(S)" 21:10 < jeremyrubin> Generalised taproot != BIPs 340-342 tho right? 21:10 < sipa> jeremyrubin: no generalized taproot = g'root 21:10 < RubenSomsen> sipa: Do I understand correctly that this concern is orthogonal to the cost of the extra 8 vbytes? 21:10 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 21:11 < zmnscpxj> Pedersen commitment k * G + s * H, where s is a script. If there is no script s (s == 0), you can keypath with k * G 21:12 < sipa> RubenSomsen: the extra 8 bytes (or rather, being forced to have a key branch) i hope will result in people looking into how to use it 21:12 < jeremyrubin> It seems like the only important claim is that 21:12 < jeremyrubin> I am personally not a fan of nudging people economically like that :/ 21:13 < sipa> jeremyrubin: privacy as a choice doesn't work 21:14 < jeremyrubin> I'd rather enable the thing that is 8 bytes smaller and artificially say it has to pay higher fees to spend than to not have it at all? 21:14 < sipa> what's the point? 21:14 < zmnscpxj> it nudges people economically as well 21:14 < RubenSomsen> sipa: OK, I see the argument for being forced to have a key branch. Because if it's just about the 8 vbytes then bare MAST could just be made 8 vbytes more expensive. 21:15 < sipa> RubenSomsen: right 21:15 < sipa> the 8 vbytes is likely nothing to most advanced script uses 21:15 < jeremyrubin> I'm just makign the point that RubenSomsen is making 21:16 < jeremyrubin> I think people could also, e.g., prefer p2sh masts because they'd save a lot of bytes on the lookup 21:16 < sipa> alternatively, see it this way: taproot gives you a free key path (or, it's included in the price anyway)... better use it 21:16 < sipa> lookup? 21:16 < jeremyrubin> But that it's worse for the security of the network 21:16 < jeremyrubin> I should be more specific 21:16 < jeremyrubin> Truncated Sha256 20 bytes masts 21:17 < jeremyrubin> to save 24 bytes per level of data 21:17 < jeremyrubin> But that if it's a major hit to the network on overall security, maybe better not to do it 21:17 < jeremyrubin> Same goes for privacy 21:18 < jeremyrubin> However, as a counterargument, people are always free to spoil their own privacy/security, so it's not clear to me how effective nudging is. 21:18 < sipa> right 21:18 < jeremyrubin> And personally think that NUMS is sort of annoying to get right in a non-metadata leaking way 21:18 < jeremyrubin> so if someone is using it, they're just getting penalized price wise for no gain 21:18 < sipa> jeremyrubin: the best you can achieve is making the more private option the cheaper one 21:19 < jeremyrubin> I personally have a small horse in this race 21:19 < jeremyrubin> because for the CTV stuff, you probably are using NUMS stuff a lot 21:20 < jeremyrubin> So it makes some stuff more annoying, and it makes compiling big CTV trees more annoying because of the EC muls and stuff. 21:20 < RubenSomsen> jeremyrubin: right, that seems like a potentially common NUMS use case 21:20 < jeremyrubin> But I think it's resolvable in many contexts. I'd just rather have it be cheaper 21:20 < jeremyrubin> Fortunately, CTV is (no longer!) a tapscript upgrade 21:20 < jeremyrubin> and the common case is a bare script tree 21:21 < jeremyrubin> so this isn't an issue for congestion control related use cases 21:22 < jeremyrubin> note that a downside is that the case where I have a couple branch CTV script, it may be cheaper for me to do it via segwit v0 than taproot 21:22 < jeremyrubin> so users will have to make that tradeoff 21:22 < sipa> jeremyrubin: let me make the effect more extreme in a hypothetival 21:23 < RubenSomsen> jeremyrubin: you also have me convinced that privacy at creation time does matter, even if you don't get it at spend time, because of situations where multiple outputs are created and one is being censored (coinjoin, op_ctv, etc.) 21:24 < sipa> imagine we had a way to make something like taproot, but it works always (e.g. use some fancy ZK proof technology that always hides scripts) 21:24 < jeremyrubin> Ah ok I think I see where you're going 21:25 < jeremyrubin> Any ZKP script is always let's say 1 KB 21:25 < sipa> this would almost certainly need to be done in a way that costs less than today's transactions, or the people who you want to use this the most (single key payments) wouldn't adopt it, breaking any gains your amazing technology could give 21:25 < sipa> exactly 21:25 < sipa> so either you hardfork to reduce the cost of the ZK proof 21:25 < sipa> or you outlaw old style single key payments 21:25 < sipa> both are ridiculous of course 21:26 < sipa> but when introducing something new, you have the choice to keep things that could technically be done cheaper more expensive, because the alternative interferes with the incentive to adopt ot 21:27 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Remote host closed the connection] 21:27 < sipa> in general i don't know the solution to this 21:28 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 21:28 < sipa> it means that some privacy improvements will be *really* hard to get adopted, even if all the tech is there 21:28 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 260 seconds] 21:28 < sipa> but here we have a case where a clear improvement is possible that woukd pretty much be a benefit for everyone, both in privacy and in cost 21:29 < jeremyrubin> Hm. So I think I have a few points within that framework. 21:29 < RubenSomsen> sipa: I'm missing something, why would reducing the cost of the ZK proof be a hard fork? 21:29 < jeremyrubin> 1) We should have a stronger story around NUMs usage 21:29 < sipa> RubenSomsen: or an extension block or so :p 21:29 < jeremyrubin> RubenSomsen: it can be a soft fork 21:29 < jeremyrubin> the reason is that there are a lot of ways to do it 21:30 < jeremyrubin> and a lot of ways leak metadata 21:30 < jeremyrubin> So it would be a shame if our anonymity set got more fractury because ossified nums stuff 21:30 < sipa> i really feel that adding bare mast is weakening taproot's story 21:30 < RubenSomsen> I imagine it'd be similar to segwit... discounted witness data, but yeah an extension block would be problematic 21:30 < jeremyrubin> Note I didn't say adding bare mast 21:30 < jeremyrubin> I said stronger story around using NUMS 21:31 < sipa> ah ok 21:31 < jeremyrubin> Like maybe a BIP 21:31 < jeremyrubin> Which defines storing the NUMS data as a branch in the script tree 21:31 < sipa> there is plenty of stuff around wallet usage that needs to be fleshed out 21:31 < sipa> like how to integrate in PSBT 21:31 < sipa> standardizing MuSig exactly 21:32 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Ping timeout: 240 seconds] 21:32 < jeremyrubin> sipa: I guess this is what I'm trying to get at as well? CTV already has cases where because people are fee sensitive they'd go to bare scripts. And v0 segwit is more effective for small numbers of branches. So I hazard some people will already do this stuff -- I guess my general push is that if we add bare MAST, then at least more people will be in the same pay-to anonymity set, and we only fracture at redeem from set. 21:32 < jeremyrubin> oops I copied that from earlier ignore sentence 1 21:33 < jeremyrubin> My point being, it's not clear we don't already have the above issue with incentives needing to be better to incent use 21:33 < jeremyrubin> So I'd rather make available what we can to make it a feewise efficient choice 21:33 < jeremyrubin> As you note, people will always choose cheaper 21:34 < jeremyrubin> This ends up coming down to if we think there are enough use cases that would opt out of Taproot because of cheaper fees in segwit v0 21:34 < sipa> i think there are a number of users that would obviously use key paths... single key, some multisig wallets, lightning, ... 21:35 < sipa> and there are a few cases where it absolutely can't be used 21:35 < sipa> then there are a large number of cases where it's not nearly as clear, and there are probably ways to do it with or without 21:36 < sipa> imho we should do everything possible to make sure the shelling point for commom spending becomes key path spendimg 21:37 < sipa> i'm really not convinced there are many (in volume) cases where key paths actually can't be used 21:37 < jeremyrubin> What do you think of my convo with harding in the taproot-bip-review chan? 21:37 < jeremyrubin> "conversation" 21:37 < jeremyrubin> He didn't reply 21:38 < sipa> and if we see there are, it can be added later - either as a separate bare mast output type, or it gets roped into the next script structure update (graftroot or cross-input aggregation or entroot or whatever) 21:38 -!- jimmysong [~jimmysong@65-36-83-142.static.grandenetworks.net] has quit [Read error: Connection reset by peer] 21:38 -!- jimmysong [~jimmysong@65-36-83-142.static.grandenetworks.net] has joined #bitcoin-wizards 21:39 < jeremyrubin> I guess that's reasonable -- but if we know there is a next update why over-index on the anonymity set today? 21:39 < sipa> we don't know anything for certain 21:39 < jeremyrubin> Why not make taproot a little bit worse so that entroot can be better? 21:40 < jeremyrubin> if you want to solve the "how will people upgrade" issue, taproot might be pretty sticky... 21:40 < sipa> i think we should always assume that the next softfork may be the last ome 21:40 < zmnscpxj> sipa: +! 21:40 < sipa> well it can't really be combined... pure mast will always be distinguishable from taproot or entroot or graftroot 21:41 < jeremyrubin> Hmm 21:41 < jeremyrubin> I disagree 21:41 < sipa> but at least the very weak "output time indistinguishability" can be had that way 21:41 < jeremyrubin> I could *imagine* a graftroot level tree like thing 21:41 < jeremyrubin> That could be hard to tell from sigs 21:41 < jeremyrubin> if you had some way of proving it was all PKRs or something but a third party couldn't without the certificate 21:42 < jeremyrubin> Anyways - that's a graftroot question 21:42 < jeremyrubin> I find it hard to reconcile your statements at 21:40 and 21:38 21:43 < jeremyrubin> If 21:40, and I have a mild belief that MAST may be very advantageous in this "lightning channel close apocolypse" scenario, then I should be fighting really hard to get it in now 21:43 < jeremyrubin> Because if we need it later we'd never get it 21:44 < sipa> then we should also do cross-input aggregation 21:44 < jeremyrubin> However, if I beleive 21:38, then I'm hunky-dory 21:44 < sipa> and graftroot 21:44 < sipa> and probably BLS signature 21:44 < jeremyrubin> But given that you beleive 21:40, I don't see how to reconcile 21:44 < sipa> and zero-knowledge proofs 21:44 < sipa> and probably confidential transactions 21:44 < sipa> :) 21:45 < jeremyrubin> don't forget ctv 21:45 < sipa> if yiu have general zero-knowledge proof scripts you don't need them ;) 21:45 < sipa> but sire 21:45 < sipa> sure 21:46 < jeremyrubin> So I guess the above is that i'm just saying I don't think you actually believe 21:40 21:46 < jeremyrubin> otherwise you just told us what you'd be doing :p 21:46 < sipa> i have no intention to work on any of those right now 21:46 < sipa> i don't know 21:47 < sipa> i think it's possible political drama makes taproot not happen 21:47 < jeremyrubin> Also I think re: 21:40 the more things you include in it the more likely it is to be the last one 21:47 < jeremyrubin> ;) 21:47 < sipa> and if that's the case it'd obviously be sad 21:47 < sipa> but that doesn't mean it's necessarily a terrible thing 21:47 < jeremyrubin> Well I mean more from a technical risk perspective 21:47 < sipa> bitcoin is great as it is 21:48 < jeremyrubin> Like risk of breaking bitcoin is somehow proportional to number of lines added (that we think are safe) 21:49 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-wizards 21:49 < jeremyrubin> Anyways, I guess just for the record I disagree with 21:40. 21:49 < jeremyrubin> I have a fun proposal: 21:49 < jeremyrubin> Two soft forks for Taproot, one which adds a spend time MAST. 21:50 < jeremyrubin> If just one and not the other, then we effectively have soft forked out the MAST or the Taproot 21:52 < jeremyrubin> (It's bad if we view BIP 9 as not voting but signaling to activate something we know we want) 21:52 < jeremyrubin> But I think miners, who signal, have the largest economic stake so hopefully they decide well 21:52 < zmnscpxj> More code complexity 21:53 < jeremyrubin> marginally so, it's probably +100 loc 21:53 < jeremyrubin> [21:47] i think it's possible political drama makes taproot not happen 21:53 < jeremyrubin> ^^^ that's the bigger worry 21:53 < sipa> the number of lines of code is not the problem 21:53 < jeremyrubin> I agree there is more complexity (4 possible end states of protocol) 21:53 < sipa> the amount of mental effort needed to convince people why they're there and that they should review them is 21:53 < jeremyrubin> But zmnscpxj did say code complexity. 21:54 < zmnscpxj> yes, but +100 loc != "marginally more code complexity" 21:54 < sipa> code complexity is more than lines of code 21:54 < sipa> anyway, semantics 21:55 < jeremyrubin> The verification rules could be pretty simple I think? Not much more complex than what's already there. I agree in abstract, I just mean that adding a "key or hash" lookup doesn't seem too fraught. 21:55 < sipa> i don't think the verification rules are the problem 21:59 < jeremyrubin> in any case -- going to switch off soon. 21:59 < jeremyrubin> Have you reviewed the work I've been doing for modeling CTV lately? 21:59 < jeremyrubin> I think you could do something similar for modeling the anonymity set under taproot v.s. taproot + MAST 22:00 -!- SynOps [~SynOps@185.189.112.11] has quit [] 22:00 < jeremyrubin> it would at least be dispositive to me if I could see under what sort of assumptions things look better or worse 22:01 < jeremyrubin> E.g., morcos expressed concern that CTV batching would overall lead to an increase in chain utilization 22:01 < jeremyrubin> Compared to just normal batching 22:01 < jeremyrubin> So I put together a model which shows that fee efficient normal batching is less efficient than CTV batching in terms of chainspace and fees https://github.com/JeremyRubin/CTVSims 22:02 < jeremyrubin> This is true if you assume that businesses outbound transactions have non constant fee distributions 22:02 < jeremyrubin> (because then they should batch by fee bands, and CTV is better at that kind of splitting up a txn with varied feerates) 22:03 < sipa> i don't know what kind of analysis is possible 22:03 < sipa> it's arguing between multiple hypotheticals that include hard to model numbers like engineering complexity 22:04 < jeremyrubin> I'd be open to helping you model it. 22:04 < jeremyrubin> The way that I've been doing it is abstracting out the distributions of numbers of things 22:04 < sipa> i don't think this is useful 22:04 < jeremyrubin> and then showing the results hold under different distributions 22:04 < sipa> this has nothing to do with distributions or numbers 22:05 < sipa> it's about different incentives and whether people care about them enough 22:05 < sipa> and priorities 22:06 < jeremyrubin> Well, you can look at my model for CTV in this example... I think i've done a reasonable job. I understand taproot is different, but not being able to model it at all makes it sound like it's a non falsifiable claim which ring unscientific 22:07 < jeremyrubin> I do generally beleive we can make some falsifiable hypotheisis about what taproot does for anonymity 22:07 < jeremyrubin> and show conditions under which it does and does not hold 22:07 < jeremyrubin> And that would be dispositive for the discourse 22:08 < sipa> the dispute is over what matters more to us as a community 22:08 < sipa> incentivizing privacy, or cheapness of things that can't use key paths 22:09 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has joined #bitcoin-wizards 22:09 < sipa> i don't think you can give a rational comparison of the form "X privacy is worth Y money" 22:09 < sipa> even if we could individually quantify those metrics 22:11 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-wizards 22:11 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection] 22:13 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 268 seconds] 22:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 22:13 < jeremyrubin> marketcap(ZCash) - marketcap(Bitcoin)? 22:13 < sipa> lol 22:14 < zmnscpxj> Or difference in earnings between an LN node vs. a JoinMarket maker 22:15 < jeremyrubin> I think the probelm is if we can't come up with a quantifiable framework for our anonymity gains we're already fucked 22:15 < jeremyrubin> Why use bitcoin at all v.s. 3% cash back on credit 22:15 < sipa> jeremyrubin: ok, i'll give you one 22:16 < sipa> we should prioritize privacy and incentives for it above all else 22:16 < sipa> as long as we can do so without changing security assumptions, and actually get it adopted (because of course, if nobody uses it, it's worthless) 22:17 < sipa> i don't think bare mast is a positive thing in that regard 22:18 -!- hellekin1 [~hellekin@141.98.101.133] has joined #bitcoin-wizards 22:19 -!- shush [~pawn@2605:e000:1c02:c564:d57c:737a:9cd2:2264] has quit [Ping timeout: 246 seconds] 22:20 -!- mryandao_ is now known as mryandao 22:21 < aj> a different way to think about it that i like is "key path" with musig/scriptless-scripts means the contract validation is done by a small set of interested people, while using actual script means the validation has to be done by all bitcoin users, so encouraging the key path approach is better for efficiency in general. for CTV, there's not as big a benefit -- you're just skipping a hash check and 22:21 < aj> intermediate transactions, but cut-through is still a win 22:23 -!- hellekin1 [~hellekin@141.98.101.133] has quit [Remote host closed the connection] 22:45 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-wizards 22:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds] 22:58 -!- Kiminuo [~mix@141.98.103.124] has joined #bitcoin-wizards 23:05 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 240 seconds] 23:16 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds] 23:22 -!- esandeen [~esandeen@185.189.112.19] has joined #bitcoin-wizards 23:24 -!- jungly [~jungly@host97-200-static.8-79-b.business.telecomitalia.it] has joined #bitcoin-wizards 23:25 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-wizards 23:35 -!- betawaffle [~betawaffl@h2.kdf.io] has quit [Remote host closed the connection] 23:35 -!- betawaffle [~betawaffl@h2.kdf.io] has joined #bitcoin-wizards 23:36 -!- tromp [~tromp@ip-213-127-95-129.ip.prioritytelecom.net] has joined #bitcoin-wizards 23:46 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 265 seconds] 23:53 -!- bildramer [~bildramer@p200300CF3716B000247F6C468E93C389.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 23:56 -!- bildramer [~bildramer@p200300CF3716B000247F6C468E93C389.dip0.t-ipconnect.de] has joined #bitcoin-wizards --- Log closed Tue Feb 18 00:00:44 2020