Transcript for #bitcoin-dev 2012/01/20

00:55 gribble New news from bitcoinrss: Stemby opened issue 772 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/772>
01:29 Joric I'm terribly terribly sorry, but windows exe on http://bitcoin.org is not 4MB as stated you have to fix that
01:30 Joric bitcoin-0.5.2-win32-setup.exe is 8427K
01:33 Joric http://bitcoin.org : Windows (exe) ~4MB
02:50 CIA-76 bitcoin: Luke Dashjr * r3cb722187815 cgminer/ (main.c miner.h): Restore old ugly inconsistent display of ADL information before the standard info http://tinyurl.com/77qlvwo
02:50 CIA-76 bitcoin: Con Kolivas * r35f676b02d66 cgminer/ (main.c miner.h): Merge pull request #75 from luke-jr/ugly_display http://tinyurl.com/7rabmdq
03:00 CIA-76 bitcoin: Luke Dashjr * rdfeb1ef594e4 cgminer/main.c: Restore old ugly inconsistent display of ADL information before the standard info http://tinyurl.com/6tr5rd9
03:00 CIA-76 bitcoin: Con Kolivas * rd9ccb3b485df cgminer/main.c: Merge pull request #76 from luke-jr/ugly_display http://tinyurl.com/7yosk8s
03:43 roconnor_ yay, my rouge relayer worked!
03:43 roconnor_ http://blockexplorer.com/testnet/tx/f49902bd5fe1d74eb99e948e4502c6850c7b1955f650abe12f5618c86766e740
03:44 roconnor_ I inserted a message in someone else's transaction without even mining it.
03:44 roconnor_ I guess this is known.
03:45 CIA-76 bitcoin: various * ra4599d..9840c1 cgminer/ (util.c miner.h README main.c): (5 commits) http://tinyurl.com/42nz69f
03:45 theymos Does that mess with their client's handling of the transaction?
03:46 roconnor_ theymos: I'm running bitcoin 0.4.0 and I've kinda messed up my own client
03:46 roconnor_ I'm not entirely sure if that is my own modified code screwing it up or if it is a problem with the badly relayed transactions
03:46 luke-jr roconnor_: upgrade to 0.4.3 :P
03:46 roconnor_ I think there is a DOS attack here
03:47 roconnor_ oh wait I take that back
03:47 roconnor_ what I was thinking isn't possible.
03:47 theymos My guess is that the sender would see one transaction stuck at 0 confirmations but also see another copy which behaves correctly.
03:47 roconnor_ theymos: sounds about right.
03:48 BlueMatt gavin posted about this problem on the mailing list this morning (its been known for a long time)
03:48 roconnor_ I think this provides motivation for my "normalize signatures" idea
03:48 roconnor_ BlueMatt: do you have a link?
03:49 roconnor_ or maybe droping non-normailzed signatures.
03:49 luke-jr I think having nodes and/or miners strip all unnecessary signatures, and normalizing the ones present, would help
03:50 luke-jr and forbidding anything other than OP_PUSH before OP_CODESEPARATOR maybe
03:50 nanotube roconnor_: i think gavin just made some commits to make isstandard not pass extra pushdatas ... assuming i'm getting what you're talking about. :)
03:50 roconnor_ I guess rogue miners can still mess with thinks, as is well known.
03:51 roconnor_ luke-jr: by rouge relayer inserts extra OP_PUSHs, so such a policy is inadequate for tackling the issue.
03:51 gmaxwell roconnor_: the isstandard stuff is widely deployed those blocks could be discouraged. ::shrugs::
03:51 luke-jr my question is, can someone insert an OP_CHECKSIGVERIFY at the front to make it unredeemable?
03:51 roconnor_ luke-jr: yes, but such a transaction will fail to validate and be droped.
03:51 luke-jr roconnor_: that's why we strip out signatures that aren't needed/used for verification?
03:52 theymos This ability to insert extra data into scriptSig was a side-effect of scriptSig and scriptPubKey being split, right? It wasn't present in the original design?
03:52 roconnor_ yes, you need to strip out unused data; though telling what data is unused isn't a trickyish issue.
03:52 roconnor_ theymos: I think it was present in the original design.
03:54 roconnor_ The "real" solution is to stop using the signatures in the when hashing to create an identifier for the transaction.
03:54 roconnor_ though I haven't though through the consequences
03:54 roconnor_ *thought
03:54 roconnor_ not to mention how untenable such a solution is.
03:54 roconnor_ *sigh*
03:54 roconnor_ maybe there is something I'm missing
03:56 roconnor_ http://sourceforge.net/mailarchive/message.php?msg_id=28699429
03:56 roconnor_ I'm glad gavin is thinking about the issue.
03:56 theymos I'm not very familiar with OP_CHECKSIG operation, but I was thinking that in the old design everything except the signatures in the scriptSig was signed, which would prevent adding more data.
03:58 roconnor_ theymos: all the signatures from all the transactions are stripped before the transaction is hashed for verification purposes (or at least that is how it is done now)
03:59 roconnor_ signatures need to be generated in order, so the best one could do is sign all the signatures in the previous txins, but you must leave the signatures in the successive txins empty.
03:59 roconnor_ (and the current one)
04:00 roconnor_ but I would guess even orginally all signatures would be left out of all txins so the signatures can be generated in any order.
04:01 theymos Ah, I was incorrectly thinking of the redeemed transactions instead of the "current" one.
04:02 BlueMatt sign the sigcount and then generally enforce sig size
04:04 theymos Or to allow more freedom the sender could sign an ordered list of pushdata sizes for each scriptSig. (This data need not be included in the transaction, since it can be calculated.)
04:09 Joric http://research.microsoft.com/pubs/156072/bitcoin.pdf O_O
04:09 BlueMatt very old...
04:09 luke-jr old
04:12 BlueMatt they make a point, but Im not 100% sure its 100% valid and its sooo far down the list of problems that should take some considering that...meh
04:17 Joric speaking of those, http://bitcoin.org : Windows (exe) ~4MB but bitcoin-0.5.2-win32-setup.exe is actually 8.4MB
04:17 BlueMatt pull request it
04:18 BlueMatt the website is open source
04:40 Joric hehe github.com went offline
04:40 Joric already up
04:41 Joric that was painful https://github.com/bitcoin/bitcoin.org/pull/14
04:43 lianj why?
04:44 Joric BlueMatt said so )
04:44 gribble New news from bitcoinrss: joric opened pull request 14 on bitcoin/bitcoin.org <https://github.com/bitcoin/bitcoin.org/pull/14>
05:05 ThomasV_ WTF? theymos censors forum posts?
05:05 Diablo-D3 who doesnt
05:05 Diablo-D3 its the only thing thats fun anymore
05:12 CIA-76 DiabloMiner: Patrick McFarland master * r45a4c7f / (2 files in 2 dirs): Fix Jackson warnings, make the kernel ~0.5% faster - http://git.io/QSomDQ https://github.com/Diablo-D3/DiabloMiner/commit/45a4c7fd7fd9f3d2f4756a210c8fa0c3be316f5d
07:21 CIA-76 DiabloMiner: Patrick McFarland master * r2384dab / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Properly mutate kernel for scalar operation - http://git.io/NBS_fQ https://github.com/Diablo-D3/DiabloMiner/commit/2384dab4b9a8c44710be442202856b4fef5e8ee6
08:44 diki A quickie, how is vanitygen able to calculate the probability of finding an address?
08:45 diki I thought that was as random as finding a block
08:54 kinlo diki: it is, just like we know that one block will fall on average every 10 minutes
08:54 kinlo same logic for vanitygen
09:08 TuxBlackEdo EXCEPTION: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_6system12system_errorEEEEE
09:08 TuxBlackEdo read_some: End of file
09:08 TuxBlackEdo C:Program FilesBitcoinitcoin-qt.exe in Runaway exception
09:08 TuxBlackEdo it keeps doing it
09:08 TuxBlackEdo after like 20 mins
09:11 diki TuxBlackEdo:In this day and age, why are you not with a 64-bit OS?
09:12 TuxBlackEdo heh
09:12 TuxBlackEdo that's the prob?
09:12 diki ugh, never said it was
09:12 diki It just strikes me as odd
09:14 TuxBlackEdo and sometime it will just stall on "bitcoind.exe getinfo"
09:14 TuxBlackEdo and i have to control-alt-delete it and reopen
10:31 sje anyone know what's the best driver version to use for 6990 / ubuntu? i have 2.5 and occasional cgminer lockups
10:38 diki well
10:38 diki I can see around a week of importing the blockchain in my db
10:39 diki Since when the blocks were ~146k it took me that much
10:42 Joric diki, took a couple of hours for me (bitcointools -> sqlite)
10:42 diki abe->mysql
10:43 diki the reason is
10:43 diki transactions
10:43 diki that is the only thing that makes abe run slower
10:44 diki once abe reaches blocks where there is 50 transactions per block or more
10:44 diki that is when it gets slower
10:45 phantomcircuit diki, i found slow part is the indexes actually
10:46 diki But this time it's different, I have more ram
10:46 diki I hope that speeds things a bit
10:46 phantomcircuit maybe
10:47 diki ever used abe?
10:47 Joric i'm thinking of loading bdb entirely into memory and reindexing it the way i want, might help with drawing charts and such
10:49 sipa sje: #bitcoin-mining
10:49 sje ty sipa
10:50 phantomcircuit diki, no but i did write a bitcoin client in python
10:50 diki well, its starting to get slower
10:50 phantomcircuit blocks are cheap
10:50 phantomcircuit transactions are expensive
10:59 [Tycho] Hello, luke-jr ?
11:02 TuxBlackEdo Yes, this is dog
11:06 [Tycho] What's the number of block that contains "/////Stack is innocent/////" message ?
11:11 TuxBlackEdo lol i like the recent addition to the blockchain "* Stack is guilty! *"
11:11 doublec Tycale: 162425 iirc
11:11 doublec erm [Tycho] ^^
11:12 [Tycho] Thanks.
11:12 [Tycho] TuxBlackEdo: where is it ?
11:22 TuxBlackEdo has to be a recent block
12:24 diki As I suspected, I am at block 70k and its slow, not fast like before
12:24 diki and when it reaches 90k, that is when it gets even slower
12:24 diki So a few days would be required to import the blk chain
12:32 TuxBlackEdo ;;bc,blocks
12:32 gribble 163041
13:43 gavinandresen Good morning y'all
13:43 sipa hi there gavin
13:45 phantomcircuit gavinandresen, it's morning ?:
13:45 phantomcircuit ?:|
13:45 gavinandresen Yes, it is morning. Get with the program.
13:45 gavinandresen :)
13:45 phantomcircuit heh
13:46 sipa don't you know official bitcoin time is GMT-5 ?
13:47 gavinandresen Hey, that's MY timezone! Cool!
13:48 sipa people thing it is UTC seconds since epoch, but it is actually seconds in GMT-5 since december 31st 1969, 7 pm
13:48 sipa *think
13:49 luke-jr phantomcircuit: UGT!
13:49 phantomcircuit lold
13:56 TuxBlackEdo I just don't get why bitcoind can't have the hashespersec calculate from the amount of getworks... at least an estimate would be nice
13:57 TuxBlackEdo and if it isn't supported anymore why isn "genproclimit" and "hashespersec" and "generate" removed from getinfo?
14:17 luke-jr TuxBlackEdo: it is, in git master
14:17 luke-jr <.<
14:22 gmaxwell Morning.
14:35 sipa gavinandresen: in ::Solver, the TX_SCRIPTHASH case causes a reply with the correct script
14:35 sipa but where is/are the necessary signatures produced
14:37 gavinandresen sipa: one sec...
14:38 gavinandresen sipa: SignSignature()
14:39 sipa i see
14:58 marty hi
14:58 marty someone mentioned once in reddit a way to make a contract in BTC, using keys as a sort of escrow. anybody knows what's it about?
14:59 sipa https://en.bitcoin.it/wiki/Contracts ?
14:59 marty let's see
14:59 marty ty
15:03 k9quaint every time I see sipa now, I think of the unholy spawn of SOPA and PIPA :P
15:03 sipa i'm going to DMCA them down
15:03 sipa i was first
15:03 k9quaint good man
15:03 Diablo-D3 k9quaint: oh fuck
15:03 Diablo-D3 goddamnit man!
15:04 Diablo-D3 I cant unsee!
15:04 Diablo-D3 why did you do that!
15:04 k9quaint you can, with a spoon
15:04 k9quaint of course if you don't guess right on which part of your brain has that image...
15:11 diki Made .42 bitcoins...
15:11 diki First time I mined for over 24 hours on a pool, since September anyway
15:17 sipa k9quaint: PIPA = protect ip act; SOPA = stop online piracy act; sipa = stop ip act :D