00:00:30 e4xit has joined #bitcoin-wizards 00:04:42 crescendo has joined #bitcoin-wizards 00:10:46 tromp has joined #bitcoin-wizards 00:21:18 wallet42 has quit 00:21:23 bizzle_ has quit 00:21:59 bizzle has joined #bitcoin-wizards 00:23:18 bizzle_ has joined #bitcoin-wizards 00:26:34 bizzle has quit 00:29:15 TD has quit 00:30:31 keus has quit 00:37:39 keus has joined #bitcoin-wizards 00:41:38 zooko has quit 00:48:12 bizzle_ has quit 00:48:47 bizzle has joined #bitcoin-wizards 00:52:49 bizzle has quit 00:57:19 So. Y'all know that sighash single bug when the Nth vin uses SINGLE and there are less than N vouts? 00:58:30 nope 00:58:32 never heard of it 00:58:34 no, but please continue 00:58:43 lemme clear this first, one sec 00:58:47 or is it for the quiz? 01:02:55 TheSeven has quit 01:06:06 okay. So... right we sign the value 1 in that case due to that bug. 01:06:26 Imagine instead that we signed the value 0 instead? 01:06:55 (e.g. in a hypothetical alternative universe the broken code was return 0 instead of return 1) 01:06:57 TheSeven has joined #bitcoin-wizards 01:07:18 Any guesses on what would be different in that universe from ours? 01:07:43 some ugly interaction with ecdsa? 01:07:53 no, should be ok? 01:08:28 mr_burdell has joined #bitcoin-wizards 01:08:48 ghtdak has quit 01:10:23 0000000000000000000000000000000000000000000000000000000000000001 01:10:51 (don't shake hands with antimatter bitcoinuniverse you) 01:11:59 BlueMatt: yea, a very ugly interaction with ecdsa. 01:12:07 it's trivial to forge signatures of the value 0 01:12:24 gmaxwell: but we'd be signing 32 0-bytes, not 0, no? 01:12:27 is there no difference? 01:12:39 gmaxwell: it isn't the hash of 0? 01:12:41 it's a number. keep in mind sighash is returning a hash. 01:12:58 ah 01:13:09 oh? our ecdsa doesnt hash it again before signing? 01:13:12 thats ugly 01:13:16 but, understandable 01:13:21 no, thats the function that hashes it that returns 1 01:13:33 ahh, fun 01:13:35 well, ok then 01:13:39 and the signature of 0 with pubkey is {r,s} = pubkey.x,pubkey.x 01:13:59 (well, a signature, I guess there are ~2^256 of them. :P ) 01:13:59 why does the function that should be hashing not return hashes conditionally? 01:14:05 https://bitcointalk.org/index.php?topic=260595.0 01:14:09 ewust: it's a bug. 01:14:09 it's kind of weird 01:14:09 hah, nice 01:14:30 but that's why 01:14:35 ... 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 (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 is reminded that he does not like ecdsa. 01:16:26 or really any DSA 01:16:45 I don't believe I've seen anyone point out that property before. 01:17:05 god knows, there is probably _something_ that is vulnerable to this, even though we aren't. 01:17:31 how come things like this are never patched when we patch for things that fork older versions? 01:17:52 tacotime_: we've never forked older versions (well not reliably) 01:18:11 pre 0.8 is lossy now, but still works. 01:18:34 oh, i didn't realize. i thought that <0.8 simply didn't work anymore because of the leveldb stuff 01:19:01 k0mputer has joined #bitcoin-wizards 01:19:07 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 ah okay 01:20:46 there are some nutter nodes out there claiming to be 0.3.x still 01:21:11 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 Deepbit's last block was 277115 and it's almost certantly still 0.3.22+patches 01:21:55 tromp has quit 01:21:58 is there a list somewhere of stuff that doesn't make bitcoin stop working but ought to be patched anyway? 01:21:59 wow 01:23:33 the crazy sighash single behavior could be soft-fork fixed. 01:24:04 gmaxwell, is there a soft fork wishlist somewhere? 01:24:10 might be logical to do it as part of malleability changes. 01:24:13 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 yeah 01:24:30 (...had the return value been 0, and not 1) 01:25:47 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 hmm, but for the grace of return-value conventions go we 01:27:11 (cf. gnuTLS last week too....) 01:27:18 nsh: also magical type handling. In _theory_ typechecking should have been like "wtf, 1 is not a hash". 01:27:29 aye 01:27:42 gmaxwell: more arguments in favor of a better script! 01:27:43 but our hashes there are uint256 and the code knows how to cast integers to uint256... 01:28:03 unfortunately, knowing how to does not translate into knowing whether to 01:28:22 i guess this is a mostly-unavoidable problem of magic types 01:28:50 i wonder what a lua-based bitcoin script would look like 01:28:57 (though you could have project wide type casting (prohibition) assertions, i suppose) 01:28:58 that could be a fun project 01:29:03 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 jrmithdobbs: that wouldn't really have the properties we want. 01:29:22 i'm having a hard time thinking of anywhere it'd be valid 01:29:34 gmaxwell: why not? 01:30:35 gmaxwell: are you coming to lunch@coinbase tomorrow? 01:30:35 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 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 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 I don't even know if we actually need the ability to cast integers to uint256 anywhere <<--- let's find out... 01:32:46 I know we use it for target comparison, and going from compact-to-full-size 01:32:52 as an int 01:33:02 not sure if we actually need _casting_ services 01:33:20 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 gmaxwell, I'm slowly removing helpers from uint256.h 01:33:46 oh it's probably used in the miner code 01:34:07 indeed 01:34:09 or is that finally stripped? 01:34:56 Another approach is simply to start anew with an opaque bitHash type, with just a few key accessors 01:35:48 nope, miner just uses the familiar 01:35:50 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256(); 01:35:57 uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256(); 01:36:26 actually... 01:36:39 peeling off uint160 into a separate type might be a nice first step 01:36:52 useful trial run for an opaque type, with fewer services demanded of it in our code 01:37:06 sounds sane to me 01:38:03 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 gmaxwell: distract yourself by convincing me lua isn't suitable ;p 01:38:40 i'm having a hard time doing it myself 01:40:53 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 plus minutia like lua bytecode isn't secure, so you can't even use a standard lua bytecode interperter. 01:41:29 (evil bytecode can escape the lua sandbox) 01:41:56 gmaxwell: memory isn't statically deciadable but it's inherently limitable by the runtime 01:42:03 Besides which, I think thats all just confused about what script actually is. Script is program _verification_ not program _execution_. 01:43:24 ghtdak has joined #bitcoin-wizards 01:43:26 and yes, i knew you couldn't use the bytecode directly :( 01:43:38 we actually use uint256::getdouble() in several places??? sigh. 01:43:39 that situation is ... unfortunate to put it nicely 01:44:35 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 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 well, not lua bytecode. 01:48:35 k0mputer_ has joined #bitcoin-wizards 01:49:21 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 you can prepay the 01:50:10 the actual operator of the oracle for usage. 01:50:14 * gmaxwell looks for that irssi script 01:50:18 * jgarzik declares death to the "^" operator 01:50:36 * 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:50:44 DougieBot5000 has quit 01:51:30 jgarzik++ 01:51:49 that book's certainly worth a reread these days 01:52:06 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:22 k0mputer has quit 01:52:36 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 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 nsh: hm? economically its great— you move the cost entirely onto the person creating the transaction. 01:53:47 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 well, it's a long way in my head, anyway :) 01:55:18 ok, wtf uses '&' on uint256. grump. 01:57:09 bool fTrickleWait = ((hashRand & 3) != 0); 01:57:12 mmmmm 01:57:44 oh come on. lol 01:58:27 uint256 hashRand = inv.hash ^ hashSalt; 01:58:30 same code section 01:58:39 sigh 01:59:09 // 1/4 of tx invs blast to all immediately 01:59:09 static uint256 hashSalt; 01:59:09 if (hashSalt == 0) 01:59:09 hashSalt = GetRandHash(); 01:59:09 uint256 hashRand = inv.hash ^ hashSalt; 01:59:10 hashRand = Hash(BEGIN(hashRand), END(hashRand)); 01:59:11 bool fTrickleWait = ((hashRand & 3) != 0); 01:59:18 * jgarzik whips out git blame 01:59:56 lol, satoshi 02:03:28 it's so weird to ^ some 256 bit numbers then decide just on the lsb. 02:09:39 gotta xor something 02:13:01 o.O 02:14:00 good thing the relay behavior is already full of security holes, or this would count as one too. 02:14:43 since anyone observing you for a bit will quickly determine your hashSalt. 02:16:04 oh nevermind it actually hashes it, I was missing that line. 02:16:08 isn't that what the hash is meant to protect against? (probably wanted an HMAC) 02:16:42 yea, somehow I just read over the line. I'm still very dubious about that xor. 02:17:01 but its probably not a pratical concern. 02:17:11 there was a mumble about deterministic randomness in a similar block before that 02:21:40 k0mputer_ has quit 02:24:24 gmaxwell, it's just silly 02:24:37 gmaxwell, might as well as generate one hash from two buffers 02:27:17 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 xor is generally kind of a bad way to combine hashes because of communtativity 02:29:37 jrmithdobbs: uhh. insane confusion there. 02:29:51 ? 02:30:02 gmaxwell: err? 02:30:04 *commutativity, bleh 02:30:06 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 ooh, proof checking 02:30:24 I'm a fan 02:30:24 jrmithdobbs: that eliminates all concerns related to the network's behavior. 02:30:47 gmaxwell: ah, yes, that does sound like a confusion re: snarks on my part 02:32:16 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 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 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 *cough* type systems *cough* 02:33:52 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 pmt_tests.cpp: In member function void CPartialMerkleTreeTester::Damage(): 02:34:47 pmt_tests.cpp:21:14: error: no match for operator^= (operand types are uint256 and const uint256) 02:34:47 hash ^= ((uint256)1 << bit); 02:34:54 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 fscking test. Fixed the above case, and no others showed up in the main code. 02:35:47 // flip one bit in one of the hashes - this should break the authentication 02:35:52 would that be just as good with a hash++ or did you get rid of that operator too. 02:35:55 ? 02:36:15 gmaxwell, not yet, but ideally ++ will die 02:36:27 gmaxwell, can just manually twiddle the buffer 02:38:32 what's the goal of changing this stuff? O.o 02:39:02 Luke-Jr: makes some mistakes less likely to be disguised by implicit type conversion. 02:39:10 like the SIGHAS_SINGLE bug. 02:39:23 SIGHASH 02:39:46 so this will tell you that SignatureHash shouldn't be returning 1, but what should it do there, throw an exception? 02:40:40 it won't compile. 02:40:52 I mean for compatiblity we'll make that work by explicitly converting it. 02:41:17 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 shockingly, uint256_tests.cpp is grumpy ;p 02:52:58 jgarzik has quit 02:55:00 bizzle has joined #bitcoin-wizards 03:06:45 tromp has joined #bitcoin-wizards 03:07:54 phrackage has joined #bitcoin-wizards 03:14:08 bizzle has quit 03:14:42 bizzle has joined #bitcoin-wizards 03:16:50 tromp has quit 03:17:27 tromp has joined #bitcoin-wizards 03:18:57 bizzle has quit 03:22:16 tromp has quit 03:32:17 PRab has joined #bitcoin-wizards 03:34:38 super3_ has joined #bitcoin-wizards 03:35:18 LarsLarsen has quit 03:36:26 jgarzik has joined #bitcoin-wizards 03:37:13 * jgarzik kicks boost 03:37:37 super3 has quit 03:37:59 * jgarzik would love to adopt the majority of google's C++ coding conventions. rule #1: no templates ;p 03:38:43 ok but only if rule #2 is no golang 03:39:40 jgarzik: pfft, templates are like the main reason to use C++ :P 03:39:53 LarsLarsen has joined #bitcoin-wizards 03:40:04 RoboTeddy has joined #bitcoin-wizards 03:40:24 Luke-Jr: they're really not =/ 03:44:29 Krellan__ has quit 03:45:35 jrmithdobbs: I thought you liked Haskell :P 03:46:43 copumpkin: hmm? I do 03:47:10 copumpkin: but c++ has much more redeeming features than it's template clusterfuck ;p 03:47:20 main.cpp:1331:114: error: no match for operator+ (operand types are uint256 03:47:21 and uint256) 03:47:21 if (pindexBestForkTip || (pindexBestInvalid && pindexBestInvalid->nChainWor 03:47:21 k > chainActive.Tip()->nChainWork + (chainActive.Tip()->GetBlockWork() * 6).getu 03:47:21 int256())) 03:47:35 hum, surprised that's not a bignum addition 03:47:39 ... 03:47:43 shouldn't it be? 03:47:51 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 copumpkin: haha, completely understandable misunderstanding, it is c++ 03:48:22 gmaxwell, sipa: ^ 03:49:55 hasan1 has joined #bitcoin-wizards 03:50:32 hasan1 is now known as shinybro_ 03:52:33 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 and bignums are not as nice as uint256 (e.g. slower, more allocation churn, etc) 03:54:20 tromp has joined #bitcoin-wizards 03:57:12 ok, let me demonstrate my ECDSA ignorance. the equations for signing are r = k * Gx, s = k^-1 * (z + r*d). 03:57:21 and the public key x component is Qx = d * Gx. 03:57:24 does that not mean you can rewrite s = k^-1 * (z + k * Qx)? 03:57:25 bizzle has joined #bitcoin-wizards 03:57:31 and forge any signature, given the pubkey? 03:57:42 i know I haven't discovered such a trivial flaw, but where did I go wrong? 03:57:46 just[dead] is now known as justanotheruser 03:58:52 you totally can, if you know k. but you don't know k. 03:59:34 (well perhaps I should decode your notation first) 03:59:45 z is the data you intend to sign? 04:00:35 yes 04:01:43 and no, i'm forging a signature for a given message, so I'm free to pick k, no? 04:01:51 i got these equations from Wikipedia's ECDSA page 04:03:14 (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 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 internal uint256 > library bignums everwhere... but. meh. 04:06:10 tromp_ has joined #bitcoin-wizards 04:06:32 you can't do that rewrite. r*d != k*d*Gx because r is not a point, it's a scalar. 04:06:44 (this is one place where the notation adds opacity) 04:07:03 since it's not clear when its operations in the curve group or in the integer field. 04:08:34 tromp has quit 04:09:31 bizzle has quit 04:09:43 zooko has joined #bitcoin-wizards 04:10:06 bizzle has joined #bitcoin-wizards 04:13:59 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 none the less... 04:14:29 bizzle has quit 04:16:42 gmaxwell: i thought they were all scalars 04:16:49 i guess I'll have to read up on EC algebra 04:17:14 gmaxwell: signature of 0 are forgable? 0 as the data? 04:18:28 * copumpkin ensures that all his messages hash to 0 to ensure plausible deniability 04:20:00 bizzle has joined #bitcoin-wizards 04:20:03 gmaxwell, have you tried removing the uint256 casting functions? 04:20:22 i assume it would break a few things which could then be made explicitly weird 04:20:27 instead of implicitly weird 04:20:53 Luke-Jr: signatures of data that hashes to 00000000... are forgeable 04:21:15 * Luke-Jr wonders what data hashes to 0000000… 04:21:29 the terminal block 04:22:44 phrackage has quit 04:25:28 edit SHA256() to exit(3) if all-zeroes results is generated 04:31:48 Excellent... uint160 is quite clean. None of the bitwise, arith, lt/gt cmp operators are used. 04:32:47 unfortunately they will always be dword-based, and never purely opaque 04:36:11 jgarzik: you mean, hexdump the input data, then exit(3)? 04:36:25 tacotime_ is now known as tt_zzz 04:37:43 ewust, he means blow up amazingly if the state is dangerous 04:38:51 but what if someone won the sha256 lottery, and you exited before printing the winning ticket! 04:39:48 ewust, i think the 1 in 2^256 odds of that happening are good enough to ignore 04:40:01 :) 04:40:21 pessimist! 04:40:29 I'm pretty sure that something should pop up specifying that you've now won bitcoin 04:40:32 ok i am sleeping 04:43:42 TheSeven has quit 04:43:48 <[7]> [7] has joined #bitcoin-wizards 04:46:08 Luke-Jr: I do feel a little bit of an itch to make signatures of 0 fail. 04:46:37 just in case some snazzy attack on sha256 lets you get an all zero hash out of anything.. 04:46:51 but I reconize that it's a silly concern. 04:48:37 tromp_ has quit 04:48:54 ghtdak has quit 04:49:11 tromp has joined #bitcoin-wizards 04:50:15 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 ewust: they can't generate transactions that have a hash of 0 04:53:37 tromp has quit 04:53:51 oh nvm, i was thinking you were proposing that check on generation, not verification 05:03:59 Grrr. using an analog modem on the phone line here disrupts my DSL modem. 05:08:03 phrackage has joined #bitcoin-wizards 05:25:08 e4xit has quit 05:25:47 RoboTedd_ has joined #bitcoin-wizards 05:29:18 RoboTeddy has quit 05:30:11 RoboTedd_ has quit 05:33:01 licnep_ has quit 05:39:25 mr_burde_ has joined #bitcoin-wizards 05:39:28 BCB has joined #bitcoin-wizards 05:42:35 mr_burdell has quit 05:46:10 BCB has left #bitcoin-wizards 05:46:22 zooko has quit 05:48:08 antephialtic has joined #bitcoin-wizards 05:52:19 gmaxwell: : 05:52:23 ☹* 05:52:56 yea, the real challenge will be calling the provider for support. Hopefully a regular analog phone call also disrupts it. 05:52:58 shinybro_ has quit 05:53:11 Because I think if I tell them a modem disrupts it their minds will melt. 05:53:21 gmaxwell: ok i understand now, thanks 05:56:23 justanotheruser is now known as just[dead] 05:56:43 gmaxwell: they might need the same frequencies? 05:57:06 Luke-Jr: nope not at all, they should be completely compatible. 05:57:11 hm 05:57:30 ADSL doesn't use anything under 40kHz or something like that, where all the modem stuff is <8kHz. 05:57:37 gmaxwell: maybe they will understand trying to send a fax, if you can't reproduce with voice. 05:57:46 yea, good call. 05:58:27 they only gaurantee fax-level service too (helpful to know to route through support) 05:58:47 as far as data over plain residential pots lines 05:58:53 antephialtic has quit 06:00:44 bizzle has quit 06:00:48 try again 06:02:45 ? 06:02:51 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 Luke-Jr: wrong window 06:03:46 midnightmagic: I have the filter, actually I tried stacking two of them. 06:04:19 might be defective pieces of crap because the lineman decided to be a dickhead 06:05:41 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 I think it's probably just operating at the margins and the concurrent modem use is enough to push it over. 06:06:09 Luke-Jr: why does eligius gbt no longer return transactions? 06:06:23 I was unable to tell the dude in #bitcoin if his transaction was about to be mined... 06:10:15 gmaxwell: to reduce startup bandwidth, not new 06:10:36 bitcoind -rpcconnect=gbt.mining.eligius.st -rpcuser=x -rpcport=9337 -rpcpassword=x getblocktemplate '{"longpollid":"bootstrap"}' 06:11:18 gmaxwell: the idea is to send an empty block template first, then immediately longpoll with a full block template 06:12:04 not unreasonable... I just wasn't aware you started that and hadn't updated my scripts. 06:12:07 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 gmaxwell: 2012 Nov 5 change date ;) 06:16:55 * midnightmagic is inclined to still blame the lineman 06:17:07 :-) 06:31:15 phrackage has quit 06:33:24 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 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:37:17 wallet42 has joined #bitcoin-wizards 06:37:27 nOgAnOo has joined #bitcoin-wizards 06:46:22 gmaxwell: sounds reasonable to me, though to be extra conservative perhaps not allow the change address concession 06:46:36 eg, so they have to add an input 06:47:14 so, in the case I was just working on— he had no other inputs :( 06:47:17 would be nice if we could have some kind of modular embedded Python for policy 06:47:27 I expect thats not too uncommon. 06:47:47 gmaxwell: well, he could use CPFP too 06:49:16 usually between adding another input and CPFP, I'd expect at least one to be viable 06:51:41 okay thats a point. 06:51:57 just[dead] is now known as justanotheruser 07:04:21 nOgAnOo has quit 07:13:53 RoboTeddy has joined #bitcoin-wizards 07:14:23 RoboTeddy has quit 07:14:29 RoboTedd_ has joined #bitcoin-wizards 07:26:42 antephialtic has joined #bitcoin-wizards 07:31:44 jtimon has quit 07:50:05 Krellan_ has joined #bitcoin-wizards 07:54:04 antephialtic has quit 07:59:15 Ademan has quit 08:00:37 Ademan has joined #bitcoin-wizards 08:00:53 wallet42 has quit 08:05:04 LarsLarsen is now known as needmoarmindmelt 08:05:34 needmoarmindmelt is now known as LarsLarsen 08:14:38 zzyzx has quit 08:20:10 Dyaheon has joined #bitcoin-wizards 08:23:06 antephialtic has joined #bitcoin-wizards 08:24:23 <_ingsoc> _ingsoc has joined #bitcoin-wizards 08:27:29 antephialtic has quit 08:46:29 mappum has quit 09:22:23

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:22:32 gavinandresen_ has joined #bitcoin-wizards 09:23:59 gavinandresen has quit 09:23:59