00:51:38Guest43303:Guest43303 is now known as amiller
00:52:22amiller:woot, i got my bitcoin paper into oakland, the fancy academic conference for bigshots
00:53:47petertodd:amiller: +1
00:54:17amiller:i'm up there with matt green's student now :o
01:06:43andytoshi:amiller: nice!
01:07:21amiller:it's the one about having "storage" as a beneficial side effect from a modified proofofwork puzzle
01:08:23petertodd:amiller: oh, you finally wrote a paper about forcing storage as part of pow?
01:08:32amiller:yeah
01:08:52amiller: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:00petertodd:amiller: heh, I hope you were clear it wasn't necessarily the most original idea :)
01:09:04petertodd:haha
01:09:27petertodd:(though maybe you did come up with it first!)
01:09:29amiller:well to be fair i've been working on this idea for 2.5 years
01:09:42amiller:it's up there in gmaxwell's crazy-shit wiki page
01:09:43petertodd:yeah, that's fine then
01:09:56petertodd:gmaxwell's only from a year ago - you've got me beat too for sure
01:12:48amiller:this was our review submitted version http://socrates1024.s3.amazonaws.com/permacoin.pdf
01:13:17amiller:btw i'm still waiting on coauthors for that mixcoin paper to finish responding to that forum post
01:13:43amiller:but regarding citing you for fidelity bonds, i absolutely had cited you originally and someone else commented it out by mistake
01:14:06amiller:it is a pet peeve of mine to take seriously citing bitcointalk posts etc properly
01:15:39petertodd:no worries
01:16:39petertodd: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:44amiller:right on, that's the only actual use i ever had in mind for this
01:19:25amiller:my coauthors thought that storing archival data for make great public benefit was good for marketing, and since it worked, good.
01:24:05petertodd:yeah, and technically, that's exactly what you'd be doing with blockchain data anyway
02:12:46justanotheruser:Any major flaws with mastercoin?
02:16:51maaku_:justanotheruser: yes?
02:17:07justanotheruser:maaku_: could you name a few?
02:17:21justanotheruser:As it always is with bitcointalk, I can only find positive opinions
02:17:49maaku_:justanotheruser: http://lmgtfy.com/?q=mastercoin+flaws
02:18:12petertodd:justanotheruser: what maaku said - Peter Todd - Chief Scientist - Mastercoin
02:19:24justanotheruser: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:52maaku_: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:22petertodd: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:47maaku_:the chief problem probably being lack of any kind of SPV support
02:20:54justanotheruser:petertodd: oh, so it is unknown whether it will be fixed
02:21:12petertodd:maaku_: yes, although to what degree SPV is a good thing is itself unknown
02:21:31shesek:petertodd, what do you mean by that?
02:21:39petertodd:justanotheruser: correct - I'm working on reviewing what specs they have right now
02:21:49maaku_:petertodd: i hope you're not on the hook for making its usd-parity voodoo work
02:22:24petertodd: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:44petertodd:maaku_: heh, I've got a lot of finance to learn...
02:23:14petertodd:maaku_: fortunately for economics, "work" is often a relative term
02:24:16shesek:miners? what trust does an spv node put on miners that a non-spv node doesn't?
02:24:34petertodd:shesek: non-spv nodes verify everything, so miners can't lie to them
02:24:48petertodd:shesek: spv will accept invalid blocks happily remember
02:25:49justanotheruser:Does the invalid block get propogated to them? Or is the assumption that the miner is directly talking to them?
02:25:59maaku_:justanotheruser: does it matter?
02:26:01shesek:well, some subset of invalid, it still requires the proof of work and transactions to be valid
02:26:05justanotheruser:maaku_: yes
02:26:13maaku_:justanotheruser: why?
02:26:27justanotheruser:maaku_: because I am curious which assumption this attack makes
02:26:43maaku_:it's the same assumption is what i'm saying
02:26:50petertodd: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:51maaku_:how do you know the identity of anyone you are connected to?
02:27:04shesek:(I'm not 100% familiar with how spv node works exactly, so I might be wrong)
02:27:16petertodd:shesek: you should be :)
02:27:39justanotheruser: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:35justanotheruser:Do spv clients propagate block headers themselves?
02:28:47maaku_:they shouldn't
02:28:49shesek: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:59shesek:* :)
02:29:04maaku_:but i wouldn't trust people not to do stupid things...
02:29:38shesek:in what ways not validating everything can it be practically abused?
02:30:37shesek:s/it be/be
02:30:51justanotheruser:petertodd: any ideas on stopping the doublespend?
02:31:52petertodd:justanotheruser: they should propagate headers, but that only lets you know about what blocks exist, not if they're valid
02:32:14petertodd:shesek: correct, and remember that in practice they usually don't validate much of anything about transactions
02:32:46petertodd:shesek: like I said, it's a *social* dynamic thing, because it makes it easy for miners to change the rules
02:32:54petertodd:justanotheruser: ?
02:33:16justanotheruser: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:32justanotheruser:so just do this purity check?
02:33:41petertodd:justanotheruser: you're cut off "so there is no way to receive masterc..."
02:33:50justanotheruser:ive mastercoins in a secure fashion."
02:34:10shesek: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:59petertodd: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:19petertodd:justanotheruser: that *is* true of bitcoin too remember, like I say, SPV nodes are trusting miners to validate for them
02:35:40justanotheruser:petertodd: yes, I didn't really understand his complaint
02:35:51petertodd:shesek: sure, but them rejecting those transactions does what? absolutely nothing - you don't know that they rejected anything!
02:36:10petertodd:shesek: (see fraud proofs)
02:36:21justanotheruser: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:25shesek: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:29petertodd:justanotheruser: the gist of it is right, but the terminology is weird
02:36:47petertodd:shesek: a transaction may be invalid because a prior transaction input was invalid
02:36:48justanotheruser:petertodd: how is my terminology weird?
02:37:07petertodd:justanotheruser: "purity"
02:37:33justanotheruser:petertodd: I am quoting the person I quoted earlier. By purity I mean lack of doublespends
02:37:48petertodd:justanotheruser: sure, we'd probably say "correctness"
02:37:53justanotheruser:ok
02:39:05petertodd: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:13petertodd: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:25justanotheruser:petertodd: so centralize it?
02:41:39petertodd: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:02justanotheruser:petertodd: do you work for mastercoin, or are you just doing this for fun?
02:44:14petertodd:justanotheruser: I'm their chief scientist
02:44:42petertodd:justanotheruser: (paid position)
02:45:05justanotheruser:petertodd: okay cool. How many people work for it (if you know)?
02:45:23justanotheruser:it's kindof weird to say work for mastercoin because it could mean two things
02:45:42petertodd:half-dozen paid devs IIRC? (dunno exact numbers)
02:45:46petertodd:?
02:45:57justanotheruser:cool
02:51:52phantomcircuit:petertodd, ethereum is neat
02:51:57justanotheruser:petertodd: killerstorms complaints seem to based around things that can be fixed. What are some big problems that might not be fixable
02:51:58phantomcircuit:it'll be lots of fun to break it horribly
02:52:07justanotheruser:phantomcircuit: heh
02:52:52justanotheruser:phantomcircuit: It seems like it will require someone to mine one really big loop to end the currency.
02:53:20justanotheruser:Or some more complicated attack will RAT every ethereum users HD
02:53:36petertodd: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:16phantomcircuit:sound advice
02:54:16petertodd:justanotheruser: I don't really know the answere to that question yet; anything *might* not be fixable
02:55:07petertodd:justanotheruser: see the #bitcoin-dev discussion about how I managed fork coinbase's bitcoin-ruby implementation twice in an hour
02:55:23petertodd:justanotheruser: consensus is hard enough as it is...
02:56:57justanotheruser:petertodd: their rules were different from the rest of the network?
02:57:15petertodd:justanotheruser: bitcoin-ruby re-implements EvalScript()...
02:58:08justanotheruser:petertodd: and their code didn't exactly align with the rest of the network?
02:58:26phantomcircuit:justanotheruser, it's nearly impossible to get it right
02:58:39phantomcircuit:they got lucky that they rejected valid transactions rather than the other way around
02:58:48justanotheruser:phantomcircuit: really? Because of all the nuances of different languages?
02:58:56petertodd:I genuinely believe it's a harder problem than safety critical aerospace software development.
02:59:08justanotheruser:huh
02:59:25justanotheruser:I guess I am taking satoshi for granted then
02:59:45petertodd:justanotheruser: getting version #1 done is easy, making version #2 identical is a nightmare
03:00:31justanotheruser:petertodd: has there ever been a case where compiling to a different OS or using different flags broke the consensus?
03:00:42petertodd:justanotheruser: yes
03:00:55petertodd:justanotheruser: that's why we ship leveldb with the source
03:01:02justanotheruser:wow
03:01:53petertodd:justanotheruser: seriously, if the blocksize were bigger just differences in performance between nodes would be causing forks
03:03:14justanotheruser:petertodd: Do you know of any opcodes that haven't been used in the blockchain that would cause a fork?
03:04:11justanotheruser:I'm assuming all the alt-clients have taken care of opcodes already used in the blockchain
03:04:23petertodd:justanotheruser: a bitcoin core fork, or a fork between core and an alt-client?
03:04:50super3:justanotheruser, your assuming the alt-clients actually know what they are doing
03:04:57petertodd:justanotheruser: I mean, shit, I'd bet a round of drinks that I could find a op_codeseparator bug in bitcoin-ruby
03:05:12justanotheruser:super3: actually my question assumes the opposite
03:05:42petertodd:justanotheruser: not sure that even all opcodes have been used, let alone in all the different ways
03:06:09petertodd:justanotheruser: heck, we didn't even test every invalid opcode in the unit tests until I fixed that
03:06:09justanotheruser:petertodd: I can guarantee that all opcodes havent been used in all different ways ;)
03:06:24petertodd:justanotheruser: heh
03:06:51justanotheruser:petertodd: the test is for the opcodes functionality, or that it returns false if it is present?
03:07:51petertodd: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:18justanotheruser:petertodd: oh, I wasn't aware that an invalid opcode could be present as long as you didn't reach it
03:09:45justanotheruser:but I guess the only way to distinguish an opcode and data *is* by reaching i
03:09:46justanotheruser:*it
03:09:48petertodd: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:10shesek: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:10shesek:||winning_pubkey)).
03:29:41shesek: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:03shesek:basically, the realitykeys pubkeys are generated deterministically based on the script and the pubkeys
03:32:40shesek: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:11petertodd: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:16petertodd: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:32shesek:why?
03:35:34petertodd: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:14shesek:oh - right! I knew about it but forgot it
03:37:09shesek:well, you could keep the master pubkey secret too and require the server to provide the derived pubkeys
03:37:26shesek:and still get the benefits of it being stateless and verifiable by third parties
03:37:27petertodd:exactly, the interactive case works, and is still stateless for the server
03:38:38shesek:well, being interactive doesn't matter that much... but it was a nice addition if it were non-interactive
03:39:59shesek:and it seems like someone already thought of every idea that I come up with, hehe :)
03:40:30petertodd:just means you're as smart as them, but came later :P
03:40:30shesek:if I understand correctly, realitykeys currently just generate unique keys with a bitcoind instance
03:40:45petertodd:probably, or, hopefully they *assign* unique keys!
03:40:46shesek:something like that is quite an improvement over that
03:41:57shesek:I started writing a small nodejs app to provide an API for that
03:42:20petertodd:oh nice!
03:42:30shesek: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:12petertodd:cool
03:44:09shesek:any reference I can link to to give you credit for the idea?
03:44:12shesek:some bitcointalk thread or something?
03:45:07petertodd:shesek: reference "personal discussion" and https://bitcointalk.org/index.php?topic=260898.msg3040083#msg3040083
03:45:47petertodd:shesek: (the "reveal private keys"/hash-preimages way of implementing oracles seems to, rather surprisingly, be my idea)
03:46:12shesek: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:14petertodd:shesek: I mean, there's *gotta* be someone who wrote it down first, at least the pre-images way seems obvious
03:46:47petertodd:secure sandbox? you trying to make a thing that evaluates scripts? my advice is don't
03:47:29shesek:well, I much prefer to just be able to feed the oracle with scripts
03:47:37petertodd: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:39shesek:why not? there are secure ways to run untrusted code
03:48:05petertodd:it's not easy - javascript is probably you're best bet simply because it's already used for that purpose
03:48:09shesek:nodejs's sandbox is pretty good (based on v8, who must have a very strong sandbox to execute webpages)
03:48:23petertodd:I think python has a sandbox in v3 too
03:48:47petertodd:dunno what's the best way to actually use either as a sandbox though, especially if you want to give network access
03:48:48shesek:thought about just using that (and possibly coffeescript) as the scripting language, buy async code will make it super ugly to use
03:49:07petertodd:you might find python is more popular with clients
03:49:36shesek:yeah, possibly so... I'll look into that
03:52:20shesek: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:29shesek:who is blocked the rest of the time
03:52:35shesek:or... something
03:53:02petertodd:yup, that's a very good idea
03:53:07shesek: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:29shesek:and improve on that later
03:54:27shesek:damn it, I have too many unfinished bitcoin-related projects stacking up, and I just added another one to the list
03:54:47shesek:so many interesting things to do, so little time to them :-(
03:54:53shesek:* to do
03:56:47petertodd:well, you could quit your day job like the rest of us :/
03:57:44go1111111: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:08shesek:my day job is my company, not so easy to quite that after putting a few years of my life into that :(
03:58:26andytoshi:go1111111: http://download.wpsoftware.net/bitcoin/wizards/ has my logs. they are a bit patchy and don't go back far
03:58:31petertodd:shesek: ah, what's the company?
03:58:31andytoshi:but they are still overwhelming :)
03:58:42shesek: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:03go1111111:andytoshi: thank you!
03:59:17shesek:I'm trying a way to do that with bitrated, hopefully
04:00:08shesek:a software development company, mostly developing tools and services related to online advertising
04:00:12petertodd:shesek: might happen in the long run!
04:00:16petertodd:cool
04:00:33andytoshi: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:47shesek:or on someone else's money, who believes its gonna happen in the long run :)
04:02:14shesek:its not very easy though, especially because I want to keep it open source and free
04:02:45shesek:but I believe I have a model that could work
04:03:13shesek:well, anyway, its getting late here. good night!
04:03:18petertodd:later
04:03:46amiller:andytoshi, do you want a big ol' chunk of my old irc -wizards logs, would you put them up there?
04:03:56go1111111: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:04andytoshi:amiller: yeah, sure
04:04:16andytoshi:amiller: apoelstra@wpsoftware.net
04:04:16petertodd:andytoshi: I've got logs from nearly day 0 too
04:04:32amiller:mine only go back to august 2013
04:04:39amiller:i have older ones somewhere else
04:04:43amiller:you should take petertodd's
04:05:25andytoshi:ok, thanks guys!. if you send them to me i'll put them up petertodd
04:07:01petertodd:andytoshi: sent
04:11:35andytoshi:petertodd: thx, they're up
04:11:39amiller: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:26andytoshi:petertodd: http://download.wpsoftware.net/bitcoin/wizards/2013/ and http://download.wpsoftware.net/bitcoin/wizards/2014/
04:15:36petertodd:andytoshi: cool. you should get rid of the joined/quit junk come to think of it
04:16:09andytoshi:petertodd: yeah, i should. i use it when i'm catching up by looking for the most recent "andytoshi has quit" message
04:16:26andytoshi:but i guess, it's a lot of noise to scroll through and i could really just look at the time
04:16:54petertodd: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:34andytoshi::D
04:18:37petertodd:andytoshi: leave that join in :P
04:20:21andytoshi::P will do
04:22:14amiller:yeah petertodd was so late to the party it's silly that his logs are the furthest back :o
04:22:50petertodd:heh, I'm a stickler for archiving
04:23:02petertodd:heck, I just forced archive.org to import the whole lot of them from your site :P
04:24:30amiller:nice.
04:24:33andytoshi::P excellent
04:31:19andytoshi: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:01andytoshi:because andytoshi-logbot's personal logs will still have the messages, in case i need them. just the website should be clean
04:32:06petertodd:cool
04:40:31petertodd: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:02petertodd:"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:18shesek: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:31shesek:this seems to work just as well, and is much less cluttered
04:43:39petertodd: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:23shesek:do you see any disadvantage in not putting the all the pubkeys as part of the derivation key?
04:44:57shesek: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:59petertodd:shesek: why do you want the user uids in there at all?
04:45:22shesek:well, it needs to be unique per user
04:45:50petertodd:shesek: why? it's a script - it doesn't need to know who'se using it
04:46:10shesek: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:11petertodd:shesek: basically, if the script ever returns true, release the corresponding private key
04:46:38petertodd:yeah, see, what you want is *arguments*
04:46:50shesek:there are multiple keys for every script, it should know which one is to be released
04:46:57shesek:based on the outcome of the script
04:47:37shesek:it doesn't have to be binary - there could be many outcomes from the script execution, each corresponding to another key
04:48:23petertodd: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:36petertodd:H(outer) depends on H(inner)
04:49:01petertodd:the crypto-code equivalent to functional programming currying
04:49:49shesek:so each outcome has a separate script that returns a boolean about that outcome being true
04:50:11petertodd: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:16shesek:and each user would only ask the server to evaluate his own outcome's function, ignoring the rest?
04:51:09petertodd:that's exactly how a theoretical implementation could do it
04:51:15shesek:yeah, I just the script's return value as part of the preimage for the derivation key
04:51:30shesek:I think a single script is somewhat nicer to work with
04:51:44petertodd:yup - it's not that your uid thing was wrong, it just gave people the wrong impression about what was happening
04:52:12shesek:well, its just something to uniquely identify the user/outcome that's shared with the script
04:52:20petertodd: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:46petertodd:I might after all be using this for something that doesn't involve users!
04:53:04shesek:right... might be the wrong name
04:53:48petertodd:names are important!
04:53:57shesek: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:14shesek:since in that case it has a one-to-one relation with the users pubkeys, it kinda makes sense
04:54:21shesek:but something more general is probably better
04:55:11shesek: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:37petertodd: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:08petertodd:after all, they might want to reuse the script, and this time bob might bet either team #2 or team #3 wins
04:58:06shesek:hmm... if the script and its outcome are not unique and could be re-used, this might cause some problems
04:58:41shesek:they would already have a private key from the previous runs
04:59:28shesek:though I think scripts should be immutable - do you see any case where the same script returns different results?
04:59:55shesek:maybe if there's some "who won the last game" page that's being accessed from the same url or something
05:00:52shesek:I could add some unique nonce in there
05:01:17shesek:maybe just based on everyone's pubkeys, like I did originally
05:01:18petertodd:that the outcomes may not be unique should be telling you something!
05:01:44jgarzik:http://blog.ethereum.org/2014/02/03/introducing-ethereum-script-2-0/
05:01:47petertodd:most scripts will actually have some core generic function - look up data on the blockchain - and an outer wrapper
05:01:55jgarzik:JMP disappears, heh
05:01:56petertodd:jgarzik: see above
05:02:41petertodd: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:16petertodd: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:43shesek:what would that outer wrapper do? provide it with some arguments?
05:04:12petertodd:exactly! provide arguments to the function that actually implements things
05:04:40petertodd: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:26shesek: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:58petertodd:so long as everything is hashed, absolutely not
05:06:15shesek: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:19petertodd:yup
05:07:27shesek: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:46shesek:let people host re-used scripts on gist/github/pastebin and allow to import them
05:08:20petertodd:what do you mean by import?
05:08:41shesek: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:30petertodd:absolutely
05:09:43shesek:say someone creates a repo on github with some commonly used scripts, allow scripts to "import github:john/oraclescripts/sports/football"
05:10:07petertodd:yeah... think through how that could be attacked...
05:10:23shesek: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:38petertodd: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:49shesek:well, the script could be changed in the future, after getting used
05:11:07petertodd:if it's changed, then how do you know users agreed to the change?
05:11:32shesek:no, I agree - this is obviously bad
05:11:36petertodd:heh
05:12:09shesek:probably best to commit to the imported script hash at the time of creation
05:12:17shesek:or just embed imported scripts inline
05:12:43shesek:(which is just another way to commit to them at the time of creation, really)
05:13:00petertodd:exactly
05:13:12petertodd:if your server accepts a tarball and commits H(tarball) that's fine
05:14:26shesek: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:57shesek:too bad async code looks so ugly :-\ I'm aiming for something simpler enough for non-programmer to use
05:15:11shesek:something that feels more like a DSL than actual code
05:15:53petertodd:I think you're going to find that actually using this stuff securely is basically a DSL
05:22:20Luke-Jr:shesek: if only some language had integrated coprocessing..
05:24:03shesek:Luke-Jr, ?
05:26:48Luke-Jr:shesek: coprocessing makes async as clean as sync
05:27:00Luke-Jr:well, kinda.
05:27:54shesek:well, yeah, async code could be clean (and nodejs now supports `yield`, which makes that somewhat nicer)
05:28:21shesek:but async isn't really an advantage here, every script execution is sandboxed
05:28:46shesek:so there's no real reason to go after an async languages specifically
05:29:25shesek:well, unless the sandbox doesn't involve a separate thread... but it usually does
05:38:17tacotime_:tacotime_ is now known as tt_away
19:19:32adams.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:32adams.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:32adams.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:42imsaguy_i:imsaguy_i is now known as imsaguy
19:37:28_ingsoc_:_ingsoc_ is now known as _ingsoc
19:45:30phantomcircuit:the dull hum of money
19:50:49home_jg:home_jg is now known as jgarzik
19:59:57jgarzik:heh
20:10:59BlueMatt:sipa: did you ever figure out if you're coming to barbados?
20:12:04phantomcircuit:BlueMatt, o.o
20:12:34sipa:BlueMatt: i'm not
20:12:35BlueMatt:phantomcircuit: fc14.ifca.ai
20:12:46BlueMatt:sipa: damn
20:13:43maaku_:BlueMatt: hard to justify :(
20:13:53BlueMatt:understandable
20:13:55phantomcircuit:lol why is it in barbados
20:14:09phantomcircuit:i mean other than the obvious vacation potential
20:14:42BlueMatt:because of vacation potential...
20:14:55maaku_:phantomcircuit: you must be new to academia
20:15:03sipa:haha
20:15:11sipa:conferences == reward mechanism
20:15:45phantomcircuit:maaku_, new? i pulled that ejector the first chance i got
20:16:40maaku_:phantomcircuit: hah, so did I
20:17:17maaku_:when I was at NASA conference travel support was a reward divied out by managers
20:17:39maaku_:Hawai'i, Nice, Rome ... be a good little researcher and you'll get a taxpayer-paid vacation
20:18:55TD:BlueMatt: you're going?
20:21:30amiller:financial crypto is always in carribbean
20:21:40amiller:i found this documentary about the first financial crypto conference
20:22:00amiller:http://vimeo.com/23562982
20:22:05amiller:but it's in japanese so i can't understand any of it
20:23:33maaku_:well, the carribbean is not an inappropriate place for international finance... although barbados isn't really known for that
20:23:46amiller: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:00amiller:it was initially at Anguilla
20:24:06roidster:roidster is now known as Guest65511
20:24:13maaku_:amiller: sshhh this channel is logged
20:24:50amiller:the cypherpunks were remarkably ambitious back in the day
20:25:19amiller:it's like a big line of research and development largely fueled by high quality science fiction
20:25:34petertodd:amiller: ambition is a common thing when you don't know the limitations of your tech :P
20:25:53amiller: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:26petertodd:well, bitcoin *did* solve a serious limitation
20:26:46petertodd:or, we think it solves it, maybe :P
20:26:53BlueMatt:TD: yea, Ill be there
20:27:10amiller:BlueMatt, TD i'll be there too
20:28:07TD:BlueMatt: lucky!
20:28:20phantomcircuit:petertodd, the limitations are largely political there
20:28:23TD:maybe i'll go next year
20:28:32BlueMatt:TD: why not just grab a ticket?
20:28:36phantomcircuit:you're only a sovereign nations as long as everybody else agrees you are
20:28:40BlueMatt:TD: or...you've got plans around then, no?
20:28:41TD:i'm already out for half of feb
20:28:50TD:i need to do some work at some point :)
20:28:56BlueMatt:TD: out of what? I thought you were done working?
20:29:06phantomcircuit:im waiting for someone to start a cash only bank somewhere
20:29:06TD:i mean, i'm on vacation for half of feb
20:29:14phantomcircuit:that'll be amusing
20:29:55BlueMatt:TD: so take more :)
20:30:02TD:will think about it
20:30:04jgarzik:phantomcircuit, amusing until they become a big robbery target anyway...
20:30:17BlueMatt:TD: I think you've got till like tomorrow before rates go up on the conf itself
20:30:31BlueMatt:oh, nope, too late already
20:30:37BlueMatt:though its only like 200 extra
20:30:43phantomcircuit:jgarzik, security for cash is something that banks have lots and lots of experience with
20:30:45shesek: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:47BlueMatt:thats nothing for a bitcoin mogul like TD :)
20:30:53phantomcircuit:that's basically just a matter of money for security
20:31:00jgarzik:phantomcircuit, ever decreasing amounts of experience...
20:31:06TD: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:08shesek:might as well just put both of them together on the same machine that's accessible to the outside world
20:31:08phantomcircuit:jgarzik, i guess
20:31:19BlueMatt:TD: ummmmm....why not?
20:31:30BlueMatt:TD: best advice Ive ever gotten: "retire early, retire often"
20:31:34phantomcircuit:jgarzik, you couldn't run such a bank in most countries anyways, so you'd probably have to hire serious security
20:31:55TD:hehe
20:32:40petertodd:shesek: you can use what sipa is now called "hardened" derivation to get around that problem
20:33:35TD:BlueMatt: will think about it :)
20:36:48shesek:petertodd, but wouldn't that mean that I need the private key to derive public keys?
20:37:41petertodd:shesek: point is you can regularly, and securely, derive a "one week only" keypair and send it to the hot box
20:37:44shesek: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:53petertodd:shesek: your master identity is still secure, making backups easier (just one seed)
20:38:34shesek:I would still need access to old weekly private keys - contracts might take a long time to finish
20:39:00shesek:it might take months, possibly years, for the user to request the script to be executed and to reveal the private key
20:39:28shesek:so I would need to make old private keys accessible too - it would only protect future keys from being compromised
20:39:40petertodd:shesek: sure, but you can always implement things like requests in advance
20:39:58petertodd:shesek: I mean, if you're waiting 1 year, is five minutes really that important? an hour?
20:40:00shesek: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:18petertodd:shesek: emphasis on known...
20:40:55shesek:if its not known, the attacker has active access and he still gets access to every new hot private key
20:41:44petertodd:shesek: not necessarily true, e.g. someone compromises some backups
20:41:57shesek: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:16shesek:yeah, that's right too
20:42:43petertodd:main thing is don't make an infrastructure where that kind of thing is impossible; give yourself some flexibility
20:42:49shesek:btw, can't I just do "hardened" derivation with a simple H(seed||nonce)?
20:43:02petertodd:that's what hardened derivation is
20:43:06shesek:it seems to have the same properties
20:43:29shesek:really? it seems more complicated from the looks of the wiki :P
20:43:48shesek:I haven't looked really closely, just skimmed it now that you mentioned it
20:44:07petertodd:shesek: heh, read it carefully :) also, the BIP32 doc is at http://github.com/bitcoin/bips
20:44:24shesek:btw, I was thinking about going with Lua
20:44:34shesek:it seems to have a very strong sandbox execution model
20:44:47shesek:and it allows for some pretty cool DSLs
20:45:03petertodd:dunno much about Lua
20:45:12petertodd:anyway, write some actual scripts that do actual things people might want first!
20:45:25petertodd:stop obsessing over the language until you get a better handle on what it might need to actually do
20:45:50petertodd: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:19shesek:well, I did! I have a mostly working version, with a "return 1" as substitute for script execution
20:47:38shesek: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:58shesek:and another that takes a script and returns ckd'(master, H(H(script)||script(input)))
20:48:25shesek:ugh, just script(), without input
20:48:41shesek:wanted to add a way to add inputs to scripts, but I didn't do that for now eventually
20:48:58petertodd:sounds good, now go write some scripts that solve actual problems for people :)
20:49:08petertodd:believe me, that's the hardest part of this by far
20:49:53shesek:some of the more obvious things this can be used for seems a bit... problematic
20:50:14shesek:not sure I want to provide that myself, prefer to let the community or some anonymous gists to do that
20:51:11petertodd:if you don't try, how do you know if the idea is feasible at all?
20:51:22petertodd:or equally, what kind of facilities the language needs to be useful?
20:52:06shesek:well, I meant problematic in a legal way, and was referring to gambling
20:52:24shesek:I'll have to check with my attorney in what position it puts me if I provide scripts that helps facilitate gambling
20:53:16shesek:I prefer to keep some distance from that
20:53:21petertodd: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:32petertodd:if your customers have to rewrite them, so what?
20:53:51shesek:oh, right, of course, I will write a few myself
20:53:59shesek:I'm assuming the most common would be based on web scraping
20:54:00petertodd:writing the code is the easiest part of these projects you know :)
20:54:16shesek:go to some webpage, match some rules against its contents, return an outcome
20:54:16petertodd:sure, so try writing some screen scrapers and see what kind of problems they'll run into
20:55:04shesek:I work a lot with web scraping/automation in my day-to-day work, I know how they work
20:55:51shesek:the most useful things to match against an http document is css/jquery-style selectors, xpath and regex
20:56:03shesek:blah, * html document
20:56:25petertodd:ok, so that's part of the problem - what happens when those scripts don't work? when the webpage changes on you?
20:57:18shesek:I guess it has to come down to human intervention at that point
20:57:44shesek:human intervention and commented scripts that describes what the parties intended when they wrote them
20:58:07shesek:or some separate field to add "notes for the human who might need to handle that in the future"
20:58:11petertodd:indeed, so think through how that procedure might work - that's a *huge* aspect of how the overall architecture should work
21:01:30shesek:yes, that's an important part too. though human intervention is probably the least fun part of a project like that
21:02:33shesek: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:10shesek:and just let the parties decide who they trust to do the human verification
21:05:43petertodd:sure - note how in typical 2-of-4 oracle schemes the two parties can always mutually agree on the outcome themselves
21:12:59shesek:what are some interesting and useful scripts that I could provide as examples?
21:13:56shesek: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:24shesek:do you know of any states that provides public death certificates?
21:19:50petertodd:dunno really - I haven't thought much about any of that stuff
21:22:01shesek:apparently both West Virginia and Missouri provide them - but both of them exclude death certificates from the last 50 years
21:22:06shesek:which isn't really useful :-\
21:22:27shesek:unless the one getting the inheritance is willing to wait 50 years
21:23:19petertodd:all though things to automate in code...
22:34:09sipa:interesting thought-experiment altcoin: an implicit UTXO of 1 coin exists for every address in advance
22:34:22sipa:as soon as this gets any exchange value, it has a +infinity market cap
22:35:43jgarzik:heh
22:37:18michagogo|cloud:um
22:37:28sipa:well, 2^160 * exchangevalue market cap
22:37:31sipa:not actually infinite :)
22:37:46michagogo|cloud:...which also means it has a market cap of zero
22:38:11michagogo|cloud:Because there are 2^160 coins premined
22:38:22michagogo|cloud:Premined, for literally anyone to claim
22:38:29michagogo|cloud:Meaning that it would be worthless
22:38:59sipa:but maybe some fool still wants to pay for more than he can "address mine"
22:39:44michagogo|cloud:...
22:40:01michagogo|cloud:You can "address mine" millions of coins per second
22:40:09sipa:it could be made very hard :)
22:40:54sipa:but yes, i see your point - it's hard to understand why anyone would pay money for this
22:41:14Alanius:... but if creating a new address is very hard, can it be useful?
22:41:33sipa:on the other hand, i think dogecoin proves that reason plays very little role :)
22:42:34Luke-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:16sipa:Luke-Jr: right, coinjoins should be considered non-IsFromMe in that regard (not allow 0 conf spends)
22:43:32Luke-Jr:sipa: but are they, right now?
22:45:43sipa:i think so, yes
22:50:18jtimon:michagogo|cloud "You can "address mine" millions of coins per second" well, you will have to pay fees to claim those coins
22:51:48jtimon:enough to convince miners not to just fill the block with their own claims
23:02:17maaku_: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:51andytoshi: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:28andytoshi: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:08maaku_: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:37andytoshi:nope, the first paragraph is an integer scheme but after the heading `Schnorr/DSA blind signatures' you can use an EC group
23:11:07andytoshi:iirc you just need discrete log to be hard.
23:12:52andytoshi: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:47sipa:schnorr seems pretty simple to implement
23:15:01sipa:and ed25519 has multiplication and addition, which is all you need
23:15:17maaku_:andytoshi: i think there are pragmatic reasons to stick to secp256k1
23:16:25maaku_: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:07sipa:if someone has the time, i'd love to see a secp256k1 vs ed25519 benchmark
23:17:58maaku_: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:18maaku_: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:33sipa:which would ed25519 not support that?
23:18:37maaku_:which iirc slows ed25519 down by a factor of two (to within the ballpark of secp256k1?)
23:18:42maaku_:sipa: no, it does not
23:18:47sipa:why?
23:19:29maaku_:because some of the bits of the private key have to have fixed values
23:19:30sipa:so?
23:19:31sipa:ah
23:19:32maaku_:and when you do the public derivation, you don't know if that's the case
23:19:36sipa:right, that interferes
23:19:38sipa:got it
23:19:59maaku_:djb doesn't make his reasoning there clear
23:20:10sipa:on the other hand, ed25519 has batch verification
23:20:11maaku_:but part of it is for performance reasons - he's excluding slower keys
23:20:37maaku_:i just don't think we know yet if that is the only reason those restrictions are there
23:20:45sipa:right
23:21:07andytoshi:on se.crypto they believe that it's just to prevent timing attacks.
23:21:19andytoshi:iirc somebody here (adam?) emailed djb about it, didn't get a reply
23:21:29sipa:for verification, timing attacks don't matter at all
23:21:38sipa:and that's the only place where we want speed
23:22:03maaku_:andytoshi: yes, that's (an implication of) the same performance issue i'm referring to
23:22:10andytoshi: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:21andytoshi:otherwise i'd just rip that code out and forget about it
23:22:42sipa:can schnorr signatures be batch-verified?
23:22:58andytoshi:dunno.
23:23:02maaku_:so i'd like to see comparison of secp256k1 vs full-key ed25519
23:24:09maaku_:our curve can be batch-verified too, correct?
23:24:37sipa:ecdsa can be batch-verified is you have the full R point, instead of just R.x in signatures
23:25:12maaku_:oh so you need some preprocessing
23:25:25sipa:not just preprocessing
23:25:33sipa:there are two options for every y coordinate
23:25:43sipa:so you get an exponential blowup of possibilities to check
23:26:41maaku_:i see
23:26:59sipa:though recently i read something about someone actually getting a speedup from ecdsa batch verification
23:27:04sipa:somewhere on the forum
23:27:19sipa:i didn't verify or investigate it, as it sounds impossible in theory
23:28:16maaku_:* maaku_ adds one more point in the Schnorr column's tally
23:28:54sipa:i don't think schnorr can be batch verified, actually
23:32:54maaku_:gmaxwell says that the Tor project is looking to do something similar with key derivation using ed25519, so maybe something will come of that