1 2013-05-09 00:00:12 <sipa> ;;bc,blocks
2 2013-05-09 00:00:13 <gribble> 235239
3 2013-05-09 00:04:07 <zooko> "Note: I spent several hours trying, and failing, to create unit tests for this patch" ???
4 2013-05-09 00:04:21 <sipa> ACTION 's fault
5 2013-05-09 00:09:05 <zooko>
6 2013-05-09 00:09:05 <zooko> sipa: why?
7 2013-05-09 00:09:35 <sipa> zooko: when I wrote CWallet, I never tested whether an instance without backing database file would work
8 2013-05-09 00:09:43 <zooko> ACTION nods.
9 2013-05-09 00:09:53 <zooko> We could write "unit tests" which provide a backing db file...
10 2013-05-09 00:11:33 <tumak> wei_: i'm using bitcoinjs for that
11 2013-05-09 00:13:44 <wei_> tumak: is there a monitoring example?
12 2013-05-09 00:13:45 <sipa> gmaxwell: have fun: http://bitcoin.sipa.be/pruning.txt
13 2013-05-09 00:14:09 <sipa> (height, timestamp, unspent outputs, total outputs, unspent output size, all outputs sie)
14 2013-05-09 00:14:18 <zooko> Where is the code that determines which candidate transactions get put into a block that a miner is working on?
15 2013-05-09 00:14:48 <sipa> zooko: CreateNewBlock, main.cpp
16 2013-05-09 00:14:51 <zooko> Thanks!
17 2013-05-09 00:15:00 <tumak> wei_: yes, for webclient. i guess you want to do that from nodejs though?
18 2013-05-09 00:15:43 <wei_> yes
19 2013-05-09 00:16:03 <wei_> thanks for the tip though
20 2013-05-09 00:16:06 <wei_> looking now
21 2013-05-09 00:16:14 <tumak> well, the low level api is getAffectedTransactions
22 2013-05-09 00:16:26 <tumak> i guess there is that kind of api in bitcoinj as well
23 2013-05-09 00:16:54 <tumak> wei_: i'd use bitcoinjs if you want to do socket.io remoting of that, as most of necessary code is already written and its actually user friendly
24 2013-05-09 00:17:54 <tumak> wei_: this is how it's done on bitcoinjs thin client https://github.com/katuma/bitcoinjs-gui/blob/master/scripts/exitnode.js#L59
25 2013-05-09 00:20:55 <gmaxwell> zooko: that decision is also greatly influenced by which transactions made it into the mempool in the first place.
26 2013-05-09 00:21:29 <zooko> gmaxwell: where is that determined?
27 2013-05-09 00:22:16 <sipa> gmaxwell: http://bitcoin.sipa.be/pruning.png
28 2013-05-09 00:23:03 <sipa> zooko: accepttomempool something
29 2013-05-09 00:24:42 <zooko> sipa: thanks!
30 2013-05-09 00:24:52 <sipa> gmaxwell: with a linear scale it looks far more impressive!
31 2013-05-09 00:25:00 <wei_> tumak: thanks that looks similar to what I need
32 2013-05-09 00:27:02 <gmaxwell> sipa: that upward bend in the utxo size on the right there is unfortunate??? but hey, can't see it yet in log scale.
33 2013-05-09 00:27:30 <gmaxwell> zooko: most important part being IsStandard() which is where the dust patch changes it.
34 2013-05-09 00:28:02 <zooko> gmaxwell: I see that.
35 2013-05-09 00:28:25 <sipa> somehow gmaxwell manages to give way better answers, by not answering the actual questions...
36 2013-05-09 00:28:55 <gmaxwell> If people knew what they actually needed to be asking, they probably could have answered the question themselves.
37 2013-05-09 00:28:56 <zooko> Well, I'm actually looking for something else besides the IsDust() thing right now...
38 2013-05-09 00:29:18 <zooko>
39 2013-05-09 00:29:18 <zooko> But yes, the part about "what goes into mempool" is highly relevant to what I actually needed to be asking.
40 2013-05-09 00:32:15 <gmaxwell> IsStandard mostly serves the purpose of making is so that to exploit some nasty bug (dos attack, netsplit, forwards incompatiblity) the requires unusual transactions you have to be able to mine a block (or at least convince someone who can to do it for you).
41 2013-05-09 00:33:31 <zooko> I don't really understand that.
42 2013-05-09 00:34:49 <gmaxwell> There have several times been discovered exploitable vulnerabilities in the initial codebase that required mining non-standard scripts. Things like OP_RETURN returning true and letting you spend any coin.
43 2013-05-09 00:35:53 <zooko> Hm.
44 2013-05-09 00:36:25 <zooko> So IsStandard() filters what (standard) miners will accept into blocks, but not what a recipient would accept as a valid transaction?
45 2013-05-09 00:36:28 <nsh> *features
46 2013-05-09 00:36:52 <gmaxwell> zooko: IsStandard makes everyone (with that code) drop the transactions unless they show up in a block.
47 2013-05-09 00:37:22 <zooko> ACTION reads IsStandard
48 2013-05-09 00:37:49 <gmaxwell> The forward incompatiblity part is more subtle. Bitcoin was designed to be forwards compatible in specific ways so new things could be added without breaking old nodes. For example, there are several OP_NOPs for this purpose. Existing nodes treat them as NO_OPs but future nodes can use them to trigger more rules in transactions, so long as if a parsing with the new opcodes as noops also works.
49 2013-05-09 00:38:20 <gmaxwell> The problem is that to deploy one of these new rules safely you need (1) a supermajority of miners imposing it, (2) no one mining transactions incompatible with the new rule.
50 2013-05-09 00:38:54 <gmaxwell> If there is nothing like IsStandard blocking them, however, griefers could be getting older nodes to mine weird looking transactions that violate a new rule.
51 2013-05-09 00:39:05 <zooko> Hm.
52 2013-05-09 00:39:08 <gmaxwell> And then deploying any new feature is risky.
53 2013-05-09 00:39:30 <gmaxwell> But a narrower IsStandard could accomplish that end, and ultimately I believe we'll use a narrower one like that.
54 2013-05-09 00:39:34 <zooko> Subtle.
55 2013-05-09 00:39:49 <cjd> interesting
56 2013-05-09 00:40:06 <nsh> cabbages
57 2013-05-09 00:40:12 <gmaxwell> ... and not just grifers. I mean, there is an economic advantage to miners to get their software-upgrading-lazy minority hashrate competition to mine invalid blocks.
58 2013-05-09 00:40:54 <cjd> It's easy to see IsStandard() as not very useful (at least for OP_RETURN attacks) since the attacker can just go hit up luke to get mined
59 2013-05-09 00:41:10 <gmaxwell> cjd: luke doesn't apply no restrictions, he applies his own.
60 2013-05-09 00:41:27 <cjd> that helps
61 2013-05-09 00:41:34 <cjd> esp. if they are unpublished
62 2013-05-09 00:41:43 <gmaxwell> cjd: and some cases like the lshift bug can't be mined, but instead exploited nodes as they were accepted into memory pools.
63 2013-05-09 00:42:01 <cjd> yeap
64 2013-05-09 00:42:06 <gmaxwell> well s/exploited/crashed/ I'm not aware of it being used to do anything other than crash.
65 2013-05-09 00:42:33 <cjd> I'm not familiar with the lshift one but that was the case with the hash tree thing
66 2013-05-09 00:42:43 <zooko> ACTION nods.
67 2013-05-09 00:42:44 <gmaxwell> The anti-dos purpose of IsStandard could be accomplished instead by things like ratelimiting and prioritizing and using finite sized pools. But there are some protocol challenges, because if the acceptance behavior is "non-determinstic" you really want a way to find out if your transaction made it anywhere... and we don't have that yet.
68 2013-05-09 00:43:35 <cjd> yeah, it would be really cool if miners could send a +1 for a transaction when they let it in
69 2013-05-09 00:43:51 <gmaxwell> cjd: or if everyone used something like p2pool.
70 2013-05-09 00:43:59 <zooko> gmaxwell: yeah, that's related to what I'm thinking about.
71 2013-05-09 00:44:01 <cjd> indeed
72 2013-05-09 00:44:04 <gmaxwell> P2pool makes concrete proof that hashpower is being applied to particular transactions.
73 2013-05-09 00:44:12 <cjd> otoh p2pool means everything is vanilla
74 2013-05-09 00:44:59 <gmaxwell> I'm actually now concerned about the dust change because I'm worried that people are going to over-popularize the knobs to adjust them. And then people are going to set random values. There was already multiple people on the forums posting saying that they'd turn them _up_ because they think that the default dust limit isn't agressive enough.
75 2013-05-09 00:45:28 <gmaxwell> cjd: huh? p2pool makes no special restrictions on the transactions you mine today.
76 2013-05-09 00:45:37 <gmaxwell> thats up to each user.
77 2013-05-09 00:46:04 <cjd> yeah but without centralized pools, there will be less interest in tinkering with the rules, less attention paid
78 2013-05-09 00:46:13 <cjd> makes vulnerability a binary state
79 2013-05-09 00:46:15 <gmaxwell> cjd: though I've actually suggested that in the future p2pool like systems might actually refuse to pay participants who replace with-fee transactions in the share chain with doublespends.
80 2013-05-09 00:46:40 <cjd> hmm
81 2013-05-09 00:46:58 <gmaxwell> cjd: I dunno about that. It's hard to say relative to hashpower, but several of the larger p2pool users have been running their own rules (I know because many have gotten help from me patching bitcoind to implement them)
82 2013-05-09 00:47:13 <cjd> hmmahh, that's cool
83 2013-05-09 00:47:19 <cjd> s/^hmm//
84 2013-05-09 00:47:45 <gmaxwell> The major pools mostly don't twiddle with the rules. :( I consider this unfortunate to a degree.
85 2013-05-09 00:47:57 <gmaxwell> But at least it means the default stuff is probably not so terrible.
86 2013-05-09 00:48:08 <cjd> yeah, that is unfortunate
87 2013-05-09 00:55:44 <cjd> re timestamping, suppose I take a hash, point multiply it into a pubkey, hash that and pay to it, then pay from it to another key and reveal the private key... am I still breaking the rules?
88 2013-05-09 00:55:52 <cjd> it's not in the utxo set forevar...
89 2013-05-09 00:58:45 <Luke-Jr> cjd: why don't you want to do it the right way?
90 2013-05-09 00:59:19 <cjd> proof size constraint & lazieness
91 2013-05-09 01:00:38 <Luke-Jr> to prove the timestamp you need the blockchain headers. your size constraint is impractical
92 2013-05-09 01:01:02 <cjd> everyone stores headers, that storage is ok
93 2013-05-09 01:01:07 <cjd> the problem is the proof itself
94 2013-05-09 01:01:46 <Luke-Jr> anyhow, I don't see how your size is notably affected by doing it right
95 2013-05-09 01:01:54 <Luke-Jr> either way, you need the merkle leaves
96 2013-05-09 01:01:59 <Luke-Jr> s/leaves/links
97 2013-05-09 01:02:34 <cjd> "right way" == the p2pool thing?
98 2013-05-09 01:03:02 <Luke-Jr> cjd: no, just make a merkle tree of message hashes, and include them directly in the block coinbase
99 2013-05-09 01:03:22 <Luke-Jr> well, in the merged mining merkletree
100 2013-05-09 01:04:46 <cjd> so pay some small fee to a miner to have the root of my tree included in the merged mining tree?
101 2013-05-09 01:05:36 <cjd> could work
102 2013-05-09 01:08:58 <gmaxwell> cjd: your proof size is no larger doing it the O(1) merged mining merkletree way than having it in a transaction.
103 2013-05-09 01:09:30 <gmaxwell> cjd: who says you pay a fee? if you construct good software for this miners will run it just to keep the timestamp crap out of the blockchain.
104 2013-05-09 01:09:52 <cjd> hmm
105 2013-05-09 01:09:59 <cjd> actually you make a very good point
106 2013-05-09 01:10:26 <cjd> I'd happily pay a fee for a short proof but others would happily tollerate a long proof and should not need to pay a fee
107 2013-05-09 01:11:03 <gmaxwell> cjd: yea, and if the proofs are in a non-binary tree... people could pay for placement.
108 2013-05-09 01:11:52 <cjd> but then I am not entirely sure if my usecase is more a colorcoin usecase or a timestamping usecase
109 2013-05-09 01:11:59 <cjd> depends on ambition really
110 2013-05-09 01:16:23 <nsh> The best lack all conviction, while the worst / Are full of passionate intensity.
111 2013-05-09 01:16:40 <Diablo-D3> what are we talking about here?
112 2013-05-09 01:17:29 <gmaxwell> well, be aware that bitcoin transactions may be moderately expensive in the future, and the networks friendlyness towards non-currency uses can't be guaranteed. (my personal view is that activity that otherwise looks and smells like currency activity and doesn't produce any additional costs like utxo bloat is just ducky)
113 2013-05-09 01:18:35 <MarceFe> I need implement authentication with sql in stratum mining, someone know how to?
114 2013-05-09 01:18:51 <cjd> thing is, for me dropping 2$ on one proof is ok if that's how it has to be, less is better but I'm certainly not constrained to 1 satoshi outputs
115 2013-05-09 01:20:42 <cjd> ofc I always have to consider the possibility of future witch hunts against transaction patterns or even addresses which are "associated with bad activity"
116 2013-05-09 01:21:30 <zooko> Witch hunts on whose part?
117 2013-05-09 01:21:51 <nsh> in a p2p system, everyone should have an equal chance to be hunting the witch
118 2013-05-09 01:22:30 <cjd> but admittedly if there is a miner's conspiracy to not mine valid transactions involving a list of addresses then we're in deep trouble anyway
119 2013-05-09 01:22:53 <helo> there already probably is
120 2013-05-09 01:23:06 <cjd> ACTION eyesroll
121 2013-05-09 01:23:24 <zooko> Would this conspiracy also conspire to refuse to build on blocks of other miners that did include these witchy transactions?
122 2013-05-09 01:23:37 <nsh> yay unto the seventh generation
123 2013-05-09 01:23:40 <Luke-Jr> cjd: it's miners' job to filter out spam. if spammers make it easy by using known addresses, why not? ;)
124 2013-05-09 01:24:28 <cjd> because these kinds of rules go south fast
125 2013-05-09 01:26:19 <cjd> not unlike the irc ridiculousness where they kline people for saying dcc send... thus you can use the rule to kill anyone's bot as long as it will echo a message for you
126 2013-05-09 01:26:42 <cjd> you get more vulnerability, not less
127 2013-05-09 01:26:57 <nsh> +1
128 2013-05-09 01:27:00 <gmaxwell> zooko: as nsh says...
129 2013-05-09 01:27:21 <gmaxwell> I recently closed and rejected a pull request to add a GUI for blacklisting addresses.
130 2013-05-09 01:27:26 <Luke-Jr> cjd: but they're necessary 'rules'.
131 2013-05-09 01:27:41 <cjd> gmaxwell: +1
132 2013-05-09 01:27:42 <Luke-Jr> cjd: if you don't filter spam, the system cannot function
133 2013-05-09 01:27:44 <gmaxwell> (and there has been a moderate amount of "the developers are evil scumm" for that)
134 2013-05-09 01:27:47 <cjd> that stuff is scary
135 2013-05-09 01:28:08 <gmaxwell> (of course, accepting it would have resulted in even more)
136 2013-05-09 01:28:17 <gmaxwell> (plus been bad for bitcoin)
137 2013-05-09 01:28:20 <cjd> it sounds so good
138 2013-05-09 01:28:34 <cjd> until you start reasoning it out D:
139 2013-05-09 01:28:55 <gmaxwell> cjd: well, fortunately "correct" use of bitcoin makes filtering by addresses pretty ineffective.
140 2013-05-09 01:29:17 <cjd> /nod
141 2013-05-09 01:29:58 <cjd> and as things grow the pay pattern will tend toward immitating a hash function
142 2013-05-09 01:30:05 <cjd> :)
143 2013-05-09 01:30:29 <nsh> cjd, ?
144 2013-05-09 01:30:37 <cjd> nothin :)
145 2013-05-09 01:30:41 <nsh> l
146 2013-05-09 01:30:46 <nsh> *k
147 2013-05-09 01:33:33 <nsh> hmm
148 2013-05-09 01:35:39 <nsh> Virtual particles are also excitations of the underlying fields, but are "temporary" in the sense that they appear in calculations of interactions, but never as asymptotic states or indices to the scattering matrix. As such the accuracy and use of virtual particles in calculations is firmly established, but their "reality" or existence is a question of philosophy rather than science.
149 2013-05-09 01:53:42 <Raccoon> Everyone please help block access to that trojan/malware site Bitcoin-Alarm by reporting it to google, so Firefox and Chrome block access.
150 2013-05-09 01:53:46 <Raccoon> --->> https://www.google.com/safebrowsing/report_badware/?url=http%3A%2F%2Fwww%2EBitcoin-Alarm%2Ecom%2F
151 2013-05-09 01:54:28 <cjd> ;;t
152 2013-05-09 01:54:29 <gribble> Google Safe Browsing: Report a Malware Page
153 2013-05-09 01:54:37 <cjd> what are they running?
154 2013-05-09 01:55:18 <cjd> wallet stealer?
155 2013-05-09 01:55:28 <alexwaters> anyone going to the conference?
156 2013-05-09 01:55:46 <alexwaters> i'm hoping to actually meet Luke Dash, main reason I'm going
157 2013-05-09 01:57:16 <Raccoon> cjd: yes, wallet stealer
158 2013-05-09 01:57:20 <Raccoon> trojan
159 2013-05-09 01:57:42 <Raccoon> cjd: they've been hammering people in #bitcoin with PM spam.
160 2013-05-09 01:57:50 <Raccoon> [11:09] <ywau8_14638> www.Bitcoin-Alarm.com - You will like it!
161 2013-05-09 01:58:07 <cjd> right
162 2013-05-09 01:59:38 <cjd> ACTION sends link to ircerr for his collection
163 2013-05-09 02:06:18 <Luke-Jr> alexwaters: O.o
164 2013-05-09 02:07:03 <jgarzik> Off-topic: IBM's homomorphic encryption lib: https://github.com/shaih/HElib
165 2013-05-09 02:07:35 <cjd> Someone told me that HE is really slow, like something that takes AES seconds takes months with HE
166 2013-05-09 02:08:44 <zooko> cjd: yes.
167 2013-05-09 02:09:26 <Raccoon> jgarzik, zooko: hit that link please.
168 2013-05-09 02:11:12 <jgarzik> Here is a free link to LWN's coverage on IBM homomorphic encryption: http://lwn.net/SubscriberLink/549665/0f64b379d75a1c0a/
169 2013-05-09 02:11:21 <jgarzik> good overview article on HE
170 2013-05-09 02:11:32 <jgarzik> it jibes with what cjd just said
171 2013-05-09 02:13:16 <gmaxwell> cjd: yea, it's really slow. And no IO ... but .. if you just need it to??? say??? tally a vote.. no big deal, and the computation can be justified.
172 2013-05-09 02:13:54 <cjd> if you want secure voting, you can just use a blockchain
173 2013-05-09 02:13:55 <alexwaters> jgarzik: can I think of it as essentially a black box that can be passed to a untrusted party? the party can make calls to the black box to receive information, but not see what's in the box? struggling with understanding how the party gets any use out of the ciphertext
174 2013-05-09 02:14:00 <cjd> in some random way
175 2013-05-09 02:14:11 <cjd> maybe put the blockchain next to the voting booth, then it will be secure
176 2013-05-09 02:14:20 <cjd> or dust payments, that will surely help
177 2013-05-09 02:14:58 <gmaxwell> cjd: you could put it on your hat and then you would be secure too.
178 2013-05-09 02:15:04 <alexwaters> i remember google mentioning using it for search, so that even they would not know what a user searched for - but my understanding of how that works is scant
179 2013-05-09 02:15:05 <gmaxwell> wear it like a tierra.
180 2013-05-09 02:15:08 <cjd> :D
181 2013-05-09 02:16:14 <cjd> poly1305 is somewhat of a similar idea, you multiply modulo 2**130-5 each block of data and then add a secret to the result
182 2013-05-09 02:16:43 <cjd> with the secret, the other end can repeat the process to authenticate the data
183 2013-05-09 02:17:17 <cjd> similar to the general idea of adding numbers w/o knowing their meaning that is
184 2013-05-09 02:20:06 <midnightmagic> ACTION backs slowly away from the huge group of drunk people.
185 2013-05-09 02:21:05 <alexwaters> or maybe it was that certain parts of their system would not know what the user searched for, still cool
186 2013-05-09 02:21:30 <Raccoon> ACTION wants to play pinball whenenver he sees midnightmagic talk
187 2013-05-09 02:23:37 <alexwaters> https://github.com/alexwaters/bitcointesting.org anyone care to help? i won't be able to work on it for a month
188 2013-05-09 02:26:55 <MarceFe> I need implement authentication with sql in stratum mining, someone know how to? Si habla castellano mejor! jaja
189 2013-05-09 02:36:11 <SteveDekorte> is it a standard for a peer to send the first year worth of blocks following a completed handshake?
190 2013-05-09 02:37:50 <cjd> not if you didn't ask for them
191 2013-05-09 02:42:30 <SteveDekorte> cjd: ok, thanks - I just didn't see that packet sent but maybe I'm not logging it
192 2013-05-09 02:44:01 <cjd> yeah, satoshi nodes do ask for blocks if it's not up to date
193 2013-05-09 03:12:39 <MacMiner741> ACTION has been synchronizing for many hours.. something wrong?
194 2013-05-09 03:13:02 <cjd> is the # of weeks decreasing?
195 2013-05-09 03:15:31 <MarceFe> cjd satoshi tommi?
196 2013-05-09 03:15:47 <cjd> o_O
197 2013-05-09 03:16:04 <MarceFe> hahaaha
198 2013-05-09 04:02:47 <SteveDekorte> is an inv block packet supposed to be broadcast automatically to peers when a valid new block is seen?
199 2013-05-09 04:06:44 <jgarzik> SteveDekorte: probably, presuming you want to serve a block to others
200 2013-05-09 04:07:25 <SteveDekorte> is there a doc that describes these details - I'm not seeing them in https://en.bitcoin.it/wiki/Protocol_specification but maybe I missed something
201 2013-05-09 04:07:55 <gmaxwell> No.
202 2013-05-09 04:08:06 <gmaxwell> And that page is considerably incomplete.
203 2013-05-09 04:08:11 <SteveDekorte> I'm not seeing other nodes broadcast new blocks atm but I thought I was before
204 2013-05-09 04:08:38 <SteveDekorte> gmaxwell: is there a better source?
205 2013-05-09 04:08:44 <jgarzik> The source
206 2013-05-09 04:10:25 <SteveDekorte> I was afraid someone would say that :)
207 2013-05-09 04:21:56 <zooko_> Hey SteveDekorte.
208 2013-05-09 04:30:53 <midnightmagic> +1 Raccoon for the pinball reference. BTW, good alternative is zen pinball on ps3
209 2013-05-09 04:31:39 <Raccoon> midnightmagic: I have this feeling we talked about pinball like 5 years ago
210 2013-05-09 04:32:46 <midnightmagic> Raccoon: It's possible. Maybe more like 3-4.
211 2013-05-09 04:33:29 <Raccoon> when you can remember an atari game like midnightmagic, 3..4..5 become a blur :p
212 2013-05-09 04:36:22 <midnightmagic> I played it on an Apple. I never did find the release for the C=64 though..
213 2013-05-09 04:36:36 <MacMiner741> do people handle litecoin questions the same as bitcoin questions?
214 2013-05-09 04:39:04 <SteveDekorte> hi zooko_
215 2013-05-09 04:43:19 <Graet> MacMiner741, rarely, #litecoin-dev might be better ;)
216 2013-05-09 04:43:42 <jordandotdev> hey all I have a question about running testnet
217 2013-05-09 04:43:45 <MacMiner741> ty
218 2013-05-09 04:43:55 <Graet> :)
219 2013-05-09 04:44:04 <jordandotdev> umm so should I create a 2nd directory and start with the -testnet and -datadir flag pointing to this new directory?
220 2013-05-09 04:44:20 <jordandotdev> if I've already downloaded the blockchain once - to save time later?
221 2013-05-09 04:44:32 <midnightmagic> jordandotdev: No it'll automatically use a subdirectory in your .bitcoin directory, called "testnet3"
222 2013-05-09 04:44:49 <jordandotdev> ok, do I need to modify my bitcoin.conf when I use the -testnet flag?
223 2013-05-09 04:45:02 <midnightmagic> jordandotdev: Just use -testnet, and make sure you have it aliased or something so yo don't accidentally spent your real bitcoin.
224 2013-05-09 04:45:16 <midnightmagic> jordandotdev: Better yet, shut down you rmain bitcoind while you're monkeying around with testnet.
225 2013-05-09 04:45:20 <jordandotdev> there isn't any real btc on there right now
226 2013-05-09 04:45:29 <midnightmagic> jordandotdev: No, you don't have to.
227 2013-05-09 04:45:35 <jordandotdev> just testing my web-ui
228 2013-05-09 04:45:44 <midnightmagic> want some testnet coins?
229 2013-05-09 04:45:53 <jordandotdev> not yet ... haven't started up yet !
230 2013-05-09 04:46:16 <midnightmagic> Well. I have a whole bunch, so let me know, I'll send some.
231 2013-05-09 04:46:30 <jordandotdev> thanx!
232 2013-05-09 04:46:38 <midnightmagic> don't thank me yet. :)
233 2013-05-09 04:47:33 <SteveDekorte> zooko_: you used to hang out on the io channel right?
234 2013-05-09 04:49:11 <jordandotdev> midnightmagic - one last question can I use the same 'accounts' when running -testnet
235 2013-05-09 04:49:34 <jordandotdev> and they'll have testnet addresses?
236 2013-05-09 04:50:36 <midnightmagic> jordandotdev: The databases are in a separate location in a subdirectory under your .bitcoin directory. There is no overlap. You'll have to create the other accounts all over again.
237 2013-05-09 04:50:46 <jordandotdev> got it no problem
238 2013-05-09 04:51:36 <jordandotdev> I'm gonna move over to armory I think for security reasons
239 2013-05-09 04:51:45 <jordandotdev> but this is a good start -
240 2013-05-09 04:52:52 <jordandotdev> does anyone recommend armory versus bitcoind for security?
241 2013-05-09 04:57:03 <wumpus> eh you still needs bitcoind with armory
242 2013-05-09 04:57:16 <jordandotdev> ok I get it
243 2013-05-09 04:57:22 <jordandotdev> it runs on top of it?
244 2013-05-09 04:57:26 <wumpus> yes
245 2013-05-09 04:57:36 <wumpus> it uses it for the block chain but not the wallet
246 2013-05-09 05:12:25 <MacMiner741> is there any kind of local encryption protection, to encrypt keystrokes into your bitcoin wallet?
247 2013-05-09 05:14:41 <kadoban> MacMiner741: you can encrypt your wallet with a passphrase if that's what you mean. otherwise, probably not
248 2013-05-09 05:34:28 <CodeShark> you can use dedicated hardware
249 2013-05-09 05:54:46 <nsh> it is possible to get similar results to fully homomorphic encryption with an amortization speed-up using pre-computations with a secret-sharing algorithm
250 2013-05-09 05:54:51 <nsh> which is kinda neat
251 2013-05-09 05:55:04 <nsh> iirc there was a good google talk about it
252 2013-05-09 05:55:56 <nsh> sorry, multi-party computation
253 2013-05-09 05:56:35 <nsh> this, possibly: http://www.youtube.com/watch?v=LRAN_w1_qmw Multi-Party Computation: From Theory to Practice (54:29) 2,761 views, ??????????????? by 35 raters
254 2013-05-09 06:08:46 <andrew_scorpil1> hi guys. Anyone using mtgox vanilla WebSocket streaming API? Does it _ever_ work?
255 2013-05-09 06:09:21 <weex> andrew_scorpil1: i hear there's some ddos action now but you can try #mtgox
256 2013-05-09 06:09:37 <andrew_scorpil1> thanks
257 2013-05-09 06:50:09 <t7> the go btc node is pretty nice
258 2013-05-09 06:51:45 <t7> well its not a node
259 2013-05-09 06:51:58 <t7> but has the network protocol done already
260 2013-05-09 06:53:13 <nsh> t7, what size board?
261 2013-05-09 06:55:49 <t7> wut
262 2013-05-09 06:56:03 <t7> not the board game... :3
263 2013-05-09 06:56:28 <nsh> :)
264 2013-05-09 06:56:32 <SomeoneWeird> wat
265 2013-05-09 06:56:35 <SomeoneWeird> lol
266 2013-05-09 06:56:35 <SomeoneWeird> oh
267 2013-05-09 06:57:10 <nsh> not impressed then. if someone implements a slim node using actual go board and pebble manipulations, well, that dude(tte) would get a pizza
268 2013-05-09 06:59:22 <jgm> Their proof of concept site is okay but I wish that people would start using units when quoting bitcoin values. 0.00081754 is just too ugly to look at (let alone 5.43e-05)
269 2013-05-09 07:00:00 <jgm> Oh, and they seem to have lost all the inputs in the transaction view
270 2013-05-09 07:01:19 <duSn> if you think 0.00081754 is 5.43e-05 then i think we should do some bidness
271 2013-05-09 07:01:58 <jgm> duSn: Separate entries on one of their pages
272 2013-05-09 07:09:16 <hazrd> hey all
273 2013-05-09 07:11:18 <hazrd> is there a way to get the current block from bitcoind? 'getinfo' only shows "blocks" : 234833, for example, which isn't current - would be nice to see how many blocks I would still need to go to be up to date
274 2013-05-09 07:16:26 <t7> hazrd, it must be in the client somewhere because it shows a progress bar in the gui
275 2013-05-09 07:16:43 <t7> not sure its exposed by bitcoind though
276 2013-05-09 07:17:52 <hazrd> t7, hmmm - does the client maybe connect to blockchain.info (or something else) to get this info? or potentially a peer...?
277 2013-05-09 07:19:29 <t7> i doubt it
278 2013-05-09 07:19:42 <t7> probably asks other peers
279 2013-05-09 07:19:47 <hazrd> ok - will go sniff through the source some more
280 2013-05-09 07:19:48 <hazrd> thanks ;)
281 2013-05-09 07:25:32 <sipa> harthere are two heuristics for guessing the total numer of blocks
282 2013-05-09 07:25:40 <sipa> and they are both just guesses
283 2013-05-09 07:26:12 <sipa> one is using the median of the number of blocks claimed by your peers (who can lie about it)
284 2013-05-09 07:26:31 <sipa> another is looking at the timestamp of the last block
285 2013-05-09 07:27:40 <hazrd> sipa, so extrapolate current block timestamp with potential blocks to current timestamp
286 2013-05-09 07:27:42 <hazrd> ?
287 2013-05-09 07:28:07 <hazrd> (not that i don't trust other peers... :) )
288 2013-05-09 07:28:25 <hazrd> s/with/from/
289 2013-05-09 07:29:29 <sipa> indeed
290 2013-05-09 07:29:50 <hazrd> actually, that makes sense - since i have timestamps per block, it wouldn't be hard to "guess" which block i should hit at a specific timestamp
291 2013-05-09 07:29:57 <hazrd> sipa, perfect, thanks!
292 2013-05-09 07:30:11 <sipa> it's mostly used guessing "am i done, or not?", not for extrapolating the total number of blocks
293 2013-05-09 07:30:24 <hazrd> understood ;)
294 2013-05-09 08:39:13 <Xexe> hi folks, can somebody point me out to the place in the sourcecode where the math function limiting the emission is defined?
295 2013-05-09 08:44:40 <jaromil> ACTION rotfl
296 2013-05-09 08:44:58 <jaromil> sry but there is no #define MAX_BITCOINS 21000000000
297 2013-05-09 08:45:21 <jaromil> its not a single math function
298 2013-05-09 08:46:26 <jaromil> your best chance is looking at this and figuring out changes across codebases https://bitcointalk.org/index.php?topic=193025.0;topicseen
299 2013-05-09 08:49:30 <sipa> see GetBlockValue in main.cpp
300 2013-05-09 08:59:35 <pagoda> Hi, I am currently programming my own miner. Can any1 maybe let me know if I am on the right path here:
301 2013-05-09 09:00:13 <SomeoneWeird> uh
302 2013-05-09 09:00:24 <pagoda> If I want to submit a "getwork" share; I should submit the header I used to generate the hash, not the hash it self?
303 2013-05-09 09:01:23 <pagoda> If so, the header should be a in Hex Little Endian format?
304 2013-05-09 09:01:27 <matjeh> you need to submit the header and the hash, so it can be validated
305 2013-05-09 09:02:48 <pagoda> Header & hash? Should they be concatenated? Or as separate parameters?
306 2013-05-09 09:03:11 <SomeoneWeird> no offense, but if you can't figure out it yourself, there's no point in writing a miner
307 2013-05-09 09:04:17 <Xexe> so it's a math curve defined in the code by cutting the Subsidy var by half each time interval?
308 2013-05-09 09:04:26 <Xexe> so it must be a reverse of y=x^2 right? but the base strangely not e but 2 instead, hmmm why is that?
309 2013-05-09 09:04:42 <Xexe> so what math fucntion precisely is that anyway?
310 2013-05-09 09:05:30 <Xexe> ohh not y=x^2, but y=2^x..
311 2013-05-09 09:07:38 <sipa> Xexe: the subsidy is 50 BTC the first 210000 blocks, then 25 BTC the next 210000 blocks, ...
312 2013-05-09 09:07:43 <sipa> 210000 is ~ 4 years
313 2013-05-09 09:08:00 <sipa> (50+25+12.5+6.25+3.125+...) * 2100000 = 21M
314 2013-05-09 09:08:15 <Xexe> jaromil, how come it's not a single math curve? hmmm it gotta be..
315 2013-05-09 09:08:24 <Xexe> sipa, yes that's correct..
316 2013-05-09 09:08:40 <skinnkavaj> Oh Mike Hearn love that guy, he wrote this in mailing list:
317 2013-05-09 09:08:45 <skinnkavaj> . It's hard to imagine an organisation as
318 2013-05-09 09:08:48 <skinnkavaj> a big as a mobile carrier engaging in financial scamming (roaming fees
319 2013-05-09 09:08:51 <skinnkavaj> excepted).
320 2013-05-09 09:08:57 <skinnkavaj> I've said this before, but I think it's worth repeating. The
321 2013-05-09 09:09:00 <skinnkavaj> double-spend protection the block chain gives you has a sweet spot
322 2013-05-09 09:09:03 <skinnkavaj> where it's really, really valuable (essential even) and then there are
323 2013-05-09 09:09:05 <Xexe> it means to me that the func is just defined that way, kinda empirically..
324 2013-05-09 09:09:07 <skinnkavaj> lots of kinds of transactions on either side of that sweet spot that
325 2013-05-09 09:09:10 <skinnkavaj> don't really benefit from it.
326 2013-05-09 09:09:16 <skinnkavaj> Obvious/trivial case where you don't need a block chain - Facebook
327 2013-05-09 09:09:19 <skinnkavaj> buys Instagram for a gajillion coins. The legal system is plenty good
328 2013-05-09 09:09:40 <sipa> Xexe: yeah
329 2013-05-09 09:09:43 <sipa> Xexe: gut feeling
330 2013-05-09 09:10:08 <BlueMatt> skinnkavaj: we've mostly all read it already, no need to paste 20 lines of an email in irc...
331 2013-05-09 09:12:09 <Xexe> i just realised that the base of the func is not the magical e number as i had assumed before, but 2 instead.
332 2013-05-09 09:13:35 <Xexe> looks not that natural to me at the moment, but it can be..
333 2013-05-09 09:15:05 <sipa> Xexe: my guess: implementation simplicity
334 2013-05-09 09:15:12 <sipa> and easy-to-explain
335 2013-05-09 09:15:24 <sipa> "the reward halves every 4 years"
336 2013-05-09 09:15:44 <Xexe> sipa, yes it well maybe
337 2013-05-09 09:31:58 <sipa> ;;nethash
338 2013-05-09 09:31:59 <gribble> 86004.7581216
339 2013-05-09 09:32:41 <sipa> in two days, we'll likely cross 2^70 hashes as PoW in the main chain
340 2013-05-09 11:55:00 <hazrd> can someone explain to me how the values after line 36 of checkpoints.cpp is calculated?
341 2013-05-09 11:59:25 <sipa> hazrd: i probably can
342 2013-05-09 11:59:56 <sipa> oh, line 36... those are just the checkpoints themself
343 2013-05-09 11:59:57 <hazrd> sipa, i understand that each check needs to be surrounded by blocks with "good" timestamps - but that's it
344 2013-05-09 12:00:08 <sipa> the hashes of the blocks that are checksums
345 2013-05-09 12:00:21 <hazrd> ok, so those are chosen at random?
346 2013-05-09 12:00:32 <hazrd> (the hard-coded values, i mean)
347 2013-05-09 12:00:40 <sipa> when there's a new release, and it has been long enough since the previous checkpoint, a new one is added
348 2013-05-09 12:01:41 <hazrd> i've been wracking my brain to find some correlation between value 1, 2, 1500 and 4032
349 2013-05-09 12:02:05 <hazrd> so, in short, there is none, it's simply a arb number based on "it's been a long enough time"?
350 2013-05-09 12:02:32 <edcba> i still think those blocks should only locked according to a formula
351 2013-05-09 12:02:45 <edcba> ie no maintenance for releases
352 2013-05-09 12:03:03 <hazrd> edcba, that's what i thought and for the life of me, I couldn't figure out the pattern
353 2013-05-09 12:03:18 <edcba> ie if chain longer than 32 then lock 3/4 of the chain
354 2013-05-09 12:03:18 <hazrd> (i'm reasonably good with that, so it was very frustrating :P )
355 2013-05-09 12:03:39 <hazrd> at least it makes sense now - thank you :)
356 2013-05-09 12:03:46 <sipa> 1, 2, 1500, 4032?
357 2013-05-09 12:03:59 <devurandom> May a transaction be confirmed in two blocks? Or may it always only appear in one?
358 2013-05-09 12:04:10 <sipa> devurandom: the second would be a double spend
359 2013-05-09 12:04:12 <rdponticelli> hazrd: One chosen because it had a lot of elevens, gavin's favourite number... :p
360 2013-05-09 12:04:31 <devurandom> sipa: But you could easily verify that the same transaction appears in two blocks, not?
361 2013-05-09 12:04:37 <sipa> devurandom: no
362 2013-05-09 12:04:39 <eqolo> sipa: i have a problem bro
363 2013-05-09 12:04:49 <devurandom> sipa: Why not?
364 2013-05-09 12:04:55 <rdponticelli> One of the last ones... ^
365 2013-05-09 12:04:56 <eqolo> you know me since some days ago, iam new here right?
366 2013-05-09 12:05:04 <hazrd> sipa, yes, the checkpoints chosen ;)
367 2013-05-09 12:05:05 <sipa> devurandom: because the database only remembers unspent transaction outputs
368 2013-05-09 12:05:22 <devurandom> ?
369 2013-05-09 12:05:24 <sipa> hazrd: i don't see those numbers anywhere
370 2013-05-09 12:05:25 <edcba> hmm
371 2013-05-09 12:05:39 <edcba> so you can't have leftovers for 1 address ?
372 2013-05-09 12:05:44 <sipa> devurandom: so if the transaction was already spent, you can't detect the duplicate anymore as a duplicate
373 2013-05-09 12:05:56 <devurandom> What I assumed is that the transactionid is unique and if it appears twice, I can throw away one of them?
374 2013-05-09 12:06:01 <sipa> devurandom: it's just some transaction that spends an input that doesn't exist, which is invalid, exactly as it would be
375 2013-05-09 12:06:11 <devurandom> "throw away" i.e. not bother about it, because I've seen it already.
376 2013-05-09 12:06:25 <hazrd> sipa, apologies - wrong code - the numbers in the official bitcoin source are 11111, 33333, 74000 etc.
377 2013-05-09 12:06:26 <devurandom> sipa: So the transaction has no unique id?
378 2013-05-09 12:06:30 <edcba> can i make some tx with (A,B) sending to (C,D,E,A) ?
379 2013-05-09 12:06:33 <sipa> devurandom: yes, it has
380 2013-05-09 12:06:36 <sipa> devurandom: its hash
381 2013-05-09 12:06:53 <devurandom> Ok, the hash becomes unique, because a transaction may only appear in one block.
382 2013-05-09 12:06:55 <chmod755> edcba, A = Alice, B = Bob?
383 2013-05-09 12:06:59 <devurandom> Then it makes sence.
384 2013-05-09 12:07:02 <devurandom> sense
385 2013-05-09 12:07:09 <edcba> chmod755: some bitcoin addrs
386 2013-05-09 12:07:12 <devurandom> sipa: Thanks :)
387 2013-05-09 12:07:17 <sipa> devurandom: but you seem to think there's a special rule forbidding duplicate transactions
388 2013-05-09 12:07:29 <sipa> devurandom: there is no such thing: it's simply invalid because it spends something that was already spent
389 2013-05-09 12:07:51 <devurandom> sipa: So the same transaction id (i.e. hash) may appear in multiple blocks)?
390 2013-05-09 12:07:55 <sipa> devurandom: no!
391 2013-05-09 12:08:13 <sipa> devurandom: the second transaction will be consuming the same inputs as the first, so it is invalid
392 2013-05-09 12:08:21 <devurandom> So there is a rule that forbids duplicate transactions?
393 2013-05-09 12:08:24 <sipa> NO!
394 2013-05-09 12:08:34 <devurandom> But you just named the rule...?
395 2013-05-09 12:08:34 <sipa> there is a rule that forbids spending the same coin twice
396 2013-05-09 12:08:46 <chmod755> edcba, you mean like this: https://blockchain.info/tx/c0a758e4dbe0a10519e24c2dcea94307f978aca6adc2ebfedb8ab6e933fbfd1a ?
397 2013-05-09 12:08:48 <sipa> which is pretty much the most basic rule in bitcoin
398 2013-05-09 12:08:56 <sipa> no double spending allowed
399 2013-05-09 12:09:03 <chmod755> edcba, multiple inputs / outputs?
400 2013-05-09 12:09:13 <devurandom> But in the end its the same. Whether I forbid that a transaction hash appears twice, or I forbid the transaction to appear twice - same...
401 2013-05-09 12:09:23 <sipa> devurandom: NO
402 2013-05-09 12:09:37 <sipa> devurandom: it is not about forbidding the same transaction hash appearing twice
403 2013-05-09 12:09:44 <edcba> chmod755: yes but having 1 of inputs = 1 of outputs
404 2013-05-09 12:09:48 <cjd> devurandom: I could craft 2 completely different transactions which target the same money, that would be invalid
405 2013-05-09 12:09:48 <sipa> it is forbidding spending an input that is already spent
406 2013-05-09 12:10:13 <devurandom> And "already spent" means: appears in a lower block?
407 2013-05-09 12:10:19 <sipa> yes
408 2013-05-09 12:10:31 <t7> err, already spent in a lower block
409 2013-05-09 12:10:37 <sipa> or in the same block
410 2013-05-09 12:10:45 <devurandom> Well, has a transaction in a lower block that draws from this output.
411 2013-05-09 12:10:45 <eqolo> sipa: I feel very badly treated, please take a look: http://pastebin.com/Q7vwdeiR
412 2013-05-09 12:10:56 <cjd> devurandom: also it will not accept transactions into it's pool if it knows about one already which targets the same money
413 2013-05-09 12:11:03 <helo> eqolo: i addressed you in #bitcoin
414 2013-05-09 12:11:07 <cjd> that's what the patch on the list is all about
415 2013-05-09 12:11:08 <devurandom> Well, if it appears in the same block, the block itself is garbage...
416 2013-05-09 12:11:17 <edcba> so an address is either spent or has a constant amount of btc for its life ??
417 2013-05-09 12:11:17 <eqolo> sipa: Is this fair? What have I violated the rules, to get banned in this way?
418 2013-05-09 12:11:29 <sipa> eqolo: i have no authority in #bitcoin-otc
419 2013-05-09 12:11:39 <t7> eqolo, you sent 4 messages of the same thing
420 2013-05-09 12:11:43 <eqolo> sipa: but please take a look. and see what you think about it
421 2013-05-09 12:11:50 <edcba> helo: it's not #bitcoin complain service...
422 2013-05-09 12:12:00 <helo> edcba: better than in here
423 2013-05-09 12:12:04 <SomeoneWeird> eqolo, if you were banned you were banned for a reason, go discuss it with ne0futur
424 2013-05-09 12:12:14 <cjd> eqolo: it's always fair, how dare you question it (unless it was vaginaroda, in which case it is always unfair)
425 2013-05-09 12:12:30 <edcba> discuss it in private
426 2013-05-09 12:12:32 <sipa> devurandom: not more or less garbage than if the transaction already existed in a former block
427 2013-05-09 12:12:38 <eqolo> SomeoneWeird: <ne0futur> i wont answer then ne0futur You must log in with services to message this user
428 2013-05-09 12:12:47 <sipa> devurandom: or if the transaction would consume a coin already consumed by a different transaction
429 2013-05-09 12:13:01 <eqolo> i feel very bad about this. i didnt do anything
430 2013-05-09 12:13:04 <devurandom> ok, thanks
431 2013-05-09 12:13:05 <devurandom> And computing power controls who is able to double-spend? I.e. if the majority of the hashrate is in evil hands, they can create such transactions that draw from already spend outputs?
432 2013-05-09 12:13:17 <sipa> devurandom: within one chain you _cannot_ double spend
433 2013-05-09 12:13:30 <cjd> ^
434 2013-05-09 12:13:32 <edcba> if the majority decides something it's the rule...
435 2013-05-09 12:13:34 <sipa> devurandom: double spending always results from making someone believe one chain is valid, and than switching to another
436 2013-05-09 12:13:40 <sipa> edcba: NO NO NO
437 2013-05-09 12:13:42 <edcba> :)
438 2013-05-09 12:13:51 <cjd> hehe
439 2013-05-09 12:13:54 <devurandom> Ok, what's so bad about someone controling the majority of the hashrate?
440 2013-05-09 12:14:13 <cjd> they can roll back blocks by not mining against them
441 2013-05-09 12:14:18 <sipa> devurandom: because that means they can make a new longer chain, and have others switch to it
442 2013-05-09 12:14:19 <eqolo> cjd: take a look. ofc i dare question that, if i get banned for nothing
443 2013-05-09 12:14:22 <cjd> so you believe this is the chain and then suddenly it changes
444 2013-05-09 12:14:25 <edcba> i mean it's a futile exercise to imagine what happens when someone has >50%
445 2013-05-09 12:14:35 <SomeoneWeird> eqolo, this is very offtopic here, take it somewhere else
446 2013-05-09 12:14:38 <sipa> devurandom: double spending is a bad term, it should be called 'transaction cancelling'
447 2013-05-09 12:14:42 <devurandom> sipa: So double-spending is actually giving someone btc that dont actually exist to make the human happy, but he will later figure out that the money he has is actually forged?
448 2013-05-09 12:15:10 <edcba> ghost spending !
449 2013-05-09 12:15:15 <sipa> devurandom: bitcoin is a consensus system, designed to make the world agree as fast as possible about the order of transactions in history
450 2013-05-09 12:15:22 <sipa> devurandom: but it's not perfect
451 2013-05-09 12:15:47 <sipa> and if someone controls a majority of the hashpower, they get to cheat the system
452 2013-05-09 12:16:05 <sipa> but whatever happens, within _one_ chain, double spending is never possible
453 2013-05-09 12:16:27 <sipa> it's just because there are always chains competing with eachother, with typically only 1 or 2 blocks disagreement
454 2013-05-09 12:16:54 <cjd> Also ofc controlling a majority of the hashpower allows them to change the basic rules of the client and force nodes to autoupdate
455 2013-05-09 12:17:06 <sipa> cjd: ...
456 2013-05-09 12:17:07 <sipa> wut?
457 2013-05-09 12:17:09 <cjd> =)
458 2013-05-09 12:17:11 <devurandom> Ok, so as long as MrEvil builds on his wrong chain, he can put transactions in there and draw real inputs and pay people with it. But then at any moment he can build from an earlier block a new chain with completely new transactions that draw from the same inputs, and the people he formerly paid suddenly have invalid money?
459 2013-05-09 12:17:29 <sipa> devurandom: basically, yes
460 2013-05-09 12:17:49 <devurandom> cjd: autoupdate???
461 2013-05-09 12:18:04 <sipa> devurandom: he was kidding (i hope)
462 2013-05-09 12:18:10 <cjd> guize cmon
463 2013-05-09 12:18:10 <devurandom> Is the algorithm encoded within the blocks themselves?
464 2013-05-09 12:18:15 <sipa> devurandom: no!
465 2013-05-09 12:18:16 <devurandom> ok...
466 2013-05-09 12:18:18 <cjd> critical thinking !
467 2013-05-09 12:18:19 <sipa> devurandom: absolutely not
468 2013-05-09 12:18:31 <devurandom> Well, that would make autoupdate possible...
469 2013-05-09 12:18:37 <devurandom> A great feature :P
470 2013-05-09 12:18:44 <devurandom> Ok, thanks for explaining all this!
471 2013-05-09 12:18:55 <sipa> devurandom: it would also completely defeat (well, call it 'change') the basic security principles
472 2013-05-09 12:19:08 <devurandom> yeah
473 2013-05-09 12:19:11 <sipa> as it means the majority of hashpower gets to decide pretty much everything
474 2013-05-09 12:19:22 <sipa> they could vote to give themself a higher mining subsidy for example
475 2013-05-09 12:19:48 <sipa> which is pretty much the greatest thing about bitcoin: those creating money need to follow strict rules that can be verified by everyone
476 2013-05-09 12:19:57 <cjd> I think autoupdate would be a nice idea for a part of the code, namely the network facing stuff, certainly not hinging on the majority hashrate though and the autoupdate code would have to be sandboxed (IE: nacl)
477 2013-05-09 12:19:59 <devurandom> So, if I am mining and find a new block being published, I should check whether I believe it and then discard the transactions that are already contained in there, and then start hashing the remaining transactions?
478 2013-05-09 12:20:11 <sipa> devurandom: indeed
479 2013-05-09 12:20:21 <sipa> but you restart continuously anyway
480 2013-05-09 12:20:27 <devurandom> Why?
481 2013-05-09 12:20:41 <sipa> because it's just random hashing
482 2013-05-09 12:20:49 <sipa> there is no progress towards finding a block
483 2013-05-09 12:20:52 <devurandom> But on the other hand this means, that not all transactions will end up in blocks. Some will just never appear in any chain...?
484 2013-05-09 12:21:01 <sipa> why not?
485 2013-05-09 12:21:19 <sipa> which ones won't?
486 2013-05-09 12:21:48 <devurandom> re: random hashing: I have to try all nonces to be confident that this block is not hashable, right? I.e. before I havent tried all of them, I cannot say that it will never go below the target.
487 2013-05-09 12:22:50 <sipa> no, you don't need to try all nonces
488 2013-05-09 12:23:05 <devurandom> Well, if there is a new block every 10 minutes and the transactions in it are part of its hash, and I have to throw away my progress when a new block appears, that means that I have to backlog these transactions. So whether a transaction appears within a block is random.
489 2013-05-09 12:23:18 <sipa> there is no such thing as 'progress'
490 2013-05-09 12:23:25 <sipa> you just hash, and check, and hash and check
491 2013-05-09 12:23:34 <sipa> and every attempt has exactly the same chance as any other
492 2013-05-09 12:23:40 <cjd> 'progress' is an interesting falacy
493 2013-05-09 12:23:42 <sipa> whether they come from the same set of transactions or not
494 2013-05-09 12:23:50 <cjd> a lot of people think that it is real
495 2013-05-09 12:24:21 <hazrd> sipa, you oddball genius!!
496 2013-05-09 12:24:31 <devurandom> Ok... So miners will stop hashing this set of transactions at some point, when they believe it becomes unrealistic that there is a nonce that can hash it below the target?
497 2013-05-09 12:24:42 <sipa> devurandom: no
498 2013-05-09 12:24:47 <hazrd> i finally understand the underlying concept
499 2013-05-09 12:24:58 <cjd> hazrd: nope
500 2013-05-09 12:25:04 <cjd> bitcoin == russian doll
501 2013-05-09 12:25:06 <SirDefaced> i wonder if a progress based coin would even work.
502 2013-05-09 12:25:08 <cjd> you never understand it
503 2013-05-09 12:25:26 <devurandom> Blind men and an elephant?
504 2013-05-09 12:25:28 <sipa> devurandom: every few seconds or so they look at their memory pool, pick the transactions they like from it, build a block from it, and then try to hash for a while to find a nonce that solves it
505 2013-05-09 12:25:44 <devurandom> ok
506 2013-05-09 12:25:51 <sipa> devurandom: they don't throw away anything by switching to a new set of transactions a few seconds later
507 2013-05-09 12:25:55 <SirDefaced> how is nonce pronounced?
508 2013-05-09 12:26:02 <sipa> nons
509 2013-05-09 12:26:12 <SirDefaced> in my mind it was
510 2013-05-09 12:26:18 <SirDefaced> newonce idky
511 2013-05-09 12:26:24 <hazrd> cjd, but you can... the concept is that if you look deep enough, you will finally find the matroiska that isn't empty.... it's the source for all the others
512 2013-05-09 12:26:28 <devurandom> So they dont really care how many nonces they tried - at random times they just switch to a new block?
513 2013-05-09 12:26:36 <sipa> devurandom: yes
514 2013-05-09 12:26:54 <sipa> as long as you are constantly trying new block+nonce combinations, you can't do better
515 2013-05-09 12:27:03 <sipa> it doesn't matter whether they come from the same block or not
516 2013-05-09 12:27:24 <devurandom> Ok, and when a new block is published, they have to remove the transactions that are now spent from their pool?
517 2013-05-09 12:27:26 <hazrd> cjd, i'm being full of shit btw :P
518 2013-05-09 12:27:31 <sipa> devurandom: indeed
519 2013-05-09 12:27:37 <devurandom> sipa: "come from the same block"?
520 2013-05-09 12:27:39 <devurandom> Who?
521 2013-05-09 12:28:18 <sipa> devurandom: it doesn't matter whether you try all 4 billion nonce with one particular block candidate, or try 2 billion nonces from two block candidates each
522 2013-05-09 12:28:22 <sipa> devurandom: the chances are the same
523 2013-05-09 12:28:51 <devurandom> So every once in a while they build a new block from the current transactions and hope they find a nonce that fits? It does not matter at all how long they have been searching and so on. They just need to make sure not to mine the same block+nonce combinations twice?
524 2013-05-09 12:29:03 <sipa> devurandom: bing
525 2013-05-09 12:29:05 <sipa> devurandom: bingo
526 2013-05-09 12:29:12 <devurandom> Thanks a lot! :)
527 2013-05-09 12:29:28 <sipa> yw
528 2013-05-09 12:29:55 <devurandom> ymmd
529 2013-05-09 13:11:27 <jgarzik> http://bitcoinmagazine.com/btcd-a-full-bitcoin-alternative-written-in-go/
530 2013-05-09 13:12:56 <jgarzik> another incomplete full implementation ;p
531 2013-05-09 13:13:10 <BlueMatt> heh
532 2013-05-09 13:14:43 <BlueMatt> I have to say I'm amazed how much press they are generating for doing yet another full implementation
533 2013-05-09 13:14:51 <BlueMatt> and not having even gotten that far afawk
534 2013-05-09 13:15:37 <sipa> jgarzik: i don't call a serialization library "an implementation"
535 2013-05-09 13:16:51 <jgarzik> I don't either, but Bitcoin Magazine apparently does ;p
536 2013-05-09 13:17:05 <BlueMatt> " Importantly, there are no alternative implementations of Bitcoin that are currently being used to any significant degree by miners." uhhhhh...I hope not, and I sure as hell hope btcd doesnt get any mining uptake either
537 2013-05-09 13:21:59 <SomeoneWeird> so lame
538 2013-05-09 13:24:09 <jaromil> hype always brings lameness
539 2013-05-09 13:26:24 <jaromil> anyone here knows of people implementing again something like witcoin? I loved that so much that I might need to rewrite it, mpfh.
540 2013-05-09 13:29:24 <TD> jaromil: i guess the reddit tipbot is the closest
541 2013-05-09 13:31:53 <jgarzik> hah. "If Java had true garbage collection, most programs would delete themselves upon execution."
542 2013-05-09 13:32:50 <TD> lol
543 2013-05-09 13:33:07 <BlueMatt> so very true
544 2013-05-09 13:33:30 <sipa> ha
545 2013-05-09 13:33:36 <The_Fly> lol
546 2013-05-09 13:34:14 <cuqa> can someone give me the difficulty as displayed in bitcoin client pls? im trying to figure out how to calculate the target, but getting different numbers than on wiki
547 2013-05-09 13:34:14 <jaromil> :^D - TD 10x looking at it
548 2013-05-09 13:35:13 <sipa> ;;diff
549 2013-05-09 13:35:14 <gribble> 1.0076292883418716E7
550 2013-05-09 13:35:18 <sipa> cuqa: ^
551 2013-05-09 13:35:56 <jaromil> TD mmm tipbot is just for voluntary tips, not even sure it counts for rating up
552 2013-05-09 13:37:51 <cuqa> thanks
553 2013-05-09 13:38:49 <jgarzik> quite a significant number of "non-standard transaction type" when I login
554 2013-05-09 13:39:00 <jgarzik> 2013-05-09 15:37:05 ERROR: CTxMemPool::accept() : nonstandard transaction type
555 2013-05-09 13:39:18 <jgarzik> (login == when my bitcoind automatically starts after login, locally)
556 2013-05-09 13:39:32 <jgarzik> ACTION needs to put together a tx-logging patch, stat
557 2013-05-09 13:39:48 <jgarzik> If I had to guess, I would speculate these are dust
558 2013-05-09 13:40:06 <jgarzik> obviously higher number of incidents here, anyway, with HEAD
559 2013-05-09 13:40:34 <sipa> jgarzik: indeed, almost certainly dust
560 2013-05-09 13:41:03 <sipa> a better error message would be nice
561 2013-05-09 13:41:12 <jgarzik> yes
562 2013-05-09 13:41:15 <BlueMatt> jgarzik: or a block explorer that supports grepping debug.log for interesting txn
563 2013-05-09 13:41:30 <BlueMatt> (and a patch to dump them, obviously)
564 2013-05-09 13:41:30 <jgarzik> BlueMatt: debug.log doesn't tell you enough for that
565 2013-05-09 13:41:47 <jaromil> jgarzik: is that picocoin?
566 2013-05-09 13:42:04 <jaromil> oh no you wrote bitcoind sry
567 2013-05-09 13:42:17 <sipa> jgarzik: seen https://github.com/realazthat/overblock ?
568 2013-05-09 13:42:27 <jgarzik> As discussed yesterday, minimally invasive would be a -txdebug=1 optional setting, which dumps transactions to a secondary log.
569 2013-05-09 13:42:47 <jgarzik> i.e. full raw tx (perhaps plus time, IP, client info)
570 2013-05-09 13:43:19 <jgarzik> sipa: neat
571 2013-05-09 13:43:23 <BlueMatt> go for it
572 2013-05-09 13:45:24 <jgarzik> + reason for dump (dust / script / DER / ...)
573 2013-05-09 13:46:13 <sipa> :( dang, my libsecp256k1 unit test fails after running for 36 minutes
574 2013-05-09 13:46:30 <sipa> well, i guess it's good news that i have unit tests then...
575 2013-05-09 13:48:48 <BlueMatt> sipa: yay testing!
576 2013-05-09 13:49:34 <realazthat> sipa: hi
577 2013-05-09 13:50:18 <helo> what version of ubuntu is used to build for releases?
578 2013-05-09 13:50:27 <BlueMatt> lucid
579 2013-05-09 13:50:39 <sipa> realazthat: hi!
580 2013-05-09 13:56:43 <sipa> heh, how do i search the issues list on github?
581 2013-05-09 13:56:55 <sipa> i would have sworn there was a search box somewhere at the top of the page
582 2013-05-09 13:57:07 <BlueMatt> definitely used to be
583 2013-05-09 13:57:23 <BlueMatt> ge
584 2013-05-09 13:57:23 <BlueMatt> yes, very very top of the pate
585 2013-05-09 13:57:50 <BlueMatt> or https://github.com/bitcoin/bitcoin/search
586 2013-05-09 13:58:06 <wumpus> there used to be a search box in the issues list itself, but now there is only the general search at the top
587 2013-05-09 13:58:20 <realazthat> wumpus: hi
588 2013-05-09 13:58:21 <wumpus> I've already had my huh?! moment with that too
589 2013-05-09 13:58:28 <wumpus> hello realazthat
590 2013-05-09 13:58:47 <realazthat> wumpus: you doing anything interesting with bitcoin?
591 2013-05-09 13:58:56 <realazthat> you seem .... not idle
592 2013-05-09 13:59:15 <wumpus> realazthat: well, I hack on it sometimes, usually the gui stuff :)
593 2013-05-09 13:59:20 <realazthat> ah cool
594 2013-05-09 13:59:35 <realazthat> well, nice to see you :D
595 2013-05-09 13:59:41 <realazthat> not idling
596 2013-05-09 14:00:03 <wumpus> and you?
597 2013-05-09 14:00:10 <realazthat> mmm
598 2013-05-09 14:00:18 <realazthat> I done this: https://github.com/realazthat/overblock
599 2013-05-09 14:00:24 <realazthat> gonna try and improve it a bit
600 2013-05-09 14:01:36 <wumpus> looks like a useful concept
601 2013-05-09 14:01:47 <wumpus> a local block explorer
602 2013-05-09 14:01:57 <hazrd> why is .gov.us so full of crap with regard to cryptography!?
603 2013-05-09 14:02:17 <hazrd> i can't get a pre-compiled openssl lib with ECC for centos/redhat
604 2013-05-09 14:02:21 <hazrd> ARGH!
605 2013-05-09 14:02:57 <realazthat> wumpus: if you have any other useful ideas ...
606 2013-05-09 14:04:18 <sipa> realazthat: wumpus is the primary author of the Bitcoin-Qt GUI :)
607 2013-05-09 14:05:08 <sipa> BlueMatt: ok, and how do i search the issues list with that? :S
608 2013-05-09 14:05:09 <realazthat> sipa: oh cool
609 2013-05-09 14:05:19 <wumpus> realazthat: well it would indeed be nice to be able to browse the content of blocks (and look up the "balance" for arbitrary addresses) without consulting a centralized service, which also crashes half of the time :)
610 2013-05-09 14:05:21 <realazthat> sipa: haha, I know him from another channel
611 2013-05-09 14:05:48 <wumpus> sipa: you can search in the titles of issues with it, but it seems more limited than the old search
612 2013-05-09 14:06:01 <wumpus> maybe there's some special commands you can enter into the search box though...
613 2013-05-09 14:07:17 <BlueMatt> sipa: umm...click the issues button on the side and type something in the search box?
614 2013-05-09 14:07:26 <BlueMatt> (using the /search link)
615 2013-05-09 14:10:01 <wumpus> BlueMatt: ah now I get it, thanks https://github.com/bitcoin/bitcoin/search?type=Issues
616 2013-05-09 14:11:08 <sipa> wumpus: heh, how did you find that?
617 2013-05-09 14:11:19 <BlueMatt> ACTION just linked it?
618 2013-05-09 14:11:54 <sipa> ah, there's a link from the generic bitcoin/bitcoin search to only issues
619 2013-05-09 14:12:09 <BlueMatt> <BlueMatt> sipa: umm...click the issues button on the side and type something in the search box?
620 2013-05-09 14:12:09 <BlueMatt> <BlueMatt> (using the /search link)
621 2013-05-09 14:12:17 <BlueMatt> :0
622 2013-05-09 14:12:19 <BlueMatt> :)
623 2013-05-09 14:12:41 <sipa> ACTION needs to learn to read
624 2013-05-09 14:12:50 <BlueMatt> welcome to the club
625 2013-05-09 14:12:51 <sipa> hah: http://www.shirtoshi.com/shirt.php?id=6
626 2013-05-09 14:13:09 <BlueMatt> hah
627 2013-05-09 14:15:13 <sipa> (J)ohn Lennon, (P)aul McCartney, (G)eorge Harrison, Ringo (S)tarr ?
628 2013-05-09 14:16:34 <wumpus> hehe
629 2013-05-09 14:27:35 <gmaxwell> 08:44 < sipa> :( dang, my libsecp256k1 unit test fails after running for 36 minutes
630 2013-05-09 14:27:42 <gmaxwell> \\O/ Hurray for testing!
631 2013-05-09 14:28:01 <BlueMatt> gmaxwell: I had the exact same response
632 2013-05-09 14:44:49 <NxTitle> libsecp256k1?
633 2013-05-09 14:54:37 <Edward_Black> A quick question - when bitcoin hashes the block twice, does that actually mean 2 rounds of SHA256, or 2*(recommended number of SHA256 rounds), which would amount to 128 rounds of SHA256 total ?
634 2013-05-09 14:55:08 <sipa> it's SHA256(SHA256(blockheader))
635 2013-05-09 14:55:56 <sipa> since the blockheader is 80 bytes, that means the inner SHA256 processes two data blocks (it uses 64 bytes per input data block), and the processing of each input data block needs 64 rounds
636 2013-05-09 14:56:32 <sipa> the ouput is 32 bytes, so the outer SHA256 only processes one input data block
637 2013-05-09 14:56:39 <sipa> i.e., 192 rounds in total
638 2013-05-09 14:57:28 <Edward_Black> Thanks
639 2013-05-09 14:58:28 <sipa> NxTitle: my own efficient implementation of ecdsa/secp256k1
640 2013-05-09 14:59:49 <NxTitle> ahh, I see
641 2013-05-09 15:10:32 <anarchy5> sipa: isnt the input work block always 512 bits, just padded with constants, plus not all 80 bytes of the header are hashed (just a few of them)
642 2013-05-09 15:10:56 <skinnkavaj> https://blog.conformal.com/btcd-a-bitcoind-alternative-written-in-go/ what do you think of this?
643 2013-05-09 15:13:23 <sipa> anarchy5: input block is indeed always 512 bits, so the 80 bytes input are padded to 128 bytes before feeding to the block processing function
644 2013-05-09 15:13:30 <sipa> anarchy5: and all 80 bytes of the header are hashed
645 2013-05-09 15:13:37 <sipa> skinnkavaj: too early to judge
646 2013-05-09 15:14:37 <gmaxwell> skinnkavaj: it's currently only deserialization code.
647 2013-05-09 15:14:48 <nsh> sipa, what's a sane strategy to a/b test new implementations against the reference bitcoind?
648 2013-05-09 15:15:02 <nsh> is there some protocol test suite, or could one be devised easily?
649 2013-05-09 15:15:16 <nsh> (et al)
650 2013-05-09 15:15:26 <gmaxwell> nsh: bluematt created an agreement tester.
651 2013-05-09 15:15:37 <gmaxwell> It's far from perfect, but it tests a lot.
652 2013-05-09 15:16:04 <nsh> right on
653 2013-05-09 15:16:34 <nsh> would it make sense to abstract the protocol to a BNF specification or something similar?
654 2013-05-09 15:16:40 <gmaxwell> No.
655 2013-05-09 15:16:43 <Diablo-D3> [01:09:09] <anarchy5> sipa: isnt the input work block always 512 bits, just padded with constants, plus not all 80 bytes of the header are hashed (just a few of them)
656 2013-05-09 15:16:46 <Diablo-D3> learn how sha256 works kthx
657 2013-05-09 15:16:49 <nsh> i've no experience in this department
658 2013-05-09 15:17:07 <gmaxwell> nsh: the wire protocol itself is pretty uninteresting. It's not essential to bitcoin cat all.
659 2013-05-09 15:17:12 <gmaxwell> s/cat/at/
660 2013-05-09 15:17:20 <Diablo-D3> BITCOIN CAT
661 2013-05-09 15:18:52 <anarchy5> Diablo-D3: i was talking about mining, not hashing the merkle tree, wrong context
662 2013-05-09 15:18:55 <gmaxwell> nsh: the important and hard part is the distributed consensus algorithim??? a pure mathmatical function that when presented with sequences of blocks, determines their validity, and selects the unique best chain.
663 2013-05-09 15:19:04 <nsh> mmm
664 2013-05-09 15:19:10 <Diablo-D3> anarchy5: I wrote a miner. Your turn.
665 2013-05-09 15:19:11 <nsh> ACTION nods
666 2013-05-09 15:19:56 <nsh> but there is perhaps some analogous abstract way to specify this that is language-independent which would facilitate reimplementation in new code
667 2013-05-09 15:20:35 <nsh> hmm, perhaps not one with any particular currency...
668 2013-05-09 15:20:56 <Diablo-D3> nsh: gmaxwell was right about the wire protocol not being essential
669 2013-05-09 15:21:02 <Diablo-D3> neither is the on disk format
670 2013-05-09 15:21:05 <Diablo-D3> its just a set of rules
671 2013-05-09 15:21:42 <gmaxwell> nsh: you can certantly write it in other ways ... but "would facilitate reimplementation in new code" is less clear??? I mean, it is code.
672 2013-05-09 15:22:25 <gmaxwell> nsh: so, e.g. you could write an expression of it that could be translated into other languages, but the trainslations must be faithful.
673 2013-05-09 15:23:01 <nsh> ok
674 2013-05-09 15:24:52 <nsh> i think i was straining towards something like PlusCal, but that does not appear to be a very mature language/project. it seems to me there ought to be better standardised ways to specify in a language-agnostic fashion the essentials of an algorithm/algorithm-set
675 2013-05-09 15:24:53 <gmaxwell> and part of the problem is that the behavior of openssl and potentially some behavior of leveldb, potentially some behavior of boost, etc. is incorporated by reference currently.
676 2013-05-09 15:25:05 <nsh> that would allow for easy testing