| 00:57:19 | gmaxwell: | So. Y'all know that sighash single bug when the Nth vin uses SINGLE and there are less than N vouts? |
| 00:58:30 | BlueMatt: | nope |
| 00:58:32 | BlueMatt: | never heard of it |
| 00:58:34 | jtimon: | no, but please continue |
| 00:58:43 | gmaxwell: | lemme clear this first, one sec |
| 00:58:47 | jtimon: | or is it for the quiz? |
| 01:06:06 | gmaxwell: | okay. So... right we sign the value 1 in that case due to that bug. |
| 01:06:26 | gmaxwell: | Imagine instead that we signed the value 0 instead? |
| 01:06:55 | gmaxwell: | (e.g. in a hypothetical alternative universe the broken code was return 0 instead of return 1) |
| 01:07:18 | gmaxwell: | Any guesses on what would be different in that universe from ours? |
| 01:07:43 | BlueMatt: | some ugly interaction with ecdsa? |
| 01:07:53 | BlueMatt: | no, should be ok? |
| 01:10:23 | pigeons: | 0000000000000000000000000000000000000000000000000000000000000001 |
| 01:10:51 | nsh: | (don't shake hands with antimatter bitcoinuniverse you) |
| 01:11:59 | gmaxwell: | BlueMatt: yea, a very ugly interaction with ecdsa. |
| 01:12:07 | gmaxwell: | it's trivial to forge signatures of the value 0 |
| 01:12:24 | BlueMatt: | gmaxwell: but we'd be signing 32 0-bytes, not 0, no? |
| 01:12:27 | BlueMatt: | is there no difference? |
| 01:12:39 | ewust: | gmaxwell: it isn't the hash of 0? |
| 01:12:41 | gmaxwell: | it's a number. keep in mind sighash is returning a hash. |
| 01:12:58 | ewust: | ah |
| 01:13:09 | BlueMatt: | oh? our ecdsa doesnt hash it again before signing? |
| 01:13:12 | BlueMatt: | thats ugly |
| 01:13:16 | BlueMatt: | but, understandable |
| 01:13:21 | gmaxwell: | no, thats the function that hashes it that returns 1 |
| 01:13:33 | BlueMatt: | ahh, fun |
| 01:13:35 | BlueMatt: | well, ok then |
| 01:13:39 | gmaxwell: | and the signature of 0 with pubkey is {r,s} = pubkey.x,pubkey.x |
| 01:13:59 | gmaxwell: | (well, a signature, I guess there are ~2^256 of them. :P ) |
| 01:13:59 | ewust: | why does the function that should be hashing not return hashes conditionally? |
| 01:14:05 | tacotime_: | https://bitcointalk.org/index.php?topic=260595.0 |
| 01:14:09 | gmaxwell: | ewust: it's a bug. |
| 01:14:09 | tacotime_: | it's kind of weird |
| 01:14:09 | BlueMatt: | hah, nice |
| 01:14:30 | tacotime_: | but that's why |
| 01:14:35 | gmaxwell: | ... so I just spent the last 30 minutes with my hands trembling verying if this wasn't an all-coins-get-stolen-vulnerability. |
| 01:15:33 | gmaxwell: | (I'd forgotten it was return 1 not return 0 ... before I checked I forged a bunch of signatures, checked that, and went ahead and crafted a test transaction ...) |
| 01:15:46 | gmaxwell: | * gmaxwell is reminded that he does not like ecdsa. |
| 01:16:26 | ewust: | or really any DSA |
| 01:16:45 | gmaxwell: | I don't believe I've seen anyone point out that property before. |
| 01:17:05 | gmaxwell: | god knows, there is probably _something_ that is vulnerable to this, even though we aren't. |
| 01:17:31 | tacotime_: | how come things like this are never patched when we patch for things that fork older versions? |
| 01:17:52 | gmaxwell: | tacotime_: we've never forked older versions (well not reliably) |
| 01:18:11 | gmaxwell: | pre 0.8 is lossy now, but still works. |
| 01:18:34 | tacotime_: | oh, i didn't realize. i thought that <0.8 simply didn't work anymore because of the leveldb stuff |
| 01:19:07 | gmaxwell: | nah, it gets stuck periodically when there is a big block, but it's nondeterminstic, and can be worked around with a bdb config file change. |
| 01:19:14 | tacotime_: | ah okay |
| 01:20:46 | jgarzik: | there are some nutter nodes out there claiming to be 0.3.x still |
| 01:21:11 | tacotime_: | i guess if i'm writing an alt chain i should maybe go through and see what other weird idiosyncrasies exist in the bitcoind implementation. i know of the extra pop for multisig tx too but that's it. |
| 01:21:48 | gmaxwell: | Deepbit's last block was 277115 and it's almost certantly still 0.3.22+patches |
| 01:21:58 | tacotime_: | is there a list somewhere of stuff that doesn't make bitcoin stop working but ought to be patched anyway? |
| 01:21:59 | tacotime_: | wow |
| 01:23:33 | gmaxwell: | the crazy sighash single behavior could be soft-fork fixed. |
| 01:24:04 | jgarzik: | gmaxwell, is there a soft fork wishlist somewhere? |
| 01:24:10 | gmaxwell: | might be logical to do it as part of malleability changes. |
| 01:24:13 | nsh: | gmaxwell, just while i'm writing my AP article for this (not really lol): this bug would have allowed anyone to forge signatures to spend anyone else's coins by triggering the bug with specially-crafted transactions, or just certain outputs that had the SINGLE vin characteristic? |
| 01:24:17 | tacotime_: | yeah |
| 01:24:30 | nsh: | (...had the return value been 0, and not 1) |
| 01:25:47 | gmaxwell: | nsh: any coin they knew the required ecdsa pubkey for. We already have the issue that if you sign a crazy SINGLE transaction thats as good as disclosing your private key, because anyone can then use your signature of 1 in another transaction. |
| 01:26:41 | nsh: | hmm, but for the grace of return-value conventions go we |
| 01:27:11 | nsh: | (cf. gnuTLS last week too....) |
| 01:27:18 | gmaxwell: | nsh: also magical type handling. In _theory_ typechecking should have been like "wtf, 1 is not a hash". |
| 01:27:29 | nsh: | aye |
| 01:27:42 | jrmithdobbs: | gmaxwell: more arguments in favor of a better script! |
| 01:27:43 | gmaxwell: | but our hashes there are uint256 and the code knows how to cast integers to uint256... |
| 01:28:03 | nsh: | unfortunately, knowing how to does not translate into knowing whether to |
| 01:28:22 | nsh: | i guess this is a mostly-unavoidable problem of magic types |
| 01:28:50 | jrmithdobbs: | i wonder what a lua-based bitcoin script would look like |
| 01:28:57 | nsh: | (though you could have project wide type casting (prohibition) assertions, i suppose) |
| 01:28:58 | jrmithdobbs: | that could be a fun project |
| 01:29:03 | gmaxwell: | I don't even know if we actually need the ability to cast integers to uint256 anywhere, I wouldn't be surprised if we didn't. |
| 01:29:21 | gmaxwell: | jrmithdobbs: that wouldn't really have the properties we want. |
| 01:29:22 | jrmithdobbs: | i'm having a hard time thinking of anywhere it'd be valid |
| 01:29:34 | jrmithdobbs: | gmaxwell: why not? |
| 01:30:35 | BlueMatt: | gmaxwell: are you coming to lunch@coinbase tomorrow? |
| 01:30:35 | gmaxwell: | jrmithdobbs: because we want statically decidable peak memory and peak computation in script. ideally it should also be easy to have some formal analysis tool analyize a proposed script and e.g. tell you if there is some derpy way that its really any anyone can spend script. |
| 01:32:22 | jrmithdobbs: | gmaxwell: lua provides that for memory pretty straight forwardly, for recursion limits implicitly, computation is a bit trickier i think and the spec is small so solvers/analysis are easy |
| 01:32:32 | gmaxwell: | BlueMatt: am not planning on it, I'm tied up in the morning. Also have plans in the evening though they could be canceled if I really wanted to. My tenative plan was to just head over wednesday late morning and stay until you kick me out. |
| 01:32:32 | jgarzik: | I don't even know if we actually need the ability to cast integers to uint256 anywhere <<--- let's find out... |
| 01:32:46 | jgarzik: | I know we use it for target comparison, and going from compact-to-full-size |
| 01:32:52 | jgarzik: | as an int |
| 01:33:02 | jgarzik: | not sure if we actually need _casting_ services |
| 01:33:20 | gmaxwell: | jgarzik: yea I was thinking of minimum difficulty? .. but I'm sure we don't need a cast, we could have an explicit conversion. |
| 01:33:39 | jgarzik: | gmaxwell, I'm slowly removing helpers from uint256.h |
| 01:33:46 | jrmithdobbs: | oh it's probably used in the miner code |
| 01:34:07 | jgarzik: | indeed |
| 01:34:09 | jrmithdobbs: | or is that finally stripped? |
| 01:34:56 | jgarzik: | Another approach is simply to start anew with an opaque bitHash type, with just a few key accessors |
| 01:35:48 | jgarzik: | nope, miner just uses the familiar |
| 01:35:50 | jgarzik: | hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256(); |
| 01:35:57 | jgarzik: | uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256(); |
| 01:36:26 | jgarzik: | actually... |
| 01:36:39 | jgarzik: | peeling off uint160 into a separate type might be a nice first step |
| 01:36:52 | jgarzik: | useful trial run for an opaque type, with fewer services demanded of it in our code |
| 01:37:06 | jrmithdobbs: | sounds sane to me |
| 01:38:03 | gmaxwell: | man, I think it's going to take hours for my blood pressure to go back to normal after thinking I found a steal all coins bug. :-/ |
| 01:38:34 | jrmithdobbs: | gmaxwell: distract yourself by convincing me lua isn't suitable ;p |
| 01:38:40 | jrmithdobbs: | i'm having a hard time doing it myself |
| 01:40:53 | gmaxwell: | jrmithdobbs: I did but you didn't believe me, both computation and memory are statically undecidable in any turing complete language in the worst case, so unless you want to either have scripts that might turn out to surprisingly fail because a dynamic check killed them, or make a normative requirement that all scripts pass some halting validator... |
| 01:41:16 | gmaxwell: | plus minutia like lua bytecode isn't secure, so you can't even use a standard lua bytecode interperter. |
| 01:41:29 | gmaxwell: | (evil bytecode can escape the lua sandbox) |
| 01:41:56 | jrmithdobbs: | gmaxwell: memory isn't statically deciadable but it's inherently limitable by the runtime |
| 01:42:03 | gmaxwell: | Besides which, I think thats all just confused about what script actually is. Script is program _verification_ not program _execution_. |
| 01:43:26 | jrmithdobbs: | and yes, i knew you couldn't use the bytecode directly :( |
| 01:43:38 | jgarzik: | we actually use uint256::getdouble() in several places??? sigh. |
| 01:43:39 | jrmithdobbs: | that situation is ... unfortunate to put it nicely |
| 01:44:35 | gmaxwell: | jrmithdobbs: for more powerful script we'd really want to do things like be able to hide untaken branches— thats a property that you don't even think of until you start thinking of script as verification rather than execution (okay, maybe some lazy functional people might think of that... oh wait, they did) |
| 01:45:09 | jrmithdobbs: | gmaxwell: ya i was gonna say ... that's kind of why i was thinking lua because you can emulate enough of the lazy bits to get that ;p |
| 01:46:22 | gmaxwell: | well, not lua bytecode. |
| 01:49:21 | gmaxwell: | jrmithdobbs: I've spent some time recently working on an implementation of a computational oracle, e.g. magic box that signs things according to code you send it. I spent a while messing around with trying to use lua for it and ultimately was unhappy with the kind of properties I could get out of it... and thats an application which can tolerate MUCH higher bounds on computation/memory than script, in particular because you can prepay the |
| 01:49:45 | jrmithdobbs: | you can prepay the |
| 01:50:10 | gmaxwell: | the actual operator of the oracle for usage. |
| 01:50:14 | gmaxwell: | * gmaxwell looks for that irssi script |
| 01:50:18 | jgarzik: | * jgarzik declares death to the "^" operator |
| 01:50:36 | jgarzik: | * jgarzik feels like Yossarian in Catch-22: http://books.google.com/books?id=Xfze51E7TEoC&lpg=PA18&ots=uVF-gzAFHC&dq=%22catch%2022%22%20death%20to%20articles%20yearn%20tragically%20tappman&pg=PA18#v=onepage&q=%22catch%2022%22%20death%20to%20articles%20yearn%20tragically%20tappman&f=false |
| 01:51:30 | nsh: | jgarzik++ |
| 01:51:49 | nsh: | that book's certainly worth a reread these days |
| 01:52:06 | gmaxwell: | jrmithdobbs: e.g. with transactions that use a lot of cpu, we have no way to pay verifying nodes, and we have no way to prepay for their usage .. e.g. if you put in a maximum that fails the transaction people can just keep flooding you with one over the maximum and you don't know until its too late. |
| 01:52:36 | gmaxwell: | and lets say someone gets you to agree to use some fancy script.. but then it turns out that you can't actually redeem it because the path you need to use to redeem it always takes too much memory or cpu. |
| 01:52:49 | nsh: | in theory SNARKS enable amortization of verification load, but that's a long way from a practical system that maintains the desired economic incentive properties |
| 01:53:20 | gmaxwell: | nsh: hm? economically its great— you move the cost entirely onto the person creating the transaction. |
| 01:53:47 | gmaxwell: | jrmithdobbs: and since we need to be so concervative in cpu/memory usage in verification, it wouldn't be hard for the limits to sneak up on you like that. |
| 01:53:56 | nsh: | well, it's a long way in my head, anyway :) |
| 01:55:18 | jgarzik: | ok, wtf uses '&' on uint256. grump. |
| 01:57:09 | jgarzik: | bool fTrickleWait = ((hashRand & 3) != 0); |
| 01:57:12 | jgarzik: | mmmmm |
| 01:57:44 | gmaxwell: | oh come on. lol |
| 01:58:27 | jgarzik: | uint256 hashRand = inv.hash ^ hashSalt; |
| 01:58:30 | jgarzik: | same code section |
| 01:58:39 | jgarzik: | sigh |
| 01:59:09 | jgarzik: | // 1/4 of tx invs blast to all immediately |
| 01:59:09 | jgarzik: | static uint256 hashSalt; |
| 01:59:09 | jgarzik: | if (hashSalt == 0) |
| 01:59:09 | jgarzik: | hashSalt = GetRandHash(); |
| 01:59:09 | jgarzik: | uint256 hashRand = inv.hash ^ hashSalt; |
| 01:59:10 | jgarzik: | hashRand = Hash(BEGIN(hashRand), END(hashRand)); |
| 01:59:11 | jgarzik: | bool fTrickleWait = ((hashRand & 3) != 0); |
| 01:59:18 | jgarzik: | * jgarzik whips out git blame |
| 01:59:56 | jgarzik: | lol, satoshi |
| 02:03:28 | gmaxwell: | it's so weird to ^ some 256 bit numbers then decide just on the lsb. |
| 02:09:39 | tacotime_: | gotta xor something |
| 02:13:01 | copumpkin: | o.O |
| 02:14:00 | gmaxwell: | good thing the relay behavior is already full of security holes, or this would count as one too. |
| 02:14:43 | gmaxwell: | since anyone observing you for a bit will quickly determine your hashSalt. |
| 02:16:04 | gmaxwell: | oh nevermind it actually hashes it, I was missing that line. |
| 02:16:08 | ewust: | isn't that what the hash is meant to protect against? (probably wanted an HMAC) |
| 02:16:42 | gmaxwell: | yea, somehow I just read over the line. I'm still very dubious about that xor. |
| 02:17:01 | gmaxwell: | but its probably not a pratical concern. |
| 02:17:11 | ewust: | there was a mumble about deterministic randomness in a similar block before that |
| 02:24:24 | jgarzik: | gmaxwell, it's just silly |
| 02:24:37 | jgarzik: | gmaxwell, might as well as generate one hash from two buffers |
| 02:27:17 | jrmithdobbs: | gmaxwell: it sounds more like a lua-specific implementation problem than an issue with the fact that lua is turing complete ... snarks uses c after all |
| 02:28:35 | tacotime_: | xor is generally kind of a bad way to combine hashes because of communtativity |
| 02:29:37 | gmaxwell: | jrmithdobbs: uhh. insane confusion there. |
| 02:29:51 | copumpkin: | ? |
| 02:30:02 | jrmithdobbs: | gmaxwell: err? |
| 02:30:04 | tacotime_: | *commutativity, bleh |
| 02:30:06 | gmaxwell: | jrmithdobbs: with SNARKS you are not running the thing being verified, you are checking a compact proof. The checking of the proof is O(1) regardless of what the program did. |
| 02:30:21 | copumpkin: | ooh, proof checking |
| 02:30:24 | copumpkin: | I'm a fan |
| 02:30:24 | gmaxwell: | jrmithdobbs: that eliminates all concerns related to the network's behavior. |
| 02:30:47 | jrmithdobbs: | gmaxwell: ah, yes, that does sound like a confusion re: snarks on my part |
| 02:32:16 | gmaxwell: | as I said, you should not be thinking of script as running code. As code running it's super insanely inefficient— since the whole network runs the same script over and over and over again. :P |
| 02:32:45 | gmaxwell: | Instead, a more useful mental model is that the person creating the transaction runs the code.. and then all the other nodes are just verifying that the code returned true. |
| 02:33:09 | gmaxwell: | Of course, we currently verify by running it again... because thats the simple thing to do. It's not, however, the only thing to do. |
| 02:33:25 | copumpkin: | *cough* type systems *cough* |
| 02:33:52 | gmaxwell: | The next more advanced thing is to encode the program as a hash tree so you can elide untaken branches of the execution, making the execution more private and potentially smaller. |
| 02:34:47 | jgarzik: | pmt_tests.cpp: In member function void CPartialMerkleTreeTester::Damage(): |
| 02:34:47 | jgarzik: | pmt_tests.cpp:21:14: error: no match for operator^= (operand types are uint256 and const uint256) |
| 02:34:47 | jgarzik: | hash ^= ((uint256)1 << bit); |
| 02:34:54 | gmaxwell: | The most advanced thing to do is to swap out running the code with a cryptographic proof of knoweldge system for NP statements. ... which lets you get snazzy things like constant size proofs regardless of how big the program was. At the expense of needing bleeding edge crypto. |
| 02:35:08 | jgarzik: | fscking test. Fixed the above case, and no others showed up in the main code. |
| 02:35:47 | jgarzik: | // flip one bit in one of the hashes - this should break the authentication |
| 02:35:52 | gmaxwell: | would that be just as good with a hash++ or did you get rid of that operator too. |
| 02:35:55 | gmaxwell: | ? |
| 02:36:15 | jgarzik: | gmaxwell, not yet, but ideally ++ will die |
| 02:36:27 | jgarzik: | gmaxwell, can just manually twiddle the buffer |
| 02:38:32 | Luke-Jr: | what's the goal of changing this stuff? O.o |
| 02:39:02 | gmaxwell: | Luke-Jr: makes some mistakes less likely to be disguised by implicit type conversion. |
| 02:39:10 | gmaxwell: | like the SIGHAS_SINGLE bug. |
| 02:39:23 | gmaxwell: | SIGHASH |
| 02:39:46 | ewust: | so this will tell you that SignatureHash shouldn't be returning 1, but what should it do there, throw an exception? |
| 02:40:40 | gmaxwell: | it won't compile. |
| 02:40:52 | gmaxwell: | I mean for compatiblity we'll make that work by explicitly converting it. |
| 02:41:17 | gmaxwell: | But if this had been caught upfront the test would have been lifted out of signaturehash and just made the signature check fail. |
| 02:44:08 | jgarzik: | shockingly, uint256_tests.cpp is grumpy ;p |
| 03:37:13 | jgarzik: | * jgarzik kicks boost |
| 03:37:59 | jgarzik: | * jgarzik would love to adopt the majority of google's C++ coding conventions. rule #1: no templates ;p |
| 03:38:43 | jrmithdobbs: | ok but only if rule #2 is no golang |
| 03:39:40 | Luke-Jr: | jgarzik: pfft, templates are like the main reason to use C++ :P |
| 03:40:24 | jrmithdobbs: | Luke-Jr: they're really not =/ |
| 03:45:35 | copumpkin: | jrmithdobbs: I thought you liked Haskell :P |
| 03:46:43 | jrmithdobbs: | copumpkin: hmm? I do |
| 03:47:10 | jrmithdobbs: | copumpkin: but c++ has much more redeeming features than it's template clusterfuck ;p |
| 03:47:20 | jgarzik: | main.cpp:1331:114: error: no match for operator+ (operand types are uint256 |
| 03:47:21 | jgarzik: | and uint256) |
| 03:47:21 | jgarzik: | if (pindexBestForkTip || (pindexBestInvalid && pindexBestInvalid->nChainWor |
| 03:47:21 | jgarzik: | k > chainActive.Tip()->nChainWork + (chainActive.Tip()->GetBlockWork() * 6).getu |
| 03:47:21 | jgarzik: | int256())) |
| 03:47:35 | jgarzik: | hum, surprised that's not a bignum addition |
| 03:47:39 | jgarzik: | ... |
| 03:47:43 | jrmithdobbs: | shouldn't it be? |
| 03:47:51 | copumpkin: | jrmithdobbs: oh, so you're saying there's more of value in C++ than templates, rather than saying that templates suck :) sorry, the former interpretation was so inconceivable to me that I didn't consider it |
| 03:48:17 | jrmithdobbs: | copumpkin: haha, completely understandable misunderstanding, it is c++ |
| 03:48:22 | jgarzik: | gmaxwell, sipa: ^ |
| 03:50:32 | hasan1: | hasan1 is now known as shinybro_ |
| 03:52:33 | gmaxwell: | jgarzik: I think the reasoning here is just that the network is not going to do more than 2^256 work before the heat death of the universe, and if somehow it does, we have much bigger problems. |
| 03:53:11 | gmaxwell: | and bignums are not as nice as uint256 (e.g. slower, more allocation churn, etc) |
| 03:57:12 | maaku: | ok, let me demonstrate my ECDSA ignorance. the equations for signing are r = k * Gx, s = k^-1 * (z + r*d). |
| 03:57:21 | maaku: | and the public key x component is Qx = d * Gx. |
| 03:57:24 | maaku: | does that not mean you can rewrite s = k^-1 * (z + k * Qx)? |
| 03:57:31 | maaku: | and forge any signature, given the pubkey? |
| 03:57:42 | maaku: | i know I haven't discovered such a trivial flaw, but where did I go wrong? |
| 03:57:46 | just[dead]: | just[dead] is now known as justanotheruser |
| 03:58:52 | gmaxwell: | you totally can, if you know k. but you don't know k. |
| 03:59:34 | gmaxwell: | (well perhaps I should decode your notation first) |
| 03:59:45 | gmaxwell: | z is the data you intend to sign? |
| 04:00:35 | maaku: | yes |
| 04:01:43 | maaku: | and no, i'm forging a signature for a given message, so I'm free to pick k, no? |
| 04:01:51 | maaku: | i got these equations from Wikipedia's ECDSA page |
| 04:03:14 | maaku: | (I tried forging a signature and -- no surprise -- it didn't work. But I don't know where I went wrong on the math) |
| 04:03:58 | jgarzik: | So, tl;dr is: we found a lot of uses for 256-integer maths, because we have a fully working uint256 lying around ;p |
| 04:04:29 | gmaxwell: | internal uint256 > library bignums everwhere... but. meh. |
| 04:06:32 | gmaxwell: | you can't do that rewrite. r*d != k*d*Gx because r is not a point, it's a scalar. |
| 04:06:44 | gmaxwell: | (this is one place where the notation adds opacity) |
| 04:07:03 | gmaxwell: | since it's not clear when its operations in the curve group or in the integer field. |
| 04:13:59 | gmaxwell: | yea, so I can't find anything that points out that signature of 0 are trivially forgable. Thats annoying. I can't realistically see myself ever coming up with a protocol that was insecure due to that, at least not intentionally. |
| 04:14:07 | gmaxwell: | none the less... |
| 04:16:42 | maaku: | gmaxwell: i thought they were all scalars |
| 04:16:49 | maaku: | i guess I'll have to read up on EC algebra |
| 04:17:14 | Luke-Jr: | gmaxwell: signature of 0 are forgable? 0 as the data? |
| 04:18:28 | copumpkin: | * copumpkin ensures that all his messages hash to 0 to ensure plausible deniability |
| 04:20:03 | phantomcircuit: | gmaxwell, have you tried removing the uint256 casting functions? |
| 04:20:22 | phantomcircuit: | i assume it would break a few things which could then be made explicitly weird |
| 04:20:27 | phantomcircuit: | instead of implicitly weird |
| 04:20:53 | ewust: | Luke-Jr: signatures of data that hashes to 00000000... are forgeable |
| 04:21:15 | Luke-Jr: | * Luke-Jr wonders what data hashes to 0000000… |
| 04:21:29 | ewust: | the terminal block |
| 04:25:28 | jgarzik: | edit SHA256() to exit(3) if all-zeroes results is generated |
| 04:31:48 | jgarzik: | Excellent... uint160 is quite clean. None of the bitwise, arith, lt/gt cmp operators are used. |
| 04:32:47 | jgarzik: | unfortunately they will always be dword-based, and never purely opaque |
| 04:36:11 | ewust: | jgarzik: you mean, hexdump the input data, then exit(3)? |
| 04:36:25 | tacotime_: | tacotime_ is now known as tt_zzz |
| 04:37:43 | phantomcircuit: | ewust, he means blow up amazingly if the state is dangerous |
| 04:38:51 | ewust: | but what if someone won the sha256 lottery, and you exited before printing the winning ticket! |
| 04:39:48 | phantomcircuit: | ewust, i think the 1 in 2^256 odds of that happening are good enough to ignore |
| 04:40:01 | ewust: | :) |
| 04:40:21 | ewust: | pessimist! |
| 04:40:29 | tt_zzz: | I'm pretty sure that something should pop up specifying that you've now won bitcoin |
| 04:40:32 | tt_zzz: | ok i am sleeping |
| 04:46:08 | gmaxwell: | Luke-Jr: I do feel a little bit of an itch to make signatures of 0 fail. |
| 04:46:37 | gmaxwell: | just in case some snazzy attack on sha256 lets you get an all zero hash out of anything.. |
| 04:46:51 | gmaxwell: | but I reconize that it's a silly concern. |
| 04:50:15 | ewust: | gmaxwell: what would the issue be even if sha256 let you do that? anyone can already generate such signatures without your private key |
| 04:50:58 | gmaxwell: | ewust: they can't generate transactions that have a hash of 0 |
| 04:53:51 | ewust: | oh nvm, i was thinking you were proposing that check on generation, not verification |
| 05:03:59 | gmaxwell: | Grrr. using an analog modem on the phone line here disrupts my DSL modem. |
| 05:46:10 | BCB: | BCB has left #bitcoin-wizards |
| 05:52:19 | Luke-Jr: | gmaxwell: : |
| 05:52:23 | Luke-Jr: | ☹* |
| 05:52:56 | gmaxwell: | yea, the real challenge will be calling the provider for support. Hopefully a regular analog phone call also disrupts it. |
| 05:53:11 | gmaxwell: | Because I think if I tell them a modem disrupts it their minds will melt. |
| 05:53:21 | maaku: | gmaxwell: ok i understand now, thanks |
| 05:56:23 | justanotheruser: | justanotheruser is now known as just[dead] |
| 05:56:43 | Luke-Jr: | gmaxwell: they might need the same frequencies? |
| 05:57:06 | gmaxwell: | Luke-Jr: nope not at all, they should be completely compatible. |
| 05:57:11 | Luke-Jr: | hm |
| 05:57:30 | gmaxwell: | ADSL doesn't use anything under 40kHz or something like that, where all the modem stuff is <8kHz. |
| 05:57:37 | Luke-Jr: | gmaxwell: maybe they will understand trying to send a fax, if you can't reproduce with voice. |
| 05:57:46 | gmaxwell: | yea, good call. |
| 05:58:27 | jrmithdobbs: | they only gaurantee fax-level service too (helpful to know to route through support) |
| 05:58:47 | jrmithdobbs: | as far as data over plain residential pots lines |
| 06:00:48 | jrmithdobbs: | try again |
| 06:02:45 | Luke-Jr: | ? |
| 06:02:51 | midnightmagic: | there's supposed to be an rf choke which cleans and isolates noise and ring from the two signals. it's possible all you need is a little $5 filter. |
| 06:03:31 | jrmithdobbs: | Luke-Jr: wrong window |
| 06:03:46 | gmaxwell: | midnightmagic: I have the filter, actually I tried stacking two of them. |
| 06:04:19 | midnightmagic: | might be defective pieces of crap because the lineman decided to be a dickhead |
| 06:05:41 | gmaxwell: | so I know my line quality is not very good. e.g. DSL has gone down when its rained. and the SNR reports from the dsl modem are not fantastic. |
| 06:05:56 | gmaxwell: | I think it's probably just operating at the margins and the concurrent modem use is enough to push it over. |
| 06:06:09 | gmaxwell: | Luke-Jr: why does eligius gbt no longer return transactions? |
| 06:06:23 | gmaxwell: | I was unable to tell the dude in #bitcoin if his transaction was about to be mined... |
| 06:10:15 | Luke-Jr: | gmaxwell: to reduce startup bandwidth, not new |
| 06:10:36 | Luke-Jr: | bitcoind -rpcconnect=gbt.mining.eligius.st -rpcuser=x -rpcport=9337 -rpcpassword=x getblocktemplate '{"longpollid":"bootstrap"}' |
| 06:11:18 | Luke-Jr: | gmaxwell: the idea is to send an empty block template first, then immediately longpoll with a full block template |
| 06:12:04 | gmaxwell: | not unreasonable... I just wasn't aware you started that and hadn't updated my scripts. |
| 06:12:07 | Luke-Jr: | actually, it only does the empty if it hasn't seen a request in like 5 mins, so simply retrying might work too |
| 06:14:39 | Luke-Jr: | gmaxwell: 2012 Nov 5 change date ;) |
| 06:16:55 | midnightmagic: | * midnightmagic is inclined to still blame the lineman |
| 06:17:07 | midnightmagic: | :-) |
| 06:33:24 | gmaxwell: | Luke-Jr: so how awful do you think it would be to run with a policy where you'll replace a transaction in the memory pool with one with higher fees, if and only if it pays the same amounts to the same outputs, but allowing up to one output to be up to $fees less? |
| 06:35:37 | gmaxwell: | trying to help this guy conflict compute a replacement with a fee, and annoyingly nothing will take it because the original feeless one is in the mempool. |
| 06:46:22 | Luke-Jr: | gmaxwell: sounds reasonable to me, though to be extra conservative perhaps not allow the change address concession |
| 06:46:36 | Luke-Jr: | eg, so they have to add an input |
| 06:47:14 | gmaxwell: | so, in the case I was just working on— he had no other inputs :( |
| 06:47:17 | Luke-Jr: | would be nice if we could have some kind of modular embedded Python for policy |
| 06:47:27 | gmaxwell: | I expect thats not too uncommon. |
| 06:47:47 | Luke-Jr: | gmaxwell: well, he could use CPFP too |
| 06:49:16 | Luke-Jr: | usually between adding another input and CPFP, I'd expect at least one to be viable |
| 06:51:41 | gmaxwell: | okay thats a point. |
| 06:51:57 | just[dead]: | just[dead] is now known as justanotheruser |
| 08:05:04 | LarsLarsen: | LarsLarsen is now known as needmoarmindmelt |
| 08:05:34 | needmoarmindmelt: | needmoarmindmelt is now known as LarsLarsen |
| 09:22:23 | wumpus: | would be nice if we could have some kind of modular embedded Python for policy <- that won't happen, but maybe a way to 'outsource' policy decisions to another process? |
| 09:23:59 | gavinandresen_: | gavinandresen_ is now known as gavinandresen |
| 09:41:54 | dansmith_btc: | Please help me understand. Is it possible to create such a proof-of-stake system where there is no possiblity of multiple chains. At least the following should be imlemented A) if a miner broadcasts two blocks when it is his turn, such miner will lose (temporarily) the privilege of mining B) A miner must broadcast a block within his specific time frame (1 minute). Would not these 2 safeguards prevent any forks in the Po |
| 09:41:55 | dansmith_btc: | s blockchain? |
| 09:45:54 | Ademan: | dansmith_btc: A miner could maintain multiple nodes and circumvent this |
| 09:48:37 | dansmith_btc: | Ademan, circumvent A) or B) ? and how? |
| 09:49:39 | Ademan: | dansmith_btc: A, how would you know that the two nodes are the same miner? |
| 09:50:47 | Ademan: | plus, so lets say I send one block to half of my connections, and a different one to the others. Eventually, both sets of nodes will realize what I've done, but they'll disagree about which one came first and is correct, how do you resolve this? |
| 09:51:04 | dansmith_btc: | Ademan, because in proof of stake the block is created by an address which holds a btc balance and signed thereby. If the miner broadcasts 2 signed blocks - that's malicious intent. |
| 09:51:44 | dansmith_btc: | Ademan, if the nodes see 2 blocks by the same miner, they mark such miner as malicious |
| 09:52:13 | Ademan: | do they then mark *all* of that miner's blocks as bad? |
| 09:52:26 | dansmith_btc: | yes, both |
| 09:52:41 | Ademan: | What if somebody has already built on one or both chains? do you rewind? |
| 09:52:52 | dansmith_btc: | or however many the attacking miner has sent within his alloted timeframe of block-sending |
| 09:53:24 | stonecoldpat: | is it possible for an attacker to change a block, but allow it to remain valid? ( a bit like transaction malleability) |
| 09:53:26 | dansmith_btc: | That's why I suggested B) - each miner has a designated timeframe |
| 09:54:44 | Ademan: | well with that you gain the rather difficult problem of accurate timekeeping in a distributed system |
| 09:54:58 | dansmith_btc: | Ademan, you are saying "building on top" - this is the current PoW terminology, not PoS |
| 09:56:33 | dansmith_btc: | each miner will be expected to be properly time-synced. Is that rather difficult? |
| 09:56:55 | Ademan: | how can you prevent them from lying? |
| 09:57:21 | Ademan: | well sorry, I know my block just reached you but I swear it's from XX:YY:ZZ |
| 09:59:03 | Ademan: | and you can't prove that it didn't just take a long path around the network before it got to you |
| 09:59:15 | dansmith_btc: | Ademan because we have a certaing timeframe of, say 1 minute and within that 1 minute the block must be broadcast and propagate to each miner. So every miner will be expecting a block from a specific miner within that 1 minute. |
| 10:00:10 | dansmith_btc: | But I see your point, there's always this "long path arounf the network" excuse |
| 10:00:40 | stonecoldpat1: | stonecoldpat1 is now known as stonecoldpat |
| 10:00:54 | dansmith_btc: | If one minute is not enough, we can make it 2 minutes. Surely that will suffice. |
| 10:02:05 | Ademan: | malicious nodes could also create their own latency (refuse to transmit a block indefinitely) |
| 10:02:29 | Ademan: | that might be tough to pull off but certainly not impossible |
| 10:07:49 | Ademan: | anyways I've got to get to bed, it's super late and I'm fried. With a bit of sleep I'll have some better thoughts on this anyways |
| 10:34:18 | justanotheruser: | justanotheruser is now known as just[dead] |
| 11:37:26 | fanquake: | fanquake has left #bitcoin-wizards |
| 13:16:22 | tt_zzz: | tt_zzz is now known as tacotime_ |
| 13:41:37 | andytoshi: | 2014-02-09 19:16:33 petertodd if SIGHASH_SINGLE is used and txin idx > max txout idx you get an error, SignatureHash() returns 1... but that error is never caught anywhere so it's treated as though the hash was 1 |
| 13:41:41 | andytoshi: | 2014-02-09 19:17:14 petertodd I hear if 0 had been returned instead it'd be a backdoor to spend anyones funds apparently |
| 13:41:54 | andytoshi: | gmaxwell: if you just noticed this, where did petertodd hear it? o.O |
| 13:43:55 | gmaxwell: | crazy. not from me. |
| 13:44:02 | andytoshi: | dansmith_btc: re 'two minutes has to be enough', then why not just require txouts to be two minutes old before spending, and invalidate any which appear as a result of a sub-2-minute double spend? |
| 13:44:27 | andytoshi: | gmaxwell: huh. i coulda sworn petertodd cited you, but my logs don't show that, so i must be thinking of something else.. |
| 13:44:34 | gmaxwell: | I mean, obviously I knew about the SIGHASH_SINGLE stuff, but hadn't thought through the ECDSA/ |
| 13:44:57 | gmaxwell: | well so.. it has been the case that I've known things before, and forgotten them completely... |
| 13:45:30 | gmaxwell: | it's possible if that happened and the last time I knew it I remembered the return value was 1 I wouldn't have been freaked out about it. |
| 13:47:49 | andytoshi: | i can't find a log entry describing the bug before the one i posted..which was not from that long ago..and iirc i did not know about it before then |
| 13:48:21 | andytoshi: | it could also just be a glitch in the matrix, 1 month is not so far for information to jump :) |
| 13:48:41 | gmaxwell: | andytoshi: the SIGHASH_SINGLE bug has been known for a long time. |
| 13:48:47 | gmaxwell: | BlueMatt found it a couple years ago. |
| 13:48:56 | andytoshi: | yeah, i know that |
| 13:49:31 | andytoshi: | but petertodd's money-stealing comment was news to me |
| 13:49:40 | jgarzik: | andytoshi, gmaxwell: Yah. petertodd fixed bugs related to this in python-bitcoinlib, months ago. |
| 13:49:57 | jgarzik: | I was returning 0, rather than 1. |
| 13:50:05 | gmaxwell: | oh wow. lol |
| 13:50:12 | jgarzik: | (and then checking the error code, rather than assuming it was a valid hash) |
| 13:50:37 | gmaxwell: | oh well thats less bad. |
| 13:50:38 | jgarzik: | i.e. the code would just die upon 0 return |
| 13:51:04 | jgarzik: | petertodd changed it to -not- die, and instead return 1, a la bitcoind |
| 13:51:06 | gmaxwell: | perfectly reasonable way for it to work, in fact. except for that pesky consistency thing. |
| 14:27:14 | zooko: | gmaxwell: I've been thinking about your prove-full-reserve protocol. |
| 14:28:06 | zooko: | gmaxwell: I don't understand what privacy/non-disclosure concern is solved by proving the membership (and sum) under ZK. |
| 14:28:42 | zooko: | The way I envision that, it would result in the public and the customer not knowing whether the company actually controls any particular amount of BTC. |
| 14:28:51 | zooko: | I.e., the company could hold 0 and still perform the ZK protocol I'm imagining. |
| 14:29:01 | zooko: | So, I must have misunderstood it. |
| 14:30:35 | gmaxwell: | zooko: Then you're not imagining the right ZK protocol. |
| 14:32:06 | gmaxwell: | I propose that they show that a blinded pubkey is a member of the set and its encrypted value. And they perform a signature to prove they have the corresponding private key(s). |
| 14:32:20 | zooko: | Ah. |
| 14:32:54 | gmaxwell: | (or you put signature verification under the ZK instead of blinding, though thats much more expensive) |
| 14:33:46 | zooko: | But how can two customers tell that the service provider isn't using the same private key to satisfy each of their challenges? |
| 14:33:58 | zooko: | Ugh, I just realized I said "The Bitcoin CEO" when I meant "The Coinbase CEO". |
| 14:34:01 | zooko: | * zooko drinks more coffee. |
| 14:36:58 | gmaxwell: | My thinking was that you do value agreement by revealing 'encrypted'_value = H(value||txid/vout||nonce) and then do another proof that takes the encrypted values and produces an encrypted sum, and you can't get away with duplication because it forces the nonce to be the same for all inputs... so any duplication would just have duplicated encrypted values. |
| 14:37:27 | gmaxwell: | there may be more efficient ways to go about it.. but just reusing the hash that you'd need to have under the ZKP for membership seemed like a good idea. |
| 14:40:12 | zooko: | Suppose there are only two customers of my service, and I've accidentally lost the Bitcoin of one of them in my couch. |
| 14:40:34 | zooko: | Then I would offer to each of them to do this protocol, but I'd use the remaining private key in both runs. |
| 14:41:01 | gmaxwell: | thats what the whole liabilties side of the proposed protocol is for. |
| 14:41:02 | zooko: | If I were a deceitful scammer. |
| 14:41:15 | zooko: | Okay, right, that's what I thought. |
| 14:41:21 | zooko: | * zooko reads back… |
| 14:41:43 | tacotime_: | is this protocol formalized anywhere? |
| 14:41:46 | zooko: | Wait, you mean the whole assets side of the protocol? |
| 14:42:02 | zooko: | Hi tacotime_ |
| 14:42:05 | tacotime_: | hi |
| 14:42:10 | zooko: | We're talking about a ZK extension of https://iwilcox.me.uk/2014/proving-bitcoin-reserves |
| 14:42:15 | tacotime_: | okay thanks |
| 14:42:38 | gmaxwell: | zooko: No. liabilties. In the assets side you prove you control some amount of coins. In the liabilties side you prove that you have some amount of obligation to your customers. |
| 14:43:12 | zooko: | Okay, so the Merkle+ZK thing we talked about above was what you're calling the assets side, right? |
| 14:43:17 | gmaxwell: | Yes. |
| 14:44:43 | gmaxwell: | the liabilties side in the original is low information leak to begin with but does reveal the sum. to make it completely zk you instead use encrypted values (like I just pointed out for the assets) and provide a ZK proof that the values are faithful. |
| 14:45:00 | zooko: | If I as the company go ahead and publicly demonstrate control over a certain sum of BTC, let's call it "X", then I can see how the https://iwilcox.me.uk/2014/proving-bitcoin-reserves#merkle_top protocol could let each customer challenge me and verify that the integer balance of my account in their books is included in their book's sum, |
| 14:45:14 | zooko: | and then I can check that their proven holdings X ≥ that sum. |
| 14:45:24 | zooko: | That's the non-ZK version that is on https://iwilcox.me.uk/2014/proving-bitcoin-reserves#merkle_top IIUC. |
| 14:45:53 | gmaxwell: | right. |
| 14:46:28 | zooko: | Okay, so what I want different from https://iwilcox.me.uk/2014/proving-bitcoin-reserves#merkle_top right now is to not reveal the sum of BTC holdings -- X -- to any customer or to the public. |
| 14:46:43 | zooko: | I currently think that the ZK extension you've mentioned isn't intended for that. |
| 14:46:50 | gmaxwell: | it is. |
| 14:47:17 | gmaxwell: | You augment the protocol by replacing the two halves with ZK versions. |
| 14:47:42 | zooko: | Ah! I was thinking only of the prove-to-customers-something-about-the-sum-of-their-account-balances side. |
| 14:47:53 | zooko: | (That's the *liabilities* side, right?) |
| 14:47:58 | gmaxwell: | Yes. |
| 14:48:09 | gmaxwell: | so I was talking in here about the assets side, since thats a bit harder to make ZK. |
| 14:48:41 | zooko: | How do you prove that you control an amount of BTC ≥ the sum of all customers' (who checked) accounts without revealing the amount of BTC you control? |
| 14:48:59 | zooko: | "talking in here" -- you mean the discussion in the last ten minutes, above? |
| 14:49:13 | zooko: | I've only read through it five times already, so maybe it is time for a sixth pass now that I understand this. ;-) |
| 14:49:24 | gmaxwell: | no no I thought you saw a discussion earlier since you mentioned "the membership (and sum) under ZK" |
| 14:49:36 | zooko: | Doh, sorry, I haven't read backlog. |
| 14:49:41 | gmaxwell: | it's okay. |
| 14:49:50 | zooko: | I have seen you mention it on IRC in the past |
| 14:49:55 | zooko: | and we talked about it in person a couple of weeks ago. |
| 14:50:20 | gmaxwell: | to prove you control you dump out a list of spendable coins including ones you control and don't control. (doesn't have to be all of them, but it limits our anonymity set) |
| 14:50:28 | zooko: | Okay. |
| 14:50:46 | gmaxwell: | then you compute a hash tree over them. Verifier does the same thing, so everyone is happy that the hash root is faithful. |
| 14:51:12 | zooko: | Okay this is a root of a... |
| 14:51:21 | zooko: | What's the *word* for this Merkle Tree over secure-hashes-and-sums? |
| 14:51:36 | zooko: | Anyway, is it that sort of tree, so we have secure hash and sum of all the keys in its leaves? |
| 14:51:36 | gmaxwell: | doesn't need to have sums for this tree. |
| 14:51:38 | zooko: | leafs? |
| 14:51:42 | zooko: | Okay, just a hash tree then. |
| 14:53:30 | gmaxwell: | then for the coin you want to prove you control you extract a branch from the hash tree (membership proof), and you extract the pubkey, and also produce a blinded pubkey (pubkey+blinding_factor) and under a ZKP verify the membership proof, you verify blinded pubkey agrees with the pubkey, you verify that the pubkey matches the transaction, and you reveal H(value||txid/vout||nonce). |
| 14:54:14 | gmaxwell: | so the verifier knows the root (computed themselves) and they know that you know a coin verifyable under that root, which has a specific blinded pubkey, and some hashed up value. |
| 14:54:32 | gmaxwell: | you also provide a signature with the blinded pubkey, which proves you can sign for the transaction. |
| 14:56:02 | gmaxwell: | the blinding is just blinding_factor = random*g ; blinded_key = pubkey+blinding_factor ; thus the private key is the original private + random due to the additive homorphism in the EC group. |
| 14:56:44 | gmaxwell: | and the only EC math under the proof is the addition to verify that the blinded pubkey is really the product of adding the real pubkey and some point. |
| 14:57:01 | zooko: | Hm. |
| 14:57:32 | gmaxwell: | I should pause to point out that petertodd has proposed an alternative way to make this stuff private which doesn't require as much crypto magic. |
| 14:57:55 | zooko: | Is it written down in a document? |
| 14:59:27 | gmaxwell: | No, it's simple at least: Just run times original protocol N-times in parallel, splitting up the customers and the funds. So that each customer sees at most 1/Nth of the funds. You can prevent the same funds from being reused in multiple proofs by putting the hash of the final commitment _in_ the funds in question, like, actually in the transactions. |
| 14:59:42 | gmaxwell: | of course if the customers cooperate it loses the privacy. |
| 14:59:46 | gmaxwell: | (for the service) |
| 14:59:51 | tacotime_: | can you guys recommend a good textbook on zkps relevant to the stuff we're doing with bitcoin? i feel out of the loop on this. |
| 14:59:54 | zooko: | Oh, relatedly, I've been looking for "fidelity bond" stuff that petertodd has allegedly written about, and the man himself answered my search queries, but the answer was to ask a search engine for certain keywords in certain fora, which hasn't worked. |
| 15:00:05 | zooko: | So, if you know of a document of petertodd's fidelity-bond ideas |
| 15:00:10 | zooko: | or anyone's, I'd appreciate a link. |
| 15:01:29 | zooko: | Also relatedly, hey petertodd: you said that "mix net something something" from FC'14 was related. Is this it? http://ifca.ai/fc14/papers/fc14_submission_170.pdf |
| 15:01:33 | gmaxwell: | zooko: there are a bunch of posts: https://bitcointalk.org/index.php?topic=146307.0 https://bitcointalk.org/index.php?topic=134827.0 http://sourceforge.net/p/bitcoin/mailman/message/29185108/ |
| 15:01:38 | zooko: | gmaxwell: thanks! |
| 15:09:24 | zooko: | Okay, I'm taking a break and will study those links, that PDF, and the most recent few lines that gmaxwell posted into this discussion. |
| 15:23:00 | comboy: | sorry for OT, hard to find fresh articles, any recommendations for linux disk encryption? is dm-crypt + luks still the best way to go? aes-xts-plain64? |
| 15:25:49 | gmaxwell: | thats what I use.. I also use pam_mount to mount my seperately encrypted home. |
| 15:30:00 | comboy: | gmaxwell: thx |
| 15:39:45 | Ademan: | So looking at https://bitcointalk.org/index.php?topic=91843.msg1011956#msg1011956 has anyone implemented this? It seems plenty reasonable. "You can also reduce the extortion risk by [...] refund txn with far future nlocktime" Doesn't that *eliminate* the extortion risk? |
| 15:43:42 | jgarzik: | Is extortion risk ever really eliminated in the human world? |
| 15:43:49 | Ademan: | Also I assume that by "both transactions are in" they mean confirmed |
| 15:44:05 | Ademan: | eh true I suppose |
| 15:45:01 | Ademan: | I guess I wasn't thinking about the "human" element here, just the protocol ;-) |
| 15:45:23 | Ademan: | But that is a good point in a lot of cases |
| 15:53:57 | super3_: | super3_ is now known as super3 |
| 16:06:41 | Ademan: | Actually no, I'm more tired than I thought. I'm not sure I understand the protocol entirely. So prior to the reveal, both parties know one secret, and their own private key. how does revealing Asecret enable me to spend BCoin? |
| 16:07:18 | Ademan: | or is it that when the other party spends their coin they reveal to me the other secret? |
| 16:08:00 | Ademan: | So theoretically they could hose me by never telling me their secret, and never spending that coin? |
| 16:37:38 | gmaxwell: | Ademan: it doesn't eliminate the extortion risk because the DOS attack is still extortion. |
| 16:38:07 | gmaxwell: | Also because if one party has given up their preimage you can try to race them at the point where the locktime expires. |
| 16:38:47 | gmaxwell: | alice releases her secret, bob says haha ... then bob waits until the locktime and tries to simultaniously collect his refund and alice's coin. |
| 16:39:10 | gmaxwell: | you can improve this by staging the locktimes in the order you do secret reveals, but the DOS attack still exists. |
| 16:39:35 | gmaxwell: | 09:08 < Ademan> So theoretically they could hose me by never telling me their secret, and never spending that coin? |
| 16:39:43 | gmaxwell: | no because of the refunds you setpu. |
| 16:39:44 | gmaxwell: | er setup. |
| 17:16:05 | maaku: | jgarzik: maybe if you eliminate the humans? |
| 17:17:35 | gmaxwell: | Exterminate. |
| 17:19:18 | maaku: | that solves a lot of problems |
| 17:59:26 | just[dead]: | just[dead] is now known as justanotheruser |
| 18:15:41 | zooko: | * zooko is back |
| 18:17:47 | amiller: | hi zooko :) |
| 18:18:29 | sipa: | * sipa is front |
| 18:19:11 | gmaxwell: | * gmaxwell is clockwise |
| 18:21:32 | zooko: | ☺ |
| 18:25:20 | [-krypto-]: | is this the right channel for asking questions about new innovations? |
| 18:25:27 | sipa: | sure |
| 18:25:46 | [-krypto-]: | sipa great |
| 18:25:49 | [-krypto-]: | :) |
| 18:26:05 | amiller: | [-krypto-], welcome! i look forward to hearing your questions about innovation. |
| 18:28:33 | [-krypto-]: | first I should say I am no dev and I am ignorant the subject, but my first question about storage, I read that namecoin has that as a possibility in its future and I was wondering if it would be possible to build a coin that could do the same |
| 18:29:10 | sipa: | datacoin has data storage as explicit purpose |
| 18:29:34 | [-krypto-]: | sipa oh I did not know that |
| 18:29:39 | tacotime_: | and maidsafe, etc |
| 18:29:55 | [-krypto-]: | thanks guys |
| 18:30:48 | Emcy_: | is miadsafe really a thing |
| 18:31:00 | tacotime_: | Emcy_, yeah |
| 18:31:07 | tacotime_: | they're launching a blockchain thing in april |
| 18:31:11 | Emcy_: | cos thier website is terribly flashy and i take that as the inverse of the actual functionality of what theyre foing |
| 18:31:26 | [-krypto-]: | right now I am hireing some devs and I will come back here later to ask more questions once that is completed... thanks for all your help |
| 18:31:37 | [-krypto-]: | :) |
| 18:31:41 | tacotime_: | Emcy_, its more or less an encrypted ccn that gives coins for storing stuff on the overall network |
| 18:32:11 | justanotheruser: | justanotheruser is now known as just[dead] |
| 18:32:29 | Emcy_: | the most incredile innovations in histroy were announced with I made this thing here is the source |
| 18:34:05 | gmaxwell: | tacotime_: datacoin, as dumb as it is actually has something; the madesafe stuff has been a lot of not obviously sensible jargon so far. |
| 18:34:53 | amiller: | step 1. hire developers, step 2. background reading :p |
| 18:35:12 | tacotime_: | gmaxwell, yeah i didn't talk to them much at the con so i have no idea how much of it is valid and how much is handwaving. |
| 18:35:37 | [-krypto-]: | amiller: background reading? |
| 18:36:03 | gmaxwell: | tacotime_: I promise that there is a lot of handwaving; but that doesn't prevent there from being substance too. |
| 18:39:14 | [-krypto-]: | after reading datacoin's site, it makes me think that the next possible step could be that the blockchain could be used as an alternative to torrent websites |
| 18:39:58 | tacotime_: | [-krypto-], there's someone doing that too |
| 18:40:04 | tacotime_: | storing the metadata in the chain |
| 18:40:09 | [-krypto-]: | oh wow |
| 18:40:35 | Emcy_: | magnets |
| 18:40:46 | gmaxwell: | [-krypto-]: I think in general blockchains are a very poor model for data storage, but I'm happy to see people expirementing. |
| 18:40:57 | tacotime_: | i think that's what super3's fork that won the conference at the hackathon was doing, along with filesharing stuff that i didn't read much on suggested by gmaxwell |
| 18:41:12 | Emcy_: | theyre poor for storage |
| 18:41:19 | phantomcircuit: | gmaxwell, i dont understand why people are fixated on using a blockchain for everything |
| 18:41:21 | Emcy_: | better for anti-censorship though |
| 18:41:24 | tacotime_: | gmaxwell probably knows more on this than i do, but super3 was talking about storing the metadata in chain when i was there |
| 18:41:34 | phantomcircuit: | it's really a very inefficient way of doing just about anything other than distributed consensus |
| 18:41:41 | phantomcircuit: | which you dont need for file storage |
| 18:41:56 | gmaxwell: | phantomcircuit: same reason they were fixated on DHTs for everything two years ago, and on XML for everything 5 years ago, and LDAP for everything 10 years ago. |
| 18:42:07 | Luke-Jr: | haha |
| 18:42:07 | phantomcircuit: | lol xml |
| 18:42:18 | phantomcircuit: | im dealing with ridiculous xml api right now |
| 18:42:19 | gmaxwell: | I've got a shiny new hammer and you are all now nails. |
| 18:42:37 | [-krypto-]: | phantomcircuit: I just want to see how far we push these coins |
| 18:42:39 | phantomcircuit: | it's case sensitive on the element names and there is no consistency |
| 18:42:43 | Emcy_: | DHTs havent gone out of fashion yet |
| 18:42:54 | gmaxwell: | Emcy_: people have mostly stopped bothering me about them. |
| 18:42:57 | tacotime_: | just ask darkwallet |
| 18:42:58 | tacotime_: | heh |
| 18:43:21 | phantomcircuit: | what are they using a dht for? |
| 18:43:32 | gmaxwell: | marketing? |
| 18:43:48 | tacotime_: | there was something in their wiki about it, lemme dig it up |
| 18:43:54 | gmaxwell: | yet another altcoin launched with a long feature list and none of the code written up for any of it. |
| 18:44:12 | gmaxwell: | or am I confusing that with darksomethingelse? |
| 18:44:13 | tacotime_: | https://wiki.unsystem.net/index.php/DarkWallet/Meetings/Nov2013 |
| 18:44:24 | gmaxwell: | oh no darkwallet is the unsystem people. |
| 18:44:28 | tacotime_: | "Semi-persistant distributed storage via DHT network and embedded hashes in the blockchain. We can have a fast encrypted web better than freenet and fast." |
| 18:44:46 | gmaxwell: | ow. that handwave hit me in the face. |
| 18:44:47 | tacotime_: | better than freenet and fast |
| 18:44:51 | tacotime_: | haha |
| 18:45:10 | gmaxwell: | with deluxe super shammy powers, buy now and get the second ABSOLUTELY FREE. |
| 18:46:18 | gmaxwell: | maybe there is indeed a way to use an anonymous consensus to undo some of the traditional DHT failsauce unreliability... but so far I've not seen any serious work. I think perhaps until we have some better language for abstractions about this stuff it will be too complicated to reason about. :( |
| 18:46:32 | Emcy_: | shamwow |
| 18:46:54 | nsh_: | or an empirical proving ground |
| 18:46:59 | nsh_: | (or both) |
| 18:46:59 | Luke-Jr: | much DHT |
| 18:47:24 | Emcy_: | anyone remeber something called blocksnet? |
| 18:47:24 | BlueMatt: | but she (and I) was wondering |
| 18:47:28 | BlueMatt: | https://twitter.com/TheBlueMatt/status/443458112117149696 |
| 18:47:29 | Emcy_: | the blurb for that was euphoric |
| 18:47:32 | BlueMatt: | wrong copy/paste |
| 18:47:59 | [-krypto-]: | blocksnet? |
| 18:48:21 | Emcy_: | or the OFF system |
| 18:48:24 | Emcy_: | same thing |
| 18:48:38 | [-krypto-]: | no |
| 18:49:54 | Emcy_: | i just want someone to make a system with little fanfare that goes big because it works ans is fantastic |
| 18:50:00 | Emcy_: | it only takes one, out of how many tries? |
| 18:50:41 | Emcy_: | perfect dark uses all that DHT gubbins and does it, but its closed source an JP only |
| 18:51:06 | tacotime_: | i'm trying to make my pos/pow hybrid coin without a lot of fanfare, but whether or not it's fantastic remains to be seen. |
| 18:51:18 | tacotime_: | or not susceptible to a load of new attacks. |
| 18:51:21 | gmaxwell: | there are like a zillion japanese crazy p2p apps that no one in the english speaking world knows anything about. |
| 18:51:45 | zooko: | tacotime_: I'm interested in your ideas. |
| 18:51:49 | gmaxwell: | Gotta have some way to share your tentical porn manga without freaking out the westerners. |
| 18:52:03 | zooko: | tacotime_: because I was thinking of similar things and then found your pages. |
| 18:52:07 | Emcy_: | thats exactly what they do with it |
| 18:52:33 | [-krypto-]: | tacotime_: have you named it yet? |
| 18:52:40 | tacotime_: | zooko, cool, i'm glad someone thinks they are interesting heh. :) |
| 18:52:55 | tacotime_: | the official name is coming out in a bit, when we launch forums/website. |
| 18:53:04 | Emcy_: | actually i think the window for a working worldwide distributed datastore has passed,, sadly |
| 18:53:26 | Emcy_: | "what is this program its taking up 10GB on my 2Tb drive and i dont know what it is this is unacceptable" |
| 18:53:42 | [-krypto-]: | tacotime_: I am interested in your coin, keep me posted :) |
| 18:53:55 | Emcy_: | and the era of unmetered internet is drawing to a close, and so is net neutrality |
| 18:54:30 | nsh_: | "JP only"? |
| 18:54:40 | nsh_: | oh, japanese |
| 18:54:44 | gmaxwell: | Emcy_: the general public is moving to hermetically sealed consumption-mostly devices (like ipads) in droves in any case. |
| 18:56:25 | Emcy_: | feels bad man |
| 18:56:49 | phantomcircuit: | Emcy_, bizarrely there are simultaneous movement away from unmetered and towards it in different areas |
| 18:56:57 | Emcy_: | and its not like they even give those little consumtion pads away for free, which they really should |
| 18:56:59 | phantomcircuit: | comcast/timewarner/att are all moving away from it |
| 18:57:09 | phantomcircuit: | while comptition is appearing that offers it on 1gbps lines |
| 18:57:24 | Emcy_: | just google fibre? |
| 18:57:49 | phantomcircuit: | Emcy_, google fiber, various municipalities, sonic.net in sf (although that is lol slow becuase it's sf) |
| 18:58:04 | phantomcircuit: | (they might be endangering a cricket with their fiber optic lines!!) |
| 18:58:37 | Emcy_: | when google is our last hope for techno freedom you know were in a tight spot |
| 18:59:23 | phantomcircuit: | Emcy_, interestingly the primary thing google is able to do is push municiple governments into stream lining the application process |
| 18:59:37 | Emcy_: | also i am brit so i laught at all of that and im enjoying my country carved up by a quasi state monopoly and a complete shithouse of a cable company |
| 18:59:54 | phantomcircuit: | which means if they become ridiculous someone could come after them and take advantage of the easier streamlined process to compete with them |
| 18:59:58 | sipa: | gmaxwell: https://twitter.com/TheBlueMatt/status/443458112117149696 |
| 19:00:20 | phantomcircuit: | Emcy_, lol bt is ridiculous |
| 19:00:37 | Emcy_: | yeah |
| 19:00:45 | tacotime_: | pretty soon we'll be verifying everything in 288 bytes |
| 19:01:12 | Emcy_: | my main ISP aa.net basically has a function of dealing with BTs bullshit so i dont have to. Thats what i pay them for they know it and i know it. |
| 19:01:44 | Emcy_: | the MD regularly blogs about his fun with BT, most recent being told by BT that 3% packet loss on an idle line is "not a fault" |
| 19:03:29 | phantomcircuit: | Emcy_, there's probably some contractual limit (i would guess 5%) that defines what a fault is |
| 19:04:51 | nsh_: | technically the infrastructure is maintained by a (sort of) spin-off company now |
| 19:05:53 | Emcy_: | http://revk.www.me.uk/2014/02/bt-official-3-packet-loss-is-not-fault.html if anyone wants to see what an activist ISP boss looks like |
| 19:06:35 | nsh_: | +1 |
| 19:11:31 | phantomcircuit: | -> Seq Scan on cgminer_results (cost=0.00..3331621.68 rows=33913468 width=8) |
| 19:11:32 | phantomcircuit: | lol |
| 19:36:14 | jgarzik: | hrm |
| 19:36:40 | jgarzik: | must resist temptation to write a protobufs-like compiler and tiny lib... for the satoshi serialization stuff |
| 19:37:04 | jgarzik: | a formal definition and some auto-generation would be nice, but, we've already dived down the protobufs rabbit hole |
| 19:45:56 | nsh__: | nsh__ is now known as nsh |
| 20:06:28 | maaku: | maaku is now known as Guest92427 |
| 20:44:22 | gmaxwell: | * gmaxwell worried about the lower tx fee changes |
| 20:44:42 | sbp: | why are you worried? |
| 20:44:55 | sbp: | you sounded quite confident in the 0.9.0 blog post |
| 20:45:25 | gmaxwell: | huh? |
| 20:45:30 | gmaxwell: | I didn't blog about it. |
| 20:45:52 | sbp: | oh right, excuse me |
| 20:46:11 | gmaxwell: | I'm worried because users with very low fees but above the relay threshold are already having long confirm times. Just encouraging people to use even lower fees may not be helpful. |
| 20:46:15 | zooko: | Hi there snp. ☺ |
| 20:46:19 | sbp: | hey zooko |
| 20:48:48 | sbp: | instead of a single heuristic estimate, why not allow a range with user control? |
| 20:49:41 | sbp: | could be as simple as high, medium, and low where high tries to target the confirm in the next block, medium in three blocks, and low in five blocks |
| 20:50:15 | gmaxwell: | sbp: You're talking a lot about something you do not understand. |
| 20:51:27 | gmaxwell: | The behavior in this case is about what nodes are willing to relay and influences how much memory pool backlog and exclusion there is. |
| 20:52:01 | phantomcircuit: | gmaxwell, combined with mempool tx's expiring i think it will be an impovement |
| 20:52:03 | phantomcircuit: | but maybe not |
| 20:52:18 | sbp: | I dunno if two lines is a lot, but point taken :-) |
| 20:52:36 | gmaxwell: | Furthermore, even if this were something about the actual fees the user applies— the user currently has no useful mechenism for determining what they should be "target the confirm" implies complex hurestics, and the consequences for getting it wrong are currently pretty annoying. |
| 20:53:05 | gmaxwell: | (and are made worse by the network being willing to relay things that won't get mined soon) |
| 20:53:15 | gmaxwell: | no biggy, I'm just n00b exhausted. |
| 20:53:46 | sbp: | I was just worried you weren't going to expand on your point, to be honest, and I was interested |
| 20:53:55 | tacotime_: | I'm adding nExpiry to my fork, with probably a max value in terms of height above the current block. It's basically that you can remove a tx from mempool after say, 8 blocks. |
| 20:53:57 | gmaxwell: | thats never a risk with me |
| 20:53:59 | tacotime_: | Good idea/bad idea? |
| 20:54:01 | sbp: | heh, heh |
| 20:54:32 | tacotime_: | Because after a certain height it's unpublishable |
| 20:54:41 | gmaxwell: | ... |
| 20:54:48 | gmaxwell: | great. you know you're going to get people robbed right? |
| 20:54:56 | tacotime_: | Apparently terrible idea heh |
| 20:54:57 | gmaxwell: | I refer you to amiller's paper. |
| 20:55:01 | tacotime_: | Please |
| 20:55:07 | gmaxwell: | er andytoshi's paper |
| 20:55:09 | gmaxwell: | :P |
| 20:55:12 | tacotime_: | Oh |
| 20:55:14 | tacotime_: | :P |
| 20:55:17 | amiller: | you can look at my paper too though if you have time :p |
| 20:55:26 | tacotime_: | What's your paper? |
| 20:55:42 | gmaxwell: | right. thats a very serious design consideration which greatly complicates consensus and fungiblity, since it means that transactions can't reliably surive reorg, even absent an attacker. |
| 20:56:48 | gmaxwell: | tacotime_: it means that in a larger reorg, like the march fork last year, thousands of coins could have been stolen that wouldn't otherwise, as you can be sure many of the senders wouldn't kindly send again. :) |
| 20:57:11 | gmaxwell: | the decision to have locktime work in only one direction was intentional— and perhaps there are ways to do other things but they are not decisions to be taken lightly. |
| 20:58:07 | tacotime_: | Ah, that complicates things, yeah. Thanks for taking the time to explain. |
| 20:59:35 | tacotime_: | So in my fork, I would like people to be able to "lend" stake to someone else for the purpose of claiming a stake block later on. |
| 21:00:02 | tacotime_: | This was a recent invention, so I'm not sure if it's a terrible idea or not, but pooling stake by sending it to someone else in the first place is a dangerous thing. |
| 21:00:16 | tacotime_: | So my idea was this: |
| 21:01:49 | tacotime_: | Create a tx on the network signing a bunch of addresses you own and then providing an address (pubkey hash) that is allowed to claim these coins for use in claiming a PoS block (PoS target is in a number of coins). |
| 21:02:16 | tacotime_: | After the network gets the tx, these coins become unspendable. |
| 21:03:03 | tacotime_: | (and can only be used as proof of stake to the network, by the address (pubkey-privkey pair) you gave to the network) |
| 21:04:11 | tacotime_: | I thought that maybe something like nExpiry would be a way to have an eventual time at which the coins would be no longer able to be used by the stakeholder and become spendable again. |
| 21:04:35 | tacotime_: | But apparently this is a very bad thing. |
| 21:05:19 | tacotime_: | Could you just require a second tx to the network to unlock them and undo the first tx? |
| 21:10:26 | tacotime_: | (and I see satoshi commented on this, derp: https://bitcointalk.org/index.php?topic=1786.0 ) |
| 21:14:50 | phantomcircuit: | tacotime_, that's a dos vector |
| 21:15:08 | phantomcircuit: | if you replaced a tx everytime a conflicting one was received someone could just continuously send out new ones |
| 21:16:41 | tacotime_: | the "lend" tx in the first place? |
| 21:19:45 | tacotime_: | i was thinking it'd be either "lent" or not "lent" per some current block, and then could not be spend again (either lent or spent normally) until you sent a tx unlocking it. |
| 21:21:38 | tacotime_: | *spent |
| 21:23:00 | nsh_: | -- |
| 21:23:01 | nsh_: | He poured a drink down his other throat with the plan that it would head the previous one off at the pass, join forces with it, and together they would get the second to pull itself together. Then all three would go off in search of the first, give it a good talking to and maybe a bit of a sing as well. |
| 21:23:01 | nsh_: | He felt uncertain as to whether the fourth drink had understood all that, so he sent down a fifth to explain the plan more fully and a sixth for moral support. |
| 21:23:04 | nsh_: | -- http://www.angelfire.com/ca3/tomsnyder/hg-3-11.html |
| 21:28:08 | gmaxwell: | Luke-Jr: any idea why the eligius pushtx interface would reject both a doublespend paying a higher fee and reject a CPFP spend of the change? |
| 21:28:12 | gmaxwell: | yea, doublespending would clear them out. I could perhaps see something line an nExpiry safely used for some side effect, but what you don't want is a reorg being forced to invalidate otherwise valid transactions. |
| 21:32:12 | phantomcircuit: | gmaxwell, it wont remove the original from the mempool iirc |
| 21:32:23 | phantomcircuit: | so you cant do pushtx to double spend |
| 21:32:35 | phantomcircuit: | (i was trying to figure out how to do that earlier) |
| 21:33:09 | phantomcircuit: | oh ffs |
| 21:33:59 | nsh_: | is freenode under semi-constant ddos these days or what? can't remember it being so bad ever before |
| 21:35:45 | phantomcircuit: | nsh_, pretty much yeah |
| 21:36:21 | Emcy_: | its GCHQ |
| 21:36:47 | tacotime_: | Is it okay to ask questions like that here? I don't wanna fill this place with stupid, but I don't wanna put out a really broken fork either. |
| 21:37:18 | Emcy_: | like what |
| 21:37:36 | tacotime_: | The "nExpiry" question I just asked, and stuff about my PoS protocol. |
| 21:38:53 | Emcy_: | youre probably ok as long as its technical and related to cryptocurrency |
| 21:38:59 | tacotime_: | Okay. |
| 21:39:17 | Emcy_: | and not related to some extant scam altcoin |
| 21:39:17 | Guest92427: | Guest92427 is now known as maaku |
| 21:39:27 | tacotime_: | Sheez |
| 21:39:45 | tacotime_: | No, mine has no premine etc and isn't out yet |
| 21:39:59 | tacotime_: | It's in the trying to finalize specifications phase |
| 21:40:14 | Emcy_: | why make your own coin? |
| 21:40:44 | tacotime_: | Because Bitcoin will never add something insane like PoS per-block validation, heh |
| 21:40:57 | tacotime_: | And I wanted to play with that and see if I could get it working |
| 21:41:19 | Emcy_: | pos? |
| 21:41:29 | tacotime_: | proof-of-stake |
| 21:41:42 | nsh_: | petulance-of-salmon |
| 21:42:13 | tacotime_: | :P |
| 21:42:23 | Muis: | Muis is now known as Guest23940 |
| 21:42:52 | tacotime_: | I still think it's a neat idea, I think gmaxwell feels it doesn't improve PoW overall and it introduces a lot of terrible instabilities into the blockchain. |
| 21:42:52 | andytoshi: | i am going to add an explicit discussion of nExpiry to my paper, because it has all sorts of nice uses and blows up in non-obvious but horrific ways |
| 21:43:01 | andytoshi: | and it's pretty hard to control it |
| 21:43:12 | Emcy_: | no one begrudges people from experimenting |
| 21:43:46 | Emcy_: | its when they launched the coin 24 hours ago and are already like COME GET YOUR HOT PISSCOINS ONLY $10 PER |
| 21:43:48 | tacotime_: | andytoshi: I posed this to gmax because I'm still a little confused about why it's super super bad |
| 21:44:08 | tacotime_: | tacotime_> Also, I'm still having a little trouble understanding why that can't be done safely. We have a fork to chain1 and chain2. Chain1 contains tx1 expiring at height+6 and chain2 contains tx2 expiring at height+6. Both forks are mined to height+8, then chain1 overtakes chain2. |
| 21:44:08 | tacotime_: | What satoshi and you are saying is the fact that chain1 cannot incorporate tx2 introduces a huge problem to the network? Isn't it the case that the miners themselves may simply not add these tx, especially once fees become high? |
| 21:44:08 | tacotime_: | And doesn't it still allow for double spends if the person who sent tx2 simply resends tx2 to the network with new outputs and a big fee, so that it's immediately incorporated? |
| 21:44:19 | tacotime_: | But probably in channel is a good place to discuss it too |
| 21:44:53 | gmaxwell: | Freenode fucked up and I was gone. |
| 21:44:58 | gmaxwell: | so I didn't see any of that before. |
| 21:45:03 | tacotime_: | Yeah, no, it's okay |
| 21:45:23 | tacotime_: | I was scared it was a really stupid question and I didn't want people in here thinking I was a moron :p |
| 21:45:28 | gmaxwell: | In any case— no, because it can always be included eventually, even if higher fees are required smart miners who are considering child transactions will just include them all once the aggregate fee is great enough. |
| 21:46:23 | sipa: | oh, altcoins are the perfec |
| 21:46:36 | sipa: | oh, altcoins are the perfect place to introduce crazy things |
| 21:46:38 | gmaxwell: | it's not really stupid... basically it makes those coins that had a hight restriction differently fungible than normal coins— they can irrepariably vanish forever, no matter how many node liked them, no matter how much fees were paid, killing all their children, even if no one was dishonest at all, which is pretty yucky. |
| 21:46:52 | sipa: | but silly things is something else |
| 21:47:26 | tacotime_: | Ah, okay. |
| 21:47:40 | gmaxwell: | tacotime_: so basically, I think you have to think very carefully if they're worth that... and probably treat them differently when you accept them or their ancestors just like we treat coinbases differently. (which have the same kind of exposure) |
| 21:48:09 | luke-jr_: | luke-jr_ is now known as Luke-Jr |
| 21:48:14 | tacotime_: | Right. |
| 21:48:25 | Emcy_: | oh yeah i got a stupid question |
| 21:48:30 | Emcy_: | what does staging mean |
| 21:48:40 | sipa: | beta |
| 21:48:42 | sipa: | testing |
| 21:48:46 | sipa: | canary |
| 21:48:48 | gmaxwell: | maybe it's as simple as the blocks always containing a count with how deep ago the most recent height blocking ancestor was... and then you don't treat coins as confirmed until the most recent hight restriction is good and burried. |
| 21:49:03 | Emcy_: | oh |
| 21:50:08 | andytoshi: | tacotime_: in general if you have a way for txes to "fail closed" so that they would be forever invalid had the blockchain history been a little different..that is bad. you can think of the blockchain as being a quantum superposition of histories if you like where the amplitude of alternate histories decays exponentially with the depth of the bifurcation |
| 21:50:32 | andytoshi: | and when you make txes invalid in certain histories but not others, suddenly -every one of their children- have value zero in one history but not others |
| 21:51:07 | andytoshi: | so you potentially get this really bad situation where you need to use the whole superposition to calculate the value of coins, and that's bad for fungibility |
| 21:51:24 | andytoshi: | and because you can change the superposition by reallocating hashpower, there is also weird incentives |
| 21:52:20 | gmaxwell: | yea, I didn't even get into the fun attacks that can be created by intentionally bumping a right on the edge transaction out of the chain— I hate the incentives reasoning... (in part because I don't know how much the ecosystem of today models the future) |
| 21:53:46 | tacotime_: | Is the alternative implementation I mentioned as dangerous in your minds? To have tx that lock funds as unspendable but can be used as stake when signed for by someone else. Then you need to submit another tx later to unlock them and re-enable spending. |
| 21:54:50 | tacotime_: | (hence, it's like you're lending your stake to another pubkey-privkey pair for the duration of time that they are locked for. however, this person can not spend them themselves, just use them for the purpose of signing PoS blocks.) |
| 21:54:50 | Ademan-school: | gmaxwell: thanks for your response earlier. I didn't see the refund transaction described in that forum post, is the protocol you're referring to here: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains ? |
| 21:56:05 | Ademan-school: | and what's the DOS case you're referring to if there's a refund transaction? |
| 21:56:31 | gmaxwell: | Ademan-school: next post down, https://bitcointalk.org/index.php?topic=91843.msg1011980#msg1011980 |
| 21:57:14 | gmaxwell: | Ademan-school: you have to wait for the refund to become eligible, which is necessarily a moderately long time if you are to avoid a normal spend and the refund racing each other. |
| 21:58:55 | gmaxwell: | Ademan-school: sorry, that whole set of posts was not very clearly explained, I was mostly pointing out that sergio was overcomplicating things. |
| 21:59:14 | tacotime_: | Alternatively, pooling stake becomes very dangerous because you need to give your coins to someone else, hence why this kind of bizarre tx is needed. |
| 21:59:49 | gmaxwell: | tacotime_: well I think all the incentive arguments around that actually involve the miner being the owner of the coins. |
| 22:00:01 | gmaxwell: | you abandon that and I dunno what you have anymore. |
| 22:00:35 | Ademan-school: | gmaxwell: np I have a feeling my lack of sleep is limiting my understanding here, sometime tomorrow I'd like to write down the entire protocol in painstaking detail and see if I've got things straight |
| 22:01:08 | gmaxwell: | Ademan-school: if you want paintstaking detail you can look at the coinswap post, where I include a protocol diagram. |
| 22:01:21 | gmaxwell: | it's the same protocol but wrapped in a couple extra layers that make it totally private. |
| 22:02:20 | gmaxwell: | https://bitcointalk.org/index.php?topic=321228.20 (I'm describing it on one blockchain there, but the same protocol works with the left half and right half on different chains, assuming some care is taken with the locktimes.) |
| 22:02:41 | tacotime_: | gmaxwell: Then I guess it becomes proof-of-sacrifice or proof-of-not-spending. My protocol for stake minting requires you to hold coins (where the number of coins is equal to a network target difficulty) for a very long time without spending them. |
| 22:03:11 | Ademan-school: | heh someone created a service called coin-swap which seems unrelated |
| 22:03:15 | gmaxwell: | ugh |
| 22:03:33 | gmaxwell: | well I blame jcorgan for the overly generic name. |
| 22:04:51 | BlueMatt_: | BlueMatt_ is now known as BlueMatt |
| 22:05:33 | tacotime_: | But then maybe it disincentivizes you to really select who you give "lend" your coins to, because you don't care as long as you get money when they do their proof-of-stake thing. |
| 22:06:42 | tacotime_: | But proof-of-stake pooling by simply giving your coins out seems like a recipe for drama. |
| 22:07:58 | gmaxwell: | yea, agreed .. sorry I'm not saying much, I think I'm basically totally uninterested in this stuff until 2-way-peg is done, and most of my spare brain space is currently being used by ideas in the space of coinwittness, external oracles, and 2-way-peg. |
| 22:08:01 | maaku: | tacotime_: proof of stake minting of any kind is a recepe for drama |
| 22:08:16 | gmaxwell: | I've mostly swapped out POS right now... since it has so many tricky problems. |
| 22:08:42 | gmaxwell: | every time I think about it I think "oh you can just do X oh wait, no thats insecure or incentive incompatible under Y shit." |
| 22:09:01 | tacotime_: | Ah, that's fine, I just always worried I'm going to do something really silly so I ask. |
| 22:09:04 | gmaxwell: | and after four iterations of that I realize I've already gone through all this before. |
| 22:09:10 | gmaxwell: | You will. |
| 22:09:24 | tacotime_: | Heh. |
| 22:10:00 | gmaxwell: | the whole space is full of traps. Nothing I've seen so far produces an intutively correct outcome, it's all patches on patches, and I strongly suspect that it just designs it to the point where the designer isn't smart enough to see what rug the swept the weaknesses under. |
| 22:10:45 | Ademan-school: | haha |
| 22:13:03 | tacotime_: | Well, I'm interested to see where I'll run into problems I guess. |
| 22:14:00 | maaku: | tacotime_: i suggest thinking long and hard why you want proof of stake *minting* in the first place |
| 22:14:18 | maaku: | there be especially vicious dragons |
| 22:14:49 | tacotime_: | maaku: Well, in my chain they just mint subblocks, which only contain a coinbase tx and validate or invalidate the PoW miner tx tree. |
| 22:15:29 | tacotime_: | PoW miners submit the tx trees. So at best the PoS people either orphan or don't orphan the tx tree, but the PoW header and their work stays valid. |
| 22:16:16 | tacotime_: | Chain selection itself is also based on PoW blocks, I couldn't figure out how to do it with PoS subblocks being involved. |
| 22:17:38 | tacotime_: | Minting blocks with transactions other than coinbase to pay themselves seemed like a bad idea. |
| 22:17:52 | zooko: | zooko has left #bitcoin-wizards |
| 22:19:15 | maaku: | tacotime_: yes, sure, but why net set subsidy=0? |
| 22:19:21 | tacotime_: | You open a lot of weird new attack vectors though; refusing to vote on PoW blocks to manipulate difficulty, PoW-PoS collusion to destroy reward of everyone not at your pool... |
| 22:19:27 | tacotime_: | For the subblocks? |
| 22:20:16 | tacotime_: | I thought you needed to incentivize some reason for them to vote honestly, because otherwise they'll simply collude with whatever PoW mining pool starts giving them money. |
| 22:20:21 | Ademan-school: | gmaxwell: I also was wondering if contracts are broken by malleability. If I can munge the first tx in a contract, the second tx is now invalid (and must be resigned?) |
| 22:20:25 | tacotime_: | (and indifferently) |
| 22:20:36 | tacotime_: | I mean, that can still happen of course. |
| 22:20:55 | Ademan-school: | er, whatever the ultimate txid ends up being, must be inserted, and the second tx resigned? |
| 22:21:24 | gmaxwell: | Ademan-school: yes, any protocol that depends on refunds is potentially broken by malleability... this was basically the big motivation for doing anything about malleability at all. There are some tricks you can do to make it a little more costly to attack, but ultimately it'll be resolved once we quash malleability. |
| 22:21:57 | tacotime_: | I think this came up once before too and I considered destroyed PoS rewards for PoS validators not voting with the majority, but then abandoned it for complexity's sake. |
| 22:22:33 | tacotime_: | (gmaxwell is correct in PoS systems being a giant pain in the ass, whenever you fix one thing something else seems to break) |
| 22:28:41 | Ademan-school: | oh heh you even note that down below the protocol diagram |
| 22:30:58 | Ademan-school: | welp, forgot to bring my charging cable to school today, signing off for now, thanks |
| 23:11:58 | shinybro: | shinybro is now known as asianbro |
| 23:35:12 | Luke-Jr: | gmaxwell: since you're not here, you're the topic of discussion |
| 23:38:02 | gmaxwell: | sweet. |
| 23:39:31 | Luke-Jr: | gmaxwell: we're going to you now |
| 23:40:17 | gmaxwell: | hm? |
| 23:40:42 | Luke-Jr: | let us in |
| 23:41:40 | sipa: | yeah we have this discussion we can't agree |
| 23:41:45 | sipa: | +on |
| 23:44:26 | Luke-Jr: | gmaxwell: I meant when we get there! |