1 2011-10-02 00:00:29 <lfm> if you want the block numbers for those others I can find them too.
  2 2011-10-02 00:03:41 <delson> I am messing about with the idea of an alternate algorithm for the way transactions are processed...
  3 2011-10-02 00:03:52 <delson> so these logs would essentially be based on an alternative bitcoin chain
  4 2011-10-02 00:07:51 <genjix> lfm: btw is that only for coinbase transactions?
  5 2011-10-02 00:08:03 <genjix> or can it be for other transactions theoretically
  6 2011-10-02 00:08:33 <genjix> it seems so
  7 2011-10-02 03:15:05 <AlexWaters> anyone have a pull they want tested tonight? i'll trade some manual testing time for a unit test writeup for your pull
  8 2011-10-02 03:17:05 <diki> just to ask but...how does one mine a block and not broadcast it?
  9 2011-10-02 03:17:19 <diki> i've heard of stuff like that happen
 10 2011-10-02 03:17:20 <diki> but how?
 11 2011-10-02 03:17:25 <AlexWaters> you could mine while connected to one peer i believe
 12 2011-10-02 03:17:32 <Diablo-D3> just make your bitcoind not do it
 13 2011-10-02 03:17:39 <Diablo-D3> I dont see the point unless you're attempting a 51% attack
 14 2011-10-02 03:17:40 <AlexWaters> and make that one peer your other node
 15 2011-10-02 03:18:00 <AlexWaters> Diablo-D3: yeah i don't see any point to it other than that as well
 16 2011-10-02 03:19:18 <diki> jist
 17 2011-10-02 03:19:20 <diki> oops
 18 2011-10-02 03:19:36 <diki> just asking, i mean, basically anyone can do it as long as he mines two consecutive blocks
 19 2011-10-02 03:24:24 <AlexWaters> anyone know where I can download the Jenkins builds?
 20 2011-10-02 03:29:05 <nanotube> AlexWaters: bluematt might ;)
 21 2011-10-02 03:29:49 <nanotube> http://jenkins.bluematt.me/ <- maybe?
 22 2011-10-02 03:30:47 <AlexWaters> nanotube: I have looked in there, I don't see a way to download the binaries - I guess I could write a script that has jenkins push them to my repo
 23 2011-10-02 03:32:16 <nanotube> http://jenkins.bluematt.me/job/Bitcoin/ws/
 24 2011-10-02 03:32:18 <nanotube> try that
 25 2011-10-02 03:34:00 <nanotube> AlexWaters: ^ (you get that by clicking the 'workspace' link
 26 2011-10-02 03:34:02 <nanotube> )
 27 2011-10-02 03:34:22 <Joric> http://jenkins.bluematt.me/job/Bitcoin/ws/ oh cool looks like it's a qt build
 28 2011-10-02 03:34:32 <Joric> does it have upnp enabled
 29 2011-10-02 03:35:10 <nanotube> dunno...
 30 2011-10-02 03:38:23 <Joric> it's not a qt build.... what the hell did i just launch? does it steal my wallet currently?
 31 2011-10-02 03:38:25 <AlexWaters> the bitcoin.exe file in there looks like WX i think
 32 2011-10-02 03:38:32 <Joric> it's wx yeah
 33 2011-10-02 03:38:41 <AlexWaters> Joric: I don't think so, haha
 34 2011-10-02 03:39:25 <nanotube> look for "STEAL_WALLET=1" in the makefile :)
 35 2011-10-02 03:39:28 <Joric> i've built my own qt version there was some problems with upnp 1.6 i recommend include it into the deps archive
 36 2011-10-02 03:39:42 <AlexWaters> in windowns?
 37 2011-10-02 03:39:49 <Joric> yeah mingw
 38 2011-10-02 03:40:06 <Joric> because, you know, without upnp it damages network and such
 39 2011-10-02 03:40:07 <AlexWaters> did you follow a guide, and do you mind posting it?
 40 2011-10-02 03:40:24 <AlexWaters> and I will try to build it that way to see what happens
 41 2011-10-02 03:41:02 <Joric> AlexWaters, i don't remember what i did linking problems probably wrong linking order
 42 2011-10-02 03:41:17 <Joric> got _imp_ instead of _
 43 2011-10-02 03:41:21 <AlexWaters> symlinking issues? I have the same problem last time I tried in windows
 44 2011-10-02 03:41:30 <AlexWaters> which is why i just download the binaries usually =P
 45 2011-10-02 03:42:12 <AlexWaters> bluematt does have a good guide somewhere though
 46 2011-10-02 03:45:14 <genjix> what is the point of jenkins?
 47 2011-10-02 03:45:21 <genjix> i never understood CI
 48 2011-10-02 03:45:57 <genjix> or is it just that there's nightlies?
 49 2011-10-02 03:47:08 <Joric> genjix, the whole point of CI is to provide regular automated builds
 50 2011-10-02 03:48:20 <Joric> funny there's no qt build though
 51 2011-10-02 03:48:47 <genjix> why?
 52 2011-10-02 03:49:03 <genjix> for people to test, or simply to see if it builds?
 53 2011-10-02 03:49:22 <Joric> i guess, the latter
 54 2011-10-02 03:50:04 <genjix> weird. i would've thought it's for people to test (nightly builds) but then why it's called CI eludes me
 55 2011-10-02 04:05:02 <AlexWaters> i think one of the goals is to get it to be a more efficient test builder
 56 2011-10-02 04:05:30 <AlexWaters> it can run testing scripts against a repo, which is valuable to me
 57 2011-10-02 04:12:18 <genjix> ic
 58 2011-10-02 04:40:46 <CIA-101> libbitcoin: genjix * r3ef9a341e162 / (include/bitcoin/script.hpp src/script.cpp): SIGHASH_SINGLE SIGHASH_NONE SIGHASH_ANYONECANPAY
 59 2011-10-02 04:40:48 <CIA-101> libbitcoin: genjix * r82ebcfd9925c / (bitcoin.sql src/storage/postgresql_storage.cpp): Handle duplicate transactions being in multiple blocks in the same chain.
 60 2011-10-02 04:40:49 <CIA-101> libbitcoin: genjix * r497e668216d3 /src/ (3 files in 2 dirs): VALIDATE BLOCKS COMPLETED!!! (search for double spends)
 61 2011-10-02 06:05:40 <sipa> the finney aattack depends on not jmmediately broadcasting
 62 2011-10-02 10:30:08 <d33tah> if I arbitrarily change the bitcoin port from 8333 to anything different in protocol.h, will the bitcoin client manage to communicate with other peers?
 63 2011-10-02 10:52:43 <Habbie> d33tah, i highly doubt it
 64 2011-10-02 10:53:43 <tcatm> d33tah: it will work but you should avoid changing the port
 65 2011-10-02 10:56:58 <da2ce7> tcatm, how hard would it be to make a version of bitcoin that works on the network that uses a diffent port randomly on every bootup.
 66 2011-10-02 10:57:49 <da2ce7> there is lost of issues with UPNP with using the same port.
 67 2011-10-02 10:57:57 <tcatm> writing the code would be easy
 68 2011-10-02 10:59:00 <tcatm> however, each nodes' address database might get outdated much sooner as not only a nodes IP but also its port can change
 69 2011-10-02 16:36:21 <sipa> the current bitcoin blockchain contains 179 MB of non-script data, and 467 MB of script data
 70 2011-10-02 16:36:55 <sipa> the non-script data seems extremely compressible (idea by gmaxwell): i implemented a CABAC for it that reduces it to 17 MB
 71 2011-10-02 16:37:44 <sipa> using key recovery, the script data itself should be compressible by a factor 2 at least as well
 72 2011-10-02 16:40:16 <gavinandresen> I'm probably reading the code wrong, but I think OP_EVAL wouldn't cause a blockchain split!
 73 2011-10-02 16:40:52 <sipa> how so? each client that doesn't support it would fail verifying such a transaction
 74 2011-10-02 16:41:12 <sipa> so the first time an OP_EVAL txout is spent, it would cause a blockchain split for those clients
 75 2011-10-02 16:41:17 <gavinandresen> Nope.  They'd look like anybody-can-spend transactions to old clients, assuming we use OP_NOP1 for OP_EVAL
 76 2011-10-02 16:41:31 <sipa> hmm, nice
 77 2011-10-02 16:41:34 <sipa> didn't know that
 78 2011-10-02 16:41:47 <gavinandresen> Me neither until I started scoping out how much work OP_EVAL would be just now
 79 2011-10-02 16:44:26 <sipa> what is still possible though, is an old miner accepting an invalid OP_EVAL-using script
 80 2011-10-02 16:44:36 <sipa> that would cause its blocks to be ignored by newer clients
 81 2011-10-02 16:44:51 <gavinandresen> yes, still need a majority of miners to upgrade
 82 2011-10-02 16:45:13 <sipa> that's indeed only a minor issue if you wait long enough for rolling it out
 83 2011-10-02 16:47:43 <ThomasV> is there an option to disable keypool extension?
 84 2011-10-02 16:48:04 <gavinandresen> what do you mean 'keypool extension' ?
 85 2011-10-02 16:48:21 <ThomasV> the creation of new keys
 86 2011-10-02 16:48:54 <ThomasV> if I use -keypool=n, does it do that?
 87 2011-10-02 16:49:19 <gavinandresen> That just sets the min number of keys in the pool, bitcoin will still create new keys.
 88 2011-10-02 16:49:25 <gavinandresen> What do you need it for?
 89 2011-10-02 16:49:44 <gavinandresen> I've been running the bitcoin faucet with a -noprivacy patch that avoid creating new keys.
 90 2011-10-02 16:50:15 <ThomasV> oh, I think I already talked about that with you ; I would like to have a wallet that I can save once and for all
 91 2011-10-02 16:50:43 <ThomasV> imo this should be the default behaviour,  btw
 92 2011-10-02 16:51:14 <gavinandresen> noprivacy does that, assuming you never explicitly ask for new keys.  It can make the accounts code very confused, though.
 93 2011-10-02 16:51:42 <ThomasV> the accounts code?
 94 2011-10-02 16:52:04 <gavinandresen> Yes, sendfrom, getaccountaddress, etc....
 95 2011-10-02 16:52:31 <gavinandresen> the RPC api used if you've got a web service that needs to keep track of balances for different users in the same wallet
 96 2011-10-02 16:52:41 <luke-jr> [14:41:17] <gavinandresen> Nope.  They'd look like anybody-can-spend transactions to old clients, assuming we use OP_NOP1 for OP_EVAL
 97 2011-10-02 16:52:51 <luke-jr> so then old clients accept them as valid, and new ones don't&
 98 2011-10-02 16:53:00 <luke-jr> and we have a malicious fork
 99 2011-10-02 16:53:29 <ThomasV> gavinandresen: where is that patch ? is it a pull request ?
