1 2012-05-27 01:45:26 <KingKatari> hey i have a question
  2 2012-05-27 01:46:46 <KingKatari> can anyone who os good with php look over a poolserver frontend and tell me where i can find the coding for the PPLNS reward system cuz right now it is doing 200% PPS rate and i dont now why
  3 2012-05-27 01:46:47 <phantomcircuit> KingKatari, http://www.catb.org/~esr/faqs/smart-questions.html
  4 2012-05-27 01:46:51 <KingKatari> err know
  5 2012-05-27 01:47:04 <KingKatari> damn k key is sticking
  6 2012-05-27 08:48:29 <enquirer> can we use namecoin as address shortener for bitcoin?
  7 2012-05-27 08:49:31 <Eliel_> wouldn't that require that everyone who sends bitcoins to such a shortened address would need to run namecoin to be able to trust the result?
  8 2012-05-27 08:51:20 <enquirer> not a big problem to incorporate both in the same client I guess
  9 2012-05-27 08:52:50 <enquirer> how?
 10 2012-05-27 08:53:07 <Eliel_> well, it's bitcoin with some extras bolted on running it's own blockchain
 11 2012-05-27 08:53:30 <Eliel_> no reason it couldn't also run bitcoin's blockchain on the side :P
 12 2012-05-27 08:53:58 <Eliel_> although, I don't think it has the BIP-16 change
 13 2012-05-27 08:55:21 <Eliel_> so, it could perhaps be simpler to take the latest bitcoin and redo the namecoin mods.
 14 2012-05-27 09:51:43 <PK> My bitcoin client process about 5 blocks per minute when catching up with the chain. If I don't run bitcoin at least daily it can take hours to update to the newest block. Is that normal?
 15 2012-05-27 09:52:08 <sipa> what hardware are you running it on?
 16 2012-05-27 09:52:15 <sipa> in particular cpu/ram/disk
 17 2012-05-27 09:52:27 <PK> CPU stays around 13% (on a quad core, so 50% of one core)
 18 2012-05-27 09:52:59 <PK> ram = 5GB, OS win xp 64
 19 2012-05-27 09:53:19 <sipa> and you're not running from an usb stick or something?
 20 2012-05-27 09:53:25 <PK> The disk is my NAS, so it's 4 disk raid5 on a 1 gbps network
 21 2012-05-27 09:53:32 <sipa> ah
 22 2012-05-27 09:54:05 <sipa> i think doing synchronous database updates on a network disk is asking for trouble
 23 2012-05-27 09:54:07 <PK> Using various disk benchmarking tools shows that the NAS is about equal to my local disk.
 24 2012-05-27 09:54:36 <sipa> maybe in throughput, but that's not the limiting factor here
 25 2012-05-27 09:56:35 <PK> sipa: I ran ATTO Disk Benchmark against the samba share and got up to 57MB/s write and 90MB/s read (transfer size: 512KB, Total length: 2GB). And initializing bitcoin (loading the full chain from disk) isn't very slow either. It's only updated from the network.
 26 2012-05-27 09:57:40 <sipa> PK: and as i said, throughput is not your problem
 27 2012-05-27 09:58:01 <sipa> but latency when doing synchronous operations is
 28 2012-05-27 09:58:54 <PK> sipa: is there a way of keeping the wallet only on the NAS and the chain local? I start bitcoin with -datadir.
 29 2012-05-27 10:00:18 <PK> Or have the gui only connect to a bitcoind instance running on the NAS 24/7. That woud be quite cool. I compiled bitcoin for arm before, so it could run there.
 30 2012-05-27 10:01:09 <sipa> yes and no - you can make the wallet a symlink to the actual file in the datadir
 31 2012-05-27 10:01:42 <PK> I agree on linux, but I'm running windows xp here. Dunno how to do symlinks there.
 32 2012-05-27 10:01:43 <sipa> or maybe better, make the datadir local, but blkindex.dat blk0001.dat and the database dir symlinks to corresponding places on the NAS mount
 33 2012-05-27 10:01:52 <sipa> oh, no idea then
 34 2012-05-27 10:02:08 <PK> feature request? :)
 35 2012-05-27 10:02:33 <sipa> already on it; 0.7 or 0.8 will probably have support for wallet files independent from the database env
 36 2012-05-27 10:03:21 <PK> nice, can you also split gui and server? To use the GUI alone with a remote server?
 37 2012-05-27 10:04:17 <sipa> there are plans to aim for disconnectint wallet and blockchain - the GUI would be part of wallet system
 38 2012-05-27 10:04:38 <sipa> but that's far more work, because of how things are built now
 39 2012-05-27 10:06:02 <PK> you can compile the server without GUI already, and you have the RPC in place. Changing the GUI to use RPC instead of calling methods directly should do that trick. Might need some additional RPC commands to be added.
 40 2012-05-27 10:06:13 <sipa> a lot more
 41 2012-05-27 10:06:32 <sipa> rpc is not really the best way for communication between GUI and wallet/blockchain
 42 2012-05-27 10:06:40 <sipa> as you need asynchronous callbacks e.g.
 43 2012-05-27 10:08:46 <PK> Maybe there's a 3rd party GUI using RPC to access bitcoind? Do you know any from the top of your head?
 44 2012-05-27 10:09:00 <sipa> spesmilo
 45 2012-05-27 10:09:07 <sipa> (never tried it)
 46 2012-05-27 10:10:12 <PK> thanks, giving it a try
 47 2012-05-27 10:12:50 <luke-jr> working on Spesmilo convinced me RPC needs to be replaced someday :p
 48 2012-05-27 10:16:10 <PK> luke-jr: do I need a patched bitcoind for that?
 49 2012-05-27 10:16:46 <luke-jr> PK: for Spesmilo, no.
 50 2012-05-27 10:16:56 <luke-jr> for replacing JSON-RPC, you'd need to write it yourself :P
 51 2012-05-27 10:17:42 <PK> luke-jr: I don't want to steal your work :) I mean Spesmilo because there is a patch.diff file.
 52 2012-05-27 10:18:42 <luke-jr> sipa:
 53 2012-05-27 10:18:44 <luke-jr> // FetchInputs treats CDiskTxPos(1,1,1) as a special "refer to memorypool" indicator
 54 2012-05-27 10:18:45 <luke-jr> // Since we're just checking the block and not actually connecting it, it might not (and probably shouldn't) be on the disk to get the transaction from
 55 2012-05-27 10:19:35 <luke-jr> PK: it's always been optional, and probably won't apply anymore
 56 2012-05-27 10:24:41 <sipa> luke-jr: sounds good; it's simply because you know the transaction is in the memory pool, and it *should not* be on disk (which would imply being in a connected block, which is not possible before creating it)
 57 2012-05-27 10:26:15 <PK> luke-jr: I can't connect to the server :( I used the same ip, user and password as I use with bitcoind on the command line. It works with bitcoind but not with Spesmilo.
 58 2012-05-27 10:31:05 <luke-jr> sipa: did I misunderstand https://github.com/bitcoin/bitcoin/pull/1246/files#r886376 ?
 59 2012-05-27 10:31:49 <sipa> luke-jr: no, i did
 60 2012-05-27 10:32:48 <luke-jr> k
 61 2012-05-27 10:33:42 <sipa> any idea about the performance effect of checking created blocks?
 62 2012-05-27 10:37:06 <luke-jr> shouldn't be significant, since both getwork and getmemorypool cache CBlock for redundant calls
 63 2012-05-27 10:37:45 <luke-jr> diskless BDB is broken at rebase :/
 64 2012-05-27 10:37:47 <luke-jr> Boost.Test framework internal error: unknown reason
 65 2012-05-27 10:37:49 <luke-jr> make: *** [bitcoind] Error 200
 66 2012-05-27 10:37:55 <luke-jr> no clue where to even begin fixing that
 67 2012-05-27 10:38:26 <sipa> i merged 1245 and 1246 on master, and fixed conflicts
 68 2012-05-27 10:38:34 <sipa> and afaik test_bitcoin worked without problems
 69 2012-05-27 10:38:49 <luke-jr> O.o
 70 2012-05-27 10:39:05 <sipa> let me try to rebase
 71 2012-05-27 10:40:31 <luke-jr> rebase has the same net effect
 72 2012-05-27 10:40:44 <sipa> i know
 73 2012-05-27 10:43:59 <sipa> luke-jr: what is that thing with rpc.cpp in that branch?
 74 2012-05-27 10:44:12 <luke-jr> ?
 75 2012-05-27 10:44:54 <sipa> http://pastebin.com/rXS409Ju
 76 2012-05-27 10:46:29 <luke-jr> sipa: I fixed getwork from the moment of its creation
 77 2012-05-27 10:47:35 <luke-jr> sipa: ie, b354251's parent commit is the one that originally introduced getwork to JSON-RPC
 78 2012-05-27 10:47:42 <sipa> ic
 79 2012-05-27 10:47:59 <luke-jr> this way, I can merge it cleanly into all the stable branches without cherry-picking too
 80 2012-05-27 10:50:19 <luke-jr> (the conflict was actually git's inability to follow the rename :/)
 81 2012-05-27 10:52:33 <luke-jr> pushed my rebase, despite the test error
 82 2012-05-27 10:58:45 <luke-jr> hmm
 83 2012-05-27 10:58:57 <luke-jr> CDBEnv::EnvShutdown is pretty ugly
 84 2012-05-27 11:00:48 <luke-jr> looks like the crash occurs only with a real client running ;)
 85 2012-05-27 11:03:06 <luke-jr> btw, any forum mods here?
 86 2012-05-27 11:05:32 <luke-jr> sipa: OK, should be good now
 87 2012-05-27 17:24:49 <luke-jr> I propose that 1txn-miners are doing so to save on bandwidth&
 88 2012-05-27 17:25:15 <luke-jr> if you have 5 kB/s upload, it delays your 500 kB blocks by almost 2 minutes
 89 2012-05-27 17:26:22 <BlueMatt> who has 5kB/s upload?
 90 2012-05-27 17:26:29 <BlueMatt> thats worse than dial up
 91 2012-05-27 17:26:49 <BlueMatt> ok, well not quite, but still
 92 2012-05-27 17:27:01 <BlueMatt> its ~dial up
 93 2012-05-27 17:27:05 <luke-jr> BlueMatt: dialup users
 94 2012-05-27 17:27:19 <BlueMatt> who is mining on dial up?
 95 2012-05-27 17:27:23 <luke-jr> also consider that you want to upload the block to at least 8 peers
 96 2012-05-27 17:27:38 <luke-jr> I bet the dialup miner ratio is greater than the dialup bitcoin user ratio
 97 2012-05-27 17:27:50 <BlueMatt> why?
 98 2012-05-27 17:28:01 <BlueMatt> I would say the opposite
 99 2012-05-27 17:28:06 <luke-jr> because people aren't likely to pay for another broadband connection at some cold mining place
