00:59:16poggy:has anyone looked at the multi sig implementations being used on darknets?
01:02:35poggy:http://pastebin.com/raw.php?i=1GFj9hPB is the source of the electrum plugin on TMP if anyone is interested
01:02:59sipa:'darknets' ?
01:03:06poggy:well tor
01:03:09poggy:and i2p
01:03:49poggy:sorry if this is off topic
01:04:11poggy:I just thought it counted as a slightly novel use of bitcoin
01:07:41justanotheruser:justanotheruser is now known as just[dead]
01:08:12sipa:i don't see the relevance of it in that question
01:08:39poggy:in which question?
01:08:40gmaxwell: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:03gmaxwell: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:22gmaxwell:(though I support people using multisig for escrow!)
01:09:51shesek:from what I've seen, seems like one market did a decent job with an electrum plugin
01:10:07shesek:and one that asks you to send them your private key when you want to release funds
01:10:29shesek:there was some guide with screenshot on "clearnet" somewhere
01:10:54gmaxwell:yea, an electrum plugin would be a good way to go.
01:24:11poggy:are there any other websites using multi sig escrow at the moment?
01:30:55shesek:poggy, there's bitrated.com, that provides a web interface for that
01:31:09shesek:(I created it)
02:12:07kinlo_:kinlo_ is now known as kinlo
02:21:40otoburb_:otoburb_ is now known as Guest67195
02:25:50ageis:ageis is now known as Guest77102
03:26:18therealnanotube:therealnanotube is now known as nanotube
03:40:39just[dead]:just[dead] is now known as justanotheruser
03:45:00Guest77102:Guest77102 is now known as ageis
04:29:54orvilleWRT:orvilleWRT has left #bitcoin-wizards
06:13:26justanotheruser:justanotheruser is now known as just[dead]
07:56:06Emcy:Emcy is now known as Guest5445
07:57:10weex:weex is now known as Guest42545
07:57:13otoburb:otoburb is now known as Guest93156
07:57:13maaku:maaku is now known as Guest61397
10:12:21Anduck_:Anduck_ is now known as Anduck
11:07:41Mike_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:58Mike_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:12Mike_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:28Mike_B:is there some clever way to alter the merkle tree scheme so that it still can handle negative balances?
11:09:06Mike_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:37gmaxwell: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:56Mike_B:ah, so you'd have two merkle trees basically?
11:12:10Mike_B:man that's clever
11:12:27gmaxwell:I think that works, I'd probably have to better understand the service to be completely sure of it.
11:13:09gmaxwell: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:19Mike_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:43Mike_B:heh, starting to appreciate that more and more as i keep diving in...
11:13:53gmaxwell:e.g. I think I extracted a half dozen applications for "make a transaction that also requires a hash preimage to spend"
11:14:34Mike_B:i was reading a paper on PoW and someone suggested it as a "web metering" tool, which i thought was interesting
11:14:40Mike_B:never thought of that before
11:16:48Mike_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:02Mike_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:34Mike_B:and balances are always +/-1
11:19:13gmaxwell:yea, actually similar to constructing proofs that mining pools aren't stuffing their sharechains.
11:20:02Mike_B:ah wow, i never thought of that
11:21:00Mike_B:gmaxwell: how would they stuff it without just having extra mining power needed to mine the easy blocks?
11:21:34gmaxwell:pool stuffing is where a pool claims it is getting more shares than it is.. then it seems unlucky.
11:21:47gmaxwell:and the operator is getting paid but not working
11:22:55gmaxwell: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:01gmaxwell:... 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:16gmaxwell:probably too expensive for some silly upvote downvote thing, bandwidth wise (And complexity).
11:29:28Mike_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:51Mike_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:58gmaxwell:right and the tree is ordered, so that if you're in it, you know exactly where you'll be.
11:30:23gmaxwell:(ordered and the parent nodes have the boundaries in them.)
11:31:21Mike_B:ah, like ordered in terms of user id, or hashed user id, or something like that?
11:31:38Mike_B:just any linear order at all that can be made public?
11:37:18gmaxwell: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:41gmaxwell: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:52gmaxwell:the other is that the count isn't stuffed with extra users that ought not exist.
11:38:54gmaxwell: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:54Mike_B:fiat-shamir transform looks cool, i need to get a better grip on actual zkp math
11:42:06Mike_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:12Mike_B:you know, like a mini-dragnet or whatever
11:42:44Mike_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:57gmaxwell:well right I was assuming you'd have some way to spot fake users.
11:43:12gmaxwell:like some verifyable way that creating a user cost something, or a post history, or ... something.
11:43:20gmaxwell:web of trust
11:43:54Mike_B:alright, very interesting. thanks for that
11:44:13Mike_B:i have no plans to create a cryptographic reddit, but when i first saw that merkle tree scheme my head exploded
11:44:34Mike_B:that came totally out of left field for me like some kind of crazy moon math i never thought of
11:44:43Mike_B:so i'm trying to see how far you could push it, but it seems like... pretty far
11:50:10gmaxwell:* gmaxwell misses witcoin
13:10:43MoALTz:would it be extreme (memory usage, bandwidth) for an altcoin to move to a merkle signature scheme?
13:13:49sipa:unless quantum crypto, i doubt the overhead of that could be justified
15:45:42HM:HM is now known as HM2
15:53:38otoburb_:otoburb_ is now known as Guest14765
15:55:18otoburb:otoburb is now known as Guest8824
16:07:28otoburb__:otoburb__ is now known as 16WAA079O
16:37:41otoburb__:otoburb__ is now known as otoburb
16:52:41Guest61397:adam3us: so I think you can use 2-way pegging to to achieve Chiemgauer-like issuance for perishable assets like freicoin
16:53:03Guest61397:Guest61397 is now known as maaku
16:54:49maaku:the conversion btc->frc is 1:1, then the return is 1.00btc:0.95btc
16:56:47maaku: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:58phantomcircuit:gmaxwell, has someone written a tool to take a list of (account_id, balance) pairs and turn it into a merkle tree?
16:59:03maaku: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:21maaku:it'll always be fractional, however, as the initial issuance is not pegged
17:11:59just[dead]:just[dead] is now known as justanotheruser
17:33:52Luke-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:35:21otoburb:Luke-Jr: not sure that's possible unless the 2nd party shares his private key with the 1st that has "veto" power
17:37:52gmaxwell:otoburb: it's not a question of possible, it's perfectly possible, but it's kinda pointless.
17:38:32gmaxwell: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:49gmaxwell:you could just implement exactly what he asked for, but I can't see a reason to.
17:39:26gmaxwell: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:43:32Luke-Jr:gmaxwell: I heard some pretty insane "ideas" at the conferenceā€¦
17:43:55Luke-Jr:makes me think Titan Bitcoin is keeping a copy of the private keys on their "physical bitcoins"
17:47:16justanotheruser:justanotheruser is now known as just[dead]
18:10:08maaku: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:16maaku:in the video game industry
18:11:22maaku: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:37andytoshi: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:17otoburb:because ... freemarket!
18:34:22jhj:jhj is now known as trn
20:17:39azariah4: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:30azariah4:love this paper
20:32:50azariah4:"The challenge we faced was implementing the AES algorithm without using main memory."
20:35:55nsh:* nsh suggests it would be the same amount of hard
20:37:47gmaxwell:AES has some properties that enable very small implementations.
20:38:29andytoshi:ecdsa requires 64 bytes of registers for the privkey and nonce, then you have to do the EC math beside that
20:46:26maaku:andytoshi: that's easy enough to find in sse registers...
20:47:31azariah4: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:58azariah4:they use the four x86 debug registers
20:48:32azariah4: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:43andytoshi:X(g^k) is another 32 bytes, so i'd guess 96 is enough
20:49:29andytoshi:maaku: i'm not familiar with sse, never did any serious x86 assembler
20:49:52andytoshi:i was a 'stay in 16-bit mode, use BIOS interrupts' kinda guy :P
20:59:15maaku:andytoshi: original SSE had 8 128-bit registers, they may have even extended that
21:00:31andytoshi:oh, nice, in that case it wouldn't be super hard, just tedious
21:00:44gmaxwell:dunno where you're going to put the code...
21:01:50azariah4:there is also 16 256-bit AVE registers since sandy bridge
21:02:35midnightmagic:I wonder how much page-fault computing would leak to those mechanisms
21:09:41azariah4:TRESOR requires a kernel patch to ptrace to avoid other userspace programs from altering the debug registers where the key is stored
21:09:58azariah4:however they are working under their own requirement to never have any key data in RAM
21:10:27azariah4: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:53azariah4: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:12azariah4:benefit would be that it could be done as a kernel module, I think, and not require a kernel patch
21:12:35azariah4:(probably much easier to get bitcoin companies to use a loadable kernel module than a kernel patch)
21:16:16gmaxwell: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:09roconnor:midnightmagic: doesn't everyone use triple page faults to compute their signatures to avoid NSA spying? :P
21:20:24nsh:page fault computing?
21:20:53roconnor:x86's page fault handling turns out to be turning complete.
21:21:45gmaxwell:hi roconnor
21:25:25nsh:oh, right
21:50:15azariah4:gmaxwell: yeah good point, looked it up, access to debug registers will trigger VMExit (hypervisor traps instruction guest executed)
21:51:32nsh_:nsh_ is now known as nsh
21:58:56azariah4:however, it could still work, depending on how the hypervisor emulates registers
22:14:53midnightmagic: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:13nsh: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:36super3:not here
22:49:04antephialtic:try #altcoinscams
22:49:37[-krypto-]:that sounds like a scam but I will bite
22:49:46[-krypto-]:antephialtic: thanks
23:29:18roconnor:nsh: IIRC you need kernel support to implement the universal computation.
23:30:06roconnor:granted it isn't impossible for malware to infect the kernel.
23:30:41nsh:i meant more in the sense of frustrating VM analysis and automated deobfuscation
23:31:26nsh:universality is neat, but you only need small degree of weirdness in practice
23:32:00gmaxwell: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:02roconnor:indeed. They said that no VM they are aware of implementes the triple fault.