00:01:11 Emcy has joined #bitcoin-wizards 00:01:11 Emcy has quit 00:01:11 Emcy has joined #bitcoin-wizards 00:03:37 rdymac has joined #bitcoin-wizards 00:04:14 shesek has quit 00:07:47 c0rw1n has quit 00:08:16 c0rw1n has joined #bitcoin-wizards 00:09:57 orperelman has quit 00:10:45 c0rw1n has quit 00:11:04 c0rw1n has joined #bitcoin-wizards 00:12:35 c0rw1n has quit 00:13:04 c0rw1n has joined #bitcoin-wizards 00:14:21 c0rw1n has quit 00:14:48 c0rw1n has joined #bitcoin-wizards 00:16:25 shesek has joined #bitcoin-wizards 00:23:43 Emcy has quit 00:24:18 Emcy has joined #bitcoin-wizards 00:26:51 mappum has joined #bitcoin-wizards 00:37:36 <[\\\]> [\\\] has joined #bitcoin-wizards 00:51:38 Guest43303 is now known as amiller 00:51:42 amiller has quit 00:51:42 amiller has joined #bitcoin-wizards 00:52:22 woot, i got my bitcoin paper into oakland, the fancy academic conference for bigshots 00:53:47 amiller: +1 00:54:17 i'm up there with matt green's student now :o 01:05:07 OneFixt has joined #bitcoin-wizards 01:06:43 amiller: nice! 01:07:21 it's the one about having "storage" as a beneficial side effect from a modified proofofwork puzzle 01:08:23 amiller: oh, you finally wrote a paper about forcing storage as part of pow? 01:08:32 yeah 01:08:52 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 amiller: heh, I hope you were clear it wasn't necessarily the most original idea :) 01:09:04 haha 01:09:27 (though maybe you did come up with it first!) 01:09:29 well to be fair i've been working on this idea for 2.5 years 01:09:42 it's up there in gmaxwell's crazy-shit wiki page 01:09:43 yeah, that's fine then 01:09:56 gmaxwell's only from a year ago - you've got me beat too for sure 01:12:48 this was our review submitted version http://socrates1024.s3.amazonaws.com/permacoin.pdf 01:13:17 btw i'm still waiting on coauthors for that mixcoin paper to finish responding to that forum post 01:13:43 but regarding citing you for fidelity bonds, i absolutely had cited you originally and someone else commented it out by mistake 01:14:04 mappum has quit 01:14:06 it is a pet peeve of mine to take seriously citing bitcointalk posts etc properly 01:15:39 no worries 01:16:39 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 right on, that's the only actual use i ever had in mind for this 01:19:25 my coauthors thought that storing archival data for make great public benefit was good for marketing, and since it worked, good. 01:24:03 nOgAnOo has quit 01:24:05 yeah, and technically, that's exactly what you'd be doing with blockchain data anyway 01:36:28 rdymac has quit 01:38:36 mappum has joined #bitcoin-wizards 01:40:07 rdymac has joined #bitcoin-wizards 01:47:25 DougieBot5000_ has quit 01:48:13 mappum has quit 01:50:24 nOgAnOo has joined #bitcoin-wizards 01:58:13 jtimon has quit 02:09:19 justanotheruser has joined #bitcoin-wizards 02:10:11 mappum has joined #bitcoin-wizards 02:12:46 Any major flaws with mastercoin? 02:14:40 Emcy has quit 02:16:47 mappum has quit 02:16:51 justanotheruser: yes? 02:17:07 maaku_: could you name a few? 02:17:21 As it always is with bitcointalk, I can only find positive opinions 02:17:49 justanotheruser: http://lmgtfy.com/?q=mastercoin+flaws 02:17:57 mappum has joined #bitcoin-wizards 02:17:57 mappum has quit 02:18:12 justanotheruser: what maaku said - Peter Todd - Chief Scientist - Mastercoin 02:19:02 mappum has joined #bitcoin-wizards 02:19:24 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 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 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 the chief problem probably being lack of any kind of SPV support 02:20:54 petertodd: oh, so it is unknown whether it will be fixed 02:21:12 maaku_: yes, although to what degree SPV is a good thing is itself unknown 02:21:31 petertodd, what do you mean by that? 02:21:39 justanotheruser: correct - I'm working on reviewing what specs they have right now 02:21:49 petertodd: i hope you're not on the hook for making its usd-parity voodoo work 02:22:24 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 maaku_: heh, I've got a lot of finance to learn... 02:23:14 maaku_: fortunately for economics, "work" is often a relative term 02:24:16 miners? what trust does an spv node put on miners that a non-spv node doesn't? 02:24:34 shesek: non-spv nodes verify everything, so miners can't lie to them 02:24:48 shesek: spv will accept invalid blocks happily remember 02:25:49 Does the invalid block get propogated to them? Or is the assumption that the miner is directly talking to them? 02:25:59 justanotheruser: does it matter? 02:26:01 well, some subset of invalid, it still requires the proof of work and transactions to be valid 02:26:05 maaku_: yes 02:26:13 justanotheruser: why? 02:26:27 maaku_: because I am curious which assumption this attack makes 02:26:43 it's the same assumption is what i'm saying 02:26:50 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 how do you know the identity of anyone you are connected to? 02:27:04 (I'm not 100% familiar with how spv node works exactly, so I might be wrong) 02:27:16 shesek: you should be :) 02:27:39 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 Do spv clients propagate block headers themselves? 02:28:47 they shouldn't 02:28:49 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 * :) 02:29:04 but i wouldn't trust people not to do stupid things... 02:29:38 in what ways not validating everything can it be practically abused? 02:30:37 s/it be/be 02:30:51 petertodd: any ideas on stopping the doublespend? 02:31:52 justanotheruser: they should propagate headers, but that only lets you know about what blocks exist, not if they're valid 02:32:14 shesek: correct, and remember that in practice they usually don't validate much of anything about transactions 02:32:46 shesek: like I said, it's a *social* dynamic thing, because it makes it easy for miners to change the rules 02:32:54 justanotheruser: ? 02:33:16 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 so just do this purity check? 02:33:41 justanotheruser: you're cut off "so there is no way to receive masterc..." 02:33:50 ive mastercoins in a secure fashion." 02:34:10 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 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 justanotheruser: that *is* true of bitcoin too remember, like I say, SPV nodes are trusting miners to validate for them 02:35:40 petertodd: yes, I didn't really understand his complaint 02:35:51 shesek: sure, but them rejecting those transactions does what? absolutely nothing - you don't know that they rejected anything! 02:36:10 shesek: (see fraud proofs) 02:36:21 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 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 justanotheruser: the gist of it is right, but the terminology is weird 02:36:47 shesek: a transaction may be invalid because a prior transaction input was invalid 02:36:48 petertodd: how is my terminology weird? 02:37:07 justanotheruser: "purity" 02:37:33 petertodd: I am quoting the person I quoted earlier. By purity I mean lack of doublespends 02:37:48 justanotheruser: sure, we'd probably say "correctness" 02:37:53 ok 02:39:05 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 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 petertodd: so centralize it? 02:41:39 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 petertodd: do you work for mastercoin, or are you just doing this for fun? 02:44:14 justanotheruser: I'm their chief scientist 02:44:42 justanotheruser: (paid position) 02:45:05 petertodd: okay cool. How many people work for it (if you know)? 02:45:23 it's kindof weird to say work for mastercoin because it could mean two things 02:45:42 half-dozen paid devs IIRC? (dunno exact numbers) 02:45:46 ? 02:45:57 cool 02:51:52 petertodd, ethereum is neat 02:51:57 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 it'll be lots of fun to break it horribly 02:52:07 phantomcircuit: heh 02:52:52 phantomcircuit: It seems like it will require someone to mine one really big loop to end the currency. 02:53:20 Or some more complicated attack will RAT every ethereum users HD 02:53:36 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 sound advice 02:54:16 justanotheruser: I don't really know the answere to that question yet; anything *might* not be fixable 02:55:07 justanotheruser: see the #bitcoin-dev discussion about how I managed fork coinbase's bitcoin-ruby implementation twice in an hour 02:55:23 justanotheruser: consensus is hard enough as it is... 02:56:57 petertodd: their rules were different from the rest of the network? 02:57:15 justanotheruser: bitcoin-ruby re-implements EvalScript()... 02:58:08 petertodd: and their code didn't exactly align with the rest of the network? 02:58:26 justanotheruser, it's nearly impossible to get it right 02:58:39 they got lucky that they rejected valid transactions rather than the other way around 02:58:48 phantomcircuit: really? Because of all the nuances of different languages? 02:58:56 I genuinely believe it's a harder problem than safety critical aerospace software development. 02:59:08 huh 02:59:25 I guess I am taking satoshi for granted then 02:59:45 justanotheruser: getting version #1 done is easy, making version #2 identical is a nightmare 03:00:00 gavinandresen has quit 03:00:31 petertodd: has there ever been a case where compiling to a different OS or using different flags broke the consensus? 03:00:42 justanotheruser: yes 03:00:55 justanotheruser: that's why we ship leveldb with the source 03:01:02 wow 03:01:53 justanotheruser: seriously, if the blocksize were bigger just differences in performance between nodes would be causing forks 03:03:14 petertodd: Do you know of any opcodes that haven't been used in the blockchain that would cause a fork? 03:04:11 I'm assuming all the alt-clients have taken care of opcodes already used in the blockchain 03:04:23 justanotheruser: a bitcoin core fork, or a fork between core and an alt-client? 03:04:50 justanotheruser, your assuming the alt-clients actually know what they are doing 03:04:57 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 super3: actually my question assumes the opposite 03:05:42 justanotheruser: not sure that even all opcodes have been used, let alone in all the different ways 03:06:09 justanotheruser: heck, we didn't even test every invalid opcode in the unit tests until I fixed that 03:06:09 petertodd: I can guarantee that all opcodes havent been used in all different ways ;) 03:06:24 justanotheruser: heh 03:06:51 petertodd: the test is for the opcodes functionality, or that it returns false if it is present? 03:07:51 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 petertodd: oh, I wasn't aware that an invalid opcode could be present as long as you didn't reach it 03:09:45 but I guess the only way to distinguish an opcode and data *is* by reaching i 03:09:46 *it 03:09:48 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:21:51 justanotheruser has quit 03:26:19 Ursium has joined #bitcoin-wizards 03:29:10 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 ||winning_pubkey)). 03:29:41 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 basically, the realitykeys pubkeys are generated deterministically based on the script and the pubkeys 03:32:40 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 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:33:42 justanotheruser has joined #bitcoin-wizards 03:34:16 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 why? 03:35:34 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:35:47 go1111111 has joined #bitcoin-wizards 03:36:14 oh - right! I knew about it but forgot it 03:37:09 well, you could keep the master pubkey secret too and require the server to provide the derived pubkeys 03:37:26 and still get the benefits of it being stateless and verifiable by third parties 03:37:27 exactly, the interactive case works, and is still stateless for the server 03:38:38 well, being interactive doesn't matter that much... but it was a nice addition if it were non-interactive 03:39:59 and it seems like someone already thought of every idea that I come up with, hehe :) 03:40:30 just means you're as smart as them, but came later :P 03:40:30 if I understand correctly, realitykeys currently just generate unique keys with a bitcoind instance 03:40:45 probably, or, hopefully they *assign* unique keys! 03:40:46 something like that is quite an improvement over that 03:41:57 I started writing a small nodejs app to provide an API for that 03:42:20 oh nice! 03:42:30 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:06 Muis has quit 03:43:12 cool 03:44:09 any reference I can link to to give you credit for the idea? 03:44:12 some bitcointalk thread or something? 03:45:07 shesek: reference "personal discussion" and https://bitcointalk.org/index.php?topic=260898.msg3040083#msg3040083 03:45:47 shesek: (the "reveal private keys"/hash-preimages way of implementing oracles seems to, rather surprisingly, be my idea) 03:46:12 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 shesek: I mean, there's *gotta* be someone who wrote it down first, at least the pre-images way seems obvious 03:46:47 secure sandbox? you trying to make a thing that evaluates scripts? my advice is don't 03:46:58 jgarzik has joined #bitcoin-wizards 03:47:29 well, I much prefer to just be able to feed the oracle with scripts 03:47:37 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 why not? there are secure ways to run untrusted code 03:48:05 it's not easy - javascript is probably you're best bet simply because it's already used for that purpose 03:48:09 nodejs's sandbox is pretty good (based on v8, who must have a very strong sandbox to execute webpages) 03:48:23 I think python has a sandbox in v3 too 03:48:47 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 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 you might find python is more popular with clients 03:49:36 yeah, possibly so... I'll look into that 03:52:20 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 who is blocked the rest of the time 03:52:35 or... something 03:53:02 yup, that's a very good idea 03:53:07 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 and improve on that later 03:54:27 damn it, I have too many unfinished bitcoin-related projects stacking up, and I just added another one to the list 03:54:47 so many interesting things to do, so little time to them :-( 03:54:53 * to do 03:56:47 well, you could quit your day job like the rest of us :/ 03:57:00 mappum has quit 03:57:34 mappum has joined #bitcoin-wizards 03:57:44 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 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 go1111111: http://download.wpsoftware.net/bitcoin/wizards/ has my logs. they are a bit patchy and don't go back far 03:58:31 shesek: ah, what's the company? 03:58:31 but they are still overwhelming :) 03:58:42 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 andytoshi: thank you! 03:59:17 I'm trying a way to do that with bitrated, hopefully 04:00:08 a software development company, mostly developing tools and services related to online advertising 04:00:12 shesek: might happen in the long run! 04:00:16 cool 04:00:33 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 or on someone else's money, who believes its gonna happen in the long run :) 04:01:49 nessence has joined #bitcoin-wizards 04:02:14 its not very easy though, especially because I want to keep it open source and free 04:02:45 but I believe I have a model that could work 04:03:13 well, anyway, its getting late here. good night! 04:03:18 later 04:03:46 andytoshi, do you want a big ol' chunk of my old irc -wizards logs, would you put them up there? 04:03:56 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 amiller: yeah, sure 04:04:16 amiller: apoelstra@wpsoftware.net 04:04:16 andytoshi: I've got logs from nearly day 0 too 04:04:32 mine only go back to august 2013 04:04:39 i have older ones somewhere else 04:04:43 you should take petertodd's 04:05:25 ok, thanks guys!. if you send them to me i'll put them up petertodd 04:07:01 andytoshi: sent 04:09:19 mappum has quit 04:11:35 petertodd: thx, they're up 04:11:36 mappum has joined #bitcoin-wizards 04:11:39 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 petertodd: http://download.wpsoftware.net/bitcoin/wizards/2013/ and http://download.wpsoftware.net/bitcoin/wizards/2014/ 04:15:36 andytoshi: cool. you should get rid of the joined/quit junk come to think of it 04:16:09 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 but i guess, it's a lot of noise to scroll through and i could really just look at the time 04:16:54 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 :D 04:18:37 andytoshi: leave that join in :P 04:20:21 :P will do 04:22:14 yeah petertodd was so late to the party it's silly that his logs are the furthest back :o 04:22:50 heh, I'm a stickler for archiving 04:23:02 heck, I just forced archive.org to import the whole lot of them from your site :P 04:24:30 nice. 04:24:33 :P excellent 04:25:39 justanotheruser has quit 04:29:38 CodeShark has quit 04:31:19 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 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 cool 04:40:30 mappum has quit 04:40:31 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:41:45 justanotheruser has joined #bitcoin-wizards 04:42:02 "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 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 this seems to work just as well, and is much less cluttered 04:43:39 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 do you see any disadvantage in not putting the all the pubkeys as part of the derivation key? 04:44:57 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 shesek: why do you want the user uids in there at all? 04:45:22 well, it needs to be unique per user 04:45:50 shesek: why? it's a script - it doesn't need to know who'se using it 04:46:10 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 shesek: basically, if the script ever returns true, release the corresponding private key 04:46:38 yeah, see, what you want is *arguments* 04:46:50 there are multiple keys for every script, it should know which one is to be released 04:46:57 based on the outcome of the script 04:47:37 it doesn't have to be binary - there could be many outcomes from the script execution, each corresponding to another key 04:48:23 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 H(outer) depends on H(inner) 04:49:01 the crypto-code equivalent to functional programming currying 04:49:49 so each outcome has a separate script that returns a boolean about that outcome being true 04:50:11 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 and each user would only ask the server to evaluate his own outcome's function, ignoring the rest? 04:51:09 that's exactly how a theoretical implementation could do it 04:51:15 yeah, I just the script's return value as part of the preimage for the derivation key 04:51:30 I think a single script is somewhat nicer to work with 04:51:44 yup - it's not that your uid thing was wrong, it just gave people the wrong impression about what was happening 04:52:05 justanotheruser has quit 04:52:12 well, its just something to uniquely identify the user/outcome that's shared with the script 04:52:20 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 I might after all be using this for something that doesn't involve users! 04:53:04 right... might be the wrong name 04:53:48 names are important! 04:53:57 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 since in that case it has a one-to-one relation with the users pubkeys, it kinda makes sense 04:54:21 but something more general is probably better 04:55:11 I think it probably makes sense to base that on the outcome - its also more natural with how the script would be written 04:55:36 RoboTeddy has quit 04:56:17 tromp_ has quit 04:56:37 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:56:51 tromp_ has joined #bitcoin-wizards 04:57:08 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 hmm... if the script and its outcome are not unique and could be re-used, this might cause some problems 04:58:41 they would already have a private key from the previous runs 04:59:28 though I think scripts should be immutable - do you see any case where the same script returns different results? 04:59:55 maybe if there's some "who won the last game" page that's being accessed from the same url or something 05:00:52 I could add some unique nonce in there 05:01:17 maybe just based on everyone's pubkeys, like I did originally 05:01:18 that the outcomes may not be unique should be telling you something! 05:01:25 tromp_ has quit 05:01:44 http://blog.ethereum.org/2014/02/03/introducing-ethereum-script-2-0/ 05:01:47 most scripts will actually have some core generic function - look up data on the blockchain - and an outer wrapper 05:01:55 JMP disappears, heh 05:01:56 jgarzik: see above 05:02:41 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:00 justanotheruser has joined #bitcoin-wizards 05:03:16 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 what would that outer wrapper do? provide it with some arguments? 05:04:12 exactly! provide arguments to the function that actually implements things 05:04:40 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 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 so long as everything is hashed, absolutely not 05:06:15 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 yup 05:07:27 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 let people host re-used scripts on gist/github/pastebin and allow to import them 05:08:20 what do you mean by import? 05:08:41 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 absolutely 05:09:43 say someone creates a repo on github with some commonly used scripts, allow scripts to "import github:john/oraclescripts/sports/football" 05:10:07 yeah... think through how that could be attacked... 05:10:23 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 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 well, the script could be changed in the future, after getting used 05:11:07 if it's changed, then how do you know users agreed to the change? 05:11:32 no, I agree - this is obviously bad 05:11:36 heh 05:12:09 probably best to commit to the imported script hash at the time of creation 05:12:17 or just embed imported scripts inline 05:12:43 (which is just another way to commit to them at the time of creation, really) 05:13:00 exactly 05:13:12 if your server accepts a tarball and commits H(tarball) that's fine 05:14:26 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 too bad async code looks so ugly :-\ I'm aiming for something simpler enough for non-programmer to use 05:15:11 something that feels more like a DSL than actual code 05:15:53 I think you're going to find that actually using this stuff securely is basically a DSL 05:16:17 justanotheruser has quit 05:16:18 justanotheruser has joined #bitcoin-wizards 05:22:20 shesek: if only some language had integrated coprocessing.. 05:24:03 Luke-Jr, ? 05:26:48 shesek: coprocessing makes async as clean as sync 05:27:00 well, kinda. 05:27:54 well, yeah, async code could be clean (and nodejs now supports `yield`, which makes that somewhat nicer) 05:28:21 but async isn't really an advantage here, every script execution is sandboxed 05:28:46 so there's no real reason to go after an async languages specifically 05:29:25 well, unless the sandbox doesn't involve a separate thread... but it usually does 05:33:25 tacotime_ has joined #bitcoin-wizards 05:38:17 tacotime_ is now known as tt_away 05:43:02 justanotheruser1 has joined #bitcoin-wizards 05:44:28 justanotheruser1 has quit 05:44:28 justanotheruser1 has joined #bitcoin-wizards 05:46:30 justanotheruser has quit 05:49:10 RoboTeddy has joined #bitcoin-wizards 05:50:13 RoboTeddy has quit 05:50:19 RoboTedd_ has joined #bitcoin-wizards 05:54:21 justanotheruser has joined #bitcoin-wizards 05:57:25 justanotheruser1 has quit 05:57:46 mappum has joined #bitcoin-wizards 06:02:44 Muis has joined #bitcoin-wizards 06:07:22 mappum has quit 06:17:29