1 2013-06-07 00:52:12 <shesek> can Bitcoin's public/private keys be used for regular asymmetric message encryption?
2 2013-06-07 01:02:09 <zeusa1mighty> So maybe this is the wrong place, but I'm curious where Avalon's announcment of 10k chip buys was and what people think about the whole situation; They've got quite a few group buys buying chips and still haven't delivered all of the Avalon miners they've already sold. Why are so many jumping on the Avalon chip bandwagon without more vetting?
3 2013-06-07 01:03:58 <Luke-Jr> shesek: no
4 2013-06-07 01:19:17 <shesek> Luke-Jr, thanks
5 2013-06-07 01:19:40 <Luke-Jr> shesek: ECDSA only does signatures/verification, not encryption
6 2013-06-07 01:20:10 <shesek> I see.
7 2013-06-07 01:20:17 <shesek> is there a standard prefix for public keys?
8 2013-06-07 01:20:23 <shesek> that is, the non-hashed public keys
9 2013-06-07 01:20:35 <Luke-Jr> shesek: AFAIK they look entirely random
10 2013-06-07 01:21:32 <shesek> I mean the version byte
11 2013-06-07 01:21:39 <shesek> it seems like https://en.bitcoin.it/wiki/List_of_address_prefixes doesn't mention it
12 2013-06-07 01:21:43 <Luke-Jr> there is no encoding for raw public keys
13 2013-06-07 01:21:55 <shesek> and brainwallet/bitaddress use the hex representation
14 2013-06-07 01:22:01 <Luke-Jr> brainwallet = bad idea
15 2013-06-07 01:22:23 <shesek> you mean the concept or the website?
16 2013-06-07 01:22:48 <Luke-Jr> concept
17 2013-06-07 01:23:18 <Corndawg> I wonder if it's possible to build into the protocol a doublespend/transaction ratio for each bitcoin address
18 2013-06-07 01:23:33 <Luke-Jr> any passphrase created by a human will be easily cracked by a computer
19 2013-06-07 01:23:40 <Luke-Jr> Corndawg: it'd be useless
20 2013-06-07 01:23:49 <Corndawg> so a merchant could accept 0 confirms from addresses with so many transactions AND over a certain ratio
21 2013-06-07 01:23:49 <Luke-Jr> Corndawg: addresses are only good for 1 transaction
22 2013-06-07 01:24:05 <Luke-Jr> there are no such thing as "from addresses"
23 2013-06-07 01:24:11 <Luke-Jr> bitcoin transactions only have destination addresses, not source
24 2013-06-07 01:24:32 <Corndawg> hmm... whats then thing on the left side of blockchain.info
25 2013-06-07 01:24:44 <Luke-Jr> misinformation, ignore it
26 2013-06-07 01:24:49 <Corndawg> hmm
27 2013-06-07 01:24:54 <Luke-Jr> blockchain.info = good way to learn how Bitcoin does NOT work
28 2013-06-07 01:25:13 <Corndawg> ok well can it be attached to a pubkey then?
29 2013-06-07 01:25:17 <Corndawg> or priv key
30 2013-06-07 01:25:25 <Corndawg> or whatever... something
31 2013-06-07 01:25:45 <Luke-Jr> Corndawg: there is no personal identification in the blockchain
32 2013-06-07 01:25:50 <Corndawg> that a buyer could use to give his previous honest reputation to a vendor as assurance
33 2013-06-07 01:26:00 <Corndawg> only if he wants
34 2013-06-07 01:26:13 <Luke-Jr> Corndawg: identity systems like PGP might be useful
35 2013-06-07 01:26:22 <Luke-Jr> but there isn't one in Bitcoin (yet?)
36 2013-06-07 01:31:16 <Corndawg> just wondering what can fix one of the bigest prob I see in Bitcoin
37 2013-06-07 01:31:26 <Luke-Jr> Corndawg: what would that be?
38 2013-06-07 01:31:47 <Corndawg> lack of instant confirm for a system designed for two partys that dont trust each other
39 2013-06-07 01:31:53 <Corndawg> for PoS merch
40 2013-06-07 01:32:08 <Luke-Jr> Corndawg: well, it's far faster than any other system, so IMO not a big problem
41 2013-06-07 01:32:16 <Luke-Jr> there's the whole speed of light limit and all..
42 2013-06-07 01:32:18 <Corndawg> "oh wait 45 mins sir for your coffee... I need to wait until 6 confirms"
43 2013-06-07 01:32:24 <Corndawg> ;)
44 2013-06-07 01:32:27 <Luke-Jr> that'd be ridiculous
45 2013-06-07 01:32:30 <Corndawg> I agree
46 2013-06-07 01:32:39 <Luke-Jr> why would a coffee shop suddenly start waiting for transactions to confirm?
47 2013-06-07 01:32:50 <Luke-Jr> they accept credit cards and checks without waiting the 6 month confirmation time
48 2013-06-07 01:33:36 <Corndawg> but they trust credit card companies more than random customers I recon
49 2013-06-07 01:33:47 <Corndawg> they could always take the hit when lots of kids learn how easily they can double spend I guess
50 2013-06-07 01:33:52 <Luke-Jr> Corndawg: that doesn't make sense
51 2013-06-07 01:33:59 <Corndawg> or just not use bitcoin... I bit I know which choice they will make
52 2013-06-07 01:34:04 <Luke-Jr> it's easier to dispute a credit card transaction than to double-spend bitcoin
53 2013-06-07 01:34:25 <Corndawg> really... I'm told it's not
54 2013-06-07 01:34:33 <Luke-Jr> lol
55 2013-06-07 01:34:47 <Luke-Jr> you just mail in a form a few months later, they reverse the transaction
56 2013-06-07 01:34:56 <Luke-Jr> value is so low the merchants don't care to argue it
57 2013-06-07 01:35:02 <Corndawg> no I mean the doublespending
58 2013-06-07 01:35:09 <Corndawg> lots of people on redit seem to think doublespending is quite trivial
59 2013-06-07 01:35:28 <Luke-Jr> it's trivial .. if you have a lot of luck or connections, and tech skills???
60 2013-06-07 01:35:30 <Corndawg> I know not all of them are programmers but... you know otherwise?
61 2013-06-07 01:35:51 <Luke-Jr> I don't think a single person has ever successfully double-spent in a retail setting
62 2013-06-07 01:35:58 <Corndawg> only one needs tech skills to write the program...
63 2013-06-07 01:36:03 <Corndawg> like mixin services
64 2013-06-07 01:36:19 <Corndawg> pleny of ppl can use them without the skill or knowledge to understand
65 2013-06-07 01:36:33 <Corndawg> cause someone else who did wrote a program to give them that ability
66 2013-06-07 01:36:53 <Luke-Jr> you're forgetting the luck/connections aspect
67 2013-06-07 01:37:28 <Corndawg> the scariest thing I read lately on reddit is that someone said "the greatest danger bitcoin faces is the continual downplaying and ignoring of issues that have the potential to seriously undermind bitcoin"
68 2013-06-07 01:37:28 <Luke-Jr> unless you're a miner, you can't even attempt it really (assuming decent double-spend detection)
69 2013-06-07 01:37:38 <Corndawg> I'm starting to wonrder just how right they are ;)
70 2013-06-07 01:37:53 <Luke-Jr> reddit is 90% trolls
71 2013-06-07 01:37:55 <Luke-Jr> at least
72 2013-06-07 01:38:00 <Diablo-D3> not really
73 2013-06-07 01:38:10 <Corndawg> most of the trolls aren't really that thoughtful or intellegent
74 2013-06-07 01:38:18 <Corndawg> thye just insult someone and move on
75 2013-06-07 01:38:35 <Luke-Jr> Corndawg: the real issues get plenty of attention
76 2013-06-07 01:39:07 <Luke-Jr> not as much as we'd like (due to limited manpower), but they do get it
77 2013-06-07 01:39:18 <phantomcircuit> Luke-Jr, reddit isn't so much trolls as much as fools
78 2013-06-07 01:39:38 <Luke-Jr> phantomcircuit: maybe, I try to avoid it
79 2013-06-07 01:39:44 <Corndawg> well I hope your right...
80 2013-06-07 01:40:46 <Luke-Jr> Corndawg: most of Bitcoin's problems lie in scaling, security, and reputation
81 2013-06-07 01:41:15 <Corndawg> isn't this a security issue?
82 2013-06-07 01:41:19 <Corndawg> doublespending
83 2013-06-07 01:41:19 <phantomcircuit> Luke-Jr, a lot of the scaling issues are implementation problems
84 2013-06-07 01:41:26 <phantomcircuit> not fundamental to the protocol at all
85 2013-06-07 01:41:27 <Luke-Jr> Corndawg: no, the "issue" you bring up isn't a real issue.
86 2013-06-07 01:41:34 <warren> anyone else been playing with the Coin Control patch?
87 2013-06-07 01:41:48 <Luke-Jr> Corndawg: it's simple risk management for businesses, but they're more empowered than they were with prior transaction systems
88 2013-06-07 01:41:58 <Luke-Jr> warren: I use (and older version of it) all the time
89 2013-06-07 01:43:12 <Corndawg> they are certainly empowered to make their choice... only as long as DS is less than percentage cost of CC will they have made the right one
90 2013-06-07 01:43:28 <warren> Luke-Jr: tried it in combination with https://github.com/bitcoin/bitcoin/pull/2651 ?
91 2013-06-07 01:44:32 <Luke-Jr> warren: no
92 2013-06-07 01:47:32 <Luke-Jr> Corndawg: it costs over 25 BTC to even *attempt* an undetectable double spend - nobody is going to risk it on coffee
93 2013-06-07 01:48:22 <phantomcircuit> Luke-Jr, i suspect the vast majority of systems do not handle even detectable double spends correctly
94 2013-06-07 01:48:31 <phantomcircuit> and just assume they dont happen
95 2013-06-07 01:48:47 <warren> (including exchanges)
96 2013-06-07 01:49:08 <phantomcircuit> intersango for one *does* handle it
97 2013-06-07 01:49:24 <phantomcircuit> that being said it does so in a comically overzealous way
98 2013-06-07 01:49:27 <phantomcircuit> but it works
99 2013-06-07 01:49:35 <phantomcircuit> lock all the things and sort it out later
100 2013-06-07 01:50:15 <shesek> Luke-Jr, why does it cost that?
101 2013-06-07 01:50:22 <Luke-Jr> shesek: you need to find a block in secret
102 2013-06-07 01:50:37 <jchp> i'm curious whether the altcoin exchanges have doublespend detection, because that could potentially be a massive clusterfuck
103 2013-06-07 01:51:02 <warren> shesek: you find a block and withhold broadcast
104 2013-06-07 01:51:12 <shesek> if he mines a block without his payment and successfully and it gets into the blockchain, he still gets the 25 BTC
105 2013-06-07 01:52:21 <jchp> i believe Luke-Jr was referring to a 1-confirm doublespend, not an unconfirmed doublespend
106 2013-06-07 01:52:24 <phantomcircuit> jchp, i doubt it...
107 2013-06-07 01:52:42 <Luke-Jr> jchp: no, 1-confirm doublespend is even more risky
108 2013-06-07 01:52:56 <warren> you need to withhold two blocks ...
109 2013-06-07 01:53:54 <jchp> why does it cost 25BTC for an unconfirmed doublespend then? i'm confused
110 2013-06-07 01:54:16 <Luke-Jr> jchp: for an UNDETECTABLE unconfirmed doublespend
111 2013-06-07 01:54:24 <jchp> oh missed that part
112 2013-06-07 01:55:30 <phantomcircuit> i actually accept 1 confirms for momentovps.com
113 2013-06-07 01:55:47 <phantomcircuit> just under the principle of nobody is going to try that hard to steal so little
114 2013-06-07 01:56:36 <jchp> also that's a service that can be revoked if anyone is crazy/stupid enough to try it
115 2013-06-07 01:56:46 <phantomcircuit> jchp, exactly
116 2013-06-07 01:56:56 <phantomcircuit> that's not automated but it does send me an email
117 2013-06-07 01:57:04 <jchp> how is dealing with hosting using bitcoin as payment?
118 2013-06-07 01:57:06 <phantomcircuit> which of course i have never actually gotten
119 2013-06-07 01:57:13 <jchp> seems like a hassle in terms of customer base
120 2013-06-07 01:57:32 <Luke-Jr> phantomcircuit: have you tested it? :>
121 2013-06-07 01:57:56 <phantomcircuit> jchp, the only complaints i've received from my host (OVH) were about port scans of universities in the middle east
122 2013-06-07 01:58:02 <phantomcircuit> saudi arabia and iran
123 2013-06-07 01:58:13 <phantomcircuit> which was weird but whatever i just suspended their account and moved on
124 2013-06-07 01:58:21 <Luke-Jr> ???
125 2013-06-07 01:58:23 <phantomcircuit> they didn't even complain about their account being suspended
126 2013-06-07 01:58:30 <Luke-Jr> as if there's something malicious about port scans'
127 2013-06-07 01:58:32 <phantomcircuit> so i assume they expected that
128 2013-06-07 01:59:16 <phantomcircuit> Luke-Jr, i personally dont care and i dont see why ovh cares
129 2013-06-07 01:59:17 <jchp> interesting, i've always assumed worse that's good haha
130 2013-06-07 01:59:31 <phantomcircuit> but in the interest of keeping services running i just suspend whenever there's a complaint
131 2013-06-07 01:59:56 <phantomcircuit> jchp, i honestly couldn't tell you since a substantial portion of users encrypt their disks
132 2013-06-07 02:01:08 <jchp> heh that actually makes things easier for you as a provider
133 2013-06-07 02:01:37 <phantomcircuit> jchp, ironically it's actually just born out of lazyness
134 2013-06-07 02:01:42 <phantomcircuit> i dont provide disk images at all
135 2013-06-07 02:01:50 <phantomcircuit> you install from an iso image over vnc
136 2013-06-07 02:02:01 <phantomcircuit> that happens to prompt you to encrypt the disk if you install ubuntu
137 2013-06-07 02:02:04 <phantomcircuit> which most people do
138 2013-06-07 02:02:14 <phantomcircuit> i suspect they just get to that point shrug and say why not
139 2013-06-07 02:03:17 <phantomcircuit> jchp, riding my lazyness to market advantage since mid 2012 ish
140 2013-06-07 02:03:47 <jchp> makes sense haha, if i need more VPS for webhosting i'll sign up to try it out
141 2013-06-07 02:04:32 <phantomcircuit> jchp, lol i recently fixed a few issues people randomly ran into and added capacity
142 2013-06-07 02:04:53 <phantomcircuit> there's now a script which actively probes to identify vms in trouble and restarts them
143 2013-06-07 02:05:15 <phantomcircuit> and other minor things like the support system actually sends emails now instead of just saying it did
144 2013-06-07 02:05:37 <phantomcircuit> the biggest problem remains libvirtd
145 2013-06-07 02:05:43 <phantomcircuit> if anything is even slightly wrong
146 2013-06-07 02:05:48 <phantomcircuit> it locks up completely
147 2013-06-07 02:05:58 <jchp> could be worse, it could be running openvz's hilariously buggy/outdated kernels
148 2013-06-07 02:06:04 <phantomcircuit> but i am pretty much always here
149 2013-06-07 02:06:16 <phantomcircuit> and when i fix problems i do my best to fix them permanently
150 2013-06-07 02:06:28 <phantomcircuit> (ie im lazy and dont want to have to keep fixing them!)
151 2013-06-07 02:06:41 <phantomcircuit> jchp, openvz is hilarious
152 2013-06-07 02:07:01 <phantomcircuit> so many providers are running kernels with public clean lpe
153 2013-06-07 02:07:23 <jchp> and i bet a lot of bitcoin businesses run VPSes on openvz and don't realize it
154 2013-06-07 02:07:23 <Luke-Jr> OpenVZ would be awesome if not for the bugs -.-
155 2013-06-07 02:07:38 <phantomcircuit> jchp, yeah i think they do
156 2013-06-07 02:08:25 <phantomcircuit> jchp, anyways a few highlights for momentovps if you ever do try it out, disks are independent of servers, disks are actually ceph rados block devices
157 2013-06-07 02:08:40 <phantomcircuit> which are mirrored across at least 2 hosts
158 2013-06-07 02:09:03 <jchp> oh that's a fun way to do things
159 2013-06-07 02:09:03 <phantomcircuit> ip addresses are assigned to a tagged vlan
160 2013-06-07 02:09:25 <phantomcircuit> so i can move a "server" from one host to another rapidly
161 2013-06-07 02:09:29 <phantomcircuit> it just copies memory
162 2013-06-07 02:10:04 <phantomcircuit> usually that takes ages since the disk image has to be copied over the network first
163 2013-06-07 02:10:22 <phantomcircuit> jchp, it's pretty fast actually
164 2013-06-07 02:10:38 <phantomcircuit> anyways
165 2013-06-07 02:10:41 <jchp> very interesting, i'll check it out later, i need to go get some food, laters!
166 2013-06-07 02:11:01 <phantomcircuit> yeah ima go try to sleep
167 2013-06-07 03:10:11 <SomeoneWeird> can you get raw block info from rpc ?
168 2013-06-07 03:10:44 <Luke-Jr> SomeoneWeird: no :/
169 2013-06-07 03:10:54 <SomeoneWeird> lol that's lame
170 2013-06-07 03:11:11 <Luke-Jr> indeed
171 2013-06-07 03:11:18 <SomeoneWeird> fix it
172 2013-06-07 03:11:18 <SomeoneWeird> :P
173 2013-06-07 03:11:20 <Luke-Jr> but nobody can be bothered to write it I guess
174 2013-06-07 03:11:25 <Luke-Jr> SomeoneWeird: putting a bounty on it? :P
175 2013-06-07 03:11:44 <Luke-Jr> seriously, it's probably like 15 mins of code I think?
176 2013-06-07 03:11:50 <Luke-Jr> at most
177 2013-06-07 03:13:20 <SomeoneWeird> how much would it take? :P
178 2013-06-07 03:13:30 <sivu> 1btc per min of coding
179 2013-06-07 03:13:38 <SomeoneWeird> lol
180 2013-06-07 03:13:39 <Luke-Jr> dunno, I'm probably about to do it anyway just because people keep wanting it <.<
181 2013-06-07 03:13:47 <Luke-Jr> so any bounty is pretty much a bonus lol
182 2013-06-07 03:14:43 <SomeoneWeird> well i have .1btc on my laptop because i'm not at home so you can have that :p
183 2013-06-07 03:18:41 <Luke-Jr> SomeoneWeird: you testing it? :P
184 2013-06-07 03:19:12 <SomeoneWeird> i can try
185 2013-06-07 03:19:14 <SomeoneWeird> :p
186 2013-06-07 03:27:27 <Luke-Jr> SomeoneWeird: https://github.com/bitcoin/bitcoin/pull/2747
187 2013-06-07 03:27:46 <Luke-Jr> looks like my time estimate was just about right O.o
188 2013-06-07 03:27:56 <Luke-Jr> except for the review/merging part XD
189 2013-06-07 03:29:11 <Luke-Jr> I went ahead and tested it too btw
190 2013-06-07 03:30:04 <SomeoneWeird> awesome
191 2013-06-07 03:33:52 <petertodd> Luke-Jr: nice, how easy is sendrawblock?
192 2013-06-07 03:37:13 <Luke-Jr> petertodd: erm, what? you mean submitblock? XD
193 2013-06-07 03:37:46 <petertodd> Luke-Jr: oh, did you just make that too?
194 2013-06-07 03:38:02 <Luke-Jr> petertodd: no, it's a standard part of GBT ;)
195 2013-06-07 03:39:08 <petertodd> Luke-Jr: oh it is too... I never realized submitblock was a raw block...
196 2013-06-07 03:42:22 <petertodd> If it wasn't so late here I'd throw together a Amazon SNS block distributor thing
197 2013-06-07 04:00:41 <SomeoneWeird> Luke-Jr, http://pastie.org/private/wigevuympepqm0ccpgttyg
198 2013-06-07 04:00:52 <SomeoneWeird> am I doing that right/
199 2013-06-07 04:01:16 <Luke-Jr> SomeoneWeird: you want 0
200 2013-06-07 04:01:30 <SomeoneWeird> ahhh
201 2013-06-07 04:01:32 <SomeoneWeird> awesome
202 2013-06-07 04:19:33 <sipa> midnightmagic: no offence, but maybe you didn't dig very deep. I once spent _hours_ trying to figure out how the hell the 'spent' flag in wallets remained up to date, eventually finding that when a script was verified (from the block validation code in maij, calling scripts's eval function), script called the wallet (which was also in main.cpp) to mark the corresponding output spent if it matched a known key
203 2013-06-07 04:20:07 <Diablo-D3> sipa: thaaaats kinda ugly
204 2013-06-07 04:21:40 <sipa> midnightmagic: i think satoshi's code was more "intricate": doing more unexpected things in a few lines of unrelated code
205 2013-06-07 04:22:17 <sipa> i think the corebase now more clearly shows how complex it is (though it's still terribly badly modularized)
206 2013-06-07 05:30:17 <maaku_> ultraprune question: if I need access to tx db in CreateTransaction, can I just create a CCoinsViewCache view(*pcoinsTip, true) ?
207 2013-06-07 05:32:20 <sipa> you can just use pcoinsTip directly
208 2013-06-07 05:32:33 <sipa> but that sounds very ugly
209 2013-06-07 05:32:53 <sipa> why do you need that?
210 2013-06-07 05:33:50 <maaku_> I've modified GetMinFee to request a storage-fee based on the age and size (bytes) of the inputs
211 2013-06-07 05:34:12 <maaku_> so naturally, it now takes CCoinsViewCache& mapInputs as an argument, and that needs to be passed from CreateTransaction()
212 2013-06-07 05:35:11 <sipa> why age?
213 2013-06-07 05:36:04 <sipa> also, whatever you're doing, SPV clients won't be able to do that
214 2013-06-07 05:36:57 <maaku_> the idea is to make the fee based on utxo size over time
215 2013-06-07 05:37:19 <sipa> you mean multiplied by time?
216 2013-06-07 05:37:26 <maaku_> and SPV clients will have access, because you only need access to the inputs of the transaction you are creating
217 2013-06-07 05:37:58 <sipa> so you should use wallet information, not UTXO data
218 2013-06-07 05:38:31 <maaku_> (1 - rate) ^ ((nOutputBytes / 1000.0)*(nHeightDelta))
219 2013-06-07 05:40:02 <maaku_> it's a compounding fee based on the age and size of the input
220 2013-06-07 05:40:33 <maaku_> and no, the calculation is in GetMinFee not the wallet (it's just that GetMinFee is called by the wallet code)
221 2013-06-07 05:41:18 <sipa> ok, so make GetMinFee just take age and size of input coins as argument, so you can call it from the wallet without access to UTXO
222 2013-06-07 05:42:00 <sipa> imho any wallet code depending on the prrsence of utxo data is broken as it will make turning the wallet code into spv harder
223 2013-06-07 05:42:22 <maaku_> ? it doesn't rely on utxo data, just wallet transactions
224 2013-06-07 05:42:47 <maaku_> but only in the context of the wallet making a new transaction
225 2013-06-07 05:43:12 <maaku_> when deciding whether to accept or relay, it needs utxo data
226 2013-06-07 05:43:13 <wallet43> does a medium client needs more that all block headers and complete utxo set?
227 2013-06-07 05:43:26 <sipa> what is a medium client?
228 2013-06-07 05:43:33 <wallet43> not a full node
229 2013-06-07 05:43:40 <wallet43> with pruned blockchain etc...
230 2013-06-07 05:44:10 <sipa> maaku_: you say passing pcoinsTip or a view on top of it to GetMinFee in CreateTransaction, you rely on the presence of utxo data
231 2013-06-07 05:44:11 <wallet43> able to verify all tx and maybee create the next block
232 2013-06-07 05:44:28 <sipa> wallet43: pruning is not relevant for all that
233 2013-06-07 05:45:01 <sipa> pruning ia juat about whether or not to keep and store historical blocks
234 2013-06-07 05:45:06 <sipa> is just
235 2013-06-07 05:45:10 <wallet43> i just wonder how big the blockchain was if it onlt contains future "relevant" data
236 2013-06-07 05:45:14 <maaku_> sipa: if there were a pseudo-view that just looked up wallet transactions instead of utxo, i could pass that instead from the wallet code
237 2013-06-07 05:45:30 <sipa> maaku_: that sounds possible yes
238 2013-06-07 05:45:31 <maaku_> maybe it's a good idea to write such a class, but I'm doing this on a lark :)
239 2013-06-07 05:45:55 <sipa> wallet43: that is not the blockchain, but the utxo set
240 2013-06-07 05:46:06 <sipa> wallet43: check the size of your chainstate directory
241 2013-06-07 05:46:11 <wallet43> yes
242 2013-06-07 05:46:12 <wallet43> 270
243 2013-06-07 05:46:30 <wallet43> which is a lot smaller that 9700
244 2013-06-07 05:47:00 <sipa> yes
245 2013-06-07 05:47:02 <wallet43> my question is, would the 270 be enough once you verified all blocks up to the last one
246 2013-06-07 05:47:08 <sipa> sure
247 2013-06-07 05:47:21 <sipa> that's exactly what it is
248 2013-06-07 05:47:21 <wallet43> cool :)
249 2013-06-07 05:47:30 <sipa> the data needed to do block validation
250 2013-06-07 05:48:48 <maaku_> anyone have some spare testnet coins? mhQbdEwScZ2LGyYmEAjAXsd65vCR86zymp
251 2013-06-07 06:08:05 <wump> maaku_: https://tpfaucet.appspot.com/ :)
252 2013-06-07 06:14:47 <warren> "// A typical txout is 33 bytes big, and will"
253 2013-06-07 06:14:53 <warren> are typical inputs 33 bytes too?
254 2013-06-07 06:20:31 <wumpus> inputs are larger, wouldn't know how large on average by heart though
255 2013-06-07 06:22:51 <sipa> 72 bytes for a signature, 33-65 for a pubkey, 2 pushes, 1 byte length record
256 2013-06-07 06:30:34 <midnightmagic> sipa: Everything I looked for before, I found, from why my bitcoind had a sticky proxy server setting (wallet.dat) to some assumptions that were made re: hex strings when tracking down a namecoind bug, to successfully modifying payouts in a mined block without tests and with a single modification on a whim one day, to adding a dozen custom rpc commands to set or unset stuff that satoshi designed originally to be immutable; but
257 2013-06-07 06:30:40 <midnightmagic> these days tracking down bits of wallet code, or even changing a version string, requires six to ten patches in multiple files in multiple locations, and my patches no longer work on the first try. I'm *always* missing some piece that depends on some other piece that depends on some other piece somewhere else. Note: This is a failing on my part, not anyone else's. Satoshi's coding style just seemed to click in my head more
258 2013-06-07 06:30:46 <midnightmagic> easily. I know TD was complaining once about a weird bitwise shift that Satoshi used to index .. a heap was it? that's the sort of thing I'm talking about. That all makes sense to me. I never looked into the scripting language, I never looked into the reorg or even the retarget code, but for the stuff I was working on, in my experience I am no longer able to make successful, longer-lived patches with as much ease as I used to.
259 2013-06-07 06:30:58 <midnightmagic> woops, i'm really sorry about the multi-line spam that was longer than I thought
260 2013-06-07 06:34:06 <SomeoneWeird> lol
261 2013-06-07 06:35:17 <sipa> midnightmagic: interesting, i'm biased of course because i know the code very well now, and didn't back then
262 2013-06-07 06:37:06 <midnightmagic> sipa: I'm certainly not complaining. I'm glad things are easier for you guys now. Since when have I ever submitted a pull request right. :)
263 2013-06-07 06:37:58 <sipa> well, more easily accessible code is in everyone's interest
264 2013-06-07 06:40:25 <mhanne> hm, i'm confused by the block exchange mechanism.. AFAIU https://bitcointalk.org/index.php?topic=41729.0 after getting a batch of inv's, the syncing node should receive the chain head, which will cause it to send a 'getblocks' again because it's an orphan..
265 2013-06-07 06:40:46 <mhanne> but that only seems to work once; if the syncing node has the orphan already, it won't send a getblocks again
266 2013-06-07 06:43:14 <mhanne> if i send it the 2nd block of the next batch instead of the chain head, it keeps syncing.. with the chain head, it stops after 1000 blocks
267 2013-06-07 06:44:07 <sipa> there are many weirdnesses in the block sync mechanism
268 2013-06-07 06:44:35 <sipa> the "request parents of orphan when received" mechanism is mostly to make sure you keep up with small new updates
269 2013-06-07 06:44:45 <sipa> there's a initial sync that's separate from that
270 2013-06-07 06:45:22 <sipa> and i hope we can get rid of the whole thing soon with headers-first sync
271 2013-06-07 06:45:48 <midnightmagic> ooo that sounds cool
272 2013-06-07 06:45:54 <mhanne> ah ok.. i'm talking about initial sync yes
273 2013-06-07 06:46:20 <sipa> mhanne: it's know (unfortunately) that initial sync gets easily confused when a true new block is announced
274 2013-06-07 06:46:26 <sipa> but the whole thing is a mess
275 2013-06-07 06:47:00 <warren> Bitcoin allows zero value txo's, and they remain as utxo's because they can be spent, we could get rid of them from memory in a hardfork if we wanted ... true?
276 2013-06-07 06:47:12 <sipa> warren: just a softfork
277 2013-06-07 06:47:17 <warren> oh?
278 2013-06-07 06:47:29 <sipa> just make 0-outputs unspendable
279 2013-06-07 06:47:40 <mhanne> well the text says that it's supposed to ask for an update directly when it receives an orphan block it already has.. maybe that got broken at some point?
280 2013-06-07 06:47:43 <petertodd> warren: really easy, do a p2sh like flag in the coinbase, and miners don't mine such txs once 95% vote
281 2013-06-07 06:47:44 <warren> oh, softfork that relies on miner majority
282 2013-06-07 06:48:04 <petertodd> warren: it's what I was going to say in my reply to your email, among other things :)
283 2013-06-07 06:48:24 <mhanne> do you see any problem with just sending it a 'new' orphan every time?
284 2013-06-07 06:48:24 <sipa> mhanne: afaik that still works perfectly
285 2013-06-07 06:48:47 <sipa> mhanne: start an unsynced node, don't send out initial getblocks
286 2013-06-07 06:48:55 <sipa> it will start syncing when the first new block is announced
287 2013-06-07 06:48:56 <sipa> afaik
288 2013-06-07 06:49:04 <sipa> if it doesn't work, there's a bug
289 2013-06-07 06:49:16 <warren> We've assumed that 0-value txo's have no purpose, but what if you *intend* to give away money to a random person, for say moral reasons?
290 2013-06-07 06:49:29 <sipa> warren: 0-value != money
291 2013-06-07 06:49:52 <petertodd> warren: You want provably unspendable with the OP_RETURN mechanism to give away mining fees.
292 2013-06-07 06:50:07 <petertodd> warren: Or anyone-can-spend with OP_TRUE
293 2013-06-07 06:50:14 <mhanne> sipa: i'm trying to sync a bitcoind from my bitcoin-ruby node.. bitcoind does send a getblocks at first, i send it 500 inv's + 1 for the head, bitcoind fetches the blocks, asks for getblocks again. but repeat that, and it won't send a getblocks again
294 2013-06-07 06:51:16 <sipa> mhanne: i'm not surprised that it'd get stuck if you do things slightly differently
295 2013-06-07 06:51:23 <sipa> mhanne: it all depends on hacks to work
296 2013-06-07 06:51:50 <mhanne> heh ok. then i'll just do my own hack as well :)
297 2013-06-07 06:53:34 <coblee> hey sipa and petertodd. Did warren already ask this? Can we do multiple inputs, 0 outputs transactions that gives all the coins in the inputs away as miner fees? Would that pollute the memory pool?
298 2013-06-07 06:54:07 <sipa> without provably-unspendable outputs, that's hard
299 2013-06-07 06:54:20 <petertodd> coblee: Zero outputs doesn't work with bitcoin, just use provably unspendable.
300 2013-06-07 06:54:35 <sipa> i assume he means "one 0-value output"
301 2013-06-07 06:54:52 <petertodd> Ah, yeah provably unspendable 0-value output.
302 2013-06-07 06:55:09 <coblee> so just an OP_RETURN and it won't be added to the memory pool right?
303 2013-06-07 06:55:10 <warren> sipa: we're going to hardfork and make the rules whatever is ideal
304 2013-06-07 06:55:26 <petertodd> coblee: you mean the UTXO set?
305 2013-06-07 06:55:31 <coblee> petertodd: yes
306 2013-06-07 06:55:44 <petertodd> coblee: Currently the code will add it to the set, but changing that is trivial in the future.
307 2013-06-07 06:55:46 <warren> petertodd: wait for e-mail, he'll describe the new proposal
308 2013-06-07 06:55:49 <sipa> heh if you hardfork you may just as well allow no-output transactions...
309 2013-06-07 06:56:01 <coblee> sipa: a bit hard
310 2013-06-07 06:56:03 <warren> sipa: any drawbacks to that?
311 2013-06-07 06:56:11 <coblee> we are not hard forking by a certain date
312 2013-06-07 06:56:11 <sipa> why is that hard?
313 2013-06-07 06:56:17 <sipa> ?
314 2013-06-07 06:56:29 <petertodd> sipa: I dunno... I'm inclined to keep compatibility with Bitcoin code given how little difference there is between no outputs and provably unspendable.
315 2013-06-07 06:56:30 <coblee> we are hard forking when with a specific transaction that's not previously allowed to clear out the dust spam
316 2013-06-07 06:56:46 <coblee> yeah, probably unspendable is good enough for us
317 2013-06-07 06:56:51 <coblee> provably
318 2013-06-07 06:56:58 <sipa> ok, so have a boolean that remembers whether you've passed that transaction
319 2013-06-07 06:57:04 <sipa> and when that is set, allow no-outputs
320 2013-06-07 06:57:26 <warren> petertodd: with this particular proposal we would need *many* wasteful tx's just to get rid of all the UTXO's, so whatever design allows for smallest tx in byte size would be nice.
321 2013-06-07 06:57:44 <warren> petertodd: and if there's no drawback to allowing no-output transactions, then that sounds good.
322 2013-06-07 06:58:15 <petertodd> warren: Right, so you're generating a tx, to spend the dust spam?
323 2013-06-07 06:58:23 <sipa> dang, you're in such a luxury position that you can choose whatever rule you want (that's not socially unacceptable), and all you'd do is that? :)
324 2013-06-07 06:58:27 <warren> petertodd: well, it's a proposal, that he didn't write yet.
325 2013-06-07 06:58:38 <TheUni> sipa: branch updated to reflect your comments from the other day, and PR sent. thanks again for having a look
326 2013-06-07 06:58:53 <sipa> TheUni: btw, you have several GPL .m4 files?
327 2013-06-07 06:58:54 <coblee> petertodd: yes. the gist is that any 1-satoshi output can be spent by the genesis key
328 2013-06-07 06:59:02 <coblee> with 0 fees
329 2013-06-07 06:59:09 <TheUni> sipa: they have exceptions, the resulting binaries aren't gpl'd
330 2013-06-07 06:59:27 <warren> sipa: we're open to suggestions, seriously. want to test stuff here? as long as you think it's good and it agrees with the anti-spam goal, we can seriously consider it.
331 2013-06-07 06:59:29 <petertodd> warren: I'd be inclined to use the soft-fork mechanism myself. Just say outputs <= 1 satoshi are unspendable from now on. That means when UTXO pruning is added, they're provably unspendable so they don't need to be added to the set.
332 2013-06-07 06:59:46 <warren> petertodd: ooh....
333 2013-06-07 06:59:49 <sipa> TheUni: you're still distributing them together with the bitcoin source, which imposes restrictions on bitcoin, afaik?
334 2013-06-07 06:59:55 <TheUni> m4s are scripts that write scripts, so in general license isn't much of a concern because they're not part of what's distributed
335 2013-06-07 06:59:56 <sipa> TheUni: (i'm no expert by any means)
336 2013-06-07 06:59:56 <warren> petertodd: then we don't need to pollute the blockchain with useless tx's
337 2013-06-07 07:00:06 <petertodd> warren: Exactly
338 2013-06-07 07:00:10 <sipa> TheUni: they become part of the bitcoin source?
339 2013-06-07 07:00:11 <warren> coblee: ^^^
340 2013-06-07 07:00:18 <coblee> warren: let me think
341 2013-06-07 07:00:30 <warren> petertodd: omgwtfbbq
342 2013-06-07 07:00:41 <coblee> petertodd: what's the ETA for UTXO pruning?
343 2013-06-07 07:01:00 <TheUni> sipa: there are no additional restrictions on source distribution
344 2013-06-07 07:01:02 <petertodd> coblee: Ask sipa, I don't actually write code. :P
345 2013-06-07 07:01:16 <sipa> coblee: it's one line of code that someone has to write :)
346 2013-06-07 07:01:31 <sipa> may be part of jgarzik's recent PR, unsure
347 2013-06-07 07:01:40 <petertodd> The real issue is how to distribute data, because that gets you very close to not all nodes having the full chain...
348 2013-06-07 07:01:47 <coblee> petertodd, warren: so we'd say 1-satoshi outputs are unspendable after a certain date. the same date we set for the BDB possible fork
349 2013-06-07 07:01:59 <petertodd> coblee: Don't do it by date, do it by coinbase vote.
350 2013-06-07 07:02:12 <sipa> TheUni: i'd like to hear other people's opinion about that first, though
351 2013-06-07 07:02:16 <sipa> TheUni: but you may be right
352 2013-06-07 07:02:19 <coblee> petertodd: ok
353 2013-06-07 07:02:30 <petertodd> coblee: The thing with BDB possible fork, is as Bitcoin has shown, when that kicks in is very unpredictable. (we still haven't forked)
354 2013-06-07 07:02:30 <warren> petertodd: litecoin has almost zero vendors, so very few people are running customized clients
355 2013-06-07 07:02:31 <coblee> just like the v2
356 2013-06-07 07:02:53 <petertodd> coblee: Yes, actually the v2 change is the better example... you can probably use that exact bit of code.
357 2013-06-07 07:03:16 <petertodd> warren: You guys have it easy
358 2013-06-07 07:03:17 <warren> petertodd: we had to turn off the v2 lockin because pool software has been making v2 for a while now and we aren't sure they're all real.
359 2013-06-07 07:03:31 <coblee> we will just make it v3 :)
360 2013-06-07 07:03:38 <petertodd> warren: sheesh...
361 2013-06-07 07:03:40 <warren> coblee: pools will screw it up
362 2013-06-07 07:04:03 <coblee> petertodd: we get to learn from our big brother bitcoin :)
363 2013-06-07 07:04:24 <petertodd> coblee: heh, and if you guys actually do something interesting, Bitcoin gets to learn from you...
364 2013-06-07 07:04:42 <warren> petertodd: we could use suggestions on something better than 95%... that already triggered many times without any clients that actually create v2.
365 2013-06-07 07:05:11 <petertodd> warren: Are people just using Bitcoin code badly modified for litecoin?
366 2013-06-07 07:05:16 <warren> petertodd: hahahaha
367 2013-06-07 07:05:22 <warren> ACTION finds URL.
368 2013-06-07 07:05:27 <coblee> pretty much
369 2013-06-07 07:05:34 <petertodd> warren: I hear litecoin mainly gets mined by p2pool...
370 2013-06-07 07:05:42 <petertodd> warren: ...often by botnets.
371 2013-06-07 07:07:35 <sipa> TheUni: for the test sources, can you do something like test_bitcoin_SOURCES = test/*_tests.cpp test/test_bitcoin.cpp $(TEST_DATA_FILES) ?
372 2013-06-07 07:07:44 <coblee> sipa: a more technical question. how would i mark an output as unspendable so that it would be picked up by UTXO pruning? i mean i could add some code to reject those transactions, but it will be a special case.
373 2013-06-07 07:08:19 <petertodd> coblee: Bitcoin has decided to use OP_RETURN at the beginning of the scriptPubKey for that.
374 2013-06-07 07:08:32 <sipa> coblee: there is no such thing "utxo pruning" except just not storing it by detecting it's provably unspendable
375 2013-06-07 07:08:42 <sipa> at the time it would be added
376 2013-06-07 07:09:32 <coblee> ok, so just making sure. nothing i would still need to prune this myself later on since i can't code it generally so that it would be picked by bitcoin's code for free
377 2013-06-07 07:10:30 <petertodd> coblee: Yeah, try to follow the same standards on stuff like that so code can work with both, including client-side.
378 2013-06-07 07:11:02 <warren> petertodd: p2pool has always been ~5% of litecoin's hash rate, and I recently discovered a major problem in p2pool, forrestv is fixing it and there is a new hardfork coming soon.
379 2013-06-07 07:11:04 <warren> petertodd: I'll explain this later.
380 2013-06-07 07:11:10 <TheUni> sipa: nope, no wildcards
381 2013-06-07 07:11:16 <sipa> TheUni: :(
382 2013-06-07 07:11:41 <petertodd> warren: OK, mention to forrestv to use OP_RETURN at the beginning of the p2pool blockchian hash...
383 2013-06-07 07:11:41 <TheUni> sipa: trust me, it'd look a lot different if wildcards could be used :)
384 2013-06-07 07:12:08 <coblee> ok thanks guys (petertodd and sipa), we will look into doing this: soft fork with 1-satoshi outpus unspendable and with v2-like lockin
385 2013-06-07 07:12:23 <warren> petertodd: err, what for?
386 2013-06-07 07:13:04 <sipa> coblee: what is special about 1 satoshi transactions?
387 2013-06-07 07:13:13 <sipa> i mean: why not 0 satishi?
388 2013-06-07 07:13:33 <petertodd> warren: Because currently p2pool makes a spendable, but zero-value, transaction in every block.
389 2013-06-07 07:13:54 <warren> coblee: Litecoin has 12M spam UTXO of 1-satoshi out of 13M current UTXO, from giant floods in the early days that were stopped by the anti-spam rules.
390 2013-06-07 07:14:03 <petertodd> sipa: it's to combat a specific spam problem, but yeah, the rule should be <= 1 satoshi
391 2013-06-07 07:14:06 <sipa> ah
392 2013-06-07 07:14:27 <coblee> petertodd: yup, got it. <=1 satoshi
393 2013-06-07 07:14:39 <petertodd> Well, with the exception that == 0 satoshi is allowed iff it's a provably unspendable OP_RETURN scriptPubKey.
394 2013-06-07 07:23:29 <sipa> TheUni: any reason why the Qt .o files are prefixed with libbitcoinqt_a- ?
395 2013-06-07 07:23:34 <sipa> (and the others aren't)
396 2013-06-07 07:23:41 <sipa> just a question
397 2013-06-07 07:23:59 <TheUni> sipa: it builds an intermediary libbitcoinqt.a
398 2013-06-07 07:24:37 <sipa> TheUni: yes, but the others also build an intermediary libbitcoind.a
399 2013-06-07 07:24:46 <TheUni> sipa: hmm, you'd think the others would be prefixed too though
400 2013-06-07 07:24:46 <TheUni> yea
401 2013-06-07 07:25:38 <sipa> (and this is pure bikeshedding) calling it libbitcoinD.a is confusing, because it contains objects that are not specific to bitcoind
402 2013-06-07 07:26:47 <TheUni> sipa: yep, fair point. that's leftover from before i actually had a game-plan
403 2013-06-07 07:27:04 <TheUni> will fix
404 2013-06-07 07:29:25 <TheUni> sipa: envision anyone complaining about the new test_bitcoin-qt binary?
405 2013-06-07 07:29:31 <TheUni> afaik that wasn't built before?
406 2013-06-07 07:29:59 <sipa> TheUni: no problem doing that
407 2013-06-07 07:30:01 <sipa> (imho)
408 2013-06-07 07:30:03 <wumpus> TheUni: why complain about that, it's the qt unit tests
409 2013-06-07 07:31:19 <TheUni> wumpus: in general i didn't want to change any current behavior, to avoid needless bikeshedding
410 2013-06-07 07:31:23 <wumpus> they should be built, that they're usually not built is a problem to be complained about :)
411 2013-06-07 07:31:34 <TheUni> but that one seemed like a no-brainer to me
412 2013-06-07 07:31:40 <sipa> yeah, it is
413 2013-06-07 07:32:00 <sipa> i really like that one make command now builds everything
414 2013-06-07 07:32:07 <wumpus> so far no comments on your changes
415 2013-06-07 07:32:10 <TheUni> ok, good
416 2013-06-07 07:32:36 <TheUni> wumpus: it's only been there for 30min :)
417 2013-06-07 07:32:47 <wumpus> yes but I'm reading them right now...
418 2013-06-07 07:33:22 <TheUni> wumpus: oh, sorry. i thought you meant nobody had commented yet (for better or worse)
419 2013-06-07 07:34:28 <TheUni> wumpus: the configure is absolutely hideous, but i can defend it pretty well i think. mingw kinda throws a wrench in things
420 2013-06-07 07:35:08 <wumpus> I'm looking mainly at code changes; all automake stuff looks hideous to me, so that's all the same, if it works in all envisioned scenarios that's good enough
421 2013-06-07 07:35:12 <TheUni> it can be tidied up a bunch once we make a few changes to the deps to tuck them into an organized prefix
422 2013-06-07 07:35:33 <TheUni> ah, ok
423 2013-06-07 07:36:07 <TheUni> well if there's a single code change that makes an impact, i'm happy to revert or reevaluate. those changes should be nops.
424 2013-06-07 07:36:20 <wumpus> one thing I wonder (haven't tested yet), do out-of-tree builds work?
425 2013-06-07 07:36:26 <TheUni> yes
426 2013-06-07 07:36:28 <TheUni> make distcheck
427 2013-06-07 07:36:29 <wumpus> cool
428 2013-06-07 07:37:07 <TheUni> however, in practice, they won't work enough to be useful
429 2013-06-07 07:37:16 <wumpus> how do you mean?
430 2013-06-07 07:37:21 <TheUni> because of leveldb
431 2013-06-07 07:37:55 <wumpus> oh, right, leveldb ignores that, it's the same with qmake out of tree builds currently
432 2013-06-07 07:38:10 <TheUni> out-of-tree build has to copy leveldb into dest, and build it there
433 2013-06-07 07:38:34 <wumpus> ha, yes, that's a solution
434 2013-06-07 07:38:48 <TheUni> that's the hack i added for make dist, anyway
435 2013-06-07 07:39:16 <TheUni> https://github.com/bitcoin/bitcoin/pull/2748/files#L1R244
436 2013-06-07 07:40:01 <TheUni> leveldb is another one i'd like to address, but one thing at a time :)
437 2013-06-07 07:41:01 <sipa> TheUni: how are inline dependencies usually dealt with?
438 2013-06-07 07:41:10 <sipa> you configure/build them separately?
439 2013-06-07 07:41:27 <TheUni> sipa: you mean like leveldb?
440 2013-06-07 07:41:30 <sipa> yes
441 2013-06-07 07:41:52 <sipa> well, i suppose in a way libbitcoind.a right now can be considered an inline dependency as well
442 2013-06-07 07:42:04 <wumpus> they're usually dealt by having the configure script call the inline dependency's configure script, at least that's what I've found
443 2013-06-07 07:42:09 <sipa> ok
444 2013-06-07 07:42:19 <TheUni> sure, but the difference is that we're unaware of what's going on with leveldb
445 2013-06-07 07:42:39 <sipa> well not unaware, we control the source code completely
446 2013-06-07 07:42:41 <TheUni> so the dependency tracking is busted, it's all or nothing
447 2013-06-07 07:42:51 <sipa> but we prefer to keep it in a state where upstream merges are easy
448 2013-06-07 07:43:04 <TheUni> sipa: sure, not a complaint, just stating how it is
449 2013-06-07 07:43:32 <TheUni> wumpus: yes, that is reasonably common when a dependency is autotool'd
450 2013-06-07 07:43:51 <TheUni> autoconf has support for configuring a sub-configure
451 2013-06-07 07:44:03 <TheUni> mainly it depends on the size of the project and how tight the integration is
452 2013-06-07 07:44:23 <sipa> TheUni: mostly asking because of my libsecp256k1
453 2013-06-07 07:44:44 <sipa> though that won't be integrated into bitcoin too soon anyway
454 2013-06-07 07:44:48 <TheUni> sipa: sec, let me take a look at your configure
455 2013-06-07 07:45:33 <TheUni> looks like it's just a few tests for yasm/openssl/gmp ?
456 2013-06-07 07:45:45 <sipa> yeah
457 2013-06-07 07:46:02 <sipa> and some logic to decide which field/scalar implementation to use based on it
458 2013-06-07 07:46:06 <TheUni> do you want it integrated with bitcoin? or you want to maintain an upstream for it?
459 2013-06-07 07:46:35 <sipa> i assume there'll be interest in it outside of bitcoin, so i like keeping it standalone (at least for now)
460 2013-06-07 07:47:20 <sipa> but to integrate with bitcoin, i'd put it in a subdirectory like leveldb i guess
461 2013-06-07 07:47:24 <sipa> (git subtree)
462 2013-06-07 07:47:40 <wumpus> yes, just an optional dependency with configure flag would be great for now
463 2013-06-07 07:47:46 <TheUni> ok. well i'm happy to do up a quick buildsystem if you'd like, and get it into debian pretty quickly i'd think
464 2013-06-07 07:48:21 <sipa> it needs big disclaimers for now :)
465 2013-06-07 07:48:26 <TheUni> heh
466 2013-06-07 07:48:36 <TheUni> well, i will have one precondition
467 2013-06-07 07:48:51 <sipa> which is?
468 2013-06-07 07:49:08 <warren> sipa: want us to ship secp256k1 by default? =)
469 2013-06-07 07:49:30 <TheUni> ah nm, looks like i read your configure wrong
470 2013-06-07 07:49:46 <TheUni> i thought you were doing a run-test of your yasm output
471 2013-06-07 07:50:19 <sipa> no, i attempt to link it with C code using to, to make sure there are name mangling/calling convention issues
472 2013-06-07 07:50:30 <sipa> but that was when the code was C++; i don't think that's even useful anymore
473 2013-06-07 07:50:55 <warren> sipa: Can bitcoin have both openssl and secp256k1 simultaneously, where one can validate the other? (wouldn't work for things that require random inputs, of course)
474 2013-06-07 07:50:57 <TheUni> yep, got it
475 2013-06-07 07:51:29 <sipa> warren: there are unit tests that compare openssl with secp256k1
476 2013-06-07 07:51:40 <sipa> (sign with one, verify using the other)
477 2013-06-07 07:52:05 <sipa> having bitcoin verify using both would be useful, but maybe overkill
478 2013-06-07 07:52:06 <warren> sipa: I meant, production nodes can run with *both*, and it can log instances where secp256k1 disagrees with openssl, to keep an eye out for bugs.
479 2013-06-07 07:52:43 <warren> it would be slow, but it wouldn't risk the node
480 2013-06-07 07:54:03 <TheUni> sipa: the code is portable?
481 2013-06-07 07:54:18 <sipa> TheUni: define portable?
482 2013-06-07 07:54:29 <sipa> i have only tested it on i386/x86_64
483 2013-06-07 07:54:33 <sipa> and linux
484 2013-06-07 07:54:36 <warren> I managed to build secp256k1 win32 binaries but I haven't tried running them
485 2013-06-07 07:54:42 <TheUni> heh
486 2013-06-07 07:54:52 <warren> gitian win32 secp256k1
487 2013-06-07 07:55:08 <TheUni> do you assume little endian? hand-written x86 asm? assume a compiler or libc?
488 2013-06-07 07:55:24 <TheUni> i'm just trying to assess any drawbacks on that front
489 2013-06-07 07:55:29 <sipa> i assume no endianness (though that isn't tested)
490 2013-06-07 07:55:43 <sipa> there is hand-written x86_64 assembly, but its use is optional
491 2013-06-07 07:56:17 <sipa> and you need either GMP or OpenSSL (for now)
492 2013-06-07 07:57:12 <sipa> the int128 field implementation requires a __int128 type, which probably means recent gcc or clang on 64-bit system, but that's optional too
493 2013-06-07 07:58:52 <sipa> a 16-bit OS will probably not work :D
494 2013-06-07 07:59:52 <TheUni> heh
495 2013-06-07 08:05:40 <sipa> TheUni: have to go; in any case, thanks for your offer; i'd appreciate a nice build system for it, but it's by no means urgent
496 2013-06-07 08:05:52 <TheUni> sipa: builds for android, fwiw
497 2013-06-07 08:06:03 <sipa> oh wow
498 2013-06-07 08:06:14 <sipa> using openssl backend?
499 2013-06-07 08:06:20 <TheUni> yea
500 2013-06-07 08:06:42 <sipa> tests work?
501 2013-06-07 08:07:12 <TheUni> umm, i can test if you can hold 5min
502 2013-06-07 08:07:20 <sipa> in an emulator?
503 2013-06-07 08:07:25 <TheUni> no
504 2013-06-07 08:07:41 <sipa> i'm curious how long the benchmark takes!
505 2013-06-07 08:08:57 <sipa> what hardware?
506 2013-06-07 08:08:57 <TheUni> running
507 2013-06-07 08:09:05 <TheUni> how long does it take on desktop?
508 2013-06-07 08:09:11 <sipa> around 2 minuts
509 2013-06-07 08:09:23 <sipa> it does 1M signature verifications
510 2013-06-07 08:09:54 <TheUni> hmm
511 2013-06-07 08:10:08 <TheUni> 0m41.10s real 0m40.89s user 0m0.03s system
512 2013-06-07 08:10:08 <TheUni> root@android:/sbin # time ./secp256k1
513 2013-06-07 08:10:08 <TheUni> test count = 100
514 2013-06-07 08:10:33 <sipa> ah, that's the unit tests, not the benchmark
515 2013-06-07 08:10:41 <sipa> make bench
516 2013-06-07 08:10:44 <TheUni> oh, thought they were the same thing
517 2013-06-07 08:10:57 <TheUni> well i'm kinda having to hand-craft your makefiles :p
518 2013-06-07 08:11:14 <sipa> right :)
519 2013-06-07 08:11:41 <sipa> in any case, on a desktop on 32-bit using openssl it will probably already be closer to 10 minutes
520 2013-06-07 08:12:01 <sipa> so it may be worth reducing the iteration count before testing
521 2013-06-07 08:12:07 <sipa> but i have to go, thanks for your help!
522 2013-06-07 08:12:15 <TheUni> running
523 2013-06-07 08:12:17 <sipa> (for both bitcoin and secp256k1)
524 2013-06-07 08:12:24 <TheUni> np, cya
525 2013-06-07 08:49:20 <melvster> james joyce said that money was 'solidified energy' ... does bitcoin fulfill that prophecy?
526 2013-06-07 08:58:47 <TheUni> sipa: for backlog: 33m54.57s real
527 2013-06-07 08:59:07 <runeks> What could cause this error?
528 2013-06-07 08:59:08 <runeks> runCommand error: system(/home/ubuntu/ASICMiner/asicminer.py --client 00000000000000a5a8f2d9a3c4b4c29e6c4b71e6acd4be90cff73fb7c55dbf9c) returned -1
529 2013-06-07 08:59:27 <runeks> does system() return the return value of the executed script?
530 2013-06-07 09:01:24 <runeks> I see that a return value of -1 for system() means it couldn't execute the program (for whatever reason).
531 2013-06-07 09:03:36 <sipa> TheUni: what hardware?
532 2013-06-07 09:05:13 <TheUni> sipa: dual cortex a9 at 1.2ghz
533 2013-06-07 09:05:42 <sipa> is that 32-bit or 64-bit?
534 2013-06-07 09:06:06 <runeks> 32-bit
535 2013-06-07 09:06:11 <sipa> still, pretty good actually: that means 0.2ms per verification
536 2013-06-07 09:06:21 <TheUni> 32. aarch64 isn't really in the wild yet
537 2013-06-07 09:06:51 <sipa> actually, i think on my own system in 32-bit (which is an i7 at 3.16GHz) mode, it's over 0.4ms
538 2013-06-07 09:07:28 <sipa> runeks: yes
539 2013-06-07 09:07:53 <TheUni> sipa: also worth noting i didn't tweak at all (neon mainly)
540 2013-06-07 09:07:57 <runeks> sipa: Yes to what?
541 2013-06-07 09:08:03 <sipa> runeks: system returns the exit code
542 2013-06-07 09:08:30 <runeks> sipa: But my program doesn't return -1 :\\ only 0 or 1
543 2013-06-07 09:09:08 <sipa> runeks: it can also return error codes resulting from failure to execute in the first place (like not finding the binary, or some shell error)
544 2013-06-07 09:09:37 <runeks> "The return value is -1 if it wasn't possible to create the shell process, and otherwise is the status of the shell process."
545 2013-06-07 09:10:14 <runeks> sipa: The strange this is that it worked fine for blocks up to 240013. And then in the middle of it all it starting failing for all subsequent blocks. Running the command manually for the block in question works fine.
546 2013-06-07 09:10:28 <runeks> s/this/thing
547 2013-06-07 09:15:01 <runeks> I'm also getting a lot of these error messages in my debug.log:
548 2013-06-07 09:15:03 <runeks> ERROR: CTxMemPool::accept() : nonstandard transaction type
549 2013-06-07 09:15:20 <runeks> 31234 of these in total in debug.log
550 2013-06-07 09:17:19 <sipa> runeks: that's the new dust filtering
551 2013-06-07 09:17:50 <runeks> sipa: Oh, ok. That's benign then.
552 2013-06-07 09:20:14 <runeks> Are the "Non-canonical signature: R value negative" messages from old clients? IIRC it's because of some non-standard OpenSSL handling of signature formats.
553 2013-06-07 09:20:38 <sipa> we don't know who keeps producing them
554 2013-06-07 09:21:29 <sipa> certainly not any bitcoind/bitcoin-qt/wxbitcoin, bitcoinj/multibit/android wallet, and no recent armory or bitcoin-js either
555 2013-06-07 09:23:29 <runeks> Odd
556 2013-06-07 09:24:17 <sipa> i've mailed and posted about it before
557 2013-06-07 09:25:57 <TD> it looked like it might have been an old bitcoinjs?
558 2013-06-07 09:26:08 <TD> the iPhone app is, iirc, un-updatable because ben is afraid of triggering a rereview by apple
559 2013-06-07 09:26:29 <TD> although if we're breaking the app with the canonical-sig changes anyway, iPhone users may soon lose the ability to run a soft-side wallet outside the browser.
560 2013-06-07 09:27:01 <sipa> oh, i didn't know there was a real iphone app in the first place
561 2013-06-07 09:27:21 <sipa> all i knew was that bitcoinjs at some point made non-canonical sigs, but that that was fixed >1y ago
562 2013-06-07 09:28:21 <sipa> i've mailed ben personally about the non-canonical sigs, to ask if he could help finding clients that created them - so he should be aware of the problem - though he didn't answer
563 2013-06-07 09:29:06 <tgs3> I was thinking of making really secure linux, most secure up to date, and providing it with preinstalled bitcoind. thoughts?
564 2013-06-07 09:31:28 <CodeShark> I really hope in the future the security of bitcoind relies more on the p2p network enforcing the rules and moving all private key storage off to isolated modules that just do signing
565 2013-06-07 09:32:25 <CodeShark> and that wallets move away from this single enduser client model to an enterprise policy definition model, where signatures are required to perform specific operations
566 2013-06-07 09:32:37 <CodeShark> one or more signatures
567 2013-06-07 09:33:18 <CodeShark> and the protocol supports proposing transactions and having signers authorize them
568 2013-06-07 09:34:06 <CodeShark> a monolithic bitcoind that does everything, including the wallet, is just not the way to go :)
569 2013-06-07 09:35:12 <CodeShark> we should really encourage people to run validation/relay nodes on as many different platforms as possible
570 2013-06-07 09:35:29 <CodeShark> to make it hard for a single attack vector to take out a significant chunk of the network
571 2013-06-07 09:37:51 <CodeShark> we might also want to look into strengthening support for a transport layer that can manage port renegotiations or even tunneling through HTTP connections to make it difficult to shut down
572 2013-06-07 09:38:31 <CodeShark> and let's move all signing off the validation/relay hubs
573 2013-06-07 09:39:59 <sipa> ACTION proposes RFC 1149
574 2013-06-07 09:42:24 <CodeShark> lol
575 2013-06-07 09:46:42 <CodeShark> RFC 1149 could work with high density storage :)
576 2013-06-07 09:47:41 <CodeShark> stick the entire UTXO set and last known block on there :)
577 2013-06-07 09:48:56 <TD> sipa: yeah ben is never responsive
578 2013-06-07 09:49:14 <TD> sipa: he spends all his time writing code, i think ..... but i think this is the most likely explanation. the iPhone app has a >1year old copy of bitcoinjs and cannot be changed.
579 2013-06-07 09:49:18 <TD> because of how screwed up apple is
580 2013-06-07 09:51:06 <sipa> TD: he was resoonsive before about the same issue (a year ago), and about other things
581 2013-06-07 09:53:35 <CodeShark> has ben disappeared?
582 2013-06-07 09:54:21 <jouke> isn't it a problem that there is still wallet software out there that will create dust outputs?
583 2013-06-07 09:54:50 <tgs3> CodeShark: that is good point. that can give good isolation. 1 program is p2p node, other program does the calculation, other is store of cold wallets
584 2013-06-07 09:56:01 <CodeShark> tgs3: yes - and I'd also like to see a protocol layer where you can propose transactions and request signatures from other nodes
585 2013-06-07 09:56:32 <tgs3> though my work regarding secure linux focuses on the system,
586 2013-06-07 09:56:34 <CodeShark> so transactions can be initiated anywhere and signed anywhere else
587 2013-06-07 09:56:44 <tgs3> but it should make it easier to isolate communication, with rules like
588 2013-06-07 09:56:58 <tgs3> bitcoind can only write into /dev/shm/transactions-to-sign
589 2013-06-07 09:57:08 <tgs3> and only bitcoind-p2pnode can read that file
590 2013-06-07 09:57:32 <CodeShark> can't hurt to also have stuff like that
591 2013-06-07 09:57:50 <tgs3> it's for case of exploit in the program or system or system lib
592 2013-06-07 09:57:53 <warren> <CodeShark> [01:33:37] to make it hard for a single attack vector to take out a significant chunk of the network <----- Sounds like accidental forks will be easy.
593 2013-06-07 09:59:07 <CodeShark> warren: that is a potential problem - but as long as the majority of nodes (and in particular mining nodes) continue to behave in a similar fashion, what that will really mean in practice is if you're running a minority node you'll have to either patch it or run a different program immediately
594 2013-06-07 09:59:59 <CodeShark> I also would recommend that mining nodes use more than one validation engine, at least two different implementations of bitcoin
595 2013-06-07 10:00:25 <CodeShark> this idea has been brought up before - I'd like to see it actually become standard practice
596 2013-06-07 10:00:38 <warren> CodeShark: the network-based testing needs to be used more. don't know to what extent fuzzing is possible on the network protocol. Might need to hire people dedicated to improving the automated tests.
597 2013-06-07 10:01:07 <warren> CodeShark: wouldn't that hurt them due to increased chance of orphans?
598 2013-06-07 10:01:31 <warren> CodeShark: it is the miner's goal to win the race and broadcast their block as quickly as possible
599 2013-06-07 10:01:51 <CodeShark> warren: it's a balance between that risk...and the risk that they end up on a minority fork
600 2013-06-07 10:02:35 <CodeShark> besides, validation can be done in parallel
601 2013-06-07 10:02:46 <warren> This is similar to my suggestion of running both openssl and secp256k1 on production nodes to keep an eye out for bugs in the latter, except there is a real cost to the miners.
602 2013-06-07 10:03:23 <warren> Miners don't do what's safe. they do what seems-to-work until it no longer works.
603 2013-06-07 10:03:34 <lianj> not only to miners
604 2013-06-07 10:04:21 <BlueMatt> ;;later tell Goonie_ I keep getting "Transaction did not deserialize completely: ..." when restarting testnet wallet app after killing it
605 2013-06-07 10:04:21 <gribble> The operation succeeded.
606 2013-06-07 10:05:04 <CodeShark> the greatest risk, as far as forks, is if a minority miner still has majority hashing power
607 2013-06-07 10:05:42 <CodeShark> minority implementation, that is
608 2013-06-07 10:05:52 <warren> well, undesired implementation
609 2013-06-07 10:06:24 <warren> CodeShark: as we learned from March 12th, don't worry! We can 51% our own network thanks to centralization.
610 2013-06-07 10:06:29 <CodeShark> haha
611 2013-06-07 10:07:16 <CodeShark> there was much irony in that event
612 2013-06-07 10:08:09 <CodeShark> it was a deliberate 51% attack using the older, buggy implementation
613 2013-06-07 10:08:23 <warren> (the above statement was sarcastic, with a tinge of fear)
614 2013-06-07 10:10:37 <CodeShark> are you saying we shouldn't rely on just calling slush up and telling him to run a different validation engine? :P
615 2013-06-07 10:11:35 <warren> CodeShark: sounds like a great plan
616 2013-06-07 10:12:33 <CodeShark> if only there were a way to directly reward miners for using more than one implementation
617 2013-06-07 10:14:12 <CodeShark> not sure that could be done in the protocol itself
618 2013-06-07 10:14:39 <CodeShark> could be done if maintainers of different implementations are willing to pay out rewards to miners who find discrepancies in behavior between their implementation and others
619 2013-06-07 10:15:08 <sipa> afaik that already exists: once there are (unknown whether compatible) validation engines on the network, miners have all incentive to verify their blocks against multiple
620 2013-06-07 10:15:12 <CodeShark> at least in cases where the behavior is reproducible
621 2013-06-07 10:15:44 <CodeShark> in which case it's easy to prove a particular block causes a fork but might be very hard to find an example
622 2013-06-07 10:16:07 <warren> Question ... if you found the rare block, what disincentive is there to delay broadcasting it since it is so rare? You're either on the winning or losing fork.
623 2013-06-07 10:16:44 <warren> just saying anything that causes delay miners won't do
624 2013-06-07 10:16:57 <warren> since their incentive to mine is driven by greed
625 2013-06-07 10:17:01 <CodeShark> perhaps we need a few more forks to motivate them, then :Lp
626 2013-06-07 10:17:27 <CodeShark> once a miner has ended up on the losing fork a couple times, perhaps they will consider it worth the tiny extra cost of running a second machine
627 2013-06-07 10:17:37 <warren> you're also suggesting they shouldn't broadcast a block, in which case the network may never know about the vulnerability
628 2013-06-07 10:18:23 <CodeShark> they SHOULD broadcast it - but perhaps with a flag of some sort
629 2013-06-07 10:18:49 <warren> This might work as incentive: a bounty for finding blocks that break different validation engines.
630 2013-06-07 10:18:50 <CodeShark> or at the very least they should send it to the maintainers of the implementations they are using
631 2013-06-07 10:19:04 <warren> Make the incentive more than the block they would lose.
632 2013-06-07 10:19:07 <CodeShark> that might be better in some circumstances
633 2013-06-07 10:20:05 <CodeShark> the coinbase transaction makes it easy to determine where the bounty goes
634 2013-06-07 10:21:02 <warren> how do you fairly fund the bounty?
635 2013-06-07 10:21:51 <CodeShark> seems like that would be up to the maintainers of the different implementations
636 2013-06-07 10:22:10 <CodeShark> and whatever donations/investors/trust fund money they can get :p
637 2013-06-07 10:23:15 <CodeShark> it also gives incentive to the maintainers of implementations to test for discrepancies before they are discovered by others
638 2013-06-07 10:25:33 <CodeShark> the full reward only needs to be paid to miners who would have otherwise mined a main chain block
639 2013-06-07 10:26:08 <warren> "main chain block" is already true
640 2013-06-07 10:26:30 <CodeShark> discrepancies can also be discovered by turning off proof-of-work validation
641 2013-06-07 10:26:50 <CodeShark> what's it called - I know there's a name for all this :p
642 2013-06-07 10:27:46 <warren> https://github.com/viperaus/stratum-mining/pull/4
643 2013-06-07 10:27:49 <warren> ACTION facepalm
644 2013-06-07 10:29:28 <CodeShark> anyhow, yes - lower difficulty shares could pay out lower rewards
645 2013-06-07 10:30:05 <warren> Not exactly what you were talking about, but "turning off proof-of-work validation" is almost what existed in the scrypt pools.
646 2013-06-07 10:31:41 <warren> // Free transaction area
647 2013-06-07 10:31:41 <warren> if (nNewBlockSize < 27000)
648 2013-06-07 10:31:41 <warren> nMinFee = 0;
649 2013-06-07 10:31:47 <warren> btw, how was 27000 chosen?
650 2013-06-07 10:32:05 <BlueMatt> because gavin likes the number 11?
651 2013-06-07 10:32:27 <SomeoneWeird> gavin loves the number 11
652 2013-06-07 10:33:00 <warren> so, no reason
653 2013-06-07 10:33:14 <CodeShark> lol - the number 11?
654 2013-06-07 10:33:21 <sipa> my guess is that's historical
655 2013-06-07 10:36:56 <Subo1978> hi, i have "walletversion" : 59900 ond windows. how should i upgrade it to 60000
656 2013-06-07 10:44:44 <kapiteined> is http://bitcoin.sipa.be dead?
657 2013-06-07 10:47:44 <sipa> no?
658 2013-06-07 10:49:38 <TD> it's slow to load but works for me
659 2013-06-07 10:49:49 <TD> that's quite an impressive recent jump
660 2013-06-07 10:50:32 <jgarzik> Yah. Wonder who has come online.
661 2013-06-07 10:50:50 <jgarzik> BFL finally shipping (or mining themselves)? New ASICMINER? Av batch 2? Other?
662 2013-06-07 10:51:45 <kapiteined> hmm.. it is over here. it seems to be some DNS issue.
663 2013-06-07 10:54:39 <TD> probably all of them together
664 2013-06-07 10:55:30 <Diablo-D3> jgarzik: all the asicminer sticks are out there now
665 2013-06-07 11:01:46 <SomeoneWeird> http://andrewkelley.me/post/jamulator.html
666 2013-06-07 11:02:23 <jgarzik> SomeoneWeird, cool
667 2013-06-07 11:02:35 <SomeoneWeird> /crazy/
668 2013-06-07 11:03:35 <jgarzik> SomeoneWeird, if you can JIT Java bytecodes, you can JIT anything, including non-native binaries
669 2013-06-07 11:04:05 <jgarzik> CPUs just haven't been fast enough to manage it in the past. I remember Kaffe, how slow it was on modern CPUs of the day (15 years ago).
670 2013-06-07 11:04:34 <SomeoneWeird> yeah i know
671 2013-06-07 11:04:36 <SomeoneWeird> still crazy
672 2013-06-07 12:20:31 <SomeoneWeird> is there a wiki page for the protocol? (p2p stuff)?
673 2013-06-07 12:21:00 <SomeoneWeird> er ok nvm
674 2013-06-07 12:50:36 <enigmuriatic1> what delimits blocks in the blockchain? in other words, if i only wanted the header of each block what regular expression or pattern would i use?
675 2013-06-07 12:53:47 <tonikt> enigmuriatic1: you mean the .dat files in the database storage folder?
676 2013-06-07 12:54:46 <enigmuriatic1> tonikt, yeah
677 2013-06-07 12:54:51 <enigmuriatic1> that's the blockchain, correct?
678 2013-06-07 12:55:08 <tonikt> eh, sort of :)
679 2013-06-07 12:55:25 <tonikt> the copy of the blockchain is there - yes
680 2013-06-07 12:55:34 <sipa> that's a bunch of files containing a concatenation of blocks serialized in network format
681 2013-06-07 12:55:43 <sipa> it's technically more a block tree than a block chain
682 2013-06-07 12:55:59 <sipa> as it does not contain information about which chain through the tree is currently considered active/best
683 2013-06-07 12:56:34 <enigmuriatic1> sipa, so it stores blocks that aren't used?
684 2013-06-07 12:56:44 <enigmuriatic1> blocks that the client considers invalid?
685 2013-06-07 12:56:51 <tonikt> as sipa said. and the format inde the dat file is: F9 BE B4 D9 followed by 4 bytes of block length, follow by the block - and repeat until you reach EOF
686 2013-06-07 12:56:56 <sipa> you mistake "invalid" for "inactive"
687 2013-06-07 12:57:03 <sipa> it does not contain invalid blocks
688 2013-06-07 12:57:07 <enigmuriatic1> that complicates things, for sure
689 2013-06-07 12:57:26 <enigmuriatic1> what's the typical method for parsing out the active ones?
690 2013-06-07 12:57:41 <sipa> you ask bitcoind?
691 2013-06-07 12:57:50 <tonikt> you need to build a tree in a memory
692 2013-06-07 12:57:58 <sipa> you can't parse that, it's just stored in a different dataset
693 2013-06-07 12:58:08 <tonikt> you cannot do it with a regexp/ pattern matching
694 2013-06-07 12:58:23 <sipa> blocks themself do not know whether they're active, obviously
695 2013-06-07 12:58:34 <enigmuriatic1> i understand that
696 2013-06-07 12:58:42 <sipa> what are you trying to do?
697 2013-06-07 12:58:47 <enigmuriatic1> sipa, what other dataset is it stored in
698 2013-06-07 12:59:25 <enigmuriatic1> i'm trying to write a blockchain parsing tool for research, sipa. one that can easily get every transaction from a blockchain and store it in a sqlite database.
699 2013-06-07 12:59:44 <enigmuriatic1> that gives the full transaction history of the market, which can then be used for research
700 2013-06-07 13:00:36 <enigmuriatic1> there was one C++ command line parser I came across but it was slow to the point of being unusable at a large scale, and there wasn't a direct command used to get all transactions
701 2013-06-07 13:06:10 <sipa> enigmuriatic1: enable txindex=1 and you can look up any transaction/block just using bitcoind RPCs
702 2013-06-07 13:06:53 <enigmuriatic1> sipa, i'm not sure what you mean by that
703 2013-06-07 13:07:12 <sipa> getblock <blockhash> gives you a block
704 2013-06-07 13:07:22 <sipa> getrawtransaction <txid> gives you a transaction
705 2013-06-07 13:08:06 <enigmuriatic1> sipa, where am i making these commands?
706 2013-06-07 13:08:22 <sipa> either using bitcoind, having it function as a JSON-RPC client
707 2013-06-07 13:08:30 <sipa> or using whatever programming language that supports JSON-RPC
708 2013-06-07 13:09:07 <enigmuriatic1> how would that be speed-wise?
709 2013-06-07 13:09:34 <sipa> bitcoind isn't particularly fast in handling with RPC calls
710 2013-06-07 13:11:57 <enigmuriatic1> sipa, that may be the problem
711 2013-06-07 13:12:05 <tonikt> it surely will be faster than sqlite
712 2013-06-07 13:12:17 <enigmuriatic1> if i'm dealing with transactions in the hundreds of millions it's going to be a bottleneck
713 2013-06-07 13:12:29 <enigmuriatic1> tonikt, the alternative is just saving them all in a text file
714 2013-06-07 13:12:35 <jgarzik> some people turn to redis or mongodb
715 2013-06-07 13:13:04 <enigmuriatic1> jgarzik, that might be a good idea. i wouldn't know though, as i've never learned thing 1 about non-SQL database tech
716 2013-06-07 13:18:14 <enigmuriatic1> tonikt, sipa, it looks like bitcoind is more of a personal parsing tool
717 2013-06-07 13:18:19 <enigmuriatic1> for personal accounts etc