| 00:51:38 | Guest43303: | Guest43303 is now known as amiller |
| 00:52:22 | amiller: | woot, i got my bitcoin paper into oakland, the fancy academic conference for bigshots |
| 00:53:47 | petertodd: | amiller: +1 |
| 00:54:17 | amiller: | i'm up there with matt green's student now :o |
| 01:06:43 | andytoshi: | amiller: nice! |
| 01:07:21 | amiller: | it's the one about having "storage" as a beneficial side effect from a modified proofofwork puzzle |
| 01:08:23 | petertodd: | amiller: oh, you finally wrote a paper about forcing storage as part of pow? |
| 01:08:32 | amiller: | yeah |
| 01:08:52 | amiller: | in the paper it's marketed as a way of getting like public good benefit, which i don't actually think makes any sense |
| 01:09:00 | petertodd: | amiller: heh, I hope you were clear it wasn't necessarily the most original idea :) |
| 01:09:04 | petertodd: | haha |
| 01:09:27 | petertodd: | (though maybe you did come up with it first!) |
| 01:09:29 | amiller: | well to be fair i've been working on this idea for 2.5 years |
| 01:09:42 | amiller: | it's up there in gmaxwell's crazy-shit wiki page |
| 01:09:43 | petertodd: | yeah, that's fine then |
| 01:09:56 | petertodd: | gmaxwell's only from a year ago - you've got me beat too for sure |
| 01:12:48 | amiller: | this was our review submitted version http://socrates1024.s3.amazonaws.com/permacoin.pdf |
| 01:13:17 | amiller: | btw i'm still waiting on coauthors for that mixcoin paper to finish responding to that forum post |
| 01:13:43 | amiller: | but regarding citing you for fidelity bonds, i absolutely had cited you originally and someone else commented it out by mistake |
| 01:14:06 | amiller: | it is a pet peeve of mine to take seriously citing bitcointalk posts etc properly |
| 01:15:39 | petertodd: | no worries |
| 01:16:39 | petertodd: | it'll be handy having your permacoin paper, because now I can formally cite it as why you'd want that to make sure blockchain data gets preserved :) |
| 01:18:44 | amiller: | right on, that's the only actual use i ever had in mind for this |
| 01:19:25 | amiller: | my coauthors thought that storing archival data for make great public benefit was good for marketing, and since it worked, good. |
| 01:24:05 | petertodd: | yeah, and technically, that's exactly what you'd be doing with blockchain data anyway |
| 02:12:46 | justanotheruser: | Any major flaws with mastercoin? |
| 02:16:51 | maaku_: | justanotheruser: yes? |
| 02:17:07 | justanotheruser: | maaku_: could you name a few? |
| 02:17:21 | justanotheruser: | As it always is with bitcointalk, I can only find positive opinions |
| 02:17:49 | maaku_: | justanotheruser: http://lmgtfy.com/?q=mastercoin+flaws |
| 02:18:12 | petertodd: | justanotheruser: what maaku said - Peter Todd - Chief Scientist - Mastercoin |
| 02:19:24 | justanotheruser: | petertodd: so you think mastercoin has major flaws that are fixable then? Or it has major flaws that aren't major enough to make it unusable |
| 02:19:52 | maaku_: | sorry to be snarky justanotheruser, but mastercoin - what's in the whitepaper, not what peter will hopefully make it into - has been ridiculed pretty much since its inception... |
| 02:20:22 | petertodd: | justanotheruser: the former, and remember I'm not convinced that these "v2" coins necessarily solve real business problems - the very idea of what mastercoin is trying to solve may prove to be flawed |
| 02:20:47 | maaku_: | the chief problem probably being lack of any kind of SPV support |
| 02:20:54 | justanotheruser: | petertodd: oh, so it is unknown whether it will be fixed |
| 02:21:12 | petertodd: | maaku_: yes, although to what degree SPV is a good thing is itself unknown |
| 02:21:31 | shesek: | petertodd, what do you mean by that? |
| 02:21:39 | petertodd: | justanotheruser: correct - I'm working on reviewing what specs they have right now |
| 02:21:49 | maaku_: | petertodd: i hope you're not on the hook for making its usd-parity voodoo work |
| 02:22:24 | petertodd: | shesek: SPV is fundementally outsourcing trust to others, on the hope that economic incentives make those people (miners) trustworthy. it's unknown to what degree that's actually a stable state of affairs |
| 02:22:44 | petertodd: | maaku_: heh, I've got a lot of finance to learn... |
| 02:23:14 | petertodd: | maaku_: fortunately for economics, "work" is often a relative term |
| 02:24:16 | shesek: | miners? what trust does an spv node put on miners that a non-spv node doesn't? |
| 02:24:34 | petertodd: | shesek: non-spv nodes verify everything, so miners can't lie to them |
| 02:24:48 | petertodd: | shesek: spv will accept invalid blocks happily remember |
| 02:25:49 | justanotheruser: | Does the invalid block get propogated to them? Or is the assumption that the miner is directly talking to them? |
| 02:25:59 | maaku_: | justanotheruser: does it matter? |
| 02:26:01 | shesek: | well, some subset of invalid, it still requires the proof of work and transactions to be valid |
| 02:26:05 | justanotheruser: | maaku_: yes |
| 02:26:13 | maaku_: | justanotheruser: why? |
| 02:26:27 | justanotheruser: | maaku_: because I am curious which assumption this attack makes |
| 02:26:43 | maaku_: | it's the same assumption is what i'm saying |
| 02:26:50 | petertodd: | justanotheruser: who's to say it'd be an attack? it could be "we've decided to change the rules because it's better for us" |
| 02:26:51 | maaku_: | how do you know the identity of anyone you are connected to? |
| 02:27:04 | shesek: | (I'm not 100% familiar with how spv node works exactly, so I might be wrong) |
| 02:27:16 | petertodd: | shesek: you should be :) |
| 02:27:39 | justanotheruser: | maaku_: you don't, but to specifically attack an individual you would have to connect to him or have the block propogate to them (which I assume spv clients might do, I don't understand spv that well) |
| 02:28:35 | justanotheruser: | Do spv clients propagate block headers themselves? |
| 02:28:47 | maaku_: | they shouldn't |
| 02:28:49 | shesek: | petertodd, yeah, I probably should ) afaik, an spv node does validate the proof of work for the blocks, the transactions he's interested about and that they're part of the block's merkle tree |
| 02:28:59 | shesek: | * :) |
| 02:29:04 | maaku_: | but i wouldn't trust people not to do stupid things... |
| 02:29:38 | shesek: | in what ways not validating everything can it be practically abused? |
| 02:30:37 | shesek: | s/it be/be |
| 02:30:51 | justanotheruser: | petertodd: any ideas on stopping the doublespend? |
| 02:31:52 | petertodd: | justanotheruser: they should propagate headers, but that only lets you know about what blocks exist, not if they're valid |
| 02:32:14 | petertodd: | shesek: correct, and remember that in practice they usually don't validate much of anything about transactions |
| 02:32:46 | petertodd: | shesek: like I said, it's a *social* dynamic thing, because it makes it easy for miners to change the rules |
| 02:32:54 | petertodd: | justanotheruser: ? |
| 02:33:16 | justanotheruser: | petertodd: "It looks like the only way to accept matercoins in secure fashion is to do a 'purity check' on an address: make sure that there are no 'weird' transactions in its history (recursively: if address A receives from B, you also need to scan history of B, and history of addresses B receives transactions from, up to the exodus). But tool like this doesn't exist (as far as I know), so there is no way to receive masterc |
| 02:33:32 | justanotheruser: | so just do this purity check? |
| 02:33:41 | petertodd: | justanotheruser: you're cut off "so there is no way to receive masterc..." |
| 02:33:50 | justanotheruser: | ive mastercoins in a secure fashion." |
| 02:34:10 | shesek: | they could send blocks that contains invalid transaction and have the block accepted by spv nodes that aren't looking at those specific transactions, but spv nodes that do care about the invalid transaction would still reject it, no? |
| 02:34:59 | petertodd: | justanotheruser: mastercoin is its own TXO set, so the only way to know if a mastercoin TXO is real is to have all MSC transactions (could be cut down to only some MSC tx's with design changes) |
| 02:35:19 | petertodd: | justanotheruser: that *is* true of bitcoin too remember, like I say, SPV nodes are trusting miners to validate for them |
| 02:35:40 | justanotheruser: | petertodd: yes, I didn't really understand his complaint |
| 02:35:51 | petertodd: | shesek: sure, but them rejecting those transactions does what? absolutely nothing - you don't know that they rejected anything! |
| 02:36:10 | petertodd: | shesek: (see fraud proofs) |
| 02:36:21 | justanotheruser: | it seems you can just start at the exodus address and look at all msc tx to find doublespends in the same way you do with bitcoin |
| 02:36:25 | shesek: | right, but the miners still can't anyone to accept invalid transactions - only blocks that contain invalid transaction they aren't aware of |
| 02:36:29 | petertodd: | justanotheruser: the gist of it is right, but the terminology is weird |
| 02:36:47 | petertodd: | shesek: a transaction may be invalid because a prior transaction input was invalid |
| 02:36:48 | justanotheruser: | petertodd: how is my terminology weird? |
| 02:37:07 | petertodd: | justanotheruser: "purity" |
| 02:37:33 | justanotheruser: | petertodd: I am quoting the person I quoted earlier. By purity I mean lack of doublespends |
| 02:37:48 | petertodd: | justanotheruser: sure, we'd probably say "correctness" |
| 02:37:53 | justanotheruser: | ok |
| 02:39:05 | petertodd: | anyway, CCoins shares the same issue, but there the trusted nature of the issuer is inherent, and it's easy to do optimizations like have the issuer sign a TXO set with their signature so you only have to get recent history |
| 02:40:13 | petertodd: | I was just talking to killerstorm about applying MMR TXO commitment schemes to colored coins actually; good way to ensure that implementations are in consensus too |
| 02:40:25 | justanotheruser: | petertodd: so centralize it? |
| 02:41:39 | petertodd: | justanotheruser: you could do that; with ccoins the centralization already exists so it's not a big deal; msc is trying features above and beyond that though |
| 02:44:02 | justanotheruser: | petertodd: do you work for mastercoin, or are you just doing this for fun? |
| 02:44:14 | petertodd: | justanotheruser: I'm their chief scientist |
| 02:44:42 | petertodd: | justanotheruser: (paid position) |
| 02:45:05 | justanotheruser: | petertodd: okay cool. How many people work for it (if you know)? |
| 02:45:23 | justanotheruser: | it's kindof weird to say work for mastercoin because it could mean two things |
| 02:45:42 | petertodd: | half-dozen paid devs IIRC? (dunno exact numbers) |
| 02:45:46 | petertodd: | ? |
| 02:45:57 | justanotheruser: | cool |
| 02:51:52 | phantomcircuit: | petertodd, ethereum is neat |
| 02:51:57 | justanotheruser: | petertodd: killerstorms complaints seem to based around things that can be fixed. What are some big problems that might not be fixable |
| 02:51:58 | phantomcircuit: | it'll be lots of fun to break it horribly |
| 02:52:07 | justanotheruser: | phantomcircuit: heh |
| 02:52:52 | justanotheruser: | phantomcircuit: It seems like it will require someone to mine one really big loop to end the currency. |
| 02:53:20 | justanotheruser: | Or some more complicated attack will RAT every ethereum users HD |
| 02:53:36 | petertodd: | phantomcircuit: someone was asking me about how easy it'd be to hire a team to do ethereum right, and my advice was to save your money for now and let people break it for free so we'll know *all* the things wrong with it :P |
| 02:54:16 | phantomcircuit: | sound advice |
| 02:54:16 | petertodd: | justanotheruser: I don't really know the answere to that question yet; anything *might* not be fixable |
| 02:55:07 | petertodd: | justanotheruser: see the #bitcoin-dev discussion about how I managed fork coinbase's bitcoin-ruby implementation twice in an hour |
| 02:55:23 | petertodd: | justanotheruser: consensus is hard enough as it is... |
| 02:56:57 | justanotheruser: | petertodd: their rules were different from the rest of the network? |
| 02:57:15 | petertodd: | justanotheruser: bitcoin-ruby re-implements EvalScript()... |
| 02:58:08 | justanotheruser: | petertodd: and their code didn't exactly align with the rest of the network? |
| 02:58:26 | phantomcircuit: | justanotheruser, it's nearly impossible to get it right |
| 02:58:39 | phantomcircuit: | they got lucky that they rejected valid transactions rather than the other way around |
| 02:58:48 | justanotheruser: | phantomcircuit: really? Because of all the nuances of different languages? |
| 02:58:56 | petertodd: | I genuinely believe it's a harder problem than safety critical aerospace software development. |
| 02:59:08 | justanotheruser: | huh |
| 02:59:25 | justanotheruser: | I guess I am taking satoshi for granted then |
| 02:59:45 | petertodd: | justanotheruser: getting version #1 done is easy, making version #2 identical is a nightmare |
| 03:00:31 | justanotheruser: | petertodd: has there ever been a case where compiling to a different OS or using different flags broke the consensus? |
| 03:00:42 | petertodd: | justanotheruser: yes |
| 03:00:55 | petertodd: | justanotheruser: that's why we ship leveldb with the source |
| 03:01:02 | justanotheruser: | wow |
| 03:01:53 | petertodd: | justanotheruser: seriously, if the blocksize were bigger just differences in performance between nodes would be causing forks |
| 03:03:14 | justanotheruser: | petertodd: Do you know of any opcodes that haven't been used in the blockchain that would cause a fork? |
| 03:04:11 | justanotheruser: | I'm assuming all the alt-clients have taken care of opcodes already used in the blockchain |
| 03:04:23 | petertodd: | justanotheruser: a bitcoin core fork, or a fork between core and an alt-client? |
| 03:04:50 | super3: | justanotheruser, your assuming the alt-clients actually know what they are doing |
| 03:04:57 | petertodd: | justanotheruser: I mean, shit, I'd bet a round of drinks that I could find a op_codeseparator bug in bitcoin-ruby |
| 03:05:12 | justanotheruser: | super3: actually my question assumes the opposite |
| 03:05:42 | petertodd: | justanotheruser: not sure that even all opcodes have been used, let alone in all the different ways |
| 03:06:09 | petertodd: | justanotheruser: heck, we didn't even test every invalid opcode in the unit tests until I fixed that |
| 03:06:09 | justanotheruser: | petertodd: I can guarantee that all opcodes havent been used in all different ways ;) |
| 03:06:24 | petertodd: | justanotheruser: heh |
| 03:06:51 | justanotheruser: | petertodd: the test is for the opcodes functionality, or that it returns false if it is present? |
| 03:07:51 | petertodd: | justanotheruser: heh, that's complex... you have to test that invalid opcodes make the script fail, don't make the script fail if within an if/else/endif block, and on top of all that, they are counted correct with regard to sigops |
| 03:09:18 | justanotheruser: | petertodd: oh, I wasn't aware that an invalid opcode could be present as long as you didn't reach it |
| 03:09:45 | justanotheruser: | but I guess the only way to distinguish an opcode and data *is* by reaching i |
| 03:09:46 | justanotheruser: | *it |
| 03:09:48 | petertodd: | justanotheruser: some of them that is true, others that is not true, and still others that is true but unlike others they don't count as a sigop |
| 03:29:10 | shesek: | I was thinking about a cool way to implement realitykeys-style oracles - the clients have list of pubkeys (for each party) and a script (that yields the "winning" pubkey(s)). The clients let id=H(script||pubkeys), and for each pubkey compute pubkey*ckd(oracle_master, H(id||pubkey)). At a later point, the server is provided with the script+pubkeys, it computes the id, determines the winner(s) and and yields ckd'(oracle_master, H(id |
| 03:29:10 | shesek: | ||winning_pubkey)). |
| 03:29:41 | shesek: | This means that: a. the server is stateless and doesn't have to store anything b. the clients don't need the server to start a transaction and c. it can very easily be proven if the oracle cheats |
| 03:31:03 | shesek: | basically, the realitykeys pubkeys are generated deterministically based on the script and the pubkeys |
| 03:32:40 | shesek: | the server can also easily restore after a data loss with just the master private key (well, there isn't really any other data saved on the server other than that) |
| 03:33:11 | petertodd: | dammit, I was sure I had already written that down at https://bitcointalk.org/index.php?topic=260898.msg3040083#msg3040083, but I guess not |
| 03:34:16 | petertodd: | heh, I think I discussed this last week with someone; you can't do it non-interactively with secp256k1 unfortunately, but you can do it interactively |
| 03:34:32 | shesek: | why? |
| 03:35:34 | petertodd: | shesek: you need a linear crypto system to pull off that trick - with ECC if you generate pub' from pub and then release sec' you can derive sec from pub and sec' |
| 03:36:14 | shesek: | oh - right! I knew about it but forgot it |
| 03:37:09 | shesek: | well, you could keep the master pubkey secret too and require the server to provide the derived pubkeys |
| 03:37:26 | shesek: | and still get the benefits of it being stateless and verifiable by third parties |
| 03:37:27 | petertodd: | exactly, the interactive case works, and is still stateless for the server |
| 03:38:38 | shesek: | well, being interactive doesn't matter that much... but it was a nice addition if it were non-interactive |
| 03:39:59 | shesek: | and it seems like someone already thought of every idea that I come up with, hehe :) |
| 03:40:30 | petertodd: | just means you're as smart as them, but came later :P |
| 03:40:30 | shesek: | if I understand correctly, realitykeys currently just generate unique keys with a bitcoind instance |
| 03:40:45 | petertodd: | probably, or, hopefully they *assign* unique keys! |
| 03:40:46 | shesek: | something like that is quite an improvement over that |
| 03:41:57 | shesek: | I started writing a small nodejs app to provide an API for that |
| 03:42:20 | petertodd: | oh nice! |
| 03:42:30 | shesek: | its quite simple, shouldn't take too long to get an api working... I hope to put it on github in a few days |
| 03:43:12 | petertodd: | cool |
| 03:44:09 | shesek: | any reference I can link to to give you credit for the idea? |
| 03:44:12 | shesek: | some bitcointalk thread or something? |
| 03:45:07 | petertodd: | shesek: reference "personal discussion" and https://bitcointalk.org/index.php?topic=260898.msg3040083#msg3040083 |
| 03:45:47 | petertodd: | shesek: (the "reveal private keys"/hash-preimages way of implementing oracles seems to, rather surprisingly, be my idea) |
| 03:46:12 | shesek: | also, any suggestions for a scripting language that's: a. concise and quick to write b. has good libraries for http and web scraping and c. has a secure sandbox? |
| 03:46:14 | petertodd: | shesek: I mean, there's *gotta* be someone who wrote it down first, at least the pre-images way seems obvious |
| 03:46:47 | petertodd: | secure sandbox? you trying to make a thing that evaluates scripts? my advice is don't |
| 03:47:29 | shesek: | well, I much prefer to just be able to feed the oracle with scripts |
| 03:47:37 | petertodd: | there's so many ways to hack that... I mean, I guess running something in a vm is probably ok, but then you want to basically run a business where a human checks it (like reality keys) |
| 03:47:39 | shesek: | why not? there are secure ways to run untrusted code |
| 03:48:05 | petertodd: | it's not easy - javascript is probably you're best bet simply because it's already used for that purpose |
| 03:48:09 | shesek: | nodejs's sandbox is pretty good (based on v8, who must have a very strong sandbox to execute webpages) |
| 03:48:23 | petertodd: | I think python has a sandbox in v3 too |
| 03:48:47 | petertodd: | dunno what's the best way to actually use either as a sandbox though, especially if you want to give network access |
| 03:48:48 | shesek: | thought about just using that (and possibly coffeescript) as the scripting language, buy async code will make it super ugly to use |
| 03:49:07 | petertodd: | you might find python is more popular with clients |
| 03:49:36 | shesek: | yeah, possibly so... I'll look into that |
| 03:52:20 | shesek: | I'm also thinking of ways to secure the master - perhaps do a daily batch of sending (id,pubkey) pairs to a separate server that provides a minimal api just for private key derivation |
| 03:52:29 | shesek: | who is blocked the rest of the time |
| 03:52:35 | shesek: | or... something |
| 03:53:02 | petertodd: | yup, that's a very good idea |
| 03:53:07 | shesek: | feels kinda wrong to put the private key on a machine that talks to the outside world, though that's probably what I'll do for now |
| 03:53:29 | shesek: | and improve on that later |
| 03:54:27 | shesek: | damn it, I have too many unfinished bitcoin-related projects stacking up, and I just added another one to the list |
| 03:54:47 | shesek: | so many interesting things to do, so little time to them :-( |
| 03:54:53 | shesek: | * to do |
| 03:56:47 | petertodd: | well, you could quit your day job like the rest of us :/ |
| 03:57:44 | go1111111: | is there an archive of this channel available somewhere? i'm an aspiring bitcoin developer and watching this room is an awesome way for me to learn stuff, but i only see like 20% of the content. Would someone be willing to send me their logs? (i promise i'm not a spy -- gmaxwell may be able to vouch for me somewhat) |
| 03:58:08 | shesek: | my day job is my company, not so easy to quite that after putting a few years of my life into that :( |
| 03:58:26 | andytoshi: | go1111111: http://download.wpsoftware.net/bitcoin/wizards/ has my logs. they are a bit patchy and don't go back far |
| 03:58:31 | petertodd: | shesek: ah, what's the company? |
| 03:58:31 | andytoshi: | but they are still overwhelming :) |
| 03:58:42 | shesek: | thought I do think I would probably do that if I could find a way to make a living from working on bitcoin |
| 03:59:03 | go1111111: | andytoshi: thank you! |
| 03:59:17 | shesek: | I'm trying a way to do that with bitrated, hopefully |
| 04:00:08 | shesek: | a software development company, mostly developing tools and services related to online advertising |
| 04:00:12 | petertodd: | shesek: might happen in the long run! |
| 04:00:16 | petertodd: | cool |
| 04:00:33 | andytoshi: | go1111111: you can also ask for citations for specific things if you want to know more. people are happy to provide links (and sometimes happy to provide explanations) |
| 04:01:47 | shesek: | or on someone else's money, who believes its gonna happen in the long run :) |
| 04:02:14 | shesek: | its not very easy though, especially because I want to keep it open source and free |
| 04:02:45 | shesek: | but I believe I have a model that could work |
| 04:03:13 | shesek: | well, anyway, its getting late here. good night! |
| 04:03:18 | petertodd: | later |
| 04:03:46 | amiller: | andytoshi, do you want a big ol' chunk of my old irc -wizards logs, would you put them up there? |
| 04:03:56 | go1111111: | andytoshi: I've always thought that I shouldn't really talk in this room until I am somewhat bitcoin-wizardly myself :) seems to be more of a "wizards discussing amongst themselves" channel, vs. "learn from the wizards." If I knew people didn't mind I would be asking lots of stuff though. |
| 04:04:04 | andytoshi: | amiller: yeah, sure |
| 04:04:16 | andytoshi: | amiller: apoelstra@wpsoftware.net |
| 04:04:16 | petertodd: | andytoshi: I've got logs from nearly day 0 too |
| 04:04:32 | amiller: | mine only go back to august 2013 |
| 04:04:39 | amiller: | i have older ones somewhere else |
| 04:04:43 | amiller: | you should take petertodd's |
| 04:05:25 | andytoshi: | ok, thanks guys!. if you send them to me i'll put them up petertodd |
| 04:07:01 | petertodd: | andytoshi: sent |
| 04:11:35 | andytoshi: | petertodd: thx, they're up |
| 04:11:39 | amiller: | go1111111, this is meant to be a pretty open and welcoming place, the main point is to keep the crazy rambling that goes on here out of bitcoin-dev where people are getting immediate technical support |
| 04:12:26 | andytoshi: | petertodd: http://download.wpsoftware.net/bitcoin/wizards/2013/ and http://download.wpsoftware.net/bitcoin/wizards/2014/ |
| 04:15:36 | petertodd: | andytoshi: cool. you should get rid of the joined/quit junk come to think of it |
| 04:16:09 | andytoshi: | petertodd: yeah, i should. i use it when i'm catching up by looking for the most recent "andytoshi has quit" message |
| 04:16:26 | andytoshi: | but i guess, it's a lot of noise to scroll through and i could really just look at the time |
| 04:16:54 | petertodd: | andytoshi: it's hilarious how the earliest message in that archive is me joining, followed by 15:37 <@gmaxwell> hi. I see you've arrived on wizard time. |
| 04:17:34 | andytoshi: | :D |
| 04:18:37 | petertodd: | andytoshi: leave that join in :P |
| 04:20:21 | andytoshi: | :P will do |
| 04:22:14 | amiller: | yeah petertodd was so late to the party it's silly that his logs are the furthest back :o |
| 04:22:50 | petertodd: | heh, I'm a stickler for archiving |
| 04:23:02 | petertodd: | heck, I just forced archive.org to import the whole lot of them from your site :P |
| 04:24:30 | amiller: | nice. |
| 04:24:33 | andytoshi: | :P excellent |
| 04:31:19 | andytoshi: | ok, i removed all the channel messages from petertodd's logs (except the initial 'wizard time' join). mine are a bit harder to grep through, i will write a cronjob in the coming days to keep those clean |
| 04:32:01 | andytoshi: | because andytoshi-logbot's personal logs will still have the messages, in case i need them. just the website should be clean |
| 04:32:06 | petertodd: | cool |
| 04:40:31 | petertodd: | gmaxwell: http://blog.ethereum.org/2014/02/03/introducing-ethereum-script-2-0/ "Crypto opcodes are removed. Instead, we will have to have someone write SHA256, RIPEMD160, SHA3 and ECC in ES as a formality, and we can have our interpreters include an optimization replacing it with good old-fashioned machine-code hashes and sigs right from the start." <- just like you proposed months ago |
| 04:42:02 | petertodd: | "Cumbersome to read, but actually quite easy to implement in any statically or dynamically types programming language or perhaps even ultimately in an ASIC." <- I hope vitalik realizes that if there's a significant advantage to implementing anything on an asic, not just the pow, you've screwed up |
| 04:43:18 | shesek: | petertodd, I think I found a much simpler way to do that. To start, the server receives the script hash (sid) and a user identifier (uid) and returns ckd(master, H(sid||uid)). To redeem, he receives the script (returing the winning uid) and returns ckd'(master,H(H(script)||script()) |
| 04:43:31 | shesek: | this seems to work just as well, and is much less cluttered |
| 04:43:39 | petertodd: | gmaxwell: I wonder if vitalik remembers your note about how doing that for a potentially-performance-mattering crypto-currency isn't necessarily a good idea though... |
| 04:44:23 | shesek: | do you see any disadvantage in not putting the all the pubkeys as part of the derivation key? |
| 04:44:57 | shesek: | I thought it would make it more binding to the specific transaction/multisig taking place, but I can't really see how it can be abused without it |
| 04:44:59 | petertodd: | shesek: why do you want the user uids in there at all? |
| 04:45:22 | shesek: | well, it needs to be unique per user |
| 04:45:50 | petertodd: | shesek: why? it's a script - it doesn't need to know who'se using it |
| 04:46:10 | shesek: | the uid can be the public key, some string representing the user ('bob' and 'alice') or some string representing the outcome ('giants win', 'giants lose') |
| 04:46:11 | petertodd: | shesek: basically, if the script ever returns true, release the corresponding private key |
| 04:46:38 | petertodd: | yeah, see, what you want is *arguments* |
| 04:46:50 | shesek: | there are multiple keys for every script, it should know which one is to be released |
| 04:46:57 | shesek: | based on the outcome of the script |
| 04:47:37 | shesek: | it doesn't have to be binary - there could be many outcomes from the script execution, each corresponding to another key |
| 04:48:23 | petertodd: | shesek: ah, see, I'm more making the point that conceptually you can think of an inner script that does the work, and an outer script for each condition |
| 04:48:36 | petertodd: | H(outer) depends on H(inner) |
| 04:49:01 | petertodd: | the crypto-code equivalent to functional programming currying |
| 04:49:49 | shesek: | so each outcome has a separate script that returns a boolean about that outcome being true |
| 04:50:11 | petertodd: | so yeah, don't call it uid, call it *return-value*, and then release the private key for a given return value if the script returns exactly that value |
| 04:50:16 | shesek: | and each user would only ask the server to evaluate his own outcome's function, ignoring the rest? |
| 04:51:09 | petertodd: | that's exactly how a theoretical implementation could do it |
| 04:51:15 | shesek: | yeah, I just the script's return value as part of the preimage for the derivation key |
| 04:51:30 | shesek: | I think a single script is somewhat nicer to work with |
| 04:51:44 | petertodd: | yup - it's not that your uid thing was wrong, it just gave people the wrong impression about what was happening |
| 04:52:12 | shesek: | well, its just something to uniquely identify the user/outcome that's shared with the script |
| 04:52:20 | petertodd: | whereas if you say return value, it's clear that the private key to be released corresponds with something the script will return |
| 04:52:46 | petertodd: | I might after all be using this for something that doesn't involve users! |
| 04:53:04 | shesek: | right... might be the wrong name |
| 04:53:48 | petertodd: | names are important! |
| 04:53:57 | shesek: | in the users case, each party creates one of those for himself and multiples his pubkey with that. so bob would use bob_pubkey*ckd(master, H(sid||'bob')) |
| 04:54:14 | shesek: | since in that case it has a one-to-one relation with the users pubkeys, it kinda makes sense |
| 04:54:21 | shesek: | but something more general is probably better |
| 04:55:11 | shesek: | I think it probably makes sense to base that on the outcome - its also more natural with how the script would be written |
| 04:56:37 | petertodd: | well no: alice, bob, and charlie agree on a magic script that returns either 1, 2, or 3, depending on what local sports team wins. They all use user_pubkey*ckd(master, H(script || n)) where n is one of 1, 2, or 3 |
| 04:57:08 | petertodd: | after all, they might want to reuse the script, and this time bob might bet either team #2 or team #3 wins |
| 04:58:06 | shesek: | hmm... if the script and its outcome are not unique and could be re-used, this might cause some problems |
| 04:58:41 | shesek: | they would already have a private key from the previous runs |
| 04:59:28 | shesek: | though I think scripts should be immutable - do you see any case where the same script returns different results? |
| 04:59:55 | shesek: | maybe if there's some "who won the last game" page that's being accessed from the same url or something |
| 05:00:52 | shesek: | I could add some unique nonce in there |
| 05:01:17 | shesek: | maybe just based on everyone's pubkeys, like I did originally |
| 05:01:18 | petertodd: | that the outcomes may not be unique should be telling you something! |
| 05:01:44 | jgarzik: | http://blog.ethereum.org/2014/02/03/introducing-ethereum-script-2-0/ |
| 05:01:47 | petertodd: | most scripts will actually have some core generic function - look up data on the blockchain - and an outer wrapper |
| 05:01:55 | jgarzik: | JMP disappears, heh |
| 05:01:56 | petertodd: | jgarzik: see above |
| 05:02:41 | petertodd: | jgarzik: if we're not careful we'll wind up with vitalik listening to us, getting rid of the really dumb stuff, and winding up with a kinda usable but flawed system that catches on anyway... |
| 05:03:16 | petertodd: | shesek: before you get too deep, try actually writing some of these scripts for real-world uses and think through how that might work |
| 05:03:43 | shesek: | what would that outer wrapper do? provide it with some arguments? |
| 05:04:12 | petertodd: | exactly! provide arguments to the function that actually implements things |
| 05:04:40 | petertodd: | e.g. if I have a "Did txid get mined?" function, the wrapper will contain the code calling it with the given txid. |
| 05:05:26 | shesek: | does it really matter if its an inner and outer script, or simply a script that contains a function definition followed with a call to that function with some arguments? |
| 05:05:58 | petertodd: | so long as everything is hashed, absolutely not |
| 05:06:15 | shesek: | I was thinking to provide some common utilities in the script's environment for things like that, but the case of user-provided re-used functions is also interesting |
| 05:07:19 | petertodd: | yup |
| 05:07:27 | shesek: | perhaps some way to import external scripts... I'm already running untrusted code, I might just as well allow it to import some random code from around the web |
| 05:07:46 | shesek: | let people host re-used scripts on gist/github/pastebin and allow to import them |
| 05:08:20 | petertodd: | what do you mean by import? |
| 05:08:41 | shesek: | though its probably best to fetch and "lock" it to a specific script at the beginning, so that it can't be changed later on |
| 05:09:30 | petertodd: | absolutely |
| 05:09:43 | shesek: | say someone creates a repo on github with some commonly used scripts, allow scripts to "import github:john/oraclescripts/sports/football" |
| 05:10:07 | petertodd: | yeah... think through how that could be attacked... |
| 05:10:23 | shesek: | probably best to leave that to the client, who will embed the imports as inline scripts as part of the script being hashed |
| 05:10:38 | petertodd: | like I said above, you should try writing some of these scripts for real in a convenient language, and think through how they'd actually be used |
| 05:10:49 | shesek: | well, the script could be changed in the future, after getting used |
| 05:11:07 | petertodd: | if it's changed, then how do you know users agreed to the change? |
| 05:11:32 | shesek: | no, I agree - this is obviously bad |
| 05:11:36 | petertodd: | heh |
| 05:12:09 | shesek: | probably best to commit to the imported script hash at the time of creation |
| 05:12:17 | shesek: | or just embed imported scripts inline |
| 05:12:43 | shesek: | (which is just another way to commit to them at the time of creation, really) |
| 05:13:00 | petertodd: | exactly |
| 05:13:12 | petertodd: | if your server accepts a tarball and commits H(tarball) that's fine |
| 05:14:26 | shesek: | it could work nicely with nodejs, browserify can take code with external dependencies and turn it into a single javascript file with everything embedded |
| 05:14:57 | shesek: | too bad async code looks so ugly :-\ I'm aiming for something simpler enough for non-programmer to use |
| 05:15:11 | shesek: | something that feels more like a DSL than actual code |
| 05:15:53 | petertodd: | I think you're going to find that actually using this stuff securely is basically a DSL |
| 05:22:20 | Luke-Jr: | shesek: if only some language had integrated coprocessing.. |
| 05:24:03 | shesek: | Luke-Jr, ? |
| 05:26:48 | Luke-Jr: | shesek: coprocessing makes async as clean as sync |
| 05:27:00 | Luke-Jr: | well, kinda. |
| 05:27:54 | shesek: | well, yeah, async code could be clean (and nodejs now supports `yield`, which makes that somewhat nicer) |
| 05:28:21 | shesek: | but async isn't really an advantage here, every script execution is sandboxed |
| 05:28:46 | shesek: | so there's no real reason to go after an async languages specifically |
| 05:29:25 | shesek: | well, unless the sandbox doesn't involve a separate thread... but it usually does |
| 05:38:17 | tacotime_: | tacotime_ is now known as tt_away |
| 19:19:32 | adams.freenode.net: | 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. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 19:19:32 | adams.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot adam3us go1111111 michagogo|cloud _ingsoc_ mappum CodeShark c0rw1n oooooo orperelman Guest70608 jtimon perrier_______ TD rdymac andytoshi DougieBot5000 roidster asoltys edulix RoboTeddy sl01 hnz mapppum gavinandresen azariah4 warren BlueMatt tt_away imsaguy_i Muis home_jg Ursium nOgAnOo OneFixt grazs qwertyoruiop_ Sorcier_FXK Alanius helo amiller kinlo crescendo rs0_ Guest83260 Luke-Jr stonecoldpat spinza @ChanServ |
| 19:19:32 | adams.freenode.net: | Users on #bitcoin-wizards: phantomcircuit Ryan52 typex Fistful_of_Coins jron_ EasyAt pigeons petertodd ryan-c wangbus Mikalv epscy gmaxwell aksyn ghtdak fagmuffinz K1773R optimator_ MoALTz_ espes___ Sangheil- wumpus poeticlobster jrmithdobbs pajarillo Krellan wrabbit heakins sipa maaku_ ageis realazthat a5m0 iddo 31NAAEFTQ licnep hno cfields nanotube gribble midnightmagic UukGoblin zacm comboy otoburb bobke Graet harrow forrestv tucenaber |
| 19:25:42 | imsaguy_i: | imsaguy_i is now known as imsaguy |
| 19:37:28 | _ingsoc_: | _ingsoc_ is now known as _ingsoc |
| 19:45:30 | phantomcircuit: | the dull hum of money |
| 19:50:49 | home_jg: | home_jg is now known as jgarzik |
| 19:59:57 | jgarzik: | heh |
| 20:10:59 | BlueMatt: | sipa: did you ever figure out if you're coming to barbados? |
| 20:12:04 | phantomcircuit: | BlueMatt, o.o |
| 20:12:34 | sipa: | BlueMatt: i'm not |
| 20:12:35 | BlueMatt: | phantomcircuit: fc14.ifca.ai |
| 20:12:46 | BlueMatt: | sipa: damn |
| 20:13:43 | maaku_: | BlueMatt: hard to justify :( |
| 20:13:53 | BlueMatt: | understandable |
| 20:13:55 | phantomcircuit: | lol why is it in barbados |
| 20:14:09 | phantomcircuit: | i mean other than the obvious vacation potential |
| 20:14:42 | BlueMatt: | because of vacation potential... |
| 20:14:55 | maaku_: | phantomcircuit: you must be new to academia |
| 20:15:03 | sipa: | haha |
| 20:15:11 | sipa: | conferences == reward mechanism |
| 20:15:45 | phantomcircuit: | maaku_, new? i pulled that ejector the first chance i got |
| 20:16:40 | maaku_: | phantomcircuit: hah, so did I |
| 20:17:17 | maaku_: | when I was at NASA conference travel support was a reward divied out by managers |
| 20:17:39 | maaku_: | Hawai'i, Nice, Rome ... be a good little researcher and you'll get a taxpayer-paid vacation |
| 20:18:55 | TD: | BlueMatt: you're going? |
| 20:21:30 | amiller: | financial crypto is always in carribbean |
| 20:21:40 | amiller: | i found this documentary about the first financial crypto conference |
| 20:22:00 | amiller: | http://vimeo.com/23562982 |
| 20:22:05 | amiller: | but it's in japanese so i can't understand any of it |
| 20:23:33 | maaku_: | well, the carribbean is not an inappropriate place for international finance... although barbados isn't really known for that |
| 20:23:46 | amiller: | i think it was in carribbean because they wanted to like buy an island in a tax free haven and build the crypto darknet utopia freehaven machine there |
| 20:24:00 | amiller: | it was initially at Anguilla |
| 20:24:06 | roidster: | roidster is now known as Guest65511 |
| 20:24:13 | maaku_: | amiller: sshhh this channel is logged |
| 20:24:50 | amiller: | the cypherpunks were remarkably ambitious back in the day |
| 20:25:19 | amiller: | it's like a big line of research and development largely fueled by high quality science fiction |
| 20:25:34 | petertodd: | amiller: ambition is a common thing when you don't know the limitations of your tech :P |
| 20:25:53 | amiller: | so it's so amazing that even though it petered out (which is sad), bitcoin is just cool enough and legitimately novel/useful to resuscitate it |
| 20:26:26 | petertodd: | well, bitcoin *did* solve a serious limitation |
| 20:26:46 | petertodd: | or, we think it solves it, maybe :P |
| 20:26:53 | BlueMatt: | TD: yea, Ill be there |
| 20:27:10 | amiller: | BlueMatt, TD i'll be there too |
| 20:28:07 | TD: | BlueMatt: lucky! |
| 20:28:20 | phantomcircuit: | petertodd, the limitations are largely political there |
| 20:28:23 | TD: | maybe i'll go next year |
| 20:28:32 | BlueMatt: | TD: why not just grab a ticket? |
| 20:28:36 | phantomcircuit: | you're only a sovereign nations as long as everybody else agrees you are |
| 20:28:40 | BlueMatt: | TD: or...you've got plans around then, no? |
| 20:28:41 | TD: | i'm already out for half of feb |
| 20:28:50 | TD: | i need to do some work at some point :) |
| 20:28:56 | BlueMatt: | TD: out of what? I thought you were done working? |
| 20:29:06 | phantomcircuit: | im waiting for someone to start a cash only bank somewhere |
| 20:29:06 | TD: | i mean, i'm on vacation for half of feb |
| 20:29:14 | phantomcircuit: | that'll be amusing |
| 20:29:55 | BlueMatt: | TD: so take more :) |
| 20:30:02 | TD: | will think about it |
| 20:30:04 | jgarzik: | phantomcircuit, amusing until they become a big robbery target anyway... |
| 20:30:17 | BlueMatt: | TD: I think you've got till like tomorrow before rates go up on the conf itself |
| 20:30:31 | BlueMatt: | oh, nope, too late already |
| 20:30:37 | BlueMatt: | though its only like 200 extra |
| 20:30:43 | phantomcircuit: | jgarzik, security for cash is something that banks have lots and lots of experience with |
| 20:30:45 | shesek: | petertodd, I was thinking about what I said yesterday about putting the oracle's master private key on a separate server with a thin api. It doesn't really make sense, because the moment a derived private key is revealed, the master public key is just as good as getting the master private key... so there's no point in separating them :-\ |
| 20:30:47 | BlueMatt: | thats nothing for a bitcoin mogul like TD :) |
| 20:30:53 | phantomcircuit: | that's basically just a matter of money for security |
| 20:31:00 | jgarzik: | phantomcircuit, ever decreasing amounts of experience... |
| 20:31:06 | TD: | elli was suggesting i should go last time we met, i think she goes every year. but yeah .... can't be partying on a beach all the time :) |
| 20:31:08 | shesek: | might as well just put both of them together on the same machine that's accessible to the outside world |
| 20:31:08 | phantomcircuit: | jgarzik, i guess |
| 20:31:19 | BlueMatt: | TD: ummmmm....why not? |
| 20:31:30 | BlueMatt: | TD: best advice Ive ever gotten: "retire early, retire often" |
| 20:31:34 | phantomcircuit: | jgarzik, you couldn't run such a bank in most countries anyways, so you'd probably have to hire serious security |
| 20:31:55 | TD: | hehe |
| 20:32:40 | petertodd: | shesek: you can use what sipa is now called "hardened" derivation to get around that problem |
| 20:33:35 | TD: | BlueMatt: will think about it :) |
| 20:36:48 | shesek: | petertodd, but wouldn't that mean that I need the private key to derive public keys? |
| 20:37:41 | petertodd: | shesek: point is you can regularly, and securely, derive a "one week only" keypair and send it to the hot box |
| 20:37:44 | shesek: | when the parties beings the transaction, they ask for ckd(master, H(sid||outcome)). With hardened keys, I would need the master private key here, no? |
| 20:37:53 | petertodd: | shesek: your master identity is still secure, making backups easier (just one seed) |
| 20:38:34 | shesek: | I would still need access to old weekly private keys - contracts might take a long time to finish |
| 20:39:00 | shesek: | it might take months, possibly years, for the user to request the script to be executed and to reveal the private key |
| 20:39:28 | shesek: | so I would need to make old private keys accessible too - it would only protect future keys from being compromised |
| 20:39:40 | petertodd: | shesek: sure, but you can always implement things like requests in advance |
| 20:39:58 | petertodd: | shesek: I mean, if you're waiting 1 year, is five minutes really that important? an hour? |
| 20:40:00 | shesek: | in which case, I can switch to a new master private key in case of a known attack and gain the same result |
| 20:40:18 | petertodd: | shesek: emphasis on known... |
| 20:40:55 | shesek: | if its not known, the attacker has active access and he still gets access to every new hot private key |
| 20:41:44 | petertodd: | shesek: not necessarily true, e.g. someone compromises some backups |
| 20:41:57 | shesek: | but yeah, rotating them on a weekly basis from a master seed and having a delayed execution in case an older private key is used could work |
| 20:42:16 | shesek: | yeah, that's right too |
| 20:42:43 | petertodd: | main thing is don't make an infrastructure where that kind of thing is impossible; give yourself some flexibility |
| 20:42:49 | shesek: | btw, can't I just do "hardened" derivation with a simple H(seed||nonce)? |
| 20:43:02 | petertodd: | that's what hardened derivation is |
| 20:43:06 | shesek: | it seems to have the same properties |
| 20:43:29 | shesek: | really? it seems more complicated from the looks of the wiki :P |
| 20:43:48 | shesek: | I haven't looked really closely, just skimmed it now that you mentioned it |
| 20:44:07 | petertodd: | shesek: heh, read it carefully :) also, the BIP32 doc is at http://github.com/bitcoin/bips |
| 20:44:24 | shesek: | btw, I was thinking about going with Lua |
| 20:44:34 | shesek: | it seems to have a very strong sandbox execution model |
| 20:44:47 | shesek: | and it allows for some pretty cool DSLs |
| 20:45:03 | petertodd: | dunno much about Lua |
| 20:45:12 | petertodd: | anyway, write some actual scripts that do actual things people might want first! |
| 20:45:25 | petertodd: | stop obsessing over the language until you get a better handle on what it might need to actually do |
| 20:45:50 | petertodd: | I mean, hell, you can always launch the service by executing the scripts *manually* to see how people use it - guarantee you that'll scale well enough for the first few weeks |
| 20:46:19 | shesek: | well, I did! I have a mostly working version, with a "return 1" as substitute for script execution |
| 20:47:38 | shesek: | its pretty simple, really - just two api endpoints, one for creation that does takes `(sid, outcome)` and return `ckd (master, H(sid||outcome))` |
| 20:47:58 | shesek: | and another that takes a script and returns ckd'(master, H(H(script)||script(input))) |
| 20:48:25 | shesek: | ugh, just script(), without input |
| 20:48:41 | shesek: | wanted to add a way to add inputs to scripts, but I didn't do that for now eventually |
| 20:48:58 | petertodd: | sounds good, now go write some scripts that solve actual problems for people :) |
| 20:49:08 | petertodd: | believe me, that's the hardest part of this by far |
| 20:49:53 | shesek: | some of the more obvious things this can be used for seems a bit... problematic |
| 20:50:14 | shesek: | not sure I want to provide that myself, prefer to let the community or some anonymous gists to do that |
| 20:51:11 | petertodd: | if you don't try, how do you know if the idea is feasible at all? |
| 20:51:22 | petertodd: | or equally, what kind of facilities the language needs to be useful? |
| 20:52:06 | shesek: | well, I meant problematic in a legal way, and was referring to gambling |
| 20:52:24 | shesek: | I'll have to check with my attorney in what position it puts me if I provide scripts that helps facilitate gambling |
| 20:53:16 | shesek: | I prefer to keep some distance from that |
| 20:53:21 | petertodd: | I said nothing about you providing the scripts, I'm just saying you should write them yourself and make sure you thoroughly understand how they might work |
| 20:53:32 | petertodd: | if your customers have to rewrite them, so what? |
| 20:53:51 | shesek: | oh, right, of course, I will write a few myself |
| 20:53:59 | shesek: | I'm assuming the most common would be based on web scraping |
| 20:54:00 | petertodd: | writing the code is the easiest part of these projects you know :) |
| 20:54:16 | shesek: | go to some webpage, match some rules against its contents, return an outcome |
| 20:54:16 | petertodd: | sure, so try writing some screen scrapers and see what kind of problems they'll run into |
| 20:55:04 | shesek: | I work a lot with web scraping/automation in my day-to-day work, I know how they work |
| 20:55:51 | shesek: | the most useful things to match against an http document is css/jquery-style selectors, xpath and regex |
| 20:56:03 | shesek: | blah, * html document |
| 20:56:25 | petertodd: | ok, so that's part of the problem - what happens when those scripts don't work? when the webpage changes on you? |
| 20:57:18 | shesek: | I guess it has to come down to human intervention at that point |
| 20:57:44 | shesek: | human intervention and commented scripts that describes what the parties intended when they wrote them |
| 20:58:07 | shesek: | or some separate field to add "notes for the human who might need to handle that in the future" |
| 20:58:11 | petertodd: | indeed, so think through how that procedure might work - that's a *huge* aspect of how the overall architecture should work |
| 21:01:30 | shesek: | yes, that's an important part too. though human intervention is probably the least fun part of a project like that |
| 21:02:33 | shesek: | perhaps I could outsource that somehow - have the parties provide an arbitrator public key and use H(sid||pubkey||outcome), then allow an outcome signed by that pubkey as a substitute for script execution |
| 21:03:10 | shesek: | and just let the parties decide who they trust to do the human verification |
| 21:05:43 | petertodd: | sure - note how in typical 2-of-4 oracle schemes the two parties can always mutually agree on the outcome themselves |
| 21:12:59 | shesek: | what are some interesting and useful scripts that I could provide as examples? |
| 21:13:56 | shesek: | preferably ones that don't involve gambling... it might be fine to provide such scripts, but I'm not quite sure about that yet |
| 21:14:24 | shesek: | do you know of any states that provides public death certificates? |
| 21:19:50 | petertodd: | dunno really - I haven't thought much about any of that stuff |
| 21:22:01 | shesek: | apparently both West Virginia and Missouri provide them - but both of them exclude death certificates from the last 50 years |
| 21:22:06 | shesek: | which isn't really useful :-\ |
| 21:22:27 | shesek: | unless the one getting the inheritance is willing to wait 50 years |
| 21:23:19 | petertodd: | all though things to automate in code... |
| 22:34:09 | sipa: | interesting thought-experiment altcoin: an implicit UTXO of 1 coin exists for every address in advance |
| 22:34:22 | sipa: | as soon as this gets any exchange value, it has a +infinity market cap |
| 22:35:43 | jgarzik: | heh |
| 22:37:18 | michagogo|cloud: | um |
| 22:37:28 | sipa: | well, 2^160 * exchangevalue market cap |
| 22:37:31 | sipa: | not actually infinite :) |
| 22:37:46 | michagogo|cloud: | ...which also means it has a market cap of zero |
| 22:38:11 | michagogo|cloud: | Because there are 2^160 coins premined |
| 22:38:22 | michagogo|cloud: | Premined, for literally anyone to claim |
| 22:38:29 | michagogo|cloud: | Meaning that it would be worthless |
| 22:38:59 | sipa: | but maybe some fool still wants to pay for more than he can "address mine" |
| 22:39:44 | michagogo|cloud: | ... |
| 22:40:01 | michagogo|cloud: | You can "address mine" millions of coins per second |
| 22:40:09 | sipa: | it could be made very hard :) |
| 22:40:54 | sipa: | but yes, i see your point - it's hard to understand why anyone would pay money for this |
| 22:41:14 | Alanius: | ... but if creating a new address is very hard, can it be useful? |
| 22:41:33 | sipa: | on the other hand, i think dogecoin proves that reason plays very little role :) |
| 22:42:34 | Luke-Jr: | petertodd: Joe and Fred coinjoin. Fred goes to spend more coins, and his wallet uses the change from said CoinJoin. Joe double-spends the coinjoin in the meantime. |
| 22:43:16 | sipa: | Luke-Jr: right, coinjoins should be considered non-IsFromMe in that regard (not allow 0 conf spends) |
| 22:43:32 | Luke-Jr: | sipa: but are they, right now? |
| 22:45:43 | sipa: | i think so, yes |
| 22:50:18 | jtimon: | michagogo|cloud "You can "address mine" millions of coins per second" well, you will have to pay fees to claim those coins |
| 22:51:48 | jtimon: | enough to convince miners not to just fill the block with their own claims |
| 23:02:17 | maaku_: | i know that i have asked this before, but I can't find the log: what is a good elliptic curve blind signature scheme? |
| 23:05:51 | andytoshi: | maaku_: did you have something in mind other than the schnorr scheme described at http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html ? |
| 23:06:28 | andytoshi: | that is what i was going to use unless somebody gave me a reason otherwise.. but i haven't put too much thought into it |
| 23:08:08 | maaku_: | that's an integer DSA scheme, right? maybe I'm demonstrating number theory ignorance here, but can I just use the same equations with elliptic curve points? |
| 23:09:37 | andytoshi: | nope, the first paragraph is an integer scheme but after the heading `Schnorr/DSA blind signatures' you can use an EC group |
| 23:11:07 | andytoshi: | iirc you just need discrete log to be hard. |
| 23:12:52 | andytoshi: | i was then going to implement that scheme for the edwards curve25519 by extending djb's ed25519 code. but i'm barely 1/3 of the way through the ed25519 paper so i don't know if that's a reasonable idea |
| 23:14:47 | sipa: | schnorr seems pretty simple to implement |
| 23:15:01 | sipa: | and ed25519 has multiplication and addition, which is all you need |
| 23:15:17 | maaku_: | andytoshi: i think there are pragmatic reasons to stick to secp256k1 |
| 23:16:25 | maaku_: | if the scripting system is made expressive enough to do these verifications, and if we desire SNARK proofs over those script execution traces |
| 23:17:07 | sipa: | if someone has the time, i'd love to see a secp256k1 vs ed25519 benchmark |
| 23:17:58 | maaku_: | there's a bunch of if's in there, but a serious enough payoff that I'm not as enamored with ed25519 as I once was |
| 23:18:18 | maaku_: | sipa: I'd like to see some hard numbers too, but for apples-to-apples it'd have to be a modified version of ed25519 which supports BIP-32 like derivation |
| 23:18:33 | sipa: | which would ed25519 not support that? |
| 23:18:37 | maaku_: | which iirc slows ed25519 down by a factor of two (to within the ballpark of secp256k1?) |
| 23:18:42 | maaku_: | sipa: no, it does not |
| 23:18:47 | sipa: | why? |
| 23:19:29 | maaku_: | because some of the bits of the private key have to have fixed values |
| 23:19:30 | sipa: | so? |
| 23:19:31 | sipa: | ah |
| 23:19:32 | maaku_: | and when you do the public derivation, you don't know if that's the case |
| 23:19:36 | sipa: | right, that interferes |
| 23:19:38 | sipa: | got it |
| 23:19:59 | maaku_: | djb doesn't make his reasoning there clear |
| 23:20:10 | sipa: | on the other hand, ed25519 has batch verification |
| 23:20:11 | maaku_: | but part of it is for performance reasons - he's excluding slower keys |
| 23:20:37 | maaku_: | i just don't think we know yet if that is the only reason those restrictions are there |
| 23:20:45 | sipa: | right |
| 23:21:07 | andytoshi: | on se.crypto they believe that it's just to prevent timing attacks. |
| 23:21:19 | andytoshi: | iirc somebody here (adam?) emailed djb about it, didn't get a reply |
| 23:21:29 | sipa: | for verification, timing attacks don't matter at all |
| 23:21:38 | sipa: | and that's the only place where we want speed |
| 23:22:03 | maaku_: | andytoshi: yes, that's (an implication of) the same performance issue i'm referring to |
| 23:22:10 | andytoshi: | sipa: yeah. for verification we don't even notice this anyway because it's a restriction on the privkeys. but i agree with maaku_ that it's prudent to be nervous |
| 23:22:21 | andytoshi: | otherwise i'd just rip that code out and forget about it |
| 23:22:42 | sipa: | can schnorr signatures be batch-verified? |
| 23:22:58 | andytoshi: | dunno. |
| 23:23:02 | maaku_: | so i'd like to see comparison of secp256k1 vs full-key ed25519 |
| 23:24:09 | maaku_: | our curve can be batch-verified too, correct? |
| 23:24:37 | sipa: | ecdsa can be batch-verified is you have the full R point, instead of just R.x in signatures |
| 23:25:12 | maaku_: | oh so you need some preprocessing |
| 23:25:25 | sipa: | not just preprocessing |
| 23:25:33 | sipa: | there are two options for every y coordinate |
| 23:25:43 | sipa: | so you get an exponential blowup of possibilities to check |
| 23:26:41 | maaku_: | i see |
| 23:26:59 | sipa: | though recently i read something about someone actually getting a speedup from ecdsa batch verification |
| 23:27:04 | sipa: | somewhere on the forum |
| 23:27:19 | sipa: | i didn't verify or investigate it, as it sounds impossible in theory |
| 23:28:16 | maaku_: | * maaku_ adds one more point in the Schnorr column's tally |
| 23:28:54 | sipa: | i don't think schnorr can be batch verified, actually |
| 23:32:54 | maaku_: | gmaxwell says that the Tor project is looking to do something similar with key derivation using ed25519, so maybe something will come of that |