1 2014-05-28 00:55:58 <andytoshi> CoinVault
2 2014-05-28 01:14:31 <Luke-Jr> hrm, searching for it fails :x
3 2014-05-28 01:26:17 <CoinHeavy> what is the âchainworkâ attribute on each block?
4 2014-05-28 01:34:53 <andytoshi> Luke-Jr: he might not have published the code, i have git access to his repo from months ago when he asked for testers, but i don't think there is anonymous access
5 2014-05-28 01:34:58 <andytoshi> so you'll have to msg him and ask
6 2014-05-28 01:36:37 <andytoshi> oh, i'm lying, it's at https://github.com/ciphrex/CoinVault
7 2014-05-28 05:39:08 <dcousens> Hey all, why are the inputs for this test data: https://github.com/bitcoin/bitcoin/blob/master/src/test/data/tx_valid.json#L57 out of order?
8 2014-05-28 05:39:44 <dcousens> The serialized tx has inputs 0002000... 0001000 ...., yet the expected inputs are 0001000, 0002000 (reversed)
9 2014-05-28 05:41:09 <dcousens> By reversed, I mean in order, not endianness.
10 2014-05-28 05:44:06 <dcousens> It appears the tests are using a hashmap to add these inputs... so maybe that is why?
11 2014-05-28 05:44:25 <dcousens> (A bit frustrating, in any case)
12 2014-05-28 05:49:56 <wumpus> dcousens: that sounds wron
13 2014-05-28 05:50:13 <wumpus> seems the test is wrong, if that passes
14 2014-05-28 05:50:32 <dcousens> wumpus: https://github.com/bitcoin/bitcoin/blob/master/src/test/transaction_tests.cpp#L123 it is adding them to a hashmap then checking them
15 2014-05-28 05:50:35 <dcousens> so the order is irrelevant
16 2014-05-28 05:50:43 <dcousens> Why they decided to use a hashmap, is beyond me
17 2014-05-28 05:50:51 <dcousens> Its the only test that isn't in order
18 2014-05-28 05:51:16 <wumpus> I'd say fix the test so that this doesn't pass, then update the data so that it passes again
19 2014-05-28 05:51:36 <dcousens> wumpus: so you think I should submit a PR for this?
20 2014-05-28 05:51:51 <wumpus> yes
21 2014-05-28 05:57:55 <SomeoneWeird> fix all the things
22 2014-05-28 06:02:58 <wumpus> dcousens: I see it builds a map mapprevOutScriptPubKeys, but it doesn't iterate over it in that test function
23 2014-05-28 06:03:25 <wumpus> in the for loop where it does the checking it iterates over tx.vin in-order
24 2014-05-28 06:04:09 <wumpus> I don't see anywhere where it relies on the order of the resulting map, but I may be missing something
25 2014-05-28 06:04:18 <shaileshg> Hi, I have been trying to get my head around coloured coins..
26 2014-05-28 06:04:30 <dcousens> wumpus: and in that iteration, it then does mapprevOutScriptPubKeys[tx.vin[i].prevout
27 2014-05-28 06:04:34 <shaileshg> what is the difference between bitcoin & colored coins from developer point of view?
28 2014-05-28 06:04:45 <wumpus> dcousens: yes it does a lookup, ordering does not affect that
29 2014-05-28 06:04:48 <shaileshg> referring to this doc: https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit
30 2014-05-28 06:04:52 <dcousens> wumpus: right, I never said it did
31 2014-05-28 06:05:31 <dcousens> I just said, unlike every test data there, it is the only one with which the lookup is necessary, the others are all in order
32 2014-05-28 06:05:35 <shaileshg> is this the right forum to discuss about CC?
33 2014-05-28 06:05:44 <dcousens> shaileshg: probably not, maybe #bitcoin
34 2014-05-28 06:05:52 <wumpus> dcousens: ok, then it looks to me that the test is correct
35 2014-05-28 06:06:01 <dcousens> wumpus: it is correct, its just odd
36 2014-05-28 06:07:02 <dcousens> wumpus: I just don't know why they bother building the hashmap at all, if almost all the test data is in the same order it will be deserialized
37 2014-05-28 06:07:15 <dcousens> And was wondering if anyone knew why
38 2014-05-28 06:07:41 <shaileshg> dcousens: kk. Do CC have a different blockchain?
39 2014-05-28 06:08:15 <dcousens> shaileshg: what? No? Depends? Wrong channel.
40 2014-05-28 06:08:54 <shaileshg> dcousens: hmm
41 2014-05-28 06:09:17 <wumpus> dcousens: it is similar to how things are done in bitcoin internally, I suppose, having an index of unspent coins and looking up the scriptpubkey in that
42 2014-05-28 06:15:45 <dcousens> wumpus: well, I might clear it out, and if it is simpler than before, I see no reason why it wouldn't be a worthwhile improvement
43 2014-05-28 06:17:26 <dcousens> wumpus: in any case, if we just reverse the order of the inputs on that test data, the entire file will have identical input orders between the expected and serialized transactions
44 2014-05-28 06:17:32 <wumpus> I think documenting the format of the tests would be much more worthwhile
45 2014-05-28 06:17:50 <dcousens> wumpus: true... but that is less likely to be a small change
46 2014-05-28 06:17:57 <petertodd> elichai2: thanks!
47 2014-05-28 06:24:30 <petertodd> sl01: my lecture wasn't on politics per-se, but rather how the bitcoin protocol inherently depends on it because it has only a linearly strong defense against attackers whereas standard crypto creates an exponentialy strong defense
48 2014-05-28 07:38:31 <kiddouk> I am trying to get the wallet address from a privatekey that I get with "Dumpprivkey". For that I base58decode_check the privatekey â so far so good. When trying to get the public key out of the private key with ecdsa.SigningKey.from_key(privatekey), it turns that the private key that I provide is "too long". What do I do wrong when I b58decode ? (working on testnet3).
49 2014-05-28 07:46:06 <kiddouk> put in a simple way, how can I convert WIF to Private Key correctly?
50 2014-05-28 07:47:14 <kiddouk> ok, nm, I found my answer (that was right in front of my eyes): https://en.bitcoin.it/wiki/Wallet_import_format
51 2014-05-28 08:51:39 <sl01> petertodd: got it, makes sense
52 2014-05-28 12:02:43 <harding> wumpus (and others): is there any existing Bitcoin-specific documentation for the tests besides the short readme in src/test? Is Core doing anything different from other software using the boost testing framework?
53 2014-05-28 12:19:03 <shaileshg> has anyone tried colored coins?
54 2014-05-28 12:19:28 <shaileshg> is it in practice as part of ecosystem or exists in theory only?
55 2014-05-28 12:21:15 <Luke-Jr> shaileshg: theory mainly; also lacks a solid use case
56 2014-05-28 12:21:28 <Luke-Jr> although smart property may make for one
57 2014-05-28 12:21:45 <shaileshg> Luke-Jr: I was coming to smart property use case
58 2014-05-28 12:21:59 <shaileshg> is it better to be done using colored coins approach or side chains one?
59 2014-05-28 12:22:23 <Luke-Jr> daughter-chains can experiment with new ideas in general
60 2014-05-28 12:23:04 <shaileshg> Luke-Jr: hmm. I am trying to explore using bitcoins (blockchain) to digitize physical assets
61 2014-05-28 12:23:20 <shaileshg> what is daughter chains?
62 2014-05-28 12:23:36 <Luke-Jr> I presume what you know as side-chains, but less ambiguous
63 2014-05-28 12:24:23 <shaileshg> is it documented anywhere for look-up?
64 2014-05-28 12:28:23 <shaileshg> Luke-Jr: is there any white paper on so called daughter chains?
65 2014-05-28 12:28:41 <Luke-Jr> not afaik
66 2014-05-28 12:30:10 <shaileshg> k
67 2014-05-28 12:39:02 <hearn> shaileshg: did you read the wiki page on smart property?
68 2014-05-28 12:39:08 <hearn> that definition, at least, does not require any alternative chains
69 2014-05-28 12:39:31 <shaileshg> hearn: yes. I am reading wiki page on smart property & contracts - both
70 2014-05-28 12:40:32 <shaileshg> looking at how to implement one for poc purpose
71 2014-05-28 13:15:54 <maaku> colored coins have some pretty solid use cases, just some real intrinsic limitations
72 2014-05-28 13:16:06 <maaku> i would recommend looking at chromawallet, which has a better technical design
73 2014-05-28 13:19:48 <hearn> Luke-Jr: the problem with your spam filter is that you still have to process all the transactions you drop, when they get confirmed, so it achieves nothing in that regard. and it makes it easier to steal from other people. it seems like a lose/lose setup, to me
74 2014-05-28 13:20:05 <hearn> i know you don't like dice sites, but from a technical perspective there doesn't seem much point
75 2014-05-28 13:21:44 <maaku> imho if you choose to drop a transaction for spam reasons, you should still remember its inputs and not accept double-spends (at least for some period of time)
76 2014-05-28 13:22:05 <Luke-Jr> hearn: they shouldn't ever be confirmed.
77 2014-05-28 13:22:12 <hearn> but they are.
78 2014-05-28 13:22:24 <Luke-Jr> not if all miners finally get their act together
79 2014-05-28 13:22:48 <hearn> there's no consensus about blocking dice sites, so that's not going to happen. but even if there was, those sites make money: the operators would just stop reusing addresses, and then it'd be pointless once again.
80 2014-05-28 13:23:19 <Luke-Jr> it's called sanity.
81 2014-05-28 13:24:16 <hearn> why do you drop them from the mempool as well as block selection? ease of implementation?
82 2014-05-28 13:24:39 <Luke-Jr> security
83 2014-05-28 13:25:11 <_1_Micky152> hi
84 2014-05-28 13:25:23 <stonecoldpat> why would the dice sites even be blocked ?
85 2014-05-28 13:25:35 <_1_Micky152> hi
86 2014-05-28 13:25:55 <maaku> stonecoldpat: because the ones that send negative replies via the block chain are bloating the utxo
87 2014-05-28 13:26:12 <Luke-Jr> stonecoldpat: referring to the ones that are DDoS attacks against Bitcoin
88 2014-05-28 13:26:36 <hearn> how does it improve security?
89 2014-05-28 13:28:06 <hearn> i can see how it *reduces* security (for the sites you don't like). i do not see how it improves security
90 2014-05-28 13:29:36 <Luke-Jr> prevents the spam from filling my mempool and crowding out legitimate transactions
91 2014-05-28 13:30:49 <hearn> but you have to be able to hold them anyway. otherwise if dice sites start switching to non-reused addresses, you would run out of memory, your node would die, and your pool would go down.
92 2014-05-28 13:31:10 <hearn> a security model that only works as long as your adversaries care about branding more than functionality, is not really a security policy at all
93 2014-05-28 13:31:29 <Luke-Jr> if dice sites start switching to non-reused addresses, then the spam filter just stops working
94 2014-05-28 13:32:09 <Luke-Jr> nobody's pretending the current filter is ideal, but it's the best we have
95 2014-05-28 13:44:49 <stonecoldpat> luke-jr: is there any data to suggest that dice sites have delayed other transactions?
96 2014-05-28 13:45:17 <Luke-Jr> stonecoldpat: if the blockchain itself counts as data; that's not the only damage they do, though
97 2014-05-28 13:45:35 <Luke-Jr> for example, fewer people are running full bitcoin nodes since there's like 5 GB of dice spam
98 2014-05-28 13:53:35 <dgenr8> Luke-Jr: miners getting their act together = never mining a tx whose inputs were seen being spent already
99 2014-05-28 13:54:25 <Luke-Jr> dgenr8: wat? that doesn't even make sense
100 2014-05-28 13:57:06 <hearn> why not? sure it does
101 2014-05-28 13:58:25 <helo> dgenr8: miners can only be expected to just mine... using a variety of approaches, with varied motivations, etc. you can't really expect a rallying cry to do much of anything.
102 2014-05-28 13:58:44 <Luke-Jr> if the inputs were spent already, the block would be invalid if it included the tx
103 2014-05-28 13:59:33 <hearn> Luke-Jr: he means, spent against the mempool. that is, if you drop transactions because you don't like them, you'd still mark the outputs they used as spent, and refuse to accept other txns into the mempool that double spent the dropped tx
104 2014-05-28 14:00:31 <Luke-Jr> hearn: why? that doesn't seem obvious at all
105 2014-05-28 14:00:54 <Luke-Jr> if someone corrects the problematic transaction, no reason not to mine it
106 2014-05-28 14:00:56 <hearn> because double spending is bad?
107 2014-05-28 14:01:09 <Luke-Jr> not all double spending is bad.
108 2014-05-28 14:01:21 <Luke-Jr> a case can be made that double spending spam is always good, in fact
109 2014-05-28 14:01:29 <hearn> i thought it would boil down tot his
110 2014-05-28 14:01:33 <Luke-Jr> it prevents the spam from being mined ever
111 2014-05-28 14:01:48 <hearn> basically, you like trying to ensure "spammers" as you see them lose money, and are willing to assist in fraud against them
112 2014-05-28 14:01:59 <Luke-Jr> um, no.
113 2014-05-28 14:02:20 <dgenr8> The "valid use cases" for authoring txes that spend the same funds twice are wholly unconvincing
114 2014-05-28 14:03:03 <dgenr8> child-pays-for-parent is an excellent way to bump fees though
115 2014-05-28 14:03:08 <Luke-Jr> also, lol @ "fraud" when you're talking about people *attacking* the network, and regularly committing fraud themselves
116 2014-05-28 14:03:33 <Luke-Jr> dgenr8: CPFP works in some cases, but not all. In the other cases, double spending works.
117 2014-05-28 14:03:41 <Luke-Jr> dgenr8: both methods to bump fees are necessary
118 2014-05-28 14:03:47 <Luke-Jr> to cover all circumstances
119 2014-05-28 14:05:38 <hearn> the only kind of attacker mentioned in the original white paper are double spenders. but whatever. i wanted to know if your policy of allowing double spends was just because that was easiest to implement, or because you actually like double spends, and now i know the answer
120 2014-05-28 14:06:18 <Luke-Jr> indeed, Satoshi didn't foresee this attack
121 2014-05-28 14:06:43 <hearn> i'd say the notion of priority and tx fees means he rather did forsee people disagreeing about how to best use block space.
122 2014-05-28 14:07:16 <Luke-Jr> he foresaw one kind of spam, but not the kind that can fool victims into funding their attack
123 2014-05-28 14:09:14 <dgenr8> Luke-Jr: have you considered that a miner with 10%, enforcing a consensus rule against respends aged > T seconds, could raise the expected cost of mining a respend to at least .25 BTC? The effect would be to make bitcoin immeasurably more useful.
124 2014-05-28 14:10:13 <Luke-Jr> dgenr8: not really. you can never trust 0 confirm transactions period
125 2014-05-28 14:10:32 <Luke-Jr> pretending anything will change that is ill-advised
126 2014-05-28 14:11:57 <dgenr8> Luke-Jr: repeating accepted wisdom is always safe
127 2014-05-28 14:12:59 <hearn> i wouldn't even call that accepted wisdom, given how widespread a practice it is
128 2014-05-28 14:13:15 <hearn> but regardless these debates are old and tired.
129 2014-05-28 14:13:48 <hearn> it's unfortunate that the bitcoin community can't agree on something so basic, but that's how it is, and it may be that bitcoin ends up simply not being routinely used for online payments as a result.
130 2014-05-28 14:14:34 <Luke-Jr> lol, as if online payments are even affected by this
131 2014-05-28 14:14:46 <Luke-Jr> offline payments, I can see a (minor) concern, but online? lol
132 2014-05-28 14:17:01 <hearn> by far, most merchants are using services like bitpay and coinbase, which don't seem to expect merchants to handle double spending. at least i've yet to ever be told to wait a confirmation before i'm sent back to the merchants "thankyou for payment" page.
133 2014-05-28 14:17:39 <Luke-Jr> I wouldn't expect you to. You're not trying to double spend, after all.
134 2014-05-28 14:17:47 <hearn> i know it's what we expected to happen, but it seems it just doesn't. perhaps most online shops don't have the backend procedures in place to handle anything other than long-delayed chargebacks
135 2014-05-28 14:17:50 <Luke-Jr> (double spend is a matter between BitPay and the merchant to deal with)
136 2014-05-28 14:18:38 <dgenr8> those services are absorbing the cost for now. the scale of the usability problem is not minor though. it's pretty huge.
137 2014-05-28 14:19:49 <Luke-Jr> dgenr8: online merchants either offer revocable goods/services (hosting, subscriptions, etc) or shipped goods
138 2014-05-28 14:19:58 <Luke-Jr> shipped goods take time to ship, well over an hour usually
139 2014-05-28 14:20:16 <Luke-Jr> and revocable stuff can be .. revoked
140 2014-05-28 14:20:34 <dgenr8> no, i am talking about the offline usability problem. Where you want to buy something, in an actual shop, and leave.
141 2014-05-28 14:20:47 <dgenr8> as hearn said so eloquently
142 2014-05-28 14:20:52 <hearn> actually i pretty frequently buy takeout food online, and its delivered within half an hour most often
143 2014-05-28 14:21:00 <hearn> it's not uncommon to have a block that takes longer than half an hour
144 2014-05-28 14:21:12 <BlueMatt> where does one go to get a circle invite around here anymore?
145 2014-05-28 14:21:13 <hearn> so that's a case where something is shipped, but it still has to be unconfirmed
146 2014-05-28 14:21:18 <Luke-Jr> dgenr8: offline is a minor problem because it's one merchants already need to deal with (bounced checks)
147 2014-05-28 14:21:47 <aschildbach_> Luke-Jr: Somehow I cannot reach your http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
148 2014-05-28 14:22:15 <hearn> Luke-Jr: nobody uses cheques outside the USA anymore. everywhere else is busy upgrading to NFC chip cards that can give a virtually cast-iron guarantee of payment in <500msec
149 2014-05-28 14:22:54 <BlueMatt> hearn: you've seen the attacks on emv, right?
150 2014-05-28 14:23:02 <hearn> yes, i read all those papers
151 2014-05-28 14:23:04 <Luke-Jr> aschildbach_: XO.net is performing a DoS on my webserver; IPv6 is unaffected, and usually at least one of the two IPs in DNS can be reached (right now, .20 seems to work)
152 2014-05-28 14:23:08 <hearn> they're all either fixed or impractical
153 2014-05-28 14:23:10 <Luke-Jr> (from my DSL anyhow)
154 2014-05-28 14:23:17 <hearn> actual observed fraud with EMV is not something any merchants worry about
155 2014-05-28 14:23:22 <BlueMatt> hearn: several of them have been exploited!
156 2014-05-28 14:23:45 <Luke-Jr> hearn: cast-iron guarantee it won't be charged back?
157 2014-05-28 14:23:48 <BlueMatt> well, ok, the problem with emv isnt that there's attacks, its that when they are exploited on a very small scale, people aren't insured against fraud anymore
158 2014-05-28 14:24:22 <aschildbach_> BlueMatt: afaik not in Germany
159 2014-05-28 14:24:31 <BlueMatt> aschildbach_: yes, depends on country
160 2014-05-28 14:24:34 <hearn> Luke-Jr: banks don't normally let you charge back things you took in person
161 2014-05-28 14:24:38 <BlueMatt> I was referring to the research in the uk, mostly
162 2014-05-28 14:24:49 <BlueMatt> hearn: they do in the us! :p
163 2014-05-28 14:25:10 <hearn> yes yes. we're talking about places that aren't hopelessly backwards. the US has to allow chargebacks very easily because the whole infrastructure is so insecure
164 2014-05-28 14:25:13 <Luke-Jr> hearn: the merchant doesn't know if the person they're handing it over to is using a stolen card
165 2014-05-28 14:25:37 <hearn> merchants don't have liability for EMV transactions
166 2014-05-28 14:25:43 <hearn> i mean, liability for stolen cards
167 2014-05-28 14:25:54 <hearn> it's either carried by the bank (if no PIN was requested) or by the user (if the correct PIN was entered)
168 2014-05-28 14:26:14 <hearn> so yeah. from the perspective of an ordinary shop it's a pretty good guarantee
169 2014-05-28 14:26:14 <Luke-Jr> hearn: I think they do in the US
170 2014-05-28 14:26:28 <hearn> yes, they do, but the US is finally upgrading to EMV. or at least they're saying they will.
171 2014-05-28 14:26:33 <hearn> ACTION heard this story before: will reserve judgement
172 2014-05-28 14:26:46 <hearn> it'll take years but eventually it'll be the same story everywhere
173 2014-05-28 14:27:14 <Luke-Jr> ok well, unfortunately, the blockchain cannot provide that kind of guarantee
174 2014-05-28 14:27:16 <BlueMatt> hearn: well, the issues with emv is that the user /ever/ has the liability, which they shouldnt...ofc it should also not be the merchant on the hook for the bank's poor security
175 2014-05-28 14:27:26 <hearn> aschildbach_: i can load luke's page. it says 89% on 0.8.x and 7% on 0.9.x .... rather different to what getaddr.bitnodes.io reports
176 2014-05-28 14:27:29 <Luke-Jr> so I guess Visa et al have a value-added service they can provide on top of Bitcoin
177 2014-05-28 14:27:42 <hearn> BlueMatt: users have liability because so many people want to do things like write their PIN on the card itself
178 2014-05-28 14:28:06 <BlueMatt> heh, ok, fair point
179 2014-05-28 14:28:08 <hearn> BlueMatt: I think the current arrangement is pretty fair. There have been exploits, like with any computer system, and ideally banks would detect all of them internally. but they've been fixed. in practice it's not a problem.
180 2014-05-28 14:28:27 <hearn> and the core of the system, the chip itself, has AFAIK never been beaten
181 2014-05-28 14:28:37 <hearn> the exploits have all been protocol level things or stuff like bad RNGs in ATMs
182 2014-05-28 14:28:51 <aschildbach_> hearn: Yeah it was very different 1 month ago, too.
183 2014-05-28 14:29:00 <hearn> aschildbach_: i think luke's page is measuring addr broadcasts
184 2014-05-28 14:29:36 <Luke-Jr> my page is just bitcoin-seeder's report
185 2014-05-28 14:29:49 <Luke-Jr> filtered against nodes that haven't been connected to recently
186 2014-05-28 14:30:26 <BlueMatt> hearn: ehhh, ok but if the protocol is horrendously complicated , protocol breaks are just as important as anything else
187 2014-05-28 14:30:40 <BlueMatt> its hard to upgrade when its all in hardware that is literally in every freaking store in the country
188 2014-05-28 14:30:44 <aschildbach_> hearn: I don't think its a propagation problem. Remember how the sochi spam stayed in the network despite only 10% of notes relaying it?
189 2014-05-28 14:30:56 <aschildbach_> nodes
190 2014-05-28 14:31:31 <hearn> BlueMatt: iirc the fixes so far were all possible on the bank server side. except maybe the bad ATMs. but those could be identified remotely, so then the next time they get refilled they can get a firmware upgrade. the other attack i can remember was implausible
191 2014-05-28 14:32:12 <BlueMatt> hmm...quite possibly, my point is more that when you have a written-by-committee, horrendously complicated protocol, you're gonna end up with problems
192 2014-05-28 14:32:18 <hearn> BlueMatt: at any rate, there are graphs of card fraud available. card-present fraud was pretty decimated by EMV rollouts, though it does still happen because of places like the USA that never upgrade.d
193 2014-05-28 14:32:27 <BlueMatt> indeed
194 2014-05-28 14:32:50 <hearn> sure. the EMV protocols are horrible because they're evolved from really old visa/mc internal stuff, if i understand correctly. sort of 20-30 years of backwards compatibility.
195 2014-05-28 14:33:01 <BlueMatt> heh, oh gawd
196 2014-05-28 14:34:30 <hearn> i heard something interesting at the conference. apparently 10-15 years ago there was work done to have embedded card readers in laptops and desktops ,that could be used for EMV
197 2014-05-28 14:34:49 <hearn> but it got sunk because the technical guys made a system where the reader was programmable, so anyone could have made their own payment network
198 2014-05-28 14:34:57 <hearn> not sure how true that is
199 2014-05-28 14:34:59 <BlueMatt> heh
200 2014-05-28 14:35:09 <BlueMatt> i could see that
201 2014-05-28 14:37:06 <hearn> aschildbach_: my node would include my tx in its block, btw. i wish miners embedded their fee policy in the coinbases
202 2014-05-28 14:37:12 <hearn> it'd make it so much easier to understand network behaviour
203 2014-05-28 14:37:33 <hearn> s/fee policy/block policy/
204 2014-05-28 14:38:12 <Luke-Jr> hearn: +1 on that
205 2014-05-28 14:38:28 <hearn> good to know we at least agree on that :)
206 2014-05-28 14:38:40 <Luke-Jr> ideally as a pubsub link, so it can be updated
207 2014-05-28 14:39:13 <Luke-Jr> (eg, a keyhash that is allowed to relay updates every so often)
208 2014-05-28 14:40:25 <hearn> hmm, interesting. so mining a block allows you to broadcast data over the p2p network for a little while?
209 2014-05-28 14:40:50 <BlueMatt> black policy as in...?
210 2014-05-28 14:41:22 <Luke-Jr> hearn: within reason of course
211 2014-05-28 14:41:29 <hearn> sure
212 2014-05-28 14:41:42 <Luke-Jr> BlueMatt: some way to express fees expected, etc
213 2014-05-28 14:41:47 <hearn> BlueMatt: min fee required to get in, set of IsStandard rules applied etc.
214 2014-05-28 14:41:48 <BlueMatt> yea
215 2014-05-28 14:42:08 <Luke-Jr> maybe mempool expiration, replacement terms, etc
216 2014-05-28 14:42:20 <BlueMatt> well since its just for informational purposes and wouldnt really be used by clients (I'd guess), you could just publish a url to a terms page...
217 2014-05-28 14:42:31 <helo> (and lie through their teeth?)
218 2014-05-28 14:42:42 <Luke-Jr> BlueMatt: clients should be able to use it ;)
219 2014-05-28 14:42:44 <BlueMatt> maybe non-standards clients would want to figure it automatically
220 2014-05-28 14:42:48 <Luke-Jr> helo: what good would that do?
221 2014-05-28 14:43:04 <BlueMatt> Luke-Jr: well, what could it be used for? I mean you cant use it, really, for fees
222 2014-05-28 14:43:16 <BlueMatt> so you get into advanced usage pretty fast
223 2014-05-28 14:43:41 <helo> roughly as much as them telling the truth
224 2014-05-28 14:45:05 <Luke-Jr> BlueMatt: sure you can
225 2014-05-28 14:48:43 <chichov> what's wrong with a node where startingheight is -1?
226 2014-05-28 14:48:54 <BlueMatt> it has no genesis block
227 2014-05-28 14:49:30 <chichov> so it doesn't store the blockchain or what does that mean then?
228 2014-05-28 14:49:35 <hearn> means it's buggy
229 2014-05-28 14:49:39 <BlueMatt> it means it is very, very confused
230 2014-05-28 14:49:46 <buZz> or its not on bitcoin
231 2014-05-28 14:50:02 <chichov> I have one here, running the satoshi client 0.8.1
232 2014-05-28 14:50:40 <chichov> whatever is wrong with him, thanks for the info!
233 2014-05-28 14:50:43 <BlueMatt> heh, swiss banks are very receptive to skipping the usual requirements when americans are trying to close an account
234 2014-05-28 14:50:54 <hearn> i bet
235 2014-05-28 14:51:11 <buZz> america says jump, the world asks how high
236 2014-05-28 14:51:54 <BlueMatt> america says "we dont like your bank secrecy", Switzerland says "fuck you too, we're just not gonna give americans accounts anymore"
237 2014-05-28 15:09:41 <crunk-ju_> are Coinbase generated buttons not showing up for others here?
238 2014-05-28 15:30:39 <hearn> how does ghash.io make money?
239 2014-05-28 15:36:15 <sl01> hearn: do you have any theories?
240 2014-05-28 15:36:26 <hearn> presumably subsidised by their cloud mining thing
241 2014-05-28 15:36:47 <sl01> so their pool is jsut marketing for cex?
242 2014-05-28 15:37:10 <hearn> i have no idea. that's why i was asking. i just noticed they don't charge any pool fees
243 2014-05-28 15:37:35 <hearn> Luke-Jr: btw what version of Core is eligius running at the moment?
244 2014-05-28 15:41:05 <shesek> hearn, I think that's one of the main reasons they're so big
245 2014-05-28 15:41:14 <hearn> presumably
246 2014-05-28 16:22:21 <kiddouk> guys, I can make a rawtransaction with a script that I wrote. When passing the transaction to "decoderawtransaction", the client can deserialise it. When I send it with "sendrawtransaction" I get an error (-22 : deserialise error) back. Any idea ?
247 2014-05-28 16:22:24 <chichov> do multisig addresses not start with 1?
248 2014-05-28 16:22:36 <hearn> p2sh addresses do not start with 1
249 2014-05-28 16:23:00 <chichov> oh, so multisig addresses are basically p2sh addresses?
250 2014-05-28 16:23:04 <shesek> kiddouk, this doesn't make much sense... you must be doing something else wrong
251 2014-05-28 16:23:33 <shesek> chichov, multisig can be used as an output script (in which case it has no address representation at all), or as a p2sh address
252 2014-05-28 16:23:57 <chichov> shesek: that's clear, thanks
253 2014-05-28 16:24:17 <kiddouk> shesek: as sendrawtransaction and decoderawtransaction expect an hex payload in the console, I can't find where I make a mistake.
254 2014-05-28 16:24:37 <shesek> kiddouk, have you tried doing that manually, and not with a script?
255 2014-05-28 16:25:20 <kiddouk> shesek: as in, creating the transaction manually ? I already copy/paste the transaction in the bitcoin console.
256 2014-05-28 16:25:56 <kiddouk> btw, it's a testnet transaction so I can easily forward the hex payload if needed.
257 2014-05-28 16:26:22 <ryan-c> Burrito: I'm guessing you saw because you watched the repo, but I updated the code. If you'd like to thank me, I'd really appreciate some help updating the documentation to reflect the new code.
258 2014-05-28 16:26:59 <Burrito> ryan-c, I turned my email watching thingy off while I did some processor-intensive things overnight, so I didn't notice, but thank you. I'll certainly take a look.
259 2014-05-28 16:27:04 <ryan-c> chichov: addresses do not appear in raw transactions
260 2014-05-28 16:27:14 <Diablo-D3> https://www.kickstarter.com/projects/readingrainbow/bring-reading-rainbow-back-for-every-child-everywh
261 2014-05-28 16:28:38 <jcorgan> Diablo-D3: interesting, but how is it #bitcoin-dev relevant?
262 2014-05-28 16:29:17 <chichov> ryan-c: what does then?
263 2014-05-28 16:29:31 <chichov> you mean the 20 byte pubkeyhash, for example?
264 2014-05-28 16:29:34 <ryan-c> Burrito: Also, for kicks, I'm writing an example program that encodes arbitrary data as base1626 and applies reed-solomon to it over PF(1627)
265 2014-05-28 16:29:40 <CodeShark> "addresses" are just a base58check encoding of a specific type of script
266 2014-05-28 16:29:55 <CodeShark> the script is what appears in raw transactions
267 2014-05-28 16:30:24 <chichov> CodeShark: yea, there seems to be some confusion about the terminology
268 2014-05-28 16:30:32 <ryan-c> chichov: The "address" is an instruction for how to make a script. You can infer what the address was based on the raw transaction, but they never appear in blocks or on the network
269 2014-05-28 16:30:35 <Diablo-D3> jcorgan: this is where people bring up the fact kickstarter doesnt accept bitcoins yet
270 2014-05-28 16:30:41 <chichov> let me give you an example
271 2014-05-28 16:30:54 <ryan-c> chichov: in particular, the version byte is discarded.
272 2014-05-28 16:31:06 <ryan-c> e.g. 1
273 2014-05-28 16:31:12 <ryan-c> or 3
274 2014-05-28 16:31:20 <ryan-c> that part just says what type of script it is
275 2014-05-28 16:31:22 <chichov> https://en.bitcoin.it/wiki/Address - Here it states that a Bitcoin address is Base58Check(pubkeyHash)
276 2014-05-28 16:32:29 <chichov> whereas in the code they refer to the bitcoin address to what the wiki article refers to as the pubkey hash
277 2014-05-28 16:32:43 <chichov> Note: PubkeyHash = RIPEMD160(SHA256(pubkey))
278 2014-05-28 16:33:01 <chichov> and see base58.h:256
279 2014-05-28 16:33:45 <ryan-c> chichov: right, but what happens is that 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy is decoded to 05 b472a266d0bd89c13706a4132ccfb16f7c3b9fcb and then this script is generated OP_HASH160 b472a266d0bd89c13706a4132ccfb16f7c3b9fcb OP_EQUAL
280 2014-05-28 16:33:58 <chichov> yep, exactly
281 2014-05-28 16:34:02 <ryan-c> notice that the 05 (encoded as 3 in the 'address') goes away
282 2014-05-28 16:34:03 <chichov> the rest is just extra
283 2014-05-28 16:34:11 <ryan-c> as does the checksum
284 2014-05-28 16:34:22 <chichov> yep, the version bit and the checksum falls away
285 2014-05-28 16:34:26 <chichov> byte*
286 2014-05-28 16:34:54 <chichov> I'm just always a bit confused when I'm talking to people and we have a different terminology
287 2014-05-28 16:35:17 <chichov> sipa, e.g., always thinks of what stands in the code, which is not consistent with the wiki terminology
288 2014-05-28 16:35:53 <ryan-c> Burrito: Mostly because the thought of someone using it to memorize an RSA key or dictate one over the phone is hilarious to me
289 2014-05-28 16:36:06 <chichov> actually, is there any consensus on what the bitcoin address is supposed to mean?
290 2014-05-28 16:36:42 <Burrito> ryan-c, :)
291 2014-05-28 16:37:18 <ryan-c> Burrito: but also i do want to actually test it with different prime fields
292 2014-05-28 16:53:51 <buZz> has there been efforts towards speeding up bitcoind on arm systems?
293 2014-05-28 16:54:19 <devthink_> hearn: thinking out loud... suppose I have a server running bitcoinj (with FullPrundeBlockStore). A user's thin wallet (with HD private nodes) is saved on the client system. When a user connects with this bitcoinj server, the client sends the public keys, and a Wallet object is created with the user's public keys. The server then replies with the list of spendable TransactionOutput. When the user disconnects, the Wallet objec
294 2014-05-28 16:54:42 <hearn> you got cut off
295 2014-05-28 16:54:49 <hearn> IRC is pretty harsh about line length limits unfortunately
296 2014-05-28 16:55:09 <devthink_> hearn: thinking out loud... suppose I have a server running bitcoinj (with FullPrundeBlockStore).
297 2014-05-28 16:55:20 <devthink_> A user's thin wallet (with HD private nodes) is saved on the client system.
298 2014-05-28 16:55:20 <hearn> you got up to: When the user disconnects, the Wallet obje
299 2014-05-28 16:55:42 <devthink_> When a user connects with this bitcoinj server, the client sends the public keys, and a Wallet object is created with the user's public keys.
300 2014-05-28 16:55:56 <devthink_> The server then replies with the list of spendable TransactionOutput. When the user disconnects, the Wallet object is removed.
301 2014-05-28 16:56:16 <devthink_> Is this feasible? Is there a performance problem?
302 2014-05-28 16:56:41 <hearn> yes, such a design can work. there needs to be a helper method on the Postgres store to make it easy, but it's not hard to do that i think.
303 2014-05-28 16:57:07 <hearn> i don't think there are any particular performance problems, beyond the need to index the UTXO set of course.
304 2014-05-28 16:57:08 <devthink_> cool. thanks!
305 2014-05-28 16:57:47 <hearn> take a look at the query in PostgresFullPrunedBlockStore.calculateBalanceForAddress
306 2014-05-28 16:57:59 <hearn> ACTION doesn't quite understand what it's doing, that's a nasty query, but the data is there
307 2014-05-28 16:58:39 <hearn> devthink_: btw there is a #bitcoinj channel
308 2014-05-28 16:58:51 <hearn> devthink_: what's the purpose of this arrangement though? if you can run full java on the client side, you can as well use an SPV wallet
309 2014-05-28 16:59:16 <Jouke> buZz: is speed a problem om ARM? I just got an odroid to see if bitcoind will run on it :)
310 2014-05-28 16:59:27 <buZz> well
311 2014-05-28 17:00:02 <buZz> i run it on a dual cortex-a7 with 1gb ram
312 2014-05-28 17:00:55 <buZz> syncing went fast but block validation is taking longer towards current day in the chain
313 2014-05-28 17:01:43 <buZz> but i guess i could try to play around with -mfpu variants
314 2014-05-28 17:01:56 <devthink_> hearn: thinking about a very thin wallet stored in the browser's local storage. with passphrase+salt and scrypt, a wallet backup would not be required...
315 2014-05-28 17:02:16 <buZz> just wondered if someone already did some (perhaps documented) effort
316 2014-05-28 17:03:05 <hearn> devthink_: that's how existing web wallets all work, yes. in practice i think we need to move away from this model. it's not as decentralised, the servers are more expensive to run .... most computers can process SPV just fine. the desire to run within the constraints of the browser isn't because of some fundamental hardware limit, it's because people perceive a lack of a good cross platform runtime
317 2014-05-28 17:04:05 <Jouke> buZz: well, if you do play around with it, I am interested in the results :)
318 2014-05-28 17:07:34 <Burrito> ryan-c, should the docstrings strongly match the new documentation (and vice versa)?
319 2014-05-28 17:08:03 <buZz> Jouke: dito ;)
320 2014-05-28 17:10:14 <ryan-c> Burrito: Not sure what you mean by 'match' - they should obviously both be correct.
321 2014-05-28 17:12:00 <Burrito> ryan-c, alright
322 2014-05-28 17:37:38 <Burrito> ryan-c, (note I'm still pretty new to Python and programming in general and don't understand files like pfint and rscoder)... Is there any great advantage to using the Mapper class (which is using dicts to map letters to integers and back), as opposed to using string indexes?: http://pastebin.com/HyN7Mi3s
323 2014-05-28 17:40:48 <Burrito> I guess it's easier and in some way simpler to add things like the 'equivs' stuff in the same data structure without having to go check first... right?
324 2014-05-28 18:09:43 <kiddouk> In the latest Official bitcoin client, are all generated addresses in compressed form ? Meaning 02/03 + point X on the curve ?
325 2014-05-28 18:10:12 <kiddouk> address' public keys, that is.
326 2014-05-28 18:22:31 <maaku> kiddouk: you can test it and see
327 2014-05-28 18:22:40 <maaku> the compressed state is stored in the dumpprivkey format
328 2014-05-28 18:24:36 <kiddouk> maaku: yes. Thad that's what I did. Since my private key is 52 bytes long, I have deducted that my key was compressed.
329 2014-05-28 18:25:09 <kiddouk> and by private key, I mean WIF formatted key.
330 2014-05-28 18:26:37 <kiddouk> Now, when I create a transaction using that key, we agree that I should provide the compressed key (starting with 02/03 + <hex> X point) in the scriptSig. Correct ?
331 2014-05-28 18:28:28 <kiddouk> My problem being that I can generate a raw transaction but it gets rejected with sendrawtransaction. I suspect a mistake in the signature process.
332 2014-05-28 18:29:38 <kiddouk> and since I am trying to emit a transaction from my wallet with a compressed key, it looks like the good place to look at :)
333 2014-05-28 18:30:35 <Luke-Jr> hearn: BTW, just to be perfectly clear since apparently our earlier conversation can be grossly misinterpreted: I will never approve of (much less endorse or actively participate in) fraud, no matter who the victim is.
334 2014-05-28 18:30:54 <hearn> ok
335 2014-05-28 18:44:16 <tyrick> In chainparams.cpp what is this array pnSeed?
336 2014-05-28 18:44:25 <tyrick> a giant list of node ips?
337 2014-05-28 18:46:51 <maaku> kiddouk: are you using 0.9? latest bitcoind gives meaningful rejection messages
338 2014-05-28 18:47:38 <maaku> Luke-Jr: just be aware that people currently are using Eligius to commit fraud against dice sites...
339 2014-05-28 18:49:36 <Burrito> tyrick, sounds like the seed nodes. Default is to use DNS seeds. Maybe those are used when the DNS cannot be used.
340 2014-05-28 18:50:48 <Burrito> tyrick, nope, I don't think those are node IPs.
341 2014-05-28 18:51:19 <Burrito> Nevermind.
342 2014-05-28 18:51:48 <tyrick> haha, what are they?
343 2014-05-28 18:52:39 <Burrito> (Nevermind at "I don't think they are node IPs" because of how it's used later)
344 2014-05-28 18:52:55 <coryfields> gavinandresen: around today?
345 2014-05-28 18:53:07 <tyrick> So they are in fact node IPs?
346 2014-05-28 18:56:07 <Burrito> tyrick, I think so, yes. I'm probably not the best person to ask. But the DNS seeds point to many IPs. It would be convenient if there were some cache of them in case the client can't use DNS. And that might be it. :)
347 2014-05-28 18:56:42 <tyrick> Thank you, Mr. Burrito.
348 2014-05-28 18:56:49 <tyrick> I will bug someone else for extra validation later
349 2014-05-28 18:56:57 <Burrito> tyrick, see also (from searching "pnseed bitcoin"): https://gitorious.org/bitcoin/luke-jr-bitcoin/commit/9126e08739f5115c3032997cabd23f27037131ef
350 2014-05-28 18:57:54 <Burrito> tyrick, better: bitcoin / contrib / seeds / makeseeds.py
351 2014-05-28 18:57:59 <Burrito> (in the git repo)
352 2014-05-28 18:59:22 <tyrick> Ahhh, it is literally a list of ip
353 2014-05-28 18:59:29 <tyrick> ip from a DNS server
354 2014-05-28 18:59:37 <Burrito> Yeah. From a list at http://bitcoin.sipa.be/seeds.txt I'm guessing.
355 2014-05-28 18:59:41 <Burrito> (because of the readme)
356 2014-05-28 18:59:48 <tyrick> who's real name must be Peter
357 2014-05-28 18:59:53 <Burrito> :)
358 2014-05-28 19:00:09 <tyrick> but with an i somewhere in there
359 2014-05-28 19:07:07 <michagogo> tyrick: Pieter
360 2014-05-28 19:22:14 <crunk-ju_> wow there hasn't been a block in 25 minutes?
361 2014-05-28 19:26:12 <tyrick> blocks are hard
362 2014-05-28 19:27:07 <crunk-ju_> lol
363 2014-05-28 20:00:22 <jcorgan> ;;tblb 1500
364 2014-05-28 20:00:24 <gribble> The expected time between blocks taking 25 minutes and 0 seconds to generate is 2 hours, 21 minutes, and 13 seconds
365 2014-05-28 20:00:40 <jcorgan> so it happens every couple hours or so. anyway, #bitcoin
366 2014-05-28 20:01:07 <BlueMatt> seems truecrypt.org was hacked :(
367 2014-05-28 20:01:26 <jcorgan> yeah, at least sourceforge has blocked the page
368 2014-05-28 20:01:28 <pigeons> and their keys they sign binaries with
369 2014-05-28 20:01:46 <BlueMatt> oh? I can still access the page
370 2014-05-28 20:01:59 <jcorgan> i'm getting "This project has been temporarily blocked for exceeding its bandwidth threshold"
371 2014-05-28 20:02:48 <BlueMatt> its going back on forth on that page
372 2014-05-28 20:04:43 <BlueMatt> shit, sounds like sf might've been hacked
373 2014-05-28 20:04:59 <BlueMatt> we arent serving any downloads there anymore, right?
374 2014-05-28 20:05:39 <jcorgan> i think we are, but i've only every compiled from github source, so i don't really know
375 2014-05-28 20:05:56 <BlueMatt> no, we dont officially, though they are still uploaded there......
376 2014-05-28 20:08:00 <hearn> truecrypt.sf.net loads for me
377 2014-05-28 20:09:41 <pigeons> http://sourceforge.net/projects/truecrypt/files/TrueCrypt/Other/ same key signed the brand new ones as the old ones
378 2014-05-28 20:14:17 <pigeons> actually i cant find old versions to check the signature, i was told it was the same key
379 2014-05-28 20:30:33 <saizai> anyone know if video from btc2014âs policy panel is up somewhere? Iâm not seeing it on youtube.
380 2014-05-28 21:13:09 <netg_> vid from every panel/session of btc2014 is online
381 2014-05-28 21:17:09 <hearn> where?
382 2014-05-28 21:23:20 <netg_> youtube, have to search the account
383 2014-05-28 21:23:22 <netg_> give me 10 mins
384 2014-05-28 21:25:38 <netg_> https://www.youtube.com/user/CoinsiderThis
385 2014-05-28 21:25:46 <netg_> this news outlet taped everything
386 2014-05-28 21:25:47 <netg_> AFAIK
387 2014-05-28 21:26:06 <hearn> thanks
388 2014-05-28 21:26:07 <hearn> ACTION -> bed
389 2014-05-28 22:59:55 <dazedhead> hi guys
390 2014-05-28 23:02:27 <dazedhead> auch paar deutsche Entwickler hier am Start?
391 2014-05-28 23:15:48 <kiddouk> dazedhead: in english maybe ?
392 2014-05-28 23:18:53 <kiddouk> maaku: yes I do (0.9.1beta). I really dont understand. So far I can decoderawtransaction and verify that the signature and the public key will return OK for OP_CHECKSIG (done by hand).
393 2014-05-28 23:18:56 <Luke-Jr> [18:47:38] <maaku> Luke-Jr: just be aware that people currently are using Eligius to commit fraud against dice sites⦠<-- no, they're using flaws in dice sites
394 2014-05-28 23:22:30 <dazedhead> Hi kiddouk, i currently trying my first steps with the RPC api to create a richlist for training... but i looks like im not getting the correct balance of my wallet... maybe you can give me some tips what i need to regard to calculate the balances of all addresses?
395 2014-05-28 23:23:21 <kiddouk> dazedhead: getbalance should give you the good balance (indeed).
396 2014-05-28 23:23:46 <kiddouk> it does the job for you.
397 2014-05-28 23:26:30 <dazedhead> but i would like to get the balances of all users i need to check all blocks or is there a function to the addresses of all users of a coin?
398 2014-05-28 23:30:09 <maaku> kiddouk: it's probably not the signature at fault
399 2014-05-28 23:30:45 <kiddouk> maaku: no need to mention that I have the necessary funds and that I transfer more than dust.
400 2014-05-28 23:31:58 <kiddouk> dazedhead: What do you mean by *all user* ? There are no user, only addresses.
401 2014-05-28 23:32:42 <kiddouk> maaku: the only error message I get is : TX rejected (code -22)
402 2014-05-28 23:33:40 <kiddouk> maaku: which leads me to https://github.com/bitcoin/bitcoin/blob/29c1fbbb97710a9c31ae594870fc41539425889c/src/rpcprotocol.h (RPC_DESERIALIZATION_ERROR)
403 2014-05-28 23:36:21 <dazedhead> kiddouk: I'm sorry... I would like to calculate the balances for each address of a coin
404 2014-05-28 23:37:41 <kiddouk> maaku: DONE ! :)