12020-02-10T01:50:27  <harding> instagibbs: saw your tweet, I guess my email was unclear because what you said is what I was trying to say in the email.
  22020-02-10T01:50:33  <harding> https://twitter.com/theinstagibbs/status/1226663192455049216
  32020-02-10T01:51:56  <harding> instagibbs: I was trying to say that any n-of-n spends can be part of the anonymity set, which would include current n-of-n OP_CHECKMULTISIG users like Blockstream Green.
  42020-02-10T01:53:02  <harding> (Sorry for not replying on Twitter; I periodically lock myself out of my account for a week at a time when I think I'm spending too much time there, so I can't reply until Tuesday.)
  52020-02-10T01:53:49  <moneyball> fwiw that is how i read harding's response
  62020-02-10T02:37:55  <gmaxwell> harding: it's unclear how much current N of N (or other multisig) will eventually use schnorr multisig vs continue using CHECKMULTISIG, particularly because multisig implies additional rounds which are extremely inconvient for some use cases.
  72020-02-10T02:38:36  <harding> gmaxwell: yeah, fair point.
  82020-02-10T02:49:14  <aj> gmaxwell: n-of-n for cold wallets looks hard, but n-of-n for online hot wallets (lightning and maybe exchange hot wallets?) could mostly work?
  92020-02-10T02:50:12  <gmaxwell> yeah, e.g. the blockstream green thing has two online keys and an offline key  (or two online keys and some csv timeout thing).
 102020-02-10T02:50:38  <gmaxwell> Thats why I said 'some use cases', instead of all. :)
 112020-02-10T02:51:02  <gmaxwell> In any case, I don't mean to be negative-- I think it's just a genuinely open question how often it'll be used.
 122020-02-10T02:51:11  <gmaxwell> obviously I'd like to see it used a lot.
 132020-02-10T02:54:45  <sipa> there are some things that can fundamentally not use the key path (e.g. if you want a policy that enforces a timelock in all conditions) - for those cases, having a pure MAST without taproot construction would be advantageous for efficiency
 142020-02-10T02:54:52  <sipa> but i think those are extremely rare
 152020-02-10T02:55:16  <gmaxwell> or, even, arguably irrational.
 162020-02-10T02:55:37  <sipa> for everything else it's a question of software complexity and tradeoffs whether using the super cheap key path is worth it
 172020-02-10T02:55:52  <sipa> i expect that often it won't be, but i very much like the incentive that it gives
 182020-02-10T02:56:28  <gmaxwell> even for online users, having the code to handle a multiround protocol is a big hurdle. ... thats a lot of why it took so many years for payment channels to exist.
 192020-02-10T02:57:30  <gmaxwell> It's extremely easy to implement a pure-ish function that takes a transaction adds a signature if it likes it and passes it along.  Much harder to make some multistep protocol.  Though at least there isn't a ton of complicated state that needs to be managed.
 202020-02-10T02:57:40  <aj> i wonder how much psbt support will simplify multiround signing protocols
 212020-02-10T02:58:32  <gmaxwell> I'm sure some people will implement musig signing by just making a service that serves up nonce commitments and their openings, disconnected from signing, and will end up exploitable as a result. :(
 222020-02-10T05:15:37  <gmaxwell> harding: re your email:  arbitary k-of-n can also use the keypath, so long as they don't mind an interactive process (and storage) for generating their key in the first place.
 232020-02-10T05:15:55  <gmaxwell> harding: not just k-of-n where you can stick a k-of-k at the top.
 242020-02-10T05:17:53  <gmaxwell> harding: don't let the blockstream guys liquid specific focus create confusion on that.  Nickler, andytoshi, etc.  care a lot about a specific application where if someone you expects to sign instead emits garbage it won't cause any delay.  Turns out that case is hard to solve, esp of n choose k is large enough that you can't just attempt all subset-signings in parallel.
 252020-02-10T05:18:08  <gmaxwell> But that particular usage really only aplies to time critical unattended automated systems.
 262020-02-10T05:19:26  <gmaxwell> All the existant CHECKMULTISIG usage I've seen (except for liquid) is not robust to broken signers... in copay or bitcoin core psbt workfor for example, if a signer insists on producing invalid sigs you'll just get inscrutiable failures.
 272020-02-10T05:20:31  <gmaxwell> If you're okay with getting an inscrutiable failure and having to retry with different signers, then a relatively straight-forward process lets you sign w/ the keypath using an arbritary threshold.
 282020-02-10T05:25:29  <gmaxwell> Essentially the process for K of N is: Each of the N parties makes a private key, each of the N parties makes a K of N sharing of their private key and distributes it to all the other parties.  Each of the parties checks that they recieved consistent shares, and saves their shares of other parties keys. The key you pay to is the N of N key of all parties (you can, of course, also make bip32
 292020-02-10T05:25:29  <gmaxwell> tweaks of the result to get multiple keys from one setup process).    Then at signing time, you sign like a K of K, except for your private key you also add in your shares of the N-K missing participants.
 302020-02-10T05:27:52  <gmaxwell> this simple version has the problem that if one of your signers is broken/malicious he can make your signatures fail.  You can detect that (his partial signature, which you can verify on its own, will be invalid), but to continue you'd have to kick him out and the signing over with a different K that doesn't include him.
 312020-02-10T05:33:50  <gmaxwell> Verifyable secret sharing itself is pretty freeking simple. You implement standard SSS over the GF(N) field of the secp256k1 scalars, and send the person their share... and send everyone else their share converted into a public key.   The interpolation process to recover the SSS value can be applied equally to pubkeys as it can be applied to scalars, so you use this fact to make sure that
 322020-02-10T05:33:50  <gmaxwell> everyone's shares add up correctly and can-- in fact-- be used to recover each player's pubkey.  The reason for this step is because if you don't check, one signer could mess up their sharing and you wouldn't be able to sign without them.
 332020-02-10T05:35:18  <gmaxwell> My view is that the primary impedimate for most users is just that the multiple round trips suck-- but thats the same story for K of K  except for K of K there isn't anything you can do with a malicious signer other than identify them to the user.
 342020-02-10T05:39:07  <gmaxwell> Someone could argue that the need to backup the shares is also an extra burden, but thats not clear to me:  even for a N of N or checkmultisg you have to backup the redeemscript (or redeemscript template) -- otherwise if you forget your counterparties pubkeys, you're hosed.
 352020-02-10T05:40:29  <gmaxwell> An implementation could be hardened somewhat if you took the shares you recieved, encrypted them with a master key, and asked all participants to store them...  I think at that point the durability requirements are identical to a script-hash CHECKMULTISIG except it's a bit more data to store.
 362020-02-10T10:52:40  *** jonatack has quit IRC
 372020-02-10T10:56:19  *** dr_orlovsky has quit IRC
 382020-02-10T10:57:04  *** dr-orlovsky has joined ##taproot-bip-review
 392020-02-10T10:58:18  *** dr-orlovsky has quit IRC
 402020-02-10T10:58:32  *** dr-orlovsky has joined ##taproot-bip-review
 412020-02-10T10:58:46  *** dr-orlovsky has quit IRC
 422020-02-10T11:10:21  *** ghost43 has quit IRC
 432020-02-10T11:10:40  *** dr-orlovsky has joined ##taproot-bip-review
 442020-02-10T11:10:41  *** ghost43 has joined ##taproot-bip-review
 452020-02-10T11:11:30  *** dr_orlovsky has joined ##taproot-bip-review
 462020-02-10T11:30:34  *** jonatack has joined ##taproot-bip-review
 472020-02-10T11:31:39  *** dr-orlovsky has quit IRC
 482020-02-10T11:53:08  *** dr-orlovsky has joined ##taproot-bip-review
 492020-02-10T12:30:23  *** jonatack has quit IRC
 502020-02-10T13:48:52  <harding> gmaxwell: thanks!  I've indeed been a bit confused by some of the things I've read in the past couple months about the safety of k<1/2n threshold signatures, and as a consequence avoiding making any claims that depend on their existence, so I really appreciate you explaining the problem and its simplest mitigations so clearly.
 512020-02-10T14:04:43  *** ghost43 has quit IRC
 522020-02-10T14:09:47  *** ghost43 has joined ##taproot-bip-review
 532020-02-10T14:11:39  <maaku> gmaxwell: irrational? the spv-proof sidechain necessarily must have all spend paths behind a CSV check
 542020-02-10T14:12:05  <maaku> just as an existence proof of a rational must-be-timelocked spend conditional
 552020-02-10T14:14:00  <maaku> generally any group contract with a forced settling period would have that construct
 562020-02-10T15:40:48  <nickler> gmaxwell: to be clear I care most about coming up with something that is secure and has a straightforward and general API (for which it would help to have a scheme that tolerates aborts)
 572020-02-10T15:53:54  *** ghost43 has quit IRC
 582020-02-10T15:55:19  *** ghost43 has joined ##taproot-bip-review
 592020-02-10T15:57:46  <harding> maaku: any individual or group who wants to impose a timelock on themself/itself can create a timelocked pre-signed transaction for which they delete a least one of the private keys required to sign an alternative transaction.  This is obviously less convenent than using OP_CLTV or OP_CSV, but it's more efficient and more private.
 602020-02-10T16:02:52  <harding> (I'm not sure I fully understand your spv-proof sidechain point, but any transaction that requires including an SPV proof in a scriptSig or witness is gonig to use a lot of data in any case, so worrying about saving a few vbytes seems like a premature optimization unless such usage becomes common.)
 612020-02-10T16:07:03  *** jonatack has joined ##taproot-bip-review
 622020-02-10T17:28:32  *** jonatack has quit IRC
 632020-02-10T18:52:57  *** jonatack has joined ##taproot-bip-review
 642020-02-10T19:06:02  *** ghost43 has quit IRC
 652020-02-10T19:06:32  *** ghost43 has joined ##taproot-bip-review
 662020-02-10T19:12:31  *** ghost43 has quit IRC
 672020-02-10T19:13:29  *** ghost43 has joined ##taproot-bip-review
 682020-02-10T20:36:23  *** ghost43 has quit IRC
 692020-02-10T20:38:21  <maaku> harding: that doesn't work for the spv-sidechain like case where the "entire group" is every user ever, past present and future
 702020-02-10T20:41:19  *** ghost43 has joined ##taproot-bip-review
 712020-02-10T20:45:12  <kanzure> gmaxwell: when you say "arguably irrational" you mean having timelocks is irrational? just want to check what you mean.
 722020-02-10T20:51:46  <gmaxwell> kanzure:  No. For every transaction there is a set of interested parties. Except for contrived puzzle bullshit for every previously existing transaction on Bitcoin (and the vast majority but not all prospective future uses) the set of interested parties is finite, fixed (or at least upper bounded), and known at key creation time.
 732020-02-10T20:52:54  <gmaxwell> If at least an upper bound is known and fixed at output creation time, then there is no reason to not let all of them togeather decide to move the coins.
 742020-02-10T20:55:21  <gmaxwell> Things like "I want to freeze my credit card in a block of ice" are irrational.  You can construct some contrived theories where unoverridable timelocks are adventagious-- like argue that paying someone timelocked coins could have different tax treatment, but this is a niche argument at at least somewhat contrived.  Similarly, you can come up with some kind of future use protocol where there
 752020-02-10T20:55:21  <gmaxwell> isn't a fixed upper bound.. or other obscure stuff. but thats inherently obscure.
 762020-02-10T20:55:38  <kanzure> sipa said that for timelock on all conditions, you cannot use the keypath. how is that true? you can sign only transactions that have nLockTime and nSequence set.
 772020-02-10T20:56:27  <sipa> kanzure: the example is for example "i want to forced hodl my own coins for a year, and i don't trust myself to make a presigned tx amd destroy the key properly"
 782020-02-10T20:56:50  <sipa> kanzure: in usual timelock contracts, it's perfectly fine to still permit an aggregate of all participant keys to spend
 792020-02-10T20:57:21  <kanzure> before the timelock is mature?
 802020-02-10T20:57:21  <gmaxwell> A timelock on _all_ conditions does not generally make any rational sense. If _every_ interested party agrees, just move the coins.   You might have some transaction where your policy if timelock A then alice, or timelock B alice or bob and charlie, or timelock C any of them.   But there is an ur-policy "if alice bob and charly agrees, ignore the timelocks"
 812020-02-10T20:58:15  <gmaxwell> You could construct some cast where you wouldn't want that but I argue that such cases are generally contrived and at least would never be _common_.
 822020-02-10T20:58:31  <kanzure> you're saying a timelock on all conditions is irrational, but sipa is saying a user might want to hold coins for a year
 832020-02-10T20:58:43  <sipa> kanzure: i'd say such a user is irrational
 842020-02-10T20:59:10  <kanzure> i have a use case where i use timelocks to force a certain spending pattern and have time to react to theft
 852020-02-10T20:59:33  <kanzure> with secure key deletion (or, optionally, bip119 OP_CHECKTEMPLATEVERIFY still with timelocks)
 862020-02-10T20:59:53  <sipa> but if that is a usecase you care about, you indeed cannot use the key path (it's still a privacy improvememt to make sure an output still looks like it might have had a key path spend)
 872020-02-10T20:59:56  <gmaxwell> kanzure: if the coins unconditionally cannot be spent before the timelock, how do you respond to the theft? your private key is stolen.
 882020-02-10T21:00:27  <kanzure> the coin is split into shard UTXOs and they can only steal one of the shards.
 892020-02-10T21:00:31  <gmaxwell> kanzure: presumably the CTV you've commited to pays to some other set of keys, right?
 902020-02-10T21:00:44  <kanzure> OK, nevermind, my output script has no timelock on all conditions (push-to-cold-storage has no timelock)
 912020-02-10T21:01:00  <gmaxwell> in that case the ur-policy might be _all_ the keys, not just the keys on the initial outputs normal paths, but also the keys on the successor CTV.
 922020-02-10T21:01:43  <gmaxwell> Right, thats my point. :P  almost always thats the case that there is some 'superset' policy that has not constraints other than agreement by some set of keys.
 932020-02-10T21:02:18  <kanzure> so backing up a sec, what's considered irrational is an OP_HODL (OP_CSV) can't-spend-at-all-until-later script.
 942020-02-10T21:02:57  <kanzure> with secure key deletion. or some other covenant mechanism.
 952020-02-10T21:03:24  <gmaxwell> Yes, thats irrational. I mean, sure people can do irrational things and have good reasons for doing them.  But there isn't a particular reason to think that they're esepecitally sticky or would ever be common.
 962020-02-10T21:03:55  <gmaxwell> in the case of "coins in a block of ice" or whatever, you could still spend them in any case, if you wanted to put enough work into it.
 972020-02-10T21:04:19  *** ghost43_ has joined ##taproot-bip-review
 982020-02-10T21:05:03  *** ghost43 has quit IRC
 992020-02-10T21:05:10  *** ghost43_ has quit IRC
1002020-02-10T21:05:19  <gmaxwell> Like, for example, if you foolishly OP_HODL'ed a bunch of coins, then the bitcoin price went way up and you were losing your mind over them.  I'd happily trade you unencumbered coins for a promise to pay me the encumbered coins,  ... for a fee and a lien on your house.  So a $50 fee to the county recorder, a few hours of time, and whatever interest rate I wanted to charge.
1012020-02-10T21:05:40  <gmaxwell> maybe adding that friction was worth it to you because your self control was really poor. ::shrugs::
1022020-02-10T21:05:52  <kanzure> say an adversary might have stolen a private key. with a timelock, you can delay when the thief can get access to the coins even if they have the private key that matches for the output script's CHECKSIG. this might give time for law enforcement investigation.
1032020-02-10T21:06:02  *** ghost43 has joined ##taproot-bip-review
1042020-02-10T21:06:46  <kanzure> yes a lot of people have poor self control. sounds useful to me?
1052020-02-10T21:06:53  <gmaxwell> kanzure: but if that private key is the ONLY way to get the coins,  then they're going to get stolen once the lock expires.  Even if you how law enforcement catches them first, that also depends on them not having shared the key with anyone else before they're caught.
1062020-02-10T21:07:07  <kanzure> yes, that's correct
1072020-02-10T21:07:23  <kanzure> criminals are a superstitous crowd, and their schemes don't scale well because of denial-of-service and trust issues
1082020-02-10T21:07:32  <kanzure> superstitiously cowardly lot, as batman would say
1092020-02-10T21:07:38  <gmaxwell> kanzure: how useful? I just demonstrated that for $50 plus interest you could escape an unescapable OP_HODL.
1102020-02-10T21:08:12  <kanzure> (specifically there's a scaling limit to criminal enterprise because of defectors)
1112020-02-10T21:08:35  <gmaxwell> In any case, I think you've missed the plot of my point:  almost always there is some sign only case. You can make contrived things where there isn't.  But at the same time I can also turn your ones where there isn't back into ones where there is.
1122020-02-10T21:08:57  <harding> There's actually these vendors called pawn shops that offer what gmaxwell described as a service; they're abundant in the U.S. at least; dunno about other places.
1132020-02-10T21:09:41  <kanzure> i was thinking about locking substantial multiples of the value of my imaginary house... yes timelocked cold storage might be contrived but i'm struggling to see which use cases are being turned down (i mean OP_CSV still works anyway).
1142020-02-10T21:09:58  <gmaxwell> So for example, I could partner with a financial counselor and announce a public key where we'll sign for anyone but only if they've paid for a $500 financial counciling session for their signature.  Now you can make your OP_HODL spendable by yourself + that key.
1152020-02-10T21:10:18  <gmaxwell> kanzure: why do you say turned down?
1162020-02-10T21:10:33  <kanzure> this started from trying to parse the comments about keypath spends and timelocks being irrational
1172020-02-10T21:11:06  *** fly_on_wall has joined ##taproot-bip-review
1182020-02-10T21:12:10  <gmaxwell> kanzure: Wouldn't my "financial counselor + you  plus  you + timelock" be superior to just you+timelock alone, even if we assume you have a spending impluse problem?
1192020-02-10T21:12:38  <kanzure> if you were good at key storage in the first place then the thief wouldn't have stolen the private key the first time around.
1202020-02-10T21:14:21  <gmaxwell> kanzure: my comments don't really have anything to do with turning anything down, but rather pointing out that there is naturally a keypath only way to spend the overwhelming majority of policies.
1212020-02-10T21:14:41  <gmaxwell> Even in some contrived case like where we assume that the user has a spending problem, you can create one that is still superior to not having that option.
1222020-02-10T21:16:15  <gmaxwell> kanzure: in your theft case,  you'd still be better off with a keypath of {you + FBI + every bitcoin developer you can get a pubkey for} at the root.   Because then if your coins are stolen you're not just hoping that you can catch the theif before he takes them and that he hasn't clawed them back. ...  you also get the option of trying to convince all those parties that its okay for them to
1232020-02-10T21:16:15  <gmaxwell> sign.
1242020-02-10T21:19:18  <kanzure> a timelock being consensus enforced is quite useful, and there's on the other hand denial of service issues with adding each additional person-key to the magic script.
1252020-02-10T21:19:40  <gmaxwell> kanzure: there is no denial of service issue relative to not having the optional at all.
1262020-02-10T21:19:40  <kanzure> anyway, makes sense. as long as the proposal doesn't involve effecting attempts at using consensus-enforced approaches to improve cold storage security then i'm pretty happy.
1272020-02-10T21:20:47  <gmaxwell> kanzure: like maybe you could never get me + you + FBI + satoshi + etc to sign to undermine the theft, but having that option  wouldn't hurt you vs not having any option to bypass the timelock.
1282020-02-10T21:21:23  <gmaxwell> maybe it's not worth actually setting up that because it provides so little value, sure.
1292020-02-10T21:25:19  <gmaxwell> similarly for the fininicial planning example, even if we presume the coin holder can't help themselves, there is some other policy like incorporating oracles on bitcoin's price or a fininicial planner... which the hodlr would agree is better than the timelock alone.
1302020-02-10T21:25:42  <gmaxwell> not to mention the possibility of  HSM oracle non-network timelocks.
1312020-02-10T21:26:09  <gmaxwell> which can give better time resolution than the network.
1322020-02-10T21:28:35  <gmaxwell> like if you'd accept you+timelock    wouldn't you be better off with  you+timelock OR you+timelock_oracle1+timelock_oracle2+timelock_oracle3+timelock_oracle4+timelock_oracle5 ?  (the 'oracles' can just be a dumb service that publish private keys on a timer)
1332020-02-10T21:29:19  <gmaxwell> maybe some of the oracles go down and you can't use that option oh well.
1342020-02-10T21:29:49  <kanzure> why would you want oracles that publish private keys on a timer instead of just using a consensus-enforced timelock?
1352020-02-10T21:30:14  <kanzure> well your script might be the wrong example
1362020-02-10T21:30:17  <gmaxwell> more private, more efficient.
1372020-02-10T21:30:32  <gmaxwell> it's not instead of, it's an OR.
1382020-02-10T21:30:34  <gmaxwell> you can spend either way.
1392020-02-10T21:30:39  <harding> Since bcash, most people I've talked to about timelocked hodling have indicated they'd really want a 2-of-2 escape clause with a friend just in case there was another opportunity to sell off forkcoins.
1402020-02-10T21:31:27  <kanzure> if you use timelock time-released private key oracles then you can use taproot keypath i guess.
1412020-02-10T21:31:57  <gmaxwell> kanzure: also you might trust the _precision_ of the oracles more, so you could use a lower timelock.
1422020-02-10T21:32:14  <gmaxwell> kanzure: right. the script-timelock would be hidden.
1432020-02-10T21:32:21  <gmaxwell> harding: great point.
1442020-02-10T21:32:50  <gmaxwell> also, is there anyone who really ways a OP_HODL that guarentees they can't move coins even if bitcoin is trading at $100k/btc?
1452020-02-10T21:33:17  <gmaxwell> I would imagine almost anyone who wants that would be okay with at least portions becoming spendable at varrious price targets.
1462020-02-10T21:34:53  <kanzure> other than having perfectly protected private keys (which can only be done with secure key deletion or pubkey recovery from random hashes), is there a good method to minimize coercion from an adversary trying to steal coins?
1472020-02-10T21:35:01  <gmaxwell> So a policy of you+2years  OR you+"wladimir and greg both says price is currently>100k/btc"  would be a preferable policy to most people than just you+2years.
1482020-02-10T21:35:37  <kanzure> if we had perfectly protected key mechanisms then we would be loudly proclaiming "use this method" to everyone and i don't think we do that. so ideally there's on/off-chain constructions we can come up with to help minimize coercion (like e.g you can only steal at most n% before the user is able to respond).
1492020-02-10T21:35:42  <gmaxwell> kanzure: don't have coins in the first place, or multisignature with largely independant (hard to concurrently coerse) parties.
1502020-02-10T21:36:02  <gmaxwell> timelocks don't solve your problem
1512020-02-10T21:36:07  <kanzure> (also i recognize that coercion minimization is off-topic for a taproot review channel, sort of)
1522020-02-10T21:36:43  <kanzure> timelocks don't, but secure key deletion or provably unknowable keys can help enforce covenants that otherwise aren't otherwise enforceable by consensus at the moment
1532020-02-10T21:36:50  <gmaxwell> also keeping your funds private and indistinguishable to make you unattractive to attack.
1542020-02-10T21:36:54  <gmaxwell> I think talking about the efficiency and privacy of varrious spending patterns is relevant.
1552020-02-10T21:37:14  <kanzure> privacy once lost cannot be re-gained so it's not a robust solution
1562020-02-10T21:37:22  <kanzure> it's a very good one though.
1572020-02-10T21:37:35  <kanzure> also "don't have coins" seems like the wrong approach for bitcoin security
1582020-02-10T21:38:02  <gmaxwell> kanzure: which is a reason why, e.g. you would prefer the you+timelock oracles vs you+timelock alone.
1592020-02-10T21:38:09  <gmaxwell> (privacy)
1602020-02-10T21:38:46  <gmaxwell> I think your "but secure key deletion or provably unknowable keys can help enforce covenants" statement is extremely vague.
1612020-02-10T21:38:57  <gmaxwell> To the extent that I agree it's true, its mostly meaningless to me.
1622020-02-10T21:39:18  <kanzure> pre-signed transactions then delete the key (trusted setup) (secure key deletion). this enforces that only a certain set of valid transactions can ever exist.
1632020-02-10T21:39:35  <gmaxwell> If you want to enforce a rule that the network can't enforce, you'll need to invoke some other parties.
1642020-02-10T21:40:05  <kanzure> (provably unknowable keys is the pubkey recovery thing where you use a blockhash as your signature against a tree of transactions (requires SIGHASH_NOINPUT and to remove the pubkey commitment requirement from the signature))
1652020-02-10T21:40:32  <gmaxwell> kanzure: that is very nearly equivilent to assigning it to some mixture of those destination policies _now_. (perhaps with timelocks gating access to them)
1662020-02-10T21:45:11  <gmaxwell> if you'd make a transaction that pays to a securely deleted key which has authored timelocked transactions moving the coins to Alice or Bob now, you'd be better off with a policy that ored spending by alice or bob...  and also escape the risk that address reuse causes irrecoverable funds loss.
1672020-02-10T21:46:44  <kanzure> what i was seeking was a method to minimize coercion from adversaries attempting to steal (like compromising someone's magic-undocumented "perfect" cold storage system that was endorsed earlier); one thought i had was the only way to know a private key is stolen is to observe a spend, so you want only a fraction of the coin to be spendable at a time by that private key, with escape ...
1682020-02-10T21:46:50  <kanzure> ...clauses to push to cold storage (or ultimately: burn the coins) which reduces the incentive for a financially-motivated attacker (but not griefers that want you to burn your coins).
1692020-02-10T21:49:09  <kanzure> what is the maximum number of coins you would feel comfortable assigning to a multisig of all the bitcoin developers you know?
1702020-02-10T21:50:48  <gmaxwell> what do you mean by that precisely?
1712020-02-10T21:51:11  <kanzure> just asking where the security comes from. your proposal was "have really good key security", made up of a multisig of bitcoin developers right?
1722020-02-10T21:51:28  <gmaxwell> (ME) OR (ME && ALL-DEVELOPERS)   ?   all of them.
1732020-02-10T21:51:28  <kanzure> and key management is important yes, but users are bad at it, and if we can improve on that with bitcoin tech then we should try to do that
1742020-02-10T21:51:50  <gmaxwell> That is not a security reduction compared to ME alone.
1752020-02-10T21:52:01  <kanzure> right, coercion still yields all the coins from you to an adversary
1762020-02-10T21:52:07  <kanzure> with that script
1772020-02-10T21:53:23  <gmaxwell> right so you'd want (ME AND TIMELOCK) OR (ME && ALL-DEVELOPERS)  as your example?   Again, all of them, except for the whole being concerned about not getting access to the coins, which seems stupid.
1782020-02-10T21:53:54  <kanzure> arguably key management isn't a topic that bitcoin should solve (since it's a much broader topic), but protecting against theft of coins (or funds loss) is of interest to bitcoin
1792020-02-10T21:54:27  <gmaxwell> Keep in mind, there is a finite and probably very small amount of coercion resistance that makes sense to achieve with technical means.
1802020-02-10T21:54:36  <harding> If someone gets your private key but knows they can only spend 1/nth of them before you're able to send the rest to cold storage (or burn them), don't they then have a strong incentive to kill you (or at least, hold you hostage away from your computer)?  It's like a story I once heard of where, when anti-theft engine disablement mechanisms became popular in Russia, carjackings skyrocketed, leading to more people being injured
1812020-02-10T21:54:37  <harding> or dying (though the story did say how much car theft was reduced).
1822020-02-10T21:54:58  <gmaxwell> If someone kidnaps you and is going to hit you with a $5 wrench until you give them the coins, telling them you control no coins that you can immediately move is just going to get you killed or seriously injured.
1832020-02-10T21:54:59  <harding> s/did say/didn't say/
1842020-02-10T21:55:09  <gmaxwell> harding: jinx
1852020-02-10T21:55:12  <kanzure> harding: how will killing you help them? maybe you have tripwires that they don't know about, watchtower pushes to cold storage or burns the coins.
1862020-02-10T21:55:32  <harding> gmaxwell: :-)
1872020-02-10T21:56:00  <kanzure> you tell them you control no coins before you get kidnapped, you get kidnapped once they believe you do have some control influence over coins. and you don't get kidnapped if they understand they can't get anything by kidnapping you.
1882020-02-10T21:56:06  <gmaxwell> kanzure: killing you reduces the risk you can aid prosecution against them for kidnapping.
1892020-02-10T21:56:38  <gmaxwell> kanzure: it's really cheap to lie and exaggerate your security, most bitcoin businesses do (as we've found from expirence)
1902020-02-10T21:56:56  <kanzure> what's the maximm amount of coercion resistance that can be achieved with said technical means? that's what i think is interesting.
1912020-02-10T21:57:01  <gmaxwell> anyone crazy enough to kidnap would do well to ignore such protective coloration and get busy with the wrench.
1922020-02-10T21:57:22  <gmaxwell> kanzure: I think privacy is a much better protection via technical means, in spite of its limitations.
1932020-02-10T21:57:29  <kanzure> yes i'm willing to reject "lie about your cold storage security" strategy
1942020-02-10T21:57:39  <kanzure> privacy is not robust... once you lose your privacy, you can't get it back.
1952020-02-10T21:58:15  <gmaxwell> kanzure: I'm saying that no matter what you do most everyone is already lying about their cold storage stratgy (including lying that they have one), so a prospective kidnapper would probably just ignore those claims.
1962020-02-10T21:58:41  <gmaxwell> and instead use absent privacy to choose targets they are confident own enough coins to make their risks worthwhile.
1972020-02-10T21:58:52  <kanzure> that's a rational kidnapper right now, yes, because there's not a well-published solution that people can prove they're using... and also BTC isn't worth $1 bajillion yet...
1982020-02-10T21:59:19  <kanzure> the expectation should be set for kidnappers that the cold storage solution is good, rather than the expectation that it is bad
1992020-02-10T21:59:33  <kanzure> (or that someone is lying about their security level)
2002020-02-10T21:59:44  <gmaxwell> worse, if you have a people "proving they are using" -- it still doesn't prove that they don't have coins outside it, -- if they have a lot inside they probably also have a lot outside... and it proves they have a lot to begin with: time to kidnap and keep them in a cage until the timelock expires.
2012020-02-10T22:00:16  <gmaxwell> kanzure: well thats uphill, as I argue even the parties most able to have good security almost universally do not, and also lie about it.
2022020-02-10T22:00:20  <kanzure> yes cage-until-expiration is something that requires you to setup tripwires and deadman-whatevers before you get kidnapped
2032020-02-10T22:00:53  <gmaxwell> kanzure: and that you don't know about them or otherwise the can be defeated with the $5 wrench attack.
2042020-02-10T22:01:03  <gmaxwell> they*
2052020-02-10T22:02:00  <kanzure> i think we can do better than "if you lose your privacy then you're screwed" surely privacy is not the only means for achieving coercion resistance
2062020-02-10T22:02:36  <gmaxwell> it's not the only means, but it's one of the strongest.
2072020-02-10T22:03:04  <gmaxwell> (maybe you assume people will setup their security practices document the part they're supposted to remember then take midazolam to wipe their memory?)
2082020-02-10T22:03:06  <gmaxwell> :P
2092020-02-10T22:03:07  <kanzure> i need one where you still have coercion resistance after you lose some privacy
2102020-02-10T22:03:35  <kanzure> well actually i did have a bacterial truth serum proposal....... but this actually helps attackers, not defenders.
2112020-02-10T22:05:13  <gmaxwell> The challenge with coersion is that if you're already assuming attackers who will kidnap-- you're better off yielding, and precommiting to not yeald just carries a lot of risk of martyring yourself over some mere money.
2122020-02-10T22:06:10  <gmaxwell> particularly because it's fundimentally impossible to prove that beating you harder won't get you to disclose something valuable, if not the keys for some specific outputs the keys for some other unencoumbered outputs.
2132020-02-10T22:06:18  <kanzure> i think some people would rather not fund evil/kidnappers in this world.
2142020-02-10T22:07:20  <kanzure> so the assumption is that it's impossible to find a system that kidnappers will believe and that actually works.
2152020-02-10T22:07:28  <kanzure> potential-kidnappers and kidnappers
2162020-02-10T22:07:49  <gmaxwell> yes, you could imaigne someone who might precommit thsemlves to die for a cause.  This is the justification for using assanges rubberhose file system for political dissadents, where the leak of their data could result in the deats of dozens to (arguably) millions of people.   It's harder to make the case that anyone should choose to die just to make kidnapping people for money less
2172020-02-10T22:07:49  <gmaxwell> profitable.
2182020-02-10T22:08:08  <gmaxwell> I mean, I'd personally rather _you_ not die that way.
2192020-02-10T22:08:32  <gmaxwell> one should also consider that a lot of kidnappers are not the brightest builbs.
2202020-02-10T22:09:07  <gmaxwell> There are cases of educated metntally stable highly socipathic kidnappers, but there are a lot of cases of drugged out idiots.
2212020-02-10T22:09:30  <kanzure> dumb kidnappers works in favor of a positive belief of an impenetrable cold storage system
2222020-02-10T22:09:55  <gmaxwell> The former might be dissuaded by protective coloration... the latter not so much.  Both are probably better defended against by traditional security trappings...  locked fences, lights, cameras, guard dogs, security, etc.
2232020-02-10T22:10:33  <gmaxwell> kanzure: dumb kidnappers assume you are them.  It's like the TSA getting angry and suspicious at you when they ask you to turn your laptop on and its running linux and acts weird.
2242020-02-10T22:11:56  <gmaxwell> I think privacy is a pretty good defence against dumbkidnappers, you say privacy is fragile but thats mostly true of an absolute sense of privacy.
2252020-02-10T22:12:37  <gmaxwell> dumb kidnappers are defened against by not having a webpage with your name and bitcoin holdings or not driving around a lambo with the tag "HODL".
2262020-02-10T22:12:53  <kanzure> is there a stronger case that "coercion resistant custody will never be believable" besides assuming it?
2272020-02-10T22:13:54  <gmaxwell> Perhaps I'm over arguing, I agree that you can make improvements, only that they're bounded.
2282020-02-10T22:14:10  <gmaxwell> There was a time in the US where gunpoint kidnapping of bank managers in the middle of the night was a widespread problem.
2292020-02-10T22:14:34  <gmaxwell> And this problem was addressed by making safe vaults that couldn't be opened outside of business hours without being drilled.
2302020-02-10T22:14:51  <kanzure> yeah but a plasma torch is what $10 bucks?
2312020-02-10T22:15:18  <gmaxwell> didn't matter. If you're willing to go the plama torch route you don't need to kidnap the bank manager and all the trouble that entails.
2322020-02-10T22:15:30  <kanzure> a timelock vault takes the bank manager out of the vault, he can't help you and you have to cut the consensus-enforced timelock (which you can't)
2332020-02-10T22:15:33  <gmaxwell> providing ways to steal your funds that don't involve kidnapping is valuable.
2342020-02-10T22:16:16  <gmaxwell> (also plasma cutters are much cheaper and more effective than the best tools that were available at the time this was an issue)
2352020-02-10T22:16:37  <gmaxwell> (now it's more addressed through remotely monitored security systems)
2362020-02-10T22:16:38  <kanzure> i'll add "let them steal funds" to the list of gmaxwell-endorsed methods  of cold storage :)
2372020-02-10T22:17:08  <gmaxwell> I think it's good advice.  Don't put yourself on the path of least resistance to steal funds.
2382020-02-10T22:17:23  <gmaxwell> your life is worth more to you than your funds.
2392020-02-10T22:17:31  <harding> +1
2402020-02-10T22:18:35  <kanzure> a consensus-enforced timelock vault takes the bank manager out of the equation (e.g. kidnapping wont help), and asymmetrically adds friction to your adversary's mission
2412020-02-10T22:18:46  <gmaxwell> it might be interesting to dig up old court cases about the bank manager kidnappings, I'm gonna bet the kidnappers were morons.
2422020-02-10T22:18:53  <sipa> also make sure that attackers know you're not on the path of least resistance before they've kidnapped you
2432020-02-10T22:19:03  <kanzure> i would like to not assume that my adversaries are idiots....
2442020-02-10T22:19:11  <gmaxwell> kanzure: you're over specifying, consensus enforced is not relevant (except it just helps guarentee that the funds will eventually be recoverable)
2452020-02-10T22:20:03  <gmaxwell> kanzure: why?  you should want to assume your attackers are what they are.  Idiocy can be strength: You're effectively arguing for a form of idiocy here, making yourself unable to spend your coins is making yourself 'willfully incapacitated'.
2462020-02-10T22:20:21  <gmaxwell> "I am going to keep beating you until you do what I want" is a very powerful precommitment.
2472020-02-10T22:20:44  <gmaxwell> and all the more convincing if it's origin is that you're too stupid to do otherwise.
2482020-02-10T22:21:06  <kanzure> it's possible to defend against 2-3 dumb guys... but i'm thinking about $1 million dollar BTC market price and how it's economical to get a team of 30 people.
2492020-02-10T22:21:39  <gmaxwell> fortuantely those people will generally prefer to rob coinbase.
2502020-02-10T22:22:12  <kanzure> they probably prefer easier targets, and there will be a lot of them at that price
2512020-02-10T22:23:02  <gmaxwell> I don't think so, what purpose would some random indivigual have in holding even hundreds of million dollars worth of bitcoin.  If they're at all sane they would have diversivied their assets long before that point.
2522020-02-10T22:23:22  <gmaxwell> But coinbase would be holding tens of billions, splits much better 30 ways.
2532020-02-10T22:23:44  <gmaxwell> Also their offices probably have fewer nutballs like you that would rather die than give up access.
2542020-02-10T22:23:52  <gmaxwell> :P (I mean that in a loving way, I promise)
2552020-02-10T22:24:19  <gmaxwell> it's also MUCH easier to scope out a corp target.
2562020-02-10T22:24:24  <gmaxwell> You get someone to get a job there.
2572020-02-10T22:24:50  <gmaxwell> it's not just a movie trope, real large scale bank robberies almost always have some kind of insider information.
2582020-02-10T22:25:39  <kanzure> so re: storing with the multisig of bitcoin developers, the new limit is now $100 million dollars instead of "all the coins" (from before)
2592020-02-10T22:25:46  <sipa> gmaxwell: if BTC goes to $1000000, i suspect that among new billionaires there will be a larger than expected amount of nutballs who hold everything in BTC :p
2602020-02-10T22:26:02  <kanzure> you have created many diehard bitcoin believers that will be holding for quite a while in that scenario yes
2612020-02-10T22:26:07  <kanzure> "you" being us really
2622020-02-10T22:27:57  <kanzure> i'm just wondering if we can employ technical measures instead of ending up with "you need to get rid of your bitcoin because this stuff is off-the-charts radioactive"
2632020-02-10T22:28:59  <gmaxwell> sipa: maybe. Larger than expected doesn't mean all that many.
2642020-02-10T22:29:30  <sipa> gmaxwell: weighted by wealth, perhaps a significant fraction :)
2652020-02-10T22:31:14  <gmaxwell> I'm doubtful, but really don't have a basis to argue it.
2662020-02-10T22:31:20  <gmaxwell> I'd certantly encourage people otherwise.
2672020-02-10T22:35:54  <gmaxwell> kanzure: I think this is all a case where the quest for some kind of 'perfection' can just hurt you a lot in practice.
2682020-02-10T22:36:53  <kanzure> we just need something good enough to overcome the available means of criminals and also something that convincingly works for security too
2692020-02-10T22:38:50  <gmaxwell> Storage that has you+third_party_ratelimiter-destination-limiter OR  you+cold_key_kept_in_safe_deposit_box  OR  you+timelock (in case the earlier fail to be available in the futre); is I think much better than simply timelocking things and hoping for the best... but all are much weaker than privacy + traditional security mechenisms.
2702020-02-10T22:40:14  <kanzure> well, i think you can add some privacy to that specific script proposal.
2712020-02-10T22:40:46  <kanzure> so for the ratelimiter i was using covenants but i guess your proposal is just some third party and hope the adversary can't compromise their security?
2722020-02-10T22:41:19  <kanzure> i mean why are we putting this on lawrence again doesn't he have kids
2732020-02-10T22:41:33  <gmaxwell> or multiple third parties. Third parties are nice because you can impose much more sophicated policies than the network, including conditional on bitcoin prices.
2742020-02-10T22:42:16  <kanzure> but if the network could implement those Very Good Policies then that would be great because the network is overall less coercible than lawrence at multisig co
2752020-02-10T22:42:25  <gmaxwell> I mean, are you now assuming this attacker is kidnapping people in both italy and austin at the same time? and that this is still somehow still easier that going after coinbase?
2762020-02-10T22:42:48  <kanzure> yes? a team of 30 and a reasonable budget can easily operate in two places at once....
2772020-02-10T22:43:34  <gmaxwell> yes, but there are a dozen exchanges that make for much better targets... 100x the coins, and full of people who aren't deeply personally invested in preventing the theft,  easy access for scoping out their security in depth.
2782020-02-10T22:44:28  <kanzure> maintaining a set of high-valued easy targets is a fee that bitcoin network is paying to thiefs... better to just pay a transaction fee for consensus-enforceable security instead.
2792020-02-10T22:45:06  <gmaxwell> except the consensus enforced security has extreme limitations in it's strength regardless.
2802020-02-10T22:45:22  <gmaxwell> Your team of 30 can just keep you and your loveones under gun for months, if thats what it took.
2812020-02-10T22:45:27  <kanzure> well, it does seem to have a floor established by PoW and mining/market price
2822020-02-10T22:45:49  <gmaxwell> and no amoutn of network anything can exceede that level of security.
2832020-02-10T22:46:47  <gmaxwell> and if you try to exceede it, you'll just make yourself wose of by hurting privacy or increasing the risk of loss through non theft reasons, or the risk of injury when the OceansBTC team decides that more wrench is needed.
2842020-02-10T22:46:59  <gmaxwell> worse*
2852020-02-10T22:48:35  <kanzure> i want a consensus-enforced ratelimiter and i think that would be enough to solve the problem right? that's a technical means of minimizing coercibility. (if it was some opcode then it might be more believable to adversaries? i haven't proposed this though.)
2862020-02-10T22:49:56  <gmaxwell> I don't see how that accomplishes much. It does nothing against the OceansBTC people just taking you on vacation at gunpoint.
2872020-02-10T22:50:29  <kanzure> well in my email from august i mentioned watchtowers need to move coins once the timelocks expire (they are monotonically increasing timelocks) and there's more than one UTXO available to the key.
2882020-02-10T22:50:32  <gmaxwell> ratelimiers mostly make sense when you have some cold way to bypass, and the rate limiter just reduces your need to frequently access the cold keys.
2892020-02-10T22:53:32  <kanzure> i was using it for minimizing total amount stolen (only way to know a private key is stolen is to observe a theft transaction and you don't want them to steal 100%)
2902020-02-10T22:54:33  <gmaxwell> so you're assuming your team of 30 phd supervillans fail the marshmello test?
2912020-02-10T22:54:54  <kanzure> no, that i never store my coins in a way that doesn't ratelimit me
2922020-02-10T22:55:14  <gmaxwell> So I kidnap you and just keep you locked up until all your rate limits play out.
2932020-02-10T22:55:36  <kanzure> trapwires and deadman switches on watchtowers can assist with that particular problem
2942020-02-10T22:56:00  <kanzure> er, tripwires rather.
2952020-02-10T22:56:17  <gmaxwell> I will cut off your other arm (first arm was already removed as a warning) if any other tripwire/deadmanswitch whatever goes off.
2962020-02-10T22:57:13  <kanzure> so the kidnappers won't believe a proof that you give them. why don't people feel this way about banks? why don't people do this to bank managers? there's some reason- it's not just the FBI's punishment; it's that they don't get anything so they don't try.
2972020-02-10T22:57:42  <gmaxwell> uh/ banks get robbed all the time, and most of the time the robbers are successful
2982020-02-10T22:57:53  <gmaxwell> they don't kidnap managers in the middle of the night anymore.
2992020-02-10T22:58:18  <gmaxwell> they walk in and take money in the middle of the day bloodlessly, or rarely execute huge heists that involve no bank personell at all.
3002020-02-10T22:59:19  <kanzure> all their transactions are reversible. they let the crazies get away with some. and sometimes you have weird geopolitical reasons you can't get back a $40 million wire transfer.
3012020-02-10T22:59:20  <gmaxwell> in the US if you walk into a bank and hand them a note that says "give me all your money or else" they will calmly give you everything from their cash drawers and not raise a fuss at all.
3022020-02-10T22:59:39  <gmaxwell> And a _majority_ of such thefts are successful.  The theifs that do it eventually get caught because it was so easy they keep doing it.
3032020-02-10T22:59:58  <gmaxwell> and evenutally they manage to do it with a police officer standing inside the lobby or right outside the door
3042020-02-10T22:59:59  <sipa> according to a random quora answer there are 4200 bank robberies per year in the US; 60% of the robbers get caught the same day
3052020-02-10T23:00:05  <kanzure> e.g. 1MDB only got $40m back and they lost like $800m.
3062020-02-10T23:00:19  <gmaxwell> okay, my figures are old/spongy. :P 40% get away.
3072020-02-10T23:00:56  <gmaxwell> point is the thefts are easy and the sucess rate isn't terrible.
3082020-02-10T23:01:42  <kanzure> a few thousand bucks is within acceptable fraud limit and easily covered by bank profit. i don't think that's interesting. when people are walking around with $200m in their pocket (or back home) i think this is structurally different from petty bank theft.
3092020-02-10T23:02:18  <sipa> i hope nobody ever walks around with that amount of cash in their pocket
3102020-02-10T23:02:41  <kanzure> and gmaxwell was saying "don't even have that much bitcoin" in the first place :)
3112020-02-10T23:02:47  <kanzure> which is a much stronger version of that.
3122020-02-10T23:03:12  <sipa> even if you insist on self-custody and keeping a large amount in BTC, you can afford better physical security
3132020-02-10T23:03:35  <gmaxwell> https://www.fbi.gov/file-repository/bank-crime-statistics-2018.pdf/view
3142020-02-10T23:04:26  <gmaxwell> Full time security guards are not terribly expensive even in high cost of living areas, at least if you're talking about hundreds of millions of dollars.
3152020-02-10T23:04:41  <kanzure> i think instead of petty bank theft more interesting to ask why arms aren't getting cutoff for the likes of big bank ceo and person-who-can-enact-ridiculously-large-wire-transfers like 1MDB style.
3162020-02-10T23:05:20  <gmaxwell> bank manager kidnapping things were an issue at one point in time in the US.
3172020-02-10T23:06:02  <gmaxwell> My understanding is that once timelocks made the bank manager no longer super useful at night, they stopped... better to either go in by yourself at night to attempt to cut things open,   or go in the bank during the daytime when it's already unlocked.
3182020-02-10T23:06:12  <kanzure> i don't think K&R solves it for bitcoin because traditional K&R depends on law enforcement and reversibility to recover proceeds in long-term
3192020-02-10T23:06:58  <sipa> cash theft is irreversible, no? or do the serial numbers get marked as non-legal tender?
3202020-02-10T23:07:33  <gmaxwell> sipa: no because they're not tracked generally.
3212020-02-10T23:07:46  <gmaxwell> it would make it unsafe to accept cash if serial numbers were getting blacklisted.
3222020-02-10T23:07:57  <gmaxwell> sometimes serial numbers are used to investigate, but not to blacklist.
3232020-02-10T23:08:02  <sipa> right
3242020-02-10T23:08:12  <sipa> that was my assumption
3252020-02-10T23:08:56  <gmaxwell> I don't think they play a big role in bank robbery arrests, they are sometimes used w/ kidnappings though I don't recall hearing a case where they were successful.
3262020-02-10T23:09:05  <kanzure> with a consensus enforced timelock, there's not just no bank manager to cut the arms off of, there's also no vault to plasma torch in the middle of the night (but i think we're now repeating each other)
3272020-02-10T23:09:06  <harding> kanzure: maybe better to ask why people don't rob gold vaults, and I think the answer is the physical security.
3282020-02-10T23:09:29  <harding> (Large gold vaults; I'm sure home safes get robbed all the time.)
3292020-02-10T23:09:30  <kanzure> harding: also cost... hard to move gold etc... but maybe i'm overestimating the friction of theft from mass.
3302020-02-10T23:09:48  <gmaxwell> kanzure: again you're overspecifying the consensus enforced isn't relevant to the security against theft (it's relevant to the security against the funds getting suck).
3312020-02-10T23:10:34  <gmaxwell> (or at least isn't very relevant to the security against theft)
3322020-02-10T23:10:58  <gmaxwell> If you're going to assume that OceansBTC team are going to do some heroic heist, then they can also wait out the timelock.
3332020-02-10T23:11:41  <kanzure> they have to wait while you are in their custody, and this triggers watchtowers or tripwires that move coins to some escape hatch (because you weren't otherwise managing your deadman switches that they didn't know about)
3342020-02-10T23:11:42  <gmaxwell> which seems a lot less likely to get them caught than kiddapping multiple people in multiple countries. (and even assuming the non-consensus behavior isn't HSM implemented and robust against kidnapping)
3352020-02-10T23:12:16  <gmaxwell> wrenches uncover deadman switches... :(
3362020-02-10T23:12:24  <harding> kanzure: what tripwire can trigger faster than you can be tortured into submission without having a high false positive rate?
3372020-02-10T23:12:31  <gmaxwell> and if your target is wrench resistant then you don't need the timelock.
3382020-02-10T23:12:53  <kanzure> harding: i think with a sufficiently strong argument that the kidnappers won't succeed, they won't even bother with torture because they would not be convinced to attack
3392020-02-10T23:13:52  <gmaxwell> Which is why physical security is good.
3402020-02-10T23:14:41  <gmaxwell> esp as it's a lot more understanable than smartcontract hokem which is often a lie. ("MTGOX coins are in HSMs"  "bitfinex keeps x% of balances in cold wallets", etc)
3412020-02-10T23:14:45  <harding> kanzure: maybe, but how do you credibly prove you have a tripwire that will activate within the hours (or maybe only minutes) it takes to torture you into submission?  A tripwire that's resistant to false positives related to loss of Internet connectivity or electricity (which are problems that still happen pretty frequently even in the most developed parts of the world, in my experience).
3422020-02-10T23:15:13  <gmaxwell> and what does the tripwire do? if it's FP rate isn't zero, you don't want it burning the coins.
3432020-02-10T23:15:26  <kanzure> i am willing to burn coins before i'm willing to fund an adversary
3442020-02-10T23:15:37  <gmaxwell> if it's just assining the coins to someone else you run into your "but what if they kidnap {other guy}?!"
3452020-02-10T23:15:44  <kanzure> and while burning coins deflates the available supply and indirectly rewards the attacker (by price appreciation), it's better than directly funding evildoers
3462020-02-10T23:16:25  <gmaxwell> meh, I have to worry about the inventives around encouraging security systems where ordinary users will have a non-trivial chance of burning their coins by accident.
3472020-02-10T23:16:28  <kanzure> (also: coin burning is a great way to steal coins and enrich yourself and use all bitcoin UTXOs as the anonymity set, but you lose like practically all the value- except a little)
3482020-02-10T23:16:54  <gmaxwell> (e.g. I feel like the wallet encryption in bitcoin core has turned out to be ethically problematic)
3492020-02-10T23:17:50  <kanzure> (as described here https://twitter.com/kanzure/status/1165664781346463745 )
3502020-02-10T23:18:00  <gmaxwell> (because I believe in the time since deployment I've seen evidence that it creates many times more losses from key loss than it prevents from theft; partially because it's only weakly effective at preventing theft)
3512020-02-10T23:19:02  <harding> gmaxwell: but if it's effectively preventing theft, wouldn't you expect to see more losses from other causes than from theft?
3522020-02-10T23:20:16  <gmaxwell> people report when it prevented theft, but I've seen incredibly few reports of that (though not zero).
3532020-02-10T23:20:44  <gmaxwell> You more or less always know when it prevented theft, because if you don't know you were compromised you'll eventually unlock the wallet and they'll steal your coins then.
3542020-02-10T23:21:08  <gmaxwell> so the only case where it protect theft is where you're compromised and uncover it before unlocking and before they crack the key.
3552020-02-10T23:21:46  <harding> Eh, I'm not sure.  How would I know whether or not it prevent theft of the encrypted wallet.dat in a safe deposit box?
3562020-02-10T23:22:02  <gmaxwell> And I've seen a LOT of reports of keys lost from it, there are at least two people that have full time businesses runnning password cracking attempts for people who lost their keys.
3572020-02-10T23:23:07  <gmaxwell> harding: by the first person anywhere ever reporting their their _non_encrypted wallet was solen from a safe deposit box.  Until that happens I think it's safe to disregard that as something its protecting.  (I agree that it would protect there if it was a current threat,  but also would gpg or truecrypt-encrypting the file... )
3582020-02-10T23:23:41  <gmaxwell> and also I've seen a lot of evidence that people underreport losing their keys because they're ashamed of their mistake.
3592020-02-10T23:23:53  <gmaxwell> while people agressively report theft.
3602020-02-10T23:24:44  <gmaxwell> the biggest arugment for it is that without it users make a nussance of themselves blaming the software when there is theft.
3612020-02-10T23:24:52  <gmaxwell> (in my view)
3622020-02-10T23:25:08  <gmaxwell> while, for some reason, they don't blame the software when they've forgotten the passphrase.
3632020-02-10T23:26:32  <harding> That's a fair point, but what percentage of people put unencrypted wallet.dats in a safe deposit box?  It's it's small, you might have to wait for a long time to get any evidence that way.  I suspect that by the time people get to putting backups in a safe deposit box, most of them have probably already enabled some sort of encryption.
3642020-02-10T23:26:35  <kanzure> nless you're peter schiff.
3652020-02-10T23:26:35  <gmaxwell> I also think it's useful to prevent mistaken spends. e.g. you think you're using a testnet wallet but you're using your bitcoin wallet.
3662020-02-10T23:27:33  <gmaxwell> harding: well instead people are putting paper wallet things generated by sometimes backdoored JS webpages... :P
3672020-02-10T23:27:44  <harding> That's fair.
3682020-02-10T23:28:27  <gmaxwell> I just think in general that it's at best unclear that it's a tradeoff that protects users interest, and at the time time anyone who owns bitcoin gains is less sophicated users lose access to their coins.
3692020-02-10T23:28:31  <gmaxwell> so it has bad incentives.
3702020-02-10T23:28:47  <gmaxwell> the system could be constructed differently to make different tradeofss.
3712020-02-10T23:29:14  <kanzure> harding: ideally we have a solution where our default recommendation isn't "torture" it's "it's obviously impenetrable for any cost of attack under $x and attacking the bank manager won't help"
3722020-02-10T23:30:10  <gmaxwell> For example, there is a known issue that people encrypt their wallet when they install the software but have no bitcoins... then a year later they move a bunch of coins out of an exchange, get an address from their wallet, then realize they long since forgot a totally unused key that they stuck on a worthless wallet.
3732020-02-10T23:30:58  <gmaxwell> kanzure: I don't see how that is economically possible. Technical means cannot prevent kidnapping and torture from being effective, at least if the kidapper is willing to go to extremes like keeping someone a prisoner and torturing them.
3742020-02-10T23:31:50  <kanzure> economic factors can change the incentives
3752020-02-10T23:32:03  <gmaxwell> And I think only a highly unusual person is going to prefer to have the coins burned and expose them to the risk of death rather than give them over, and as a result it isn't a very plausable threat.
3762020-02-10T23:32:42  <kanzure> we shouldn't be held hostage by hypothetical indisciriminately violent attackers (by definition they are irrationally violent and you can't placate them to prevent your death)
3772020-02-10T23:33:28  <gmaxwell> and to the extent that an effort at protective coloration to convince people you're unrobbable just identifies you as an interesting target, thats probably not really good.
3782020-02-10T23:36:13  *** willcl_ark has quit IRC
3792020-02-10T23:38:28  *** willcl_ark has joined ##taproot-bip-review
3802020-02-10T23:51:38  *** gnusha has joined ##taproot-bip-review
3812020-02-10T23:55:32  *** lukedashjr has joined ##taproot-bip-review
3822020-02-10T23:58:09  *** luke-jr has quit IRC