1 2012-07-29 00:13:50 <jgarzik> maaku: green threads... meh
  2 2012-07-29 00:15:46 <jgarzik> someone just needs to JIT python already.  not halfway (pypy) but all the way.
  3 2012-07-29 00:16:00 <jgarzik> the python language fundamentally does -not- require GIL
  4 2012-07-29 00:16:07 <NASDAQEnema> hai guys
  5 2012-07-29 00:16:12 <jgarzik> parrot might be the only hope
  6 2012-07-29 00:16:33 <NASDAQEnema> I may have killed the 51% problem.
  7 2012-07-29 00:16:35 <NASDAQEnema> https://bitcointalk.org/index.php?topic=96365.msg1061940#msg1061940
  8 2012-07-29 00:17:23 <NASDAQEnema> essentially allow multiple attackers to compete during the attack and work out a way to measure consistent production of blocks,
  9 2012-07-29 00:17:47 <NASDAQEnema> the more attackers the higher the threshold and the lower the reward.
 10 2012-07-29 00:18:52 <gmaxwell> Please keep the gibberish on the forums.
 11 2012-07-29 00:19:16 <NASDAQEnema> lol
 12 2012-07-29 00:33:14 <MC1984> how do i do the datadir thing?
 13 2012-07-29 00:33:50 <MC1984> can i specify the blockchain to be on an external drive say
 14 2012-07-29 00:51:25 <jgarzik> humbug.  pynode script verification dies on TX eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb (block #163685 or so)
 15 2012-07-29 00:53:21 <jgarzik> looks like that requires both bignum encoding and CHECKMULTISIG
 16 2012-07-29 00:55:34 <jgarzik> openssl's code seems to imply you shift the value out 1 byte at a time, in big endian order
 17 2012-07-29 00:55:55 <jgarzik> 4-byte big endian size pre-pended, and final byte or'd with 0x80 for sign
 18 2012-07-29 00:56:05 <jgarzik> but that's just a quick read
 19 2012-07-29 01:57:58 <gribble> New news from bitcoinrss: fanquake opened pull request 48 on bitcoin/bitcoin.org <https://github.com/bitcoin/bitcoin.org/pull/48>
 20 2012-07-29 02:25:05 <jgarzik> Well, it's a start.  My own non-OpenSSL bignum.py matches OpenSSL's MPI encoding at least 50% of the time ;)
 21 2012-07-29 03:14:05 <theymos> gmaxwell: I was thinking about the future of the max block size. What do you think about each node automatically setting its max block size to a calculated value based on disk space and bandwidth: "I have 100 GB disk space available, 10 MB per 10 minutes download speed and 1 MB per 10 minutes upload speed, so I'll stop relaying blocks [discouraging them] if they're near 1/8 MB [enough for each peer] and stop accepting them at all if they're over
 22 2012-07-29 03:16:27 <gmaxwell> theymos: What I'd like to first do before even asking that question is solve it so you can do full validation without a historical copy of the chain.
 23 2012-07-29 03:16:44 <gmaxwell> Becuase that changes the kind of answers which are acceptable to the blocksize question.
 24 2012-07-29 03:17:13 <gmaxwell> E.g. your size tolerance becomes more driven by the number of ecdsa validations you can perform per second and network bandwidth than long term storage if you have the option of going 'storageless'.
 25 2012-07-29 03:19:24 <theymos> "full validation without a historical copy of the chain" <- Is the current best plan for this still a hash tree of unspent outputs, with the root in each block?
 26 2012-07-29 03:20:07 <gmaxwell> Yes. (Though there are lots of variations on the details floating around)
 27 2012-07-29 03:20:36 <gmaxwell> Also the notice-of-treachery thing I suggested.
 28 2012-07-29 03:21:27 <theymos> OK. I think those a good ideas. With those, you think no max block size would be OK?
 29 2012-07-29 03:21:31 <gmaxwell> basically make it so that when nodes observe that a chain has broken the rules they pull out the minimum data require to prove the violation and share it widely.. if you get such a proof you can use it to reject a bad chain, even if the violation happens in part of the chain you didn't wittness yourself.
 30 2012-07-29 03:22:50 <gmaxwell> theymos: Perhaps not no-max, but a chain agreed max would probably be okay.
 31 2012-07-29 03:23:37 <gmaxwell> The problem with no-max is that one griefer could make one 1TB (or pick some other value that would break lots of nodes but only about half of them) block and cause enormous partitioning.
 32 2012-07-29 03:27:00 <gmaxwell> theymos: we'd have to hardfork to change the max, so I'd hope that the scaling improvements that have been circulating around would get integrated as part an parcel of that change.
 33 2012-07-29 03:27:13 <theymos> Yeah, that sounds good. Currently miners don't care about the long-term implications of large blocks -- they only want them to be accepted widely when the block is mined. Removing the long-term implications fixes it.
 34 2012-07-29 03:28:06 <gmaxwell> Also need to be careful with the future economic assumptions. If miners can set their instant max to $enormous in order to collect all the fees you don't get market pressure to increase fees, just a race to the bottom.
 35 2012-07-29 03:29:46 <theymos> That does seem to be a problem. I haven't thought about that one much, but artificially fixing the supply makes me uneasy. I'd prefer a more free-market solution.
 36 2012-07-29 03:30:12 <gmaxwell> heh, without limited supply you can't have a market. ;)
 37 2012-07-29 03:31:43 <gmaxwell> (and alternatively if there isn't a protocol rule to set the max you'll get miners that set it by back conspiring to reject certian blocks, a bad precident and bad for uninvolved nodes who won't know when a block is going to get killed by the cartel)
 38 2012-07-29 03:35:31 <theymos> If storage doesn't matter, then the transaction space isn't too limited naturally. What we care about is network hashing power -- we don't want this to get too low. Artificially limiting the transaction space isn't a very free-market solution for getting the "right" network hashing power -- it may be too low or too high, and end-users can't change it easily. Ideally you'd want paying more fees to get you more hashing power for just your transact
 39 2012-07-29 03:36:29 <gmaxwell> But hashing power for _your_ transaction isn't what you want, you want hashing power in the future chain to make it expensive to reverse. Also it's the recipent who wants it, not the sender. :( Lots of tragedy of the commons room.
 40 2012-07-29 03:37:25 <gmaxwell> And storage still matters some and transaction validation computational complexity matters and network bandwidth grows much slower than storage and computation speeds.
 41 2012-07-29 03:37:37 <gmaxwell> So there are still real limited supply things here, but they don't naturally form a market.
 42 2012-07-29 03:37:55 <gmaxwell> Because you'd always rather _someone else_ take the cost of paying for the security.
 43 2012-07-29 03:38:03 <gmaxwell> but if it's insecure we all suffer.
 44 2012-07-29 03:38:34 <gmaxwell> But there are orders of magnitude.. e.g. if we can make it 100x more scalable then thats a big improvement.
 45 2012-07-29 03:41:49 <theymos> Mike Hearn mentioned that big miners might normally stay inactive, but confirm transactions really fast if they have enough fees. Maybe this'd be enough to keep difficulty reasonably high.
 46 2012-07-29 03:44:40 <gmaxwell> theymos: Not as helpful as you think at first glance.. that gets you the one confirm, but it doesn't bury the transaction. It would potentially make the chain very burst too, in which case you're going to have to have a seperate clearance network to make it reasonable usable.
 47 2012-07-29 03:45:08 <gmaxwell> So once you've done that, well, lack of per block throughput matters less.
 48 2012-07-29 03:47:37 <theymos> The recipient could spend the transaction with a fee for every confirmation they'd like to have. A separate network does seem like a likely solution, though.
 49 2012-07-29 03:56:52 <gmaxwell> theymos: a seperate network has a LOT of benefits. e.g. near instant confirmations, and the ability to keep the main chain very distributed because maintaining it is cheap.
 50 2012-07-29 03:58:26 <theymos> Do you imagine a Bitcoin-like side-network? Or centralized blind signing services? Or something else?
 51 2012-07-29 03:58:54 <gmaxwell> I don't know, this is something the market can decide on. Different things have different advantages.
 52 2012-07-29 03:59:35 <gmaxwell> Bitcoin-like will always have issues with 'slow' confirmations for some definition of slow.
 53 2012-07-29 04:03:15 <theymos> Did you read that post on the forum about using hashcoin's "payment channels" concept with a network of payment processors for cheap, instant payments to anyone? That's a neat idea that might solve this problem if Bitcoin transactions don't get *too* expensive.
 54 2012-07-29 04:03:52 <jgarzik> w00t.   bignum.py output now matches openssl byte-for-byte.  input will be left for later.
 55 2012-07-29 04:10:16 <gribble> New news from bitcoinrss: gmaxwell opened issue 1637 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1637>
 56 2012-07-29 07:40:27 <SomeoneWeird> can we ever expect http proxy support?
 57 2012-07-29 07:40:49 <SomeoneWeird> i mean, theres socks
 58 2012-07-29 07:41:05 <Diablo-D3> probably not
 59 2012-07-29 07:41:26 <Diablo-D3> http proxy is only good for http
 60 2012-07-29 07:46:03 <SomeoneWeird> heh, true
 61 2012-07-29 08:15:09 <wumpus> http CONNECT could work, I suppose
 62 2012-07-29 08:17:17 <wumpus> could be useful for going through corporate firewalls, though a lot block ports != 443
 63 2012-07-29 08:30:59 <SomeoneWeird> yerp
 64 2012-07-29 10:05:17 <MC-Eeepc> the alt chain subforum is pants on head retarded
 65 2012-07-29 10:05:38 <MC-Eeepc> its been a number of years since i saw this level of forum drama
 66 2012-07-29 10:06:27 <MC-Eeepc> seems like they even went and tried to dox each other and ended up threatening a small girl with rape on the phone
 67 2012-07-29 10:12:26 <Joric> someone just 51% raped LTC guess that's the reason to worry
 68 2012-07-29 10:19:57 <jrmithdobbs> i have no words for this
 69 2012-07-29 10:20:24 <jrmithdobbs> http://home.jrbobdobbs.org/mith/lol-code-signing-10.8-fail.png
 70 2012-07-29 10:23:47 <upb> whta does that have to do with code signing?
 71 2012-07-29 10:27:53 <jrmithdobbs> upb: look at the dates. /usr/bin/ssh has the date all files from my 10.8 upgrade have as c/mtime ;p
 72 2012-07-29 10:28:21 <jrmithdobbs> upb: /opt/local/bin/ssh is from macports and was built before upgrade.
 73 2012-07-29 10:28:46 <jrmithdobbs> upb: aka, i am 100% sure it is not signed.
 74 2012-07-29 10:30:40 <jrmithdobbs> upb: hoorah security theatre
 75 2012-07-29 10:31:46 <upb> oh
 76 2012-07-29 10:33:39 <jrmithdobbs> upb: great huh
 77 2012-07-29 10:34:08 <jrmithdobbs> afaict signing stuff only applies to app packages and can be worked around by launching a file open dialog to open the other bin you want to run worst case
 78 2012-07-29 10:34:11 <jrmithdobbs> ha
 79 2012-07-29 10:34:15 <jrmithdobbs> I haven't dug too deeply
 80 2012-07-29 13:38:06 <jgarzik> dodecahedron
 81 2012-07-29 13:46:37 <MC-Eeepc> fuck yea geometry
 82 2012-07-29 13:48:25 <Joric> it would be cool to make something like that for bitcoin addresses http://internet-map.net
 83 2012-07-29 13:49:19 <Joric> says there are 350,000 sites and 2m+ links in case of bitcoin there will be more than 5m adresses
 84 2012-07-29 13:49:46 <Joric> it took several weeks for rebalancing the graph (on CPU)
 85 2012-07-29 13:50:09 <Joric> rendered 30m tiles (256x256)
 86 2012-07-29 13:57:46 <Joric> hm there's no blockchain.info probably old data
 87 2012-07-29 13:58:02 <Joric> said he used alexa database
 88 2012-07-29 13:59:26 <Joric> seems theres no .info sites at all
 89 2012-07-29 14:15:36 <gribble> New news from bitcoinrss: jgarzik opened issue 1638 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1638>
 90 2012-07-29 14:30:26 <jgarzik> 07/29/12 16:29:53 SetBestChain: new best=000000000000044fa137  height=191369  work=406085148475160689314  date=07/29/12 16:29:20
 91 2012-07-29 14:30:27 <jgarzik> 07/29/12 16:29:53 ProcessBlock: ACCEPTED
 92 2012-07-29 14:30:28 <jgarzik> 07/29/12 16:29:53 getblocks -1 to 00000000000000000000 limit 500
 93 2012-07-29 14:30:30 <jgarzik> last line x 3
 94 2012-07-29 14:31:46 <jgarzik> if not a bug, its as if it wants to re-check the first 500 blocks of the chain, when a new block arrives
 95 2012-07-29 14:33:01 <jgarzik> getpeerinfo only reports two non-satoshi-0.6 clients connected: vers 40000 and 50601
 96 2012-07-29 14:33:18 <jgarzik> blank strSubVer
 97 2012-07-29 14:55:56 <gmaxwell> jgarzik: what happens there is this: new node starts. It has no blocks. It asks its first peer for blocks
 98 2012-07-29 14:56:06 <gmaxwell> The first peer is unresponsive (for whatever reason)
 99 2012-07-29 14:56:27 <gmaxwell> Then, later, you announce a block. It now tries to pull the chain from you.
100 2012-07-29 14:57:21 <gmaxwell> I think that explains what you observed? A more interesting question is why does it seem like nodes are getting stuck ok on the IBD more often now.
101 2012-07-29 14:58:52 <jgarzik> gmaxwell: no nodes with startingheight < 191300
102 2012-07-29 14:59:34 <jgarzik> I wonder if satoshi client will send out a blank CBlockLocator() for some strange reason
103 2012-07-29 15:00:02 <jgarzik> and again,
104 2012-07-29 15:00:04 <jgarzik> 07/29/12 16:59:35 ProcessBlock: ACCEPTED
105 2012-07-29 15:00:04 <jgarzik> 07/29/12 16:59:35 SetBestChain: new best=0000000000000085e1fe  height=191373  work=406117213322897547414  date=07/29/12 16:59:09
106 2012-07-29 15:00:19 <jgarzik> 07/29/12 16:59:38 getblocks -1 to 00000000000000000000 limit 500
107 2012-07-29 15:01:01 <jgarzik> all connected peers are /Satoshi:0.6*/ except the two versions listed above
108 2012-07-29 15:01:18 <gmaxwell> hm. Quite odd.
109 2012-07-29 19:17:23 <c4pt-otc> does anyone know if its possible to fit more than eight 6990's into one machine if each 6990 uses two gpus
110 2012-07-29 19:17:46 <jrmithdobbs> wrong channel
111 2012-07-29 19:18:33 <luke-jr> c4pt-otc: likely, if your motherboard supports VT-d
112 2012-07-29 19:19:21 <c4pt-otc> jrmithdobbs, what channel should i ask in #bitcoin?
113 2012-07-29 19:19:41 <c4pt-otc> thinking about putting eight 7990s into this http://www.newegg.com/Product/Product.aspx?Item=N82E16816152125
114 2012-07-29 19:19:41 <jrmithdobbs> c4pt-otc: #bitcoin-mining or #clustercomput (the last is a guess)
115 2012-07-29 19:20:25 <luke-jr> c4pt-otc: why not just get a bunch of x1 slots? :p
116 2012-07-29 19:20:33 <luke-jr> I'd fill that with 12 cards
117 2012-07-29 19:21:08 <c4pt-otc> luke-jr, more performance with 6990 or 7990
118 2012-07-29 19:22:58 <SomeoneWeird> barely
119 2012-07-29 19:23:06 <luke-jr> c4pt-otc: x1 vs x16 makes no difference in performance
120 2012-07-29 19:26:18 <SomeoneWeird> (if you're only mining)
121 2012-07-29 22:20:16 <jgarzik> time for some uncensored, hardcore XXX checkmultisig'ing
122 2012-07-29 22:20:34 <jgarzik> no holds barred, unprotected key exchanges
123 2012-07-29 23:08:56 <graingert> buh
124 2012-07-29 23:09:19 <graingert> jgarzik: why unprotected ?