100 2011-10-02 16:53:30 <gavinandresen> luke-jr: right, have to assume that a majority of miners upgrade
101 2011-10-02 16:53:30 <luke-jr> ah, sipa noted that
102 2011-10-02 16:53:37 <gavinandresen> ThomasV: not a pull request:  https://github.com/gavinandresen/bitcoin-git/commit/47e2066ffc9c67de661f1e59ffe65a912fa3c4cc
103 2011-10-02 16:54:25 <ThomasV> I see
104 2011-10-02 16:54:26 <gavinandresen> luke-jr:   ... generate a couple of evil transactions and that should give miners a pretty big incentive to upgrade....
105 2011-10-02 16:54:56 <luke-jr> gavinandresen: or make OP_EVAL invalid ;)
106 2011-10-02 16:55:02 <sipa> gavinandresen: i think you're right, a "OP_DUP OP_HASH160 <scriptHash> OP_EQUALVERIFY OP_EVAL" script should evaluate to true if OP_EVAL=OP_NOP1
107 2011-10-02 16:55:44 <luke-jr> how many OP_NOPs are there?
108 2011-10-02 16:55:50 <luke-jr> ie, will this hack only work once?
109 2011-10-02 16:55:54 <gavinandresen> sipa:  yes, it will.  luke-jr : see script.h
110 2011-10-02 16:56:23 <gavinandresen> luke-jr: there are 10 of them.
111 2011-10-02 16:56:24 <sipa> 10
112 2011-10-02 16:56:36 <luke-jr> why not start at OP_NOP10?
113 2011-10-02 16:56:43 <luke-jr> for reusing
114 2011-10-02 16:57:01 <gavinandresen> start at the end?  is there a good reason to?
115 2011-10-02 16:57:14 <luke-jr> so the OP_NOPs are together?
116 2011-10-02 16:57:21 <luke-jr> or I guess OP_NOP2 doesn't follow OP_NOP anyway
117 2011-10-02 16:57:38 <sipa> i don't see what you're saying
118 2011-10-02 16:57:41 <luke-jr> so they go in sequential order, instead of 1 3 4 5 6 7 8 9 10? :P
119 2011-10-02 16:57:57 <luke-jr> cosmetics
120 2011-10-02 16:58:17 <sipa> 2--10 are as sequential as 1--9 is?
121 2011-10-02 16:58:43 <luke-jr> sipa: if you replace OP_NOP2 with OP_EVAL, then it's 1, 3-10
122 2011-10-02 16:58:59 <sipa> and why would you do that?
123 2011-10-02 16:59:03 <luke-jr> if OP_NOP10 is replaced first, then it's 1-9
124 2011-10-02 16:59:08 <luke-jr> &
125 2011-10-02 16:59:22 <sipa> why not just use OP_NOP1?
126 2011-10-02 16:59:57 <luke-jr> I assume OP_NOP(1) is already in existing transactions
127 2011-10-02 17:00:28 <sipa> ah, that's a good point - no idea if it is, though
128 2011-10-02 17:00:35 <luke-jr> in fact, I'm certain it is
129 2011-10-02 17:00:40 <luke-jr> seeing as i've used it
130 2011-10-02 17:00:42 <luke-jr> :p
131 2011-10-02 17:00:46 <gavinandresen> that's a good point; will have to interpret as OP_EVAL after a certain date or block number
132 2011-10-02 17:01:09 <luke-jr> no need to, if you're careful about it
133 2011-10-02 17:01:47 <gavinandresen> luke-jr: how so?  If there is already an OP_NOP1 in the blockchain then interpreting it as OP_EVAL would make the block invalid
134 2011-10-02 17:02:18 <luke-jr> if.