00:28:58 petertodd sipa: two separate indices under consideration here right? 00:30:00 the TXO MMR which is an append/update structure whose hash root is committed to the coinbase 00:30:25 you append each new output, and update a spent-bit for each input 00:30:45 and a separate, per-block tree of outputs indexed by TXO, right? 00:35:09 daira1 has joined #bitcoin-wizards 00:35:43 At some point I'd convinced myself that it made sense to have seperate append only and insert only datastructures, though I don't know why. Obviously managing an append only one is much easier. 00:38:35 eristisk has quit 00:38:45 daira2 has quit 00:40:08 oh i guess it can be the same structure as actual insertion/append order within a block doesn't matter 00:42:33 gmaxwell: for double-spend validation I still think an updatable trie structure is best 00:42:52 but lately I've been thinking about a MMO-like structure for the scriptPubKey index 01:04:28 justanotheruser has joined #bitcoin-wizards 01:05:13 justanotheruser: So perhaps its possible to construct a precisely brittle cryptosystem and paired signature system such that I encrypt data using keys plus some additional data which I give you, such that knoweldge of _any_ signature with the key is enough to decrypt the data. 01:05:45 but not enough to forge signatures. 01:06:22 i really want to see more of a sketch of how this would work, and elaborations on the intractability of adaptive difficulty 01:06:44 or at least some clearer idea of to achieveable precision in likely decryption window 01:06:48 *the 01:07:00 DSA like schemes can be constructed so that they leak a linear relationship between the the private key and the message. So the trickyness would be figuring out how to leak just enough that the encryption is revealed but not forgery. 01:07:01 (re: POW which turns the distributed computation into ticking for timelock encryption) 01:07:16 right 01:07:53 nsh: yea, I dunno, it's a very vague sketch. I was happy that something like it sounded possible because it just seemed to me to be the most realistic way of having non-trustbased timelock encryption I'd ever heard or thought of. 01:08:04 I wish this was possible with bitcoin because this altcoin would only be valuable for secret keeping meaning the only exchanges would be between miners and secret sharers 01:08:12 and speculator 01:08:13 s 01:08:17 But the obvious ways to go about bilding it are super ugly. 01:08:22 mmm 01:09:20 justanotheruser: Well, as I said before a two phase protocol could make it possible to pay for it in bitcoin. The advantage of the alt thing is just that the pow would be "useful". 01:09:44 E.g. lets not go building a bunch of things that require people to needlessly burn energy when we can instead just build one. :P 01:11:08 gmaxwell: So you're saying the secret miners would be securing the network in this altcoin, while they wouldn't be in bitcoin? 01:11:24 I mean you're saying that's your concenr 01:12:03 justanotheruser: right. The idea on the altcoin page is that you have a cryptocurrency who's POW has a side effect of yielding previously unknown private keys for public keys which were set way in advance. 01:12:45 which IMO is way more useful than that primecoin crap. :P 01:14:33 My example of using DLP cracking is lame because DLP cracking is super-not-progress-free. You get a quadratic speedup from being stateful... but there are a LOT of different cryptosystems out there. I would be really surprised if something weren't reasonably sutiable. But even ignoring that details like handling difficulty seem hard to get right. 01:14:34 gmaxwell: Is there a use for primecoins PoW? No one has been able to explain who wants Cunningham chains 01:15:02 No. There is no use as far as I can tell, except abstract numbertheory navel gazing. 01:15:16 of course, insight comes from unexpected places at times. 01:16:10 plus, I _suspect_ that PoW might be the _only_ really viable way to have truly secure timelock encryption. 01:16:23 * nsh nods 01:16:33 just because the timelock usage alone could never really fund enough processing power to make it secure. 01:17:24 The problem I see is your secret being worth 3 times as much as the secret rewards meaning your secret is found 4 times as fast as it should have been. 01:17:49 well thats part of the reason I propose encrypting with all intermediate keys. 01:18:07 so the comparison is not one blocks reward, its all rewards between here and now. 01:21:22 hm 01:21:36 gmaxwell: Do you consider any altcoins useful other than namecoin? 01:21:40 You could also strengthen a decenteralized timelock with distributed timelocks. 01:22:16 hmm 01:22:26 justanotheruser: not really so far, mostly they've done absolutely nothing interesting. The few that aren't just copied of the bitcoin code with a few lines changed are mostly either pure marketing and vaporware or are trivially insecure rubbish. 01:23:17 i bet a way to find cunningham chains quickly would also yield some useful number-theory results 01:23:25 so primecoin will become useful exactly when it's destroyed :) 01:23:26 E.g. To decrypt this message you need all the blocks between now and 2016 and 6 of 10 timelock servers OR all the blocks between now and 2017. 01:24:09 gmaxwell: how do you handle an increasing network power? 01:24:47 justanotheruser: one of many unsolved problems here 01:24:59 hm? no I proposed a solution, but its kludgy. 01:25:13 Or is this the centralized distributed solution with the servers verifying the block time 01:26:02 gmaxwell: it's not on your alt page... 01:26:16 you've got a mechanism for scaling reward 01:26:25 maaku: "POW which turns the distributed computation into ticking for timelock encryption" 01:26:48 but say I want to encrypt something to 2016. how do I know how far to go? 01:27:05 justanotheruser: I suggested running multiple problems. Say your problems are just H("timelock is great"||x||y) = pubkey. and x and y start at 0. When a solution for a given problem is found, y is incremented. 01:27:07 justanotheruser: i'm talking about difficulty adjustment specifically 01:27:42 If difficulty is too low then to solve a block you start requiring work on x=0 and x=1 ... if it's still too low you require work on x=0 and x=1 and x=2 01:27:50 gmaxwell: ah, i misunderstood. so you break each key into multiple problems? 01:27:55 maaku: your concern is it being found faster with higher network hashpower? 01:28:22 and so basically instead of solving one timelock sequence you solve 1 to n time lock sequences, with n depending on difficulty. 01:29:00 you can encrypt your message with as many of the sequences are you believe will exist in the future, but there is some risk if the difficulty is too low that the network is not solving the sequence you need. 01:29:01 gmaxwell: That involves centralization right? 01:29:05 wtf 01:29:06 no 01:29:36 sorry, I'm just confused as to where you'd get that idea! :P 01:29:42 I was confused by "and 6 of 10 timelock servers" 01:30:04 justanotheruser: oh I thought you were talking about me explaining how difficulty adjustment works. 01:30:20 that was just a comment on 17:21 < gmaxwell> You could also strengthen a decenteralized timelock with distributed timelocks. 01:30:26 and yes, its not decenteralized. 01:30:49 I see 01:31:08 But, e.g. decenteralized + distributed OR lots-more-decenteralized doesn't seem too bad to me. 01:31:36 justanotheruser: my concern is that you cannot predict which keys to use to encrypt something such that it won't be release until day X in the future 01:32:09 I don't see how 6 of 10 timelock servers verifying blockchain length to release a secret is different from them verifying the data 01:32:22 maaku: well you can in my example, you just encrypt using x=0 y={0..expected time in the future} 01:32:30 justanotheruser: huh? there is no verifying the blockchain at all. 01:32:51 brb 01:33:40 gmaxwell: but then in the future when people have asic ecdsa crackers for this, difficulty will require each block to iterate x=0..(some very large amount) 01:33:42 but it could just as easily be built to do x=0 y=(0.. some large amount) 01:34:06 maaku: presumably they'd not do this, prefering to get the block reward 01:34:13 maaku: yes, correct. Though if they did that they'd not get the block reward. 01:34:19 i don't think this is safe against an asic explosion 01:34:43 so they give up 1 block reward in order to destroy entirely the utility of the timelock encryption 01:35:32 maaku: No, because you have the option of also using the higher Xs... but it puts a tradeoff over the risk that the network may not tick for all the work you need in the future. 01:36:13 basically, to use it with perfect security requires you to predict the future difficulty. But it can be constructed so that if you fail to guess right all is not lost. 01:36:15 Which means you might as well just make the network tick with a single appended value, so you guarantee all keys are moved through 01:36:54 Then you can use it to say "I encrypt this until the network expends X computational cycles" 01:37:07 maaku: no, that gives you no control of the time at all. And you _do_ guarentee that all keys are moved through for all levels under the difficulty. 01:37:24 lack of control over tiem is precisly my point... 01:37:27 you can achieve that in the multilevel scheme by threshold encrypting. 01:38:34 basically the multilevel scheme allows you basically freedom between choosing absolute work, and absolute time (but with race ahead risk) 01:39:51 e.g. you can encrypt the problem to X=0 * 1000 or X=0*500 + X=1*500 or X=0*250 + X=1*250 + X=2*250 + X=3*250 ... to achieve absolute work (to whatever degree you wish to approximate it) 01:40:54 [unrelated] new optimization of koblitz curve optimization: http://eprint.iacr.org/2012/519 01:41:40 gmaxwell: but presumably you reveal which ones you encrypt against right? (to avoid combinatorial explosion in decrypting) 01:42:03 so someone need only "work ahead" those keys to decrypt 01:42:06 or you can encrypt to X=0 only, and have absolute time but perhaps a race-ahead risk if the difficulty goes way up. Or you can have some guess at future difficulty (e.g. if the system is already on asics, then projecting mooress law or whatever).. or you can use all of these at once. 01:42:26 (and if they're a miner they can later reuse that work for the subsidy) 01:42:35 No, the work can't be reused. 01:42:53 The attempts you make in the cracking are based on the hashes of the prior blocks, or you don't have a consensus. 01:43:54 maaku: But what I described there achieves absolute work ("X=0 * 1000 or X=0*500 + X=1*500 or X=0*250 +"), regardless of the difficulty. You can "race ahead" sure, but there is no faster way than doing a certan absolute amount of work. 01:44:01 gmaxwell: I'm not sure I follow. the public keys are known in advance right? and the problem is to find the private keys right? 01:45:21 maaku: correct. The hash of your header tells you what part of the solution space to check. Finding a block requires proving you checked the right part of the space and found a distinguished point. 01:45:59 (a distinguished point is either the solution to the current problem, or some 'near miss' based on some arbritary criteria) 01:47:57 Wrt the absolute stuff, I was only pointing out that my hierarchical scheme allows you to get any mixture of "absolute work" or "absolute time with race ahead risk (diff overshoot risk)" or "absolute time with failure to decrypt (diff undershot risk)" that you like. It's not perfect, by any means, but I think it could be reasonably successful. 01:49:29 maaku: e.g. forget that there is a faster way of solving ECDLP than just testing secret keys. To mine this you take your header hash and multiply it by the base point and then measure the current solution's hamming distance to the current digits of pi or whatever is the current x=0 target problem. If its below a threshold you have a x=0 solution. 01:50:07 if you raced ahead previously, that work isn't useful to you because the secret keys you checked weren't derrived from hashing a vaid header. 01:50:13 (at least not useful for mining) 01:53:33 andytoshi: that paper is about classical koblitz— which is for characteristic 2 fields. I can't believe people are still doing stuff with characteristic 2 in 2012. 01:54:07 oh, damn 01:54:12 also it's 2014 :P 01:57:15 let's split the difference for another couple of days eh? :) 02:12:10 *sigh* 02:12:15 https://www.openssl.org/ <-- compromised 02:13:00 * gmaxwell not going to load a compromised site. 02:13:21 just says "TurkGuvenligiTurkSec Was Here @turkguvenligi + we love openssl _" 02:13:26 no html. but good policy :) 02:17:37 In blockchain time It's already April 2014 02:26:59 joecool has joined #bitcoin-wizards 02:32:37 So I think I have a goofy convoluted protocol for centeralized timelocking, between alice and a clock though it requires having some substr opcode we don't have. 02:33:12 what's at the centre? 02:33:46 The idea is that alice and the clock can make a (complicted) series of transactions which sets things up so that alice learns a public key for which the clock knows the secret. Alice and the clock both put up funds, if the clock releases the secret on time it gets both its funds back and alices funds. 02:34:20 If the clock releases the secret early, then it doesn't get its funds back. If it doesn't release it alice gets its funds. 02:35:04 the basic idea is that if you give me a signature with a key of yours, and if we had the right opcodes, I could write a scriptpubkey which allowed you to redeem it if and only if you reuse the same k value, thus disclosing the private key. 02:35:07 hmmm 02:36:09 so then you setup a complicated sequence of timelocked n of m fiddly transactions so that there are three ways the thing can be released... early— and the funds can only go to fee or alice.. ontime the funds go to the clock, or late and the funds go to alice. 02:40:00 I dunno if it would be useful though, esp I don't know how to prevent people from freeloading. E.g. alice publishes the initial signature and now any number of people can use that timelock 02:42:57 i'm not sure that's too much of a problem, necessarily 02:45:43 well, if the bitcoin incentives are to have any point at all they should be fairly large... and it's not reasonable to ask clock to lock up funds for a long time without a considerable return. the more people who use it without paying the more incentive for clock to make a deal with someone and never disclose or disclose early. 02:47:06 how about a different one, how about a semi-anonymous quorum timelock. 02:48:43 N players have a distributed public private key. The private key is split into polynomial shares such that— say— 50% of them are required to recover the private key. 02:49:14 right 02:49:34 over time, some M of the N player drop out— they vanish without any of the other playeryers hearing from them for a while, and so they do some quourum consensus and decide those M players are defunct. 02:50:19 They invite M new players, and do some protocol needing 50% of the original N to update help the new M players recover the shares of the M that left. 02:51:03 ignoring how you'd go about doing that— how would this break down? 02:52:16 i think i'm lost 02:53:05 http://www.openssl.org/ <--- sigh 02:53:07 nsh: well you get how you can have a key shared among many people such that you need a majorty? You can do this in ec groups such that there doesn't need to be any trusted dealer. 02:53:15 sure 02:53:42 if you love openssl you wouldn't do that... 02:54:37 nsh: just information theoretically, if M of the N leave, but M (maybe they love openssl, but not as much as fleeting noteriety in dubious social circles) 02:55:09 gmaxwell, can they repopulate without revelaing the secret itself though? 02:55:11 that seems less obvious 02:55:13 (after all, they could just recover the whole key and than split it up again) 02:55:23 depends on the sharing scheme i guess 02:56:08 nsh: Yea, I haven't figured out how to do it, I'm pretty sure it can be done though. Just assume they can for the moment— it's pointless if the scheme isn't useful regardless of doing that. 02:56:19 okay 02:56:21 nsh: probably helps them get their next job. i've heard that some major art thefts are only to enable the theives to get "in" to an organization 02:56:21 nsh: or actually I'm completely sure it can be done, I don't know how easy it is to do it. 02:56:31 * nsh nods 02:57:09 nsh: I'm completely sure because the remaining N-M plus new M could use secure multiparty computation to secretly regenerate the whole key and then split it back up and give it to the new N users. 02:57:22 yes, that makes sense 02:57:36 Though I also think its likely that there is a less horriffic way than invoking SMPC. 02:57:36 modulo some computational/bandwidth costs 02:57:45 * nsh nods 02:58:24 seems to me that you could get a pretty darn robust timelock this way. 02:58:39 you just need some sybil resistant way to select players. 02:59:06 i'm missing bits still. how do you go from N of M secrets (with dropouts and repopulation) to timelock? 02:59:11 And then you can do {magic} to continually redistribute the key so that people coming and going don't break you. 02:59:31 oh just as the "rules of the system" the N parties agree that once the time passes they'll all publish their keys. 02:59:52 backed by fidelity bonds? 03:00:03 So it's secure so long as the majority follows the rule. But systems like that often aren't pratical because they don't handle the members changing over time. 03:00:45 hmmm. i don't know how easy it would be to find N people who would reliably publish on schedule 03:01:11 nsh: maybe? or love for their commnuity. It's not like this is an expensive operation. Generally the reason I think majority of N systems are not pratical isn't that you can't trust the majority for most things you'd want, but because of membership complications. 03:01:21 nsh: well its not people, of course, it's people's software. :P 03:01:28 sure :) 03:02:49 i think you could set up an adaptive cracking challenge via a set of clues running on daemons spread about place such that the Nth clue is published encrypted with a puzzle of difficulty chosen on the basis of how quickly the N-1th puzzle was cracked 03:02:54 e.g. you could do this very simply, with all of us here.. but a year from now many of us may have moved on, gotten hit by bussess, become pissed off at the group. And a bunch of new people would have arrived. Maybe N/2 is unfindable a year or two from now. or you just barely have N/2 still standing, and a few people decide to hold the group randsom. 03:03:38 the general principle of "topping up" the multiparty pool seems a pretty useful one 03:04:20 and this isn't just wank, you could use something like this to enable p2pool to hold a abalance. e.g. have a private key escrowed to the p2pool hashrate, and keep "topping up". 03:04:43 but perhaps open to sneaky people who (being coerced to) fake absence until a threshold is reached 03:05:33 it might be possible to modulate each share when topping up such that people who have dropped out are no longer able to partake in revealing 03:05:35 sure, well one thing about the SMPC approch to it is that you could totally redo everyone's shares. The original interpolation way I was thinking about this was vulnerable to people "leaving" in ordre to come back and get someone elses share. 03:05:47 right 03:06:44 yea, you could achieve that at least under the SMPC case... where you have no risk of an incremental break as the shares are just unrelated. (e.g. you have an encrypted secret which is shared, and inside the smpc you reencrypt, so the shares are unrelated) 03:06:54 right 03:07:52 I guess one problem is being at all confident that "there is anything in the box". 03:08:40 e.g. a bunch of jokers begin such a system with an encryption of nothing, but promising it is the key to great riches. And they all gradually leave, selling their share in the pot to other people. 03:08:49 heh, sounds like religion 03:08:53 :) 03:09:26 but I guess that too isn't bad in the SMPC model, since the SMPC could just produce a proof of knowledge (E.g. signature) as a side effect at every remix. 03:09:29 ohhh I found a problem. 03:09:43 A old majority could fork a past state. 03:09:52 (there was a schoolboy prank where you'd get a bunch of people to stand at the corner of a tall problem and all point up and look excited. then wait for more people to arrive until it was sustained enough for the original pranksters to wander off) 03:09:57 fork? 03:10:05 s/problem/building/ # heh.. 03:10:33 e.g. people leave the system until none of the original players are left. The one day the original players meet up and go, "oh I wish we still controlled that key" ... "But wait! I saved my old share, if we all did!" 03:11:26 ah, right 03:11:28 so that would bugger the timelock case where you can't usefully rotate the keys as topups happen. 03:11:45 well, there's no way around that i can think of that doesn't require a T3rdP 03:12:03 but it wouldn't hurt the p2pool "keeps a balance" case, since the pool could just keep moving the funds. (e.g. the bitcoin network is the trusted third party) 03:12:12 right 03:12:39 i think ways of using the bitcoin network as a trusted third party will be a pretty big area of research in future 03:12:46 and tada, if we had scalable threshold signatures in bitcoin we wouldn't need anything else for the p2pool case. 03:13:35 you take your N p2pool hashes (selected by their shares in the p2pool sharechain), and you assign funds to them... then late a largely overlapping new N are selected, and the they generate a new threshold key, and the old N move the funds to the new threshold key. 03:13:41 (are there any threads/mailpost/notes on scalable threshold signatures?) 03:14:23 nsh: they're straightforward if you use schnorr instead of DSA, or so says adam3us— I've not personally implemented. At least the N of N case is obvious enough. 03:14:47 basically for the N of N you can just directly compose the public keys.. and to sign directly compose the signatures. 03:15:00 mmm, right 03:15:23 The N of M works based on schnorr basically testing a linear relation, but I've not actually worked through how it works. 03:16:11 lack of scalable threshold signatures I think is a major shortcoming in bitcoin, probably the script limitation with the greatest impact on other protocols. 03:16:22 hmmm 03:16:53 esp because other limitations you can generally work around by invoking multisig. 03:17:23 e.g. how coinswap makes any complicated protocol look like a multisig. :P 03:17:26 assuming schnorr sigs allow for M-of-N, could you add the functionality via a new OP without changing out ECDSA completely? 03:17:32 correct. 03:17:40 right 03:17:47 we definitely need to have a script-extension playground 03:17:52 it's a little tricky to make it backwards compatible. you just can't add a OP_NEWCHECKSIG 03:17:53 that would be very useufl 03:18:28 e.g. it would need to be somehting like a P2SH style change. 03:18:45 what does P2SH style mean? 03:19:17 a generalization of payability? 03:19:37 the reason you can't just take one of the existing NO_OP opcodes and make it into a OP_NEWCHECKSIG is that I could write a transaction that did OP_NEWCHECKSIG OP_NOT OP_VERIFY. 03:19:49 e.g. this transaction is only valid if the newsignature fails. 03:20:21 hmm, and this shoots other places than your (transaction sender's) own foot? 03:20:41 what I mean by p2sh style is that the whole _new syntax_ script is completely hidden from old nodes, they just see a boring hashlocked transaction. 03:21:06 oh, i see 03:21:27 nsh: yea, if OP_NEWCHECKSIG looks like OP_TRUE to old nodes, then I could author a transaction which new nodes would accept but old nodes would reject, and that forks the network. 03:21:40 but no biggie, just hide the whole new script from old nodes completely. 03:21:43 * nsh nods 03:22:20 so it's as solved as backwards compatible P2SH, at least 03:22:32 adam3us has quit 03:22:43 though I don't know if any future script extensions are realisitc at all. There are now several actually functional full node implementations, whos going to make those people implement any particular change? 03:24:33 hmm 03:25:07 there should be families of end-to-end functionality for which it doesn't matter if there exist nodes that are blind to the internals maybe 03:26:23 it's not a problem for using P2SH if older nodes don't recognize them? 03:26:39 * nsh needs to read more about the proposals 03:28:48 adam3us has joined #bitcoin-wizards 03:32:33 P2SH uses the same set of opcodes that have always been around 03:32:45 older nodes might think they're nonstandard, but they'll just not relay them 03:34:19 hmm 03:35:03 andytoshi: older nodes don't even _see_ the interior script opcodes. 03:35:09 They just see some binary data on the stack. 03:35:25 jrmithdobbs has quit 03:36:37 what i meant was, if we can implement p2sh without unduly worrying about old nodes, shouldn't the same logic hold for implementing threshhold sigs? 03:37:10 only if it were implemented in the same way. 03:37:18 right, so only people who want the new functionality are required to run nodes implementing it 03:37:19 * nsh nods 03:37:26 no. ugh 03:37:38 oh 03:37:47 none of these changes are secure unless at least a majority of hashpower enforces them. 03:37:54 ah 03:38:10 right, sorry. 03:38:53 so the concern is that at some point changes to the reference client might not necessarily lead to 50(+whatever)% hashpower realization 03:39:11 jrmithdobbs has joined #bitcoin-wizards 03:39:15 the trickyness in deployment is that if its not done carefully you can end up where the new feature creates a fatal forking bug even if 90% of the hashpower deploys. P2SH shows one way to do it safely. 03:39:18 although there was some talk about disentangling validation from mining the other day... 03:39:38 nsh: I don't even know what you mean there, it's already quite disentangled. 03:39:48 neither do i, never mind... :) 03:39:50 Most "miners" have never participated in validation. :( 03:40:20 i can't remember exactly what was said such that i took that away from it. was probably not paying much attention 03:40:44 in any case, it's not just hashpower. lets say 80% of hashpower were to have deployed p2sh, but most full nodes don't. 03:41:21 that means that later some super majority of the miners might go "hey, lol, we could make a lot more if we rob all those suckers using p2sh and assign all their coins to us" 03:41:45 e.g. if ~everyone doesn't eventually deploy the new rule it leaves the mining incentives potentially out of wack. 03:42:10 a majority of hashpower is necessary for the new thing to be safe, but it's not really sufficient. 03:42:15 hmmm 03:42:48 i'd love if some student made pretty diagrams illustrating all these things graphically for a thesis or something 05:22:46 <_ingsoc> _ingsoc has joined #bitcoin-wizards 05:45:55 is anyone working on the altcoin builder? 05:46:09 otherwise I'm gonna hack one together and at least provide bitcoind/bitcoin-qt (for a neat price) 05:47:00 BlueMatt: I think I read that some russian guy is 05:48:27 hahaha go for it BlueMatt, it'd be awesome if someone on this channel was behind it 05:48:59 we could just quietly slip experiments into other peoples' alts ;) 05:49:17 yea, plus I plan on charging for use of a fork based on anything past 0.8 05:49:31 that way if any alts popup that get to big, we can just step in and shut down their networks with the bloom /0 bug 05:51:34 hmm, this sounds like a slippery slope to actually becoming the illuminati 05:51:42 wait, i thought that was the plan? 05:51:50 yeah, i guess i could live with that :) 05:51:54 nsh: shhhhh 05:51:55 * nsh smiles 05:52:31 BlueMatt, what's required for altcoin builder? 05:52:53 me spending a night and learning bootstrap and then y'all advertising it 05:52:53 i've been semirecruited for a somewhat similar venture, so might be able to help 05:54:20 not sure what you're offering here... 05:54:33 neither do i, it's fine 05:54:41 heh, ok 05:55:21 "Summary: Remote p2p crash via bloom filters" is that the bloom /0 bug? 05:55:35 yup 05:55:40 ah, *reads* 05:55:42 yours truly cant code 05:56:18 ah, it's just a case of iterative failure most of the time 05:56:44 wasn't your fault in coding it, there is one of you and more people than you reviewed it. 05:56:54 crashbugs are the fault of the reviewers. 05:56:55 idd 05:56:55 :P 05:57:04 has there been any exploitation of it? 05:57:12 i don't recall hearing about it until now which is a good sign 05:57:20 you cant really exploit it, just crash the node 05:57:29 that's what i meant, sorry 05:57:34 ideally someone will step up and kill nodes to force upgrades slowly 05:57:45 i'd volunteer, but... 05:57:49 :) 05:57:55 ie kill a few nodes a day until there are no more nodes with the bug running 05:58:47 * nsh nods 05:59:17 they'll turn over eventually. plenty worse vulns out there... 05:59:48 28 million open DNS resolvers on the internet or something 06:09:48 well, sure 06:10:05 not my job to fix the internet though, I just need to fix bitcoin 06:16:40 <_ingsoc> _ingsoc has quit 06:16:52 true 06:18:12 jcorgan has joined #bitcoin-wizards 07:08:35 nsh has quit 07:16:20 i wish there was someone whose job is was to fix the internet 07:16:41 there may be a few of those... 07:23:11 <_ingsoc> _ingsoc has joined #bitcoin-wizards 07:59:24 mappum has joined #bitcoin-wizards 08:02:46 mappum has quit 08:17:00 Hunger- has quit 08:18:01 jcorgan has left #bitcoin-wizards 08:41:47 mapppum has quit 08:42:14 mapppum has joined #bitcoin-wizards 08:43:30 petertodd: I see you changed to SIGHASH_NONE in dust-b-gone, now you need to automatically feed the dust-b-gone data into andy's tool when there is an open cj. 08:43:53 though I expect andy's joining will need to be taught to not strip that signature. :P 08:48:38 andytoshi: ^ PT's dustbegone now generates transactions which spend dust coins (ones with very low value) with the sighash flags set to NONE|ANYONECANPAY if you supported these being submitted to you, you could have people one-pass give away coins to the join. 09:28:12 Hunger- has joined #bitcoin-wizards 09:44:21 jtimon has joined #bitcoin-wizards 10:32:13 Krellan has quit 10:33:03 jtimon has quit 10:33:22 Krellan has joined #bitcoin-wizards 10:50:47 go11111111111 has quit 11:04:23 go11111111111 has joined #bitcoin-wizards 11:16:38 mapppum has quit 11:31:00 nsh has joined #bitcoin-wizards 11:45:14 <_ingsoc> _ingsoc has quit 11:46:45 <_ingsoc> _ingsoc has joined #bitcoin-wizards 11:48:49 go11111111111 has quit 12:27:16 nsh has quit 12:27:16 nsh has joined #bitcoin-wizards 12:36:47 <_ingsoc> _ingsoc has quit 12:37:20 Guest20474 is now known as jarpiaine 12:37:31 jarpiaine is now known as jarpiain 13:15:06 TD has joined #bitcoin-wizards 14:01:03 TD has quit 14:09:55 <_ingsoc> _ingsoc has joined #bitcoin-wizards 14:16:29 <_ingsoc> _ingsoc has quit 14:18:27 <_ingsoc> _ingsoc has joined #bitcoin-wizards 14:42:09 <_ingsoc> _ingsoc has quit 14:44:16 <_ingsoc> _ingsoc has joined #bitcoin-wizards 14:49:15 hnz has quit 14:53:52 hnz has joined #bitcoin-wizards 15:13:16 TD has joined #bitcoin-wizards 15:20:42 Krellan has quit 15:21:01 Krellan has joined #bitcoin-wizards 15:33:24 Krellan has quit 15:39:44 Krellan has joined #bitcoin-wizards 16:16:47 jtimon has joined #bitcoin-wizards 16:22:17 CodeShar_ has joined #bitcoin-wizards 16:22:17 CodeShar_ has quit 16:22:35 CodeShar_ has joined #bitcoin-wizards 16:22:55 CodeShark has quit 16:24:46 CodeShar_ has quit 16:25:06 CodeShark has joined #bitcoin-wizards 16:49:35 <_ingsoc> _ingsoc has quit 16:51:30 <_ingsoc> _ingsoc has joined #bitcoin-wizards 17:13:25 realazthat has quit 17:13:26 iddo has quit 17:14:38 iddo has joined #bitcoin-wizards 17:16:23 realazthat has joined #bitcoin-wizards 17:20:17 Graet has quit 17:20:47 Graet has joined #bitcoin-wizards 17:30:56 gmaxwell: cool, i'll definitely check this out 17:31:05 how much of OP_CHECKSIG do i need to implement to find the hash byte? 17:46:14 ah, i see, none -- the wiki is just worded weirdly 17:54:43 <_ingsoc> _ingsoc has quit 18:00:10 Fistful_of_Coins has quit 18:00:16 Fistful_of_Coins has joined #bitcoin-wizards 18:01:32 Fistful_of_Coins has quit 18:01:48 Fistful_of_LTC has joined #bitcoin-wizards 18:01:52 Fistful_of_LTC has quit 18:01:54 <_ingsoc> _ingsoc has joined #bitcoin-wizards 18:02:09 jtimon has quit 18:03:39 Fistful_of_LTC has joined #bitcoin-wizards 18:03:41 Fistful_of_LTC has quit 18:03:41 Fistful_of_LTC has joined #bitcoin-wizards 18:04:40 Fistful_of_LTC is now known as Fistful_of_Coins 18:14:31 <_ingsoc> _ingsoc has quit 18:16:25 <_ingsoc> _ingsoc has joined #bitcoin-wizards 18:20:37 TD has quit 18:31:36 petertodd: Does this mean I'm updating dust-b-gone? 18:32:35 midnightmagic: latest commit was dec 19 18:33:03 guess so then. 18:33:12 jtimon has joined #bitcoin-wizards 18:41:01 * nsh imagines dust-b-done being advertised as a 1950s style household cleaning product with subtle sexual undertones 18:41:27 *gone 18:57:56 espes__ has joined #bitcoin-wizards 18:59:01 ok, i have updated coinjoin so that it won't strip signatures in the specific case that sighash is NONE|ANYONECANPAY 18:59:25 petertodd: if you want to throw dust in the joiner, you will also have to add an output to the donation address to indicate that it should all go to fees 19:00:16 CodeShark: maybe this gives you a way to preserve your multisig information? if you can make your scriptSigs look like an ordinary NONE|ANYONECANPAY sig then the joiner won't wreck them 19:12:59 Muis has quit 19:13:54 Muis has joined #bitcoin-wizards 19:17:53 (if the scriptSig starts with a PUSHDATA, coinjoin just jumps to the end of the data and reads that byte as a hashType) 19:23:27 joecool has quit 19:35:55 andytoshi: Is there a way I can fire off dust txes into the next coinjoin tx on the command-line? 19:35:58 :-D 19:36:07 I seem to get a lot of dust. It's pretty annoying 19:36:35 midnightmagic: sign it away NONE|ANYONECANPAY 19:37:10 actually, make a transaction paying to the fee address, and sign with NONE|ANYONECANPAY 19:37:17 then submit it as a usual coinjoin transaction 19:37:57 hrm 19:38:08 midnightmagic: the POST form on the coinjoin site is dead simple, you can probably use curl 19:38:13 mappum has joined #bitcoin-wizards 19:38:32 it doesn't report errors in a super simple-to-parse way.. so don't make mistakes ;) 19:38:43 ok 19:38:47 you can read the current status in text https://www.wpsoftware.net/coinjoin/status.php 19:39:23 one moment, i'll pastebin the source of that file so you can see all possible outputs 19:40:07 anyone looked into the network fork? 19:40:20 http://pastebin.com/nYLHDMfM 19:40:31 BlueMatt: i'm reading all the txouts right now, haven't seen any weird ones 19:41:09 there are a few massive txs 19:41:42 eg 057f800f430b22417bdf829d16e78393249634d5409c36b63f058c1a2b54fcf1 19:41:55 is about 64k 19:42:01 which block is this? 19:42:33 block 277596 is 0000000000000001947cc7acbbc9a240517f9ba19c16b4f937795c6b58019fb5 19:42:45 bc.i and blockexplorer are stuck at 277595 19:42:52 bc.i isnt anymore 19:42:54 yea 19:44:56 ;;cjs 19:44:57