00:01:04 ghtdak has quit 00:06:11 spinza has quit 00:06:12 spinza_ has joined #bitcoin-wizards 00:15:52 ghtdak has joined #bitcoin-wizards 00:32:57 jtimon has quit 00:35:52 jgarzik has quit 01:04:54 wyager has joined #bitcoin-wizards 01:19:00 thanks andytoshi 01:22:24 From #p2pool: 01:22:25 17:20 < owowo> gmaxwell: can you explain why ppl are mining on those BIG pools? 01:22:28 17:21 < owowo> I don't get it, they must get more coin there. 01:22:32 home_jg is now known as jgarzik 01:23:06 oh he says he was kidding now. 01:23:13 dude just nearly dodged getting face-stabbed. 01:27:28 bigger pools could operate on lower margins, so miners could benefit from the lower fees 01:27:54 I'm not really familiar with pools though, so I'm not sure if that's true in practice 01:27:56 shesek: except that there are smaller 0 fee options (including p2pool) 01:28:06 the biggest pools have historically had the highest fees. 01:29:18 (the exception being ghash.io, and thats weird on a couple levels including the that its widely understood that the owners of ghash.io own a majority of the hashpower on their pool) 01:29:44 doesn't ghash's hashpower comes mostly from cex? 01:30:45 shesek: yes, common ownership. 01:30:50 which is physically owned by them, but should be "owned" by other people 01:31:14 though as long as they have physical ownership over the hardware, its really a matter of trusting them 01:31:14 yea, no clue how much of cex is "owned" by other people— they don't disclose that, the prices are off the charts. 01:32:07 in any case, ignoring ghash.io it's always been the case that the largest pools had the highest fees, almost nearly in order. 01:32:12 btw, about p2pool, doesn't it have a much higher orphan rate that would really effect payouts for the worse? 01:32:22 wow 01:32:24 * gmaxwell cries 01:32:41 shesek: no, P2pool's orphan rate is lower than other pools by an order of magnitude. 01:32:55 sorry, I'm really not familiar with p2pool and pools in general, I'm just asking to educate myself better :) 01:33:24 My crying is because it's just a replay of the constant fud that circulates and has no basis in reality. :( It's not your fault the whole world is dumb. 01:33:27 so it seems like a lot of people are misinformed about that, I've read that in multiple places 01:34:40 and I wonder how it worked out like that with the pools fees 01:34:55 and why people keep joining the bigger pools if that's the case 01:35:14 it might be psychological, where people think that bigger pools are better for some reason 01:35:37 they face a choice paralysis when they need to pick one, and go after the largest one hoping that its somewhat better 01:35:52 back in early 2012 there was a span when p2pool had a somewhat high orphan rate, it's not clear if it was just bad luck or a real problem but major work was done to improve it. The end result has in the last several months had only 2 orphans against like 1627 blocks. Compared to, say, eligius which has had somewhat more than 1% orphans (also typical for other pools) 01:36:47 Overall p2pool has solved about 107% of the blocks you would have expected based on its observed work done. 01:37:20 shesek: oh a lot of people misunderstand why pooling exists, they think that mining is a race— and in a race the fastest party always (or almost always) wins. 01:37:37 They talk about needing an X TH miner in order to "keep up" and things like that. 01:37:48 Following that logic, the biggest would be best. sooo. 01:38:16 also explains the inverse fee relationship. They think the biggest is best but attempt— without the aid of math or understanding— to balance that against fees. 01:38:43 educating miners better could definitely help here, some more official resources about that could do some good 01:39:12 an "introduction to mining" on bitcoin.org or something 01:40:25 I do think there's some choice paralysis in play here too. Miners don't really have any effective way to pick a pool, which makes that choice somewhat hard... I guess that some just pick the biggest by default 01:40:43 yes, "so many other people choose it, it has to be good" 01:41:13 we've also seen some "large pool cycling" where the second or third largest pool gets a lucky run and shows up at the top of the charts... and then it becomes the largest pool. 01:42:05 P2pool has a bunch of UX stupidity that doesn't help— even feeds into the misunderstandings. 01:42:16 perhaps something that helped pick a pool, with a weighted random based on the inverse popularity 01:42:39 there really is only one pool we should be recommending, p2pool. It's the only suriving pool thats a decenteralized system. 01:42:51 could be marketed as "help save Bitcoin from centralization by using this!" 01:43:03 warren has been trying that. 01:44:18 setting up an "whatpoolshouldipick.com" that simply gave one pool in a big font with a link, explaining how the selection works, could be nice 01:44:37 and help overcome that choice paralysis 01:44:45 but yeah, long term, p2pool is much better 01:45:07 but its still somewhat inaccessible to users and requires setting up a full node 01:45:43 I saw a thread about this on bitcointalk, it would really help if they setup a nice looking website with instructions and easier way to get it up and running 01:45:59 'they' 01:46:10 it's not like there is a P2pool company. 01:47:00 well, yeah, it should really be a community effort 01:47:06 not really "they", more like "we" 01:47:27 At the moment setting up a full node is so burdensom that its sort of the long poll in the tent. Sync really needs to be fixed. 01:49:14 what are your current thoughts on the best way to address this? 01:50:22 It's addressed by sipa's headers first sync work. 01:50:45 But the code is immature. 01:52:42 sipa closed https://github.com/bitcoin/bitcoin/pull/2964 saying that he's working on something better, is it public yet? 01:52:52 can't seem to find a newer pull request / issue 01:54:20 DougieBot5000 has quit 01:54:40 shesek: he has been pipelining the changes since it seemed to be a bit much at once. https://github.com/bitcoin/bitcoin/pull/3370 02:02:05 cool, I haven't really kept up with developments on that front, looks like a good solution 02:05:21 gmaxwell, what do you think about that website I suggested? I think it could be pretty cool as a go-to solution for picking a pool 02:05:42 can even be provably fair by basing the "random" choice on the user's ip and user agent 02:10:26 shesek: being 'fair' isn't desirable, it's just an invitation to open up 1000 scam pools that will eat people's money. 02:10:27 HobGoblin has joined #bitcoin-wizards 02:10:50 HobGoblin is now known as Guest32748 02:12:05 gmaxwell, the pools would obviously need to be reputable and vetted manually, but from the "pool" of pools that are available the random choice based on inversed popularity could be provably fair, to ensure its not favoring any specific pools 02:12:47 amiller has joined #bitcoin-wizards 02:13:00 amiller is now known as Guest53598 02:14:09 espes___ has joined #bitcoin-wizards 02:14:21 pigeons_ has joined #bitcoin-wizards 02:14:59 espes__ has quit 02:14:59 pigeons has quit 02:14:59 UukGoblin has quit 02:15:00 petertodd has quit 02:15:00 amiller_ has quit 02:19:30 petertodd has joined #bitcoin-wizards 02:29:17 nessence has joined #bitcoin-wizards 02:43:51 pigeons_ is now known as pigeons 02:53:05 kyrio has joined #bitcoin-wizards 03:05:31 wyager has quit 03:05:52 wyager has joined #bitcoin-wizards 03:38:06 Guest53598 is now known as amiller 03:38:09 amiller has quit 03:38:09 amiller has joined #bitcoin-wizards 03:45:56 wyager has quit 04:42:02 wyager has joined #bitcoin-wizards 04:46:30 MoALTz_ has joined #bitcoin-wizards 04:47:38 roidster_ has joined #bitcoin-wizards 04:48:59 maaku_ has joined #bitcoin-wizards 04:49:41 mappum_ has joined #bitcoin-wizards 04:55:21 wyager has quit 04:55:22 ghtdak has quit 04:55:22 mappum has quit 04:55:22 roidster has quit 04:55:22 maaku has quit 04:55:23 MoALTz has quit 04:58:41 ghtdak has joined #bitcoin-wizards 04:59:36 wyager has joined #bitcoin-wizards 05:05:35 fagmuffinz has quit 05:06:18 fagmuffinz has joined #bitcoin-wizards 05:06:58 Taek42 has quit 05:07:26 warren has quit 05:09:31 Taek42 has joined #bitcoin-wizards 05:12:25 warren has joined #bitcoin-wizards 06:14:58 justanotheruser is now known as Coyote 06:15:14 Coyote is now known as justanotheruser 06:17:40 Has anyone made any proposals for anonymity networks upon which things like coinjoins and coinswaps could take place? 06:18:05 justanotheruser is now known as NotJustanotherus 06:18:15 NotJustanotherus is now known as justanotheruser 06:22:51 I left the Jesuscoin-killing script (replaying the Bitcoin blockchain) running overnight 06:23:03 Only gotten as far as block 234853 06:25:37 michagogo|cloud: nice, you actually made the magic changing thing 06:25:57 Malefice has quit 06:26:02 justanotheruser: I actually tweaked linearize.py to do that 06:26:16 michagogo|cloud: does jesuscoin have a community at all? 06:26:17 But before I actually ran it, I realized that I didn't need to 06:26:27 This script also works: http://0bin.net/paste/OFWqJ7Lj0k0GO0o4#Rd6uP8VFxwv3SEO4HQAwtF+Vy5M3ZtaUrrKC9m3qI+w= 06:26:33 justanotheruser: Not really, afaik 06:27:14 michagogo|cloud: Is this only possible because jesuscoin has all bitcoins defaults? 06:27:20 justanotheruser: Yes 06:27:27 It's a 100% clone of Bitcoin 06:27:38 Specifically the genesis block and parameters 06:29:36 Oh my god 06:29:42 that is so stupid 06:29:52 And hilarious 06:31:22 heh 06:31:33 I wonder why no one did this for ixcoin or i0coin 06:31:47 well I guess ixcoin had a premine, but i0coin it might be possible 06:52:28 wyager has quit 06:58:40 Bitcoin currently only allows turing incomplete scripts. Please tell me why an altcoin that has a limit on both block size and cycles executed to verify a blocks transaction (allowing turing complete scripts) is a bad idea. 07:02:56 roidster_ has quit 07:07:04 wyager has joined #bitcoin-wizards 07:50:19 wyager has quit 08:10:02 Malefice has joined #bitcoin-wizards 08:21:08 nOgAnOo has joined #bitcoin-wizards 08:21:10 nOgAnOo has quit 08:21:56 nOgAnOo has joined #bitcoin-wizards 08:21:58 nOgAnOo has quit 08:22:09 nOgAnOo has joined #bitcoin-wizards 08:22:12 nOgAnOo has quit 08:22:22 nOgAnOo has joined #bitcoin-wizards 08:22:24 nOgAnOo has quit 08:22:35 nOgAnOo has joined #bitcoin-wizards 08:22:37 nOgAn0o has quit 08:22:37 nOgAnOo has quit 08:22:48 nOgAn0o has joined #bitcoin-wizards 08:22:48 nOgAn0o has quit 08:35:52 justanotheruser, it's not a bad idea, experimentally. it might be a foolhardy store of value 08:36:22 nsh: why? 08:37:16 because there's no explicit incentive analysis that guarantees behaviour converges towards the subset of actions that preserve integrity 08:38:13 there could be weird effects that stop people self-interestedly cooperating to keep value stable 08:38:23 (there could also not) 08:38:23 technically, if you limit the number of cycles then it's not turing complete 08:41:54 Taek42: the scripts were never turing complete 08:42:17 and there can only be a limited number of scripts per block, therefore the blocks were never turing complete 08:42:20 I know that, was just knit-picking 08:43:02 <_ingsoc> _ingsoc has joined #bitcoin-wizards 08:43:09 Taek42: oh, I misunderstood. You were referring to my original statement where I said this could be turing complete. 08:43:11 I was wondering if it would be possible to build a higher-level lanugage on bitcoin script 08:43:17 right 08:43:36 Image a C-like that output bitcoin-script instead of assembly 08:43:47 michagogo|cloud: jesuscoin i love it 08:43:48 Yes, it wouldn't be turing complete, but it would allow for turing complete scripts that get cut off if they run too long (so pseudo-turing-complete) 08:44:24 well not cut off, but only be accepted if they have a limited run time 08:44:27 As long as you have a reliable way of measuring where the scripts get cut off 08:44:30 <_ingsoc> _ingsoc has left #bitcoin-wizards 08:44:39 because all hosts would need to agree if a script took too long to terminate 08:44:48 Taek42: it would be like measuring where transactions get cut off. The miners determined it 08:44:55 (in terms of size) 08:45:02 hmmm 08:46:29 ghtdak has quit 08:47:01 ghtdak has joined #bitcoin-wizards 08:47:21 The transactor could say how many cycles the script should take in the header. If it takes more than that, then the miner can spend the transaction themselves maybe? (This is the best way I can think of preventing DoSing miners with large scripts 08:47:51 I suppose that would limit the ability to give people scripts that they can spend later though 08:48:06 well actually nvm the statement directly above this 08:48:38 you should build these scripts so they can't run arbitrarily longly, otherwise someone will donate the tx to miners 08:49:48 nsh: Are you saying this system would hurt stability of the price? 08:50:44 not necessarily, just that things tend toward instability as the degrees of freedom increase 08:51:40 nsh: when you say degrees of freedom do you mean it in the mathematical sense, or could I substitute degrees with amount? 08:51:46 nsh I'm not sure I agree with that 08:52:00 mathematical, but perhaps i'm wrong 08:52:50 certainly in mechanical dynamic systems you are more likely to exhibit chaotic behaviour when you have more (dynamically coupled) degrees of freedom 08:52:52 nsh: could you explain what a degree of freedom is in these terms then? 08:53:16 "In mechanics, the degree of freedom (DOF) of a mechanical system is the number of independent parameters that define its configuration. It is the number of parameters that determine the state of a physical system" 08:53:36 nsh: Are you saying bitcoin price would be more stable if it didn't have p2sh? 08:53:59 no 08:53:59 shesek has quit 08:54:44 doesn't p2sh add a DOF? 08:54:45 the price stability derives from the network stability, which derives from everyone's behaviours being constrained (by "enlightened self-interest") to keep things working in some defined manner 08:55:02 yes, but you're making stronger assertions :) 08:55:55 depends on what you mean by network 08:56:12 nsh: Does another DOF hurt network stability? 08:56:13 bitcoins price instability derives from the fact that the volume in circulation can't adjust to the demand 08:56:21 and the demand has been all over the map 08:56:34 justanotheruser, depends 08:56:54 what i proposed was that as the number of DoFs increases then the entire system _tends_ towards more unstable behaviour 08:57:26 hm 08:57:42 mappum_ has quit 08:57:44 to go from that to saying adding one DoF neccessarily increase instability requires some additional evidence 08:57:49 I'm not sure if I agree with you. I don't think it makes in less stable unless it makes it less secure 08:57:52 and anyway, i'm probably just smoking crack 09:00:29 Another advantage I see in this is a limit on CPU intensive scripts. No longer will we have to worry about transactions that take a long time to validate but are inexpensive because they take up little physical space 09:19:18 the reason why turing complete scripts are a bad idea is because you cannot determine the cost of running without running 09:19:56 even if it's not actually turing complete and limited to some high amount of cycles 09:21:50 which means easy DoS attacks? 09:22:53 If you had it in a sterile environment (no malware issues), I would think that the only problem would be large scripts (too much data) or long scripts (too much runtime) 09:23:07 wouldn't limiting the cycles prevent that? 09:27:48 if one transaction costs 1000 times more to validate than another, you need pretty good policying to make sure it is deincentivized 09:31:16 or you could charge each transaction equal to the theoretical limit on how expensive it is 09:31:21 then the miners will be happy 09:31:36 or you could wait to charge until you know how many clock cycles were spent validating it 09:32:04 Malefice has quit 09:35:11 the problem is that mining is constrained by size, so will end up picking transactions with sufficient fee per byte 09:35:34 if you want the same incentive for execution, you need a hard limit per block on validation cost 09:35:55 which complicates optimal transaction selectiom 09:46:07 jtimon has joined #bitcoin-wizards 10:06:03 hnz has quit 10:11:08 hnz has joined #bitcoin-wizards 10:18:06 Guest32748 has quit 10:18:06 Guest32748 has joined #bitcoin-wizards 10:18:10 Guest32748 is now known as UukGoblin 10:30:46 brisque has joined #bitcoin-wizards 10:38:59 orperelman has joined #bitcoin-wizards 11:17:11 go1111111 has quit 11:42:46 <_ingsoc> _ingsoc has joined #bitcoin-wizards 12:44:19 <_ingsoc> _ingsoc has quit 12:56:44 adam3us has quit 13:13:25 gigavps has joined #bitcoin-wizards 13:13:38 adam3us has joined #bitcoin-wizards 13:16:26 Krellan has quit 13:20:17 Krellan has joined #bitcoin-wizards 14:02:59 gigavps has quit 14:06:07 <_ingsoc> _ingsoc has joined #bitcoin-wizards 14:12:06 adam3us has quit 14:22:21 Luke-Jr has quit 14:23:13 Luke-Jr has joined #bitcoin-wizards 14:32:02 Luke-Jr has quit 14:32:23 Luke-Jr has joined #bitcoin-wizards 14:40:09 sipa: I really don't see what the big deal is; you have to execute the script anyway yourself to validate that the transaction is valid. Adding opcode counters to Eval() isn't a big deal. 14:40:22 <_ingsoc> _ingsoc has left #bitcoin-wizards 14:40:42 sipa: sure there's some theoretical static analysis stuff you could do, but it's consensus critical - keep it simple and stupid 14:47:33 adam3us has joined #bitcoin-wizards 14:53:18 petertodd: suppose i make a script which has fee for 100000 iterations, but runs for 100001, so it can't validate 14:53:30 is there a nice way to prevent a DoS along those lines? 14:54:43 andytoshi: probably not, but at least that's a local DoS attack - lots of those 14:55:14 andytoshi: anyway, a csript can't exceed the limit for a whole block by definition, and block propagation has to be fast, thus it can't be that much of an issue 14:55:22 yeah, fair enough, i guess people are free to make IsStandard reject anything that might take too long for their system 14:55:34 also a good point 14:55:56 andytoshi: yup 14:56:18 fagmuffinz has left #bitcoin-wizards 14:56:22 fagmuffinz has joined #bitcoin-wizards 14:56:32 andytoshi: and static analysis is all well and good, but like I say, it'd be in consensus critical codepaths... 14:57:05 yeah, perhaps it's a meta-problem that people will try to do it if they see a benefit 14:57:27 lol! 14:58:07 the real problem i see with turing-completeness is that the block limits you'd have to put on it are too stringent for anything cool to be done 14:58:37 OTOH if we could do snark-validation so only one person (potentially the transactors themselves) ever have to compute it, i'd be happy with it 14:58:45 yeah, but like I say, until we get SCIP you have to have limits because you have to actually run the code to validate! turing completeness has nothing to do with that 15:09:17 orperelman has quit 15:19:40 roidster has joined #bitcoin-wizards 15:22:38 andytoshi: certantly the block limits you'd have to have would be too stringent to do anything interesting if the instruction set weren't very high level, and if we had to assume execution via a very dumb interperter. 15:22:50 the latter is probably true, the former not so much. 15:23:12 This isn't to say I'm necessarily a fan of turing complete script. I do think getting an execution counter right is hard. 15:23:52 gmaxwell: just do a MAST design and make sure your MAST hash function is more costly than anything else... 15:24:14 btw about pegged side-chain, i think the actual spv proven side->main protocol would not need to be run. its just a threat that it could be run. cross chain-atomic swaps can do the actual swap. and market makers can do it. if volume dries up or mkt maker low on funds he can clear via side->main spv proof. 15:24:37 petertodd, what's MAST? 15:24:39 adam3us: it needs to be run some, but perhaps not much. 15:24:55 nsh: merkleized abstract syntax tree 15:25:09 ah, ty 15:25:19 petertodd: I don't think it would be efficient to force every branch to be mast, besides loops with unknown depth can't be seperately mast-ed. 15:25:58 gmaxwell: yes. it depends on the willingness of mkt maker to hold btc funds someone with big long term btc holdings anyway would be willing to mkt make all-day-long for 0.1% or whatever, its near free risk free money for executing a script. its a form of interest for btc holdins 15:26:15 gmaxwell: which is my serious point: turing completeness often gives you more efficient code in cpu and code size 15:26:25 adam3us: I mean, you'd need to have at least one execution to get funds there in the first place. 15:27:12 petertodd: certantly low level opcodes do not. 15:27:52 adam3us: but yea, that was part of my point when we previously discussed. It can be expensive because it's not a primary daily mechenism. 15:27:55 gmaxwell: agreed. mkt makers might need to do rare large tx in which ever direction is leading to a liquidity exhausting direction. but the mkt maker spread should be tiny as anyone holding btc can do it, and they can do it with airgap security if they want trezor/armory so there should be lots of security 15:28:29 gmaxwell: agreed. i think everything i just said was in the original thread. just emphasizing how cool that is :) 15:29:11 sipa: I think you could perhaps resolve the selection complication by just counting each byte as one instruction too, and have only an instruction limit. Then at least the optimization can remain in one dimension. 15:29:44 I still think implementors will totally screw up their instruction counting, esp when slower scripts start driving them ot JIT. 15:30:09 it might help if every signature needed to have its final instruction count with it, and they're forced to match exactly. 15:30:56 gmaxwell: its the missing part of my hypothesis that a 1-way peg is already close to plausible for mkt maker to fill the gap, if there is eg some long term chain migration plan. in this way no migration is necessary. 15:31:37 nannyboo has joined #bitcoin-wizards 15:32:51 gmaxwell: pay per cycle. yes seems plausible, but may create lumpy work load for nodes. maybe processing with in a given time-frame becomes critical to the semantics of the tx even. the point of TC would be to use it as a meta-programming language to define new coins and rules. eg in this kind of system something like p2sh change is just a script with no system code changes. a script can define a new concept 15:33:36 yea, I'm still not arguing letting validation become expensive is a good idea. :P Just filling out the idea. 15:34:43 nannyboo has quit 15:34:45 gmaxwell: but u have to wonder about the safety of that. btc script is intentionally constrained and even then people were value scared enuf to disable most of it. general script are even disabled right (only certain pre-cooked ones allowed)? this on the other hand may allow a clever set of scripts to attack each other, and 15:35:37 Implementers currently get script execution all wrong and it's already quite simple. 15:35:51 gmaxwell: so somone creates a btc/usd call option, and someone else creates another script to do something else or a competing call option and it steals all the money from the other call options. its like redcode 15:36:19 adam3us: I don't think we're ready to have scripts run on thier own - creates consensus issues about when a script is supposed to run! 15:37:56 DougieBot5000 has joined #bitcoin-wizards 15:38:03 gmaxwell: even if the interpreter is correct (single implementation = spec satoshi style) i am not sure about the redcode game issue 15:38:13 redcode game? 15:39:27 petertodd: never played it but http://en.wikipedia.org/wiki/Core_War 15:39:44 adam3us: ah! yeah that's a classic 15:39:48 petertodd: users battle for control of the cpu with hostile code 15:40:57 Interesting thought: transactions and the blockchain are a way of stringing multiple bits of code together in a DAG. 15:41:30 adam3us: certantly that kind of ecosystem would create greater incentives for reorgs. 15:42:22 petertodd: i have thought about making a blockchain-based haskell-like language 15:42:28 sadly, i could see no point to it 15:43:30 andytoshi: I had the similar idea of doing a HSM with merklized forth actually - pretty much the exact opposite direction in terms of implementation complexity 15:44:22 adam3us1 has joined #bitcoin-wizards 15:45:06 hsm == Hierarchical storage management ? 15:45:30 hardware security module 15:46:11 gmaxwell: ah, that's what i thought, but i didn't see the connection to merklized forth 15:46:22 gmaxwell: but even if (hypothetically) the incentives worked, and the interpreter escape issue was magically solved, and program counter issues avoided... i am still wondering if its fundmentally unprovably dangerous 15:46:58 andytoshi: it's more because forth is incredibly simple, so it's more likely you'd actually get the implementation right 15:47:16 gmaxwell: see i mean it defines a language for writing bitcoin functions, new script functions, new semantics for value transfer or whatever, its fully general; but in such an environment would u not be in a core-war / redcode scenario is my point 15:47:28 andytoshi: yet forth still can do lisp-like tricks by doing data as code 15:48:02 petertodd: oh, i see 15:48:48 adam3us has quit 15:48:55 i should've looked up forth instead of hsm :P all i know is 'stack-based language' 15:48:59 adam3us1: I'm not sure if it would be core-war or not. If resource constraints work they'd be fighting the resource constraints not each other. Certantly lots of people would lose money by writing dumb code that can be tricked. "LOL I integer overflowed your transaction and took all your monies!" 15:49:02 gmaxwell: its almost but not quite, like you linked a remote execution of java byte code for fees and feature extension ito the bitcoinj - in theory flexible - in practice dangerously generic 15:49:51 and yes, I think it would be very very hard to make safe in a single implementation, and exceptionally hard to safely reimplement. 15:50:22 gmaxwell: i mean that one could just take your private key and be done. but yes exactly, the question is beyond that even competently written script extensions written in a generic jvm bytecode kind of level be systematically safe from any other byte code string that could be later run in the competing ecosystem 15:50:41 This is why I prefer the path of using SNARKs of some kind for more complex scripts. 15:50:54 it seems that any instance of 'breaking out of the sandbox' would be a forking scenario, since it'd probably depend on the memory layout of the targets 15:51:35 adam3us1: I mean, right now eligius isn't using a multisignature address for the emergency pool address because they don't know how to go forward on making sure their prefered script formulation is safe. 15:51:57 gmaxwell: well snarks just mean that u dont run the code, you run the verifier on the proof the code was run; it still vulnerable if it is as self-extensible as TC arbitrary vm bytecode level code 15:52:09 gmaxwell: you mean they don't have the tools to just go make a scriptSig to try spending it? 15:52:15 andytoshi: maybe, overwriting the behavior of one other opcode might be possible just with a constant offset. 15:53:44 petertodd: they want to have a {a and b} or {{a or b} and 2 of 3{c,d,e}} sort of script. They came up with one, but were not completely confident that their coding was flawless (or if unexpected behavior in op_if would let funds get stolen) 15:54:28 adam3us1: at least there is no "code escape" bug in the snark case. Or consensus-criticial-implementation-consistency bugs. 15:54:34 adam3us1: are you talking about finding bugs in the snark circuit (which is commited to in the preprocessing stage) itself? 15:54:36 gmaxwell: ah, did they do the "op_if" as "select block of code" style? 15:54:37 only the risk that you write a bad script. 15:54:47 gmaxwell: i am thinking it may have even some mathematical provability limits. if u consider the near infinite (finite because of program counter limit per time-slice) set of computable functions how can you generically prove that there exists no other function that can damage teh intended properties of the former extension function when used by anyone. 15:55:08 gmaxwell: correct on the code ecsape and interpretation fork 15:55:21 petertodd: they did two checksigs and accumulator to count how many worked, and if its not two, they drop into an op_if block that checks the accumulator for one, and runs a check multisig. 15:55:58 andytoshi: no i am just saying if each and every user can go wild and create bitcoin script language extensions dynamically how do u know the resulting ecosystem will be safe after each dynamic new feature is added. it is maybe mathematically undecidable 15:56:03 adam3us1: sure, or— "You can steal my coins if you can find the discrete log of 0xdeadbeef" 15:56:21 adam3us1: oh, gotcha, still on the redcode scenario 15:57:24 gmaxwell: right, see I would do that as op_if 2 a b checkmultisig else if a checksigverify else b checksigverify endif 2 c d e 3 checkmultisig endif 15:57:45 gmaxwell: but these TC extensions are stateful. so if there is any rational logic to disabling simple things like XOR script, this is like letting anyone define new opcodes and higher level functions running arbitrary byte code. how is that safe in comparison 15:58:29 gmaxwell: spend with sig_a sig_b 1, or with: sig_c sig_d (sig_a or sig_b) 1/0 0 15:58:37 gmaxwell: no accumulator needed 15:58:44 petertodd: well that form repeats the pubkeys a fair bit. 15:59:04 gmaxwell: yes, but it's very simple to understand 15:59:14 adam3us1: yea, I can't justify stateful things. 15:59:35 petertodd: but ... we want to both have and eat the cake. 16:00:04 gmaxwell: lets see if we can succesfully eat a muffin without losing tens of thousands of dollars 16:00:05 petertodd: in any case, it's an issue that the ability to safely use fancier scripts is that they're moderately risky. 16:01:14 but (1) my comment was also an existance proof that people are actually smart enough to realize this (2) it's sort of their own problem if they don't. 16:01:17 gmaxwell: well that's just inherent to doing complex things 16:01:21 i thought the rationale for having disabled opcodes is that they could screw with the people running the code (i.e. everyone) to cause either DoS attacks of some form, or worse, forks 16:01:31 (It wasn't me who pointed out that script was risky either, I think) 16:01:36 but in case of snarks, everybody is just verifying that a specific (TC-complete) circuit was run 16:02:03 andytoshi: we disabled the op_codes because lshift was exploitable to crash nodes. 16:02:05 andytoshi: the rational was "oh shit! lets be super cautious now" 16:02:17 It turns out that some of the other disabled ones had other bugs too. 16:02:37 andytoshi: lshift could have been fixed, but just disabling was easy 16:02:52 andytoshi: back then I don't think people fully understood how hard re-enablingthem would be 16:03:13 gmaxwell: what next. google nacl (sandbox execution of x86 binaries). activex for bitcoin :) 16:03:37 well, i'd hope that we donet have OP_OPENNETWORKPORT ;) 16:03:54 adam3us1: the pressure to implement fast JITs for this stuff is part of the reason I'm skeptical about people getting the cycle counters right. 16:04:01 andytoshi: this is more like OP_FORMATDISK, OP_SENDPRIVATEKEYS 16:06:13 gmaxwell: the nice thing about cross chain atomic swap as the main mechanism is its full-node secure (not just spv) and its the market makers who are taking the SPV risk 16:06:29 (back on the pegged side-chain again) 16:06:33 in any case, with snarks I think you're just left with people may right scripts which are unsafe in a mean and nasty world, and I'm okay with that. I don't think we can do better without removing all flexibility. Hell, even DSA is not really safe in a mean and nasty world. :) 16:07:19 adam3us1: hm. well atomic chain swaps are not secure against sufficently reorgs with double spends... but they are a 1:1 risk, only the person swapping with you can rip you off. 16:07:33 er sufficiently deep reorgs. 16:08:29 Right the first step of an atomic swap is to multisig escrow coins. If you suffer a reorg deep enough that the escrowing can be killed on one chain, after the transaction is done on the other, the coins can be clawed back. 16:08:35 it's just not a doomsday risk 16:09:37 so.. i guess OP_DOOMSDAY is completely out the window? 16:09:46 gmaxwell: i am not 100% sure, though there is some plausibility, that you can expect to extract secure finance in a distributed version of core wars/redcode, even with user action on input for private keys, private key crypto ops outside of the sandbox, sandboxes for execution. non-functional statefuul code in a hostile distributed execution environment plus a bit of crypto 16:10:19 adam3us1: my first question: what is all this going to actually be used for? 16:11:26 OneFixt has quit 16:11:46 OneFixt has joined #bitcoin-wizards 16:15:12 adam3us has joined #bitcoin-wizards 16:27:30 hello 16:34:32 brisque has quit 16:35:58 petertodd: its going to be used say to encourage an explosion of innovation, by making TC code maximally self-extensible. 16:39:30 petertodd: alternatively a fun experiment in core-wars/redode with $Bns at stake, or exploring the boundaries of human ability to write secure code in a hostile environment & formal provability of security properties of code 16:39:48 true! 16:39:58 corewars where you atually lose money if you lose 16:46:49 nsh has quit 16:48:09 very interesting, I hadn't thought about the scripts as a source of consensus-criticial-implementation-consistency bugs 16:48:46 I'm not sure I understand the corewars attacks though 16:49:16 say I pay to a p2sh and the script is TC 16:49:26 Krellan has quit 16:50:01 the attacker still has to find a script with the same hash, no? 16:50:16 what am I missing adam3us1 ? 16:50:47 Krellan has joined #bitcoin-wizards 16:55:35 <_ingsoc> _ingsoc has joined #bitcoin-wizards 17:11:02 Krellan has quit 17:21:18 I guess I don't understand the corewars game itself 17:22:30 Krellan has joined #bitcoin-wizards 17:23:43 jtimon: corewars i never played either but the idea is to seize control of the cpu or the other guys program. a game of hostile code vs hostile code 17:24:25 nsh has joined #bitcoin-wizards 17:24:57 yeah I understand the general idea, I'm not sure I udnerstand the strategies though 17:26:14 anyway, apart from gmaxwell's concerns (code scape and script-consensus), what are the potential problems with a TC p2sh ? 17:26:25 I have actually played corewars. 17:27:13 (on an atari ST, I believe) 17:27:17 the game looks very interesting 17:27:50 adam3us: if TC extensions can be written by anyone dynamically at any time to the opcode, script lang etc and the TC is persistently statefull i was wondering if an existing op code or smart-contract can convince its author that it cant be later fooled by someone elses state changes, extensions etc. TC is a lot of complexity. 17:29:27 <_ingsoc> _ingsoc has left #bitcoin-wizards 17:30:34 jtimon: wait quark has its own PoW? 17:31:07 TC is all the complexity :) I'm still not sure I understand what you mean though :( 17:31:17 yes, I think so 17:31:43