00:57:19gmaxwell:So. Y'all know that sighash single bug when the Nth vin uses SINGLE and there are less than N vouts?
00:58:32BlueMatt:never heard of it
00:58:34jtimon:no, but please continue
00:58:43gmaxwell:lemme clear this first, one sec
00:58:47jtimon:or is it for the quiz?
01:06:06gmaxwell:okay. So... right we sign the value 1 in that case due to that bug.
01:06:26gmaxwell:Imagine instead that we signed the value 0 instead?
01:06:55gmaxwell:(e.g. in a hypothetical alternative universe the broken code was return 0 instead of return 1)
01:07:18gmaxwell:Any guesses on what would be different in that universe from ours?
01:07:43BlueMatt:some ugly interaction with ecdsa?
01:07:53BlueMatt:no, should be ok?
01:10:51nsh:(don't shake hands with antimatter bitcoinuniverse you)
01:11:59gmaxwell:BlueMatt: yea, a very ugly interaction with ecdsa.
01:12:07gmaxwell:it's trivial to forge signatures of the value 0
01:12:24BlueMatt:gmaxwell: but we'd be signing 32 0-bytes, not 0, no?
01:12:27BlueMatt:is there no difference?
01:12:39ewust:gmaxwell: it isn't the hash of 0?
01:12:41gmaxwell:it's a number. keep in mind sighash is returning a hash.
01:13:09BlueMatt:oh? our ecdsa doesnt hash it again before signing?
01:13:12BlueMatt:thats ugly
01:13:16BlueMatt:but, understandable
01:13:21gmaxwell:no, thats the function that hashes it that returns 1
01:13:33BlueMatt:ahh, fun
01:13:35BlueMatt:well, ok then
01:13:39gmaxwell:and the signature of 0 with pubkey is {r,s} = pubkey.x,pubkey.x
01:13:59gmaxwell:(well, a signature, I guess there are ~2^256 of them. :P )
01:13:59ewust:why does the function that should be hashing not return hashes conditionally?
01:14:09gmaxwell:ewust: it's a bug.
01:14:09tacotime_:it's kind of weird
01:14:09BlueMatt:hah, nice
01:14:30tacotime_:but that's why
01:14:35gmaxwell:... 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:33gmaxwell:(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:46gmaxwell:* gmaxwell is reminded that he does not like ecdsa.
01:16:26ewust:or really any DSA
01:16:45gmaxwell:I don't believe I've seen anyone point out that property before.
01:17:05gmaxwell:god knows, there is probably _something_ that is vulnerable to this, even though we aren't.
01:17:31tacotime_:how come things like this are never patched when we patch for things that fork older versions?
01:17:52gmaxwell:tacotime_: we've never forked older versions (well not reliably)
01:18:11gmaxwell:pre 0.8 is lossy now, but still works.
01:18:34tacotime_:oh, i didn't realize. i thought that <0.8 simply didn't work anymore because of the leveldb stuff
01:19:07gmaxwell: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:14tacotime_:ah okay
01:20:46jgarzik:there are some nutter nodes out there claiming to be 0.3.x still
01:21:11tacotime_: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:48gmaxwell:Deepbit's last block was 277115 and it's almost certantly still 0.3.22+patches
01:21:58tacotime_:is there a list somewhere of stuff that doesn't make bitcoin stop working but ought to be patched anyway?
01:23:33gmaxwell:the crazy sighash single behavior could be soft-fork fixed.
01:24:04jgarzik:gmaxwell, is there a soft fork wishlist somewhere?
01:24:10gmaxwell:might be logical to do it as part of malleability changes.
01:24:13nsh: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:30nsh:(...had the return value been 0, and not 1)
01:25:47gmaxwell: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:41nsh:hmm, but for the grace of return-value conventions go we
01:27:11nsh:(cf. gnuTLS last week too....)
01:27:18gmaxwell:nsh: also magical type handling. In _theory_ typechecking should have been like "wtf, 1 is not a hash".
01:27:42jrmithdobbs:gmaxwell: more arguments in favor of a better script!
01:27:43gmaxwell:but our hashes there are uint256 and the code knows how to cast integers to uint256...
01:28:03nsh:unfortunately, knowing how to does not translate into knowing whether to
01:28:22nsh:i guess this is a mostly-unavoidable problem of magic types
01:28:50jrmithdobbs:i wonder what a lua-based bitcoin script would look like
01:28:57nsh:(though you could have project wide type casting (prohibition) assertions, i suppose)
01:28:58jrmithdobbs:that could be a fun project
01:29:03gmaxwell: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:21gmaxwell:jrmithdobbs: that wouldn't really have the properties we want.
01:29:22jrmithdobbs:i'm having a hard time thinking of anywhere it'd be valid
01:29:34jrmithdobbs:gmaxwell: why not?
01:30:35BlueMatt:gmaxwell: are you coming to lunch@coinbase tomorrow?
01:30:35gmaxwell: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:22jrmithdobbs: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:32gmaxwell: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:32jgarzik: I don't even know if we actually need the ability to cast integers to uint256 anywhere <<--- let's find out...
01:32:46jgarzik:I know we use it for target comparison, and going from compact-to-full-size
01:32:52jgarzik:as an int
01:33:02jgarzik:not sure if we actually need _casting_ services
01:33:20gmaxwell: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:39jgarzik:gmaxwell, I'm slowly removing helpers from uint256.h
01:33:46jrmithdobbs:oh it's probably used in the miner code
01:34:09jrmithdobbs:or is that finally stripped?
01:34:56jgarzik:Another approach is simply to start anew with an opaque bitHash type, with just a few key accessors
01:35:48jgarzik:nope, miner just uses the familiar
01:35:50jgarzik:hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
01:35:57jgarzik:uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
01:36:39jgarzik:peeling off uint160 into a separate type might be a nice first step
01:36:52jgarzik:useful trial run for an opaque type, with fewer services demanded of it in our code
01:37:06jrmithdobbs:sounds sane to me
01:38:03gmaxwell: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:34jrmithdobbs:gmaxwell: distract yourself by convincing me lua isn't suitable ;p
01:38:40jrmithdobbs:i'm having a hard time doing it myself
01:40:53gmaxwell: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:16gmaxwell:plus minutia like lua bytecode isn't secure, so you can't even use a standard lua bytecode interperter.
01:41:29gmaxwell:(evil bytecode can escape the lua sandbox)
01:41:56jrmithdobbs:gmaxwell: memory isn't statically deciadable but it's inherently limitable by the runtime
01:42:03gmaxwell:Besides which, I think thats all just confused about what script actually is. Script is program _verification_ not program _execution_.
01:43:26jrmithdobbs:and yes, i knew you couldn't use the bytecode directly :(
01:43:38jgarzik:we actually use uint256::getdouble() in several places??? sigh.
01:43:39jrmithdobbs:that situation is ... unfortunate to put it nicely
01:44:35gmaxwell: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:09jrmithdobbs: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:22gmaxwell:well, not lua bytecode.
01:49:21gmaxwell: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:45jrmithdobbs:you can prepay the
01:50:10gmaxwell:the actual operator of the oracle for usage.
01:50:14gmaxwell:* gmaxwell looks for that irssi script
01:50:18jgarzik:* jgarzik declares death to the "^" operator
01:50:36jgarzik:* 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:49nsh:that book's certainly worth a reread these days
01:52:06gmaxwell: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:36gmaxwell: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:49nsh: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:20gmaxwell:nsh: hm? economically its great— you move the cost entirely onto the person creating the transaction.
01:53:47gmaxwell: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:56nsh:well, it's a long way in my head, anyway :)
01:55:18jgarzik:ok, wtf uses '&' on uint256. grump.
01:57:09jgarzik:bool fTrickleWait = ((hashRand & 3) != 0);
01:57:44gmaxwell:oh come on. lol
01:58:27jgarzik:uint256 hashRand = inv.hash ^ hashSalt;
01:58:30jgarzik:same code section
01:59:09jgarzik:// 1/4 of tx invs blast to all immediately
01:59:09jgarzik:static uint256 hashSalt;
01:59:09jgarzik:if (hashSalt == 0)
01:59:09jgarzik:hashSalt = GetRandHash();
01:59:09jgarzik:uint256 hashRand = inv.hash ^ hashSalt;
01:59:10jgarzik:hashRand = Hash(BEGIN(hashRand), END(hashRand));
01:59:11jgarzik:bool fTrickleWait = ((hashRand & 3) != 0);
01:59:18jgarzik:* jgarzik whips out git blame
01:59:56jgarzik:lol, satoshi
02:03:28gmaxwell:it's so weird to ^ some 256 bit numbers then decide just on the lsb.
02:09:39tacotime_:gotta xor something
02:14:00gmaxwell:good thing the relay behavior is already full of security holes, or this would count as one too.
02:14:43gmaxwell:since anyone observing you for a bit will quickly determine your hashSalt.
02:16:04gmaxwell:oh nevermind it actually hashes it, I was missing that line.
02:16:08ewust:isn't that what the hash is meant to protect against? (probably wanted an HMAC)
02:16:42gmaxwell:yea, somehow I just read over the line. I'm still very dubious about that xor.
02:17:01gmaxwell:but its probably not a pratical concern.
02:17:11ewust:there was a mumble about deterministic randomness in a similar block before that
02:24:24jgarzik:gmaxwell, it's just silly
02:24:37jgarzik:gmaxwell, might as well as generate one hash from two buffers
02:27:17jrmithdobbs: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:35tacotime_:xor is generally kind of a bad way to combine hashes because of communtativity
02:29:37gmaxwell:jrmithdobbs: uhh. insane confusion there.
02:30:02jrmithdobbs:gmaxwell: err?
02:30:04tacotime_:*commutativity, bleh
02:30:06gmaxwell: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:21copumpkin:ooh, proof checking
02:30:24copumpkin:I'm a fan
02:30:24gmaxwell:jrmithdobbs: that eliminates all concerns related to the network's behavior.
02:30:47jrmithdobbs:gmaxwell: ah, yes, that does sound like a confusion re: snarks on my part
02:32:16gmaxwell: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:45gmaxwell: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:09gmaxwell: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:25copumpkin:*cough* type systems *cough*
02:33:52gmaxwell: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:47jgarzik:pmt_tests.cpp: In member function ‘void CPartialMerkleTreeTester::Damage()’:
02:34:47jgarzik:pmt_tests.cpp:21:14: error: no match for ‘operator^=’ (operand types are ‘uint256’ and ‘const uint256’)
02:34:47jgarzik:hash ^= ((uint256)1 << bit);
02:34:54gmaxwell: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:08jgarzik:fscking test. Fixed the above case, and no others showed up in the main code.
02:35:47jgarzik:// flip one bit in one of the hashes - this should break the authentication
02:35:52gmaxwell:would that be just as good with a hash++ or did you get rid of that operator too.
02:36:15jgarzik:gmaxwell, not yet, but ideally ++ will die
02:36:27jgarzik:gmaxwell, can just manually twiddle the buffer
02:38:32Luke-Jr:what's the goal of changing this stuff? O.o
02:39:02gmaxwell:Luke-Jr: makes some mistakes less likely to be disguised by implicit type conversion.
02:39:10gmaxwell:like the SIGHAS_SINGLE bug.
02:39:46ewust:so this will tell you that SignatureHash shouldn't be returning 1, but what should it do there, throw an exception?
02:40:40gmaxwell:it won't compile.
02:40:52gmaxwell:I mean for compatiblity we'll make that work by explicitly converting it.
02:41:17gmaxwell: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:08jgarzik:shockingly, uint256_tests.cpp is grumpy ;p
03:37:13jgarzik:* jgarzik kicks boost
03:37:59jgarzik:* jgarzik would love to adopt the majority of google's C++ coding conventions. rule #1: no templates ;p
03:38:43jrmithdobbs:ok but only if rule #2 is no golang
03:39:40Luke-Jr:jgarzik: pfft, templates are like the main reason to use C++ :P
03:40:24jrmithdobbs:Luke-Jr: they're really not =/
03:45:35copumpkin:jrmithdobbs: I thought you liked Haskell :P
03:46:43jrmithdobbs:copumpkin: hmm? I do
03:47:10jrmithdobbs:copumpkin: but c++ has much more redeeming features than it's template clusterfuck ;p
03:47:20jgarzik:main.cpp:1331:114: error: no match for ‘operator+’ (operand types are ‘uint256’
03:47:21jgarzik:and ‘uint256’)
03:47:21jgarzik:if (pindexBestForkTip || (pindexBestInvalid && pindexBestInvalid->nChainWor
03:47:21jgarzik:k > chainActive.Tip()->nChainWork + (chainActive.Tip()->GetBlockWork() * 6).getu
03:47:35jgarzik:hum, surprised that's not a bignum addition
03:47:43jrmithdobbs:shouldn't it be?
03:47:51copumpkin: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:17jrmithdobbs:copumpkin: haha, completely understandable misunderstanding, it is c++
03:48:22jgarzik:gmaxwell, sipa: ^
03:50:32hasan1:hasan1 is now known as shinybro_
03:52:33gmaxwell: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:11gmaxwell:and bignums are not as nice as uint256 (e.g. slower, more allocation churn, etc)
03:57:12maaku:ok, let me demonstrate my ECDSA ignorance. the equations for signing are r = k * Gx, s = k^-1 * (z + r*d).
03:57:21maaku:and the public key x component is Qx = d * Gx.
03:57:24maaku:does that not mean you can rewrite s = k^-1 * (z + k * Qx)?
03:57:31maaku:and forge any signature, given the pubkey?
03:57:42maaku:i know I haven't discovered such a trivial flaw, but where did I go wrong?
03:57:46just[dead]:just[dead] is now known as justanotheruser
03:58:52gmaxwell:you totally can, if you know k. but you don't know k.
03:59:34gmaxwell:(well perhaps I should decode your notation first)
03:59:45gmaxwell:z is the data you intend to sign?
04:01:43maaku:and no, i'm forging a signature for a given message, so I'm free to pick k, no?
04:01:51maaku:i got these equations from Wikipedia's ECDSA page
04:03:14maaku:(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:58jgarzik: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:29gmaxwell:internal uint256 > library bignums everwhere... but. meh.
04:06:32gmaxwell:you can't do that rewrite. r*d != k*d*Gx because r is not a point, it's a scalar.
04:06:44gmaxwell:(this is one place where the notation adds opacity)
04:07:03gmaxwell:since it's not clear when its operations in the curve group or in the integer field.
04:13:59gmaxwell: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:07gmaxwell:none the less...
04:16:42maaku:gmaxwell: i thought they were all scalars
04:16:49maaku:i guess I'll have to read up on EC algebra
04:17:14Luke-Jr:gmaxwell: signature of 0 are forgable? 0 as the data?
04:18:28copumpkin:* copumpkin ensures that all his messages hash to 0 to ensure plausible deniability
04:20:03phantomcircuit:gmaxwell, have you tried removing the uint256 casting functions?
04:20:22phantomcircuit:i assume it would break a few things which could then be made explicitly weird
04:20:27phantomcircuit:instead of implicitly weird
04:20:53ewust:Luke-Jr: signatures of data that hashes to 00000000... are forgeable
04:21:15Luke-Jr:* Luke-Jr wonders what data hashes to 0000000…
04:21:29ewust:the terminal block
04:25:28jgarzik:edit SHA256() to exit(3) if all-zeroes results is generated
04:31:48jgarzik:Excellent... uint160 is quite clean. None of the bitwise, arith, lt/gt cmp operators are used.
04:32:47jgarzik:unfortunately they will always be dword-based, and never purely opaque
04:36:11ewust:jgarzik: you mean, hexdump the input data, then exit(3)?
04:36:25tacotime_:tacotime_ is now known as tt_zzz
04:37:43phantomcircuit:ewust, he means blow up amazingly if the state is dangerous
04:38:51ewust:but what if someone won the sha256 lottery, and you exited before printing the winning ticket!
04:39:48phantomcircuit:ewust, i think the 1 in 2^256 odds of that happening are good enough to ignore
04:40:29tt_zzz:I'm pretty sure that something should pop up specifying that you've now won bitcoin
04:40:32tt_zzz:ok i am sleeping
04:46:08gmaxwell:Luke-Jr: I do feel a little bit of an itch to make signatures of 0 fail.
04:46:37gmaxwell:just in case some snazzy attack on sha256 lets you get an all zero hash out of anything..
04:46:51gmaxwell:but I reconize that it's a silly concern.
04:50:15ewust: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:58gmaxwell:ewust: they can't generate transactions that have a hash of 0
04:53:51ewust:oh nvm, i was thinking you were proposing that check on generation, not verification
05:03:59gmaxwell:Grrr. using an analog modem on the phone line here disrupts my DSL modem.
05:46:10BCB:BCB has left #bitcoin-wizards
05:52:19Luke-Jr:gmaxwell: :
05:52:56gmaxwell:yea, the real challenge will be calling the provider for support. Hopefully a regular analog phone call also disrupts it.
05:53:11gmaxwell:Because I think if I tell them a modem disrupts it their minds will melt.
05:53:21maaku:gmaxwell: ok i understand now, thanks
05:56:23justanotheruser:justanotheruser is now known as just[dead]
05:56:43Luke-Jr:gmaxwell: they might need the same frequencies?
05:57:06gmaxwell:Luke-Jr: nope not at all, they should be completely compatible.
05:57:30gmaxwell:ADSL doesn't use anything under 40kHz or something like that, where all the modem stuff is <8kHz.
05:57:37Luke-Jr:gmaxwell: maybe they will understand trying to send a fax, if you can't reproduce with voice.
05:57:46gmaxwell:yea, good call.
05:58:27jrmithdobbs:they only gaurantee fax-level service too (helpful to know to route through support)
05:58:47jrmithdobbs:as far as data over plain residential pots lines
06:00:48jrmithdobbs:try again
06:02:51midnightmagic: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:31jrmithdobbs:Luke-Jr: wrong window
06:03:46gmaxwell:midnightmagic: I have the filter, actually I tried stacking two of them.
06:04:19midnightmagic:might be defective pieces of crap because the lineman decided to be a dickhead
06:05:41gmaxwell: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:56gmaxwell:I think it's probably just operating at the margins and the concurrent modem use is enough to push it over.
06:06:09gmaxwell:Luke-Jr: why does eligius gbt no longer return transactions?
06:06:23gmaxwell:I was unable to tell the dude in #bitcoin if his transaction was about to be mined...
06:10:15Luke-Jr:gmaxwell: to reduce startup bandwidth, not new
06:10:36Luke-Jr:bitcoind -rpcconnect=gbt.mining.eligius.st -rpcuser=x -rpcport=9337 -rpcpassword=x getblocktemplate '{"longpollid":"bootstrap"}'
06:11:18Luke-Jr:gmaxwell: the idea is to send an empty block template first, then immediately longpoll with a full block template
06:12:04gmaxwell:not unreasonable... I just wasn't aware you started that and hadn't updated my scripts.
06:12:07Luke-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:39Luke-Jr:gmaxwell: 2012 Nov 5 change date ;)
06:16:55midnightmagic:* midnightmagic is inclined to still blame the lineman
06:33:24gmaxwell: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:37gmaxwell: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:22Luke-Jr:gmaxwell: sounds reasonable to me, though to be extra conservative perhaps not allow the change address concession
06:46:36Luke-Jr:eg, so they have to add an input
06:47:14gmaxwell:so, in the case I was just working on— he had no other inputs :(
06:47:17Luke-Jr:would be nice if we could have some kind of modular embedded Python for policy
06:47:27gmaxwell:I expect thats not too uncommon.
06:47:47Luke-Jr:gmaxwell: well, he could use CPFP too
06:49:16Luke-Jr:usually between adding another input and CPFP, I'd expect at least one to be viable
06:51:41gmaxwell:okay thats a point.
06:51:57just[dead]:just[dead] is now known as justanotheruser
08:05:04LarsLarsen:LarsLarsen is now known as needmoarmindmelt
08:05:34needmoarmindmelt:needmoarmindmelt is now known as LarsLarsen
09:22:23wumpus: 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:59gavinandresen_:gavinandresen_ is now known as gavinandresen
09:41:54dansmith_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:55dansmith_btc:s blockchain?
09:45:54Ademan:dansmith_btc: A miner could maintain multiple nodes and circumvent this
09:48:37dansmith_btc:Ademan, circumvent A) or B) ? and how?
09:49:39Ademan:dansmith_btc: A, how would you know that the two nodes are the same miner?
09:50:47Ademan: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:04dansmith_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:44dansmith_btc:Ademan, if the nodes see 2 blocks by the same miner, they mark such miner as malicious
09:52:13Ademan:do they then mark *all* of that miner's blocks as bad?
09:52:26dansmith_btc:yes, both
09:52:41Ademan:What if somebody has already built on one or both chains? do you rewind?
09:52:52dansmith_btc:or however many the attacking miner has sent within his alloted timeframe of block-sending
09:53:24stonecoldpat:is it possible for an attacker to change a block, but allow it to remain valid? ( a bit like transaction malleability)
09:53:26dansmith_btc:That's why I suggested B) - each miner has a designated timeframe
09:54:44Ademan:well with that you gain the rather difficult problem of accurate timekeeping in a distributed system
09:54:58dansmith_btc:Ademan, you are saying "building on top" - this is the current PoW terminology, not PoS
09:56:33dansmith_btc:each miner will be expected to be properly time-synced. Is that rather difficult?
09:56:55Ademan:how can you prevent them from lying?
09:57:21Ademan:well sorry, I know my block just reached you but I swear it's from XX:YY:ZZ
09:59:03Ademan:and you can't prove that it didn't just take a long path around the network before it got to you
09:59:15dansmith_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:10dansmith_btc:But I see your point, there's always this "long path arounf the network" excuse
10:00:40stonecoldpat1:stonecoldpat1 is now known as stonecoldpat
10:00:54dansmith_btc:If one minute is not enough, we can make it 2 minutes. Surely that will suffice.
10:02:05Ademan:malicious nodes could also create their own latency (refuse to transmit a block indefinitely)
10:02:29Ademan:that might be tough to pull off but certainly not impossible
10:07:49Ademan: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:18justanotheruser:justanotheruser is now known as just[dead]
11:37:26fanquake:fanquake has left #bitcoin-wizards
13:16:22tt_zzz:tt_zzz is now known as tacotime_
13:41:37andytoshi: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:41andytoshi: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:54andytoshi:gmaxwell: if you just noticed this, where did petertodd hear it? o.O
13:43:55gmaxwell:crazy. not from me.
13:44:02andytoshi: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:27andytoshi: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:34gmaxwell:I mean, obviously I knew about the SIGHASH_SINGLE stuff, but hadn't thought through the ECDSA/
13:44:57gmaxwell:well so.. it has been the case that I've known things before, and forgotten them completely...
13:45:30gmaxwell: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:49andytoshi: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:21andytoshi:it could also just be a glitch in the matrix, 1 month is not so far for information to jump :)
13:48:41gmaxwell:andytoshi: the SIGHASH_SINGLE bug has been known for a long time.
13:48:47gmaxwell:BlueMatt found it a couple years ago.
13:48:56andytoshi:yeah, i know that
13:49:31andytoshi:but petertodd's money-stealing comment was news to me
13:49:40jgarzik:andytoshi, gmaxwell: Yah. petertodd fixed bugs related to this in python-bitcoinlib, months ago.
13:49:57jgarzik:I was returning 0, rather than 1.
13:50:05gmaxwell:oh wow. lol
13:50:12jgarzik:(and then checking the error code, rather than assuming it was a valid hash)
13:50:37gmaxwell:oh well thats less bad.
13:50:38jgarzik:i.e. the code would just die upon 0 return
13:51:04jgarzik:petertodd changed it to -not- die, and instead return 1, a la bitcoind
13:51:06gmaxwell:perfectly reasonable way for it to work, in fact. except for that pesky consistency thing.
14:27:14zooko:gmaxwell: I've been thinking about your prove-full-reserve protocol.
14:28:06zooko:gmaxwell: I don't understand what privacy/non-disclosure concern is solved by proving the membership (and sum) under ZK.
14:28:42zooko: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:51zooko:I.e., the company could hold 0 and still perform the ZK protocol I'm imagining.
14:29:01zooko:So, I must have misunderstood it.
14:30:35gmaxwell:zooko: Then you're not imagining the right ZK protocol.
14:32:06gmaxwell: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:54gmaxwell:(or you put signature verification under the ZK instead of blinding, though thats much more expensive)
14:33:46zooko: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:58zooko:Ugh, I just realized I said "The Bitcoin CEO" when I meant "The Coinbase CEO".
14:34:01zooko:* zooko drinks more coffee.
14:36:58gmaxwell: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:27gmaxwell: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:12zooko: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:34zooko: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:01gmaxwell:thats what the whole liabilties side of the proposed protocol is for.
14:41:02zooko:If I were a deceitful scammer.
14:41:15zooko:Okay, right, that's what I thought.
14:41:21zooko:* zooko reads back…
14:41:43tacotime_:is this protocol formalized anywhere?
14:41:46zooko:Wait, you mean the whole assets side of the protocol?
14:42:02zooko:Hi tacotime_
14:42:10zooko:We're talking about a ZK extension of https://iwilcox.me.uk/2014/proving-bitcoin-reserves
14:42:15tacotime_:okay thanks
14:42:38gmaxwell: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:12zooko:Okay, so the Merkle+ZK thing we talked about above was what you're calling the assets side, right?
14:44:43gmaxwell: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:00zooko: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:14zooko:and then I can check that their proven holdings X ≥ that sum.
14:45:24zooko:That's the non-ZK version that is on https://iwilcox.me.uk/2014/proving-bitcoin-reserves#merkle_top IIUC.
14:46:28zooko: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:43zooko:I currently think that the ZK extension you've mentioned isn't intended for that.
14:46:50gmaxwell:it is.
14:47:17gmaxwell:You augment the protocol by replacing the two halves with ZK versions.
14:47:42zooko:Ah! I was thinking only of the prove-to-customers-something-about-the-sum-of-their-account-balances side.
14:47:53zooko:(That's the *liabilities* side, right?)
14:48:09gmaxwell:so I was talking in here about the assets side, since thats a bit harder to make ZK.
14:48:41zooko: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:59zooko:"talking in here" -- you mean the discussion in the last ten minutes, above?
14:49:13zooko: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:24gmaxwell:no no I thought you saw a discussion earlier since you mentioned "the membership (and sum) under ZK"
14:49:36zooko:Doh, sorry, I haven't read backlog.
14:49:41gmaxwell:it's okay.
14:49:50zooko:I have seen you mention it on IRC in the past
14:49:55zooko:and we talked about it in person a couple of weeks ago.
14:50:20gmaxwell: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:46gmaxwell: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:12zooko:Okay this is a root of a...
14:51:21zooko:What's the *word* for this Merkle Tree over secure-hashes-and-sums?
14:51:36zooko:Anyway, is it that sort of tree, so we have secure hash and sum of all the keys in its leaves?
14:51:36gmaxwell:doesn't need to have sums for this tree.
14:51:42zooko:Okay, just a hash tree then.
14:53:30gmaxwell: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:14gmaxwell: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:32gmaxwell:you also provide a signature with the blinded pubkey, which proves you can sign for the transaction.
14:56:02gmaxwell: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:44gmaxwell: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:32gmaxwell: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:55zooko:Is it written down in a document?
14:59:27gmaxwell: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:42gmaxwell:of course if the customers cooperate it loses the privacy.
14:59:46gmaxwell:(for the service)
14:59:51tacotime_: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:54zooko: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:05zooko:So, if you know of a document of petertodd's fidelity-bond ideas
15:00:10zooko:or anyone's, I'd appreciate a link.
15:01:29zooko: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:33gmaxwell: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:38zooko:gmaxwell: thanks!
15:09:24zooko: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:00comboy: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:49gmaxwell:thats what I use.. I also use pam_mount to mount my seperately encrypted home.
15:30:00comboy:gmaxwell: thx
15:39:45Ademan: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:42jgarzik:Is extortion risk ever really eliminated in the human world?
15:43:49Ademan:Also I assume that by "both transactions are in" they mean confirmed
15:44:05Ademan:eh true I suppose
15:45:01Ademan:I guess I wasn't thinking about the "human" element here, just the protocol ;-)
15:45:23Ademan:But that is a good point in a lot of cases
15:53:57super3_:super3_ is now known as super3
16:06:41Ademan: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:18Ademan:or is it that when the other party spends their coin they reveal to me the other secret?
16:08:00Ademan:So theoretically they could hose me by never telling me their secret, and never spending that coin?
16:37:38gmaxwell:Ademan: it doesn't eliminate the extortion risk because the DOS attack is still extortion.
16:38:07gmaxwell: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:47gmaxwell: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:10gmaxwell:you can improve this by staging the locktimes in the order you do secret reveals, but the DOS attack still exists.
16:39:35gmaxwell:09:08 < Ademan> So theoretically they could hose me by never telling me their secret, and never spending that coin?
16:39:43gmaxwell:no because of the refunds you setpu.
16:39:44gmaxwell:er setup.
17:16:05maaku:jgarzik: maybe if you eliminate the humans?
17:19:18maaku:that solves a lot of problems
17:59:26just[dead]:just[dead] is now known as justanotheruser
18:15:41zooko:* zooko is back
18:17:47amiller:hi zooko :)
18:18:29sipa:* sipa is front
18:19:11gmaxwell:* gmaxwell is clockwise
18:25:20[-krypto-]:is this the right channel for asking questions about new innovations?
18:25:46[-krypto-]:sipa great
18:26:05amiller:[-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:10sipa:datacoin has data storage as explicit purpose
18:29:34[-krypto-]:sipa oh I did not know that
18:29:39tacotime_:and maidsafe, etc
18:29:55[-krypto-]:thanks guys
18:30:48Emcy_:is miadsafe really a thing
18:31:00tacotime_:Emcy_, yeah
18:31:07tacotime_:they're launching a blockchain thing in april
18:31:11Emcy_: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:41tacotime_:Emcy_, its more or less an encrypted ccn that gives coins for storing stuff on the overall network
18:32:11justanotheruser:justanotheruser is now known as just[dead]
18:32:29Emcy_:the most incredile innovations in histroy were announced with I made this thing here is the source
18:34:05gmaxwell: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:53amiller:step 1. hire developers, step 2. background reading :p
18:35:12tacotime_: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:03gmaxwell: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:58tacotime_:[-krypto-], there's someone doing that too
18:40:04tacotime_:storing the metadata in the chain
18:40:09[-krypto-]:oh wow
18:40:46gmaxwell:[-krypto-]: I think in general blockchains are a very poor model for data storage, but I'm happy to see people expirementing.
18:40:57tacotime_: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:12Emcy_:theyre poor for storage
18:41:19phantomcircuit:gmaxwell, i dont understand why people are fixated on using a blockchain for everything
18:41:21Emcy_:better for anti-censorship though
18:41:24tacotime_: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:34phantomcircuit:it's really a very inefficient way of doing just about anything other than distributed consensus
18:41:41phantomcircuit:which you dont need for file storage
18:41:56gmaxwell: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:07phantomcircuit:lol xml
18:42:18phantomcircuit:im dealing with ridiculous xml api right now
18:42:19gmaxwell: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:39phantomcircuit:it's case sensitive on the element names and there is no consistency
18:42:43Emcy_:DHTs havent gone out of fashion yet
18:42:54gmaxwell:Emcy_: people have mostly stopped bothering me about them.
18:42:57tacotime_:just ask darkwallet
18:43:21phantomcircuit:what are they using a dht for?
18:43:48tacotime_:there was something in their wiki about it, lemme dig it up
18:43:54gmaxwell:yet another altcoin launched with a long feature list and none of the code written up for any of it.
18:44:12gmaxwell:or am I confusing that with darksomethingelse?
18:44:24gmaxwell:oh no darkwallet is the unsystem people.
18:44:28tacotime_:"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:46gmaxwell:ow. that handwave hit me in the face.
18:44:47tacotime_:better than freenet and fast
18:45:10gmaxwell:with deluxe super shammy powers, buy now and get the second ABSOLUTELY FREE.
18:46:18gmaxwell: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:54nsh_:or an empirical proving ground
18:46:59nsh_:(or both)
18:46:59Luke-Jr:much DHT
18:47:24Emcy_:anyone remeber something called blocksnet?
18:47:24BlueMatt:but she (and I) was wondering
18:47:29Emcy_:the blurb for that was euphoric
18:47:32BlueMatt:wrong copy/paste
18:48:21Emcy_:or the OFF system
18:48:24Emcy_:same thing
18:49:54Emcy_:i just want someone to make a system with little fanfare that goes big because it works ans is fantastic
18:50:00Emcy_:it only takes one, out of how many tries?
18:50:41Emcy_:perfect dark uses all that DHT gubbins and does it, but its closed source an JP only
18:51:06tacotime_: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:18tacotime_:or not susceptible to a load of new attacks.
18:51:21gmaxwell:there are like a zillion japanese crazy p2p apps that no one in the english speaking world knows anything about.
18:51:45zooko:tacotime_: I'm interested in your ideas.
18:51:49gmaxwell:Gotta have some way to share your tentical porn manga without freaking out the westerners.
18:52:03zooko:tacotime_: because I was thinking of similar things and then found your pages.
18:52:07Emcy_:thats exactly what they do with it
18:52:33[-krypto-]:tacotime_: have you named it yet?
18:52:40tacotime_:zooko, cool, i'm glad someone thinks they are interesting heh. :)
18:52:55tacotime_:the official name is coming out in a bit, when we launch forums/website.
18:53:04Emcy_:actually i think the window for a working worldwide distributed datastore has passed,, sadly
18:53:26Emcy_:"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:55Emcy_:and the era of unmetered internet is drawing to a close, and so is net neutrality
18:54:30nsh_:"JP only"?
18:54:40nsh_:oh, japanese
18:54:44gmaxwell:Emcy_: the general public is moving to hermetically sealed consumption-mostly devices (like ipads) in droves in any case.
18:56:25Emcy_:feels bad man
18:56:49phantomcircuit:Emcy_, bizarrely there are simultaneous movement away from unmetered and towards it in different areas
18:56:57Emcy_:and its not like they even give those little consumtion pads away for free, which they really should
18:56:59phantomcircuit:comcast/timewarner/att are all moving away from it
18:57:09phantomcircuit:while comptition is appearing that offers it on 1gbps lines
18:57:24Emcy_:just google fibre?
18:57:49phantomcircuit:Emcy_, google fiber, various municipalities, sonic.net in sf (although that is lol slow becuase it's sf)
18:58:04phantomcircuit:(they might be endangering a cricket with their fiber optic lines!!)
18:58:37Emcy_:when google is our last hope for techno freedom you know were in a tight spot
18:59:23phantomcircuit:Emcy_, interestingly the primary thing google is able to do is push municiple governments into stream lining the application process
18:59:37Emcy_: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:54phantomcircuit: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:58sipa:gmaxwell: https://twitter.com/TheBlueMatt/status/443458112117149696
19:00:20phantomcircuit:Emcy_, lol bt is ridiculous
19:00:45tacotime_:pretty soon we'll be verifying everything in 288 bytes
19:01:12Emcy_: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:44Emcy_: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:29phantomcircuit:Emcy_, there's probably some contractual limit (i would guess 5%) that defines what a fault is
19:04:51nsh_:technically the infrastructure is maintained by a (sort of) spin-off company now
19:05:53Emcy_: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:11:31phantomcircuit:-> Seq Scan on cgminer_results (cost=0.00..3331621.68 rows=33913468 width=8)
19:36:40jgarzik:must resist temptation to write a protobufs-like compiler and tiny lib... for the satoshi serialization stuff
19:37:04jgarzik:a formal definition and some auto-generation would be nice, but, we've already dived down the protobufs rabbit hole
19:45:56nsh__:nsh__ is now known as nsh
20:06:28maaku:maaku is now known as Guest92427
20:44:22gmaxwell:* gmaxwell worried about the lower tx fee changes
20:44:42sbp:why are you worried?
20:44:55sbp:you sounded quite confident in the 0.9.0 blog post
20:45:30gmaxwell:I didn't blog about it.
20:45:52sbp:oh right, excuse me
20:46:11gmaxwell: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:15zooko:Hi there snp. ☺
20:46:19sbp:hey zooko
20:48:48sbp:instead of a single heuristic estimate, why not allow a range with user control?
20:49:41sbp: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:15gmaxwell:sbp: You're talking a lot about something you do not understand.
20:51:27gmaxwell: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:01phantomcircuit:gmaxwell, combined with mempool tx's expiring i think it will be an impovement
20:52:03phantomcircuit:but maybe not
20:52:18sbp:I dunno if two lines is a lot, but point taken :-)
20:52:36gmaxwell: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:05gmaxwell:(and are made worse by the network being willing to relay things that won't get mined soon)
20:53:15gmaxwell:no biggy, I'm just n00b exhausted.
20:53:46sbp:I was just worried you weren't going to expand on your point, to be honest, and I was interested
20:53:55tacotime_: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:57gmaxwell:thats never a risk with me
20:53:59tacotime_:Good idea/bad idea?
20:54:01sbp:heh, heh
20:54:32tacotime_:Because after a certain height it's unpublishable
20:54:48gmaxwell:great. you know you're going to get people robbed right?
20:54:56tacotime_:Apparently terrible idea heh
20:54:57gmaxwell:I refer you to amiller's paper.
20:55:07gmaxwell:er andytoshi's paper
20:55:17amiller:you can look at my paper too though if you have time :p
20:55:26tacotime_:What's your paper?
20:55:42gmaxwell: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:48gmaxwell: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:11gmaxwell: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:07tacotime_:Ah, that complicates things, yeah. Thanks for taking the time to explain.
20:59:35tacotime_: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:02tacotime_: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:16tacotime_:So my idea was this:
21:01:49tacotime_: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:16tacotime_:After the network gets the tx, these coins become unspendable.
21:03:03tacotime_:(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:11tacotime_: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:35tacotime_:But apparently this is a very bad thing.
21:05:19tacotime_:Could you just require a second tx to the network to unlock them and undo the first tx?
21:10:26tacotime_:(and I see satoshi commented on this, derp: https://bitcointalk.org/index.php?topic=1786.0 )
21:14:50phantomcircuit:tacotime_, that's a dos vector
21:15:08phantomcircuit:if you replaced a tx everytime a conflicting one was received someone could just continuously send out new ones
21:16:41tacotime_:the "lend" tx in the first place?
21:19:45tacotime_: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:23:01nsh_: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:01nsh_: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:04nsh_:-- http://www.angelfire.com/ca3/tomsnyder/hg-3-11.html
21:28:08gmaxwell: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:12gmaxwell: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:12phantomcircuit:gmaxwell, it wont remove the original from the mempool iirc
21:32:23phantomcircuit:so you cant do pushtx to double spend
21:32:35phantomcircuit:(i was trying to figure out how to do that earlier)
21:33:09phantomcircuit:oh ffs
21:33:59nsh_:is freenode under semi-constant ddos these days or what? can't remember it being so bad ever before
21:35:45phantomcircuit:nsh_, pretty much yeah
21:36:21Emcy_:its GCHQ
21:36:47tacotime_: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:18Emcy_:like what
21:37:36tacotime_:The "nExpiry" question I just asked, and stuff about my PoS protocol.
21:38:53Emcy_:youre probably ok as long as its technical and related to cryptocurrency
21:39:17Emcy_:and not related to some extant scam altcoin
21:39:17Guest92427:Guest92427 is now known as maaku
21:39:45tacotime_:No, mine has no premine etc and isn't out yet
21:39:59tacotime_:It's in the trying to finalize specifications phase
21:40:14Emcy_:why make your own coin?
21:40:44tacotime_:Because Bitcoin will never add something insane like PoS per-block validation, heh
21:40:57tacotime_:And I wanted to play with that and see if I could get it working
21:42:23Muis:Muis is now known as Guest23940
21:42:52tacotime_: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:52andytoshi: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:01andytoshi:and it's pretty hard to control it
21:43:12Emcy_:no one begrudges people from experimenting
21:43:46Emcy_:its when they launched the coin 24 hours ago and are already like COME GET YOUR HOT PISSCOINS ONLY $10 PER
21:43:48tacotime_:andytoshi: I posed this to gmax because I'm still a little confused about why it's super super bad
21:44:08tacotime_: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:08tacotime_: 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:08tacotime_: 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:19tacotime_:But probably in channel is a good place to discuss it too
21:44:53gmaxwell:Freenode fucked up and I was gone.
21:44:58gmaxwell:so I didn't see any of that before.
21:45:03tacotime_:Yeah, no, it's okay
21:45:23tacotime_: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:28gmaxwell: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:23sipa:oh, altcoins are the perfec
21:46:36sipa:oh, altcoins are the perfect place to introduce crazy things
21:46:38gmaxwell: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:52sipa:but silly things is something else
21:47:26tacotime_:Ah, okay.
21:47:40gmaxwell: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:09luke-jr_:luke-jr_ is now known as Luke-Jr
21:48:25Emcy_:oh yeah i got a stupid question
21:48:30Emcy_:what does staging mean
21:48:48gmaxwell: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:50:08andytoshi: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:32andytoshi: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:07andytoshi: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:24andytoshi:and because you can change the superposition by reallocating hashpower, there is also weird incentives
21:52:20gmaxwell: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:46tacotime_: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:50tacotime_:(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:50Ademan-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:05Ademan-school:and what's the DOS case you're referring to if there's a refund transaction?
21:56:31gmaxwell:Ademan-school: next post down, https://bitcointalk.org/index.php?topic=91843.msg1011980#msg1011980
21:57:14gmaxwell: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:55gmaxwell: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:14tacotime_: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:49gmaxwell:tacotime_: well I think all the incentive arguments around that actually involve the miner being the owner of the coins.
22:00:01gmaxwell:you abandon that and I dunno what you have anymore.
22:00:35Ademan-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:08gmaxwell:Ademan-school: if you want paintstaking detail you can look at the coinswap post, where I include a protocol diagram.
22:01:21gmaxwell:it's the same protocol but wrapped in a couple extra layers that make it totally private.
22:02:20gmaxwell: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:41tacotime_: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:11Ademan-school:heh someone created a service called coin-swap which seems unrelated
22:03:33gmaxwell:well I blame jcorgan for the overly generic name.
22:04:51BlueMatt_:BlueMatt_ is now known as BlueMatt
22:05:33tacotime_: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:42tacotime_:But proof-of-stake pooling by simply giving your coins out seems like a recipe for drama.
22:07:58gmaxwell: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:01maaku:tacotime_: proof of stake minting of any kind is a recepe for drama
22:08:16gmaxwell:I've mostly swapped out POS right now... since it has so many tricky problems.
22:08:42gmaxwell: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:01tacotime_:Ah, that's fine, I just always worried I'm going to do something really silly so I ask.
22:09:04gmaxwell:and after four iterations of that I realize I've already gone through all this before.
22:09:10gmaxwell:You will.
22:10:00gmaxwell: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:13:03tacotime_:Well, I'm interested to see where I'll run into problems I guess.
22:14:00maaku:tacotime_: i suggest thinking long and hard why you want proof of stake *minting* in the first place
22:14:18maaku:there be especially vicious dragons
22:14:49tacotime_: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:29tacotime_: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:16tacotime_: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:38tacotime_:Minting blocks with transactions other than coinbase to pay themselves seemed like a bad idea.
22:17:52zooko:zooko has left #bitcoin-wizards
22:19:15maaku:tacotime_: yes, sure, but why net set subsidy=0?
22:19:21tacotime_: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:27tacotime_:For the subblocks?
22:20:16tacotime_: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:21Ademan-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:25tacotime_:(and indifferently)
22:20:36tacotime_:I mean, that can still happen of course.
22:20:55Ademan-school:er, whatever the ultimate txid ends up being, must be inserted, and the second tx resigned?
22:21:24gmaxwell: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:57tacotime_: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:33tacotime_:(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:41Ademan-school:oh heh you even note that down below the protocol diagram
22:30:58Ademan-school:welp, forgot to bring my charging cable to school today, signing off for now, thanks
23:11:58shinybro:shinybro is now known as asianbro
23:35:12Luke-Jr:gmaxwell: since you're not here, you're the topic of discussion
23:39:31Luke-Jr:gmaxwell: we're going to you now
23:40:42Luke-Jr:let us in
23:41:40sipa:yeah we have this discussion we can't agree
23:44:26Luke-Jr:gmaxwell: I meant when we get there!