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
unknown1 has quit []
marcoagner has quit [Ping timeout: 260 seconds]
rusty has joined #bitcoin-wizards
robwerks1 has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
shush has quit [Read error: Connection reset by peer]
shush has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
nick_freeman has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
asukan has joined #bitcoin-wizards
tromp has quit [Ping timeout: 246 seconds]
nick_freeman has joined #bitcoin-wizards
nick_fre_ has joined #bitcoin-wizards
Emcy has quit [Remote host closed the connection]
nick_freeman has quit [Ping timeout: 240 seconds]
bildramer has quit [Remote host closed the connection]
bildramer has joined #bitcoin-wizards
nick_fre_ has quit [Remote host closed the connection]
AaronvanW has quit [Ping timeout: 272 seconds]
uncleray95 has joined #bitcoin-wizards
molly has joined #bitcoin-wizards
Dean_Guss has joined #bitcoin-wizards
mol has quit [Ping timeout: 265 seconds]
Emcy has joined #bitcoin-wizards
DeanGuss has quit [Ping timeout: 240 seconds]
Emcy has quit [Remote host closed the connection]
IGHOR has joined #bitcoin-wizards
nuncanada has quit [Quit: Leaving]
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
dome has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
Dean_Guss has quit [Remote host closed the connection]
Dean_Guss has joined #bitcoin-wizards
robwerks1 has quit []
tromp has joined #bitcoin-wizards
dome has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tromp has quit [Ping timeout: 272 seconds]
dome has joined #bitcoin-wizards
dome has quit [Client Quit]
Emcy has joined #bitcoin-wizards
SynOps has joined #bitcoin-wizards
queip has quit [Read error: Connection reset by peer]
queip has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 240 seconds]
zmnscpxj has joined #bitcoin-wizards
Dean_Guss has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-wizards
Aranjedeath has joined #bitcoin-wizards
CryptoDavid has quit [Quit: Connection closed for inactivity]
shush has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 260 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
<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).
<zmnscpxj> so there would be 3 spend paths? keyspend, taproot w/ non-NUMS keypair, taproot w/ hashToCurve(MAST)?
<RubenSomsen> yup
AaronvanW has quit [Ping timeout: 260 seconds]
<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
rusty has quit [Quit: Leaving.]
<sipa> RubenSomsen: that has the same problems, i think?
<sipa> people wouldn't be incentivized to build single-key-spendable protocols
<RubenSomsen> Would they not? Option 1 is still the cheapest.
<sipa> i think it depends on engineering costs
<sipa> and how much people care about privacy
<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
<RubenSomsen> If incentives are indeed a concern, it'd be more efficient to just raise the cost of using hashToCurve(MAST) by 32 vbytes.
<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
<sipa> at no loss in efficiency or privacy
<sipa> (compared to having a spend-mast-directly that's output-indistinguishable from taproot)
<RubenSomsen> Hmm, it'd be indistinguishable assuming everyone upgrades, right? I mean that seems reasonable, just checking if I understood.
<sipa> no?
<jeremyrubin> sipa: there is a loss of privacy
<sipa> things that get spent using a mast-no-taproot construction are obviously distinguishable from taproot ones
<jeremyrubin> Loss of privacy at create time
<sipa> that's irrelevant, i think?
<sipa> outputs get spent
<jeremyrubin> It can be relevant
<jeremyrubin> e.g., if I want to censor txns to certain types of wallets? Or flag a wallet as sending to certain types
<RubenSomsen> sipa: I meant prior to spending
<sipa> jeremyrubin: then you'd censor them at spend time
<sipa> RubenSomsen: i don't think policy privacy at creation time matters (except to the extent that it hurts overall policy privacy)
<sipa> but if you're going to reveal the policy at spend time anyway, then nothing is gained by having it at creation time
<jeremyrubin> sipa: it just is a concrete observable metadatum
<jeremyrubin> you can argue it doesn't matter, but it is detectable
<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)
<sipa> yes, it is detectable - but if spending reveals it, it will be detected anyway
<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.
<sipa> fin? obl? bofa?
<jeremyrubin> fin = financial
<jeremyrubin> BoFa = Bank Of America
<sipa> RubenSomsen: well whatever is revealed at creation time is obviously a privacy loss
<jeremyrubin> OBL = # 1 most wanted man, thanks obama ;)
<sipa> jeremyrubin: i don't understand the relevance
<sipa> and all of this has way too many hypotheticals
<jeremyrubin> More just making the point that there are real world examples where receive time and send time are treated differently
<jeremyrubin> So a practical example!
<jeremyrubin> Here:
<zmnscpxj> the receive time of one entity is the send time of another entity, so...
<jeremyrubin> I am going to send to my 100 users
<jeremyrubin> 1 of them has a banned address type
<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.
<jeremyrubin> now my batch won't get mined
<sipa> i expect that exactly nobody who has legitimately cannot use the key path in taproot will care about an extra 8 vbytes
<jeremyrubin> However, if it's the redeemers responsibility for the type of address
<jeremyrubin> Then I make my batch and there's no distinguishing output types
<jeremyrubin> and 99/100 users are ok
<jeremyrubin> So not being able to discriminate output types is good, even if the info is eventually revealed
<sipa> sure, all other things equal, i agree
<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
<jeremyrubin> I think per-address NUMS is relatively unlikely
<jeremyrubin> Unless it's also one of the leafs of the TapScript as an OP_RETURN script?
<jeremyrubin> That might be a convenient place to stick the metadata so you'd already need it...
<sipa> ?
<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.
<jeremyrubin> I agree -- hashToCurve(mast) is roughly equivalent
<sipa> RubenSomsen: tweak using H(thecript || yourprivkey) or so
<jeremyrubin> However, if the world doesn't agree on a single public NUMS
<sipa> so use H + r*G where r is a hash derived from your privkey
<jeremyrubin> E.g., hashToCurve("lightning user"), hashToCurve("coinbase user")
<jeremyrubin> Then there would be an addtl metadata leak
<jeremyrubin> v.s. if the BIP defines hashToCurve("NUMS") then says "use this", it's only a bit worse than hashToCurve(MAST)
<jeremyrubin> sipa: please no privkey in the nums lol
<jeremyrubin> if you need to audit the NUMS-ness of the point that's bad :)
<sipa> jeremyrubin: you can sign with NUMS-H
<sipa> to prove it's a nums
<jeremyrubin> NUMS-H?
<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)
<aj> RubenSomsen: "raise the cost of using hashToCurve(MAST) by 32 vbytes" -- 32 weight units, 8 vbytes; revealing the NUMS point is witness data
<sipa> jeremyrubin: NUMS minus H
<jeremyrubin> ah ok
<jeremyrubin> I'm not sure how that helps without revealing H
<jeremyrubin> *preimage H
<sipa> H is a constant
<sipa> it's in the BIP
<jeremyrubin> Ah I thought H was the hash here
<RubenSomsen> aj: Thanks, 8 vbytes, my bad
<jeremyrubin> zmnscpxj: please no interactivity
<zmnscpxj> n-of-n MuSig is non-interactive
<zmnscpxj> and if you are refusing to sign, you are not interacting
<sipa> without interactivity you cannot have an indistinguishable nums point
<zmnscpxj> and in practice script paths have to fill in pubkeys of participants anyway, so you need *some* interaction, at minimum to provide pubkeys
<sipa> zmnscpxj: can be done using xpubs
<jeremyrubin> zmnscpxj: If i need to audit to the IRS that it was NUMS this is a bad idea
<sipa> nums point can't be obtained that way
<jeremyrubin> Because you can't prove it's NUMS
<zmnscpxj> well, there is that, assuming the IRS can be convinced
<jeremyrubin> E.g., if I'm making a tax advantaged annuity structure, you need NUMS to prove there was no alt spending path
<jeremyrubin> zmnscpxj: let's assume you take them to court and have a lawyer worth their salt
<jeremyrubin> Facts are facts, justice is blind ;)
<jeremyrubin> zmnscpxj: if it helps, let's assume sipa is the presiding judge
<zmnscpxj> could use a well-published NUMS point and tweak with the n-of-n MuSig; result is still a NUMS
<zmnscpxj> and again, n-of-n MuSig does not require interactivity, just pubkeys from all participants, which can also be extracted from xpub
<jeremyrubin> Ok here's another question then
<jeremyrubin> So you do this, and then you reuse the same n-of-n MuSig setup
<sipa> i'm wrong i think; you can have indistinguishable nonce points without interactive setup
<jeremyrubin> now both outputs have the same NUMS
<jeremyrubin> sipa: yeah you can just have H(nonce) and send everyone nonce
<sipa> "send everyone" = interactive
<jeremyrubin> Ah
<jeremyrubin> Well everyone has to receive something
<jeremyrubin> Do they just get the taproot output?
<jeremyrubin> Taproot Output + Scripts?
<zmnscpxj> interactivity is a spectrum: how many messages can you send and receive?
<sipa> by no interactive setup i mean: you can write a function of xpubs that computes the addresses
<sipa> zmnscpxj: none
<zmnscpxj> where did you get the xpubs then?
<zmnscpxj> bleah, semantics
<sipa> yeah :)
<zmnscpxj> let us proceed with your definition
<jeremyrubin> I disagree, but I'm curious where you're going
<sipa> better definition: no access to private keys is necessary to compute addresses (apart from a onetime get xpub from privkey)
<jeremyrubin> Assume we have just 1 xpub how does it work?
<jeremyrubin> it seems any adversary would be able to also run this deterministic function
<sipa> use MuSig(H,P1,P2,P3,...) with H the constant second generator, and P1...Pn are all the participant pubkeys
<sipa> not all pubkeys will be revealed to the chain
<sipa> assuming there are at least 2 branches
<jeremyrubin> branches = keys?
<zmnscpxj> Do all participants already pre-know the xpubs of other participants?
<jeremyrubin> So my general issue with this is there's sort of a baked in assumption that P1, P2... etc are a private group
<aj> what are y'all actually trying to do?
<jeremyrubin> I also don't see why we would need more than MuSig(H, P1) for any PN
<sipa> i don't know anymore
<zmnscpxj> convince sipa to make taproot more complicated, for nerd points
<aj> zmnscpxj: we've got entroot for that
<zmnscpxj> !!!!
<gribble> Error: "!!!" is not a valid command.
<jeremyrubin> entroot?
<zmnscpxj> Ent
<aj> graftroot, generalised taproot, and cross-input signature aggregation
* sipa needs to finish up writrup on that
<jeremyrubin> Ah Ok -- I thought it was a new thing
<sipa> but maybe taproot firdt
<jeremyrubin> EntWivesRoot
* jeremyrubin gets sued by the estate of tolkein
<zmnscpxj> Should have used a NUMS point
<jeremyrubin> aj: i think the question we're looking at is how should people be using NUMS point
<jeremyrubin> And if there isn't a great way of doing it, should we heed this 'group' ENTity and add a bare MAST?
<sipa> i don't see how those are related
<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
<jeremyrubin> sipa: this is at least what I perceived the conversation to be around when I jumped in.
<aj> jeremyrubin: if bare MAST is fine, then just using the constant H directly as the NUMS point is fine
<zmnscpxj> using a NUMS point implies you cannot use the keypath
<zmnscpxj> only advantage is saving 8 vbytes
<sipa> i think the reduction in incentives of bare mast is undesirable
<zmnscpxj> conversely, if bare MAST is undesirable, a constant H is also undesirable?
<sipa> zmnscpxj: no
<jeremyrubin> Can you restate this I think it was confusing
<zmnscpxj> ^^
<jeremyrubin> [21:06] <sipa> i think the reduction in incentives of bare mast is undesirable
<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
shush has quit [Remote host closed the connection]
<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
<aj> then a scriptPubKey of "hash OP_CTV" is good enough
asukan_ has joined #bitcoin-wizards
asukan has quit [Quit: Konversation terminated!]
<jeremyrubin> aj: cf generalised taproot?
asukan_ is now known as asukan
<jeremyrubin> ok there's no way I'm going to grok that in the next 5 minutes
<aj> jeremyrubin: publish point P as scriptPubKey (segwit v2), and spend via script S and signature against public key "P-hash2curve(S)"
<jeremyrubin> Generalised taproot != BIPs 340-342 tho right?
<sipa> jeremyrubin: no generalized taproot = g'root
<RubenSomsen> sipa: Do I understand correctly that this concern is orthogonal to the cost of the extra 8 vbytes?
shush has joined #bitcoin-wizards
<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
<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
<jeremyrubin> It seems like the only important claim is that
<jeremyrubin> I am personally not a fan of nudging people economically like that :/
<sipa> jeremyrubin: privacy as a choice doesn't work
<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?
<sipa> what's the point?
<zmnscpxj> it nudges people economically as well
<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.
<sipa> RubenSomsen: right
<sipa> the 8 vbytes is likely nothing to most advanced script uses
<jeremyrubin> I'm just makign the point that RubenSomsen is making
<jeremyrubin> I think people could also, e.g., prefer p2sh masts because they'd save a lot of bytes on the lookup
<sipa> alternatively, see it this way: taproot gives you a free key path (or, it's included in the price anyway)... better use it
<sipa> lookup?
<jeremyrubin> But that it's worse for the security of the network
<jeremyrubin> I should be more specific
<jeremyrubin> Truncated Sha256 20 bytes masts
<jeremyrubin> to save 24 bytes per level of data
<jeremyrubin> But that if it's a major hit to the network on overall security, maybe better not to do it
<jeremyrubin> Same goes for privacy
<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.
<sipa> right
<jeremyrubin> And personally think that NUMS is sort of annoying to get right in a non-metadata leaking way
<jeremyrubin> so if someone is using it, they're just getting penalized price wise for no gain
<sipa> jeremyrubin: the best you can achieve is making the more private option the cheaper one
<jeremyrubin> I personally have a small horse in this race
<jeremyrubin> because for the CTV stuff, you probably are using NUMS stuff a lot
<jeremyrubin> So it makes some stuff more annoying, and it makes compiling big CTV trees more annoying because of the EC muls and stuff.
<RubenSomsen> jeremyrubin: right, that seems like a potentially common NUMS use case
<jeremyrubin> But I think it's resolvable in many contexts. I'd just rather have it be cheaper
<jeremyrubin> Fortunately, CTV is (no longer!) a tapscript upgrade
<jeremyrubin> and the common case is a bare script tree
<jeremyrubin> so this isn't an issue for congestion control related use cases
<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
<jeremyrubin> so users will have to make that tradeoff
<sipa> jeremyrubin: let me make the effect more extreme in a hypothetival
<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.)
<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)
<jeremyrubin> Ah ok I think I see where you're going
<jeremyrubin> Any ZKP script is always let's say 1 KB
<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
<sipa> exactly
<sipa> so either you hardfork to reduce the cost of the ZK proof
<sipa> or you outlaw old style single key payments
<sipa> both are ridiculous of course
<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
shush has quit [Remote host closed the connection]
<sipa> in general i don't know the solution to this
shush has joined #bitcoin-wizards
<sipa> it means that some privacy improvements will be *really* hard to get adopted, even if all the tech is there
Madars has quit [Ping timeout: 260 seconds]
<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
<jeremyrubin> Hm. So I think I have a few points within that framework.
<RubenSomsen> sipa: I'm missing something, why would reducing the cost of the ZK proof be a hard fork?
<jeremyrubin> 1) We should have a stronger story around NUMs usage
<sipa> RubenSomsen: or an extension block or so :p
<jeremyrubin> RubenSomsen: it can be a soft fork
<jeremyrubin> the reason is that there are a lot of ways to do it
<jeremyrubin> and a lot of ways leak metadata
<jeremyrubin> So it would be a shame if our anonymity set got more fractury because ossified nums stuff
<sipa> i really feel that adding bare mast is weakening taproot's story
<RubenSomsen> I imagine it'd be similar to segwit... discounted witness data, but yeah an extension block would be problematic
<jeremyrubin> Note I didn't say adding bare mast
<jeremyrubin> I said stronger story around using NUMS
<sipa> ah ok
<jeremyrubin> Like maybe a BIP
<jeremyrubin> Which defines storing the NUMS data as a branch in the script tree
<sipa> there is plenty of stuff around wallet usage that needs to be fleshed out
<sipa> like how to integrate in PSBT
<sipa> standardizing MuSig exactly
shush has quit [Ping timeout: 240 seconds]
<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.
<jeremyrubin> oops I copied that from earlier ignore sentence 1
<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
<jeremyrubin> So I'd rather make available what we can to make it a feewise efficient choice
<jeremyrubin> As you note, people will always choose cheaper
<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
<sipa> i think there are a number of users that would obviously use key paths... single key, some multisig wallets, lightning, ...
<sipa> and there are a few cases where it absolutely can't be used
<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
<sipa> imho we should do everything possible to make sure the shelling point for commom spending becomes key path spendimg
<sipa> i'm really not convinced there are many (in volume) cases where key paths actually can't be used
<jeremyrubin> What do you think of my convo with harding in the taproot-bip-review chan?
<jeremyrubin> "conversation"
<jeremyrubin> He didn't reply
<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)
jimmysong has quit [Read error: Connection reset by peer]
jimmysong has joined #bitcoin-wizards
<jeremyrubin> I guess that's reasonable -- but if we know there is a next update why over-index on the anonymity set today?
<sipa> we don't know anything for certain
<jeremyrubin> Why not make taproot a little bit worse so that entroot can be better?
<jeremyrubin> if you want to solve the "how will people upgrade" issue, taproot might be pretty sticky...
<sipa> i think we should always assume that the next softfork may be the last ome
<zmnscpxj> sipa: +!
<sipa> well it can't really be combined... pure mast will always be distinguishable from taproot or entroot or graftroot
<jeremyrubin> Hmm
<jeremyrubin> I disagree
<sipa> but at least the very weak "output time indistinguishability" can be had that way
<jeremyrubin> I could *imagine* a graftroot level tree like thing
<jeremyrubin> That could be hard to tell from sigs
<jeremyrubin> if you had some way of proving it was all PKRs or something but a third party couldn't without the certificate
<jeremyrubin> Anyways - that's a graftroot question
<jeremyrubin> I find it hard to reconcile your statements at 21:40 and 21:38
<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
<jeremyrubin> Because if we need it later we'd never get it
<sipa> then we should also do cross-input aggregation
<jeremyrubin> However, if I beleive 21:38, then I'm hunky-dory
<sipa> and graftroot
<sipa> and probably BLS signature
<jeremyrubin> But given that you beleive 21:40, I don't see how to reconcile
<sipa> and zero-knowledge proofs
<sipa> and probably confidential transactions
<sipa> :)
<jeremyrubin> don't forget ctv
<sipa> if yiu have general zero-knowledge proof scripts you don't need them ;)
<sipa> but sire
<sipa> sure
<jeremyrubin> So I guess the above is that i'm just saying I don't think you actually believe 21:40
<jeremyrubin> otherwise you just told us what you'd be doing :p
<sipa> i have no intention to work on any of those right now
<sipa> i don't know
<sipa> i think it's possible political drama makes taproot not happen
<jeremyrubin> Also I think re: 21:40 the more things you include in it the more likely it is to be the last one
<jeremyrubin> ;)
<sipa> and if that's the case it'd obviously be sad
<sipa> but that doesn't mean it's necessarily a terrible thing
<jeremyrubin> Well I mean more from a technical risk perspective
<sipa> bitcoin is great as it is
<jeremyrubin> Like risk of breaking bitcoin is somehow proportional to number of lines added (that we think are safe)
Madars has joined #bitcoin-wizards
<jeremyrubin> Anyways, I guess just for the record I disagree with 21:40.
<jeremyrubin> I have a fun proposal:
<jeremyrubin> Two soft forks for Taproot, one which adds a spend time MAST.
<jeremyrubin> If just one and not the other, then we effectively have soft forked out the MAST or the Taproot
<jeremyrubin> (It's bad if we view BIP 9 as not voting but signaling to activate something we know we want)
<jeremyrubin> But I think miners, who signal, have the largest economic stake so hopefully they decide well
<zmnscpxj> More code complexity
<jeremyrubin> marginally so, it's probably +100 loc
<jeremyrubin> [21:47] <sipa> i think it's possible political drama makes taproot not happen
<jeremyrubin> ^^^ that's the bigger worry
<sipa> the number of lines of code is not the problem
<jeremyrubin> I agree there is more complexity (4 possible end states of protocol)
<sipa> the amount of mental effort needed to convince people why they're there and that they should review them is
<jeremyrubin> But zmnscpxj did say code complexity.
<zmnscpxj> yes, but +100 loc != "marginally more code complexity"
<sipa> code complexity is more than lines of code
<sipa> anyway, semantics
<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.
<sipa> i don't think the verification rules are the problem
<jeremyrubin> in any case -- going to switch off soon.
<jeremyrubin> Have you reviewed the work I've been doing for modeling CTV lately?
<jeremyrubin> I think you could do something similar for modeling the anonymity set under taproot v.s. taproot + MAST
SynOps has quit []
<jeremyrubin> it would at least be dispositive to me if I could see under what sort of assumptions things look better or worse
<jeremyrubin> E.g., morcos expressed concern that CTV batching would overall lead to an increase in chain utilization
<jeremyrubin> Compared to just normal batching
<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
<jeremyrubin> This is true if you assume that businesses outbound transactions have non constant fee distributions
<jeremyrubin> (because then they should batch by fee bands, and CTV is better at that kind of splitting up a txn with varied feerates)
<sipa> i don't know what kind of analysis is possible
<sipa> it's arguing between multiple hypotheticals that include hard to model numbers like engineering complexity
<jeremyrubin> I'd be open to helping you model it.
<jeremyrubin> The way that I've been doing it is abstracting out the distributions of numbers of things
<sipa> i don't think this is useful
<jeremyrubin> and then showing the results hold under different distributions
<sipa> this has nothing to do with distributions or numbers
<sipa> it's about different incentives and whether people care about them enough
<sipa> and priorities
<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
<jeremyrubin> I do generally beleive we can make some falsifiable hypotheisis about what taproot does for anonymity
<jeremyrubin> and show conditions under which it does and does not hold
<jeremyrubin> And that would be dispositive for the discourse
<sipa> the dispute is over what matters more to us as a community
<sipa> incentivizing privacy, or cheapness of things that can't use key paths
shush has joined #bitcoin-wizards
<sipa> i don't think you can give a rational comparison of the form "X privacy is worth Y money"
<sipa> even if we could individually quantify those metrics
mryandao_ has joined #bitcoin-wizards
mryandao has quit [Remote host closed the connection]
Madars has quit [Ping timeout: 268 seconds]
AaronvanW has joined #bitcoin-wizards
<jeremyrubin> marketcap(ZCash) - marketcap(Bitcoin)?
<sipa> lol
<zmnscpxj> Or difference in earnings between an LN node vs. a JoinMarket maker
<jeremyrubin> I think the probelm is if we can't come up with a quantifiable framework for our anonymity gains we're already fucked
<jeremyrubin> Why use bitcoin at all v.s. 3% cash back on credit
<sipa> jeremyrubin: ok, i'll give you one
<sipa> we should prioritize privacy and incentives for it above all else
<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)
<sipa> i don't think bare mast is a positive thing in that regard
hellekin1 has joined #bitcoin-wizards
shush has quit [Ping timeout: 246 seconds]
mryandao_ is now known as mryandao
<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
<aj> intermediate transactions, but cut-through is still a win
hellekin1 has quit [Remote host closed the connection]
Madars has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 272 seconds]
Kiminuo has joined #bitcoin-wizards
Madars has quit [Ping timeout: 240 seconds]
justan0theruser has quit [Ping timeout: 246 seconds]
esandeen has joined #bitcoin-wizards
jungly has joined #bitcoin-wizards
Madars has joined #bitcoin-wizards
betawaffle has quit [Remote host closed the connection]
betawaffle has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
Madars has quit [Ping timeout: 265 seconds]
bildramer has quit [Remote host closed the connection]
bildramer has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
Madars has joined #bitcoin-wizards
t-bast has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
Madars has quit [Ping timeout: 265 seconds]
AaronvanW has joined #bitcoin-wizards
marcoagner has joined #bitcoin-wizards
slivera has joined #bitcoin-wizards
Madars has joined #bitcoin-wizards
esandeen has quit []
kurtc has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
Madars has quit [Ping timeout: 240 seconds]
solirc has joined #bitcoin-wizards
mol has joined #bitcoin-wizards
molly has quit [Ping timeout: 268 seconds]
Zenton has joined #bitcoin-wizards
setpill has joined #bitcoin-wizards
nick_freeman has joined #bitcoin-wizards
nick_freeman has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
kurtc has quit [Ping timeout: 260 seconds]
jcoe1 has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
jimmysong has quit [Read error: Connection reset by peer]
jimmysong has joined #bitcoin-wizards
kurtc has joined #bitcoin-wizards
shush has quit [Ping timeout: 240 seconds]
Madars has joined #bitcoin-wizards
someone235 has joined #bitcoin-wizards
Madars has quit [Ping timeout: 272 seconds]
son0p has joined #bitcoin-wizards
Madars has joined #bitcoin-wizards
t-bast has quit [Ping timeout: 260 seconds]
kurtc has quit [Ping timeout: 260 seconds]
Madars has quit [Ping timeout: 268 seconds]
jungly has quit [Remote host closed the connection]
t-bast has joined #bitcoin-wizards
solirc has quit []
t-bast has quit [Quit: Leaving]
Madars has joined #bitcoin-wizards
miconda has joined #bitcoin-wizards
slivera has quit [Remote host closed the connection]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
vcorem has joined #bitcoin-wizards
vcorem has quit [Client Quit]
Madars has quit [Ping timeout: 272 seconds]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
uncleray95 has quit [Remote host closed the connection]
rafalcpp has joined #bitcoin-wizards
son0p has quit [Quit: leaving]
Madars has joined #bitcoin-wizards
Madars has quit [Ping timeout: 240 seconds]
justanotheruser has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
jungly has joined #bitcoin-wizards
jimmysong has quit [Quit: Leaving]
Madars has joined #bitcoin-wizards
Madars has quit [Ping timeout: 272 seconds]
mol has quit [Read error: Connection reset by peer]
setpill has quit [Quit: o/]
zmnscpxj has quit [Quit: Leaving]
miconda has quit []
<EmmyNoether> The Trojan Message Attack on the Pay-to-Public-Key-Hash Protocol of Bitcoin | SpringerLink
Madars has joined #bitcoin-wizards
jimmysong has joined #bitcoin-wizards
Madars has quit [Ping timeout: 268 seconds]
shush has joined #bitcoin-wizards
mdunnio has joined #bitcoin-wizards
bsm1175321 has joined #bitcoin-wizards
bsm1175321 has quit [Client Quit]
jungly has quit [Remote host closed the connection]
jungly has joined #bitcoin-wizards
jb55 has quit [Quit: jb55]
bitcoin-wizards7 has joined #bitcoin-wizards
DASPRiD2 has joined #bitcoin-wizards
<bitcoin-wizards7> Zk rollup is far more efficient than CTV, basically same approach. Solves propagation. Recursive proofs Halo style are more flexible than cut-through. Solves IBD.cut-through
bitcoin-wizards7 has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<stevenro-> musalbas: not on eprint?
<sarang> Speaking of Halo, the preprint was just revised: https://eprint.iacr.org/2019/1021
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 240 seconds]
mdunnio has quit [Remote host closed the connection]
nuncanada has joined #bitcoin-wizards
<musalbas> don't think so, looks paywalled
<musalbas> just shared here as title and abstract looks relevant
shush has joined #bitcoin-wizards
<nsh> it's a book chapter/appendix
<nsh> (on springer, at least)
shush has quit [Ping timeout: 272 seconds]
shush has joined #bitcoin-wizards
<musalbas> it's conference proceedings
Madars has joined #bitcoin-wizards
* nsh nods
jb55 has joined #bitcoin-wizards
DASPRiD2 has quit []
Madars has quit [Ping timeout: 268 seconds]
Madars has joined #bitcoin-wizards
jungly has quit [Remote host closed the connection]
jungly has joined #bitcoin-wizards
<jeremyrubin> I think a ZK Rollup like technique is complementary to a OP_CTV like thing.
<jeremyrubin> whoever bitcoin-wizards7 was left the server, but there are good reasons to prefer something like CTV for now.
mdunnio has joined #bitcoin-wizards
Zenton has quit [Ping timeout: 260 seconds]
jungly has quit [Remote host closed the connection]
Cros1 has joined #bitcoin-wizards
<mappum> Has anyone worked on threshold multisig based on taproot which just uses musigs of the distinct subsets of signers? For example, 3-of-5 could just be one 3-subset aggregated key as the key spend path, and the aggregated keys of the 5 remaining 3-subsets in the script tree
laurentmt has joined #bitcoin-wizards
<mappum> There's a combinatoric explosion for larger sets, e.g. 10B subsets for 40-of-50, but you could pick a small number of those subsets and depending on what percentage of signers are willing to sign (being at least as high as the threshold), it would be probabilistically likely that one of the subsets is all present
<mappum> If it's an application where most of the signers will agree most of the time, then it gets to use the key spend path most of the time and is super compact
<sipa> mappum: not sure what you mean by "worked on", but that approach is explained in BIP 342
<sipa> ah, it does not mention the ability to have one aggregate as the key path
<mappum> sipa: oh cool, I've been reading an older version that I printed out a long time ago
<mappum> but what I'm thinking is that for the large sets, you can also have the big linear OP_CHECKSIGADD script as a fallback. so in most cases you'll either get to use the aggregated key path, or an aggregated key script path
AaronvanW has quit []
<sipa> mappum: good point
<mappum> It sucks that the signers would have to either know which of the musig subsets they are signing for, or sign for all the subsets at once. It would be cool if one partial signature could be aggregated into any of the given musig subsets
laurentmt has quit [Quit: laurentmt]
<mappum> It would be possible if c in the signature committed to the full set of possible signers rather than the aggregated subset key, but that would require something different from a normal schnorr checksig op
slivera has joined #bitcoin-wizards
nirved has quit [Ping timeout: 248 seconds]
nirved has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 246 seconds]
shush has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
shush has quit [Ping timeout: 240 seconds]
shush has joined #bitcoin-wizards
<uiuc-slack3> <smk7> Hey
rusty has quit [Quit: Leaving.]
mdunnio has quit [Remote host closed the connection]
shush has quit [Remote host closed the connection]
Zenton has joined #bitcoin-wizards
mdunnio has joined #bitcoin-wizards
jungly has joined #bitcoin-wizards
instagibbs has quit [Ping timeout: 260 seconds]
Cros1 has quit []
ddustin has joined #bitcoin-wizards
ddustin_ has joined #bitcoin-wizards
instagibbs has joined #bitcoin-wizards
ddustin_ has quit [Read error: Connection reset by peer]
ddustin has quit [Read error: Connection reset by peer]
ddustin__ has joined #bitcoin-wizards
Kiminuo has quit [Ping timeout: 240 seconds]
ddustin has joined #bitcoin-wizards
ddustin has quit [Read error: Connection reset by peer]
ddustin has joined #bitcoin-wizards
mreider has joined #bitcoin-wizards
ddustin has quit [Client Quit]
jungly has quit [Remote host closed the connection]
jungly has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
Guyver2 has quit [Ping timeout: 268 seconds]
shush has joined #bitcoin-wizards
jcoe1 has quit [Quit: Konversation terminated!]
ddustin__ has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 272 seconds]
Guyver2_ has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Chris_Stewart_5 has quit [Remote host closed the connection]
mdunnio has quit [Remote host closed the connection]
mryandao has quit [Remote host closed the connection]
mryandao has joined #bitcoin-wizards
zmnscpxj has joined #bitcoin-wizards
jungly has quit [Remote host closed the connection]
jungly has joined #bitcoin-wizards
jungly has quit [Remote host closed the connection]
luke-jr has quit [Ping timeout: 265 seconds]
shush has quit [Remote host closed the connection]
luke-jr has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
zmnscpxj_ has joined #bitcoin-wizards
zmnscpxj has quit [Ping timeout: 240 seconds]
shush has quit [Remote host closed the connection]
shush has joined #bitcoin-wizards
slivera has quit [Remote host closed the connection]
zmnscpxj_ has quit [Ping timeout: 240 seconds]
jungly has joined #bitcoin-wizards
jungly has quit [Remote host closed the connection]
shush has quit [Remote host closed the connection]
jonatack has quit [Ping timeout: 240 seconds]
rusty has joined #bitcoin-wizards
echonaut has quit [Remote host closed the connection]
echonaut has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
<nickler> The Pay-to-Public-Key-Hash attack paper unpaywalled https://rdcu.be/b1RuO
<sipa> ok, it's a 2^128 attack using the collision on the sighash function
<sipa> which they consider an attack because they believe Bitcoin aims at a 256 security level (??)
<nickler> because the hash function used is SHA256
marcoagner has quit [Ping timeout: 265 seconds]
<sipa> well it's easy to fork the network (arguably its most important function) with a collision attack on SHA256