| 00:28:58 | maaku: | petertodd sipa: two separate indices under consideration here right? |
| 00:30:00 | maaku: | the TXO MMR which is an append/update structure whose hash root is committed to the coinbase |
| 00:30:25 | maaku: | you append each new output, and update a spent-bit for each input |
| 00:30:45 | maaku: | and a separate, per-block tree of outputs indexed by TXO, right? |
| 00:35:43 | gmaxwell: | 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:40:08 | maaku: | oh i guess it can be the same structure as actual insertion/append order within a block doesn't matter |
| 00:42:33 | maaku: | gmaxwell: for double-spend validation I still think an updatable trie structure is best |
| 00:42:52 | maaku: | but lately I've been thinking about a MMO-like structure for the scriptPubKey index |
| 01:05:13 | gmaxwell: | 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 | gmaxwell: | but not enough to forge signatures. |
| 01:06:22 | nsh: | 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 | nsh: | or at least some clearer idea of to achieveable precision in likely decryption window |
| 01:06:48 | nsh: | *the |
| 01:07:00 | gmaxwell: | 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 | nsh: | (re: POW which turns the distributed computation into ticking for timelock encryption) |
| 01:07:16 | nsh: | right |
| 01:07:53 | gmaxwell: | 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 | justanotheruser: | 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 | justanotheruser: | and speculator |
| 01:08:13 | justanotheruser: | s |
| 01:08:17 | gmaxwell: | But the obvious ways to go about bilding it are super ugly. |
| 01:08:22 | nsh: | mmm |
| 01:09:20 | gmaxwell: | 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 | gmaxwell: | 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 | justanotheruser: | 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 | justanotheruser: | I mean you're saying that's your concenr |
| 01:12:03 | gmaxwell: | 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 | gmaxwell: | which IMO is way more useful than that primecoin crap. :P |
| 01:14:33 | gmaxwell: | 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 | justanotheruser: | gmaxwell: Is there a use for primecoins PoW? No one has been able to explain who wants Cunningham chains |
| 01:15:02 | gmaxwell: | No. There is no use as far as I can tell, except abstract numbertheory navel gazing. |
| 01:15:16 | gmaxwell: | of course, insight comes from unexpected places at times. |
| 01:16:10 | gmaxwell: | plus, I _suspect_ that PoW might be the _only_ really viable way to have truly secure timelock encryption. |
| 01:16:23 | nsh: | * nsh nods |
| 01:16:33 | gmaxwell: | just because the timelock usage alone could never really fund enough processing power to make it secure. |
| 01:17:24 | justanotheruser: | 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 | gmaxwell: | well thats part of the reason I propose encrypting with all intermediate keys. |
| 01:18:07 | gmaxwell: | so the comparison is not one blocks reward, its all rewards between here and now. |
| 01:21:22 | justanotheruser: | hm |
| 01:21:36 | justanotheruser: | gmaxwell: Do you consider any altcoins useful other than namecoin? |
| 01:21:40 | gmaxwell: | You could also strengthen a decenteralized timelock with distributed timelocks. |
| 01:22:16 | nsh: | hmm |
| 01:22:26 | gmaxwell: | 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 | andytoshi: | i bet a way to find cunningham chains quickly would also yield some useful number-theory results |
| 01:23:25 | andytoshi: | so primecoin will become useful exactly when it's destroyed :) |
| 01:23:26 | gmaxwell: | 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 | justanotheruser: | gmaxwell: how do you handle an increasing network power? |
| 01:24:47 | maaku: | justanotheruser: one of many unsolved problems here |
| 01:24:59 | gmaxwell: | hm? no I proposed a solution, but its kludgy. |
| 01:25:13 | justanotheruser: | Or is this the centralized distributed solution with the servers verifying the block time |
| 01:26:02 | maaku: | gmaxwell: it's not on your alt page... |
| 01:26:16 | maaku: | you've got a mechanism for scaling reward |
| 01:26:25 | justanotheruser: | maaku: "POW which turns the distributed computation into ticking for timelock encryption" |
| 01:26:48 | maaku: | but say I want to encrypt something to 2016. how do I know how far to go? |
| 01:27:05 | gmaxwell: | 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 | maaku: | justanotheruser: i'm talking about difficulty adjustment specifically |
| 01:27:42 | gmaxwell: | 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 | maaku: | gmaxwell: ah, i misunderstood. so you break each key into multiple problems? |
| 01:27:55 | justanotheruser: | maaku: your concern is it being found faster with higher network hashpower? |
| 01:28:22 | gmaxwell: | 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 | gmaxwell: | 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 | justanotheruser: | gmaxwell: That involves centralization right? |
| 01:29:05 | gmaxwell: | wtf |
| 01:29:06 | gmaxwell: | no |
| 01:29:36 | gmaxwell: | sorry, I'm just confused as to where you'd get that idea! :P |
| 01:29:42 | justanotheruser: | I was confused by "and 6 of 10 timelock servers" |
| 01:30:04 | gmaxwell: | justanotheruser: oh I thought you were talking about me explaining how difficulty adjustment works. |
| 01:30:20 | gmaxwell: | that was just a comment on 17:21 < gmaxwell> You could also strengthen a decenteralized timelock with distributed timelocks. |
| 01:30:26 | gmaxwell: | and yes, its not decenteralized. |
| 01:30:49 | justanotheruser: | I see |
| 01:31:08 | gmaxwell: | But, e.g. decenteralized + distributed OR lots-more-decenteralized doesn't seem too bad to me. |
| 01:31:36 | maaku: | 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 | justanotheruser: | 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 | gmaxwell: | maaku: well you can in my example, you just encrypt using x=0 y={0..expected time in the future} |
| 01:32:30 | gmaxwell: | justanotheruser: huh? there is no verifying the blockchain at all. |
| 01:32:51 | justanotheruser: | brb |
| 01:33:40 | maaku: | 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 | maaku: | but it could just as easily be built to do x=0 y=(0.. some large amount) |
| 01:34:06 | andytoshi: | maaku: presumably they'd not do this, prefering to get the block reward |
| 01:34:13 | gmaxwell: | maaku: yes, correct. Though if they did that they'd not get the block reward. |
| 01:34:19 | andytoshi: | i don't think this is safe against an asic explosion |
| 01:34:43 | maaku: | so they give up 1 block reward in order to destroy entirely the utility of the timelock encryption |
| 01:35:32 | gmaxwell: | 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 | gmaxwell: | 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 | maaku: | 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 | maaku: | Then you can use it to say "I encrypt this until the network expends X computational cycles" |
| 01:37:07 | gmaxwell: | 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 | maaku: | lack of control over tiem is precisly my point... |
| 01:37:27 | gmaxwell: | you can achieve that in the multilevel scheme by threshold encrypting. |
| 01:38:34 | gmaxwell: | basically the multilevel scheme allows you basically freedom between choosing absolute work, and absolute time (but with race ahead risk) |
| 01:39:51 | gmaxwell: | 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 | andytoshi: | [unrelated] new optimization of koblitz curve optimization: http://eprint.iacr.org/2012/519 |
| 01:41:40 | maaku: | gmaxwell: but presumably you reveal which ones you encrypt against right? (to avoid combinatorial explosion in decrypting) |
| 01:42:03 | maaku: | so someone need only "work ahead" those keys to decrypt |
| 01:42:06 | gmaxwell: | 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 | maaku: | (and if they're a miner they can later reuse that work for the subsidy) |
| 01:42:35 | gmaxwell: | No, the work can't be reused. |
| 01:42:53 | gmaxwell: | 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 | gmaxwell: | 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 | maaku: | 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 | gmaxwell: | 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 | gmaxwell: | (a distinguished point is either the solution to the current problem, or some 'near miss' based on some arbritary criteria) |
| 01:47:57 | gmaxwell: | 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 | gmaxwell: | 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 | gmaxwell: | 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 | gmaxwell: | (at least not useful for mining) |
| 01:53:33 | gmaxwell: | 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 | andytoshi: | oh, damn |
| 01:54:12 | andytoshi: | also it's 2014 :P |
| 01:57:15 | nsh: | let's split the difference for another couple of days eh? :) |
| 02:12:10 | nsh: | *sigh* |
| 02:12:15 | nsh: | https://www.openssl.org/ <-- compromised |
| 02:13:00 | gmaxwell: | * gmaxwell not going to load a compromised site. |
| 02:13:21 | nsh: | just says "TurkGuvenligiTurkSec Was Here @turkguvenligi + we love openssl _" |
| 02:13:26 | nsh: | no html. but good policy :) |
| 02:17:37 | justanotheruser: | In blockchain time It's already April 2014 |
| 02:32:37 | gmaxwell: | 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 | nsh: | what's at the centre? |
| 02:33:46 | gmaxwell: | 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 | gmaxwell: | 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 | gmaxwell: | 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 | nsh: | hmmm |
| 02:36:09 | gmaxwell: | 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 | gmaxwell: | 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 | nsh: | i'm not sure that's too much of a problem, necessarily |
| 02:45:43 | gmaxwell: | 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 | gmaxwell: | how about a different one, how about a semi-anonymous quorum timelock. |
| 02:48:43 | gmaxwell: | 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 | nsh: | right |
| 02:49:34 | gmaxwell: | 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 | gmaxwell: | 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 | gmaxwell: | ignoring how you'd go about doing that— how would this break down? |
| 02:52:16 | nsh: | i think i'm lost |
| 02:53:05 | warren: | http://www.openssl.org/ <--- sigh |
| 02:53:07 | gmaxwell: | 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 | nsh: | sure |
| 02:53:42 | maaku: | if you love openssl you wouldn't do that... |
| 02:54:37 | gmaxwell: | nsh: just information theoretically, if M of the N leave, but M |
| 02:54:44 | nsh: | (maybe they love openssl, but not as much as fleeting noteriety in dubious social circles) |
| 02:55:09 | nsh: | gmaxwell, can they repopulate without revelaing the secret itself though? |
| 02:55:11 | nsh: | that seems less obvious |
| 02:55:13 | gmaxwell: | (after all, they could just recover the whole key and than split it up again) |
| 02:55:23 | nsh: | depends on the sharing scheme i guess |
| 02:56:08 | gmaxwell: | 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 | nsh: | okay |
| 02:56:21 | maaku: | 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 | gmaxwell: | 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: | * nsh nods |
| 02:57:09 | gmaxwell: | 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 | nsh: | yes, that makes sense |
| 02:57:36 | gmaxwell: | Though I also think its likely that there is a less horriffic way than invoking SMPC. |
| 02:57:36 | nsh: | modulo some computational/bandwidth costs |
| 02:57:45 | nsh: | * nsh nods |
| 02:58:24 | gmaxwell: | seems to me that you could get a pretty darn robust timelock this way. |
| 02:58:39 | gmaxwell: | you just need some sybil resistant way to select players. |
| 02:59:06 | nsh: | i'm missing bits still. how do you go from N of M secrets (with dropouts and repopulation) to timelock? |
| 02:59:11 | gmaxwell: | And then you can do {magic} to continually redistribute the key so that people coming and going don't break you. |
| 02:59:31 | gmaxwell: | 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 | nsh: | backed by fidelity bonds? |
| 03:00:03 | gmaxwell: | 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 | nsh: | hmmm. i don't know how easy it would be to find N people who would reliably publish on schedule |
| 03:01:11 | gmaxwell: | 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 | gmaxwell: | nsh: well its not people, of course, it's people's software. :P |
| 03:01:28 | nsh: | sure :) |
| 03:02:49 | nsh: | 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 | gmaxwell: | 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 | nsh: | the general principle of "topping up" the multiparty pool seems a pretty useful one |
| 03:04:20 | gmaxwell: | 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 | nsh: | but perhaps open to sneaky people who (being coerced to) fake absence until a threshold is reached |
| 03:05:33 | nsh: | 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 | gmaxwell: | 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 | nsh: | right |
| 03:06:44 | gmaxwell: | 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 | nsh: | right |
| 03:07:52 | gmaxwell: | I guess one problem is being at all confident that "there is anything in the box". |
| 03:08:40 | gmaxwell: | 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 | nsh: | heh, sounds like religion |
| 03:08:53 | nsh: | :) |
| 03:09:26 | gmaxwell: | 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 | gmaxwell: | ohhh I found a problem. |
| 03:09:43 | gmaxwell: | A old majority could fork a past state. |
| 03:09:52 | nsh: | (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 | nsh: | fork? |
| 03:10:05 | nsh: | s/problem/building/ # heh.. |
| 03:10:33 | gmaxwell: | 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 | nsh: | ah, right |
| 03:11:28 | gmaxwell: | so that would bugger the timelock case where you can't usefully rotate the keys as topups happen. |
| 03:11:45 | nsh: | well, there's no way around that i can think of that doesn't require a T3rdP |
| 03:12:03 | gmaxwell: | 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 | nsh: | right |
| 03:12:39 | nsh: | 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 | gmaxwell: | and tada, if we had scalable threshold signatures in bitcoin we wouldn't need anything else for the p2pool case. |
| 03:13:35 | gmaxwell: | 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 | nsh: | (are there any threads/mailpost/notes on scalable threshold signatures?) |
| 03:14:23 | gmaxwell: | 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 | gmaxwell: | basically for the N of N you can just directly compose the public keys.. and to sign directly compose the signatures. |
| 03:15:00 | nsh: | mmm, right |
| 03:15:23 | gmaxwell: | 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 | gmaxwell: | 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 | nsh: | hmmm |
| 03:16:53 | gmaxwell: | esp because other limitations you can generally work around by invoking multisig. |
| 03:17:23 | gmaxwell: | e.g. how coinswap makes any complicated protocol look like a multisig. :P |
| 03:17:26 | nsh: | 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 | gmaxwell: | correct. |
| 03:17:40 | nsh: | right |
| 03:17:47 | nsh: | we definitely need to have a script-extension playground |
| 03:17:52 | gmaxwell: | it's a little tricky to make it backwards compatible. you just can't add a OP_NEWCHECKSIG |
| 03:17:53 | nsh: | that would be very useufl |
| 03:18:28 | gmaxwell: | e.g. it would need to be somehting like a P2SH style change. |
| 03:18:45 | nsh: | what does P2SH style mean? |
| 03:19:17 | nsh: | a generalization of payability? |
| 03:19:37 | gmaxwell: | 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 | gmaxwell: | e.g. this transaction is only valid if the newsignature fails. |
| 03:20:21 | nsh: | hmm, and this shoots other places than your (transaction sender's) own foot? |
| 03:20:41 | gmaxwell: | 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 | nsh: | oh, i see |
| 03:21:27 | gmaxwell: | 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 | gmaxwell: | but no biggie, just hide the whole new script from old nodes completely. |
| 03:21:43 | nsh: | * nsh nods |
| 03:22:20 | nsh: | so it's as solved as backwards compatible P2SH, at least |
| 03:22:43 | gmaxwell: | 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 | nsh: | hmm |
| 03:25:07 | nsh: | 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 | nsh: | it's not a problem for using P2SH if older nodes don't recognize them? |
| 03:26:39 | nsh: | * nsh needs to read more about the proposals |
| 03:32:33 | andytoshi: | P2SH uses the same set of opcodes that have always been around |
| 03:32:45 | andytoshi: | older nodes might think they're nonstandard, but they'll just not relay them |
| 03:34:19 | nsh: | hmm |
| 03:35:03 | gmaxwell: | andytoshi: older nodes don't even _see_ the interior script opcodes. |
| 03:35:09 | gmaxwell: | They just see some binary data on the stack. |
| 03:36:37 | nsh: | 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 | gmaxwell: | only if it were implemented in the same way. |
| 03:37:18 | nsh: | right, so only people who want the new functionality are required to run nodes implementing it |
| 03:37:19 | nsh: | * nsh nods |
| 03:37:26 | gmaxwell: | no. ugh |
| 03:37:38 | nsh: | oh |
| 03:37:47 | gmaxwell: | none of these changes are secure unless at least a majority of hashpower enforces them. |
| 03:37:54 | nsh: | ah |
| 03:38:10 | nsh: | right, sorry. |
| 03:38:53 | nsh: | so the concern is that at some point changes to the reference client might not necessarily lead to 50(+whatever)% hashpower realization |
| 03:39:15 | gmaxwell: | 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 | nsh: | although there was some talk about disentangling validation from mining the other day... |
| 03:39:38 | gmaxwell: | nsh: I don't even know what you mean there, it's already quite disentangled. |
| 03:39:48 | nsh: | neither do i, never mind... :) |
| 03:39:50 | gmaxwell: | Most "miners" have never participated in validation. :( |
| 03:40:20 | nsh: | 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 | gmaxwell: | 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 | gmaxwell: | 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 | gmaxwell: | e.g. if ~everyone doesn't eventually deploy the new rule it leaves the mining incentives potentially out of wack. |
| 03:42:10 | gmaxwell: | a majority of hashpower is necessary for the new thing to be safe, but it's not really sufficient. |
| 03:42:15 | nsh: | hmmm |
| 03:42:48 | nsh: | i'd love if some student made pretty diagrams illustrating all these things graphically for a thesis or something |
| 05:45:55 | BlueMatt: | is anyone working on the altcoin builder? |
| 05:46:09 | BlueMatt: | otherwise I'm gonna hack one together and at least provide bitcoind/bitcoin-qt (for a neat price) |
| 05:47:00 | justanotheruser: | BlueMatt: I think I read that some russian guy is |
| 05:48:27 | andytoshi: | hahaha go for it BlueMatt, it'd be awesome if someone on this channel was behind it |
| 05:48:59 | andytoshi: | we could just quietly slip experiments into other peoples' alts ;) |
| 05:49:17 | BlueMatt: | yea, plus I plan on charging for use of a fork based on anything past 0.8 |
| 05:49:31 | BlueMatt: | 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 | andytoshi: | hmm, this sounds like a slippery slope to actually becoming the illuminati |
| 05:51:42 | nsh: | wait, i thought that was the plan? |
| 05:51:50 | andytoshi: | yeah, i guess i could live with that :) |
| 05:51:54 | BlueMatt: | nsh: shhhhh |
| 05:51:55 | nsh: | * nsh smiles |
| 05:52:31 | nsh: | BlueMatt, what's required for altcoin builder? |
| 05:52:53 | BlueMatt: | me spending a night and learning bootstrap and then y'all advertising it |
| 05:52:53 | nsh: | i've been semirecruited for a somewhat similar venture, so might be able to help |
| 05:54:20 | BlueMatt: | not sure what you're offering here... |
| 05:54:33 | nsh: | neither do i, it's fine |
| 05:54:41 | BlueMatt: | heh, ok |
| 05:55:21 | nsh: | "Summary: Remote p2p crash via bloom filters" is that the bloom /0 bug? |
| 05:55:35 | BlueMatt: | yup |
| 05:55:40 | nsh: | ah, *reads* |
| 05:55:42 | BlueMatt: | yours truly cant code |
| 05:56:18 | nsh: | ah, it's just a case of iterative failure most of the time |
| 05:56:44 | gmaxwell: | wasn't your fault in coding it, there is one of you and more people than you reviewed it. |
| 05:56:54 | gmaxwell: | crashbugs are the fault of the reviewers. |
| 05:56:55 | nsh: | idd |
| 05:56:55 | gmaxwell: | :P |
| 05:57:04 | nsh: | has there been any exploitation of it? |
| 05:57:12 | nsh: | i don't recall hearing about it until now which is a good sign |
| 05:57:20 | BlueMatt: | you cant really exploit it, just crash the node |
| 05:57:29 | nsh: | that's what i meant, sorry |
| 05:57:34 | BlueMatt: | ideally someone will step up and kill nodes to force upgrades slowly |
| 05:57:45 | nsh: | i'd volunteer, but... |
| 05:57:49 | nsh: | :) |
| 05:57:55 | BlueMatt: | ie kill a few nodes a day until there are no more nodes with the bug running |
| 05:58:47 | nsh: | * nsh nods |
| 05:59:17 | nsh: | they'll turn over eventually. plenty worse vulns out there... |
| 05:59:48 | nsh: | 28 million open DNS resolvers on the internet or something |
| 06:09:48 | BlueMatt: | well, sure |
| 06:10:05 | BlueMatt: | not my job to fix the internet though, I just need to fix bitcoin |
| 06:16:52 | nsh: | true |
| 07:16:20 | maaku: | i wish there was someone whose job is was to fix the internet |
| 07:16:41 | BlueMatt: | there may be a few of those... |
| 08:18:01 | jcorgan: | jcorgan has left #bitcoin-wizards |
| 08:43:30 | gmaxwell: | 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 | gmaxwell: | though I expect andy's joining will need to be taught to not strip that signature. :P |
| 08:48:38 | gmaxwell: | 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. |
| 12:37:20 | Guest20474: | Guest20474 is now known as jarpiaine |
| 12:37:31 | jarpiaine: | jarpiaine is now known as jarpiain |
| 17:30:56 | andytoshi: | gmaxwell: cool, i'll definitely check this out |
| 17:31:05 | andytoshi: | how much of OP_CHECKSIG do i need to implement to find the hash byte? |
| 17:46:14 | andytoshi: | ah, i see, none -- the wiki is just worded weirdly |
| 18:04:40 | Fistful_of_LTC: | Fistful_of_LTC is now known as Fistful_of_Coins |
| 18:31:36 | midnightmagic: | petertodd: Does this mean I'm updating dust-b-gone? |
| 18:32:35 | andytoshi: | midnightmagic: latest commit was dec 19 |
| 18:33:03 | midnightmagic: | guess so then. |
| 18:41:01 | nsh: | * nsh imagines dust-b-done being advertised as a 1950s style household cleaning product with subtle sexual undertones |
| 18:41:27 | nsh: | *gone |
| 18:59:01 | andytoshi: | ok, i have updated coinjoin so that it won't strip signatures in the specific case that sighash is NONE|ANYONECANPAY |
| 18:59:25 | andytoshi: | 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 | andytoshi: | 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:17:53 | andytoshi: | (if the scriptSig starts with a PUSHDATA, coinjoin just jumps to the end of the data and reads that byte as a hashType) |
| 19:35:55 | midnightmagic: | andytoshi: Is there a way I can fire off dust txes into the next coinjoin tx on the command-line? |
| 19:35:58 | midnightmagic: | :-D |
| 19:36:07 | midnightmagic: | I seem to get a lot of dust. It's pretty annoying |
| 19:36:35 | maaku: | midnightmagic: sign it away NONE|ANYONECANPAY |
| 19:37:10 | maaku: | actually, make a transaction paying to the fee address, and sign with NONE|ANYONECANPAY |
| 19:37:17 | maaku: | then submit it as a usual coinjoin transaction |
| 19:37:57 | midnightmagic: | hrm |
| 19:38:08 | andytoshi: | midnightmagic: the POST form on the coinjoin site is dead simple, you can probably use curl |
| 19:38:32 | andytoshi: | it doesn't report errors in a super simple-to-parse way.. so don't make mistakes ;) |
| 19:38:43 | midnightmagic: | ok |
| 19:38:47 | andytoshi: | you can read the current status in text https://www.wpsoftware.net/coinjoin/status.php |
| 19:39:23 | andytoshi: | one moment, i'll pastebin the source of that file so you can see all possible outputs |
| 19:40:07 | BlueMatt: | anyone looked into the network fork? |
| 19:40:20 | andytoshi: | http://pastebin.com/nYLHDMfM |
| 19:40:31 | andytoshi: | BlueMatt: i'm reading all the txouts right now, haven't seen any weird ones |
| 19:41:09 | andytoshi: | there are a few massive txs |
| 19:41:42 | andytoshi: | eg 057f800f430b22417bdf829d16e78393249634d5409c36b63f058c1a2b54fcf1 |
| 19:41:55 | andytoshi: | is about 64k |
| 19:42:01 | BlueMatt: | which block is this? |
| 19:42:33 | andytoshi: | block 277596 is 0000000000000001947cc7acbbc9a240517f9ba19c16b4f937795c6b58019fb5 |
| 19:42:45 | andytoshi: | bc.i and blockexplorer are stuck at 277595 |
| 19:42:52 | BlueMatt: | bc.i isnt anymore |
| 19:42:54 | BlueMatt: | yea |
| 19:44:56 | maaku: | ;;cjs |
| 19:44:57 | gribble: | Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one. |
| 19:46:25 | andytoshi: | i've found 2 now which exceed 64k, which makes bash whine at me..idk if 64k is a magic number for anything else |
| 19:46:34 | andytoshi: | make that 3 |
| 19:46:42 | andytoshi: | 5 |
| 20:10:22 | justanotheruser: | Whats all this I'm hearing about 277596 |
| 20:15:20 | nsh: | it's the new magic number. three has retired |
| 20:29:38 | Emcy: | whats interesting about that block |
| 20:33:53 | andytoshi: | Emcy: on #bitcoin-dev they are discussing it, appears to be just a communication problem around an ordinary reorg |
| 20:35:10 | BlueMatt: | Emcy: not even communication, just a reorg |
| 20:41:12 | midnightmagic: | andytoshi: Hey I think your .onion hidden site doesn't work with the /coinjoin/ action. nginx says file not found. |
| 20:42:24 | andytoshi: | oh, thanks |
| 20:42:53 | andytoshi: | fixed |
| 20:43:11 | Emcy: | andytoshi i got it |
| 20:43:24 | Emcy: | big reorg tho |
| 20:44:00 | Emcy: | that guy limiting his blocks to 32kb wtf |
| 20:51:57 | andytoshi: | fyi there is a new paper on bitcoin mining vulnerabilities out: http://eprint.iacr.org/2013/868.pdf |
| 20:52:07 | andytoshi: | which we may get swamped by over the next few days |
| 20:52:27 | andytoshi: | it starts by assuming an attacker can communicate with every miner faster than they can communicate with each other |
| 20:53:39 | andytoshi: | the top of page 3 invokes the sunk cost fallacy as some sort of determiner of miner behavior, so i stopped reading there |
| 20:54:04 | BlueMatt: | so...same assumption as many other attacks on mining stuff... |
| 20:59:55 | Emcy: | isnt the biggest predictor of miner behavior the fire and forget factor |
| 21:03:43 | BlueMatt: | in other words we need to further encourage mining pool peering even though it already exists pretty extensively for the largest ones afaiu |
| 21:05:03 | Emcy: | why? it reorged fine |
| 21:05:16 | BlueMatt: | re: the paper, not the reorg |
| 21:05:35 | Emcy: | oh |
| 21:23:51 | midnightmagic: | lol |
| 21:25:09 | phantomcircuit: | BlueMatt, re: super old stale block |
| 21:25:22 | phantomcircuit: | some mining hardware fails to flush when the network finds a new block |
| 21:25:43 | phantomcircuit: | so they can submit shares for minutes and minutes after the pool has updated |
| 21:25:56 | nsh: | sacrifices to the fallen CPU miners |
| 21:26:06 | nsh: | pour out some hashes for your homies |
| 21:26:07 | phantomcircuit: | smarter pools publish the block on the off chance it's accepted |
| 21:34:15 | midnightmagic: | lol |
| 21:38:23 | BlueMatt: | phantomcircuit: does that effect the paper or just random statement of dumb mining hardware? |
| 21:38:43 | phantomcircuit: | BlueMatt, i was commenting on the recent fork |
| 21:38:51 | BlueMatt: | ahh |
| 21:38:58 | BlueMatt: | Im not even sure this is the case here |
| 21:39:38 | phantomcircuit: | BlueMatt, just the terrible operator with his terrible connection |
| 21:40:00 | phantomcircuit: | also the stuff about chinese internet beign terrible is true but im sure he can afford a real connection |
| 21:40:06 | phantomcircuit: | it doesn't even have to be that big |
| 21:40:49 | midnightmagic: | andytoshi: Okay, I'm attempting to submit a transaction to the coinjoin interface consisting of 0.00000004 btc, with the sum being completely "donated" to the fee address. It's telling me my inputs are not valid, usually meaning they've already been spent. |
| 21:42:08 | BlueMatt: | he limits his blocks so he can relay with 1 udp packet.... |
| 21:42:19 | BlueMatt: | I mean thats just overkill no matter how shitty your connection is... |
| 21:42:25 | phantomcircuit: | that's just sillyness |
| 21:42:59 | phantomcircuit: | im sure he has the bandwidth but his latency is probably terrible |
| 21:43:12 | phantomcircuit: | also i wonder if he remembers to retransmit |
| 21:43:26 | phantomcircuit: | im guessing no |
| 21:44:11 | BlueMatt: | probably not |
| 21:50:45 | andytoshi: | midnightmagic: can you msg me the tx? |
| 21:51:35 | andytoshi: | or just the input ids? |
| 22:12:14 | midnightmagic: | andytoshi: sure |
| 22:25:53 | nsh: | nsh is now known as nshbit |
| 22:31:05 | nshbit: | nshbit is now known as nshchawmp |