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