1 2012-12-12 00:32:08 <etotheipi_> sipa: gmaxwell: do you know if there's a way the payment protocol could accommodate chained keys? (such as BIP32) By this, I mean that my webserver distributes addresses for customers to pay me, but if it's compromised, the attacker could replace the watching-only wallet with their own and steal payments until I find out
2 2012-12-12 00:32:53 <etotheipi_> I would like to, *essentially* sign the public chain and have other clients be able to verify that the addresses they received are on that chain, but I don't acutally want to give them the whole public chain (for privacy reasons)
3 2012-12-12 00:35:34 <sipa> you'd accomplish that by deriving from a known chain, but with more than 32 bits of entropy after that
4 2012-12-12 00:35:55 <etotheipi_> ideally, there was some mathematical trick such that I can transfer the signature from the root to any child addresses
5 2012-12-12 00:38:00 <etotheipi_> sipa: you mean that you can transfer partial root chain information, and send the extra information needed to verify that *just this one key* is part of that known chain
6 2012-12-12 00:38:02 <etotheipi_> ?
7 2012-12-12 00:39:03 <sipa> imagine the subkey id was not a 32-bit number, but a 256-bit number
8 2012-12-12 00:39:48 <sipa> if my public extended key M/i was known, then if I give out M/i/x with x a random 256-bit number
9 2012-12-12 00:40:00 <sipa> you know it's derived from M/i (since you derived it yourself)
10 2012-12-12 00:40:14 <sipa> and you won't be able to iterate anything else derived from it
11 2012-12-12 00:40:23 <sipa> but that's overly complex i think
12 2012-12-12 00:40:24 <etotheipi_> so M/i is a chain that isn't used for collecting coins?
13 2012-12-12 00:40:42 <sipa> doesn't really matter
14 2012-12-12 00:41:49 <etotheipi_> sipa: I don't entirely follow (yet), but I get the gist of it
15 2012-12-12 00:42:10 <etotheipi_> the question I have is: isn't this something that should be handled by the payment protocol?
16 2012-12-12 00:42:26 <sipa> imho, no
17 2012-12-12 00:42:31 <etotheipi_> servers with BIP 32 watching-only wallets will all be vulnerable without this
18 2012-12-12 00:42:43 <etotheipi_> or what's the other solution?
19 2012-12-12 00:42:57 <sipa> well if they can get to your server, they can get to your private key too
20 2012-12-12 00:43:16 <sipa> the PKI key, i mean
21 2012-12-12 00:44:01 <etotheipi_> hmm... this isn't exactly how I envisioned it
22 2012-12-12 00:44:14 <etotheipi_> I was envisioning that you have a PKI key kept offline
23 2012-12-12 00:44:19 <gmaxwell> etotheipi_: huh? vulnerable to what? Someone getting on them and taking the enumeration keys? well yes. But you can't stop that. Either anyone with the server's data can enumerate or not.
24 2012-12-12 00:44:23 <etotheipi_> and you use it to sign watching-only chains
25 2012-12-12 00:44:58 <etotheipi_> and clients would have a way to verify that the address they received is part of the signed chain
26 2012-12-12 00:45:05 <gmaxwell> Oh I see what you're thinking.
27 2012-12-12 00:45:38 <sipa> you want to sign child keys with the root key, or have a proof that they are derived from a known root
28 2012-12-12 00:45:44 <etotheipi_> but, of course, we don't want to give every customer the entire chain
29 2012-12-12 00:45:48 <gmaxwell> Meh. So you want to sign the addresses only, not the invoice, so the signing key can be offline.
30 2012-12-12 00:46:17 <etotheipi_> sipa: yes
31 2012-12-12 00:46:30 <gmaxwell> Of course, that means I can make up forged invoices "1 Gold bar ??? 1 BTC -> signed(etotheipi_)" bleh.
32 2012-12-12 00:46:43 <sipa> no, the invoice has to be signed
33 2012-12-12 00:46:44 <sipa> no, the invoice has to be signed
34 2012-12-12 00:46:45 <etotheipi_> as I was pondering server security, I realized that this is a seriously-damaging vulnerability
35 2012-12-12 00:46:57 <gmaxwell> unless you do _both_ with seperate signing keys.
36 2012-12-12 00:47:26 <etotheipi_> I mean... control of the server means collecting all gross income for a business for 1-24 hours until they figure it out
37 2012-12-12 00:47:31 <gmaxwell> etotheipi_: 'seriously-damaging vulnerability' when absolutely no payment system ever created is secure against that? :)
38 2012-12-12 00:48:03 <etotheipi_> well that's why I'm bringing it up here... it sounds like a problem that *might* be solvable with Bitcoin
39 2012-12-12 00:48:04 <sipa> i think that if you get write access to the invoice-creating server, you have larger problems
40 2012-12-12 00:48:07 <gmaxwell> but I agree its an interesting point.
41 2012-12-12 00:48:33 <gmaxwell> sipa: you do, of course??? but it is interestng that it may be possible to keep the keys that sign authenticating the payment addresses offline.
42 2012-12-12 00:49:29 <etotheipi_> that shifts the scope of the payment protocol quite a bit though ... as you said: it would be signed address chains, instead of individually-signed invoices
43 2012-12-12 00:49:30 <etotheipi_> that shifts the scope of the payment protocol quite a bit though ... as you said: it would be signed address chains, instead of individually-signed invoices
44 2012-12-12 00:50:18 <gmaxwell> e.g. invoices signed with a key who's cert has a flag that says "good for signing invoices only, payment addresses must be signed by this other key" and that other key is offline.
45 2012-12-12 00:50:31 <etotheipi_> if we did nothing else except come up with a way to do this, what are the remaining vulnerabilies? Everything on the invoice could be altered *except* the address
46 2012-12-12 00:50:35 <gmaxwell> Of course this is all impossibly complex any I'm doubtful we'd get anyone to actually use it... :(
47 2012-12-12 00:50:54 <sipa> and implement it correctly, if its security was relied upon
48 2012-12-12 00:50:55 <sipa> and implement it correctly, if its security was relied upon
49 2012-12-12 00:51:02 <etotheipi_> gmaxwell: I'd say the same thing about Bitcoin itself :)
50 2012-12-12 00:51:18 <sipa> haha
51 2012-12-12 00:51:22 <gmaxwell> etotheipi_: and I think we're on the verge of failing there!
52 2012-12-12 00:52:16 <gmaxwell> Having to have signing keys online is a major weakness of basically all ecommerce schemes.
53 2012-12-12 00:52:57 <etotheipi_> gmaxwell: right... so now imagine we solved that... which I'm envisioning my be "simply" a chaining trick much like BIP 32 itself
54 2012-12-12 00:53:07 <etotheipi_> that's a pretty significant advancement in security *potential*
55 2012-12-12 00:53:51 <etotheipi_> *may be
56 2012-12-12 00:54:40 <gmaxwell> etotheipi_: another alternative is to provide an _unrolled_ key, were there is one signed part, and an unsigned chaining part.. and the client does the composition and send. This means the worst an attacker could do is take funds hostage.
57 2012-12-12 00:54:59 <sipa> well it can be done a lot easier: in addition to the txout script (with an address in it), you provide your known public key, and a random 256-bit number, with the property that HASH(pubkey*number) == address
58 2012-12-12 00:55:10 <sipa> no need for full BIP32 derivation
59 2012-12-12 00:55:19 <gmaxwell> ^ thats exactly what I was saying!
60 2012-12-12 00:56:04 <sipa> and the certificate should contain the pubkey then, indeed
61 2012-12-12 00:57:03 <gmaxwell> ACTION watches etotheipi_ slowly invent 'script' for invoices???
62 2012-12-12 00:58:20 <etotheipi_> heh, I was hoping I could just seed the idea with you smart people, and you'll figure it out while I go back to my regularly-scheduled Armory development :)
63 2012-12-12 01:01:40 <gmaxwell> etotheipi_: well I've wanted something like this before, for the PoS stuff??? because one of the (multiple) killer problems with PoS is keeping your signing keys online.
64 2012-12-12 01:03:25 <etotheipi_> so, if we figured out nothing else except a way to prove that the address is part of a signed chain, what are the remaining vulnerabilies of a compromised server? Everything on the invoice could be altered *except* the address
65 2012-12-12 01:07:22 <etotheipi_> I bet this is a problem that roconnor would like to contribute to :)
66 2012-12-12 01:07:31 <roconnor> what's that?
67 2012-12-12 01:07:33 <gmaxwell> Right. And the server could just issue non-signed invoices and most users would pay them. tada.
68 2012-12-12 01:08:10 <roconnor> etotheipi_: how goes the armoury?
69 2012-12-12 01:08:21 <etotheipi_> I want to be able to use an offline SSL cert to sign a watching-only address chain (such as BIP 32), and have a way for a user to verify that the address they received (requesting payment) is a child of that chain
70 2012-12-12 01:08:22 <etotheipi_> I want to be able to use an offline SSL cert to sign a watching-only address chain (such as BIP 32), and have a way for a user to verify that the address they received (requesting payment) is a child of that chain
71 2012-12-12 01:08:58 <roconnor> I don't know anything about X.314159 whatever ... yet
72 2012-12-12 01:09:08 <etotheipi_> but I don't want to give them the root explicitly, because I don't want them to see my entire business's transaction history
73 2012-12-12 01:09:20 <etotheipi_> well, it doesn't need to be X.509 for this thought experiment
74 2012-12-12 01:09:26 <sipa> i'm sure roconnor would love to come up with a formally-verifiable script language for certificate checking, though :p
75 2012-12-12 01:09:27 <roconnor> oh okay
76 2012-12-12 01:09:30 <etotheipi_> any cryptographically secure method will do, and may be adaptible
77 2012-12-12 01:09:38 <gmaxwell> State goals not mechenisms. You want a user to get an invoice authored and signed by compromised server, identified by some PKI chain.. and have the user not send payments to the bad guys that compromised it.
78 2012-12-12 01:10:27 <etotheipi_> roconnor: btw the Armory is going well. Just released Beta, FINALLY
79 2012-12-12 01:10:55 <sipa> [03:10] [sipa(+Zi)] [16:freenode/#bitcoin-dev(+Ccnt)] [Act: 3,14,15]
80 2012-12-12 01:11:07 <sipa> look at the list of active channels!
81 2012-12-12 01:11:16 <gavinandresen> Speaking of invoices... I made a good bit of progress today on the PaymentRequest implementation. https://github.com/gavinandresen/paymentrequest
82 2012-12-12 01:11:20 <sipa> 03:09:06 < roconnor> I don't know anything about X.31415
83 2012-12-12 01:11:31 <sipa> the fact that I see this, means i need sleep
84 2012-12-12 01:11:34 <roconnor> etotheipi_: I don't suppose you've asked fellowtraveller?
85 2012-12-12 01:11:50 <roconnor> sipa: you have work in the morning!
86 2012-12-12 01:11:55 <sipa> yeah :(
87 2012-12-12 01:11:58 <etotheipi_> no, I just thought of this like 20 min ago, and was running it by whoever happened to be in this channel
88 2012-12-12 01:11:59 <etotheipi_> no, I just thought of this like 20 min ago, and was running it by whoever happened to be in this channel
89 2012-12-12 01:12:05 <roconnor> :)
90 2012-12-12 01:12:09 <sipa> well... most of my colleagues arrive around noon though :P
91 2012-12-12 01:12:36 <etotheipi_> it wouldn't surprise me if there was a crytographically secure solution, much like type-2 deterministic wallets
92 2012-12-12 01:13:03 <etotheipi_> to "transfer" signatures from a root key to the children without having to reveal the root key
93 2012-12-12 01:13:06 <sipa> roconnor: long time since I saw you active in here, btw!
94 2012-12-12 01:13:23 <roconnor> I've been busy with my new job
95 2012-12-12 01:13:59 <sipa> :)
96 2012-12-12 01:17:49 <roconnor> etotheipi_: is the verfication online (ie interactive) or offline?
97 2012-12-12 01:19:20 <roconnor> gmaxwell: can you state the goal one more time?
98 2012-12-12 01:21:17 <gmaxwell> Compromised server. It gives a secure client an invoice. Client checks signatures on invoice against PKI. Client pays and the attacker can't get the payment. The idea being that the invoice has an online signature, but the payment addresses in it has an offline signature so the attacker can't replace it. Problem: You want to use a new address for every txn for privacy and accounting reasons. (and don't want to just precomput a zillion signe
99 2012-12-12 01:21:53 <etotheipi_> roconnor: here's the issue: you have a webserver that distributes addresses to customers for your business dealings... that server is compromised and the attacker has it distirbute the attacker's addresses
100 2012-12-12 01:22:19 <etotheipi_> for some number of hours, the attacker will be collecting gross income meant for the company
101 2012-12-12 01:23:37 <etotheipi_> I'd like to have it so that a compromised server will not lead to stolen funds (because the addresses on the invoices can't be altered)
102 2012-12-12 01:24:18 <gavinandresen> buy a hardware token that will store the private signing key. Done, attacker can't impersonate you.
103 2012-12-12 01:25:10 <etotheipi_> gavinandresen: but they have control of the server, and can send any address they want to to the hardware token for signing
104 2012-12-12 01:25:15 <gmaxwell> gavinandresen: the attacker has compromised the webserver. It can write any invoice the webserver can write. I suppose if the hardware token is taking unsigned invoices, parsing them, and adding the payment addresses.. you're right. And certantly that avoid protocol complications!
105 2012-12-12 01:26:07 <gavinandresen> I dunno how programmable the hardware security tokens are these days, but seems like they aught to be able to generate the address chain.
106 2012-12-12 01:26:17 <etotheipi_> gavinandresen: good point
107 2012-12-12 01:26:44 <gmaxwell> gavinandresen: certantly hardware exists that can do this.
108 2012-12-12 01:27:34 <roconnor> okay I think I understand now.
109 2012-12-12 01:27:35 <gmaxwell> (e.g. the IBM cryptocards are tamper resistant embedded PC's on PCI cards??? you could have a SPV bitcoin node on one if you wanted)
110 2012-12-12 01:30:28 <roconnor> etotheipi_: are you worried about your clients sharing data with each other?
111 2012-12-12 01:30:30 <etotheipi_> this would applicable to a lot of security models
112 2012-12-12 01:30:39 <etotheipi_> not just bitcoin
113 2012-12-12 01:30:56 <etotheipi_> or rather, I bet something like this is already done (HW devices that only sign, but can't give out the key)
114 2012-12-12 01:31:41 <roconnor> how does a hardware thing solve this problem?
115 2012-12-12 01:31:50 <etotheipi_> roconnor: I'm concerned that my webserver is compromised, and I don't notice for 24 hours that no payments are received (because they're all going to the attacker)
116 2012-12-12 01:32:25 <gavinandresen> top-of-my-head random thought: the payment_url in the PaymentRequest might be a good belt&suspenders shut-down-attacker... if it was part of the CA-signed certificate and pointed to a different server then it could eliminate the single-point of failure (attacker would have to compromise two servers to succeed, assuming payment_url server was double-checking payment addresses)
117 2012-12-12 01:33:09 <roconnor> etotheipi_: and why not just give out keys signed by an offline key?
118 2012-12-12 01:33:34 <roconnor> just to clairify the problem?
119 2012-12-12 01:33:42 <etotheipi_> roconnor: I don't want to have to generate and sign a bajillion individual keys... it kind of defeats the purpose of having deterministic wallets
120 2012-12-12 01:34:24 <gavinandresen> You could pre-sign a bajillion chained-key PaymentRequests. disk space is cheap. Wallet is still deterministic....
121 2012-12-12 01:34:26 <etotheipi_> agreed though.... I'm sure any business could sign enough keys that they'd never run out...
122 2012-12-12 01:36:19 <etotheipi_> you could fill half a hard-drive on the server with pre-signed keys
123 2012-12-12 01:37:12 <roconnor> my idea would be to have the signing key for invoices on an "optio-isolated" computer :d
124 2012-12-12 01:37:45 <roconnor> wait that doesn't work at all
125 2012-12-12 01:37:46 <roconnor> wait that doesn't work at all
126 2012-12-12 01:37:47 <roconnor> nevermind
127 2012-12-12 01:37:53 <gmaxwell> yea, the motivation for determinism is reduced there. So if you did that you'd just have a cert-chain flag for 'must have seperately signed payment key'
128 2012-12-12 01:38:04 <gmaxwell> roconnor: bi directional optoisolated. :P
129 2012-12-12 01:38:44 <gmaxwell> roconnor: well, it's not entirely crazy to have a signing server which is only exposed to the webserver and has a very small attack surface area. 'sends and recieves invoices via rs232, nothing more'
130 2012-12-12 01:39:26 <etotheipi_> but I like the HW idea -- it generates the signatures AND fills in payment addresses without the ability to download it from the device
131 2012-12-12 01:39:31 <gavinandresen> yes, that would be an easier-to-program version of the smart hardware token
132 2012-12-12 01:40:18 <roconnor> what would fellow traveller say?
133 2012-12-12 01:40:30 <gavinandresen> "use open transactions" ?
134 2012-12-12 01:41:05 <roconnor> what happens when an open transactoin server is compromised?
135 2012-12-12 01:41:06 <roconnor> what happens when an open transactoin server is compromised?
136 2012-12-12 01:41:39 <doublec> people rejoice that someone worked out how to use it?
137 2012-12-12 01:43:45 <jgarzik> sipa: nick reg doesn't happen automatically
138 2012-12-12 01:43:56 <jgarzik> sipa: so I lose it every time my local net bounces
139 2012-12-12 01:43:57 <jgarzik> sipa: so I lose it every time my local net bounces
140 2012-12-12 01:51:16 <gmaxwell> hahaha
141 2012-12-12 01:51:20 <gmaxwell> (at doublec)
142 2012-12-12 01:52:03 <etotheipi_> if only it was as easy to create and prototype hardware devices as it is to do with SW algorithms...
143 2012-12-12 01:52:27 <etotheipi_> unfortunately, I'm HW-retarded
144 2012-12-12 01:55:23 <etotheipi_> my fiance complains about how much time I spend developing... I tell her "at least, I'm not *also* spending thousands of dollars buying hardware to try out my crazy ideas"
145 2012-12-12 02:07:16 <roconnor> I don't understand how harware is helping here.
146 2012-12-12 02:09:15 <etotheipi_> roconnor: if the HW device has both the signing keys AND the address chain... and the HW device is responsible for adding addresses to invoices before signing them
147 2012-12-12 02:16:01 <roconnor> oh I see, the attacker can just get the system to sign arbitrary invoices ... to you
148 2012-12-12 02:16:25 <roconnor> my optio-isolated computer would be a reasonable cheap alternative to tamperproof hardware.
149 2012-12-12 02:18:03 <roconnor> deterministic wallets would still be useful for backup purposes
150 2012-12-12 02:26:21 <etotheipi_> roconnor: of course, I'd still prefer a crypto solution that allows for offline keys to sign the chain, so users aren't restricted to proprietary HW solutions, even if it can only prevent address altering
151 2012-12-12 02:27:17 <etotheipi_> (i.e. the invoice might be alterable, but the address is guaranteed to belong to the intended recipient, so the attacker might be able to cause an inconvenience, but not steal the funds)
152 2012-12-12 02:27:46 <roconnor> etotheipi_: the deterministic keys let you produce a stream of public-keys without access to the private key, right?
153 2012-12-12 02:29:32 <roconnor> etotheipi_: maybe you can remind me or link to how these address chains work
154 2012-12-12 02:30:17 <roconnor> maybe we can make a stream of addresses and signatures.
155 2012-12-12 02:44:30 <jgarzik> doublec: chuckle ;p
156 2012-12-12 03:00:26 <etotheipi_> roconnor: sorry, got distracted
157 2012-12-12 03:01:47 <etotheipi_> roconnor: the deterministic wallet is using the equality that private key is a (large integer), public key is a*G (G is generator point), thus if you can generate a deterministic sequence (preferably "non-linear") of chaincodes, you just make PrivKey[i+1] = ChainCode[i]*PrivKey[i]
158 2012-12-12 03:02:14 <etotheipi_> and thus also PubKey[i+1] = ChainCode[i]*PubKey[i]
159 2012-12-12 03:02:32 <roconnor> right
160 2012-12-12 03:02:35 <roconnor> good
161 2012-12-12 03:02:57 <etotheipi_> but that's only how the addresses are created... signatures are quite a bit more complicated in ECDSA
162 2012-12-12 03:03:02 <etotheipi_> (as I'm sure you know)
163 2012-12-12 03:03:07 <roconnor> so it might be able to use ECC to "sign" these PubKeys in a similar chainCode way?
164 2012-12-12 03:03:16 <etotheipi_> roconnor: that's what I'm hoping
165 2012-12-12 03:03:17 <etotheipi_> roconnor: that's what I'm hoping
166 2012-12-12 03:03:55 <etotheipi_> that there's a way to "sign" the root public key in such a way that the signature is preserved or verifiable in the child keys
167 2012-12-12 03:04:36 <etotheipi_> unfortunatley, ECDSA signing is not as simple as RSA/GPG signing
168 2012-12-12 03:04:37 <etotheipi_> unfortunatley, ECDSA signing is not as simple as RSA/GPG signing
169 2012-12-12 03:04:53 <roconnor> etotheipi_: though, perhaps all you need to do is sing PubKey[0] and then a user can verify that (i,PubKey[i]) is derived from that pubkey.
170 2012-12-12 03:04:57 <roconnor> *sign
171 2012-12-12 03:05:18 <etotheipi_> roconnor: yes, except you don't want to give each of your customers your entire business transaction history
172 2012-12-12 03:05:48 <roconnor> don't they have it already if they have PubKey[i]?
173 2012-12-12 03:05:59 <etotheipi_> no, they need the non-public chaincode, too
174 2012-12-12 03:06:08 <roconnor> or is ChainCode[i] a secret?
175 2012-12-12 03:06:17 <roconnor> ah
176 2012-12-12 03:06:23 <etotheipi_> the chaincode doesn't have to be protected like the private keys.... it's only a breach of privacy, not security
177 2012-12-12 03:06:32 <roconnor> right
178 2012-12-12 03:06:40 <roconnor> well I need to go to sleep;
179 2012-12-12 03:06:43 <roconnor> interesting puzzel
180 2012-12-12 03:06:44 <etotheipi_> but you still prefer to keep it hidden
181 2012-12-12 03:06:50 <etotheipi_> I knew you'd like it :)
182 2012-12-12 03:06:51 <roconnor> understood
183 2012-12-12 03:07:12 <etotheipi_> I'll probably break out some ECDSA on my whiteboard at work tomorrow :)
184 2012-12-12 03:07:19 <roconnor> :)
185 2012-12-12 05:23:44 <helo> what if satoshi had started four blockchains, and ran them in parallel?
186 2012-12-12 05:24:52 <helo> quadruplets?
187 2012-12-12 05:25:37 <Diablo-D3> helo: wouldnt work
188 2012-12-12 05:25:45 <Diablo-D3> you'd just end up with four different currencies
189 2012-12-12 05:26:55 <helo> right
190 2012-12-12 05:28:55 <helo> they would all be able to have some kind of value, and be traded amongst themselves
191 2012-12-12 05:30:21 <helo> but how would the overall market cap compare? would the prices find equilibrium?
192 2012-12-12 05:34:47 <jgarzik> network effect
193 2012-12-12 05:34:59 <jgarzik> there is greater value in one to rule them all
194 2012-12-12 05:40:02 <vazakl> http://www.bbc.co.uk/news/science-environment-20629671
195 2012-12-12 05:40:29 <DMCommit> [DiabloMiner] Diablo-D3 pushed 1 new commit to master: http://git.io/0ug0dA
196 2012-12-12 05:40:43 <Luke-Jr> why is DMCommit here?
197 2012-12-12 07:06:23 <abrkn> hmm, can someone explain this http://blockchain.info/tx-index/36201774/274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857
198 2012-12-12 07:19:15 <sturles> https://blockchain.info/wallet/escrow
199 2012-12-12 07:52:11 <hasha> lol, thats still going on
200 2012-12-12 07:52:38 <hasha> must be a slow night
201 2012-12-12 07:52:39 <hasha> must be a slow night
202 2012-12-12 07:53:02 <phantomcircuit> hmm, can someone explain this http://blockchain.info/tx-index/36201774/274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857
203 2012-12-12 07:53:03 <phantomcircuit> hmm, can someone explain this http://blockchain.info/tx-index/36201774/274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857
204 2012-12-12 08:12:11 <Jouke> 09:18 < sturles> https://blockchain.info/wallet/escrow
205 2012-12-12 08:12:16 <Jouke> oops
206 2012-12-12 08:29:20 <kinlo> phantomcircuit: that's basicly p2sh no?
207 2012-12-12 08:29:57 <kinlo> hmmz, no, p2sh is related but something else
208 2012-12-12 08:33:16 <sipa> phantomcircuit: 1-of-2 multisig
209 2012-12-12 08:33:41 <sipa> the second pubkey is invalid but was never tested
210 2012-12-12 08:40:18 <j58wej6hdssd> what is the bitcoin-0.7.1-linux.tar.gz md5 and why are there no hashes advertised on bitcoin.org?
211 2012-12-12 08:40:19 <j58wej6hdssd> what is the bitcoin-0.7.1-linux.tar.gz md5 and why are there no hashes advertised on bitcoin.org?
212 2012-12-12 08:42:44 <sipa> here they are: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/
213 2012-12-12 08:42:51 <sipa> if you click through to the sf download page
214 2012-12-12 08:43:06 <j58wej6hdssd> hm, so both the binaries and the sums are hosted on the same site
215 2012-12-12 08:43:34 <sipa> they're signed by gavin's GPG key, though
216 2012-12-12 08:43:35 <sipa> they're signed by gavin's GPG key, though
217 2012-12-12 08:43:41 <j58wej6hdssd> alright, thanks
218 2012-12-12 08:44:02 <sipa> (not thet you have any reason to trust his key, but ...)
219 2012-12-12 08:44:44 <j58wej6hdssd> well you're right it's more credible
220 2012-12-12 09:01:38 <sipa> if you click through to the sf download page/usr/bin/i686-w64-mingw32-ld: cannot find -lc
221 2012-12-12 09:01:49 <sipa> any idea how to disable trying to link to libc explicitly?
222 2012-12-12 09:01:57 <sipa> eh
223 2012-12-12 09:02:14 <sipa> i *wanted* to say
224 2012-12-12 09:02:48 <sipa> BlueMatt: building of qrencode on i686-w64-mingw32 fails
225 2012-12-12 09:02:53 <sipa> /usr/bin/i686-w64-mingw32-ld: cannot find -lc
226 2012-12-12 09:03:04 <sipa> BlueMatt: any ideas?
227 2012-12-12 09:23:59 <Diablo-D3> sipa: lolwat?
228 2012-12-12 09:24:27 <sipa> i suppose mingw doesn't have an explicit libc
229 2012-12-12 09:24:43 <sipa> as it links against some funky windows/msvc libraries instead
230 2012-12-12 09:25:27 <sipa> the configure script seems to have some logic to disable -lc on mingw builds, but perhaps is confused by our cross-compiling setup
231 2012-12-12 09:44:51 <Diablo-D3> TODAY IS 12/12/12, THE END OF THE WORLD IS NIGH
232 2012-12-12 11:52:29 <jine> Does anyone know (except theymos) if blockexplorer.com/testnet is running on testnet3 or the original one? MagicalTux?
233 2012-12-12 11:52:30 <jine> Does anyone know (except theymos) if blockexplorer.com/testnet is running on testnet3 or the original one? MagicalTux?
234 2012-12-12 11:53:25 <sipa> testnet3
235 2012-12-12 11:53:27 <sipa> afaik
236 2012-12-12 12:01:25 <jine> Nope, seems like it is testnet (1)... testnet3 has a blockheight of 39717, blkexplorer only has 33665 + the date is 2 mo ago.. :(
237 2012-12-12 12:02:03 <sipa> oh, really :o
238 2012-12-12 12:05:35 <gmaxwell> jine: no, it's just wedged or something.
239 2012-12-12 12:05:36 <jine> Oh wait, i think you're correct. It's the same genesis block in my chain as it is on blkexplorer
240 2012-12-12 12:05:53 <jine> gmaxwell: Yeah
241 2012-12-12 12:08:17 <DMCommit> [DiabloMiner] Diablo-D3 pushed 1 new commit to master: http://git.io/NDKQCw
242 2012-12-12 12:13:11 <sipa> gmaxwell: which blocks have the unit-tests-in-testnet?
243 2012-12-12 12:13:12 <sipa> gmaxwell: which blocks have the unit-tests-in-testnet?
244 2012-12-12 12:13:21 <sipa> should be able to check those easily
245 2012-12-12 12:13:22 <sipa> should be able to check those easily
246 2012-12-12 12:43:22 <ThomasV> http://blockchain.info/charts/total-bitcoins <-- looks broken
247 2012-12-12 13:49:57 <TD> hello
248 2012-12-12 13:51:38 <Rebroad> any idea why I'm getting "keypool reserve 21" and "keypool return 21" every 5 seconds in my debug.log ?
249 2012-12-12 13:51:41 <m0mchil> hi Mike
250 2012-12-12 13:52:14 <sipa> Rebroad: you're mining, or doing some other RPC frequently?
251 2012-12-12 13:52:37 <sipa> m0mchil: reminds me that i haven't answered your mail - sorry
252 2012-12-12 13:53:07 <m0mchil> sipa: no problem, it's rubbish I guess :)
253 2012-12-12 13:53:14 <Rebroad> sipa, not that I'm aware of
254 2012-12-12 13:53:17 <BillDev_> noob dev here, trying to get bitcoin source to build in eclipse juno on ubuntu 11.10. is there a cook book somewhere that will help?
255 2012-12-12 13:53:46 <sipa> m0mchil: it's certainly not conventional :)
256 2012-12-12 13:54:07 <Rebroad> sipa, the line "ThreadRPCServer method=getinfo" does preceed each instance though..
257 2012-12-12 13:54:50 <sipa> Rebroad: so you're calling getinfo frequently, and as that tries producing a block (afaik), it temporarily needs access to a key from the keypool
258 2012-12-12 13:55:26 <sipa> Rebroad: btw, have you seen https://github.com/bitcoin/bitcoin/issues/2034 ?
259 2012-12-12 13:55:30 <Rebroad> sipa, what's causing the getinfo to be called? is it something connecting to the rpc server?
260 2012-12-12 13:55:52 <sipa> i don't know your computer!
261 2012-12-12 13:56:29 <sipa> something is sending the getinfo RPC to your bitcoind
262 2012-12-12 14:36:26 <roconnor> etotheipi_: hey, I had an idea.
263 2012-12-12 15:00:28 <DMCommit> [DiabloMiner] Diablo-D3 pushed 1 new commit to master: http://git.io/hDgb6A
264 2012-12-12 15:00:29 <DMCommit> [DiabloMiner] Diablo-D3 pushed 1 new commit to master: http://git.io/hDgb6A
265 2012-12-12 15:04:55 <gmaxwell> Luke-Jr: please don't encourage grau in thinking that template proposals are a _replacement_ for writing a correct and complete implementation of the network rules. :-/
266 2012-12-12 15:15:01 <helo> sipa: is there anywhere to read about atomic bitcoin exchange?
267 2012-12-12 15:23:47 <helo> bufferbox using colored coin for pickup authentication would be pretty neat
268 2012-12-12 15:25:52 <gavinandresen> helo: "atomic bitcoin exchange" : do you mean across blockchains? https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
269 2012-12-12 15:26:46 <helo> maybe i misunderstood when i heard of it originally, but i was thinking "exchanging monetary bitcoin for a colored bitcoin in one transaction"
270 2012-12-12 15:26:47 <helo> maybe i misunderstood when i heard of it originally, but i was thinking "exchanging monetary bitcoin for a colored bitcoin in one transaction"
271 2012-12-12 15:27:07 <sipa> helo: why do you expect me to know about that? :)
272 2012-12-12 15:27:39 <helo> so the seller receiving payment would ensure that the buyer owned the colored bitcoin
273 2012-12-12 15:28:16 <helo> sipa: i thought it was you that said something like "blah i think i figured out how to get atomic transactions to work"
274 2012-12-12 15:29:05 <sipa> for colored coins sure... they're always atomic
275 2012-12-12 15:29:13 <sipa> as it's within the same chain
276 2012-12-12 15:31:32 <jgarzik> helo: within the same chain, "Atomic coin swapping" https://bitcointalk.org/index.php?topic=112007.0
277 2012-12-12 15:31:39 <helo> yes, that
278 2012-12-12 15:40:41 <TD> gavinandresen: good morning
279 2012-12-12 15:40:45 <TD> how are things going ?
280 2012-12-12 15:41:36 <gavinandresen> good
281 2012-12-12 15:42:01 <TD> is the payment protocol progressing?
282 2012-12-12 15:42:17 <gavinandresen> TD: yes, server-side code is on github: https://github.com/gavinandresen/paymentrequest
283 2012-12-12 15:42:36 <gavinandresen> it's generalized/reworked version of your prototype code
284 2012-12-12 15:42:43 <TD> nice
285 2012-12-12 15:42:50 <gavinandresen> And there is a pretty long TODO list to get it all done
286 2012-12-12 15:43:05 <gavinandresen> ... but at least every step is pretty straightforward
287 2012-12-12 15:43:39 <gavinandresen> I'm planning on switching gears and helping get the 0.8 changes reviewed/tested/etc, though
288 2012-12-12 15:43:40 <gavinandresen> I'm planning on switching gears and helping get the 0.8 changes reviewed/tested/etc, though
289 2012-12-12 15:44:01 <TD> oh yes that reminds me, my prototype code doesn't do anything special for EV certs
290 2012-12-12 15:44:11 <TD> i don't know what structure they have. I'd have that CN=Human Friendly Name
291 2012-12-12 15:44:14 <TD> but don't actually know for sure
292 2012-12-12 15:44:19 <TD> s/have/hope/
293 2012-12-12 15:44:20 <TD> s/have/hope/
294 2012-12-12 15:44:29 <TD> yeah getting 0.8 out would be good
295 2012-12-12 15:44:43 <TD> BlueMatt: think bloom filters can make it or are things a bit swamped
296 2012-12-12 15:44:54 <gavinandresen> and getting 0.7.2 out... what's the gribble command for number-of-blocks?
297 2012-12-12 15:46:04 <gribble> 211948
298 2012-12-12 15:46:04 <helo> ;;blocks
299 2012-12-12 15:49:11 <gavinandresen> Somebody's giving away a free bitcoin to whoever claims it first: http://blockchain.info/tx-index/36310989/cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35
300 2012-12-12 15:50:23 <jgarzik> gavinandresen: /me looks at build system... bleh. Maybe I can convert paymentrequest to autotools :)
301 2012-12-12 15:50:29 <jgarzik> it's small enough
302 2012-12-12 15:50:38 <gavinandresen> ok. patches welcome.
303 2012-12-12 15:51:15 <gavinandresen> (existing build system I adopted from protocol buffers)
304 2012-12-12 15:51:33 <TD> autotools have a way of making small things big
305 2012-12-12 15:51:51 <TD> given that the relevant programs are single files :)
306 2012-12-12 15:52:02 <TD> oh ok, util.cpp too
307 2012-12-12 15:52:18 <TD> i'm surprised boost doesn't have command line parsing
308 2012-12-12 15:52:26 <gavinandresen> I'm not using boost
309 2012-12-12 15:52:37 <gavinandresen> (on purpose, that's the dependency that seems to trip lots of people up)
310 2012-12-12 15:52:40 <TD> ok
311 2012-12-12 15:53:27 <sipa> i have a branch with a 1.7 leveldb and native windows env port, by the way
312 2012-12-12 15:53:42 <TD> oh, cool. from where?
313 2012-12-12 15:54:12 <sipa> followed a link from someone mentioning it on the leveldb mailinglist
314 2012-12-12 15:54:41 <sipa> i'm not sure how trustable it is, though
315 2012-12-12 15:55:23 <sipa> branch is here: https://github.com/sipa/bitcoin/commits/leveldb17 and the code comes from https://github.com/chirino/leveldb
316 2012-12-12 15:55:46 <sipa> the hard part is migrating gitian to a more recent ubuntu
317 2012-12-12 15:57:08 <sipa> gavinandresen: you're ok with (potentially) migrating to a precise VM for doing the windows builds?
318 2012-12-12 15:57:39 <gavinandresen> sipa: sure. The only reason to use an old VM for builds is compatibilty with old versions of Linux, and that obviously doesn't matter for WIndows
319 2012-12-12 15:58:01 <sipa> indeed; precise has a 4.6.3 GCC for mingw with more recent headers
320 2012-12-12 15:58:12 <sipa> so we can even use things like -flto in builds
321 2012-12-12 15:58:24 <gavinandresen> is precise the latest and greatest?
322 2012-12-12 15:58:51 <sipa> no, but upgrading further shouldn't be a problem, and more recent ubuntu's don't have a more recent mingw gcc
323 2012-12-12 15:59:06 <gavinandresen> if we're going to upgrade, why not upgrade to latest&greatest?
324 2012-12-12 15:59:07 <gavinandresen> if we're going to upgrade, why not upgrade to latest&greatest?
325 2012-12-12 15:59:09 <sipa> anyway, first making it produce a build in the first place - yesterday i was stuck on building qrencode
326 2012-12-12 15:59:31 <sipa> i expect problems creating a quantal image when you're one precise yourself
327 2012-12-12 15:59:45 <gavinandresen> ok. precise is the long-term-support release?
328 2012-12-12 15:59:59 <sipa> yes
329 2012-12-12 16:00:10 <gavinandresen> cool, then that's a good reason to use it.
330 2012-12-12 16:00:21 <TD> gavinandresen: the server side code could also provide an extern "C" api so it's easily exposed via PHP plugins and the like
331 2012-12-12 16:00:47 <sipa> the problem is just because it means switching to mingw-w64 (confusingly enough, that suite also has a 32-bit cross compiler), not switching ubuntu releases
332 2012-12-12 16:00:49 <gavinandresen> TD: good idea.
333 2012-12-12 16:01:10 <sipa> at least i got the native windows leveldb to compile using that
334 2012-12-12 16:01:37 <TD> but did you actually test it on a windows machine :)
335 2012-12-12 16:01:44 <gavinandresen> TD: I imagine the server-side code will get re-implemented a dozen or so times, in python and php and as a loadable apache module and.....
336 2012-12-12 16:02:28 <sipa> TD: no, because i can't build bitcoind using that set yet
337 2012-12-12 16:02:48 <TD> gavinandresen: yeah, maybe. the code isn't quite so straightforward but sure could be
338 2012-12-12 16:02:50 <TD> ACTION -> meeting
339 2012-12-12 16:02:55 <sipa> so first make it build, then i'll try running it
340 2012-12-12 16:21:12 <sipa> wow, gavin merging spree :p
341 2012-12-12 16:21:13 <sipa> wow, gavin merging spree :p
342 2012-12-12 16:21:23 <gavinandresen> wheeeee
343 2012-12-12 16:29:14 <sipa> gavinandresen: hmmm regarding the locking clang stuff, i think the author agreed to take jgarzik's suggestion into account first
344 2012-12-12 16:29:32 <sipa> can be done afterwards, of course
345 2012-12-12 16:29:33 <sipa> can be done afterwards, of course
346 2012-12-12 16:29:42 <gavinandresen> yep
347 2012-12-12 16:34:37 <Diapolo> Gavin, what happened :D. You seem in a rush ^^.
348 2012-12-12 16:34:38 <Diapolo> Gavin, what happened :D. You seem in a rush ^^.
349 2012-12-12 16:34:59 <sipa> no, this is his normal work speed; he was just paused :p
350 2012-12-12 16:35:07 <gavinandresen> I'm done for now.
351 2012-12-12 16:36:43 <gavinandresen> I'm going to pull sipa's parallel transaction-checking code and then re-sync the entire chain on my Mac, so I pulled anything safe/trivial first.
352 2012-12-12 16:36:50 <Diapolo> It's a good thing to merge that little pulls!
353 2012-12-12 16:37:37 <sipa> gavinandresen: benchmark results on OSX would be interesting
354 2012-12-12 16:38:13 <sipa> gavinandresen: the fastest way to re-run block validation is now starting with a fully-up-to-date datadir, deleting the coins/ dir, and restarting the client
355 2012-12-12 16:38:14 <gavinandresen> sipa: what benchmarks would be most interesting?
356 2012-12-12 16:38:15 <gavinandresen> sipa: what benchmarks would be most interesting?
357 2012-12-12 16:38:30 <sipa> that just rebuilds the coindb and undo data
358 2012-12-12 16:38:48 <sipa> difference between -par=1 and -par=N is interesting
359 2012-12-12 16:39:04 <sipa> CPU/memory usage during validation
360 2012-12-12 16:40:02 <gavinandresen> sipa: ok, I'll build a -O3 binary for benchmarking
361 2012-12-12 16:44:56 <sipa> -flto may also help, if you're on a recent GCC
362 2012-12-12 16:46:44 <sipa> (4.6+)
363 2012-12-12 16:46:52 <Diapolo> What does that switch?
364 2012-12-12 16:46:59 <gavinandresen> sipa: I've got an up-to-date-with-0.7.2 datadir (so blk*.dat, not blocks/ ) ... I need to -loadblock first?
365 2012-12-12 16:47:34 <sipa> gavinandresen: yes, or move the blk files to their new location, and -reindex
366 2012-12-12 16:48:27 <sipa> Diapolo: it means the .o files (produced per C++ source file) contain the intermediate representation internal to the compiler, and not fully-compiled assembly code (well, actually both)
367 2012-12-12 16:48:46 <sipa> Diapolo: and when linking the .o files together, the final optimization and compilation step happens
368 2012-12-12 16:48:56 <sipa> so for example it can do inlining across modules
369 2012-12-12 16:49:13 <sipa> as if the entire program was one .cpp file
370 2012-12-12 16:49:16 <gavinandresen> sipa: I'll benchmark with the ancient compiler I've been using first.
371 2012-12-12 16:49:17 <gavinandresen> sipa: I'll benchmark with the ancient compiler I've been using first.
372 2012-12-12 16:49:18 <Diapolo> sipa: so in the it the binary will run faster or compiles faster?
373 2012-12-12 16:49:29 <Diapolo> it = end ^^
374 2012-12-12 16:49:34 <sipa> Diapolo: compiles slower, runs faster (and is typically smaller)
375 2012-12-12 16:49:43 <Diapolo> thanks, will try that one too
376 2012-12-12 16:49:44 <sipa> but the linking step becomes many time slower
377 2012-12-12 16:50:05 <Diapolo> so -O3 does not enable this?
378 2012-12-12 16:50:09 <sipa> no, it can't
379 2012-12-12 16:50:21 <sipa> as it needs changes both at compile time and at link time
380 2012-12-12 16:50:58 <sipa> it can work multi-threaded by the way, -flto=N with N the number of threads
381 2012-12-12 16:51:13 <Diapolo> so is't a CXXFLAG and LFLAG right?
382 2012-12-12 16:51:27 <sipa> CXXFLAGS and LDFLAGS, indeed
383 2012-12-12 16:51:37 <sipa> though i think CXXFLAGS are passed to the linker anyway as well
384 2012-12-12 16:52:41 <Diapolo> thanks sipa
385 2012-12-12 16:54:05 <Rebroad> I notice that armory provides offline wallets.. but it seems to make it more complicated than I'd have thought it needs to be.... surely it should be possible to define an offline wallet by just a list of public addresses, no?
386 2012-12-12 16:55:52 <jgarzik> somehow, my single core CPU mining on mainnet has not produced any blocks yet!
387 2012-12-12 16:56:28 <jgarzik> CreateNewBlock(): total size 249482
388 2012-12-12 16:56:45 <jgarzik> ACTION thinks that he should not be relaying junk unlikely to make it into my own blocks
389 2012-12-12 16:57:45 <gavinandresen> sipa: I tried the move blk*.dat to blocks/ method... after two false starts I figured it out (extra zero in the filenames, and first file is 00000.dat )
390 2012-12-12 17:00:05 <gavinandresen> jgarzik: a size limit (maybe 2x the maximum block size) on the memory pool and evicting transactions based on the priority they'd be accepted into blocks sounds like a good idea to me
391 2012-12-12 17:01:00 <TD> the other thing that can be potentially useful is profile guided optimization
392 2012-12-12 17:01:17 <jgarzik> poolsz is just a measure of junk we kept and relayed. Would be nicer to simply -not- reply junk ;p
393 2012-12-12 17:01:22 <TD> ie, you compile in a special mode, sync the chain/stay on the network for a while, quit, use the generated data files to recompile
394 2012-12-12 17:01:24 <TD> output should be faster
395 2012-12-12 17:01:49 <gavinandresen> jgarzik: sure, but until you see a bunch of transactions fly by your node won't have an idea of what is junk and what isn't.
396 2012-12-12 17:02:37 <gavinandresen> TD: I'd rather we spent time on headers-first download than getting another 2% faster optimization in
397 2012-12-12 17:03:10 <TD> yeah, sure, it was just a note
398 2012-12-12 17:03:11 <TD> yeah, sure, it was just a note
399 2012-12-12 17:04:03 <gavinandresen> jgarzik: in other words, I think the right model is: accept/relay almost anything until your memory pool fills up, then start dropping the lowest-quality transactions (where quality is "what would I put in my blocks if I was a miner")
400 2012-12-12 17:04:51 <TD> i'd actually like to see the memory pool become another leveldb rather than strictly have to be in memory all the time
401 2012-12-12 17:04:58 <TD> but that heuristic is a decent start, i guess
402 2012-12-12 17:05:44 <gavinandresen> TD: we still need to resolve non-final transactions in the memory pool, too. I still think they don't belong there.
403 2012-12-12 17:06:28 <TD> it's pretty fundamental to how they work
404 2012-12-12 17:06:55 <TD> maybe we should start calling it the pending pool? calling it the memory pool just needlessly confines our thinking
405 2012-12-12 17:07:16 <gavinandresen> I don't agree. If you're using non-final transactions for contracts/etc, then the parties involved in the transaction can hold them until they're final. No reason for the entire network to keep them.
406 2012-12-12 17:07:45 <TD> some of the contracts, in particular for micropayments, don't work that way
407 2012-12-12 17:07:58 <TD> the reason for the lock time feature is HFT (which i tend to call micropayment channels, but HFT is a more general idea)
408 2012-12-12 17:08:10 <TD> consider that i want to buy bandwidth off you, or any metered service
409 2012-12-12 17:08:27 <TD> we start swapping new versions of transactions that spend a multisig output. we can do that at high speed, it's a sig generate/verify
410 2012-12-12 17:08:38 <gavinandresen> sure...
411 2012-12-12 17:08:48 <TD> but if i can broadcast the first version of the tx (the one that assigned all value back to me) even after many new versions were signed, it doesn't work
412 2012-12-12 17:09:11 <gavinandresen> if the network rejects non-final transactions then you can't broadcast it.
413 2012-12-12 17:09:13 <TD> the lock time is there to ensure that if i try and rip you off like that, you can observe what i've done and present the network with the latest version
414 2012-12-12 17:10:39 <TD> then i'm still screwed
415 2012-12-12 17:10:48 <TD> you just wait until the first version of the transaction finalizes and broadcast it
416 2012-12-12 17:10:54 <TD> it's a race and whoever is first wins
417 2012-12-12 17:11:09 <TD> the only way this is safe, is if there's an agreed window of time in which the latest version can be presented to the network
418 2012-12-12 17:11:15 <TD> which is why satoshi designed it that way
419 2012-12-12 17:11:21 <gavinandresen> So march the locktime backwards from some point in the future....
420 2012-12-12 17:11:23 <TD> there's no reason locktimed transactions have to be problematic
421 2012-12-12 17:12:23 <gavinandresen> If there are two versions of a transaction, both final, then there's no way to guarantee which one is accepted anyway, no matter what the sequence number rules are (a rogue miner can do whatever they like)
422 2012-12-12 17:13:48 <TD> nothing in bitcoin is guaranteed, it's only about probabilities.
423 2012-12-12 17:14:06 <TD> in theory, it can't work because botnets will double spend on you all the time. in practice it does work.
424 2012-12-12 17:14:33 <TD> locktime being marched backwards means doing it a block at a time. that means that the faster you want to negotiate (the finer the micropayments) the longer the time window has to be
425 2012-12-12 17:14:34 <gavinandresen> Agreed, but I think if one transaction becomes final 10 seconds before another, then that 10-second head start will win 99.9% of the races
426 2012-12-12 17:14:35 <gavinandresen> Agreed, but I think if one transaction becomes final 10 seconds before another, then that 10-second head start will win 99.9% of the races
427 2012-12-12 17:15:00 <TD> what is the exact concern with the original formulation? just disk consumption?
428 2012-12-12 17:15:01 <TD> what is the exact concern with the original formulation? just disk consumption?
429 2012-12-12 17:15:31 <gavinandresen> I don't like that the rules are complicated. And yes, I'm worried about DoS attacks
430 2012-12-12 17:15:35 <TD> bear in mind, i don't even think the memory pool is capped today.
431 2012-12-12 17:16:07 <TD> the rules aren't really that complicated. they let you establish a user-defined window of time in which the best version of a tx can be presented. in the standard case, you don't ever have to actually do a mempool replacement
432 2012-12-12 17:16:08 <gavinandresen> yes, and we have some ugly constants to workaround that
433 2012-12-12 17:16:12 <TD> it's the option of doing so that keeps people honest
434 2012-12-12 17:16:46 <TD> if anyone was to re-activate tx replacement, they'd do some extra anti-dos work anyway
435 2012-12-12 17:16:47 <TD> if anyone was to re-activate tx replacement, they'd do some extra anti-dos work anyway
436 2012-12-12 17:17:22 <jgarzik> indeed, the memory pool is not capped at all, presently
437 2012-12-12 17:17:43 <jgarzik> I've proposed ejecting transactions that do not make it into a block, with lifetime X - 144
438 2012-12-12 17:17:47 <TD> i think we could probably use some heuristics like this:
439 2012-12-12 17:17:48 <gavinandresen> I don't like the economics of nSequence replacement-- you're asking the network to perform a service for you, but you have no incentive to be efficient
440 2012-12-12 17:17:50 <jgarzik> (where X is the current block received)
441 2012-12-12 17:17:57 <jgarzik> thus, you have the network _prove_ the transaction is useless
442 2012-12-12 17:18:00 <jgarzik> and evict based on that
443 2012-12-12 17:18:07 <jgarzik> er, X + 144
444 2012-12-12 17:18:10 <TD> - for the first 120 seconds after you receive a timelocked transaction, keep it in the mempool at the same priority as other transactions
445 2012-12-12 17:18:18 <jgarzik> or X + (144 * N_days)
446 2012-12-12 17:18:24 <TD> - after 120 seconds, drop the priority. if the node runs out of resources, it can be discarded at this point
447 2012-12-12 17:18:55 <TD> that gives participants in HFT protocols plenty of time to spot a cheating attempt and cancel it out, but it means you can't fill up the mempool arbitrarily by just sending coins timelocked far in the future
448 2012-12-12 17:19:16 <TD> gavinandresen: where's the inefficiency?
449 2012-12-12 17:19:37 <TD> ACTION thinks it's quite an elegant design actually, remarkable how satoshi thought it through so far in advance
450 2012-12-12 17:20:28 <TD> together lock times and sequence numbers are a very simple mechanism (hardly a screenful of code) that make a lot of things possible
451 2012-12-12 17:20:51 <gavinandresen> TD: I don't like arbitrary heuristics like "drop after X seconds" or our current "smells like spam if it has less than 0.0001BTC/kb fee"
452 2012-12-12 17:21:07 <TD> sure
453 2012-12-12 17:21:17 <TD> for 120 seconds we can replace it with a function of the nodes resources
454 2012-12-12 17:21:30 <TD> these issues can be resolved if and when somebody sits down to do the work of implementing micropayment channels/HFT
455 2012-12-12 17:21:31 <gavinandresen> So I'd rather the replacement rule was "drop transactions that aren't going to make a profit for me if I put them ina block"
456 2012-12-12 17:21:51 <gavinandresen> ... which means a transaction with a lockTime ten days from now and no fee is definitely a loser.
457 2012-12-12 17:22:06 <gavinandresen> ... nine days from now, or a higher fee, and that's more of a winner...
458 2012-12-12 17:22:09 <TD> it'd only be a loser if the nodes run out of resources and need to throw something out.
459 2012-12-12 17:22:43 <TD> as hardware gets cheaper over time the cost of keeping little bits of data around will fall and the time it takes for transactions to be discarded goes up
460 2012-12-12 17:22:51 <TD> anyway, it's not relevant now
461 2012-12-12 17:22:53 <TD> we have bigger issues to solve
462 2012-12-12 17:22:54 <TD> we have bigger issues to solve
463 2012-12-12 17:27:14 <Luke-Jr> gmaxwell: of course they aren't. I don't see how that's even possible.
464 2012-12-12 17:46:31 <phantomcircuit> i had a dream last night about an ssd
465 2012-12-12 17:46:34 <phantomcircuit> i need to get out more
466 2012-12-12 17:47:10 <phantomcircuit> in other news 0.7.1 saturates mirrored volumes
467 2012-12-12 17:47:17 <phantomcircuit> so is io bound
468 2012-12-12 17:56:24 <sipa> gmaxwell: btw, seems around 10-20% (very rough yes, didn't measure accurately) of script verification is not spent in ECDSA verification
469 2012-12-12 17:56:27 <sipa> which seems a lot
470 2012-12-12 17:56:37 <sipa> s/yes/guess/
471 2012-12-12 18:18:47 <amiller> phantomcircuit, was the ssd hot
472 2012-12-12 18:19:17 <phantomcircuit> amiller, yes i was working it out reaaaly well
473 2012-12-12 18:32:42 <Diablo-D3> GOG.com is giving out DRM free Duke Nukem 3D for free: http://j.mp/DukeNukem3Dfree
474 2012-12-12 18:35:39 <sipa> gavinandresen: moving block files won't work in cooperation with the delete-/coins-trick, as that just rebuilds coins/ to match the state of the block index
475 2012-12-12 18:35:40 <sipa> gavinandresen: moving block files won't work in cooperation with the delete-/coins-trick, as that just rebuilds coins/ to match the state of the block index
476 2012-12-12 18:35:51 <sipa> gavinandresen: but moving files + -reindex should work
477 2012-12-12 18:36:25 <gavinandresen> took 1.5 hours to -reindex after moving/renaming the blk files
478 2012-12-12 18:36:47 <gavinandresen> I'm benchmarking a run after deleting coins/ now
479 2012-12-12 18:37:27 <sipa> with the parallellism active?
480 2012-12-12 18:37:39 <gavinandresen> yes, default parallelism (4 threads on this machine)
481 2012-12-12 18:38:00 <gavinandresen> I assume that doesn't kick in until after the last checkpoint?
482 2012-12-12 18:38:05 <sipa> indeed
483 2012-12-12 18:53:48 <TD> BlueMatt: did i somehow unmerge your comparison tool?
484 2012-12-12 18:56:59 <TD> hmm
485 2012-12-12 19:13:40 <BlueMatt> sipa: yea, the w64 stuff is kinda a misnomer, its just new version (which happens to have 64-bit support)
486 2012-12-12 19:13:41 <BlueMatt> sipa: yea, the w64 stuff is kinda a misnomer, its just new version (which happens to have 64-bit support)
487 2012-12-12 19:14:47 <BlueMatt> sipa: yea, to change the compiler (by default, I think you can override it?) you have to edit the file which was placed at compile-time
488 2012-12-12 19:15:59 <jgarzik> BlueMatt: what is the canonical link for your happy block tester, that TD loves to trumpet?
489 2012-12-12 19:16:04 <BlueMatt> gavinandresen: whats the merge window like for 0.8? I can probably get bloom filters cleaned up by the end of the day friday if it means they can get pulled for 0.8?
490 2012-12-12 19:16:13 <TD> jgarzik: http://code.google.com/r/bluemattme-bitcoinj/source/detail?r=9a38bc965a2559f4f873a3337b815cc34a19f05b&name=fullverif
491 2012-12-12 19:16:23 <TD> i say on that page i merged it, but now i can't find it in the master branch
492 2012-12-12 19:16:24 <TD> i say on that page i merged it, but now i can't find it in the master branch
493 2012-12-12 19:16:28 <TD> so i guess i need to merge it again
494 2012-12-12 19:16:29 <BlueMatt> no, newverif, not fullverif
495 2012-12-12 19:16:39 <jgarzik> It requires Java? hrm.
496 2012-12-12 19:16:50 <BlueMatt> jgarzik: yes, its bitcoinj based
497 2012-12-12 19:17:09 <TD> oh sorry
498 2012-12-12 19:17:13 <BlueMatt> TD: yea, I was wondering where that went
499 2012-12-12 19:17:36 <jgarzik> ACTION was hoping it could be integrated into the bitcoin/bitcoin.git tree
500 2012-12-12 19:17:42 <TD> BlueMatt: do you have more stuff you want me to merge?
501 2012-12-12 19:17:45 <jgarzik> maybe I can translate into C++ or JSON
502 2012-12-12 19:17:46 <gavinandresen> BlueMatt: that should work
503 2012-12-12 19:18:01 <TD> jgarzik: it could be. i don't think there's any requirement that stuff in the bitcoin.git tree be only in C++
504 2012-12-12 19:18:10 <TD> otherwise just use the version from our repo
505 2012-12-12 19:18:21 <jgarzik> TD: realistically, it should be integrated with test_bitcoin for maximal impact
506 2012-12-12 19:18:29 <jgarzik> TD: doing that with Java is simply a high hurdle
507 2012-12-12 19:18:29 <TD> well, it works by comparing two different impls
508 2012-12-12 19:18:30 <TD> well, it works by comparing two different impls
509 2012-12-12 19:19:12 <BlueMatt> jgarzik: not really, though I wouldnt mind a link to https://github.com/TheBlueMatt/test-scripts (which are the scripts run by jenkins/pull-tester)
510 2012-12-12 19:19:22 <jgarzik> TD: so, C++ in bitcoin.git is not a _theoretical_ requirement, but yes it is a realistic and practical requirement
511 2012-12-12 19:19:33 <BlueMatt> TD: not until bloom filters and I get a chance to finalize my db structure changes for upgrade
512 2012-12-12 19:19:34 <BlueMatt> TD: not until bloom filters and I get a chance to finalize my db structure changes for upgrade
513 2012-12-12 19:19:38 <TD> ok
514 2012-12-12 19:19:39 <jgarzik> we have Python in contrib/
515 2012-12-12 19:19:43 <BlueMatt> gavinandresen: alright, Ill have it by then as much as possible then
516 2012-12-12 19:19:51 <jgarzik> no worries. I can probably translate into C++
517 2012-12-12 19:20:15 <jgarzik> BlueMatt: I seriously doubt 0.8-rc1 will appear in < 7 days
518 2012-12-12 19:20:26 <TD> i don't think grabbing a jvm is a particularly high bar, but alright, if you want to do that go ahead
519 2012-12-12 19:20:31 <BlueMatt> jgarzik: eventually the goal is to just get the chain it creates mined and put it in test_bitcoin
520 2012-12-12 19:20:40 <BlueMatt> jgarzik: for now using it as a java app is just a stop-gap until that happens
521 2012-12-12 19:20:40 <TD> you could rely on gcj, i think
522 2012-12-12 19:20:44 <TD> not tested with that for a while
523 2012-12-12 19:21:06 <BlueMatt> jgarzik: yea, though Ive been out of the loop for a while...
524 2012-12-12 19:21:27 <jgarzik> BlueMatt: I would prefer a series of test data in serialized binary form
525 2012-12-12 19:21:36 <jgarzik> BlueMatt: easier to copy those, than procedural code
526 2012-12-12 19:22:14 <sipa> it's much harder to do the big stuff using just a data-driven unit test
527 2012-12-12 19:22:21 <BlueMatt> jgarzik: agreed
528 2012-12-12 19:22:31 <sipa> things like sending some blocks and checking whether you switched to the right block
529 2012-12-12 19:22:45 <sipa> ok, should still be doable actually now i think about it
530 2012-12-12 19:22:46 <sipa> ok, should still be doable actually now i think about it
531 2012-12-12 19:23:16 <BlueMatt> jgarzik: the goal is to have the chain that thing generates to be just one more file in test/data/
532 2012-12-12 19:23:17 <jgarzik> sipa: most of the low level block chain tests should be doable
533 2012-12-12 19:23:35 <jgarzik> I agree there is higher level everything-ties-together state that makes testing some conditions difficult
534 2012-12-12 19:23:49 <sipa> BlueMatt: please do!
535 2012-12-12 19:23:59 <jgarzik> +1
536 2012-12-12 19:24:29 <jgarzik> an external testing client, a la ApacheBench (/usr/bin/ab) would be useful
537 2012-12-12 19:24:30 <jgarzik> an external testing client, a la ApacheBench (/usr/bin/ab) would be useful
538 2012-12-12 19:24:51 <jgarzik> You both standardize on a starting block, such as testnet3 block height 600,
539 2012-12-12 19:24:58 <jgarzik> then execute the test client
540 2012-12-12 19:25:08 <BlueMatt> sipa: we'll see how much time I have, but I may start to throw some of those tests in the bitcoinj test tool thing
541 2012-12-12 19:25:36 <jgarzik> or start at whatever testnet3-in-a-box starts at
542 2012-12-12 19:25:37 <jgarzik> or start at whatever testnet3-in-a-box starts at
543 2012-12-12 19:25:54 <BlueMatt> yep, would be nice
544 2012-12-12 19:26:11 <BlueMatt> esp testing that the testee properly relays blocks to other connections when it receives them, etc
545 2012-12-12 19:26:37 <sipa> well, that's far less of a requirement than block/tx validity
546 2012-12-12 19:26:38 <sipa> well, that's far less of a requirement than block/tx validity
547 2012-12-12 19:26:47 <sipa> but sure, should be tested too
548 2012-12-12 19:28:10 <jgarzik> sipa: given the current protocol does not provide acknowledgements, that might be one useful way of detect tx/block rejection
549 2012-12-12 19:28:13 <BlueMatt> well, yes, test that blocks/txn are verified properly, etc is obv included, but the fact that those are relayed further properly and all that is nice
550 2012-12-12 19:28:34 <jgarzik> P2P never says "rejected" or "accepted"
551 2012-12-12 19:28:35 <jgarzik> P2P never says "rejected" or "accepted"
552 2012-12-12 19:28:41 <jgarzik> just silence, or more silence ;p
553 2012-12-12 19:28:42 <jgarzik> just silence, or more silence ;p
554 2012-12-12 19:28:54 <BlueMatt> it currently just asks for blocks each time to see if it was accepted
555 2012-12-12 19:29:22 <jgarzik> does that detect side chain additions?
556 2012-12-12 19:29:32 <jgarzik> I don't think we can detect that by any method
557 2012-12-12 19:29:33 <jgarzik> I don't think we can detect that by any method
558 2012-12-12 19:29:34 <BlueMatt> no?
559 2012-12-12 19:29:36 <BlueMatt> yea
560 2012-12-12 19:29:58 <TD> reconnect and check the height in the ver message
561 2012-12-12 19:29:59 <TD> reconnect and check the height in the ver message
562 2012-12-12 19:30:53 <jgarzik> To be specific: many valid tests include adding blocks to a weaker chain. it would be nice to confirm that addition each step of the way, rather than only at the point (if ever) when said weak chain becomes the best chain.
563 2012-12-12 19:31:43 <jgarzik> so to confirm the storage of each individual weak chain block
564 2012-12-12 19:35:05 <sipa> BlueMatt: lol, deps build on precise failed with this error:
565 2012-12-12 19:35:06 <sipa> bash: line 59: killall: command not found
566 2012-12-12 19:35:07 <sipa> bash: line 59: killall: command not found
567 2012-12-12 19:35:22 <BlueMatt> no killall?
568 2012-12-12 19:35:29 <sipa> so it would seem!
569 2012-12-12 19:35:42 <sipa> ACTION adds psmisc
570 2012-12-12 19:35:43 <sipa> ACTION adds psmisc
571 2012-12-12 19:35:56 <BlueMatt> (its trying to killall wine something which are left around after running wine so it finishes)
572 2012-12-12 19:35:57 <BlueMatt> (its trying to killall wine something which are left around after running wine so it finishes)
573 2012-12-12 19:36:09 <sipa> indeed
574 2012-12-12 19:46:17 <terraforma> has anyone here tested bitcoin-qt on Xubuntu 12.10 ??
575 2012-12-12 19:47:18 <terraforma> I'm having a strange issue with the icon. Just wondering if anyone else is experiencing the same.
576 2012-12-12 19:47:19 <terraforma> I'm having a strange issue with the icon. Just wondering if anyone else is experiencing the same.
577 2012-12-12 19:47:36 <slush1> terraforma: I'm running it on 12.04 and I have such issues as well
578 2012-12-12 19:48:33 <terraforma> interesting, any idea if its a bug with bitcoin, or XFCE, or GNOME or something?
579 2012-12-12 19:48:34 <terraforma> interesting, any idea if its a bug with bitcoin, or XFCE, or GNOME or something?
580 2012-12-12 19:48:39 <terraforma> lol
581 2012-12-12 19:49:25 <slush1> um, I'm running Xubuntu, but with gnome3 now, a bit unusual configuration :-)
582 2012-12-12 19:49:35 <slush1> I think they changed some API recently, Skype had similar issues.
583 2012-12-12 19:50:13 <terraforma> hmm, that's weird. I hope they work it out soon. Its pretty annoying.
584 2012-12-12 19:50:20 <terraforma> Thanks for validating
585 2012-12-12 19:50:21 <terraforma> Thanks for validating
586 2012-12-12 19:51:24 <slush1> I think that "they" means somebody from bitcoin dev team :)
587 2012-12-12 19:53:39 <BlueMatt> TD: btw, how is my dnsseed doing in getting results back quicker
588 2012-12-12 19:53:49 <TD> it's been fine lately
589 2012-12-12 19:54:00 <TD> i recently checked in some code to parallelise seed lookups
590 2012-12-12 19:54:26 <BlueMatt> TD: thats why I asked, I changed its setup so that it should be returning results really quick
591 2012-12-12 19:54:42 <TD> cool
592 2012-12-12 19:54:44 <BlueMatt> (its using a global set of dns servers now...)
593 2012-12-12 19:54:44 <TD> thanks for that
594 2012-12-12 19:55:27 <TD> btw i checked in a few fixes for chain splitting bugs
595 2012-12-12 19:55:31 <TD> found by FindBugs
596 2012-12-12 19:55:34 <TD> ACTION loves that tool
597 2012-12-12 19:56:28 <BlueMatt> (I just wondered how mine was doing in comparison to jgarzik's because it doesnt have "glue" for the distributed ones so those may not really ever be getting used)
598 2012-12-12 19:56:41 <BlueMatt> (I can update that if its not working)
599 2012-12-12 19:57:39 <sipa> ACTION crosses fingers for new precise build
600 2012-12-12 19:57:41 <gavinandresen> sipa: I just wrote some code (that I'm testing) to use old blkNNNN.dat files when people upgrade to 0.8
601 2012-12-12 19:58:14 <sipa> gavinandresen: to auto-migrate, or just to keep using the old file names?
602 2012-12-12 19:58:39 <sipa> luke also wrote some hacky migrate code alreadt for next-test
603 2012-12-12 19:58:40 <sipa> luke also wrote some hacky migrate code alreadt for next-test
604 2012-12-12 19:58:44 <gavinandresen> I wrote it to hard-link blk0001.dat to blocks/blk00000.dat, and auto-reindex
605 2012-12-12 19:58:56 <sipa> ha
606 2012-12-12 19:59:09 <TD> hard links? on windows?
607 2012-12-12 19:59:19 <gavinandresen> yeah, yay boost!
608 2012-12-12 19:59:23 <TD> huh
609 2012-12-12 19:59:24 <TD> ok
610 2012-12-12 19:59:36 <sipa> TD: i don't think his code is supposed to work on windows :)
611 2012-12-12 19:59:36 <TD> i know NTFS has a feature like that. i guess it's safe to rely on NTFS for a long time
612 2012-12-12 19:59:37 <TD> i know NTFS has a feature like that. i guess it's safe to rely on NTFS for a long time
613 2012-12-12 19:59:58 <gavinandresen> I try to write cross-platform code, and usually succeed....
614 2012-12-12 20:00:13 <TD> heh
615 2012-12-12 20:06:15 <TD> gavinandresen: could you add these lines to the top of paymentrequest.proto please?
616 2012-12-12 20:06:30 <TD> package payments;
617 2012-12-12 20:06:45 <TD> option java_package = "org.bitcoin.protocols.payments";
618 2012-12-12 20:06:58 <gavinandresen> TD: sure
619 2012-12-12 20:07:25 <TD> just to namespace the generated classes nicely
620 2012-12-12 20:07:39 <TD> the .proto file should maybe have comments in it too, from the spec
621 2012-12-12 20:09:11 <TD> oh also
622 2012-12-12 20:09:21 <TD> option java_outer_classname = "Protos";
623 2012-12-12 20:09:28 <TD> otherwise it generates a file with an ugly name like Paymentrequest.java
624 2012-12-12 20:09:29 <TD> otherwise it generates a file with an ugly name like Paymentrequest.java
625 2012-12-12 20:09:34 <TD> (from the proto filename)
626 2012-12-12 20:21:01 <BlueMatt> TD: minor typo in comment for PeerGroup constructor - the name of the option is connectionTimeoutMillis not oonnectionTimeoutMillis
627 2012-12-12 20:21:41 <sipa> ha, deps build succeeded, but my script tried to copy the wrong file :D
628 2012-12-12 20:21:42 <gavinandresen> TD: pushed payments changes
629 2012-12-12 20:21:43 <sipa> ACTION restarts
630 2012-12-12 20:21:49 <TD> BlueMatt: i deleted the connectionTimeoutMillis param
631 2012-12-12 20:21:52 <TD> BlueMatt: are you fully synced to head?
632 2012-12-12 20:21:53 <TD> BlueMatt: are you fully synced to head?
633 2012-12-12 20:22:06 <BlueMatt> TD: I believe so
634 2012-12-12 20:22:07 <TD> gavinandresen: thanks
635 2012-12-12 20:22:34 <BlueMatt> (unless you just pushed something in the last hour)
636 2012-12-12 20:22:57 <TD> oh i see it now
637 2012-12-12 20:23:02 <TD> sorry, i thought you meant in the code
638 2012-12-12 20:23:03 <TD> thanks
639 2012-12-12 20:23:09 <BlueMatt> no, comment, no big deal
640 2012-12-12 20:24:03 <TD> pushed fixed
641 2012-12-12 20:24:10 <TD> fix pushed :)
642 2012-12-12 20:44:37 <slevin> do I ask questions here?
643 2012-12-12 20:45:14 <BlueMatt> TD: NullPointerException in PeerGroup:607 when using connectTo, dont really have time to debug atm, sorry...Ill debug later if you dont get around to it
644 2012-12-12 20:45:44 <TD> hmm
645 2012-12-12 20:45:48 <TD> i have a feeling it may be a race condition
646 2012-12-12 20:45:49 <TD> i have a feeling it may be a race condition
647 2012-12-12 20:45:58 <TD> that code is "not excellent" and is on my hitlist of things to rewrite
648 2012-12-12 20:46:26 <TD> will look some other day though
649 2012-12-12 20:46:32 <sipa> slevin: that depends entirely on yourself :p
650 2012-12-12 20:47:05 <slevin> is it safe to ask questions here, lol
651 2012-12-12 20:49:23 <sipa> BlueMatt:
652 2012-12-12 20:49:24 <sipa> /home/ubuntu/build/boost_1_50_0/stage/lib/libboost_thread_win32-mt-s.a(tss_pe.o):tss_pe.cpp:(.rdata$T+0x0): multiple definition of `__tls_used'
653 2012-12-12 20:49:27 <sipa> /usr/lib/gcc/i686-w64-mingw32/4.6/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-tlssup.o):tlssup.c:(.tls+0x0): first defined here
654 2012-12-12 20:49:35 <sipa> any ideas?
655 2012-12-12 20:49:46 <BlueMatt> crap, Ive seen that...dont remember how to fix though...
656 2012-12-12 20:51:43 <BlueMatt> sipa: https://svn.boost.org/trac/boost/ticket/4258 ?
657 2012-12-12 20:52:08 <BlueMatt> I believe thats where Ive seen it before
658 2012-12-12 20:55:50 <sipa> eww
659 2012-12-12 20:56:46 <TD> gavinandresen: so - i have a series of bytes. it's a payment protocol request. do i parse it as SignedPaymentRequest or just PaymentRequest?
660 2012-12-12 20:57:13 <TD> gavinandresen: we want signing to be optional, so, we need a simple and generic way to distinguish them
661 2012-12-12 20:57:30 <sipa> i suppose you'd need a dummy signed payment request
662 2012-12-12 20:57:37 <TD> gavinandresen: when the signature was embedded into the request, it was easy, just req.has_signature()
663 2012-12-12 20:57:47 <TD> sipa: so a SignedPaymentRequest might not actually be signed?
664 2012-12-12 20:57:58 <sipa> right - defeats the purpose i guess
665 2012-12-12 20:58:33 <TD> it might still be the simplest way to go
666 2012-12-12 20:58:48 <TD> pki_type = "none" and make the pki_data and signature members optional
667 2012-12-12 20:58:53 <sipa> it'd rather be paymentrequest and unsignedpaymentrequest
668 2012-12-12 20:58:54 <TD> or extract the PKI data into a separate message
669 2012-12-12 20:59:06 <sipa> where the second is the payload of the first, and the first is optionally signed
670 2012-12-12 20:59:17 <TD> it also doesn't make a ton of sense to have the payment request version in SignedPaymentRequest rather than PaymentRequest
671 2012-12-12 20:59:31 <TD> perhaps what we want is this:
672 2012-12-12 20:59:33 <TD> message PaymentRequestWrapper {
673 2012-12-12 20:59:42 <TD> optional PKIData pki_data = 1;
674 2012-12-12 20:59:51 <TD> required bytes payment_request_bytes = 2;
675 2012-12-12 21:00:06 <TD> option int32 version = 3 [default=1];
676 2012-12-12 21:00:07 <TD> }
677 2012-12-12 21:00:14 <sipa> something like that, indeed
678 2012-12-12 21:00:46 <sipa> BlueMatt: so... how to fix that? manually patching the boost source in the boost-win32 descriptor?
679 2012-12-12 21:01:04 <BlueMatt> nfc...dont remember
680 2012-12-12 21:01:13 <BlueMatt> try that and see if it fixes it?
681 2012-12-12 21:01:24 <sipa> ha! or passing -D__MINGW64__ to the compiler
682 2012-12-12 21:01:31 <BlueMatt> he
683 2012-12-12 21:02:06 <sipa> because boost assumes mingw64 sets that define, but it doesn't
684 2012-12-12 21:25:56 <TD> srsly. java, you were doing so well
685 2012-12-12 21:26:38 <sipa> BlueMatt: any reason not to upgrade to boost 1.52 for the windows build?
686 2012-12-12 21:27:27 <BlueMatt> sipa: I dont recall, there may have been an issue, maybe Diapolo or wumpus would remember?
687 2012-12-12 21:28:06 <gavinandresen> TD: you should know whether the series of bytes you're getting is a PaymentRequest or a SignedPaymentRequest by whatever protocol is sending it to you. E.g. they'll have different MIME types...
688 2012-12-12 21:28:39 <Zarutian> ACTION notices that he is two dot versions late with his qt bitcoin client
689 2012-12-12 21:28:44 <TD> gavinandresen: why force people to use out of band mechanisms (double the number of file registrations, etc). it seems like unnecessary work when a different message structure makes it all automatic
690 2012-12-12 21:28:59 <gavinandresen> out-of-band? What band is sending you the requests?
691 2012-12-12 21:29:09 <gavinandresen> If HTTP, then you've got the mime type in the header
692 2012-12-12 21:29:18 <gavinandresen> If email, mime type in the attachment metadata
693 2012-12-12 21:29:36 <gavinandresen> if some custom protocol... then yeah, you'll have some way of wrapping messages
694 2012-12-12 21:35:49 <sipa> BlueMatt: i'll just try if that works first
695 2012-12-12 21:36:24 <BlueMatt> sipa: it would be an issue somewhere weird...anyway, just make sure to ping them before pushing
696 2012-12-12 21:39:17 <TD> gavinandresen: ok, sure, but why not just have a single protobuf that can parse any payment request and then just let people check a field to find out what it is?
697 2012-12-12 21:39:38 <TD> i guess i don't see, why using some out of band system, is better than just having a super-type
698 2012-12-12 21:39:44 <TD> ACTION kicks java
699 2012-12-12 21:39:57 <TD> how can sun have made this all so easy until the last line and then screwed things up so badly
700 2012-12-12 21:39:59 <TD> unbelievable
701 2012-12-12 21:40:21 <sipa> TD: what's the problem?
702 2012-12-12 21:40:59 <TD> building cert chains, checking signatures, etc ???. all pretty easy so far. until I want to break apart the X.509 "name" data to get the domain name for which the cert was issued
703 2012-12-12 21:41:09 <gavinandresen> TD: mmm. feels like a religious argument between strong and weak typing. I don't really care, I'm just tired of tweaking the spec. All of the SignedPaymentRequest fields could be made optional, and pki_type could have a "none" setting....
704 2012-12-12 21:41:11 <TD> it ONLY exposes the name data in the form of a string formatted according to some insanely complicated spec
705 2012-12-12 21:41:32 <TD> gavinandresen: that also works for me, if the spec says that a payment request is always a SignedPaymentRequest object.
706 2012-12-12 21:42:20 <gavinandresen> I'll sleep on it, too close to dinner to decide right now
707 2012-12-12 21:43:30 <jgarzik> network news: somebody has been DDoS'ing SatoshiDICE
708 2012-12-12 21:43:51 <jgarzik> this is not the first post, but it does provide some updates: https://bitcointalk.org/index.php?topic=80312.msg1396064#msg1396064 search around for earlier mentions.
709 2012-12-12 21:45:09 <TD> not sure that's a DoS
710 2012-12-12 21:45:10 <TD> not sure that's a DoS
711 2012-12-12 21:45:13 <TD> seeing as they seem to be handling it fine
712 2012-12-12 21:45:32 <jgarzik> there's the original post: https://bitcointalk.org/index.php?topic=80312.msg1391013#msg1391013
713 2012-12-12 21:45:45 <jgarzik> sure, handling it. it's still spamming the block chain, even if they are returning bets.
714 2012-12-12 21:46:03 <TD> so ??? not a dos
715 2012-12-12 21:46:15 <TD> oh, ok
716 2012-12-12 22:04:03 <TD> PKIX is such a pain in the arse
717 2012-12-12 22:04:04 <TD> PKIX is such a pain in the arse
718 2012-12-12 22:05:24 <TD> lol, from the bouncy castle docs
719 2012-12-12 22:05:27 <TD> "It turns out that the number of standard ways the fields in a DN should be encoded into their ASN.1 counterparts is rapidly approaching the number of machines on the internet. "
720 2012-12-12 22:05:31 <TD> brilliant
721 2012-12-12 22:12:03 <sipa> BlueMatt: grr, now there's one new library (context) in boost which we don't need that doesn't build on mingw
722 2012-12-12 22:12:04 <sipa> BlueMatt: grr, now there's one new library (context) in boost which we don't need that doesn't build on mingw
723 2012-12-12 22:12:22 <sipa> and ./bootstrap.sh --without-libraries=context still builds it
724 2012-12-12 22:14:41 <sipa> ah, maybe i need to pass that to bjam too
725 2012-12-12 22:40:44 <sipa> \\o/ build succeeded
726 2012-12-12 22:44:01 <jgarzik> 12/12/12 23:41:33 ERROR: CTxMemPool::accept() : not enough fees 777c4027fac0fb71b9f67b6b724547c25d7f7271fc01eca4b87bf2bb4cca8482, 10000 < 50000
727 2012-12-12 22:44:02 <jgarzik> 12/12/12 23:43:31 ERROR: CTxMemPool::accept() : not enough fees 777c4027fac0fb71b9f67b6b724547c25d7f7271fc01eca4b87bf2bb4cca8482, 10000 < 50000
728 2012-12-12 22:44:24 <jgarzik> for TXs not relayed, I notice the same TX over and over
729 2012-12-12 22:44:30 <jgarzik> seems like we need a negative cache
730 2012-12-12 22:44:37 <jgarzik> if this problem ever scaled
731 2012-12-12 22:44:54 <sipa> sounds good; we need a positive cache too :)
732 2012-12-12 22:45:04 <jgarzik> a "TX seen" set
733 2012-12-12 22:45:05 <jgarzik> a "TX seen" set
734 2012-12-12 22:45:19 <jgarzik> surely the mempool is the positive cache
735 2012-12-12 22:45:24 <sipa> it's not
736 2012-12-12 22:45:42 <sipa> the mempool doesn't contain things that were already accepted into to blockchain and entirely spent
737 2012-12-12 22:45:57 <jgarzik> ah true
738 2012-12-12 22:46:22 <gmaxwell> Odd.. I thought we had the negative cache problem (e.g. rerequestng non-standard txn), but when I checked my own nodes I didn't see any repeated fetches.
739 2012-12-12 22:46:26 <sipa> and having a positive/negative cache allows you to skip tx validation (except for spentness of inputs) entirely
740 2012-12-12 22:47:09 <sipa> anyone on windows here?
741 2012-12-12 22:54:54 <jgarzik> hmmm. Difficult to tell when to add to the TX-seen cache.
742 2012-12-12 22:56:06 <jgarzik> Cannot do it in the AlreadyHave() call, because the peer->AskFor() that is triggered may not result in any useful response.
743 2012-12-12 22:57:11 <sipa> you add it as soon as you've tried connecting it
744 2012-12-12 22:57:30 <sipa> before that you don't know if it's valid or not
745 2012-12-12 22:58:04 <gmaxwell> yea, has to be after you've checked the hash, otherwise I tell you I have AAAA and give you bad data, you reject it and never pull AAAA.
746 2012-12-12 22:58:13 <sipa> indeed
747 2012-12-12 22:58:29 <sipa> but not just CheckTransaction, as that gets called for orphans as well
748 2012-12-12 22:58:39 <sipa> and you don't know whether orphans are valid yet
749 2012-12-12 23:21:47 <sipa> bah, seems the produced file depends on some gcc .dll's
750 2012-12-12 23:22:30 <gmaxwell> sipa: ssp.dll?
751 2012-12-12 23:22:53 <jgarzik> sipa: maybe you want -static-libgcc and/or -static-libstdc++
752 2012-12-12 23:23:00 <sipa> indeed
753 2012-12-12 23:23:22 <sipa> libgcc_s_sjlj-1.dll, libstdc++6.dll, libgcc_s_dm2-1.dll
754 2012-12-12 23:23:23 <sipa> iirc
755 2012-12-12 23:52:12 <roconnor> etotheipi_: ping