1 2013-11-04 00:09:17 <sipa> gmaxwell: i wonder whether we still need the BIP30 rule enforcement
2 2013-11-04 00:09:26 <sipa> as BIP34 makes it impossible to exploit
3 2013-11-04 00:10:06 <sipa> unless there exists a pre-BIP34 block which starts with something that could be interpreted as the push of a future block height
4 2013-11-04 00:19:51 <ekkis> sipa: in fact, it seems to me I should be using a decimal with 8 digits instead of a double
5 2013-11-04 00:20:11 <ekkis> sipa: but I'm wondering what happens when we go into fractions of a satoshi
6 2013-11-04 00:20:33 <ekkis> I've read that the protocol supports further divisions but I'm not sure how I should handle it
7 2013-11-04 00:23:03 <ekkis> I remember seeing page with advice for proper handling of datatypes for bitcoin projects...
8 2013-11-04 00:23:57 <Luke-Jr> ekkis: you should be storing 64-bit integers in raw amount, not BTC
9 2013-11-04 00:24:09 <Luke-Jr> ekkis: so if you have BTC, do *1e8 and round it
10 2013-11-04 00:24:29 <Jason> Luke-Jr: heya. how's it going?
11 2013-11-04 00:24:33 <Luke-Jr> the protocol doesn't support further divisions; if you do, then do satoshis as a decimal type
12 2013-11-04 00:24:37 <Luke-Jr> Jason: ok
13 2013-11-04 00:24:53 <Jason> Luke-Jr: i've got a question for you if you've got a minute, although I think you just answered my question
14 2013-11-04 00:25:09 <ekkis> Luke-Jr: I see? yes, I just found it: Proper Money Handling (JSON-RPC)
15 2013-11-04 00:25:15 <Jason> Luke-Jr: proper money handling: i'm supposed to multiply the amount I wish to send via bitcoind's API by 1e8?
16 2013-11-04 00:25:47 <melvster> i think btc would have to go up in value quite a lot before divisions are added to the protocol ...
17 2013-11-04 00:25:55 <melvster> but it's theoretically possible
18 2013-11-04 00:25:57 <ekkis> Luke-Jr: I'm using the bitnet.client library from c# and it was coded to represent amount as floats. I want to patch it but wasn't sure what datatype I should be using
19 2013-11-04 00:25:58 <Jason> >>> 0.00000001*1e8
20 2013-11-04 00:25:59 <Jason> 1.0
21 2013-11-04 00:26:02 <Jason> yeah?
22 2013-11-04 00:26:13 <melvster> iirc gavin said so once
23 2013-11-04 00:28:27 <sipa> melvster: everything is theoretically possible
24 2013-11-04 00:28:47 <sipa> i find the claim that the protocol can be upgraded to support more digits misleading
25 2013-11-04 00:29:05 <sipa> of course it can, just as it can be upgraded to be a wrapper around PayPal
26 2013-11-04 00:29:12 <sipa> well, "upgraded"
27 2013-11-04 00:29:29 <ekkis> sipa: shite? sql server doesn't store unsigned 64-bit integers? I think I'll go with decimals
28 2013-11-04 00:29:42 <sipa> ekkis: sounds like the way to go
29 2013-11-04 00:30:09 <Luke-Jr> melvster: it's theoretically possible, in the form of making a new "altcoin" that continues the previous blockchain
30 2013-11-04 00:30:48 <Luke-Jr> ekkis: why would you ever use MS SQL?
31 2013-11-04 00:30:55 <Jason> lol
32 2013-11-04 00:31:37 <Arnavion> What's wrong with MS SQL?
33 2013-11-04 00:31:52 <Luke-Jr> it's MS?
34 2013-11-04 00:31:56 <sipa> take it elsewhere before this becomes a flamewar
35 2013-11-04 00:31:57 <sipa> please
36 2013-11-04 00:32:04 <Luke-Jr> and as he just said, it doesn't have int64
37 2013-11-04 00:32:23 <Arnavion> Of course it does
38 2013-11-04 00:32:31 <Arnavion> What database doesn't have a 64-bit int
39 2013-11-04 00:32:38 <Luke-Jr> ekkis says MS SQL doesn't.
40 2013-11-04 00:33:24 <Arnavion> http://technet.microsoft.com/en-us/library/ms187745(v=sql.105).aspx
41 2013-11-04 00:33:31 <Arnavion> Notice first entry
42 2013-11-04 00:33:31 <sipa> can you take this to #mssql?
43 2013-11-04 00:33:35 <Arnavion> Sorry
44 2013-11-04 00:47:52 <ekkis> Luke-Jr: SQL Server is a natural extension of an MVC app written in .net
45 2013-11-04 00:48:48 <ekkis> Luke-Jr: no, what I said was it doesn't have an [unsigned] 64-bit int
46 2013-11-04 00:50:27 <ekkis> incidentally? I'm getting a (500) Internal Server Error from the server when I run it in test mode? and I don't see where logs are kept. thoughts anyone?
47 2013-11-04 00:50:55 <ekkis> incidentally, I'm not running bitcoind but bitcoin-qt...
48 2013-11-04 00:51:07 <ekkis> and it seemed to be working fine when I was running it in production mode
49 2013-11-04 00:51:55 <ekkis> I've changed the port to 18332 and the server seems to be answering but when I try to send coins I get that error
50 2013-11-04 00:53:45 <ekkis> ah? I figured it out? the error isn't very helpful but it's my bad
51 2013-11-04 00:55:19 <ekkis> whoa? it works. my first bitcoin payment. yea!!
52 2013-11-04 01:35:00 <Luke-Jr> ekkis: it doesn't need to be unsigned
53 2013-11-04 02:04:25 <gulli> Anyone developing in java have any experience in using url POST instead of JSONRPC to talk to bitcoind?
54 2013-11-04 02:07:08 <SomeoneWeird> gulli, ... i don't think you can
55 2013-11-04 02:09:00 <gulli> hmm
56 2013-11-04 02:09:02 <gulli> https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29
57 2013-11-04 02:09:02 <gulli> says here you can
58 2013-11-04 02:20:07 <gulli> This just seems so stupid, its so easy to find easy and good JSONRPC libraries for almost any common programming language except Java
59 2013-11-04 02:20:30 <gulli> If you want it for java its almost always a maven project with a billion dependecies
60 2013-11-04 03:02:57 <Luke-Jr> gavinandresen: unfortunately, that vulnerability seems to be a real possibility
61 2013-11-04 03:03:17 <gavinandresen> Luke-Jr: what vulnerability? selfish mining?
62 2013-11-04 03:03:45 <Luke-Jr> yes
63 2013-11-04 03:03:53 <Luke-Jr> also, don't we have a responsible disclosure page on bitcoin.org? :/
64 2013-11-04 03:04:16 <gavinandresen> mmm. I want to see what the bitcoin-wizards think when they wake up.
65 2013-11-04 03:05:03 <SomeoneWeird> which vuln is this?
66 2013-11-04 03:05:12 <Luke-Jr> http://arxiv.org/abs/1311.0243
67 2013-11-04 03:05:53 <warren> static const int PROTOCOL_VERSION = 70001;
68 2013-11-04 03:06:13 <warren> sizeof() of that int changes depending on 32bit or 64bit?
69 2013-11-04 03:06:24 <gavinandresen> The scheme smells like a version of the gambler's ruin "can't lose" scheme to me, too, but I haven't thought hard about it yet.
70 2013-11-04 03:06:27 <SomeoneWeird> Luke-Jr, interesting
71 2013-11-04 03:06:50 <gavinandresen> (martingale strategy for withholding blocks....)
72 2013-11-04 03:08:34 <Luke-Jr> gavinandresen: you're possibly right, but I think it needs more consideration before it's ruled out
73 2013-11-04 03:09:07 <gavinandresen> Luke-Jr: agreed. Although the hand-wavy "we'll just Sybil the network to keep the honest blocks from propagating" seems wrong
74 2013-11-04 03:09:15 <Luke-Jr> I guess I should check if anyone else got an advance disclosure privately, before I send the author a rant for not following responsible disclosure practices..
75 2013-11-04 03:09:39 <gavinandresen> Luke-Jr: ⦠given that pools/miners have a very strong incentive to be well-connected to each other
76 2013-11-04 03:09:47 <Luke-Jr> gavinandresen: well, they might not be able to sybil it, but they could certainly target big pools with their block broadcasts first
77 2013-11-04 03:10:10 <Luke-Jr> which, yeah, big miners already do for fair blocks
78 2013-11-04 03:10:13 <gavinandresen> Luke-Jr: right, but EVERYBODY wants to do that
79 2013-11-04 03:12:32 <Luke-Jr> even if this is successful, I'm not sure it's worth a hardfork to fix
80 2013-11-04 03:12:58 <Luke-Jr> eg, similar to the block withholding exploit, or even the centralised pool problem
81 2013-11-04 03:13:17 <gavinandresen> they didn't propose a hardfork to fix, just a simple policy change of "mine on random chain" instead of "mine on first-seen chain"
82 2013-11-04 03:13:34 <Luke-Jr> not sure that changes anything though
83 2013-11-04 03:13:40 <gavinandresen> they claim it does.
84 2013-11-04 03:13:45 <Luke-Jr> first-seen is already essentially random in a race
85 2013-11-04 03:13:59 <Luke-Jr> and if the good miners are interconnected, first-seen is *better* than random
86 2013-11-04 03:14:14 <gavinandresen> agreed. All of which is why I think they're just wrong.
87 2013-11-04 03:15:00 <BlueMatt> ACTION agrees with the "they're just wrong" sentiment
88 2013-11-04 03:15:21 <BlueMatt> though I do believe we should more actively encourage good peering for miners
89 2013-11-04 03:16:02 <BlueMatt> (which would take their argument's "maybe you have a small point" to "you're argument is invalid")
90 2013-11-04 03:16:05 <BlueMatt> at least the way I read it
91 2013-11-04 03:16:19 <gavinandresen> That was the most interesting result from the Decker/Wattenhofer paper on Information Propagation, in my opinion: they single-handedly cut the orphan rate in half by decreasing block propagationt hops
92 2013-11-04 03:16:44 <BlueMatt> agreed
93 2013-11-04 03:16:50 <gavinandresen> That's a trivial defense against a Sybil attack, too....
94 2013-11-04 03:16:59 <BlueMatt> yep
95 2013-11-04 03:17:08 <BlueMatt> is anyone actively working on this
96 2013-11-04 03:17:28 <BlueMatt> ACTION is very seriously considering taking up the project of setting up a peering network
97 2013-11-04 03:17:38 <BlueMatt> with merchant+mining peers/etc
98 2013-11-04 03:17:39 <gavinandresen> Dunno. Blockchain.info was connecting to everything last I heard....
99 2013-11-04 03:17:46 <BlueMatt> meh, thats not the point
100 2013-11-04 03:17:58 <warren> connecting and relaying?
101 2013-11-04 03:18:02 <warren> or just connecting?
102 2013-11-04 03:18:04 <gavinandresen> dunno
103 2013-11-04 03:18:09 <BlueMatt> one party connecting to all public nodes doesn't help, really
104 2013-11-04 03:18:19 <BlueMatt> when lots of merchants have nodes that only make outbound connections
105 2013-11-04 03:18:46 <BlueMatt> it may help pools that likely have listening nodes peered with their mining nodes, but still
106 2013-11-04 03:18:46 <warren> https://github.com/bitcoin/bitcoin/pull/3180 <---- btw, this commit supposedly reduces propagation latency and would help network-wide orphans too.
107 2013-11-04 03:18:59 <warren> it also makes headers first much faster
108 2013-11-04 03:20:13 <gavinandresen> Mmm. That reminds me, I wrote down a couple of potential TODOs after reading the Decker/Wattenhofer paperâ¦.
109 2013-11-04 03:20:49 <gavinandresen> I'll open issues before I forget again
110 2013-11-04 03:20:51 <BlueMatt> ACTION notes that the next foundation grant round wont be for a while and thinks about where to setup relaying nodes...
111 2013-11-04 03:21:49 <gavinandresen> BlueMatt: relaying inside the Amazon cloud would be nifty. Very cheap bandwidth from datacenter to datacenter last I looked....
112 2013-11-04 03:23:13 <warren> BlueMatt: I've been looking at the question of "how cheap can randomly placed, ultra-low power disablewallet relay node hardware be"
113 2013-11-04 03:25:14 <BlueMatt> warren: I was thinking bitcoind is overkill...my plan was to have one bitcoind which does message verification and then a bunch of leightweight relay nodes that do no verification once they've received the all-good from the verifier
114 2013-11-04 03:25:15 <warren> BlueMatt: headless ARM with enough RAM and storage to last several years, with bitcoind built to minimize disk churn to avoid wearing down the flash rewrite cycles
115 2013-11-04 03:25:35 <warren> eh.... centralized verification?
116 2013-11-04 03:25:40 <warren> sounds dangerous
117 2013-11-04 03:25:52 <BlueMatt> hardware requirements isnt the issue, you ideally want to minimize latency as much as possible and create nodes which can serve a shitton of clients with essentially no cpu
118 2013-11-04 03:26:10 <warren> after pruning happens, storage is a non-issue, then it's a matter of RAM for UTXO
119 2013-11-04 03:26:11 <BlueMatt> warren: well, all the peers do their own verification as well, but the relay network will do verification only once then relay to many
120 2013-11-04 03:26:57 <BlueMatt> ie the design I was thinking is: merchants/pool ops peer with some set of relay nodes. Those nodes just forward data around as much as possible after they have confirmed the data is good
121 2013-11-04 03:27:14 <BlueMatt> and then you get more relay nodes which are public and relay data around to anyone who wants to put an addnode in their conf
122 2013-11-04 03:27:19 <BlueMatt> (ie p2pool-style miners)
123 2013-11-04 03:28:23 <groglogic> gavinadresen: this one i assume? http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
124 2013-11-04 03:29:39 <jedunnigan> there is also http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf
125 2013-11-04 03:30:48 <warren> phantomcircuit: btw, rebase is requested on your PR
126 2013-11-04 03:32:17 <gavinandresen> groglogic: https://github.com/bitcoin/bitcoin/issues/3195
127 2013-11-04 03:34:15 <gavinandresen> jedunnigan: I've actually been working on better support for "snack machine payments" the last few days....
128 2013-11-04 03:34:33 <jedunnigan> gavinandresen: exciting!
129 2013-11-04 03:34:44 <gavinandresen> ⦠starting with tools that let me easily create -regtest-mode double-spends
130 2013-11-04 03:34:46 <jedunnigan> i remmeber you mentioning that on the mailing list a little while ago
131 2013-11-04 03:38:54 <BlueMatt> hah, someone on github cleverly registered with satoshi's email and is now listed as the 5th top contributor on http://bitcoin.org/en/development
132 2013-11-04 03:39:09 <BlueMatt> either that or saracen is satoshi and very seriously fucked up on the privacy front...
133 2013-11-04 03:41:20 <groglogic> gavinadresen: i see thanks. and i'll read that paper. been getting deeper into btc lately
134 2013-11-04 03:43:13 <groglogic> BlueMatt: i traced his posts. they're coming from an IP inside ... inside... (wait for it)... "nsa.gov" ? anybody know what that is? (kidding, kidding)
135 2013-11-04 03:45:54 <fanquake> https://github.com/bitcoin/bitcoin/commits?author=saracen Surely there would be more commits if he's taken over satoshi's alias on github? Or does GitHub's history cut off after 3 years
136 2013-11-04 03:46:36 <BlueMatt> thats cut off https://github.com/bitcoin/bitcoin/commits/master?page=134
137 2013-11-04 03:47:46 <phantomcircuit> BlueMatt, lol that's hilarious
138 2013-11-04 03:47:52 <fanquake> hmm, curious that it only lists those few commits.
139 2013-11-04 03:48:18 <phantomcircuit> warren, rebase against master or squash the commits?
140 2013-11-04 03:49:37 <fanquake> That contributing feature must only take into account a certain amount of history, https://github.com/bitcoin/bitcoin/commits?author=sirius-m gives nothing.
141 2013-11-04 04:16:32 <warren> phantomcircuit: looks like both
142 2013-11-04 04:26:06 <phantomcircuit> warren, uh i think i did that right
143 2013-11-04 04:26:08 <phantomcircuit> can you check
144 2013-11-04 04:29:51 <phantomcircuit> sipa, also yes