| 00:59:16 | poggy: | has anyone looked at the multi sig implementations being used on darknets? |
| 01:02:35 | poggy: | http://pastebin.com/raw.php?i=1GFj9hPB is the source of the electrum plugin on TMP if anyone is interested |
| 01:02:59 | sipa: | 'darknets' ? |
| 01:03:06 | poggy: | well tor |
| 01:03:09 | poggy: | and i2p |
| 01:03:49 | poggy: | sorry if this is off topic |
| 01:04:11 | poggy: | I just thought it counted as a slightly novel use of bitcoin |
| 01:07:41 | justanotheruser: | justanotheruser is now known as just[dead] |
| 01:08:12 | sipa: | i don't see the relevance of it in that question |
| 01:08:39 | poggy: | in which question? |
| 01:08:40 | gmaxwell: | sipa: the reason he's asking is that apparently some of these tor drug market things are using multisig for their escrow stuff. |
| 01:09:03 | gmaxwell: | I'm doubtful that the implementation is competent, but I really haven't heard anything about it... am not really all that eager to go looking. :) |
| 01:09:22 | gmaxwell: | (though I support people using multisig for escrow!) |
| 01:09:51 | shesek: | from what I've seen, seems like one market did a decent job with an electrum plugin |
| 01:10:07 | shesek: | and one that asks you to send them your private key when you want to release funds |
| 01:10:29 | shesek: | there was some guide with screenshot on "clearnet" somewhere |
| 01:10:54 | gmaxwell: | yea, an electrum plugin would be a good way to go. |
| 01:24:11 | poggy: | are there any other websites using multi sig escrow at the moment? |
| 01:30:55 | shesek: | poggy, there's bitrated.com, that provides a web interface for that |
| 01:31:09 | shesek: | (I created it) |
| 02:12:07 | kinlo_: | kinlo_ is now known as kinlo |
| 02:21:40 | otoburb_: | otoburb_ is now known as Guest67195 |
| 02:25:50 | ageis: | ageis is now known as Guest77102 |
| 03:26:18 | therealnanotube: | therealnanotube is now known as nanotube |
| 03:40:39 | just[dead]: | just[dead] is now known as justanotheruser |
| 03:45:00 | Guest77102: | Guest77102 is now known as ageis |
| 04:29:54 | orvilleWRT: | orvilleWRT has left #bitcoin-wizards |
| 06:13:26 | justanotheruser: | justanotheruser is now known as just[dead] |
| 07:56:06 | Emcy: | Emcy is now known as Guest5445 |
| 07:57:10 | weex: | weex is now known as Guest42545 |
| 07:57:13 | otoburb: | otoburb is now known as Guest93156 |
| 07:57:13 | maaku: | maaku is now known as Guest61397 |
| 10:12:21 | Anduck_: | Anduck_ is now known as Anduck |
| 11:07:41 | Mike_B: | gmaxwell, i had a question about your merkle tree proof-of-reserves scheme (figured i'd better ask here than in the gox chan) |
| 11:07:48 | gmaxwell: | sure |
| 11:07:58 | Mike_B: | so say you (for some reason) are operating a system in which users can lend bitcoin to one another, so that they can have negative balances |
| 11:08:12 | Mike_B: | so some users have positive balances, some have negative balances, but it all is supposed to sum up to some total amount of reserves |
| 11:08:28 | Mike_B: | is there some clever way to alter the merkle tree scheme so that it still can handle negative balances? |
| 11:09:06 | Mike_B: | and, i guess, somehow prevent the exchange operator from adding a ton of spurious negative balances to make it seem like there are less reserves needed than there actually are |
| 11:10:37 | gmaxwell: | I still think in that case what you'd do is split users into two balances "asset balance" and "obligation balance" ... asset balance reflect their share of the assets the service should hold, people who are in debt would just be 0. |
| 11:11:56 | Mike_B: | ah, so you'd have two merkle trees basically? |
| 11:12:10 | Mike_B: | man that's clever |
| 11:12:27 | gmaxwell: | I think that works, I'd probably have to better understand the service to be completely sure of it. |
| 11:13:09 | gmaxwell: | a lot of this stuff is just the same ideas .. repeated at different scales and angles. Once your toolbelt is big enough they're not that surprising. :) |
| 11:13:19 | Mike_B: | eh, I just pulled the service out of thin air, it's kind of a contrived example... it was just the math i was trying to understand |
| 11:13:43 | Mike_B: | heh, starting to appreciate that more and more as i keep diving in... |
| 11:13:53 | gmaxwell: | e.g. I think I extracted a half dozen applications for "make a transaction that also requires a hash preimage to spend" |
| 11:14:34 | Mike_B: | i was reading a paper on PoW and someone suggested it as a "web metering" tool, which i thought was interesting |
| 11:14:40 | Mike_B: | never thought of that before |
| 11:16:48 | Mike_B: | gmaxwell: my application is a bit silly, i was actually thinking initially of something like a reddit upvote/downvote site - i was wondering how you might prove somehow that you as a site operator haven't added spurious votes |
| 11:17:02 | Mike_B: | but then i thought that it'd basically be the same thing as a bitcoin exchange where negative balances are allowed (for some weird reason) |
| 11:18:34 | Mike_B: | and balances are always +/-1 |
| 11:19:13 | gmaxwell: | yea, actually similar to constructing proofs that mining pools aren't stuffing their sharechains. |
| 11:20:02 | Mike_B: | ah wow, i never thought of that |
| 11:21:00 | Mike_B: | gmaxwell: how would they stuff it without just having extra mining power needed to mine the easy blocks? |
| 11:21:34 | gmaxwell: | pool stuffing is where a pool claims it is getting more shares than it is.. then it seems unlucky. |
| 11:21:47 | gmaxwell: | and the operator is getting paid but not working |
| 11:22:55 | gmaxwell: | for the votes ... one way to do it would be to encrypt the users names (with a key that depends on the item id). .. you place the votes in a binary search hashtree. You use the root of the tree to pick some users at random and prove their membership and decryption but not what they voted. so that shows that it's not being stuffed with users that don't exist. then for each user you show them the path to where they should be in the ... |
| 11:23:01 | gmaxwell: | ... tree (search tree), and they're there and their vote is right and they can see it's counted, or they're correctly not there. |
| 11:24:16 | gmaxwell: | probably too expensive for some silly upvote downvote thing, bandwidth wise (And complexity). |
| 11:29:28 | Mike_B: | gmaxwell: sorry a bit confused... so for each item, you're saying to create a tree of only the users who voted on it. each node consists of their encrypted name, their vote, and some kind of combined hash of all those values for the two parent notes - right? |
| 11:29:51 | Mike_B: | and yeah, the upvote/downvote thing is a contrived example, i'm just trying to understand the general reasoning behind this idea and how it applies in various situations to develop more of a mental "toolbox" like you were saying |
| 11:29:58 | gmaxwell: | right and the tree is ordered, so that if you're in it, you know exactly where you'll be. |
| 11:30:23 | gmaxwell: | (ordered and the parent nodes have the boundaries in them.) |
| 11:31:21 | Mike_B: | ah, like ordered in terms of user id, or hashed user id, or something like that? |
| 11:31:38 | Mike_B: | just any linear order at all that can be made public? |
| 11:37:18 | gmaxwell: | sure hashed userid, just so the user can compute it himself and see if he's there where he should/shouldn't be. |
| 11:37:41 | gmaxwell: | there are basically two things you need to test here. One is that the particular user is counted/not counted as the case may be. |
| 11:37:52 | gmaxwell: | the other is that the count isn't stuffed with extra users that ought not exist. |
| 11:38:54 | gmaxwell: | you can accomplish some evidence of the second just by revealing some random fraction of the users in the set, selected by the hash of the set (this is the fiat-shamir transform of a cut and choose protocol). (without revealing their votes). |
| 11:41:54 | Mike_B: | fiat-shamir transform looks cool, i need to get a better grip on actual zkp math |
| 11:42:06 | Mike_B: | would that stop a site operator from creating like 1,000,000 dummy user accounts and making them "exist" in the system? |
| 11:42:12 | Mike_B: | you know, like a mini-dragnet or whatever |
| 11:42:44 | Mike_B: | fake people who appear real with plausible-sounding fake names like "Max Gregwell" and etc, but just don't have any social security numbers anywhere =P |
| 11:42:57 | gmaxwell: | well right I was assuming you'd have some way to spot fake users. |
| 11:43:12 | gmaxwell: | like some verifyable way that creating a user cost something, or a post history, or ... something. |
| 11:43:20 | gmaxwell: | web of trust |
| 11:43:23 | Mike_B: | haha |
| 11:43:54 | Mike_B: | alright, very interesting. thanks for that |
| 11:44:13 | Mike_B: | i have no plans to create a cryptographic reddit, but when i first saw that merkle tree scheme my head exploded |
| 11:44:34 | Mike_B: | that came totally out of left field for me like some kind of crazy moon math i never thought of |
| 11:44:43 | Mike_B: | so i'm trying to see how far you could push it, but it seems like... pretty far |
| 11:50:10 | gmaxwell: | * gmaxwell misses witcoin |
| 13:10:43 | MoALTz: | would it be extreme (memory usage, bandwidth) for an altcoin to move to a merkle signature scheme? |
| 13:13:49 | sipa: | unless quantum crypto, i doubt the overhead of that could be justified |
| 15:45:42 | HM: | HM is now known as HM2 |
| 15:53:38 | otoburb_: | otoburb_ is now known as Guest14765 |
| 15:55:18 | otoburb: | otoburb is now known as Guest8824 |
| 16:07:28 | otoburb__: | otoburb__ is now known as 16WAA079O |
| 16:37:41 | otoburb__: | otoburb__ is now known as otoburb |
| 16:52:41 | Guest61397: | adam3us: so I think you can use 2-way pegging to to achieve Chiemgauer-like issuance for perishable assets like freicoin |
| 16:53:03 | Guest61397: | Guest61397 is now known as maaku |
| 16:54:49 | maaku: | the conversion btc->frc is 1:1, then the return is 1.00btc:0.95btc |
| 16:54:58 | maaku: | *1.00frc |
| 16:56:47 | maaku: | you just need to add a "discount" message during the queting period which identifies a timestamp of the bitcoin block containing the return peg in order to establish current value |
| 16:57:58 | phantomcircuit: | gmaxwell, has someone written a tool to take a list of (account_id, balance) pairs and turn it into a merkle tree? |
| 16:59:03 | maaku: | this lets anyone inflate frc at the cost of btc, and to exchange back up to the amount of bitcoins that were put in, without ruinous effects |
| 16:59:21 | maaku: | it'll always be fractional, however, as the initial issuance is not pegged |
| 17:11:59 | just[dead]: | just[dead] is now known as justanotheruser |
| 17:33:52 | Luke-Jr: | [11:45:15] do you know if multisig supports 1 out of 2, where one of the parties can decide to do the transaction on his own, but the other party needs permission from both? |
| 17:33:55 | Luke-Jr: | lolwut |
| 17:35:21 | otoburb: | Luke-Jr: not sure that's possible unless the 2nd party shares his private key with the 1st that has "veto" power |
| 17:37:52 | gmaxwell: | otoburb: it's not a question of possible, it's perfectly possible, but it's kinda pointless. |
| 17:38:32 | gmaxwell: | if party 1 can transact unilatterally and party 2 can only transact with party 1's consent then this is almost indistinguishable from party 1 just holding a single private key. |
| 17:38:49 | gmaxwell: | you could just implement exactly what he asked for, but I can't see a reason to. |
| 17:39:26 | gmaxwell: | I answered him in the affirimative that you could do that however, ... and in returned he's planning on running some grand business to handle other people's money. Of course. |
| 17:39:37 | otoburb: | hehe |
| 17:43:32 | Luke-Jr: | gmaxwell: I heard some pretty insane "ideas" at the conference… |
| 17:43:55 | Luke-Jr: | makes me think Titan Bitcoin is keeping a copy of the private keys on their "physical bitcoins" |
| 17:47:16 | justanotheruser: | justanotheruser is now known as just[dead] |
| 18:10:08 | maaku: | Luke-Jr: depends on the industry. Unity 3D uses Mono for basically all programmable game logic, and they're grabbing tons of market share |
| 18:10:16 | maaku: | in the video game industry |
| 18:11:22 | maaku: | if i were making a new protocol with client-executable code (which I would be if I weren't distracted by bitcoin), I would use .NET/Mono over Java or Javascript |
| 18:11:37 | andytoshi: | Luke-Jr: i got a few good ones too. i liked the guy who insisted that doge was 'just gonna keep happening regardless of technical problems'. i told him that it actually stops happening whenever they push a hardforking change in a point release and their consensus is destroyed... he paused for a moment then said 'that's the free market man!' |
| 18:13:17 | otoburb: | because ... freemarket! |
| 18:34:22 | jhj: | jhj is now known as trn |
| 20:17:39 | azariah4: | How hard do you think it'll be to implement ECDSA like TRESOR (no, not trezor)? https://www.usenix.org/legacy/event/sec11/tech/full_papers/Muller.pdf |
| 20:32:30 | azariah4: | love this paper |
| 20:32:50 | azariah4: | "The challenge we faced was implementing the AES algorithm without using main memory." |
| 20:35:55 | nsh: | * nsh suggests it would be the same amount of hard |
| 20:37:47 | gmaxwell: | AES has some properties that enable very small implementations. |
| 20:38:29 | andytoshi: | ecdsa requires 64 bytes of registers for the privkey and nonce, then you have to do the EC math beside that |
| 20:46:26 | maaku: | andytoshi: that's easy enough to find in sse registers... |
| 20:47:31 | azariah4: | it seems the only data persistent over multiple signatures would be the privkey, and the TRESOR approach with AES works with up to 256 bit keys |
| 20:47:58 | azariah4: | they use the four x86 debug registers |
| 20:48:32 | azariah4: | during the actual signing I suppose other registers could freely be used as long as they are cleared before enabling pre-emption again |
| 20:48:43 | andytoshi: | X(g^k) is another 32 bytes, so i'd guess 96 is enough |
| 20:49:29 | andytoshi: | maaku: i'm not familiar with sse, never did any serious x86 assembler |
| 20:49:52 | andytoshi: | i was a 'stay in 16-bit mode, use BIOS interrupts' kinda guy :P |
| 20:59:15 | maaku: | andytoshi: original SSE had 8 128-bit registers, they may have even extended that |
| 21:00:31 | andytoshi: | oh, nice, in that case it wouldn't be super hard, just tedious |
| 21:00:44 | gmaxwell: | dunno where you're going to put the code... |
| 21:01:50 | azariah4: | there is also 16 256-bit AVE registers since sandy bridge |
| 21:02:35 | midnightmagic: | I wonder how much page-fault computing would leak to those mechanisms |
| 21:09:41 | azariah4: | TRESOR requires a kernel patch to ptrace to avoid other userspace programs from altering the debug registers where the key is stored |
| 21:09:58 | azariah4: | however they are working under their own requirement to never have any key data in RAM |
| 21:10:27 | azariah4: | if you are fine with key data in RAM, but want to avoid L3 cache monitoring timing attacks mentioned by Mike Hearn in his recent thread on the mailing list |
| 21:10:53 | azariah4: | then I guess you could only load the key into the registers during the atomic step of the signing code, and then wipe the registers |
| 21:11:12 | azariah4: | benefit would be that it could be done as a kernel module, I think, and not require a kernel patch |
| 21:12:35 | azariah4: | (probably much easier to get bitcoin companies to use a loadable kernel module than a kernel patch) |
| 21:16:16 | gmaxwell: | azariah4: if you can load a kernel module on the actual host then you're already not on a shared system and the issue is mostly moot. |
| 21:19:09 | roconnor: | midnightmagic: doesn't everyone use triple page faults to compute their signatures to avoid NSA spying? :P |
| 21:20:24 | nsh: | page fault computing? |
| 21:20:53 | roconnor: | x86's page fault handling turns out to be turning complete. |
| 21:21:37 | roconnor: | *turing |
| 21:21:45 | gmaxwell: | hi roconnor |
| 21:21:51 | roconnor: | *Turing |
| 21:21:52 | roconnor: | hi |
| 21:25:25 | nsh: | oh, right |
| 21:50:15 | azariah4: | gmaxwell: yeah good point, looked it up, access to debug registers will trigger VMExit (hypervisor traps instruction guest executed) |
| 21:51:32 | nsh_: | nsh_ is now known as nsh |
| 21:58:56 | azariah4: | however, it could still work, depending on how the hypervisor emulates registers |
| 22:14:53 | midnightmagic: | roconnor: :) i think it's a wonderful little piece of research, for sure. https://www.usenix.org/conference/woot13/workshop-program/presentation/bangert |
| 22:20:13 | nsh: | i wonder if anyone's employed it to defeat malware analysis yet |
| 22:44:23 | [-krypto-]: | Hey guys |
| 22:45:24 | [-krypto-]: | can anyone suggest a channel where I can find devs that might want to help work on a new coin |
| 22:45:36 | super3: | not here |
| 22:49:04 | antephialtic: | try #altcoinscams |
| 22:49:37 | [-krypto-]: | that sounds like a scam but I will bite |
| 22:49:46 | [-krypto-]: | antephialtic: thanks |
| 23:29:18 | roconnor: | nsh: IIRC you need kernel support to implement the universal computation. |
| 23:29:51 | nsh: | mm |
| 23:30:06 | roconnor: | granted it isn't impossible for malware to infect the kernel. |
| 23:30:41 | nsh: | i meant more in the sense of frustrating VM analysis and automated deobfuscation |
| 23:31:26 | nsh: | universality is neat, but you only need small degree of weirdness in practice |
| 23:32:00 | gmaxwell: | roconnor: it's what you do when there is a kernel exploit they lets you only write movl instructions to arbritary locations. :P |
| 23:32:02 | roconnor: | indeed. They said that no VM they are aware of implementes the triple fault. |