00:17:06 sipa: gavin is on vacation at the moment 00:17:48 ok 00:20:46 sipa: it's not possible for two blocks to have identical time received, right? is this in case of future multi-threading? 00:20:56 (assuming a high enough resolution clock) 00:22:35 it uses a microsecond clock, but that isn't available on windows 00:22:52 actually, there should be no need for that 00:23:02 just an incrementing sequence id 00:23:25 yeah 00:23:36 windows does have high resolution clock APIs 00:23:38 good to bring that up 00:23:50 yeah, but not available through the boost function we're using now 00:23:57 in any case, sequence id is easier and faster 00:26:08 .. // Check trees node between the current best chain and the candidate. 00:26:12 that comment is a little unclear, imo 00:26:17 what's a "trees node" 00:26:43 that comment makes no sense :) 00:30:32 sipa: what happens if a thread is interrupted whilst it's in the middle of re-organising in this new way? 00:30:54 hmmm 00:31:13 i see interruption points, but no discussion of what happens if there's an abort 00:31:18 you're right 00:31:22 this could be a problem 00:32:11 i should add these comments to the github really 00:32:26 please comment on the pullreq, not on the commits 00:32:35 the commit comments sometimes get lost in rebasings 00:34:09 hmmm 00:34:49 i'm not sure how to do that. doesn't that lose the line references? 00:35:36 yeah :( 00:35:59 oh well. no matter. you have comments in your inbox now 00:47:13 TD: thanks 00:48:38 np 02:58:39 Sangheili_afk is now known as Sangheili 03:58:55 is there a channel like #bitcoin except everyone is not illiterate? 04:00:18 #eligius ? 04:58:49 andytoshi: heh maybe this one. 04:59:32 :P i'd like to get a coinjoin going without the same five people :P 04:59:40 oops, i put too many :P's in there.. 05:06:22 one can never have too many :Ps. >_> 05:06:42 but i guess if you're looking for a larger audience, maybe -dev. 05:06:53 or make a forum post >_> 05:15:29 yeah, i'll make a forum post 05:15:55 and try to preempt all the "TL;DR" and "nobody will use it, too complicated" posts.. 05:16:49 or even #bitcoin 05:17:29 well what prompted my question was, i tried it on #bitcoin, and was flooded with "too complicated, just a toy, tl;dr, nobody would ever use this" 05:17:53 apparently if you can't do something better to bitch about it than to either learn or ignore it 05:21:54 andytoshi: Bitcoin-otc might be a better venue. People are silly, obviously its not for everyone. 05:22:20 andytoshi: you should probably announce a time in advance in order to get people to expect to be there. E.g. I was thinking of organizing a weekly thing. 05:25:34 andytoshi: as far as a channel with technically interested people... hell if I know. Bitcoin is a complete mystery to me in that respect. 06:19:00 gmaxwell: well, thanks for the convo that just happened on #bitcoin then :P 06:19:09 also, i don't have your comments on ed25519 06:19:18 there was a power outage where my logger lives, i think it was then 08:37:02 andytoshi did you make a coinjoin bot or something 08:40:36 <_ingsoc> Is the code available? 09:10:25 Sangheili is now known as Sangheili_afk 11:10:04 nsh- is now known as nsh 15:16:48 -- 15:16:49 Alfred Menezes, who has studied the new algorithm as a cryptographic researcher at the University of Waterloo in Ontario, Canada, calls it "a fantastic algorithm—a stunning development." He says, "If I were a company today considering the use of pairing-based cryptography, I would be terrified of using small-characteristic pairings." In one case he studied, the algorithm succeeds in 15:16:49 274 operations, vs. 2103 operations with the previous best algorithm. "While the 274 computation is certainly a formidable challenge, with an organization like the NSA, it becomes feasible." 15:16:52 -- http://cacm.acm.org/news/170850-french-team-invents-faster-code-breaking-algorithm/fulltext 15:18:32 i'd like to see an animation of a las vegas descent tree algorithm in operaiton 15:33:24 Emcy, _ingsoc_: no, ;;cjs just pings my website to get the current status 15:33:49 the website is here: https://www.wpsoftware.net/coinjoin/ , the source to the interesting stuff is here: https://www.wpsoftware.net/coinjoin/ 15:34:13 but there's a lot of surrounding code which runs the website which is not public, it's too ugly 15:35:16 i meant, the source is here: https://github.com/apoelstra/coinjoin 15:51:50 oh god rawtxs 15:52:38 A1 for effort, needs huge red 72pt warnings though 15:54:09 there is quite a lot of work put into making it idiotproof 15:54:35 i'm not a very creative idiot, but i can't think of what people could do wrong here 15:55:44 spending all change as fees is quite popular with the mortals who attempt to mess with rawtxs 15:56:59 yeah, gmaxwell had a clever idea for that ... all the fees should be sent to a magic address, and the joiner does the fee calculations itself 15:57:08 so submitted transactions are required to have inputs == outputs 15:59:18 is that possible in bitcoin right now 15:59:47 no, the joiner actually modifies the transactions before asking for signatures 16:04:05 ;;cjs 16:04:05 Coinjoin Status: There is no currently open session. 16:12:19 its a good start, but we know this all has to be completely transparent eventually if its going to make any real impact on the system 16:12:53 Emcy: AIUI, this isn't supposed to become what everyone uses, or make any real impact on the system 16:12:56 At least not as-is 16:13:36 this or CJ in general? 16:13:54 CJ absolutely has to work wide-scale, or something like it 16:14:26 Emcy: this 16:14:35 Not CJ in general, of course 16:14:37 the alternative is having such a powerfult technology as bitcoin turned against us 16:15:11 and im kind of sick of seeing civil society forge its own chains by accident 16:23:00 we are bound by no faster iron than our flocksome follies and unfounded fear 16:52:43 i am rather skeptical about widespread coinjoining. small scale joining gives you a small modicum of deniability .... how much privacy it gives you is rather an open question at this point 17:00:29 Emcy: in the short term my main thinking is to use coinjoin with two-party-mixes as a way to thoroughly break the idea that transactions are authored by a single person. There's a lot of work to do beyond that, but breaking that assumption is a very important first step. 17:01:35 Emcy: e.g. naive two-party-mixes leak information with regard to the values on the txins and txouts, but subsequent efforts can help plug that leak by, for instance, using value-matching techniques where one party to the transaction delibrately matches the values of the other party's txouts 17:03:06 Emcy: this also ties into merge avoidance: if txins are not always merged into a single txout to make a payment you have a lot more flexibility in making coinjoins that don't give external observers useful information. equally that people are doing merge-avoidance with coinjoin means that even when you don't use that feature, transactions have solid plausible deniability 17:08:40 Emcy: example: I want to pay you, and you've told me you'll accept up to two txouts for that payment. I do a two-party CJ mix with someone who needs a specific output value, and I use one of those txouts to match their value, the other to send you the balance of the payment, and I have a third txout with my change. 18:50:11 topic is: Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas 18:50:11 Users on #bitcoin-wizards: andytoshi-logbot goedgoed TD adam3us eristisk OneFixt daira1 nsh jgarzik hnz Graet forrestv deepc0re_ Fistful_of_Coins Emcy MoALTz Luke-Jr warren joecool Alanius K1773R realazthat iddo gribble sipa jrmithdobbs helo Sangheili_afk edulix andytoshi michagogo|cloud maaku spinza Muis kinlo CodeShark EasyClaus petertodd nanotube azariah4 @gmaxwell typex phantomcircuit Mikalv midnightmagic tucenaber epscy UukGoblin pigeons trn jarpiain lianj 18:50:11 Users on #bitcoin-wizards: cfields Ryan52 HM2 firepacket harrow hno BlueMatt amiller wangbus Krellan Hunger- 18:50:20 nsh: I really gotta get around to implementing decentralized IRC... lol 18:50:43 thx, my perl script does not notice being unhooked for some reason, it is supposed to reconnect 18:50:44 petertodd, didn't you have notes on that? 18:50:45 nsh: meh, I'll just write a whitepaper on it instead... 18:50:49 aye, that's the way 18:50:53 implementation is for grad-students 18:51:07 nsh: hehe, "My favorite programming language is English." 18:51:08 secure irc (not decentralised) exists, cryptocat 18:51:14 though not sure there's any point encrypting irc :) 18:51:20 of course it's not really irc 18:51:30 * nsh smiles 18:51:44 what's the latency on pond? 18:51:54 high 18:51:55 nsh: high 18:51:57 ok, nm 18:51:59 it's meant for email like uses 18:52:03 right 18:52:10 nsh: there's built in delays on pond 18:52:15 multi-user chat OTR like chat is what cryptocat is for 18:52:20 * nsh nods 18:53:17 nsh: anyway, the dark wallet guys are interested in doing it, but no specific timeline - cj is much higher priority, as is openpgp stuff for payment protocol/payment protocol-like stuff 18:53:23 ok wizards, I'm trying to decide if the forward-diff, reverse-diff or both should be checkpointed in the utxo validation index proposal 18:54:07 in addition to the committed root hash 18:54:07 grrrr. this time the irc app crashed 18:54:09 sigh 18:54:48 maaku: explain? 18:55:55 nsh: I don't think anyone is using characteristic 2 for pairing, at least not in the open world... everything is using the 254 bit BN curve, which is on a prime field. 18:56:06 my diff I mean what I called an "operational proof" in the previous BIP - a list of key,value pairs to insert/update, a list to delete, and paths through the merkle structures to accomplish that 18:56:57 a forward-diff would take you from prevBlock to currentBlock (e.g. summarize the effect the block has on the index structure) 18:57:18 a reverse diff is an undo block : take you from the current block to the previous block 18:57:36 it should be possible to turn a forward diff into a reverse diff and vice versa 18:57:51 gmaxwell, right. i think it's much closer to a curiosity than a catastrophy for the foreseeable future. but i don't know the math at all, so can't guess at the likelihood of eventual generalization of the technique 18:57:57 since you have both the information being added (explicitly) and the information being removed (from the path) 18:58:11 maaku: so what's the use-case for those deltas? 18:58:52 petertodd: well, a reverse delta could be used to recover from a reorg during pruned operation 18:59:06 but beyond that, that's why I'm asking :) 18:59:12 nsh: it's only like the Nth attack on characteristic 2 things, so I don't think any engineering-cryptographers (as opposed to theoretical-cryptographers) are the least bit excited by it. 18:59:13 maaku: but why does that need to be committed? 18:59:43 maaku: having explicit committed deltas would also make proving fraud even more complex, because now the deltas themselves may be fraudulent 19:01:10 gmaxwell, the paper mentions "medium" characteristic too so perhaps there's some ground being made. dunno 19:01:20 petertodd: a delta would give you a listing of the inputs spent just in that block though 19:01:42 i know that's something you've advocated - is it still relevant if there is a committed validation index? 19:01:51 medium appears to mean "3" though 19:02:17 in which case practical applications should properly be described as employing fields of "unfathomable" characteristic :) 19:02:19 maaku: ah, good point. :) of course, I advocated *just* having the deltas 19:03:20 maaku: see, for a wallet syncing txs, they want to know two things: a new txout exists relevant to them, and a txout was spent that they owned 19:03:25 another point is storageless mining / validation - the delta (forward in this case) provides the information you need to update mempool proofs 19:03:58 maaku: so if you only have deltas, you want both. if you have utxo + deltas, then you only need the "was spent" delta, the "is new utxo" is provided by the utxo set commitment 19:04:56 maaku: for memoryless operation you don't need to commit the forward delta: you provide it to update the UTXO set, and the fact that the forward delta applied to the existing UTXO set results in the new set is the proof 19:06:52 which is what the forward delta is - it contains the relevant portions of the utxo set 19:07:15 maaku: yes, but my point is there is no reason to commit it 19:07:33 nsh: I mean, ec with highly composite fields is subject to index calculus and is known insecure forever. People use "unfathomable" characteristic now in practice (this isn't to say that there aren't commercial characteristic 2 systems, there probably are…). 19:07:39 maaku: committing it just fixes the way it's designed in stone 19:08:16 maaku: and come to think of it, the same argument applies to the reverse delta: you're better off just proving to SPV clients that the UTXO still exists in the set for every block when it comes to showing them their utxo wasn't spent 19:08:40 * nsh nods 19:08:52 maaku: there's some size tade-offs here, but the difference isn't much and I'm very hesitent to make things more complex for a minor decrease in bandwidth 19:10:31 petertodd: what about truly storageless nodes (which just keep the current merkle root + mempool + some temporary space for proof processing)? 19:10:50 my thought was that by committing the reverse delta they can work backwards 19:10:51 maaku: again, there's no need to commit the deltas 19:11:17 maaku: they know the deltas are valid by the fact that the UTXO root matches after the deltas are applied 19:12:31 ah, so I can just query the network "what's the delta from A to B?" and verify what I get back 19:12:34 ok 19:13:08 yup 19:13:30 which means if we figure out a better way to describe the deltas, we can change that without a fork 19:13:40 ok i had some fuzzy thinking - i was thinking they would query for proofs by hash (of the delta itself) 19:13:45 but that's silly 19:15:05 on another note, I had a complex mechanism for structuring the final txout of the coinbase transaction, but I don't think that's necessary 19:15:14 mathematically, is there likely to be a "canonical" way of describing the difference in the utxo set structure? (modulo some symmetries that are orthogonal to security/accounting) 19:15:45 here's an easy rule: if last txout starts with OP_RETURN, concat the remainder of the script with the coinbase string 19:17:07 nsh: it's a weird question. there are arbitrary choices and tradeoffs made in choosing/designing a Merkle structure 19:17:26 but it's definately a requirement that there exist a canonical form of that structure 19:17:43 well, many of those choices will be fork-constrained, i'd imagine 19:18:13 fork constrained? 19:18:33 maaku: whats the op-ret rule for? 19:19:09 petertodd: you start stuffing Merkle roots in the coinbase string and you quickly run out of room and/or crowd out other uses 19:19:36 maaku: right, but, how does that rule help? 19:19:41 and changing the size of the coinbase string is a hard-fork ... so overflow to the last txout 19:19:52 also, allows midstate compression 19:19:55 nm, i gtg sociability :) merriment to ye all 19:20:09 nsh: happy holidays 19:20:38 maaku: the only thing in the coinbase that's consensus right now is the height, so I'd be inclined to leave that situation the way it is rather than add even more complexity 19:20:46 nsh: later 19:21:19 nsh: when you come back, there's a long debate in the UBC thread about what structure to use for the index 19:21:35 prefix trees were chosen because anyone could reconstruct the canonical structure without knowing the entire spend history 19:22:26 right, but with needing to know the entire UTXO set, and with the disadvantage that adding anything to the set requires having to have the entire set 19:22:42 (though you can outsource the storage to others) 19:23:09 petertodd: in a series of bips I will be proposing committing three 256-bit hashes (validation index, wallet index, arbitrary data committment) 19:23:31 maaku: what's the validation and wallet indexes exactly? 19:23:50 validation is txid -> CCoins 19:24:32 wallet index is what I've been calling the address index: txid:n -> unspent txout 19:25:40 sory, scriptPubKey:txid:n -> unspent output 19:26:11 i find it easier to explain to muggles if I call them based on what they are used for: txid keyed index for blockchain validation, scriptPubKey:txid:n index for lightweight wallet apps 19:26:40 maaku: suggestion: explain in detail how some examples of compact proofs could be made for various frauds 19:26:55 petertodd: will do 19:26:56 maaku: being able to prove fraud compacting is a huge use-case for all this stuff 19:27:18 maaku: for instance you do need a merkle-sum-tree in there for txin/txout values 19:28:19 petertodd: yes, both indices have nValue summation in the "extra" field 19:28:23 maaku: and while a bit less efficient, I'd be very inclined to ensure that tree must be distributed as part of some other use-case so we don't get into a situation where nodes stop passing it around 19:28:29 maaku: good 19:29:09 maaku: also, it should be easy to prove part of a transaction exists, IE, I shouldn't need the whole tx to just prove a single txout existed in it 19:30:16 maaku: now I guess scriptPubKey:txid:n -> unspent output works for that, but there needs to be something similar for the scriptSig case too - txid -> CCoins would probably better be txid -> merkle tree of txins + merkle tree of txouts 19:30:37 petertodd: can you elaborate? I'm using a modified version of sipa's CCoins data structure which is basically metadata + compressed unspent outputs 19:31:06 i see 19:31:19 maaku: suppose I have a 100KB transaction, can I prove it had a txout with a specific form without providing the whole transaction? 19:32:13 maaku: that txid tree is the perfect place to sum fees too: sum all transaction inputs and outputs, sum that, then sum all tx fees 19:32:17 yes you'd only be providing the compressed outputs (33 bytes * number of unspent outputs, if they are standard form, plus a few bytes metadata) 19:32:45 maaku: but that's the thing, # of unspent outputs can be very large, leading to a large proof 19:33:26 maaku: I'm also extremely reluctant to make the CCoins compression a consensus thing - it's very likely standard transaction forms will change in the future 19:34:22 maaku: much simpler is just to commit to the uncompressed forms, and do compression (if warrented) as a optimization for the on-disk format 19:34:40 petertodd: I would find that compelling if it weren't for P2SH 19:34:43 maaku: and for that matter, for the on-network format too 19:34:49 maaku: P2SH may change in the future 19:35:09 maaku: like I say, if you don't commit to the exact compression format that doesn't stop you from using one anyway 19:35:44 yes that is true 19:36:08 i'm already considering a different hash format for gmaxwell's SNARK concerns 19:36:27 SNARK 19:36:32 how do you people come up with these names 19:36:42 well not different, just expanded with fields having fixed width and fixed offsets 19:36:51 maaku: another interesting issue is that if this is a pure UTXO thing, then we don't have any committment to OP_RETURN data, which shuts out a lot of valid applications for it where a per block index of that data would be very useful 19:37:12 phantomcircuit: the quality of your acronym determines your funding when government research dollars are at stake, alas 19:37:14 maaku: e.g. my stealth address stuff 19:37:53 maaku, lol 19:38:04 maaku: suppose we find we picked the wrong hash format, what's the plan? that consideration should be documented 19:38:09 tbh my donations are largely based on hilariousness of acronyms 19:38:32 phantomcircuit: PHANTOMCIRCUITISADICKHEAD 19:38:53 lol 19:39:04 petertodd, im going to hack you and steal all your research funding 19:39:17 see whose laughing then! 19:39:24 phantomcircuit: IGTHYASAYRF <- that's not even pronouncable, lame 19:40:52 petertodd: so one advantage of committing to a compressed serialization format (for network and disk at least) is the ability to distribute the UTXO set and get a validating node online quickly, then move backwards validating to genesis 19:41:16 -- 19:41:20 * maaku is thinking 19:41:30 maaku: but that's not true: you can just as equally commit to the uncompressed format and pass around compressed data 19:41:52 maaku: the only advantage is that the amount of data being hashed is less, but compressed-vs-uncompressed is a tiny difference 19:42:20 petertodd: yes, but the compression may not be lossless (pruning of spent data) 19:42:35 even if you're using a proper custom dictionary you're not going to get more than about 15% compression 19:42:38 maaku: huh? I'm talking about CCoins compression here 19:42:49 CCoins does not contain spent outputs 19:43:02 that's what I'm talking about 19:44:51 maaku: right, but then you're talking about TXO vs UTXO sets 19:46:10 maaku: if you work with a full UTXO set, there's not much of a difference between the two - the TXO version needs some extra data to fill in the missing parts of the tree, but we're talking about a log(n) difference 19:48:58 maaku: you can also get up and running faster with a TXO set, as you can grab the UTXO's that are most likely to actually get spent first, reservingthe less likely ones for later (or never bothering) 19:58:27 http://www.bbc.co.uk/news/technology-25506020 i cant believe this is the first exposure thousands of people will have to the concept of public key crypto 21:46:50 Sangheili_afk is now known as Sangheili 22:30:48 Sangheili is now known as Sangheili_afk 23:57:16 oh good, there is now a storage spam coin: http://datacoin.info/index.php?id=index 23:58:01 haha 23:59:37 cryptocurrencies: fuzztesting the fascade of economic rationality since 2008 23:59:50 heh