--- Log opened Wed Dec 11 00:00:11 2013
--- Day changed Wed Dec 11 2013
00:00 < andytoshi> hmm, running signtransaction on my supposedly-signed transaction changes the signature
00:00 < andytoshi> which is a bad sign i think
00:01 < andytoshi> but otoh running decoderawtransaction, i can see that my code is doing exactly what i would have done, had i merged them by hand
00:02 < andytoshi> it seems like signrawtransaction's signatures depend in a noticeable way on what the other inputs are
00:04 < gmaxwell> andytoshi: first, the signatures have a nonce and every time you sign will be different.
00:04 < andytoshi> oh, that's right
00:04 < gmaxwell> secondly, a normal sighash all signature covers all the input ids and outputs (but not the signatures themselves)
00:05 < andytoshi> yes, i'm aware of that
00:05 < andytoshi> but it zeros out the scriptSigs
00:05 < gmaxwell> right.
00:05 < andytoshi> my feeling is, i should just post this on the cj thread, and if it's creating invalid transactions, that's a safe failure mode
00:06 < BlueMatt> anyone want a google glass invite to work on bitcoin on glass? (or in general, but itd be cool to pay with bitcoin on glass)
00:07 < BlueMatt> (because thats not insecure or anything)
00:07 < andytoshi> yeah, there'd be bullies putting QR codes on peoples' feet then saying "your shoes are untied!"
00:07 < andytoshi> you look down and bam, lunch money stolen
00:08 < BlueMatt> well, someone who has time should think about how to make it secure, but first they need glass :)
00:08 < gmaxwell> the glass interface seems really twitchy
00:08 < BlueMatt> how so?
00:08 < gmaxwell> but there are buttons so you can use those.
00:09 < gmaxwell> BlueMatt: just easy to trigger the wrong thing.
00:09 < BlueMatt> yea, it can be
00:14 < gmaxwell> andytoshi: I don't see any huge risk from it, it's not an automated signer, user-beware that they check the decode before signing what it gives them.
00:14 < BlueMatt> it also doesnt even support passcode locks, so you'd have to do that yourself if you wanted anything like bitcoin
00:14 < BlueMatt> still, someone should do it...I'll throw in an invite if someone wants to
00:16 < andytoshi> grr, i typed up a nice message and bitcointalk deleted it..
00:17 < BlueMatt> why would you type a nice message for bitcointalk anyway?
00:20 < andytoshi> if you guys trust me, i can make linux 64 binaries as well, if you wanna play with this..
00:22 < andytoshi> http://download.wpsoftware.net/bitcoin/coinjoin/
00:56 < BlueMatt> andytoshi: I havent been paying attention, how is the matching process on there?
00:57 < andytoshi> hmm?
00:57 < BlueMatt> some magic p2p network that matches people who want to join, or what?
00:59 < andytoshi> BlueMatt: oh, i didn't solve that problem
00:59 < andytoshi> kjj was talking about it
00:59 < andytoshi> my thing requires you get together and exchange rawtransactions, it just simplifies the merge steps..
01:00 < BlueMatt> ahh, I was hoping for something that could get merged into wallets
01:00 < BlueMatt> :(
01:00 < andytoshi> not yet
06:14 < michagogo|cloud> 06:35:30 <gmaxwell> andytoshi: there is no 'validatetransaction' rpc call, the best you can do is try it on testnet ... or an isolated node. (e.g. if the txn isn't relevant to your wallet, and you are -noconnect -nolisten ... it'll only ever be in memory on your node)
06:14 < michagogo|cloud> Wait, is -noconnect a thing?
06:14 < michagogo|cloud> I knew of -connect=0.0.0.0
06:16 < sipa> -noX is interpreted as -X=0
06:16 < michagogo|cloud> Oh, cool
06:16 < michagogo|cloud> (and can you -connect=0?)
07:03 < wumpus> I don't think -noconnect is a supported option
07:04 < michagogo|cloud> BlueMatt: around?
07:05 < michagogo|cloud> er, wrong channel
12:25 < nsh> http://www.sparecoins.io/ <--- good / bad / ugly / dunno?
12:26 < gmaxwell> nsh: save us from clicking with a one line summary.
12:26 < nsh> browser-extension wallet, storing keys inside browser
12:26 < nsh> --
12:26 < nsh> Every week, another online Bitcoin Wallet gets hacked. SpareCoins, however, does not have a central point for attackers to target. Your private keys are encrypted and stored inside your browser, rather than an unsafe remote server. Your private keys can be backed up at anytime, and clearing your cache won’t delete your keys.
12:26 < nsh> --
12:27 < nsh> depends on the code quality i guess..
12:27 < nsh> --
12:27 < wumpus> don't bitaddress etc work the same?
12:27 < nsh> Sam Stewart5 hours ago
12:27 < nsh> It sends bitcoins. It's easy. It works. What more do you need?
12:27 < nsh> -- review. (this is the attitude that worries me...)
12:27 < nsh> unsure
12:29 < sipa> I consider every argument of the form "It is secure because ... only inside your browser" to be invalid
12:29 < sipa> which e-wallet did that, hack their JS to steal some coins back?
12:30 < nsh> aye. though this model is without a server, but just as succeptible to untrusted updates
12:33 < wumpus> well the advantage to this is that you can just host the .html files locally
12:34 < wumpus> and maintain them in (for example) a git repository so that changes are trackable
12:35  * nsh nods
12:35 < wumpus> but I'm also a bit wary to trusting my browser with a wallet, I prefer native applications for that
12:37 < wumpus> browsers have a reputation of having all kinds of suble security bugs which suddenly become fatal if you store high-valued private keys in them
12:38 < nsh> wumpus, this echoes my sentiments
12:39 < nsh> also browsers are an established target for malware/spyware/adware already
12:39 < wumpus> then again, they do accomplish the goal of being more secure than online hosted wallets
12:39 < phantomcircuit> sipa, i actually prefer my implementation, his is using the stdio functions for apparently no reason
12:54 < sipa> phantomcircuit: there was discussion about it on the mailing list
12:54 < sipa> i can't remember why, though
12:54 < phantomcircuit> their google groups is impossible to read online
12:55 < phantomcircuit> every reply ends up with at least 100 citations at the bottom
13:09 < nsh> it works for science...
13:10 < nsh> (fsvo 'works')
13:11 < maaku> nsh: meh, sometimes I wish paper writers would boil it down to the 4-5 actually useful citations
13:11 < nsh> indeed, or at least be able to click through to the relevant findings in the referenced papers highlighted
13:13 < nsh> at lot of it is formality though. you have to prove you're not replicating anyone else's work by laboriously referencing trifflingly similar paper
13:13 < andytoshi> it is also considered polite, to improve others' citation rankings
13:13 < andytoshi> <.<
13:13  * nsh nods
13:24 < phantomcircuit> the ticket i opened asking apple to clarify msync MS_SYNC behavior has been tagged Rank:No Value
13:24 < phantomcircuit> so im just going to assume that msync w/ MS_SYNC does the stupidest thing possible
13:24 < phantomcircuit> which is to flush to the dirty page cache of the filesystem and not to disk
13:25 < phantomcircuit> meaning likely the mmap issues in leveldb could be corrected simply by swapping fdatasync->msync to msync -> fdatasync
13:44 < maaku> andytoshi: which is the problem, as a user of academic research: i'd rather useless citations weren't piled on to boost people's rankings
13:45 < gmaxwell> maaku: piled on to grease reviewers palms. :)
13:45 < maaku> heh, yeah
13:45 < gmaxwell> "You want me to cite what? ... ugh. fine."
13:47 < andytoshi> maaku: i concur, i think it's going to improve a bit as people tend to read preprints more, rather than published papers
13:47 < andytoshi> and gratuitous citations on preprints don't help anyone
13:47 < andytoshi> so as long as you just ignore all the actual journals... ;)
16:31 < andytoshi> everyone involved in my coinjoin, i'm going to publish it in about 90 minutes (3PM pacific), so if you want to bug me about it, just /msg
16:33 < jgarzik> andytoshi: this seems like #bitcoin-otc material?   bitcoin coin swap meets...
16:33 < andytoshi> hmm, good call
16:33 < andytoshi> it just happened this time that everyone involved (who would identify themselves to me) is a wizard
16:51 < Luke-Jr> andytoshi?
16:52 < Luke-Jr> publish what? :P
16:53 < andytoshi> Luke-Jr: a couple days ago a bunch of us got together on a coinjoin, and i'm just now getting to publishing the combined transaction
16:53 < andytoshi> there were some delays as i had to write tools to do the merger, and people were not always online
16:54 < amiller> oh my, coping with n parties some of which may or may not be online at any given time :3
16:54 < gmaxwell> jgarzik: yea, I'd suggested doing coinjoin tuesdays or whatever. But it sounds like andy might have something better.
16:56 < andytoshi> (i am working on a site which uses my coinjoin merger tool, and flips every N seconds between collecting unsigned transactions and collecting signed ones)
16:56 < Luke-Jr> andytoshi: ah, I thought you meant a paper or program :P
16:57 < andytoshi> nope, nothing so exciting
16:57 < andytoshi> though i do have a program at https://github.com/apoelstra/coinjoin which does the merging
18:24 < nsh> has anyone done an analysis to predict (in some model) when we might be likely to hit the 1mb blocksize limit due to transaction volume?
18:29 < andytoshi> so, the coinjoin transaction has been publish, and has drifted past my node at least
18:29 < andytoshi> which believes it is 100% fees
18:32 < andytoshi> ..well, it has all the relevant addresses and the correct 'send' and 'receive' amounts on each, it's just the total that's wring
18:33 < gmaxwell> andytoshi: actually it believes it has negative fees.
18:33 < gmaxwell> because it has money that came in from nowhere. :)
18:33 < andytoshi> oh :P it's the amount that's displayed as negative.
18:34 < gmaxwell> and yea, what it does for the fees displayed there is braindamaged.
18:34 < andytoshi> ok, and the output of listunspent 0 has all my money listed.. phew
18:34 < andytoshi> i understand how signatures work and it was still scary :)
18:34 < andytoshi> "somehow i lost everyone's money"
18:34 < gmaxwell> andytoshi: it's prudent to be a chicken, but you're still a chicken. :P
18:35 < andytoshi> this is so cool, that basically a bunch of strangers put $35000 into an envelope i held out, saying i'd mail it..
18:37 < gmaxwell> yea, because the envelope was magic and made it impossible (well, if their putting-in was well formed) for you to cheat. Someday all those fairy tales will sounds sensible.
18:39  * nsh smiles
18:39 < nsh> fools! it was a moebius envelope...
18:40 < nsh> andytoshi, is your coinjoin thing explained somewhere?
18:40 < andytoshi> well, the bitcointalk thread is at https://bitcointalk.org/index.php?topic=279249.0
18:41 < andytoshi> idk if anyone 'invented' the idea, i figured it out just from the name..
18:42 < andytoshi> to use my tool, the README on https://github.com/apoelstra/coinjoin should be sufficient
18:42 < nsh> ty
18:43 < gmaxwell> Petertodd invented the name at my request. The idea of making private transactions this way has basically been known forever. E.g. I recall some old post of hal's describing a higher level protocol for anonymous loans based basically on coinjoins.
18:43  * nsh nods
18:44 < gmaxwell> I was getting a bit frustrated with people fixating on "zerocoin" as a magical unicorn that was just around the corner(tm) to solve all privacy problems. ... and I decided that part of the problem with people fixating was that the alternatives didn't have _names_.
18:44 < gmaxwell> which sounds kinda weird but I think its true.
18:44 < gmaxwell> so then armed with a name I wrote up a description and a call to action.
18:44 < nsh> excellent
18:44 < andytoshi> i think it's true, back in 2011 when you had that coinjoining thread with no name, it looked very scary and technical
18:45 < andytoshi> and at the time i didn't look into it at all
18:45 < andytoshi> otoh, this time around i knew how transactions were structured, so maybe i didn't need the name..
18:47 < nsh> names act as conceptual anchors and nucleation points
18:47 < nsh> they can be very effecticious :)
18:48 < andytoshi> yeah, before it was "type some weird commands to get hex codes you are supposed to give to gmaxwell via PM, who totally can't get money out of them, and he'll give you some more hex codes to incant over"
18:48 < nsh> (or efficacious, which is apparently less made-up of a word)
18:48 < andytoshi> and then somehow people smarter than you would no longer be able to watch you so closely :)
18:49 < nsh> i think things where you could illustrate them with a silly simpsons aside cartoon sketch
18:49 < nsh> i picture a load of robed and hooded stone-cutter mason-types all gathering together solemnly in a circle and exchanging things from closed fists while blindfolded
18:50 < nsh> :)
18:50 < gmaxwell> What I observed is that zerocoin is even _more_ technically inaccessable but it had an accessible name and so many people were interested and a few people even learned about some of the details.  I also added the points that they could be done automatically, and that you could potentially use blind signing to even blind the merging party to the mapping, and that you could use sorting networks to boost the anonymity to any size, none ...
18:50 < gmaxwell> ... of which are all that important to the idea.
18:50 < nsh> mmm
18:51 < gmaxwell> https://bitcointalk.org/index.php?topic=5027.msg73733#msg73733
18:53 < nsh> "There needs to be a system of anonymous payments, and a simple trusted machine called the Pot. (In practice, the Pot would be simulated by the participants, using a cryptographic multi-party computation.)"   boy, those parentheses sure make that sound simple...
18:53 < gmaxwell> what gets described there can be accomplished with a coinjoin and an inverse coinjoin coupled with blind signing to prevent DOS of the inverse coinjoin.
18:53 < nsh> hmm
18:54 < nsh> how are legs broken if someone welches?
18:54 < gmaxwell> the output of the coinjoin is not anonymous.
18:54 < gmaxwell> (and thus inputs of the inverse coinjoin are not anonymous)
18:55 < gmaxwell> e.g.  it takes random private amounts and makes N uniform public amounts. And then later N uniform public amounts come back (or else!) and random private amounts are dispensed.
18:57  * nsh nods
20:13 < maaku> TD: I think merge avoidance and coinjoin are solving two different (but important) things
20:13 < TD> could be, but can you elaborate?
20:14 < maaku> well, take your coffee shop example. what if alice doesn't want her employer to know how she is spending her salary?
20:15 < maaku> by running a wallet that continuously mixes through coinjoin (until some privacy threshold is achieved), she can mask that information
20:20 < maaku> i think they complement each other nicely
20:30 < TD> do you mean "when" or "how"?
20:30 < TD> because i don't see how the employer could know what she's spending her money on regardless
20:30 < TD> unless she spends to a well known address (solution: don't have well known addresses)
20:31 < TD> i guess they would know what proportion of the salary she had spent
20:33 < andytoshi> my feeling is that hiding from your employer is a special, very difficult case
20:33 < andytoshi> coinjoin alone should thwart data analysts
20:34 < andytoshi> to hide from somebody providing all of your money, you'd need to do an off
20:34 < andytoshi> off-chain mix
20:34 < TD> maaku is referring to an article i wrote that explores some cases where it doesn't
20:34 < TD> https://medium.com/p/7f95a386692f
20:34 < andytoshi> oh, thx
20:37 < TD> maaku: i think i may agree that they complement each other in some cases, for sure. coinjoin type systems give some degree of deniability. however, at significant cost. it would be nice if the same deniability could be obtained without the cost.
20:39 < maaku> TD: the employer knows where he sent payment to
20:40 < maaku> and therefore knows the denominations at the very least of where she sent the coins
20:40 < maaku> and by taint, can deduce who owns the address
20:40 < TD> i don't follow the last part. the employer only sees that alice spent some of her coins.
20:40 < TD> he can't know what she spent them on
20:41 < maaku> yes, but when those coins eventually do get spent by the third party, they link to other outputs, which can be traced backwards
20:41 < TD> traced backwards how? i feel you're assuming something that i'm missing, here
20:42 < TD> employer pays alice. alice pays bob. bob sees $TRANSACTIONS but beyond knowing the last hop (alice) doesn't know more than that
20:42 < maaku> andytoshi: coinjoin can be used to hide from your employer as they can no longer be sure which outputs are yours, or coinswap which lets you swap identities with some other coin
20:46 < maaku> TD: i'm assuming that you can actually realistically determine the owner of a key from network analysis with better than random probability, even if it's a use-once key
20:47 < TD> i am not convinced that assumption is valid
20:47 < TD> it should *not* be valid at least, if addresses are not reused and merge avoidance is done
20:48 < maaku> if merge avoidance is done by every other node i transact with
20:48 < maaku> i don't like outsourcing my privacy to those i transact with
20:51 < TD> coinjoin requires outsourcing as well, in effect. you have to hope that there are enough others available at the time who have a sufficient amount they wish to mix that you get reasonable deniability
20:51 < TD> otherwise you end up with implausible deniability only
20:52 < maaku> TD: the scenarios I've considered for coinjoin mixing involve doing it in the background, yielding outputs that are made availble to the spendable balance
20:53 < maaku> coinjoin-as-payment is just an added bonus that obscures the fact that a payment is even occuring
20:53 < maaku> the quality of the mix doesn't matter so much then
23:08 < phantomcircuit> lol
23:08 < phantomcircuit> i just finished reading mikes entire blog post
23:08 < phantomcircuit> intersango hot wallet already sort of does that
--- Log closed Thu Dec 12 00:00:49 2013