100 2012-05-27 17:28:22 <BlueMatt> how many people mine at random remote locations?
101 2012-05-27 17:28:33 <sipa> does dialup still exist?
102 2012-05-27 17:28:56 <BlueMatt> and if they do, I would think they have a fairly large operation, and then broadband is a small fraction of what they pay for power
103 2012-05-27 17:29:04 <luke-jr> XD
104 2012-05-27 18:29:04 <amiller> i'm trying to come up with a model for bitcoin that accounts for message delays
105 2012-05-27 18:29:19 <amiller> for example the proof in the bitcoin whitepaper implicitly assumes that new blocks are propagated instantly
106 2012-05-27 18:30:09 <amiller> this seems to be the main difference compared to traditional distributed systems theory papers, in which a worst-case bound for the message delay exists and is either a) known or b) unknown
107 2012-05-27 18:33:23 <amiller> i think it's the common sentiment that bitcoin is a byzantine-consensus system, but showing that it's so would be a good counter to complaints like this (ignore the part about checkpoints) http://www.links.org/?p=1183
108 2012-05-27 18:37:29 <amiller> i'm basically trying to model a worst-case scenario like this: someone finds a new block, there's a maximum delay of D before everyone knows about it and is mining at that height or better, but up until time D the rest of the network is wasting effort or, worse, mining on a fork
109 2012-05-27 18:40:40 <amiller> i've figured out how to express this problem as a two dimensional markov chain, one dimension is the height of the largest 'main chain' and the other dimension is the height of the largest 'fork' known by an adversary
110 2012-05-27 18:41:11 <amiller> but i have no idea how to analyze it. also i couldn't figure out how to describe this with anything simpler
111 2012-05-27 18:41:32 <splatster> There needs to be one or more nodes which each of the mining pools connect to to speed up block propagation between them.
112 2012-05-27 18:41:33 <amiller> maybe someone here knows more than i do about queuing theory or has thought about this puzzle already
113 2012-05-27 21:28:07 <luke-jr> so& working on refactoring the transaction time code&
114 2012-05-27 21:28:30 <luke-jr> not sure how to handle the "system clock was temporarily way off for a while, but fixed now" case :/
115 2012-05-27 22:32:00 <gmaxwell> I've got a testnet node here managing to take 16.8 seconds to return on getmemorypool.
116 2012-05-27 22:32:29 <gmaxwell> (has 2469 transactions in the hopper)
117 2012-05-27 22:35:15 <luke-jr> >_<
118 2012-05-27 22:35:23 <luke-jr> gmaxwell: is that with or without my pullreqs?
119 2012-05-27 22:37:20 <gmaxwell> Ye.s
120 2012-05-27 22:37:29 <gmaxwell> It's trunk + new testnet.
121 2012-05-27 22:38:24 <gmaxwell> haven't stuck a profiler on it but I did break into it a few times and ever time I did it was in sha256 in openssl.
122 2012-05-27 22:40:09 <luke-jr> gmaxwell: can't say I'd expect an improvement, but my checknewblock tests sure don't take 17 seconds to pass
123 2012-05-27 22:40:31 <luke-jr> (and they mine a full 110 blocks and test size/sigop limits..)
124 2012-05-27 22:41:49 <gmaxwell> yea, not sure why it's so slow.
125 2012-05-27 23:13:03 <wladston> I'm running bitcoind on a headless server. Any ideas on how to check the status of my client ? like, how to check if it is synced already
126 2012-05-27 23:16:51 <wladston> figured out, nevermind