| 00:13:23 | bramc: | Has anybody considered making the spending formula of utxos be specified by its hash? That would make them smaller and help with anonymity, especially for more complex transactions |
| 00:18:32 | gmaxwell: | You mean putting the hash of the scriptpubkey in the transaction as what you're paying to instead of the script itself? |
| 00:19:17 | gmaxwell: | If so... Bitcoin already does this, and has for years. It's called P2SH. It's not required, though its used pretty much universally for multisig. |
| 00:39:22 | bramc: | gmaxwell, Yes, that's exactly what I mean, thanks. |
| 00:40:20 | gmaxwell: | nice that you indenpendantly came up with it. |
| 00:40:52 | bramc: | It's unfortunate that it isn't also used for non-multisig, because something being multisig is the main thing which makes things stand out |
| 00:42:26 | bramc: | It also would be nice if they could be in a tree, so if there were multiple ways a utxo could be spent only one of them would have to be revealed |
| 00:44:29 | gmaxwell: | Yes, we call that a merkelized abstract syntax tree; originally proposed by Pieter Wuille and Russel O'connor. Thats not implemented currently, but it's been discussed for a few years. |
| 00:45:04 | gmaxwell: | (it's mentioned on that alt ideas page you've been linked to a few times :) there are other ideas there you'd likely like) |
| 00:45:50 | bramc: | I haven't worked my way through that page yet. It's on my list. |
| 00:50:09 | bramc: | I've now gotten through coinswap. I don't think it's possible to get rid of the multisig from that one, unless there's a protocol for doing combo signatures in some way which look like regular signatures but need two counterparties to complete |
| 00:52:21 | gmaxwell: | Two of two threshold signatures with schnorr are utterly trivial, you add the signatures togeather (and the pubkeys). There is an interactive scheme for 2 of 2 ecdsa as well, though it's complicated and I dunno if anyone has bothered implementing it. |
| 00:52:21 | shesek: | bramc, IIRC 2-of-2 should be possible without OP_CHECKMULTISIG and with some plain cryptography |
| 00:53:54 | bramc: | Yes, that intuitively makes sense. The relevant targets are ecdsa and ed25519 |
| 00:55:00 | gmaxwell: | well, careful with ed25519 when transposting crypto stuff from the bitcoin space. We use a cofactor 1 curve, ed25519 has multiple subgroups. Some of the things we discuss have security considerations if applied to a curve with multiple subgroups. |
| 00:55:39 | gmaxwell: | (and we're not always diligent about pointing out when a single subgroup assumption applies) |
| 00:55:42 | bramc: | How? |
| 00:55:52 | bramc: | I mean, as long as you're just using it for signatures... |
| 00:56:30 | gmaxwell: | e.g. someone naievely applying BIP32 to ed25519 is going to get it wrong. |
| 00:58:12 | gmaxwell: | because they keys must be a multiple of 8 ... (or not even possible, as I believe there are ed25519 implementations which require the most significant bit of the private key to be set, which cannot be assured with BIP32) |
| 00:58:55 | bramc: | I *think* ed25519 allows any value of the private key to be valid, by design |
| 01:00:00 | bramc: | But yeah, anything involving cleaving open of the signature scheme and mucking with its internals could be bad, but as long as the signature scheme is used as a black box it should be fine |
| 01:00:17 | gmaxwell: | Well sort of. The normal interface takes the key and hashes it, multiplies it by 8 and sets the MSB. But thats obviously not compatible with BIP32. If you go and implement BIP32 for ed25519 you'll need to deal with it at a slightly lower level and you run into these things. |
| 01:00:45 | gmaxwell: | But thats not 'internal' to the signature system, it's internal to the pubkey generation. In any case, as I said take care. |
| 01:01:52 | bramc: | I really do need to work through bip32 and figure out what it's really all about |
| 01:03:13 | gmaxwell: | The part thats interesting and not totally obvious is: You can give me an 'extended pubkey', and I can generate more pubkeys for you (an unlimited set), e.g. for making reoccuring payments or for tracking a shared 'watching wallet' without any further communication between us. |
| 01:03:17 | bramc: | But now I'm curious if there are more complicated than 2-of-2 schemes for sharing private keys, and if maybe it might even be possible to hack hash preimages in there somehow |
| 01:04:06 | bramc: | oh, yes, that is an interesting question, although there's the expedient hack of just sending a long list of pubkeys |
| 01:04:43 | gmaxwell: | bramc: N of M is trivial for schnorr too, if you don't mind some setup. For ECDSA it seems only possible with a trusted dealer. The point of hash preimages is to make them public, so it would be counterproductive to include them in an indistinguishable signature scheme. |
| 01:05:39 | gmaxwell: | So you can do things like put an extended pubkey on your webserver the vends keys, and if its hacked the hacker can only substitute keys for new sales. And yea, you could just give a list, but the list can run out, which is an administrative burden. In practice we saw people putting private keys on the server to address that. |
| 01:05:51 | gmaxwell: | (esp it's a pain if the private keys are off in a safe someplace) |
| 01:05:58 | bramc: | Oh right, it's important that the hash preimage have to be revealed as part of the scheme. It might be possible to hack around that though, so you and I both generate keys such that we can verify that if you reveal the full key of thing B then I can know the key to thing A |
| 01:05:59 | bramc: | sort of |
| 01:07:16 | gmaxwell: | The developers of bytecoin foolishly though there was no reason to support hash preimages because, e.g. G*x is a hash, if I pay to pubkey Gx and you spend it, you're demonstrating knoweldge of x. ... but that missed the point. |
| 01:07:46 | bramc: | Yeah the protocol needs to be a bit more complicated than that |
| 01:08:12 | gmaxwell: | there are some things that can be done, e.g. if you force the nonce in the signature you can make the signature leak the private key, though thats often not so useful. |
| 01:09:27 | bramc: | What we want is a protocol where I can tell that if you finish signing thing Y it will automatically give me enough info to sign thing X, and I can verify this in advance |
| 01:09:59 | gmaxwell: | e.g. force you to sign with r=Gk where I know k... then I can recover the private key. But what you'd want is worse, like 3 of 3 where I only learn _one_ of the private keys, and thats much harder since a regular schnorr/dsa signature doesn't have enough degrees of freedom. |
| 01:10:54 | bramc: | All the public key stuff is totally not swapped into my head right now, I'll have to think about this more |
| 01:11:48 | gmaxwell: | I suspect its only possible with additional constraints that would make it distinguishable. Which defeats the point. But I haven't given that a ton of thought. |
| 01:12:10 | bramc: | Our ability to do stuff in advance may be helpful. Like, we coordinate the generation of two public keys, and coordinate the possible signing of one of them, so that if you complete a particular signature I know it will help me finish a particular other signature |
| 01:12:27 | gmaxwell: | At least 2 of 2 multisig is not uncommon in bitcoin already, so swaps do have some anonymity set. |
| 01:12:28 | bramc: | What do you mean by 'distinguishable'? |
| 01:12:45 | gmaxwell: | bramc: Well your goal was to make these transactions look exactly like an ordinary one, right? |
| 01:12:52 | bramc: | Right, yes |
| 01:14:25 | gmaxwell: | I can give you an exact scheme that lets us createt two two of twos, such that if you complete one I can complete the other. ... but it requires making the script pubkey force you to use a particular r value (one where I know its discrete log) in your signature. If I see that txn, I recover your private key, then I can complete the other txn. And it can be bidirectional, e.g. if mine gets finis |
| 01:14:31 | gmaxwell: | hed first, you can get my private key and complete the other txn. |
| 01:14:34 | gmaxwell: | but it's distinguishable because it adds that constraint on r. |
| 01:15:20 | bramc: | Come to think of it, for lots of things what you want is an ordinary keys distribution scheme doing n-of-m straightforwardly, because it's just key backup |
| 01:18:01 | gmaxwell: | Not sure I follow there. As an aside, n of m does not generalize plausable multifactor policies. E.g. A && B || B && C cannot be constructed as N of M. |
| 01:19:26 | bramc: | I mean, if you want to have a distributed backup for your private key you can just do a distributed backup for your private key instead of using a multisig |
| 01:20:17 | gmaxwell: | oh, no. the concern for multisig is not backup. The primary motivation is multiple devices because common computers and smartphones are security disasters, and crackers who compromise your system will _reliably_ steal your bitcoins. |
| 01:20:20 | shesek: | bramc, that forces you to reconstruct it on a single machine at some point |
| 01:20:38 | shesek: | which might be problematic for some situations |
| 01:21:18 | bramc: | Right, that makes sense |
| 01:21:27 | shesek: | right. with multisig you could have multiple separate machines that would have to be compromised to gain access to funds |
| 01:21:39 | shesek: | with something like ssss, you end up with a single point of failure |
| 01:21:57 | gmaxwell: | or even compromised by conspiring attackers... which is nice, all can be compromised so long as the attackers don't cooperate you're good to go. :P |
| 01:22:14 | bramc: | You mean, you're forcing the creation of a single point of failure in order to get access to the funds |
| 01:23:07 | gmaxwell: | right, if you've just split up the key you must join the split parts to spend. If that part is compromised, you're toast. If you have an uncompromisable spot to sign, well why not just keep the key there to begin with? :) |
| 01:23:25 | gmaxwell: | By all means, if you're implementing a competing cryptocurrency, feel free to not support multisig. |
| 01:23:28 | gmaxwell: | :P |
| 01:23:55 | gmaxwell: | No doubt it would make the code simpler. |
| 01:24:25 | bramc: | My issue with multisig isn't the functionality, it's the traceability. If it's possible to do the same thing with 'offline' tools, I'd rather do that. |
| 01:24:45 | bramc: | And of course, implementing those tools is a net loss in terms of code complexity |
| 01:25:36 | gmaxwell: | Well there appears to be no efficient alternative that doesn't require at least an interactive setup; which is contraindicated for some but not all applications. |
| 01:26:44 | bramc: | Yes, the simple asynchrony of multisig protocols is convenient. Perhaps that's doable as well though. |
| 01:29:11 | gmaxwell: | For example, shesek runs a webside that introduces people to arbritrartors to be potential cosigners on 2-of-3 transactions that let people reduce counterparty risk. Having to have an interactive protocol with the arb before you transact would be a bit of a drag; esp since usually a transaction can be resolved without ever contacting them. We (myself or Pieter? I forget) came up with a multisig |
| 01:29:17 | gmaxwell: | nature scheme that had some overhead (basically a log2(n) number of additional hashes where n is the number of different ways you could satisify the signature, and you could dummy pad it to even out the anonymity set) but could skip the interactive setup. |
| 01:29:20 | bramc: | Is coinjoin just putting a whole bunch of coins into a single big one and then pulling them back out again? |
| 01:30:49 | gmaxwell: | bramc: Not quite. It's writing a single transaction that spends multiple coins, owned by multiple people, and which creates multiple coins. Third parties (or even the participants, depending on how its done) don't learn the mapping between the input and output ownership. |
| 01:31:19 | gmaxwell: | (maybe you could see it as making a big coin and breaking it up, but its a single transaction, which makes it all atomic) |
| 01:32:11 | bramc: | Okay, that's fairly trivial to implement at least in terms of the crypto involved |
| 01:38:14 | bramc: | From an untraceability standpoint if the p2sh script is kept in a merkle tree it should be a maximally imbalanced tree to avoid leaking its overall length |
| 01:40:19 | gmaxwell: | well a lot of overhead there... e.g. to represent a 4 of 7 you have 7 choose 4 leafs... a balaced tree is reasonable in size, an unbalanced one is pretty awful. |
| 01:42:06 | bramc: | That depends on whether what's revealed is always a truncation after the beginning |
| 01:42:26 | bramc: | If it's always that, then the most overhead for the reveal is a single hash for the next bit |
| 01:48:46 | bramc: | Some protocols depend on the length of the preimage as well, that would also be very hard to make a key sharing equivalent of |
| 02:01:57 | bramc: | It seems most things can be supported via multisig, with possible combinations of signatures, plus hash preimages where there are ranges of possible lengths on the preimages |
| 04:08:41 | OneFixt_: | OneFixt_ is now known as OneFixt |
| 04:30:23 | cbeams_: | cbeams_ is now known as cbeams |
| 04:33:43 | BlueMatt: | BlueMatt has left #bitcoin-wizards |
| 04:34:37 | tlrobinson_: | tlrobinson_ is now known as tlrobinson |
| 04:54:50 | jcluck: | jcluck is now known as cluckj |
| 05:55:08 | op_mul: | bramc: the complex part of coinjoin isn't the cryptography side, but discovery and pairing. there's the problem that if you coinjoin with a group of sybil joiners you gain nothing. |
| 05:55:45 | bramc: | op_mul, Yes, that's where the problems come in |
| 05:55:56 | op_mul: | and denial of service. peers can refuse to sign and hang your round. |
| 05:56:51 | gmaxwell: | the hang thing can be addressed, it's just client complexity. |
| 05:57:23 | op_mul: | traditionally people have set up privacy services which usually all fall to the same flaw. they have an automated system which takes coins from one address and squirts out unrelated ones at a different address, minus a percentage fee. |
| 05:57:35 | fluffypony: | ShadowCash released their whitepaper and the first commit which apparently introduces ring sigs + NIZK - http://shadow.cash/downloads/shadowcash-anon.pdf |
| 05:59:12 | op_mul: | fluffypony: and for those that don't think opening PDFs is a good idea. https://webcache.googleusercontent.com/search?hl=en&q=cache%3Ahttp%3A%2F%2Fshadow.cash%2Fdownloads%2Fshadowcash-anon.pdf |
| 06:00:57 | bramc: | Coinswap is overall a much more appealing protocol |
| 06:01:21 | fluffypony: | lol bramc |
| 06:01:23 | roidster: | roidster is now known as Guest97609 |
| 06:01:32 | fluffypony: | very funny |
| 06:02:01 | bramc: | Notably you can do a coinswap between two different currencies as well, requiring only two counterparties |
| 06:02:08 | bramc: | fluffypony, is that sarcasm? |
| 06:03:35 | fluffypony: | oh you were being serious? |
| 06:03:42 | fluffypony: | I thought you were joking |
| 06:03:50 | bramc: | Why would I be joking? |
| 06:05:16 | fluffypony: | because if you're referring to shadowcash, then just about anything is more appealing than something that hasn't even been reviewed yet (and is incomplete) |
| 06:05:42 | fluffypony: | if you're referring to transactional privacy in general, then that statement is clearly ridiculous |
| 06:06:18 | bramc: | I'm comparing coinswap vs. coinjoin |
| 06:06:27 | fluffypony: | oh in that respect I would agree |
| 06:06:50 | gmaxwell: | bramc: the swap just has a fair amount of additional cost. |
| 06:06:58 | gmaxwell: | because it requires two transactions. |
| 06:07:27 | op_mul: | fluffypony: in my mind all of these altcoins have the trouble in that they only need to work so far as the pump goes. I don't know anything about this one particularly, but that seems to be the case every single time. |
| 06:07:33 | gmaxwell: | fluffypony: he's not talking about $godknowswhatcrazyassaltcoin, he's talking about my protocol posts. |
| 06:07:35 | bramc: | gmaxwell, depends what you mean by 'cost', the amount of network overhead is utterly trivial, although it does gunk up the block chain a bit |
| 06:08:16 | gmaxwell: | well, whatever your units, it's basically 2x the transaction data. |
| 06:08:24 | fluffypony: | op_mul: oh I know, I just linked to it because it's the first altcoin whitepaper in a while to actually have algebra in it :-P |
| 06:09:11 | op_mul: | fluffypony: it exploded in googles HTML render I think, unless there's meant to be flying lambda |
| 06:09:55 | op_mul: | fluffypony: wait 440ms to verify a single signature!? |
| 06:11:32 | op_mul: | that's pretty insane. if I was a miner of that there's no way in hell I'd be putting transactions in my blocks. |
| 06:12:08 | fluffypony: | here |
| 06:12:09 | fluffypony: | http://pdfnomo.re/1c6cARR/ |
| 06:14:20 | op_mul: | better, but it still says it takes 440ms to verify. |
| 06:15:38 | fluffypony: | yup |
| 09:05:17 | orwell.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:17 | orwell.freenode.net: | Users on #bitcoin-wizards: andy-logbot Baz__ pavel_ grau nagromlt RoboTeddy nuke1989 nessence NewLiberty op_mul woah cluckj midnightmagic Muis Luke-Jr tlrobinson BlueMatt TheSeven coiner ryanxcharles joris nullbyte gues Transisto Dr-G2 ebfull tacotime DougieBot5000 Adlai shesek zooko maraoz EasyAt grishnakh__ starsoccer bramc Guest12706 gavinandresen tromp__ postpre hashtag OneFixt danneu catcow TD-Linux ryan-c roasbeef amiller smooth optimator_ mmozeiko Alanius Emcy |
| 09:05:17 | orwell.freenode.net: | Users on #bitcoin-wizards: epscy Graftec prodatalab koshii Aquent go1111111 waxwing Guest22019 pi07r kobud GnarSith copumpkin dgenr8 bosma bbrittain bitbumper mortale JonTitor Shiftos null_radix PRab Hunger- MRL-Relay devrandom fluffypony jgarzik mr_burdell mkarrer samson_ DoctorBTC HaltingState btc__ NikolaiToryzin CryptOprah mappum grandmaster [\\\] Iriez c0rw1n_ kanzure warren Krellan LaptopZZ nanotube Graet fenn otoburb LarsLarsen coutts bobke jchp nsh_ SubCreative |
| 09:05:17 | orwell.freenode.net: | Users on #bitcoin-wizards: asoltys_ sl01_ arowser K1773R nickler_ a5m0 PaulCapestany @ChanServ Meeh phantomcircuit SDCDev wumpus dansmith_btc comboy btcdrak spinza ahmed_ lnovy espes__ tdlfbx heath eordano luny jbenet nsh gribble gwillen Nightwolf gazab Anduck Dyaheon cfields digitalmagus8 stonecoldpat gmaxwell pigeons isis andytoshi lechuga_ artifexd hguux_ michagogo kumavis warptangent Fistful_of_Coins HM2 paperbot maaku Cory Guest38445 coryfields iddo kinlo azariah |
| 09:05:17 | orwell.freenode.net: | Users on #bitcoin-wizards: yoleaux Logicwax berndj lclc_bnc s1w Eliel_ sneak harrigan sipa AdrianG livegnik BananaLotus burcin wizkid057 tromp_ poggy Taek Apocalyptic throughnothing petertodd crescendo so [d__d] BigBitz jaromil helo Keefe phedny BrainOverfl0w harrow |
| 09:24:54 | lclc_bnc: | lclc_bnc is now known as lclc |
| 09:38:17 | rusty: | rusty has left #bitcoin-wizards |
| 11:35:39 | lclc: | lclc is now known as lclc_bnc |
| 11:57:52 | GAit: | i did some updated stats on p2sh transactions and I thought people over here may be interested, http://i.imgur.com/DZx8o87.png |
| 12:26:05 | nullbyte_: | nullbyte_ is now known as Guest38991 |
| 12:31:17 | bbrittain_: | bbrittain_ is now known as bbrittain |
| 12:41:15 | omni: | omni is now known as Guest22767 |
| 13:14:20 | fanquake: | fanquake has left #bitcoin-wizards |
| 13:18:38 | wallet421: | wallet421 is now known as wallet42 |
| 14:30:20 | tlrobinson_: | tlrobinson_ is now known as tlrobinson |
| 15:29:00 | zooko`: | zooko` is now known as zooko |
| 15:45:54 | Anduck: | Anduck is now known as `Anduck |
| 15:46:06 | `Anduck: | `Anduck is now known as Anduck |
| 16:07:00 | lclc_bnc: | lclc_bnc is now known as lclc |
| 19:43:23 | helo: | helo is now known as he1o |
| 19:43:30 | he1o: | he1o is now known as helo |
| 19:55:32 | kanzure: | swhack found https://gist.github.com/anonymous/105cd61893f8d3bfc324 |
| 19:55:45 | kanzure: | for some reason people are confused and think bittorrent is a storage protocol instead of a transmission protocol |
| 19:57:36 | zooko: | kanzure: :-( |
| 19:57:47 | zooko: | Oh, hey, that's by kragen. |
| 19:57:52 | zooko: | We've been talking about that on #tahoe-lafs. |
| 19:57:54 | kanzure: | yes, which is why i'm doubly upset |
| 19:58:04 | kanzure: | i also don't know why he refuses to show up in here (i've prodded him) |
| 19:58:26 | kanzure: | (i just have high expectations of him i guess) |
| 20:17:23 | EasyAt_: | EasyAt_ is now known as EasyAt |
| 20:22:31 | lclc: | lclc is now known as lclc_bnc |
| 20:24:40 | lclc_bnc: | lclc_bnc is now known as lclc |
| 20:34:05 | lclc: | lclc is now known as lclc_bnc |
| 21:14:26 | Adlai`: | Adlai` is now known as adlai |
| 23:18:14 | nsh: | .title http://continuations.com/post/105272022635/bitcoin-clarifying-the-foundational-innovation-of |
| 23:18:14 | yoleaux: | Continuations : Bitcoin: Clarifying the Foundational Innovation of... |
| 23:21:57 | nsh: | there should be a special term for people who categorize and think they've explicated |
| 23:22:07 | nsh: | and it should be synonymous with dead |
| 23:26:02 | kanzure: | "In contrast to most recent work in peer-to-peer software, our design is based on mathematical proofs of security rather than hand-waving." |
| 23:26:05 | kanzure: | http://szabo.best.vwh.net/securetitle.html |
| 23:32:08 | gmaxwell: | andytoshi: you may find this thread interesting: https://bitcointalk.org/index.php?topic=893898.0 "A covert-channel-free black-box signer without ZNPs" |
| 23:32:44 | gmaxwell: | Sergio gives a 4 move protocol that prevents an evil hardware wallet from exfultrating secrets compatible with the existing network, and requiring nothing fancy. |
| 23:32:56 | gmaxwell: | Annoyingly it's four moves, which sucks for a wallet in a safe. |
| 23:34:02 | gmaxwell: | I give a two move protocol that makes the sidechannel size have exponential cost... which I think might be worth doing only if you absolutely wouldn't do the 4 move version... since elsewhere I've shown that a single bit channel is more than enough to leak whatever given enough signatures. |
| 23:35:38 | gmaxwell: | Can anyone link me to the state of the art in probablistic payments that work in the current network? I have a scheme I think is new which is very nice. |
| 23:35:46 | gmaxwell: | (but maybe I just reinvented something) |