| 01:19:00 | justanotheruser: | thanks andytoshi |
| 01:22:24 | gmaxwell: | From #p2pool: |
| 01:22:25 | gmaxwell: | 17:20 < owowo> gmaxwell: can you explain why ppl are mining on those BIG pools? |
| 01:22:28 | gmaxwell: | 17:21 < owowo> I don't get it, they must get more coin there. |
| 01:22:32 | home_jg: | home_jg is now known as jgarzik |
| 01:23:06 | gmaxwell: | oh he says he was kidding now. |
| 01:23:13 | gmaxwell: | dude just nearly dodged getting face-stabbed. |
| 01:27:28 | shesek: | bigger pools could operate on lower margins, so miners could benefit from the lower fees |
| 01:27:54 | shesek: | I'm not really familiar with pools though, so I'm not sure if that's true in practice |
| 01:27:56 | gmaxwell: | shesek: except that there are smaller 0 fee options (including p2pool) |
| 01:28:06 | gmaxwell: | the biggest pools have historically had the highest fees. |
| 01:29:18 | gmaxwell: | (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 | shesek: | doesn't ghash's hashpower comes mostly from cex? |
| 01:30:45 | gmaxwell: | shesek: yes, common ownership. |
| 01:30:50 | shesek: | which is physically owned by them, but should be "owned" by other people |
| 01:31:14 | shesek: | though as long as they have physical ownership over the hardware, its really a matter of trusting them |
| 01:31:14 | gmaxwell: | 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 | gmaxwell: | 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 | shesek: | btw, about p2pool, doesn't it have a much higher orphan rate that would really effect payouts for the worse? |
| 01:32:22 | gmaxwell: | wow |
| 01:32:24 | gmaxwell: | * gmaxwell cries |
| 01:32:41 | gmaxwell: | shesek: no, P2pool's orphan rate is lower than other pools by an order of magnitude. |
| 01:32:55 | shesek: | sorry, I'm really not familiar with p2pool and pools in general, I'm just asking to educate myself better :) |
| 01:33:24 | gmaxwell: | 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 | shesek: | so it seems like a lot of people are misinformed about that, I've read that in multiple places |
| 01:34:40 | shesek: | and I wonder how it worked out like that with the pools fees |
| 01:34:55 | shesek: | and why people keep joining the bigger pools if that's the case |
| 01:35:14 | shesek: | it might be psychological, where people think that bigger pools are better for some reason |
| 01:35:37 | shesek: | 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 | gmaxwell: | 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 | gmaxwell: | Overall p2pool has solved about 107% of the blocks you would have expected based on its observed work done. |
| 01:37:20 | gmaxwell: | 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 | gmaxwell: | They talk about needing an X TH miner in order to "keep up" and things like that. |
| 01:37:48 | gmaxwell: | Following that logic, the biggest would be best. sooo. |
| 01:38:16 | gmaxwell: | 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 | shesek: | educating miners better could definitely help here, some more official resources about that could do some good |
| 01:39:12 | shesek: | an "introduction to mining" on bitcoin.org or something |
| 01:40:25 | shesek: | 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 | gmaxwell: | yes, "so many other people choose it, it has to be good" |
| 01:41:13 | gmaxwell: | 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 | gmaxwell: | P2pool has a bunch of UX stupidity that doesn't help— even feeds into the misunderstandings. |
| 01:42:16 | shesek: | perhaps something that helped pick a pool, with a weighted random based on the inverse popularity |
| 01:42:39 | gmaxwell: | there really is only one pool we should be recommending, p2pool. It's the only suriving pool thats a decenteralized system. |
| 01:42:51 | shesek: | could be marketed as "help save Bitcoin from centralization by using this!" |
| 01:43:03 | gmaxwell: | warren has been trying that. |
| 01:44:18 | shesek: | 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 | shesek: | and help overcome that choice paralysis |
| 01:44:45 | shesek: | but yeah, long term, p2pool is much better |
| 01:45:07 | shesek: | but its still somewhat inaccessible to users and requires setting up a full node |
| 01:45:43 | shesek: | 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 | gmaxwell: | 'they' |
| 01:46:10 | gmaxwell: | it's not like there is a P2pool company. |
| 01:47:00 | shesek: | well, yeah, it should really be a community effort |
| 01:47:06 | shesek: | not really "they", more like "we" |
| 01:47:27 | gmaxwell: | 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 | shesek: | what are your current thoughts on the best way to address this? |
| 01:50:22 | gmaxwell: | It's addressed by sipa's headers first sync work. |
| 01:50:45 | gmaxwell: | But the code is immature. |
| 01:52:42 | shesek: | sipa closed https://github.com/bitcoin/bitcoin/pull/2964 saying that he's working on something better, is it public yet? |
| 01:52:52 | shesek: | can't seem to find a newer pull request / issue |
| 01:54:40 | gmaxwell: | 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 | shesek: | cool, I haven't really kept up with developments on that front, looks like a good solution |
| 02:05:21 | shesek: | 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 | shesek: | can even be provably fair by basing the "random" choice on the user's ip and user agent |
| 02:10:26 | gmaxwell: | 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:50 | HobGoblin: | HobGoblin is now known as Guest32748 |
| 02:12:05 | shesek: | 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:13:00 | amiller: | amiller is now known as Guest53598 |
| 02:43:51 | pigeons_: | pigeons_ is now known as pigeons |
| 03:38:06 | Guest53598: | Guest53598 is now known as amiller |
| 06:14:58 | justanotheruser: | justanotheruser is now known as Coyote |
| 06:15:14 | Coyote: | Coyote is now known as justanotheruser |
| 06:17:40 | justanotheruser: | Has anyone made any proposals for anonymity networks upon which things like coinjoins and coinswaps could take place? |
| 06:18:05 | justanotheruser: | justanotheruser is now known as NotJustanotherus |
| 06:18:15 | NotJustanotherus: | NotJustanotherus is now known as justanotheruser |
| 06:22:51 | michagogo|cloud: | I left the Jesuscoin-killing script (replaying the Bitcoin blockchain) running overnight |
| 06:23:03 | michagogo|cloud: | Only gotten as far as block 234853 |
| 06:25:37 | justanotheruser: | michagogo|cloud: nice, you actually made the magic changing thing |
| 06:26:02 | michagogo|cloud: | justanotheruser: I actually tweaked linearize.py to do that |
| 06:26:16 | justanotheruser: | michagogo|cloud: does jesuscoin have a community at all? |
| 06:26:17 | michagogo|cloud: | But before I actually ran it, I realized that I didn't need to |
| 06:26:27 | michagogo|cloud: | This script also works: http://0bin.net/paste/OFWqJ7Lj0k0GO0o4#Rd6uP8VFxwv3SEO4HQAwtF+Vy5M3ZtaUrrKC9m3qI+w= |
| 06:26:33 | michagogo|cloud: | justanotheruser: Not really, afaik |
| 06:27:14 | justanotheruser: | michagogo|cloud: Is this only possible because jesuscoin has all bitcoins defaults? |
| 06:27:20 | michagogo|cloud: | justanotheruser: Yes |
| 06:27:27 | michagogo|cloud: | It's a 100% clone of Bitcoin |
| 06:27:38 | michagogo|cloud: | Specifically the genesis block and parameters |
| 06:29:36 | wyager: | Oh my god |
| 06:29:42 | wyager: | that is so stupid |
| 06:29:52 | wyager: | And hilarious |
| 06:31:22 | justanotheruser: | heh |
| 06:31:33 | justanotheruser: | I wonder why no one did this for ixcoin or i0coin |
| 06:31:47 | justanotheruser: | well I guess ixcoin had a premine, but i0coin it might be possible |
| 06:58:40 | justanotheruser: | 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. |
| 08:35:52 | nsh: | justanotheruser, it's not a bad idea, experimentally. it might be a foolhardy store of value |
| 08:36:22 | justanotheruser: | nsh: why? |
| 08:37:16 | nsh: | because there's no explicit incentive analysis that guarantees behaviour converges towards the subset of actions that preserve integrity |
| 08:38:13 | nsh: | there could be weird effects that stop people self-interestedly cooperating to keep value stable |
| 08:38:23 | nsh: | (there could also not) |
| 08:38:23 | Taek42: | technically, if you limit the number of cycles then it's not turing complete |
| 08:41:54 | justanotheruser: | Taek42: the scripts were never turing complete |
| 08:42:17 | justanotheruser: | and there can only be a limited number of scripts per block, therefore the blocks were never turing complete |
| 08:42:20 | Taek42: | I know that, was just knit-picking |
| 08:43:09 | justanotheruser: | Taek42: oh, I misunderstood. You were referring to my original statement where I said this could be turing complete. |
| 08:43:11 | Taek42: | I was wondering if it would be possible to build a higher-level lanugage on bitcoin script |
| 08:43:17 | Taek42: | right |
| 08:43:36 | Taek42: | Image a C-like that output bitcoin-script instead of assembly |
| 08:43:47 | stonecoldpat: | michagogo|cloud: jesuscoin i love it |
| 08:43:48 | justanotheruser: | 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 | justanotheruser: | well not cut off, but only be accepted if they have a limited run time |
| 08:44:27 | Taek42: | 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 | Taek42: | because all hosts would need to agree if a script took too long to terminate |
| 08:44:48 | justanotheruser: | Taek42: it would be like measuring where transactions get cut off. The miners determined it |
| 08:44:55 | justanotheruser: | (in terms of size) |
| 08:45:02 | Taek42: | hmmm |
| 08:47:21 | justanotheruser: | 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 | justanotheruser: | I suppose that would limit the ability to give people scripts that they can spend later though |
| 08:48:06 | justanotheruser: | well actually nvm the statement directly above this |
| 08:48:38 | justanotheruser: | you should build these scripts so they can't run arbitrarily longly, otherwise someone will donate the tx to miners |
| 08:49:48 | justanotheruser: | nsh: Are you saying this system would hurt stability of the price? |
| 08:50:44 | nsh: | not necessarily, just that things tend toward instability as the degrees of freedom increase |
| 08:51:40 | justanotheruser: | 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 | Taek42: | nsh I'm not sure I agree with that |
| 08:52:00 | nsh: | mathematical, but perhaps i'm wrong |
| 08:52:50 | nsh: | 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 | justanotheruser: | nsh: could you explain what a degree of freedom is in these terms then? |
| 08:53:16 | nsh: | "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 | justanotheruser: | nsh: Are you saying bitcoin price would be more stable if it didn't have p2sh? |
| 08:53:59 | nsh: | no |
| 08:54:44 | justanotheruser: | doesn't p2sh add a DOF? |
| 08:54:45 | nsh: | 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 | nsh: | yes, but you're making stronger assertions :) |
| 08:55:55 | Taek42: | depends on what you mean by network |
| 08:56:12 | justanotheruser: | nsh: Does another DOF hurt network stability? |
| 08:56:13 | Taek42: | bitcoins price instability derives from the fact that the volume in circulation can't adjust to the demand |
| 08:56:21 | Taek42: | and the demand has been all over the map |
| 08:56:34 | nsh: | justanotheruser, depends |
| 08:56:54 | nsh: | what i proposed was that as the number of DoFs increases then the entire system _tends_ towards more unstable behaviour |
| 08:57:26 | justanotheruser: | hm |
| 08:57:44 | nsh: | to go from that to saying adding one DoF neccessarily increase instability requires some additional evidence |
| 08:57:49 | justanotheruser: | 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 | nsh: | and anyway, i'm probably just smoking crack |
| 09:00:29 | justanotheruser: | 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 | sipa: | the reason why turing complete scripts are a bad idea is because you cannot determine the cost of running without running |
| 09:19:56 | sipa: | even if it's not actually turing complete and limited to some high amount of cycles |
| 09:21:50 | nsh: | which means easy DoS attacks? |
| 09:22:53 | Taek42: | 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 | Taek42: | wouldn't limiting the cycles prevent that? |
| 09:27:48 | sipa: | 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 | Taek42: | or you could charge each transaction equal to the theoretical limit on how expensive it is |
| 09:31:21 | Taek42: | then the miners will be happy |
| 09:31:36 | Taek42: | or you could wait to charge until you know how many clock cycles were spent validating it |
| 09:35:11 | sipa: | the problem is that mining is constrained by size, so will end up picking transactions with sufficient fee per byte |
| 09:35:34 | sipa: | if you want the same incentive for execution, you need a hard limit per block on validation cost |
| 09:35:55 | sipa: | which complicates optimal transaction selectiom |
| 10:18:10 | Guest32748: | Guest32748 is now known as UukGoblin |
| 14:40:09 | petertodd: | 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 | petertodd: | sipa: sure there's some theoretical static analysis stuff you could do, but it's consensus critical - keep it simple and stupid |
| 14:53:18 | andytoshi: | petertodd: suppose i make a script which has fee for 100000 iterations, but runs for 100001, so it can't validate |
| 14:53:30 | andytoshi: | is there a nice way to prevent a DoS along those lines? |
| 14:54:43 | petertodd: | andytoshi: probably not, but at least that's a local DoS attack - lots of those |
| 14:55:14 | petertodd: | 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 | andytoshi: | yeah, fair enough, i guess people are free to make IsStandard reject anything that might take too long for their system |
| 14:55:34 | andytoshi: | also a good point |
| 14:55:56 | petertodd: | andytoshi: yup |
| 14:56:18 | fagmuffinz: | fagmuffinz has left #bitcoin-wizards |
| 14:56:32 | petertodd: | andytoshi: and static analysis is all well and good, but like I say, it'd be in consensus critical codepaths... |
| 14:57:05 | andytoshi: | yeah, perhaps it's a meta-problem that people will try to do it if they see a benefit |
| 14:57:27 | petertodd: | lol! |
| 14:58:07 | andytoshi: | 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 | andytoshi: | 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 | petertodd: | 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:22:38 | gmaxwell: | 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 | gmaxwell: | the latter is probably true, the former not so much. |
| 15:23:12 | gmaxwell: | 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 | petertodd: | gmaxwell: just do a MAST design and make sure your MAST hash function is more costly than anything else... |
| 15:24:14 | adam3us: | 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 | nsh: | petertodd, what's MAST? |
| 15:24:39 | gmaxwell: | adam3us: it needs to be run some, but perhaps not much. |
| 15:24:55 | petertodd: | nsh: merkleized abstract syntax tree |
| 15:25:09 | nsh: | ah, ty |
| 15:25:19 | gmaxwell: | 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 | adam3us: | 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 | petertodd: | gmaxwell: which is my serious point: turing completeness often gives you more efficient code in cpu and code size |
| 15:26:25 | gmaxwell: | adam3us: I mean, you'd need to have at least one execution to get funds there in the first place. |
| 15:27:12 | gmaxwell: | petertodd: certantly low level opcodes do not. |
| 15:27:52 | gmaxwell: | 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 | adam3us: | 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 | adam3us: | gmaxwell: agreed. i think everything i just said was in the original thread. just emphasizing how cool that is :) |
| 15:29:11 | gmaxwell: | 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 | gmaxwell: | I still think implementors will totally screw up their instruction counting, esp when slower scripts start driving them ot JIT. |
| 15:30:09 | gmaxwell: | 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 | adam3us: | 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:32:51 | adam3us: | 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 | gmaxwell: | yea, I'm still not arguing letting validation become expensive is a good idea. :P Just filling out the idea. |
| 15:34:45 | adam3us: | 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 | gmaxwell: | Implementers currently get script execution all wrong and it's already quite simple. |
| 15:35:51 | adam3us: | 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 | petertodd: | 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:38:03 | adam3us: | gmaxwell: even if the interpreter is correct (single implementation = spec satoshi style) i am not sure about the redcode game issue |
| 15:38:13 | petertodd: | redcode game? |
| 15:39:27 | adam3us: | petertodd: never played it but http://en.wikipedia.org/wiki/Core_War |
| 15:39:44 | petertodd: | adam3us: ah! yeah that's a classic |
| 15:39:48 | adam3us: | petertodd: users battle for control of the cpu with hostile code |
| 15:40:57 | petertodd: | Interesting thought: transactions and the blockchain are a way of stringing multiple bits of code together in a DAG. |
| 15:41:30 | gmaxwell: | adam3us: certantly that kind of ecosystem would create greater incentives for reorgs. |
| 15:42:22 | andytoshi: | petertodd: i have thought about making a blockchain-based haskell-like language |
| 15:42:28 | andytoshi: | sadly, i could see no point to it |
| 15:43:30 | petertodd: | 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:45:06 | andytoshi: | hsm == Hierarchical storage management ? |
| 15:45:30 | gmaxwell: | hardware security module |
| 15:46:11 | andytoshi: | gmaxwell: ah, that's what i thought, but i didn't see the connection to merklized forth |
| 15:46:22 | adam3us1: | 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 | petertodd: | andytoshi: it's more because forth is incredibly simple, so it's more likely you'd actually get the implementation right |
| 15:47:16 | adam3us1: | 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 | petertodd: | andytoshi: yet forth still can do lisp-like tricks by doing data as code |
| 15:48:02 | andytoshi: | petertodd: oh, i see |
| 15:48:55 | andytoshi: | i should've looked up forth instead of hsm :P all i know is 'stack-based language' |
| 15:48:59 | gmaxwell: | 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 | adam3us1: | 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 | gmaxwell: | 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 | adam3us1: | 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 | gmaxwell: | This is why I prefer the path of using SNARKs of some kind for more complex scripts. |
| 15:50:54 | andytoshi: | 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 | gmaxwell: | 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 | adam3us1: | 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 | petertodd: | gmaxwell: you mean they don't have the tools to just go make a scriptSig to try spending it? |
| 15:52:15 | gmaxwell: | andytoshi: maybe, overwriting the behavior of one other opcode might be possible just with a constant offset. |
| 15:53:44 | gmaxwell: | 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 | gmaxwell: | adam3us1: at least there is no "code escape" bug in the snark case. Or consensus-criticial-implementation-consistency bugs. |
| 15:54:34 | andytoshi: | adam3us1: are you talking about finding bugs in the snark circuit (which is commited to in the preprocessing stage) itself? |
| 15:54:36 | petertodd: | gmaxwell: ah, did they do the "op_if" as "select block of code" style? |
| 15:54:37 | gmaxwell: | only the risk that you write a bad script. |
| 15:54:47 | adam3us1: | 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 | adam3us1: | gmaxwell: correct on the code ecsape and interpretation fork |
| 15:55:21 | gmaxwell: | 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 | adam3us1: | 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 | gmaxwell: | adam3us1: sure, or— "You can steal my coins if you can find the discrete log of 0xdeadbeef" |
| 15:56:21 | andytoshi: | adam3us1: oh, gotcha, still on the redcode scenario |
| 15:57:24 | petertodd: | 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 | adam3us1: | 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 | petertodd: | 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 | petertodd: | gmaxwell: no accumulator needed |
| 15:58:44 | gmaxwell: | petertodd: well that form repeats the pubkeys a fair bit. |
| 15:59:04 | petertodd: | gmaxwell: yes, but it's very simple to understand |
| 15:59:14 | gmaxwell: | adam3us1: yea, I can't justify stateful things. |
| 15:59:35 | gmaxwell: | petertodd: but ... we want to both have and eat the cake. |
| 16:00:04 | petertodd: | gmaxwell: lets see if we can succesfully eat a muffin without losing tens of thousands of dollars |
| 16:00:05 | gmaxwell: | 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 | gmaxwell: | 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 | petertodd: | gmaxwell: well that's just inherent to doing complex things |
| 16:01:21 | andytoshi: | 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 | gmaxwell: | (It wasn't me who pointed out that script was risky either, I think) |
| 16:01:36 | andytoshi: | but in case of snarks, everybody is just verifying that a specific (TC-complete) circuit was run |
| 16:02:03 | gmaxwell: | andytoshi: we disabled the op_codes because lshift was exploitable to crash nodes. |
| 16:02:05 | petertodd: | andytoshi: the rational was "oh shit! lets be super cautious now" |
| 16:02:17 | gmaxwell: | It turns out that some of the other disabled ones had other bugs too. |
| 16:02:37 | petertodd: | andytoshi: lshift could have been fixed, but just disabling was easy |
| 16:02:52 | petertodd: | andytoshi: back then I don't think people fully understood how hard re-enablingthem would be |
| 16:03:13 | adam3us1: | gmaxwell: what next. google nacl (sandbox execution of x86 binaries). activex for bitcoin :) |
| 16:03:37 | andytoshi: | well, i'd hope that we donet have OP_OPENNETWORKPORT ;) |
| 16:03:54 | gmaxwell: | 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 | adam3us1: | andytoshi: this is more like OP_FORMATDISK, OP_SENDPRIVATEKEYS |
| 16:06:13 | adam3us1: | 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 | adam3us1: | (back on the pegged side-chain again) |
| 16:06:33 | gmaxwell: | 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 | gmaxwell: | 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 | gmaxwell: | er sufficiently deep reorgs. |
| 16:08:29 | gmaxwell: | 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 | gmaxwell: | it's just not a doomsday risk |
| 16:09:37 | nsh: | so.. i guess OP_DOOMSDAY is completely out the window? |
| 16:09:46 | adam3us1: | 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 | petertodd: | adam3us1: my first question: what is all this going to actually be used for? |
| 16:27:30 | justanotheruser: | hello |
| 16:35:58 | adam3us1: | petertodd: its going to be used say to encourage an explosion of innovation, by making TC code maximally self-extensible. |
| 16:39:30 | adam3us: | 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 | petertodd: | true! |
| 16:39:58 | petertodd: | corewars where you atually lose money if you lose |
| 16:48:09 | jtimon: | very interesting, I hadn't thought about the scripts as a source of consensus-criticial-implementation-consistency bugs |
| 16:48:46 | jtimon: | I'm not sure I understand the corewars attacks though |
| 16:49:16 | jtimon: | say I pay to a p2sh and the script is TC |
| 16:50:01 | jtimon: | the attacker still has to find a script with the same hash, no? |
| 16:50:16 | jtimon: | what am I missing adam3us1 ? |
| 17:21:18 | jtimon: | I guess I don't understand the corewars game itself |
| 17:23:43 | adam3us: | 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:57 | jtimon: | yeah I understand the general idea, I'm not sure I udnerstand the strategies though |
| 17:26:14 | jtimon: | anyway, apart from gmaxwell's concerns (code scape and script-consensus), what are the potential problems with a TC p2sh ? |
| 17:26:25 | gmaxwell: | I have actually played corewars. |
| 17:27:13 | gmaxwell: | (on an atari ST, I believe) |
| 17:27:17 | jtimon: | the game looks very interesting |
| 17:27:50 | adam3us: | 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 | adam3us: | jtimon: wait quark has its own PoW? |
| 17:31:07 | jtimon: | TC is all the complexity :) I'm still not sure I understand what you mean though :( |
| 17:31:17 | jtimon: | yes, I think so |
| 17:31:43 | jtimon: | a "basket algorithm" |
| 17:31:59 | jtimon: | some freicoiners pushed for something similar for a while |
| 17:33:30 | jtimon: | instead of using just one hash function as Bitcoin does, Quark uses six: BLAKE, Blue Midnight Wish, Groestl, JH, Skein and Keccak. |
| 17:33:35 | adam3us: | jtimon: oh maybe i heard of that some mix, yes |
| 17:33:36 | jtimon: | http://bitcoinmagazine.com/8972/quarkcoin-noble-intentions-wrong-approach/ |
| 17:37:36 | jtimon: | I don't know adam3us, if you're hashing your own TC script, why would you fool yourself? |
| 17:37:47 | brisque: | https://ghash.io/ghashio_press_release.pdf |
| 17:39:18 | brisque: | 45% private hardware is interesting though, gmaxwell wasn't wrong about the amount of funding selling hardware gave them |
| 17:39:38 | gmaxwell: | "Jeffery Smith" |
| 17:39:58 | pigeons: | Tom Williams |
| 17:40:15 | jtimon: | can't they just p2pool? is 55% p2pool risky? |
| 17:40:22 | brisque: | no. |
| 17:40:41 | brisque: | if ghash.io dumped their load on p2pool they would rocket the share difficulty though. |
| 17:41:08 | jtimon: | I see, it's a question of efficiency |
| 17:41:44 | brisque: | gmaxwell: different name than on their domain at least. |
| 17:41:46 | gmaxwell: | brisque: well it's not that bad because p2pool adapts share difficulty per miner somewhat. |
| 17:42:05 | brisque: | good point. |
| 17:43:58 | jtimon: | Interesting: "Non-standard transactions, such as mentioned above, can not be relayed to |
| 17:43:58 | jtimon: | the blockchain network, however they are still valid, and can be mined |
| 17:43:58 | jtimon: | using the hashing power accumulated on GHash.IO. " |
| 17:44:27 | adam3us: | jtimon: point is if everyone can extend the script language at any time, and write to global, persistent state (presumably with some authorization) are we still as confident that a smart-contract cant be tricked by another persons script or state chagnes. probably not as sure. maybe not very sure at all. |
| 17:44:40 | brisque: | jtimon: not much help if there's no publicly known nodes to push to though. eligius has an interface for it. |
| 17:46:24 | jtimon: | adam3us what you mean a persistent state? apart from the utxo itself? Like a global "general purpose in-chain memory" or something? |
| 17:46:46 | adam3us: | jtimon: yes. |
| 17:47:22 | jtimon: | and why is that persistent state needed for? |
| 17:47:53 | jtimon: | I thought we were only assuming TC scripting |
| 18:52:05 | maaku_: | gmaxwell: "p2pool adapts share difficulty per miner" is that true? i thought the current share level was part of p2pool's consensus. |
| 18:52:55 | gmaxwell: | maaku_: there is a minimum share difficulty and a maximum share difficulty (just a multiple of the minimum) which is part of the consensus. |
| 18:53:33 | gmaxwell: | maaku_: but indivigual miners can choose any difficulty in between the two, and the stock software targets getting a certian number (1000? I forget) of shares in the window. |
| 18:54:12 | maaku_: | ah |
| 18:55:22 | maaku_: | re TC complete scripts, is there any known application of this stuff? |
| 18:55:25 | gmaxwell: | The end result is just that the minimum is lower than it would be if everyone used the minimum... and large miners give up a small amount of share variance by default, but it makes the variance much lower for small miners. |
| 18:56:58 | gmaxwell: | maaku_: not really. I mean, if bounds are high enough it expands the space of non-private non-interactive bounty transactions. e.g. "100 BTC to someone who provides the root key to AACS" |
| 19:00:01 | maaku_: | gmaxwell: short of that stuff, which is probably best done with a SNARK verification opcode, it seems like most of the benefits could be had via MAST & loop unrolling |
| 19:01:09 | gmaxwell: | maaku_: yea, personally I don't see a lot of point to turing complete. The lack of privacy really closes a lot of options that would otherwise be interesting. |
| 19:01:45 | gmaxwell: | And a lot of stuff can just be done with simple finite state which could be represented in a fixed script (and, indeed, MAST compressed) |
| 19:03:20 | gmaxwell: | I'm more interested in questions like "How can you encode a boolean satisfaction rule like (x and y) or ((x or y) and 2 of 3 (a,b,c)) most compactly. |
| 19:05:31 | maaku_: | that would be directly useful |
| 19:08:06 | gmaxwell: | Coding those kinds of rules via procedural branching is not terribly compact. |
| 19:08:35 | midnightmagic: | truth-table optimization and karnaugh maps? |
| 19:11:17 | gmaxwell: | The naive way is to encode a truth table, but its exponential in the number of variables. |
| 19:12:24 | gmaxwell: | I suppose that a 32 bit truth table for 5 inputs would still be smaller than any way that script can express the above rule. |
| 19:18:15 | midnightmagic: | oh right.. "like". |
| 19:18:48 | gmaxwell: | hm. perhaps efficient encoding of the satisfaction rules is less interesting than I was thinking. The reason is that when the rules can be reorded so that you can avoid disclosing >1 public key, then you're better off MAST compressing that part of the rule. |
| 19:20:01 | gmaxwell: | e.g. you could have a OP_TABLE that took in 5 bits encoding x,y,a,b,c signatures passing and a 32 bit table value, ... but it would result in a larger script than a procedural one that only disclosed the a,b,c pubkeys if !(x&&y). |
| 19:21:16 | midnightmagic: | truth table optimization and piles of interesting technique for it are covered in digital logic design texts such as .. hrm. I can't find it anymore. Well, mine has this guy with a hat, and in the other side, the picture is inverted and the guy is gone and there's blue sky revealed behind the cutout. |
| 19:23:24 | nsh: | i don't think i've ever remembered a book cover in such detail... |
| 19:23:26 | gmaxwell: | I wonder if there is a efficient way to represent truth tables that are never 'too indifferent'... e.g. wouldn't be better represented by a MAST. My head hurts. |
| 19:23:47 | nsh: | hmm |
| 19:24:13 | nsh: | what's indifference in this context, gmaxwell? |
| 19:25:36 | gmaxwell: | nsh: e.g. in the truth table for (x and y) or ((x or y) and 2 of 3 (a,b,c)) if x&&y or !x && !y then it doesn't matter if a,b,c are true. |
| 19:25:51 | nsh: | ah, right |
| 19:26:29 | gmaxwell: | so if you were to make a script that encoded (x and y) or ((x or y) and 2 of 3 (a,b,c)) you would probably want to use a branching script that revealed a,b,c pubkeys if and only if x^y |
| 19:27:03 | nsh: | hmm |
| 19:28:29 | gmaxwell: | e.g. coding 5 checksigs and then a truth table over them would likely not be the best way to represent that multisig. The truth table is smaller than the branching stuff, but if we had hash compression of untaken branches the branching stuff would be smaller. |
| 19:29:21 | gmaxwell: | So I was wondering if there might be an efficient representation for truth tables where that _wouldn't_ be the case, e.g. where no 1 bit prefix can factor out at least two of the interior tests. |
| 19:30:07 | gmaxwell: | e.g. there is no such x input wire that makes the table insensitive to more than two or more other wires. |
| 19:31:20 | nsh: | beats me |
| 19:34:59 | Taek42: | Would Pierce's logic help any? |
| 19:45:16 | amiller: | i'm interested if anyone here has looked at ethereum http://ethereum.org/ethereum.html |
| 19:45:25 | amiller: | vitalik's attempt at making a broader script language for contracts |
| 19:46:10 | amiller: | the main interesting thing is you can have a "contract", which is like a persistent utxo, it receives data inputs from transactions, it has a special register-like thing representing a "balance" of conserved currency, and it can contains instructions that "send" from that balance to some other contract |
| 19:49:01 | pigeons: | i dont know what can be done about it, and obviously its not a technical issue, but when i look at different smart contract proposals, not usually directly bitcoin related, i wonder about how sometimes a party to the contract would need to be an expert in the execution platform and the language to be sure the contract he is agreeing to, maybe written by the other party will do what he expects. i guess that's no different than "real world" "du |
| 19:49:25 | gmaxwell: | pigeons: you got cutoff at than "real world" "du |
| 19:49:37 | pigeons: | real world "dumb" contracts |
| 19:49:50 | spinza_: | spinza_ is now known as spin123456 |
| 19:49:51 | spin123456: | spin123456 is now known as spinza |
| 19:50:26 | pigeons: | not that anyone can protect everyone from potential ripoffs all the time, but some people would try to fool people. contract does X, but it does not |
| 19:50:57 | gmaxwell: | pigeons: but sure, part of the point is that "standard" contracts can be formed which get reviewed by experts. But its absolutely an issue, and its part of the reason that the simple forth-like encoding in bitcoin is pretty good— simply becasuse it actually isn't TOO terrible for the right kind of expert to evaluate them. Likewise, their non-turing completeness makes it possible to make tools that analize them and present to you ... |
| 19:51:04 | gmaxwell: | ... all the ways of satisifying them. |
| 19:51:22 | pigeons: | right |
| 19:51:35 | spinza: | spinza is now known as spin123456 |
| 19:51:35 | spin123456: | spin123456 is now known as spinza |
| 19:59:26 | maaku_: | gmaxwell: if you allow non-valid pubkeys and sigs for the ones which are not required, isn't that enough? |
| 19:59:42 | maaku_: | e.g. the pubkey script is OP_TABLE for x,y,a,b,c |
| 20:00:12 | maaku_: | the scriptSig is x-pubkey x-sig y-pubkey y-sig OP_0 OP_0 OP_0 OP_0 OP_0 OP_0 |
| 20:00:38 | maaku_: | er-no, you need to check that the pubkeyhashes match, nevermind |
| 20:01:51 | andytoshi: | amiller: i've seen it mentioned a few times here, so i think somebody (not me) has looked into it |
| 20:02:19 | amiller: | ok. it's possible i've pasted it here before too. |
| 20:02:47 | amiller: | having a) contracts that persist through multiple transactions and b) a way of sending value from one to another are both new |
| 20:02:55 | amiller: | and far more relevant to discuss imo than the red herring of turing completness |
| 20:03:03 | maaku_: | well, open-txns does that |
| 20:03:08 | maaku_: | but new as a bitcoin proposal i suppose |
| 20:03:31 | maaku_: | it fails spectacularly at managing DoS potential with its TC scripts |
| 20:03:41 | gmaxwell: | amiller: well I think the covenants post I made shows the kind of farscial mess you can make with that stuff. |
| 20:04:17 | gmaxwell: | I'd be more interesting in someone giving a clear example which can't just be replaced with an interactive protocol. |
| 20:04:31 | amiller: | chess game |
| 20:04:49 | gmaxwell: | I'm sure ones exist, but I mostly drew a blank. |
| 20:05:36 | amiller: | the reason you can't do multiple round protocols with bitcoin including covenant script is that you can't condition future txouts on the current txout |
| 20:05:51 | gmaxwell: | amiller: what, you have the program verify your chess witness? One of the players will just stop moving once he sees that he'll lose but before the transcript is finished, — exponential advantage for cheating. |
| 20:06:24 | amiller: | ok so you do the standard trick for adding fairness by having a move timer |
| 20:06:34 | amiller: | if you fail to publish a valid move within k blocks you forfeit |
| 20:08:08 | gmaxwell: | amiller: okay, fair enough. |
| 20:08:30 | amiller: | so. maybe it's still possible to do this with covenant |
| 20:08:55 | amiller: | because you can make the input claimable with evidence that there is a blockchain with sufficient length that includes corresponding transactions etc. whatever |
| 20:09:24 | amiller: | maybe you can always transform any other smart-contract system into one with the current semantics and using chain proofs like that. |
| 20:09:58 | gmaxwell: | amiller: in any case, its _always_ possible without making the network evaluate turing complete code, because you can just outsource script processing via a snark. |
| 20:10:11 | amiller: | yes turing complete is completely irrelevant here |
| 20:11:06 | amiller: | i think the semantics of the chess game example are pretty clear and that makes it a good example, it's just not an obvious business case financial impact kind of thing, that's the only problem with it |
| 20:11:23 | gmaxwell: | Then what is? you can allow arbritary data from the chain just by extracting it and presenting it to the program. |
| 20:11:56 | amiller: | including a proof that a suitable transaction doesn't exist? |
| 20:12:21 | amiller: | like if i wanted to time out the player who fails to publish a chess move, i would want to show that the current chain has k blocks and does not contain a valid move |
| 20:12:56 | gmaxwell: | why would you even publish the moves? you'd use a dominating spend like I proposed for anti-cheat in the coinwitness thread. |
| 20:13:40 | gmaxwell: | Basically if someone tries to time out redeem the game, the output is covenant locked so that it can be spent by either a longer witness or after a final timeout. |
| 20:14:32 | gmaxwell: | Was I clear enough there? sorry. I don't actually know how much of what I'm talking about you've read. |
| 20:14:41 | gmaxwell: | I didn't want to repeat it all if you've read it all. |
| 20:14:54 | amiller: | i've at least skimmed both threads but i am pretty sure i don't understand many details correctly |
| 20:15:39 | gmaxwell: | amiller: the idea is that to redeem the prize in our chess game you either present proof you've seen a complete transcript for the game in which you've won OR |
| 20:16:17 | gmaxwell: | if the time is past a timeout, AND you present a transcript where your move is last then you can spend it with a transaction whos TXOUT is constrained, such that: |
| 20:16:57 | gmaxwell: | it can be spent after a final timeout (some time from now) OR it can be spent by a similar constrained transaction which a somewhat advanced final timeout and proof of a witness of a longer transcript. |
| 20:17:18 | amiller: | witness of a longer transcript than what |
| 20:17:27 | gmaxwell: | that the longest seen so far, it accumulates. |
| 20:17:39 | amiller: | here's an edge case though |
| 20:17:43 | amiller: | suppose player 1 has a timeout |
| 20:17:46 | amiller: | but player 2 does *not* have a timeout |
| 20:18:00 | amiller: | player 1 publishes his move in time |
| 20:18:30 | amiller: | player 2 pretends that he didn't see the first move, and shows a long transcript and tries to redeem the timeout |
| 20:18:55 | gmaxwell: | He can't, because player 2 can't produce a longer transcript on his own. |
| 20:19:00 | amiller: | player 1 can't just try to timeout player 2 because player 2 isn't on the clock, but you would want to prevent player 2 from omitting the published move |
| 20:20:11 | gmaxwell: | amiller: e.g. player 1 moves, player 2 tries to redeem an empty transcript. Player 1 says fuck you and publishes a 1 move transcript. Player 2 can either give up, or present a 2 move transcript. If he does the latter player 1 can present a three move transcript and so on. |
| 20:20:31 | amiller: | when is the coin irrevocably spent? |
| 20:20:41 | amiller: | if this can keep going on |
| 20:21:46 | gmaxwell: | when the transcript can grow no more, or when someone finally misses an update timeout. |
| 20:22:57 | gmaxwell: | and sure, it's probably possible in chess (it is possible in go) to setup a case where the game goes periodic-stalemate in which case it could go on forever if no party will yield. But the evaluation model doesn't matter there. |
| 20:23:08 | gmaxwell: | (e.g. you can't solve this by having proof of publication) |
| 20:52:43 | jtimon: | gmaxwell, for your non-disclousure key logic problem |
| 20:54:17 | jtimon: | any boolean ecuation can be turned into the form (a * c * e) + (b * c * e), wait |
| 20:54:28 | jtimon: | let me look at your example |
| 20:54:36 | jtimon: | well, no |
| 20:55:30 | gmaxwell: | the 2 of 3 can be expanded into (a&&b or b&&c or a&&c) |
| 20:55:35 | jtimon: | the point is to build a tree with N or branches |
| 20:55:49 | jtimon: | n OR branches |
| 20:56:42 | jtimon: | a tree in which width is OR and deep is AND |
| 20:56:47 | jtimon: | argh |
| 20:56:54 | jtimon: | words don't come easy |
| 20:58:31 | jtimon: | and anything can be expanded to that structure |
| 20:59:09 | jtimon: | to get the coins you only need to reveal the relevant branch |
| 20:59:42 | jtimon: | sorry, I'll smoke a cigarrete while trying to translate that to english |
| 21:01:38 | gmaxwell: | jtimon: right, but because hiding a branch still costs you a 256 bit hash, it doesn't save you anything to hide a branch that only contains one key, its better to just test it directly at the current level. |
| 21:02:11 | gmaxwell: | e.g. you would not represent a or b as a else {b} |
| 21:07:51 | jtimon: | ?I don't understand the e.g. |
| 21:08:07 | jtimon: | but about the hidden branch hash cost |
| 21:08:37 | jtimon: | it is on the scriptSig, not the scriptPubKey, does it really matter? |
| 21:08:48 | jtimon: | well, yes, sorry |
| 21:08:58 | jtimon: | not that much, but still matters |
| 21:18:41 | jtimon: | it fails spectacularly at managing DoS potential with its TC scripts |
| 21:18:51 | jtimon: | I'm not so sure about that |
| 21:19:14 | jtimon: | my understanding (and I'm not sure I understand the proposal) |
| 21:19:19 | maaku_: | jtimon: iirc his proposal is to have script execution paid for in fees |
| 21:19:25 | jtimon: | is that it is protected through fees |
| 21:19:32 | jtimon: | yes |
| 21:19:39 | maaku_: | but if the script is invalidated by running too long, then how does the miner collect the fees? |
| 21:19:52 | maaku_: | *transaction is invalided by the script running too long |
| 21:20:15 | jtimon: | you're paying fees as it is executed, so the execution is somehow "in-chain" |
| 21:20:36 | jtimon: | maybe the scripts are executed in several blocks |
| 21:20:50 | jtimon: | and only a max instructions per block is executed |
| 21:20:57 | maaku_: | then how do you reach consensus on it? |
| 21:21:03 | jtimon: | that was my thought at the time, but doesn't look very scalable |
| 21:21:16 | maaku_: | you bloat the chain with invalid transactions that steal a little bit of fees from its inputs nonetheless? |
| 21:21:48 | jtimon: | because everyone executes the number of transactions that can be paid or the max_per_block (if there's any) |
| 21:22:14 | jtimon: | as said, it doesn't look very scalable at a first glance |
| 21:22:46 | gmaxwell: | maaku_: they move the execution construct out of the transaction and make it free standing. |
| 21:22:58 | jtimon: | I guess he has solved TC by fees in a non-scalable way |
| 21:23:01 | gmaxwell: | e.g. you have an object that has a balance which it can use to pay for execution. |
| 21:23:15 | gmaxwell: | it stops executing when its balance is 0. |
| 21:23:30 | gmaxwell: | it create it at all requires positive fees. |
| 21:23:41 | maaku_: | so it's a distributed-replicated time-share system? |
| 21:23:41 | gmaxwell: | this isn't to say that any of its is good or makes any sense. |
| 21:24:03 | gmaxwell: | the fees are paying the wrong people... unless you convert mining to be a proof of agent execution. :P |
| 21:24:09 | jtimon: | and I hadn't even considered problems related to script-consensus |
| 21:25:23 | jtimon: | exactly miners will get fees, but the rest of validators will be screwed for nothing |
| 21:25:45 | jtimon: | is that what you're saying gmaxwell? |
| 21:25:49 | gmaxwell: | yes. |
| 21:27:34 | jtimon: | so let's go back to compressed scripts |
| 21:28:15 | jtimon: | you could have a list of addresses Lk |
| 21:28:40 | jtimon: | scriptPubKey only contains it's hash |
| 21:29:55 | jtimon: | with a byte or a short, you can select the order in which the scripts in Lk will appear |
| 21:30:15 | jtimon: | the Lk is 64 bit per variable |
| 21:31:38 | jtimon: | then you can have a list of lists OR_list |
| 21:32:20 | jtimon: | each of the lists is named AND_list_n |
| 21:33:02 | jtimon: | and you have another byte to select n |
| 21:33:41 | jtimon: | scriptPubKey contains a hash of Or_list + Lk |
| 21:34:03 | jtimon: | the AND list just contains bytes reffering to scripts in Lk |
| 21:34:15 | jtimon: | indexing |
| 21:35:33 | jtimon: | so the public keys can be presented in any order selected by order_byte |
| 21:35:53 | jtimon: | of the list Lk |
| 21:36:58 | jtimon: | to sign the AND list selected by logic_byte |
| 21:38:41 | jtimon: | there's plenty of redundancy to optimize here, I'm just using bytes for convenience |
| 21:39:04 | jtimon: | not redundancy, unused bits |
| 21:40:23 | jtimon: | well, I'll think more about this until I can express it in a way that can make sense or that helps me find the deficiency by myself |