1 2013-03-06 00:02:05 occulta has joined
2 2013-03-06 00:02:31 defunctzombie is now known as defunctzombie_zz
3 2013-03-06 00:04:49 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
4 2013-03-06 00:05:42 COGSMITH has joined
5 2013-03-06 00:09:26 osmosis has joined
6 2013-03-06 00:15:03 Hasimir has joined
7 2013-03-06 00:20:26 K1773R is now known as K1773R|OFF
8 2013-03-06 00:22:10 gritcoin has quit (Quit: gritcoin)
9 2013-03-06 00:24:16 <DBordello> Any RPC commands change in 0.80? Any reason I should be afraid of upgrading for an integrated service?
10 2013-03-06 00:25:08 <gmaxwell> if your service needs an index of non-wallet transaction (e.g. available via getrawtransaction) that index is now optional and off by default.
11 2013-03-06 00:25:47 <sipa> gmaxwell: drop the 'e.g.'
12 2013-03-06 00:26:01 ielo has quit (Ping timeout: 245 seconds)
13 2013-03-06 00:28:02 mtve has joined
14 2013-03-06 00:35:19 sgornick has quit (Ping timeout: 250 seconds)
15 2013-03-06 00:36:37 MobGod has joined
16 2013-03-06 00:38:13 zooko` has quit (Read error: Operation timed out)
17 2013-03-06 00:38:53 Diablo-D3 has quit (Quit: do coders dream of sheep()?)
18 2013-03-06 00:39:33 Diablo-D3 has joined
19 2013-03-06 00:41:42 B0g4r7 has quit (Ping timeout: 276 seconds)
20 2013-03-06 00:41:45 knotwork has quit (Ping timeout: 245 seconds)
21 2013-03-06 00:43:04 DarkGhost-c has joined
22 2013-03-06 00:43:41 <DarkGhost-c> hi guys, I have bitcoind on my server and for some reason. whenever I create an address and someone sends money to it
23 2013-03-06 00:43:47 <DarkGhost-c> it takes forever for it to show up
24 2013-03-06 00:43:59 <sipa> define forever
25 2013-03-06 00:44:41 <warren> sipa: the unit of time until Mickey Mouse falls into the public domain
26 2013-03-06 00:45:10 <DarkGhost-c> easily an hour.
27 2013-03-06 00:45:37 <gmaxwell> DarkGhost-c: what do you mean by 'show up'?
28 2013-03-06 00:45:42 <Scrat> DarkGhost-c: was that today? because there were some slow blocks today
29 2013-03-06 00:45:57 <sipa> DarkGhost-c: does that mean the transaction not showing up (listtransactions; this should be in seconds), or the balance not being counted (which requires a confirmation, and care take minutes-hours)
30 2013-03-06 00:45:59 <gmaxwell> transactions that relay should be visible in list transactions instantly.
31 2013-03-06 00:46:14 <sipa> s/care/can/
32 2013-03-06 00:46:45 <Scrat> what I said only applies if you're using getbalance
33 2013-03-06 00:49:49 vampireb has quit (Quit: Lost terminal)
34 2013-03-06 00:49:52 B0g4r7 has joined
35 2013-03-06 00:51:31 knotwork has joined
36 2013-03-06 00:51:44 Diablo-D3 has quit (Quit: do coders dream of sheep()?)
37 2013-03-06 00:51:57 <DBordello> gmaxwell, we do not index non-wallet transactions, but do use getrawtransaction
38 2013-03-06 00:52:12 Diablo-D3 has joined
39 2013-03-06 00:52:56 <sipa> DBordello: if you use getrawtransaction, you'll most likely need to set txindex=1
40 2013-03-06 00:53:08 <gmaxwell> DBordello: what do you use getrawtransanction on?
41 2013-03-06 00:53:30 <sipa> actually, we should have a getrawtransaction like function that fetches from the wallet...
42 2013-03-06 00:53:51 Mrcheesenips has quit (Read error: Connection reset by peer)
43 2013-03-06 00:53:56 DarkGhost-c has quit (Ping timeout: 255 seconds)
44 2013-03-06 00:54:35 Mrcheesenips has joined
45 2013-03-06 00:55:11 <gmaxwell> I'm going to keep thinking that getrawtransanction checks the wallet too, until it does.
46 2013-03-06 00:55:59 <sipa> haha
47 2013-03-06 00:56:35 <sipa> i just dislike mixing blockchain-querying functions with wallet-querying one, as that will complicate separating the two
48 2013-03-06 00:57:18 <gmaxwell> generally I agree, though, reading it from the wallet is like reading it from the mempool.
49 2013-03-06 00:57:40 <gmaxwell> so I usually expect anything that will return from the mempool will return the wallet too.
50 2013-03-06 00:57:55 <sipa> makes sense
51 2013-03-06 00:58:03 splnkr has joined
52 2013-03-06 00:58:44 <DBordello> I use getrawtransaction to determine the address that sent the transaction
53 2013-03-06 00:58:57 <DBordello> However, they are wallet-bound transactions
54 2013-03-06 00:59:00 <gmaxwell> lol
55 2013-03-06 00:59:12 <gmaxwell> What service do you run?
56 2013-03-06 00:59:17 <DBordello> BTCPak.com
57 2013-03-06 00:59:24 <DBordello> (We check for green addresses)
58 2013-03-06 00:59:30 <DBordello> (And I aware of gmaxwell's opinion of those :)
59 2013-03-06 00:59:37 <gmaxwell> welp, enjoy your extra giga of storage.
60 2013-03-06 00:59:38 <sipa> not only his opinion
61 2013-03-06 01:00:01 <DBordello> Although not a great solution, it does work very well
62 2013-03-06 01:00:10 <petertodd> gmaxwell: The wallet will happily contain transactions that don't make it to the mempool, e.g. nLockTime
63 2013-03-06 01:00:13 <sipa> i'm sure it works; it just doesn't scale
64 2013-03-06 01:00:43 hydrogenesis has joined
65 2013-03-06 01:00:48 <sipa> and it will prevent you from pruning one day
66 2013-03-06 01:00:52 <gmaxwell> as an example of how well it doesn't work, it means you can't run a pruned node, and even on 0.8 prevents you from enjoying an 800MB and growing disk space (and IO) savings.
67 2013-03-06 01:01:17 <DBordello> 1GB of space is not a big concern
68 2013-03-06 01:01:19 <sipa> perhaps we should just implement pruning, so people have a reason to disable txindex and services that rely on it
69 2013-03-06 01:01:37 <DBordello> Especially versus allowing us to accept zero-confirmation transactions from trusted sources
70 2013-03-06 01:01:47 <gmaxwell> DBordello: sure sure, but it's 1GB today, it will grow linearly.
71 2013-03-06 01:01:51 <gwillen> gmaxwell, sipa: Tell me your opinions about green addresses :-)
72 2013-03-06 01:02:13 <DBordello> gmaxwell, understood. The cost of doing business
73 2013-03-06 01:02:14 <sipa> gwillen: abuse of the blockchain as a communication channel between sender and receiver
74 2013-03-06 01:02:37 <sipa> and decreasing privacy
75 2013-03-06 01:02:55 <gwillen> do 'green' address schemes use the blockchain for information-passing directly, or just implicitly by whitelisting addresses?
76 2013-03-06 01:03:16 <sipa> implicitly, but they typically require 2 transactions instead of one
77 2013-03-06 01:03:22 <gwillen> interesting; why is that?
78 2013-03-06 01:03:31 occulta has quit (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/)
79 2013-03-06 01:03:36 <gmaxwell> because they're abusing the blockchain for communication. :P
80 2013-03-06 01:03:45 <sipa> because they don't receive everything at the green address, so they must first send to the green address, and then to the actual destination
81 2013-03-06 01:03:50 <gwillen> please humor me and explain how they actually work :-)
82 2013-03-06 01:03:51 <gwillen> ahh, I See
83 2013-03-06 01:03:52 <gwillen> see*
84 2013-03-06 01:04:23 <sipa> plus it requires very manual trust management (which is not necessarily a problem)
85 2013-03-06 01:04:36 <gmaxwell> DBordello: A cost you're not just taking yourself, but one you're imposing on the whole world. Because mtgox is too lazy to setup a channel for you to get auths for instant transactions externally, instead the blockchain gets bloated forever with these additional authorization signatures.
86 2013-03-06 01:04:38 <gwillen> I'm curious -- how (if at all) do you anticipate preventing or dealing with the issue of people using the blockchain for communication?
87 2013-03-06 01:04:42 <DBordello> gwillen, Mt. Gox has posted a "green address" that they own. Since I trust Mt.Gox to not doublespend me, I accept transactions from the green address with zero-confirmations
88 2013-03-06 01:04:51 <gwillen> gmaxwell, sipa: ^
89 2013-03-06 01:04:52 <DBordello> However, it requries two transactions, Internal Mt.Gox -> Green -> Me
90 2013-03-06 01:04:55 <sipa> gwillen: by providing better solutions that are easier
91 2013-03-06 01:04:56 <gmaxwell> gwillen: competition for blockchain space generally will address that.
92 2013-03-06 01:04:58 <sipa> gwillen: like a payment protocol
93 2013-03-06 01:05:11 <gwillen> so you're not in the luke-jr "ban 'em all" camp? :-)
94 2013-03-06 01:05:40 <sipa> i don't think that's a productive way of dealing with things
95 2013-03-06 01:05:43 <DBordello> gmaxwell, good point
96 2013-03-06 01:05:57 <gwillen> in particular, if you think that competition for blockchain space will address it, then it seems fine to use the blockchain for communication given that the transaction fees so generated as as good as anybody else's
97 2013-03-06 01:06:10 <gwillen> but if you think that such competition is _not_ sufficient, then perhaps other means are needed
98 2013-03-06 01:06:20 <sipa> i'm not sure it is sufficient
99 2013-03-06 01:06:34 <sipa> as it imposes a cost on fully verifying nodes which aren't getting paid
100 2013-03-06 01:06:45 * gwillen nods
101 2013-03-06 01:06:47 <gmaxwell> Green addresses also goof up privacy for all bitcoin users. It means that if sayâ a religious advocacy group recieves some funds, and then get raded by the state-approve-religion group, and they see that two hops back the funds were mtgox-green they can go ask mtgox what user generated the txn, then investigate them.. etc.
102 2013-03-06 01:07:02 <gwillen> sipa: do you have any thoughts on how you would prevent it?
103 2013-03-06 01:07:02 <petertodd> You know, if you want to do green addresses "right", use P2SH multisig, so that one signature differs so customers all have different deposit addresses, and the other signature can identify the "green" service.
104 2013-03-06 01:07:04 <sipa> which may lead to a decrease of such nodes, ultimately resulting in a decreased trustability of bitcoin as a whole
105 2013-03-06 01:07:11 <sipa> gwillen: as i said, payment protocol
106 2013-03-06 01:07:12 <gwillen> sipa: aside from 'competition for blockchain space'?
107 2013-03-06 01:07:14 <gmaxwell> So even if you're not personally a green address user if anyone you trade with is, or anyone they trade with is.. and so on, then your privacy is diminished.
108 2013-03-06 01:07:30 <muhoo> heh, is fireduck SD?
109 2013-03-06 01:07:33 <gwillen> sipa: that doesn't really solve the general problem, though; the blockchain is incredibly valuable as a communication tool, and more people are going to use it that way
110 2013-03-06 01:07:34 sgornick has joined
111 2013-03-06 01:07:41 <gwillen> sipa: you can solve this instance, but there will be more
112 2013-03-06 01:07:55 <sipa> gwillen: the blockchain _sucks_ as a communication tool: it is slow, unreliable and expensive
113 2013-03-06 01:08:04 <muhoo> gotta love commit comments like "moo" and code comments like "making mushroom soup, I am" http://code.google.com/r/fireduck-magicpony/source/list
114 2013-03-06 01:08:13 <gmaxwell> gwillen: it's actually pretty worthless as a communication tool. It is a low bandwidth worldwide broadcast medium with prepetual stoarge.. there just isn't room to do much communication with it.
115 2013-03-06 01:08:25 <sipa> gwillen: and by expensive i mean the total cost for the world operating it, not just fees
116 2013-03-06 01:08:38 <gmaxwell> perpetual*
117 2013-03-06 01:08:40 <gwillen> well, that kind of expense is an interesting issue
118 2013-03-06 01:08:45 <gwillen> since it's an externality so it won't actually stop anybody
119 2013-03-06 01:08:48 <sipa> but even aside from the cost
120 2013-03-06 01:09:08 <sipa> it is unreliable (i'm mostly talking about the P2P protocol, not just the blockchain maintained by it)
121 2013-03-06 01:09:11 <sipa> and slow
122 2013-03-06 01:09:30 <sipa> while you're typically just communicating directly from sender to receiver anyway (example: visiting their website)
123 2013-03-06 01:09:33 <gwillen> slow is fair enough; how unreliable is it, when you use a reasonably-high tx fee?
124 2013-03-06 01:09:49 <gmaxwell> gwillen: It's also insanely not private, as mentioned aboveâ attaching mtgox names to lots of transactions craps up user's privacy because it makes it easier for unrelated people to trace the transactions.
125 2013-03-06 01:09:53 <sipa> why do you want to pay when TCP/IP connections are cheaper than dirt?
126 2013-03-06 01:10:05 <BlueMatt> gmaxwell/sipa: out of curiosity, how much do you use so while coding?
127 2013-03-06 01:10:06 <sipa> you can just *tell* them if there was a protocol for doing so
128 2013-03-06 01:10:27 <gwillen> well, as you say, the blockchain is global, broadcast, and perpetual
129 2013-03-06 01:10:32 <gmaxwell> gwillen: its either unreliable or costly to you (not an externality)
130 2013-03-06 01:10:41 <gwillen> there are plenty of uses for such a thing where you don't necessarily have a TCP connection to whoever you're communicating with
131 2013-03-06 01:10:42 <gmaxwell> take your pick.
132 2013-03-06 01:10:42 <Luke-Jr> gwillen: none of which are important for communication
133 2013-03-06 01:10:44 <sipa> BlueMatt: sometimes, though mostly for languages i'm less familiar with (like python)
134 2013-03-06 01:11:02 mappum has quit (Ping timeout: 255 seconds)
135 2013-03-06 01:11:05 <sipa> gwillen: agree, there are cases where just communication directly isn't a good fit
136 2013-03-06 01:11:12 <gwillen> so for example, supposing someone were going to run a message-certification / timestamping service
137 2013-03-06 01:11:15 <gmaxwell> BlueMatt: almost never, except for things I'm unfamilar with like sipa says.
138 2013-03-06 01:11:17 <gwillen> and they did this by tossing hashes into the blockchain
139 2013-03-06 01:11:24 <gwillen> (as few hashes as they could get away with, but still some)
140 2013-03-06 01:11:30 <BlueMatt> ok, but how much do you use other docs for languages you are more farmiliar with?
141 2013-03-06 01:11:31 <gwillen> would you consider this abusive? how would you prevent it, if so?)
142 2013-03-06 01:11:36 <petertodd> gwillen: there are better ways to do that
143 2013-03-06 01:11:38 <gmaxwell> gwillen: you can get away with adding 0 marginal hashes for timestamping.
144 2013-03-06 01:11:43 <sipa> gwillen: if in the coinbase, it's perfectly fine to me
145 2013-03-06 01:11:52 <sipa> and you never need more than 1 hash anyway (merkle tree)
146 2013-03-06 01:12:11 <gwillen> so adding a little bit of information for a good cause is okay, in your view
147 2013-03-06 01:12:12 <sipa> (see chronobit)
148 2013-03-06 01:12:20 <petertodd> gwillen: I've already implemented that actually, and it'll be coinbase too before long
149 2013-03-06 01:12:40 <gwillen> sipa: ah, yes -- chronobit looks like exactly the sort of thing I had in mind, yes
150 2013-03-06 01:12:42 <sipa> gwillen: if that cause doesn't conflict with the interests of those who pay for having bitcoin as a financial medium
151 2013-03-06 01:12:55 <sipa> gwillen: i.e., those running a full node
152 2013-03-06 01:12:57 <gmaxwell> gwillen: but chronobit adds nothing to the blockchain.
153 2013-03-06 01:13:02 <petertodd> gwillen: You can also piggy-back on high volume transactions, and stuff your hashes in the sequence numbers of transactions with a few inputs.
154 2013-03-06 01:13:15 <gwillen> what does chronobit do -- use the nonce or something?
155 2013-03-06 01:13:26 <petertodd> chronobit uses p2pool
156 2013-03-06 01:13:26 <gwillen> it has to store the hash somewhere :-)
157 2013-03-06 01:13:29 <gmaxwell> gwillen: no, it includes it in an existing merge mining hashtree.
158 2013-03-06 01:13:33 <gmaxwell> gwillen: no. it doesn't.
159 2013-03-06 01:13:55 <petertodd> basically your hash goes in a share you mine as part of the p2pool share chain, which eventually makes it to a p2pool share, and then the blockchain
160 2013-03-06 01:14:16 <gwillen> I see
161 2013-03-06 01:14:17 <petertodd> Currently the proofs are way length, because the p2pool share chain is strictly linear, but that can be fixed.
162 2013-03-06 01:14:25 <gwillen> so merged mining is already putting information in the blockchain
163 2013-03-06 01:14:37 <sipa> a constant amount per block, yes
164 2013-03-06 01:14:40 <gwillen> so the additional information for timestamping is going into a merged-mining chain somewhere
165 2013-03-06 01:14:44 <petertodd> Yes, but a fixed amount of information, for any amount of merge-mined chains.
166 2013-03-06 01:14:44 <gwillen> and not into the bitcoin chain directly
167 2013-03-06 01:14:55 <sipa> it's not really a separate chain
168 2013-03-06 01:14:59 <gwillen> I guess I should try to understand how merged mining works
169 2013-03-06 01:15:04 <gwillen> I am not very clear on it
170 2013-03-06 01:15:06 <sipa> it's just data being committed in the merged mining tree
171 2013-03-06 01:15:12 <gmaxwell> gwillen: If I sound impatient its because its a little frustrating that when confronted with the slighest bit of complexity many people's first resort is crapping externalized cost over other people rather than stepping up and taking a one time cost to under how what they want can be accomplished near costlessly for everyone.
172 2013-03-06 01:15:38 <gwillen> gmaxwell: well, I'm approaching this from the perspective that there is an infinite variety of people who are going to have various uses for the blockchain in the future
173 2013-03-06 01:15:46 <gwillen> and you're going to disagree with some of them, and that will not stop them
174 2013-03-06 01:15:48 <gwillen> so I'm interested in what will
175 2013-03-06 01:16:06 <petertodd> gwillen: Yes, and we're going to crap all over them the same way we hate litterers.
176 2013-03-06 01:16:06 <gmaxwell> gwillen: I gave the ultimate answer way up above.
177 2013-03-06 01:16:18 <gmaxwell> And part of it is social, as petertodd points out.
178 2013-03-06 01:16:22 <sipa> gwillen: well if there are two groups of people, who want to use it for strictly separate purposes, i think they might just kill eachother by forcing their costs onto eachother
179 2013-03-06 01:16:40 <sipa> resulting in a solution that is cheaper for both if they'd run it separately
180 2013-03-06 01:18:17 <muhoo> gmaxwell: externalizing costs is what makes capitalism run :-)
181 2013-03-06 01:18:30 <gwillen> okay, so if I'm understanding this correctly, at least for namecoin merged mining -- which apparently differs from p2pool merged mining -- the extra information in the bitcoin chain is going into the coinbase scriptSig?
182 2013-03-06 01:18:43 <gmaxwell> gwillen: not quite.
183 2013-03-06 01:18:43 <sipa> yes
184 2013-03-06 01:18:53 <gwillen> (I am reading https://en.bitcoin.it/wiki/Merged_mining_specification .)
185 2013-03-06 01:18:56 <gmaxwell> gwillen: There is a hashtree committed to in the coinbase.
186 2013-03-06 01:19:08 <gmaxwell> gwillen: but there can be an unbounded number of things committed via that one hash.
187 2013-03-06 01:19:12 <gwillen> yes, I understand
188 2013-03-06 01:19:25 <gwillen> specifically the extra bytes that make it into the bitcoin chain are what I am asking about
189 2013-03-06 01:19:34 ByteUnit has quit (Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331])
190 2013-03-06 01:19:42 <gmaxwell> E.g. 100,000 timestamps plus namecoin plus i0coin plus foobarcoin plus whatever, there is just the one hash.
191 2013-03-06 01:19:49 <gwillen> indeed
192 2013-03-06 01:19:57 ahbritto has quit (Ping timeout: 250 seconds)
193 2013-03-06 01:20:02 <gmaxwell> and those bytes are now already there, so no more ever need to be added.
194 2013-03-06 01:20:10 ahbritto__ has quit (Ping timeout: 256 seconds)
195 2013-03-06 01:20:16 <sipa> well, they are optional
196 2013-03-06 01:20:25 <gwillen> they are there in merge-mined blocks, but not non-merge-mined blocks, yes?
197 2013-03-06 01:20:37 <gwillen> not quibbling, just making sure I understand what's happening
198 2013-03-06 01:20:51 <gmaxwell> gwillen: they're there when miners participating in some kind of merged mining mine blocks and not otherwise.
199 2013-03-06 01:20:56 * gwillen nods
200 2013-03-06 01:21:08 <gwillen> and they include-by-reference whichever aux trees those merged miners are mining
201 2013-03-06 01:21:12 <gmaxwell> (not sure if "there in merge-mined blocks, but not non-merge-mined blocks" reflects a confused understanding or not, it could)
202 2013-03-06 01:21:13 <gwillen> for whichever merged miners happen to find that block.
203 2013-03-06 01:21:16 <sipa> but i don't think many people would care about a 32-byte increase per block (1.6 MiB per year!!!) if that results in a near-infinite amount of data that can be committed to the chain
204 2013-03-06 01:21:42 bock has quit (Quit: Verlassend)
205 2013-03-06 01:21:47 <gwillen> sipa: well, I'm trying to understand how hard of a line people are taking against extra information in the chain that is not directly relevant to bitcoin itself :-)
206 2013-03-06 01:21:50 <sipa> but it's all costs/benefits, and community consensus about it
207 2013-03-06 01:21:54 * gwillen nod
208 2013-03-06 01:21:54 ahbritto has joined
209 2013-03-06 01:22:24 <sipa> if everyone in the bitcoin community wants to have their familfy photos stored in the blockchain, there is not really a problem
210 2013-03-06 01:22:32 <yebyen> well i think i learned that if you're starting a new testnet chain, you can't just discard the wallet of the original chain, because your generating nodes won't have any transactions to use as inputs
211 2013-03-06 01:22:34 ahbritto__ has joined
212 2013-03-06 01:22:50 <yebyen> can anyone say if that's true?
213 2013-03-06 01:22:53 <petertodd> yebyen: Huh?
214 2013-03-06 01:23:02 <sipa> "start a new testnet chain" ... wut?
215 2013-03-06 01:23:05 <petertodd> yebyen: Generating a block doesn't use transactions for inputs.
216 2013-03-06 01:23:07 <gwillen> sipa: if you're limited to using coinbase, of course that's only true if you can convince a merged-mining group to include your family photos somewhere, yes?
217 2013-03-06 01:23:19 <yebyen> petertodd: i thought a block would have to publish a transaction
218 2013-03-06 01:23:21 <gwillen> sipa: although if p2pool is going to start stamping arbitrary data you can use that
219 2013-03-06 01:23:24 <gmaxwell> gwillen: fundimentally the extra information is parasitic. Does it come along with benefits or not? do those benefits offset the costs?
220 2013-03-06 01:23:39 <yebyen> i cleared both the wallets and the blockchain and my testnet in a box sat for hours without generating any blocks
221 2013-03-06 01:23:47 <gmaxwell> gwillen: so? you can only include a transaction if you can convince a miner to include it. Thats the same question.
222 2013-03-06 01:23:49 <petertodd> yebyen: No, a block is the one example where a transaction is created with no inputs, so it's legal for a block to have no transactions in it at all.
223 2013-03-06 01:23:50 <sipa> yebyen: were you mining?
224 2013-03-06 01:24:04 <petertodd> yebyen: I suspect you weren't mining at all, or your computer is just really, really slow.
225 2013-03-06 01:24:09 <yebyen> sipa: sure, hashes per second in the kilohundreds
226 2013-03-06 01:24:11 <petertodd> yebyen: Was CPU usage at 100%?
227 2013-03-06 01:24:18 <gmaxwell> was gen=1 set?
228 2013-03-06 01:24:20 <gwillen> gmaxwell: but I assume if people started using the scriptSig in non-coinbase transactions to add a hash of auxilliary data, you'd feel less charitable?
229 2013-03-06 01:24:20 <yebyen> yep
230 2013-03-06 01:24:27 <gwillen> gmaxwell: since that will inflate the blockchain faster?
231 2013-03-06 01:24:27 <yebyen> it's only a tegra2
232 2013-03-06 01:24:30 <yebyen> so dual core arm
233 2013-03-06 01:24:34 <yebyen> two nodes at 140000
234 2013-03-06 01:24:56 <gmaxwell> gwillen: the practice on the network already substantially prohibits that.
235 2013-03-06 01:25:01 <yebyen> but leaving the wallets and clearing the blockchain, it reliably generated the first block in about 10 or 20 minutes
236 2013-03-06 01:25:13 <yebyen> assert that twice is a good measure of reliably
237 2013-03-06 01:25:14 <sipa> yebyen: i think you were just lucky
238 2013-03-06 01:25:23 <gmaxwell> gwillen: transactions with extra crud in the scriptsig are non-standard and won't be relayed or mined.
239 2013-03-06 01:25:26 <gwillen> gmaxwell: because miners won't mine transactions with scriptsigs that have 'interesting' contents?
240 2013-03-06 01:25:27 <sipa> the wallet has nothing to do with the block chain
241 2013-03-06 01:25:30 * gwillen nods
242 2013-03-06 01:25:36 <gwillen> gmaxwell: they don't affect block validity, right? Just relaying and mining?
243 2013-03-06 01:25:41 <sipa> gwillen: indeed
244 2013-03-06 01:25:43 * gwillen nods
245 2013-03-06 01:25:51 <petertodd> yebyen: Hmm... at diff 1 you need to calculate 2*31 hashes on average to find a block, so expected time between blocks is about an hour.
246 2013-03-06 01:26:05 <yebyen> well
247 2013-03-06 01:26:14 <yebyen> i did not know that
248 2013-03-06 01:26:16 <gmaxwell> gwillen: it's simple survivalâ bitcoin can't survive if people use it as a data trashbin because they want to externalize their storage costs onto the worlds most inefficient storage system. :P
249 2013-03-06 01:26:16 <sipa> petertodd: 2^32, no?
250 2013-03-06 01:26:27 <petertodd> sipa: I mean 50:50 chance
251 2013-03-06 01:26:32 <petertodd> sipa: I think that's right...
252 2013-03-06 01:26:33 <yebyen> is it possible to ratchet the client code to allow the difficulty to drop below 1?
253 2013-03-06 01:26:42 <petertodd> sipa: So 95% would be a few hours
254 2013-03-06 01:26:48 <yebyen> without major overhauls
255 2013-03-06 01:26:50 <petertodd> yebyen: Yes, by editing the source code.
256 2013-03-06 01:27:01 <yebyen> minDifficulty or something
257 2013-03-06 01:27:02 <gwillen> gmaxwell: well, if bitcoin will not survive, then I definitely want to sell my coins. ;-) I hope you're clear by now on the fact that I'm not planning to use it as a storage dumping ground, I just want to understand the issues around people doing that.
258 2013-03-06 01:27:07 <gmaxwell> gwillen: so people will use social, technical, structural, and legal mechanisms as approiate to encourage sane usage.
259 2013-03-06 01:27:11 * gwillen nods
260 2013-03-06 01:27:45 RazielZ has quit (Ping timeout: 264 seconds)
261 2013-03-06 01:27:49 <gmaxwell> gwillen: well I think it's fine. We have lots of tools.
262 2013-03-06 01:27:54 * gwillen nods
263 2013-03-06 01:28:00 <sipa> petertodd: 50% would be almost 3 billion hashes
264 2013-03-06 01:28:11 <muhoo> legal?
265 2013-03-06 01:28:13 <petertodd> sipa: Ah - I've never taken stats...
266 2013-03-06 01:28:29 <petertodd> muhoo: Sure, we'll track you down and sue you for abusing a computer service.
267 2013-03-06 01:28:29 <muhoo> i thought this stuff exists totally outside the law
268 2013-03-06 01:28:31 <sipa> petertodd: short story: distribution is assymetric, so median != mean
269 2013-03-06 01:28:45 <gmaxwell> What can happen is that datapackrats will have to compete with currency users for space, which is kinda a bummer as it drives up costs for currency users, but at some point it de-externalizes costs enough to get the packrats their own home.
270 2013-03-06 01:28:50 <petertodd> muhoo: Enforcement is difficult, that's it.
271 2013-03-06 01:29:21 <gmaxwell> muhoo: uh. nothing exists outside the law...
272 2013-03-06 01:29:35 grau has joined
273 2013-03-06 01:30:02 <sipa> gmaxwell: is 'packrats' a word, or did you make the same typo twice?
274 2013-03-06 01:30:13 <gwillen> actually, and I hesitate to suggest another means of abuse because I suspect it will get me yelled at... ;-) -- can you make a transaction with an output of zero coins? If so, you could use the pubkeyhash field to store the hash of an aux merkle tree.
275 2013-03-06 01:30:15 <BlueMatt> its a word
276 2013-03-06 01:30:27 <BlueMatt> sipa: ^
277 2013-03-06 01:30:28 <gmaxwell> I'm trying to avoid saying spammer so instead: http://en.wikipedia.org/wiki/Pack_rat
278 2013-03-06 01:30:32 <gwillen> without violating the usual rules on scriptPubKeys.
279 2013-03-06 01:30:42 <sipa> gwillen: it's valid, but non-standard
280 2013-03-06 01:30:43 <petertodd> gwillen: That increases the UTXO set, the worst kind of abuse.
281 2013-03-06 01:30:51 <gmaxwell> it's a word used in english to refer to people who hord things.
282 2013-03-06 01:30:57 <sipa> ok
283 2013-03-06 01:30:59 <muhoo> hoarders = pack rat
284 2013-03-06 01:31:10 <gmaxwell> gwillen: zero coin outputs are nonstandard too.
285 2013-03-06 01:31:12 <gwillen> sipa: an output of zero coins is nonstandard (and hence non-relayable/non-mineable?)
286 2013-03-06 01:31:15 <gwillen> ahh, *nods*
287 2013-03-06 01:31:24 <gwillen> you could just make it bitdust instead
288 2013-03-06 01:31:26 tyn has quit (Ping timeout: 245 seconds)
289 2013-03-06 01:31:29 <gwillen> and then it would be destroyed in the process
290 2013-03-06 01:31:38 <gmaxwell> indeed, but you can only store 160 bits per txout that way.
291 2013-03-06 01:31:42 <sipa> bitdust isn't destroyed?
292 2013-03-06 01:31:42 <BlueMatt> why is the GetMinFee so uselessly complicated when it is called from exactly 2 places?
293 2013-03-06 01:31:51 osmosis has quit (Quit: Leaving)
294 2013-03-06 01:31:54 <gwillen> sipa: I'm propsing to use the scriptpubkey to store arbitrary data
295 2013-03-06 01:32:01 <gwillen> sipa: thus the corresponding private key will not exist
296 2013-03-06 01:32:01 <petertodd> gmaxwell: Though only recently - I have a well-connected logging node for this stuff that gets dozens of attempts to relay zero-value-out txs every day.
297 2013-03-06 01:32:05 <gwillen> so the output will be destroyed
298 2013-03-06 01:32:09 <sipa> gwillen: that's horrible
299 2013-03-06 01:32:12 <gwillen> :D
300 2013-03-06 01:32:15 <BlueMatt> gwillen: dont ever do that
301 2013-03-06 01:32:15 <gwillen> I'm a horrible person
302 2013-03-06 01:32:17 <sipa> gwillen: it will create an unspendable output
303 2013-03-06 01:32:20 <petertodd> gmaxwell: Actually, I wonder if that's the guy who said he was timestamping...
304 2013-03-06 01:32:27 <sipa> which needs to be retained for eternity
305 2013-03-06 01:32:27 <muhoo> gwillen: oh now this makes sense. that's considered very, very evil.
306 2013-03-06 01:32:33 <sipa> in fast-accessible storage
307 2013-03-06 01:32:35 <gmaxwell> retained in fast memory.
308 2013-03-06 01:32:38 <gmaxwell> Right.
309 2013-03-06 01:32:56 <gwillen> well, if I can think of it, other people can too
310 2013-03-06 01:33:02 <gwillen> so it had better be possible to deal with it
311 2013-03-06 01:33:20 <sipa> we need The Blockchain Busters!
312 2013-03-06 01:33:28 mdszy has joined
313 2013-03-06 01:33:40 <sipa> license to kill -9, rm -rf, ...
314 2013-03-06 01:33:51 <mdszy> is there any sort of API for simply getting a bitcoin exchange rate?
315 2013-03-06 01:33:53 <muhoo> who you gonna call?
316 2013-03-06 01:34:07 <BlueMatt> mdszy: bitcoincharts probably
317 2013-03-06 01:34:15 <gwillen> seriously though, the UTXO set is going to grow without bound
318 2013-03-06 01:34:19 <gwillen> people will lose their keys by accident
319 2013-03-06 01:34:31 <gwillen> or they will do stupid blockchain tricks like I just described
320 2013-03-06 01:34:32 <muhoo> ok i'm pretty convinced that i've found the SD code and this is it: http://code.google.com/r/fireduck-magicpony/source/list
321 2013-03-06 01:34:38 <gmaxwell> gwillen: its bounded in fact, so long as we don't allow zero value outputs (or at least don't let them get spent ever again)
322 2013-03-06 01:34:39 <BlueMatt> gwillen: no, if you lose a key, you also lose coins, so there is a limit there
323 2013-03-06 01:34:47 <gmaxwell> gwillen: the bound is on the order of 44 PB or so.
324 2013-03-06 01:34:57 <gwillen> gmaxwell: is that one UTXO per satoshi?
325 2013-03-06 01:35:02 <gmaxwell> gwillen: yea.
326 2013-03-06 01:35:05 <gwillen> ahahahahaha.
327 2013-03-06 01:35:13 <gmaxwell> but thats pretty horrible.
328 2013-03-06 01:35:20 <gwillen> it is, yes.
329 2013-03-06 01:35:21 Diablo-D3 has quit (Quit: do coders dream of sheep()?)
330 2013-03-06 01:35:28 <gmaxwell> But bounded, none the less.
331 2013-03-06 01:35:32 <gwillen> true.
332 2013-03-06 01:35:44 <gwillen> and it's a much tighter bound than I would have expected.
333 2013-03-06 01:35:58 Diablo-D3 has joined
334 2013-03-06 01:35:58 <gmaxwell> in terms of a more productive conversation...
335 2013-03-06 01:36:01 <gwillen> heh.
336 2013-03-06 01:36:24 <BlueMatt> gwillen: yes, in fact tons of people have thought of the idea, but people havent abused it. Why? Well because its possible to do it properly and doing it either way requires coding ability, so...meh?
337 2013-03-06 01:36:25 <gmaxwell> we've been talking some about enabling people to use the bitcoin p2p network for communication without the data ending up in the blockchain (or esp the UTXO set)
338 2013-03-06 01:36:45 <gwillen> gmaxwell: that would be exciting; although for stuff like timestamping, the permanence is the point
339 2013-03-06 01:37:27 <gmaxwell> gwillen: for _timestamping_ you only need communication to get you to a miner to add you to an external tree. No storage.
340 2013-03-06 01:37:41 <gwillen> well, and you need a miner to agree to do it
341 2013-03-06 01:37:48 <gwillen> whereas abusing the UTXO set you don't
342 2013-03-06 01:37:51 <gwillen> you just need a tx fee
343 2013-03-06 01:37:59 <gmaxwell> gwillen: sure, and why would they not agree to your timestamp but would agree to a txn that cost them more?
344 2013-03-06 01:38:07 <BlueMatt> well, you could just as easily pay a miner the same fee?
345 2013-03-06 01:38:16 <gwillen> right, but there's already a protocol for me to pay them to insert a TX
346 2013-03-06 01:38:19 <gmaxwell> gwillen: no, not juse a fee, but also evading antispamming rule.
347 2013-03-06 01:38:26 <petertodd> gmaxwell: Reminds me, I did the math on a theoretical UTXO set/node processing machine with log2(n) scaling, and it seems that it would need about 70m^2 of surface area, though less if you are more optimal with the distribution of heat radiating surface area...
348 2013-03-06 01:38:44 <petertodd> gmaxwell: 70m^2 for the max UTXO set of course
349 2013-03-06 01:38:56 Mrcheesenips has quit (Ping timeout: 245 seconds)
350 2013-03-06 01:39:05 <gwillen> seriously though, is there a protocol by which, right now, I can pay a miner a fee to include my hash in their aux data?
351 2013-03-06 01:39:21 <BlueMatt> still, it would be cool to have large miners have a "send us arbitrary data for a our merkle merged-mining headers and a small fee" api at miners
352 2013-03-06 01:39:28 <petertodd> gwillen: It's called OpenTimestamps, and I'm running that service right now.
353 2013-03-06 01:39:29 <gmaxwell> gwillen: yes, chronobit. But it's a bit bizarre.
354 2013-03-06 01:39:32 <gwillen> heh
355 2013-03-06 01:39:38 <gwillen> well, bizarre is better than nothing
356 2013-03-06 01:39:50 <gwillen> and it might be less bizarre than my UTXO abuse
357 2013-03-06 01:39:56 hydrogenesis has quit (Quit: Colloquy for iPad - http://colloquy.mobi)
358 2013-03-06 01:40:10 <petertodd> gwillen: https://github.com/opentimestamps/opentimestamps-client <- you need python3, python3-gnupg, and maybe another library or two
359 2013-03-06 01:40:21 <gmaxwell> BlueMatt: the small fee part doesn't avoid the bloat. really the service should be free, provided at no cost by bitcoin because it costs basically nothing to provide and because providing it prevents crapping on perpetual storage for things that don't need it.
360 2013-03-06 01:40:50 <BlueMatt> gmaxwell: well, Im assuming miners are evil, evil people who just do it for the fees
361 2013-03-06 01:40:53 <BlueMatt> gmaxwell: realistically, sure
362 2013-03-06 01:41:07 <gmaxwell> BlueMatt: even if you assume that, they can charge by getwork.
363 2013-03-06 01:41:51 <gwillen> gmaxwell: it looks like with chronobit you still have to allocate an entire merged-mining chainid for each user? That's a bit scary.
364 2013-03-06 01:42:19 <petertodd> gwillen: No you don't
365 2013-03-06 01:42:34 <petertodd> gwillen: You just pick a chainid you aren't using *yourself*
366 2013-03-06 01:42:51 <gwillen> ahhh, I see
367 2013-03-06 01:42:55 <petertodd> gwillen: And anyway, this chainid thing is only because the current merge-mine standard utterly sucks.
368 2013-03-06 01:43:03 <gwillen> heh, *nods*
369 2013-03-06 01:44:06 JZavala has quit (Ping timeout: 276 seconds)
370 2013-03-06 01:46:36 <gmaxwell> One thing that would help any timestamping effort is having a standing user of it. I think a lot of people dork around with it and then it really goes nowhere because it's more novel than useful.
371 2013-03-06 01:46:49 * gwillen nods
372 2013-03-06 01:47:20 <gmaxwell> might be neat if gpg keys got theselves timestamped on creation so that you could tell which of two competing keys was older.
373 2013-03-06 01:47:35 <petertodd> Well, funny that... I'm assuming whoever gave me 5BTC to get my opentimestamps server back up is using it, because I'm suddenly getting a timestamp request a few times an hour.
374 2013-03-06 01:47:49 free__ is now known as welovecp
375 2013-03-06 01:47:59 <muhoo> time is a funny concept.
376 2013-03-06 01:48:04 <petertodd> gmaxwell: Yeah, I timestamped all the dev keys months ago...
377 2013-03-06 01:49:19 <gmaxwell> petertodd: yea, who cares, pointless unless there is a standard for the keys to contain them and clients to actually validate them.
378 2013-03-06 01:49:38 <petertodd> gmaxwell: Of course, but such standards can be made and so on.
379 2013-03-06 01:50:02 <petertodd> gmaxwell: The main thing, is with Bitcoin, such standards actually make sense because you're not forced to trust central timestamping providers and manage that whole layer of complexity.
380 2013-03-06 01:50:14 <muhoo> i just went through this with an embeded product that needed to use SSL. if the clock wasn't set correctly, it thought it was 1970 and all certs were in the future, thus invalid. so we had to add ntps to it, etc. that as a "doh" moment.
381 2013-03-06 01:50:20 <gmaxwell> I'm just saying that unless they get implemented the infrastructure will just rot.
382 2013-03-06 01:50:32 <gwillen> muhoo: then you realized that ntp isn't authenticated
383 2013-03-06 01:50:36 <gwillen> muhoo: and you cried and did it anyway?
384 2013-03-06 01:51:01 <petertodd> gmaxwell: Hey, all that stuff was on my long todo list, and GPG's was one of the first I wanted to tackle.
385 2013-03-06 01:51:09 <petertodd> gmaxwell: Until I got this whole banking bug...
386 2013-03-06 01:51:15 <muhoo> gwillen: exactly. we had to stop somewhere and just say "ok, that's a hole"
387 2013-03-06 01:51:24 <gwillen> muhoo: you don't work on chromeOS, do you
388 2013-03-06 01:51:24 <gmaxwell> petertodd: dunno if you noticed but phantomcircuit and jgarzik have the banking bug too.
389 2013-03-06 01:51:32 <gwillen> muhoo: I heard this story already from a chromeOS dev :-)
390 2013-03-06 01:51:48 Mrcheesenips has joined
391 2013-03-06 01:51:48 Mrcheesenips has quit (Changing host)
392 2013-03-06 01:51:48 Mrcheesenips has joined
393 2013-03-06 01:51:54 <petertodd> gmaxwell: Yeah, it's a project with a much bigger impact.
394 2013-03-06 01:52:18 <gmaxwell> gwillen: doesn't chromos use HTTPS time to set time? .. uh circular problem there!
395 2013-03-06 01:52:24 <gwillen> gmaxwell: yep!
396 2013-03-06 01:52:30 <gmaxwell> (tails does too)
397 2013-03-06 01:52:34 <jgarzik> petertodd: interested in provable banking, and creating incentives for off-chain transactions, where intermediaries/aggregators do not have incentive to cheat
398 2013-03-06 01:52:40 <muhoo> exactly, it was an ourobous loop.
399 2013-03-06 01:52:41 D34TH has quit (Read error: Connection reset by peer)
400 2013-03-06 01:52:52 <DarkGhost`> sipa, even listtransactions doesn't show it, not does getbalance.
401 2013-03-06 01:52:57 <muhoo> time, as i said, is a funny concept. hard to bootstrap securely.
402 2013-03-06 01:53:02 LargoG has joined
403 2013-03-06 01:53:07 <petertodd> jgarzik: same here basically
404 2013-03-06 01:53:19 <petertodd> jgarzik: what's your ideas on making it happen?
405 2013-03-06 01:53:51 <petertodd> muhoo: Secure hardware does it with a clock and a backup battery usually...
406 2013-03-06 01:54:00 <jgarzik> petertodd: I don't pretend to have good answers :) Transparency and proof is easy, anti-cheating is hard
407 2013-03-06 01:54:08 <jgarzik> petertodd: and plain ole failure survival
408 2013-03-06 01:54:11 <petertodd> muhoo: Said hardware dies %100 after the 20 years when the battery dies...
409 2013-03-06 01:54:42 <muhoo> this particular hw doesn't have any battery-backed clock other than the system clock, which shuts off when the system powers down
410 2013-03-06 01:54:57 <petertodd> jgarzik: Yeah, I think we should tackle transparency and proof first, because we're going to find out the situation is harder than we thought...
411 2013-03-06 01:54:59 <jgarzik> petertodd: one easy idea is a distributed set of daemons, who collectively manage a ledger
412 2013-03-06 01:55:20 <gmaxwell> petertodd: You can make anti-cheating at least n of m distributed.
413 2013-03-06 01:55:21 <jgarzik> petertodd: failure or compromise of any 1-2 is survivable, as a goal
414 2013-03-06 01:55:31 <gmaxwell> Though that results in distributed systems problems.
415 2013-03-06 01:56:01 <petertodd> jgarzik: Oh sure, but n-of-m systems frankly don't seem novel to me... I mean, I've always assumed fidelity bonded bank backends would do that stuff purely as a way to be more reliable.
416 2013-03-06 01:56:09 clav8 has joined
417 2013-03-06 01:56:24 da2ce7_d has quit (Read error: Connection reset by peer)
418 2013-03-06 01:56:31 <gmaxwell> they's at level of anti-cheating that doesn't exist in existing bitcoin banklike services, however. Sad as that is.
419 2013-03-06 01:56:46 <jgarzik> petertodd: mainly curious about bank-like stuff, as it intersects with bots: http://garzikrants.blogspot.com/2013/01/storj-and-bitcoin-autonomous-agents.html
420 2013-03-06 01:56:52 <gmaxwell> s/they's at/they are a/
421 2013-03-06 01:57:01 clav8 has quit (Client Quit)
422 2013-03-06 01:57:18 <petertodd> jgarzik: Yeah, I read that awhile back, nice concept.
423 2013-03-06 01:57:39 clav8 has joined
424 2013-03-06 01:58:58 <gmaxwell> I would say a good development path is (1) non-fractional-reserve-proofs, then (2) n of m for anti-cheating and security, then (3) trusted hardware for security and anti-cheating, then (4) fidelity bonds or other mechenisms for anti-cheating.
425 2013-03-06 02:00:55 <petertodd> It'd say n of m is a backend thing, orthogonal to the overall idea. But otherwise I agree with the order.
426 2013-03-06 02:01:31 <petertodd> Maybe even trusted hardware first, just because it'll get stuff out in the open that won't be as badly hacked, but upgrading would be tough.
427 2013-03-06 02:01:38 <petertodd> We could destroy a lot of confidence early on...
428 2013-03-06 02:03:08 torsthaldo has quit (Read error: Connection reset by peer)
429 2013-03-06 02:05:53 ahbritto has quit (Ping timeout: 250 seconds)
430 2013-03-06 02:06:04 ahbritto__ has quit (Ping timeout: 256 seconds)
431 2013-03-06 02:06:36 ahbritto__ has joined
432 2013-03-06 02:06:41 ahbritto has joined
433 2013-03-06 02:07:58 gritcoin has joined
434 2013-03-06 02:11:28 <ProfMac> network time protocol (ntp) seems like a really good match to bitcoin.
435 2013-03-06 02:11:40 <gmaxwell> ProfMac: uh? why do you say that?
436 2013-03-06 02:12:28 <gmaxwell> petertodd: it's not really an orthogonal thingâ n of m is one way to gain pratical confidence that theft won't happen. It makes it objectively harder for a hacker to hack, and it increases the cost of cheating. (e.g. N people's reputation lost)
437 2013-03-06 02:13:47 <ProfMac> it sends time in a series of messages between servers. bitcoin is already doing that. ntp is hierarchical, respecting UTC and central authorities, but it does already have encryption and antispoofing code inside it. It also provides for any station to have a GPS input.
438 2013-03-06 02:14:53 <gmaxwell> ProfMac: GPS is a centerally controlled authority. NTP servers have no way to prove that they are obeying it.
439 2013-03-06 02:15:04 <gmaxwell> Bitcoin has no encryption, doesn't need any.
440 2013-03-06 02:15:19 <gmaxwell> NTP isn't secure against malicious servers even with it.
441 2013-03-06 02:15:44 <warren> GPS is vulnerable too
442 2013-03-06 02:16:03 <jgarzik> bbiab, baby bedtime
443 2013-03-06 02:16:54 <gmaxwell> warren: thats redundant with saying its centrally controlled.
444 2013-03-06 02:17:08 da2ce7 has joined
445 2013-03-06 02:17:13 <Luke-Jr> we should rework Bitcoin to use tonal time
446 2013-03-06 02:17:15 * Luke-Jr ducks
447 2013-03-06 02:17:37 <gmaxwell> Luke-Jr: doesn't it already? :P SI second? you can print the number in whatever base you want.
448 2013-03-06 02:17:53 <Luke-Jr> gmaxwell: SI seconds are not tonal units :P
449 2013-03-06 02:18:05 <gmaxwell> what is the tonal second then?
450 2013-03-06 02:18:10 <Luke-Jr> the timmill is about 1.3 seconds long
451 2013-03-06 02:18:34 <Luke-Jr> 86400/0x10000
452 2013-03-06 02:18:51 <gwillen> the real question is
453 2013-03-06 02:18:53 <gwillen> why would anybody care
454 2013-03-06 02:19:20 <warren> gmaxwell: not exactly, it's also vulnerable to parties who aren't the central authority
455 2013-03-06 02:19:44 <gmaxwell> warren: yes, sure. but that isn't what you said. :P
456 2013-03-06 02:19:55 <warren> ok
457 2013-03-06 02:20:13 <ProfMac> Universal Coordinated Time (UTC) is a centrally coordinated entity.
458 2013-03-06 02:20:57 mixer_mad has quit (Quit: Lost terminal)
459 2013-03-06 02:20:57 <gmaxwell> ProfMac: with the right hardware you can track TAI on your own... though UTC needs the leapseconds which are set by non-reproducable methods.
460 2013-03-06 02:21:08 <gritcoin> UTC isn't particularly susceptible to attack because it isn't a realtime product. It is produced weeks to month after the fact.
461 2013-03-06 02:21:16 <gritcoin> And GPS doesn't run on UTC (or UT-anything)
462 2013-03-06 02:21:32 <gmaxwell> it runs on GPS time, but transmits the utc correction.
463 2013-03-06 02:21:48 <gritcoin> It transmits an approximation to the correction
464 2013-03-06 02:21:56 <gmaxwell> I wrote up a fun example of how to make decenteralized time: http://people.xiph.org/~greg/decentralized-time.txt
465 2013-03-06 02:22:26 <gmaxwell> (it's mostly sillyness, but perhaps seeing it helps people realize current time is centralized.
466 2013-03-06 02:22:30 <gmaxwell> )
467 2013-03-06 02:23:23 <ProfMac> is there anyone who doesn't think that time is centralized?
468 2013-03-06 02:23:31 <Luke-Jr> gmaxwell: couldn't block height itself be a decentralized time metric?
469 2013-03-06 02:24:31 <gmaxwell> ProfMac: you said ntp was "a really good match to bitcoin"
470 2013-03-06 02:24:45 <gmaxwell> Luke-Jr: yup.. though maybe not the most human friendly.
471 2013-03-06 02:24:48 <gritcoin> neither utc nor gps time can be fiddled with without someone noticing, because we have external references to compare to that can't be altered
472 2013-03-06 02:25:26 <gmaxwell> gritcoin: uh. gps can be locally spoofed quite easily... and if you're getting it from an ntp server you have no evidence at all that it isn't pure fantasy.
473 2013-03-06 02:25:48 <gritcoin> yes, but that's not gps time or utc time. That's random ntp server time.
474 2013-03-06 02:26:00 <warren> US military learned about local spoofing the hard way, apparently.
475 2013-03-06 02:26:04 LargoG has quit (Remote host closed the connection)
476 2013-03-06 02:26:04 <gmaxwell> gritcoin: The first half of my sentence is.
477 2013-03-06 02:26:33 <gritcoin> And receivers with the right techniques can trivially spot spoofing, through deep inertial integration
478 2013-03-06 02:26:38 LargoG has joined
479 2013-03-06 02:27:13 <gritcoin> receivers that know their own time source error budget and their inertial reference error budget can spot alterations in gps signal of less than 1cm/s
480 2013-03-06 02:27:44 <ProfMac> gmaxwell, I like the use of correlation on RF noise from the sun.
481 2013-03-06 02:28:27 <gmaxwell> gritcoin: lol not without L2 and Y code.
482 2013-03-06 02:28:32 <gritcoin> False
483 2013-03-06 02:28:40 <gritcoin> it is trivial with an l1 only receiver
484 2013-03-06 02:28:53 <gritcoin> Y code is irrelevant for block IIF and forward
485 2013-03-06 02:29:04 <gmaxwell> gritcoin: provide links. because you don't even get positional accuracy that good with plain l1 c/a without a phase reference.
486 2013-03-06 02:29:55 <gmaxwell> I'm not saying you're full of it, but I don't see how and I'd like to learn.
487 2013-03-06 02:30:19 <gritcoin> Not absolute positional accuracy. But with inertial integration in the navigation filter, even a l1 only receiver can distinguish between external error and movement.
488 2013-03-06 02:30:32 <gritcoin> Not taken that way at all.
489 2013-03-06 02:30:54 <gmaxwell> great, but I can slew your time as much as I like by doing it slowly without making it seem like you're moving much.
490 2013-03-06 02:30:54 <gritcoin> It is extensions of TRAIM techniques
491 2013-03-06 02:31:13 <gmaxwell> er not-moving-much.
492 2013-03-06 02:31:17 <gritcoin> right, but you need hundreds of feet to get 100s of nanoseconds
493 2013-03-06 02:32:16 <gritcoin> Also can be detected through real time exchange of phase information with a non-local station
494 2013-03-06 02:33:01 <gritcoin> And receivers with wide front ends and sophisticated anti-jamming can do way better than the stuff that's been spoofed on drones.
495 2013-03-06 02:33:58 <gritcoin> This is ignoring phased array antennas which if rotated while operating can definitively fix the source of a correlation peak to within a few degrees and compare to known position of satellites
496 2013-03-06 02:34:21 <gmaxwell> I think I'd be willing to bet that I can just replace the constellation, provide accurate positioning, and then just send a UTC difference value of years off and anything commercially produced will believe it, even if actually does something smart if the inertial filtering says its lost its mind.
497 2013-03-06 02:34:54 <gritcoin> I would say read Inside GNSS's monthly technical primers for a good slow survey of what people are doing.
498 2013-03-06 02:35:15 Toresh_ has joined
499 2013-03-06 02:35:26 <gritcoin> Yeah, a lot of receivers would fail that way, for sure
500 2013-03-06 02:35:42 <gmaxwell> Certantly anything low cost consumer off the shelf is not doing synthetic aperture to fix the birds positions in the sky. :P
501 2013-03-06 02:35:50 <gritcoin> And many of the receivers that are ntp stratum 0 fall into that category.
502 2013-03-06 02:36:29 mappum has joined
503 2013-03-06 02:36:32 <gritcoin> No, although they (low cost consumer chipsets) do exist that compare CDMA and GPS timing and use CDMA directly for ranging
504 2013-03-06 02:36:50 <gritcoin> And the cdma side is much harder to spoof
505 2013-03-06 02:37:21 <gmaxwell> yea, though the CDMA basestations are just more GPSDOs. (I know, I got my collection of GPSDOs from a CDMA network upgrade!)
506 2013-03-06 02:37:35 <gritcoin> But yeah, I totally agree with you that a dedicated attacker could locally deny the availability of accurate GPS time
507 2013-03-06 02:37:44 <gritcoin> for most end users
508 2013-03-06 02:37:58 Toresh has quit (Ping timeout: 260 seconds)
509 2013-03-06 02:37:58 Toresh_ is now known as Toresh
510 2013-03-06 02:38:39 PhantomSpark has joined
511 2013-03-06 02:38:47 <gmaxwell> gritcoin: really my bigger argument was that it's ultimately a centrally controlled system. One of the more trustworthy ones no doubt, but that does make it philosophically unlike Bitcoin.
512 2013-03-06 02:38:48 <gritcoin> If you want to implement most of the inertial based techniques unfortunately just the code and carrier phase data that some receivers spit out isn't sufficient; you need access to knobs and values that are internal to the correlators
513 2013-03-06 02:38:53 grau has quit (Remote host closed the connection)
514 2013-03-06 02:38:58 <gritcoin> Yah, we're waaay OT
515 2013-03-06 02:39:22 <gmaxwell> gritcoin: yea, there are neat things people are doing with gnuradio and such where they have the correlator in 'software'.
516 2013-03-06 02:39:26 <gmaxwell> And indeed. :P
517 2013-03-06 02:40:39 B0g4r7 has quit (Ping timeout: 276 seconds)
518 2013-03-06 02:42:33 <gritcoin> As a pointer for the literature, DPE (direct position estimation) work deals with bayesian inference based all observables available -- time and position certification with confidence levels has been demonstrated in that area. And that's a wrap :)
519 2013-03-06 02:43:01 <gmaxwell> 18:27 < ProfMac> gmaxwell, I like the use of correlation on RF noise from the sun.
520 2013-03-06 02:43:47 <gmaxwell> I felt particularly clever for that one, but I wouldn't be surprised if it were totally impractical for boring engineering reasons.
521 2013-03-06 02:44:21 <gmaxwell> Mostly it was just fun calling the sun "attack resistant"
522 2013-03-06 02:44:46 <gritcoin> we hope it is :)
523 2013-03-06 02:45:40 <gmaxwell> its like a lot of things in cryptography, often at best we hope to reduce things to "if this doesn't hold then you have much bigger problems"
524 2013-03-06 02:48:53 <Luke-Jr> the sun might suddenly explode and consume the Earth in exactly 3 minutes 21 seconds!
525 2013-03-06 02:49:07 <Luke-Jr> ^ more likely than breaking Bitcoin :P
526 2013-03-06 02:49:29 B0g4r7 has joined
527 2013-03-06 02:49:35 a5m0 has quit (Quit: No Ping reply in 180 seconds.)
528 2013-03-06 02:49:42 TheSeven has quit (Read error: Connection reset by peer)
529 2013-03-06 02:49:42 <Luke-Jr> (in theory at least)
530 2013-03-06 02:49:51 a5m0 has joined
531 2013-03-06 02:49:51 a5m0 has quit (Changing host)
532 2013-03-06 02:49:51 a5m0 has joined
533 2013-03-06 02:50:20 TheSeven has joined
534 2013-03-06 02:50:49 <gmaxwell> don't be too confident, the sun has been failing to explode and consume the earth for 4 billion years. Bitcoin has a little way to go just for pure maturity. :P
535 2013-03-06 02:51:42 LargoG has quit (Ping timeout: 276 seconds)
536 2013-03-06 02:52:06 LargoG has joined
537 2013-03-06 02:54:52 andytoshi has joined
538 2013-03-06 02:58:48 <etotheipi_> did testnet change again ,with 0.8?
539 2013-03-06 03:00:29 <jaakkos> have you considered a plan for a scenario that, in the future, one way or another, the developers of major clients are persecuted or otherwise targetted?
540 2013-03-06 03:00:52 <andytoshi> jaakkos: github will still be there
541 2013-03-06 03:00:54 tyn has joined
542 2013-03-06 03:01:18 <andytoshi> there would be a lot of scrutiny on their patches, and if anything funny happened, there'd be a fork
543 2013-03-06 03:01:53 <jaakkos> if the project goes uncoordinated for an extended period of, it might have some consequences...
544 2013-03-06 03:01:59 <jaakkos> +time
545 2013-03-06 03:02:25 <andytoshi> i think armory is well-positioned to take over then ;)
546 2013-03-06 03:02:55 <gmaxwell> etotheipi_: no.
547 2013-03-06 03:03:01 <andytoshi> haha
548 2013-03-06 03:03:05 BTCTrader2 has quit (Ping timeout: 250 seconds)
549 2013-03-06 03:03:17 <etotheipi_> andytoshi: I think so too
550 2013-03-06 03:03:51 <gmaxwell> etotheipi_: uh. Since when is armor a network node? And since when are you going to go all rambo into maintaining development when other people are sitting in jail? :P
551 2013-03-06 03:04:40 <etotheipi_> it's not a network node, but when bitcoin-qt/bitcoind is hidden in the background, it looks like it's legit
552 2013-03-06 03:05:22 <gmaxwell> I suspect there has been a conversational convergence failure.
553 2013-03-06 03:05:48 <Luke-Jr> lol
554 2013-03-06 03:06:05 <etotheipi_> I haven't been paying attention to the conversation
555 2013-03-06 03:06:24 hydrogenesis has joined
556 2013-03-06 03:07:11 Shealan has quit (Quit: Leaving.)
557 2013-03-06 03:07:53 <gmaxwell> https://en.bitcoin.it/w/index.php?title=Running_Bitcoin&diff=32218&oldid=32217
558 2013-03-06 03:07:57 <gmaxwell> :-/
559 2013-03-06 03:08:02 <gmaxwell> Any idea why he made that edit?
560 2013-03-06 03:08:50 freakazoid_ has quit (Ping timeout: 245 seconds)
561 2013-03-06 03:09:45 defunctzombie_zz is now known as defunctzombie
562 2013-03-06 03:09:54 <andytoshi> who is that?
563 2013-03-06 03:09:54 LargoG has quit (Ping timeout: 276 seconds)
564 2013-03-06 03:10:12 LargoG has joined
565 2013-03-06 03:10:17 <Luke-Jr> gmaxwell: maybe confusion over the change to -foo=0 ?
566 2013-03-06 03:10:23 <gmaxwell> MagicalTux: Think we could get you to set a $wgRC2UDPAddress / $wgRC2UDPPort on en.bitcoin.it to some host of mine so I could run a bot to tell us when these pages change?
567 2013-03-06 03:10:28 Goonie has quit (Ping timeout: 248 seconds)
568 2013-03-06 03:10:32 <gmaxwell> Luke-Jr: but -daemon?
569 2013-03-06 03:10:49 <Luke-Jr> gmaxwell: -daemon is deprecated for -Qt I think?
570 2013-03-06 03:10:59 paraipan has quit (Remote host closed the connection)
571 2013-03-06 03:11:25 <gmaxwell> Luke-Jr: ah, I never knew that daemon worked at all for -qt.
572 2013-03-06 03:11:33 <Luke-Jr> gmaxwell: it didn't, but it did for wx
573 2013-03-06 03:14:21 <gmaxwell> I think what he did was run -qt and added everything that didn't show up.
574 2013-03-06 03:14:50 <Luke-Jr> plausable
575 2013-03-06 03:14:52 <Luke-Jr> sgornick: poke
576 2013-03-06 03:17:09 <jgarzik> huh
577 2013-03-06 03:17:16 <jgarzik> Did blockchain.info cancel their mixing service?
578 2013-03-06 03:17:45 <gmaxwell> vanished it, in fact.
579 2013-03-06 03:17:54 <jaakkos> :o
580 2013-03-06 03:18:15 <jaakkos> where do i launder my money now...
581 2013-03-06 03:18:33 <gmaxwell> increased my estimation of their odds of continued survival at least.
582 2013-03-06 03:18:47 hsmiths has joined
583 2013-03-06 03:20:03 BTCTrader2 has joined
584 2013-03-06 03:20:25 <petertodd> jaakkos: petermix
585 2013-03-06 03:21:34 andytoshi has quit (Remote host closed the connection)
586 2013-03-06 03:21:41 <jgarzik> 2013-03-06 03:20:56 ignoring large orphan tx (size: 37478, hash: 108b92aaf2)
587 2013-03-06 03:21:42 <petertodd> gmaxwell: Ah, I didn't realize you really meant that the n servers would be totally separately controlled; that's different.
588 2013-03-06 03:22:19 <gmaxwell> petertodd: yes! with the funds also in n of m p2sh.
589 2013-03-06 03:22:22 Lannoc has quit ()
590 2013-03-06 03:22:29 midnightmagic has quit (Ping timeout: 246 seconds)
591 2013-03-06 03:22:43 <DarkGhost`> I sent a payment to an address on my server, bitcoind, it still hasn't showed in listtransactions or getbalance
592 2013-03-06 03:22:43 andytoshi has joined
593 2013-03-06 03:22:45 <DarkGhost`> been about 3 hrs
594 2013-03-06 03:22:51 midnightmagic has joined
595 2013-03-06 03:23:12 <DarkGhost`> is it because i'm using addnode to some relay thing?
596 2013-03-06 03:23:25 <DarkGhost`> and should I run -rescan?
597 2013-03-06 03:23:44 <freewil> DarkGhost`, see if the transaction is on blockchain.info
598 2013-03-06 03:23:53 <DarkGhost`> it is.
599 2013-03-06 03:24:05 <freewil> does it have any confirmations yet?
600 2013-03-06 03:24:22 <gmaxwell> DarkGhost`: -rescan does nothing useful but waste your time, unless you've been editing your wallet with pywallet or something.
601 2013-03-06 03:25:01 <freewil> if blockchain.info knows about it then the majority of the network probably does too, it just hasn't made it into a block yet
602 2013-03-06 03:25:19 <DarkGhost`> well how do I make this happen quicker
603 2013-03-06 03:25:24 <freewil> be patient
604 2013-03-06 03:25:29 <DarkGhost`> I can't wait 3 hours to know if a transaction has made it to my wallet yet
605 2013-03-06 03:25:30 mappum has quit (Ping timeout: 276 seconds)
606 2013-03-06 03:25:48 <petertodd> gmaxwell: Although, you do have the problem that the supposedly separately controlled individuals can collaborate... (I've always assumed n of m funds, just good redundency practice)
607 2013-03-06 03:26:09 LargoG has quit (Ping timeout: 276 seconds)
608 2013-03-06 03:26:10 <petertodd> gmaxwell: Really important with trusted hardware too, as if the hardware fails you're screwed.
609 2013-03-06 03:27:04 FredEE has quit (Quit: FredEE)
610 2013-03-06 03:28:08 <DarkGhost`> freewil it has no transactions.
611 2013-03-06 03:28:11 FredEE has joined
612 2013-03-06 03:28:26 <doublec> DarkGhost`: does it have any confirmations?
613 2013-03-06 03:28:34 <doublec> DarkGhost`: (according to blockchain.info?)
614 2013-03-06 03:28:52 <DarkGhost`> no.
615 2013-03-06 03:28:59 <DarkGhost`> it was sent a long time ago though
616 2013-03-06 03:29:38 <doublec> DarkGhost`: do the transaction inputs depend on any other unconfirmed transactions?
617 2013-03-06 03:29:49 <doublec> DarkGhost`: and does the transaction include a fee?
618 2013-03-06 03:30:05 <DarkGhost`> https://blockchain.info/address/1LUey8iwSEK4gxeGutUuQbHCdkcAvs4vQR I'm, not sure?
619 2013-03-06 03:30:35 <gmaxwell> petertodd: thats true, but it still gets you a larger reputational hit. And a conspiracy is less likely that a single party defect. Plus it's protection for the operator, less gun-to-the-head risk when you don't hold the keys alone.
620 2013-03-06 03:31:26 <petertodd> gmaxwell: In any case, the actual tech required to do that is probably mostly the same needed for n-of-m redundency, so doing it is a no-brainer.
621 2013-03-06 03:31:27 <doublec> DarkGhost`: no fee plus really tiny amount probably means low priority
622 2013-03-06 03:31:51 <DarkGhost`> where do you see no fee? just curious?
623 2013-03-06 03:33:51 <doublec> DarkGhost`: see "fees" here: https://blockchain.info/tx/545b987b438518062f8c630eddb26520f4a6d27f92323405b84f5b04061fee31?show_adv=true
624 2013-03-06 03:33:58 fiesh has quit (Ping timeout: 252 seconds)
625 2013-03-06 03:34:33 zooko` has joined
626 2013-03-06 03:34:45 JStoker has quit (Excess Flood)
627 2013-03-06 03:35:31 <DarkGhost`> doublec, thank you, a few more questions. when using bitcoind, and I do getaccountaddress, will it always make a new one? how do I keep it so theirs one address for that account? and how do I send bitcoins from bitcond without a fee?
628 2013-03-06 03:35:33 ahbritto has quit (Read error: Connection reset by peer)
629 2013-03-06 03:35:34 andytoshi has quit (Quit: WeeChat 0.4.0)
630 2013-03-06 03:36:29 ahbritto__ has quit (Read error: Connection reset by peer)
631 2013-03-06 03:36:50 FredEE has quit (Quit: FredEE)
632 2013-03-06 03:37:08 fiesh has joined
633 2013-03-06 03:37:10 <doublec> DarkGhost`: getaccountaddress returns the same address for that account on each invocation until the address receives something. Then it'll return a new address.
634 2013-03-06 03:37:27 <DarkGhost`> gotcha, so if the address is used it creates new?
635 2013-03-06 03:37:31 <doublec> yes
636 2013-03-06 03:37:35 <DarkGhost`> so for example, that address in blockchain will be gone
637 2013-03-06 03:37:37 <DarkGhost`> because its used?
638 2013-03-06 03:37:56 <doublec> no you can still receive to that address. You just won't get that returned by getaccountaddress anymore
639 2013-03-06 03:38:07 FredEE has joined
640 2013-03-06 03:38:07 <DarkGhost`> what would I do to receive that address
641 2013-03-06 03:38:19 <doublec> I'm not sure I understand the question
642 2013-03-06 03:38:30 <DarkGhost`> what command would I use for bitcoind to get that same address used above
643 2013-03-06 03:38:57 tyn has quit (Ping timeout: 245 seconds)
644 2013-03-06 03:39:02 <DarkGhost`> if getaccountaddress returns a new one, how would I get old one?
645 2013-03-06 03:39:11 <doublec> you'd remember it :)
646 2013-03-06 03:39:15 <DarkGhost`> okay.
647 2013-03-06 03:39:16 <DarkGhost`> makes sense
648 2013-03-06 03:39:31 <DarkGhost`> and what about sending a small amount bitcoinwithout a fee
649 2013-03-06 03:39:35 <DarkGhost`> like .001 through bitcoind?
650 2013-03-06 03:39:42 <doublec> I don't know if you can
651 2013-03-06 03:40:01 <DarkGhost`> why not
652 2013-03-06 03:40:25 <gmaxwell> it won't relay it, it won't mine it.
653 2013-03-06 03:40:43 <gmaxwell> this prevents people from DOS attacking bitcoin ('penny flood')
654 2013-03-06 03:40:51 <doublec> if it did let you,you'd end up with stuck transactions like your current non-confirming one
655 2013-03-06 03:40:52 <DarkGhost`> well how was that .0006 sent then
656 2013-03-06 03:41:03 <DarkGhost`> through blockchain wallet
657 2013-03-06 03:41:25 <doublec> they either don't use bitcoind, or they use a modified one, or they used low level transaction creation api's
658 2013-03-06 03:41:27 <gmaxwell> DarkGhost`: they have agreements with miners to include their non-standard txn.
659 2013-03-06 03:41:42 <gmaxwell> and they also don't use bitcoind.
660 2013-03-06 03:42:00 <DarkGhost`> hmm
661 2013-03-06 03:42:07 <DarkGhost`> so If I want to do this Is houldn't use bitcoind?
662 2013-03-06 03:42:19 <gmaxwell> not using bitcoind is not sufficient.
663 2013-03-06 03:42:27 <gmaxwell> DarkGhost`: what are you trying to do?
664 2013-03-06 03:42:34 <DarkGhost`> send small amounts of bitcoins
665 2013-03-06 03:42:40 <Luke-Jr> gmaxwell: he's trying to flood without fees
666 2013-03-06 03:42:44 <gmaxwell> Well, you can't not without paying fees.
667 2013-03-06 03:42:46 <Luke-Jr> been at it for a few days now
668 2013-03-06 03:42:59 <gmaxwell> The software is specifically setup to prevet this. Your peers prevent this, etc.
669 2013-03-06 03:43:13 <gmaxwell> Changing what you run doesn't change what everyone else runs.
670 2013-03-06 03:43:17 <jgarzik> 2013-03-06 03:43:00 ignoring large orphan tx (size: 11475, hash: 9cd8cd1c3a)
671 2013-03-06 03:43:40 <DarkGhost`> so you're saying I won't receive https://blockchain.info/tx/545b987b438518062f8c630eddb26520f4a6d27f92323405b84f5b04061fee31 this?
672 2013-03-06 03:44:04 <Luke-Jr> DarkGhost`: probably not any time soon, unless MtGox sent it
673 2013-03-06 03:44:20 <gmaxwell> " ssl_error_handshake_unexpected_alert"
674 2013-03-06 03:45:07 <DarkGhost`> so lets say I was accepting bitcoins for something, and I accept even small amounts such as .0006, would it be smart to use blockchain instead of waiting for it to enter my wallet?
675 2013-03-06 03:45:27 vigilyn2 has joined
676 2013-03-06 03:45:33 <Luke-Jr> DarkGhost`: no, it'd be smart to use MtGox
677 2013-03-06 03:45:34 vigilyn has quit (Read error: Connection reset by peer)
678 2013-03-06 03:45:39 <DarkGhost`> mtgox api?
679 2013-03-06 03:45:41 <Luke-Jr> yes
680 2013-03-06 03:45:45 <gmaxwell> it would probably be smartest to use a shared wallet, so that the problematic small inputs are someone elses problem.
681 2013-03-06 03:45:45 <Luke-Jr> they have a merchant solution
682 2013-03-06 03:46:05 <Luke-Jr> and MtGox even lets you get instant confirms within their system
683 2013-03-06 03:46:28 <gmaxwell> And keeps internal to gox transactions off the chain as a bonus.
684 2013-03-06 03:46:42 gritcoin has quit (Quit: gritcoin)
685 2013-03-06 03:46:51 <DarkGhost`> can I create seperate addresses for accounts like bitcoind with
686 2013-03-06 03:46:52 <DarkGhost`> mtgox?
687 2013-03-06 03:46:57 <Luke-Jr> yes
688 2013-03-06 03:47:05 <Luke-Jr> it always does
689 2013-03-06 03:47:08 <DarkGhost`> hmm
690 2013-03-06 03:47:14 <DarkGhost`> why doesnt SD use this?
691 2013-03-06 03:47:25 <DarkGhost`> why didn't you suggest this earlier Luke-Jr?~
692 2013-03-06 03:47:25 <Luke-Jr> because SD is hostile to Bitcoin
693 2013-03-06 03:47:36 <Luke-Jr> DarkGhost`: you were asking different questions ;)
694 2013-03-06 03:47:48 <Luke-Jr> receiving small payments means you control the destination
695 2013-03-06 03:47:51 <Luke-Jr> sending, not so much
696 2013-03-06 03:48:01 <DarkGhost`> so to accept small amounts/any amounts, and send back small/any amounts i should use mt gox api
697 2013-03-06 03:48:44 <Luke-Jr> DarkGhost`: pretty much IMO
698 2013-03-06 03:49:03 <Luke-Jr> MagicalTux: you have any policy on this kind of thing?
699 2013-03-06 03:49:08 <gmaxwell> DarkGhost`: I still don't know what you're doing, it may be silly no matter how you do it.
700 2013-03-06 03:50:38 <DarkGhost`> mtgox api, does that mean the other party on the end has to have mtgox also?
701 2013-03-06 03:51:12 owowo has quit (Quit: sayonara)
702 2013-03-06 03:52:16 <Luke-Jr> DarkGhost`: in this case, they're better off using MtGox, but can use anything
703 2013-03-06 03:52:35 <Luke-Jr> gmaxwell: wow, valgrind lets you attach a gdb and dump leaks without quitting the program!
704 2013-03-06 03:52:43 <DarkGhost`> okay.
705 2013-03-06 03:52:46 JStoker has joined
706 2013-03-06 03:52:51 <DarkGhost`> mtgox -> bitcoind will work?
707 2013-03-06 03:53:02 <DarkGhost`> thank you btw for the help
708 2013-03-06 03:53:08 <Luke-Jr> DarkGhost`: yes
709 2013-03-06 03:53:13 <DarkGhost`> thanks Luke-Jr
710 2013-03-06 03:53:32 <Luke-Jr> DarkGhost`: I expect if you send a lot of small transactions to bitcoind from MtGox, they will block you eventually tho
711 2013-03-06 03:53:47 <Luke-Jr> assuming they even allow that
712 2013-03-06 03:53:56 <Luke-Jr> might be a minimum send amount
713 2013-03-06 03:54:02 <gmaxwell> looking at the logs...
714 2013-03-06 03:54:03 <gmaxwell> 00:25 < DarkGhost`> they still send you back like .000001 so you know that you lost
715 2013-03-06 03:54:09 <gmaxwell> Yes, and they pay a fee on that transaction.
716 2013-03-06 03:54:26 <DarkGhost`> so there relaly paying .000501 to show you that you lost?
717 2013-03-06 03:54:28 <gmaxwell> (or really, the player pays it but there you go)
718 2013-03-06 03:54:46 <Luke-Jr> DarkGhost`: yes
719 2013-03-06 03:54:53 <gmaxwell> DarkGhost`: its comes out of the player's bet. But yes. They are.
720 2013-03-06 03:54:58 <Luke-Jr> gmaxwell: I wonder how bitcoind would react if they sent a 0 BTC output back
721 2013-03-06 03:55:01 <gmaxwell> actually more than 0.0005 in fact.
722 2013-03-06 03:55:09 <DarkGhost`> why more than .0005?
723 2013-03-06 03:55:15 <gmaxwell> Luke-Jr: non-standard.
724 2013-03-06 03:55:27 <Luke-Jr> gmaxwell: since when? O.o
725 2013-03-06 03:55:32 <gmaxwell> DarkGhost`: because they apparently want priority over other transactions in getting that transaction mined.
726 2013-03-06 03:55:44 <gmaxwell> Luke-Jr: 0.7 â 0 value txouts are nonstandard for obvious reasons.
727 2013-03-06 03:55:57 <DarkGhost`> https://blockchain.info/address/1LUey8iwSEK4gxeGutUuQbHCdkcAvs4vQR if i do bitcoind getblock that hash right there
728 2013-03-06 03:55:59 <DarkGhost`> would it get it faster?
729 2013-03-06 03:56:03 <Luke-Jr> gmaxwell: can we make 0.00000001 BTC non-standard too? :P
730 2013-03-06 03:56:09 <gmaxwell> Luke-Jr: it is on my nodes.
731 2013-03-06 03:57:25 <gmaxwell> Luke-Jr: What I'd like to do is have miners decline to mine any txn that creates a txout which wouldn't be rational to spend: The size of including it would imply more fees than the return on the output.
732 2013-03-06 03:57:59 <jgarzik> I think there was consensus on making 0.00000001 BTC non-standard
733 2013-03-06 03:58:13 <jgarzik> though it should be an easily accessible "less than X" knob
734 2013-03-06 03:58:33 <gmaxwell> hm. Thats a thought.
735 2013-03-06 03:58:42 <Luke-Jr> jgarzik: keep in mind, non-standard also means non-receivable
736 2013-03-06 03:58:48 <gmaxwell> though it's kinda cruddy that you don't know what your peers policy is.
737 2013-03-06 04:00:17 <Luke-Jr> who is Trace Mayer? O.o
738 2013-03-06 04:00:21 mappum has joined
739 2013-03-06 04:00:30 rbecker is now known as RBecker
740 2013-03-06 04:00:32 <gmaxwell> hm?
741 2013-03-06 04:02:01 RBecker is now known as rbecker
742 2013-03-06 04:02:10 <DarkGhost`> would it be bad to addnodfe
743 2013-03-06 04:02:11 <DarkGhost`> addnode
744 2013-03-06 04:02:14 <DarkGhost`> all of the ones blockchain has?
745 2013-03-06 04:02:31 <DarkGhost`> what exactly woudl that do
746 2013-03-06 04:02:50 <gmaxwell> Are you just saying stuff to try to irritate people here?
747 2013-03-06 04:02:53 gritcoin has joined
748 2013-03-06 04:02:59 <DarkGhost`> lmao, I'm just trying to get a grasp for this
749 2013-03-06 04:03:04 <DarkGhost`> i'm sorry.
750 2013-03-06 04:03:21 <DarkGhost`> what would that do?
751 2013-03-06 04:03:47 <gmaxwell> Nothing but waste resources for you and the people you're connecting to.
752 2013-03-06 04:04:03 bitit has joined
753 2013-03-06 04:04:45 <DarkGhost`> I think Luke-Jr sent me a link the other day, is htere something I can read up on that explains nodes and etc so I don't have to ask stupid questions?
754 2013-03-06 04:05:11 kipp has quit (Ping timeout: 246 seconds)
755 2013-03-06 04:05:26 kipp_ has joined
756 2013-03-06 04:05:28 kipp_ is now known as kipp
757 2013-03-06 04:07:37 gritcoin has quit (Client Quit)
758 2013-03-06 04:09:24 <doublec> You're asking the questions the wrong way. Better to say "I want to do X, how do I do that" where X is some higher level task rather than "What would happen if I did Y" where Y is a low level task you think might be needed for X.
759 2013-03-06 04:09:47 <gmaxwell> hm. interesting. so.. random recent block on my node is 152021 in size and collected .2588 in fees. so that means an average of .0003098361410508 BTC/byte in fees. An additional txin adds, say, 182 bytes to a transaction... suggests that txouts far under .0003 are not viable.
760 2013-03-06 04:10:55 <gmaxwell> doublec: but how does that help me find out where I can get lederhosen for an alpaca???
761 2013-03-06 04:11:50 <PRab> Is there a way to know what the priority of a transaction was when it got included in a block?
762 2013-03-06 04:13:16 <doublec> hehe
763 2013-03-06 04:13:33 <gmaxwell> PRab: yes, apply the priority formula with the ages computed as of the block.
764 2013-03-06 04:14:39 <PRab> Is there an api to get the rough data that I would need? Or will I have to mess around in the Raw Transactions API a bunch?
765 2013-03-06 04:15:04 zooko` has quit (Ping timeout: 245 seconds)
766 2013-03-06 04:16:34 <PRab> I don't mind data munging, but parsing the entire blockchain seems tedious.
767 2013-03-06 04:17:09 mdszy has quit (Quit: goodnight~)
768 2013-03-06 04:17:19 JZavala has joined
769 2013-03-06 04:17:24 Diablo-D3 has quit (Quit: do coders dream of sheep()?)
770 2013-03-06 04:17:41 Diablo-D3 has joined
771 2013-03-06 04:18:05 abrkn has joined
772 2013-03-06 04:18:11 <PRab> My end goal is to get a histogram of each transactions priority when it was included in its respective block. Hopefully I'll be able to apply some different filters and try different formulas for the priority to see how they effect the overall histogram.
773 2013-03-06 04:20:50 <xjrn> wow. that's not tedious?
774 2013-03-06 04:21:14 swappermall has quit (Read error: Connection reset by peer)
775 2013-03-06 04:21:30 <PRab> I'm hoping I can automate most of it.
776 2013-03-06 04:22:09 <PRab> I believe that the end result could be very beneficial for tuning mining pools.
777 2013-03-06 04:22:18 <xjrn> i think you'll discover the world of digital shit-heaps
778 2013-03-06 04:23:22 <xjrn> does it matter prior to consistent block saturation?
779 2013-03-06 04:23:37 abrkn\ has joined
780 2013-03-06 04:23:37 abrkn is now known as Guest83320
781 2013-03-06 04:23:52 <PRab> Right now, some pools exclude SD transactions just because they are from SD. I believe that there is a different formula that will prevent "spam" but still allow services like SD to exist.
782 2013-03-06 04:24:21 <PRab> (SD could still be improved in several other ways to be more blockchain friendly)
783 2013-03-06 04:25:12 <xjrn> i think some pools exclude sd because they are run by luke-jr.
784 2013-03-06 04:26:26 <PRab> I agree that is a leading faction, but luke-jr has some good reason why they are excluded. I am trying to find a more balanced solution.
785 2013-03-06 04:26:43 Guest83320 has quit (Ping timeout: 245 seconds)
786 2013-03-06 04:26:56 <PRab> faction --> factor
787 2013-03-06 04:27:38 grau has joined
788 2013-03-06 04:27:48 <Luke-Jr> xjrn: responsible pools exclude SD
789 2013-03-06 04:28:29 <Luke-Jr> PRab: autodetecting blockchain abuse would be a welcome improvement of course
790 2013-03-06 04:29:08 <egecko> and who decides what is "abuse"?
791 2013-03-06 04:29:27 <SomeoneWeird> the majority
792 2013-03-06 04:30:03 <PRab> That is the goal of my endeavor. By making a nice graphical representation, I believe that "abuse" will become more selfevident.
793 2013-03-06 04:30:05 freakazoid_ has joined
794 2013-03-06 04:30:39 <gmaxwell> PRab: uh. priority doesn't have anything to do with those transactions, however. It's only used to sort the free txn.
795 2013-03-06 04:30:41 <PRab> SomeoneWeird: Not the majority, each individual miner (pool) decides for itself.
796 2013-03-06 04:30:54 <egecko> thats like saying someone knows porn when they see it
797 2013-03-06 04:31:09 abrkn\ has quit (Ping timeout: 276 seconds)
798 2013-03-06 04:31:31 <egecko> exactly what is the gripe about SD anyway?
799 2013-03-06 04:31:38 <doublec> PRab: each node has a say too if they refuse to relay abusive transactions
800 2013-03-06 04:31:55 grau has quit (Ping timeout: 250 seconds)
801 2013-03-06 04:31:58 <gmaxwell> egecko: go debate with luke in #bitcoin, not here please.
802 2013-03-06 04:32:16 <gmaxwell> egecko: or just look in the logs, it has been discussed many many times.
803 2013-03-06 04:32:30 <PRab> gmaxwell: I keep misusing/abusing the term priority. I basically mean "the chance that transaction will be included in the next block"
804 2013-03-06 04:33:05 <PRab> doublec: True unless the node sends the transaction directly to the miner.
805 2013-03-06 04:33:12 <gmaxwell> PRab: well, I have no clue how you're going to graph that.
806 2013-03-06 04:33:47 <PRab> gmaxwell: perfect, then it sounds like a good challenge.
807 2013-03-06 04:34:18 TheSeven has quit (Disconnected by services)
808 2013-03-06 04:34:27 [7] has joined
809 2013-03-06 04:35:07 <gmaxwell> PRab: if you're interested in this spaceâ we're mostly interested in incentive realignments that encourage people to not bloat the UTXO set, and potentially ones that encourage privacy promoting behaviors.
810 2013-03-06 04:35:14 JStoker has quit (Excess Flood)
811 2013-03-06 04:35:45 <gmaxwell> I don't think that most people here think SD is terribly interesting. other than as a watercooler gripe and a demonstration that the system is currently somewhat miscalibrated.
812 2013-03-06 04:36:23 <PRab> gmaxwell: Agreed about shrinking UTXO. I'm not as concerned about privacy (just my opinion).
813 2013-03-06 04:37:02 <Luke-Jr> egecko: people donate their CPU time and bandwidth to Bitcoin for a common purpose. taking advantage of that for other purposes violates the trust of these volunteers
814 2013-03-06 04:37:13 <PRab> SD is just a starting point. For me it is a good benchmark of what people currently believe is abusive.
815 2013-03-06 04:37:28 * Luke-Jr sees #bitcoin redirect
816 2013-03-06 04:38:47 Guest28611 is now known as burrito
817 2013-03-06 04:39:05 <gmaxwell> PRab: without privacy bitcoin is pretty unattractive compared to traditional banking. I'm not talking about druggies hiding their whatever, I'm talking about the inlaws asking why you're buying contraception when they want grandkids. Virtually all banking has casual privacy as a basic feature, and bitcoin is pretty weak in that regard if misused.
818 2013-03-06 04:39:17 burrito is now known as Guest40859
819 2013-03-06 04:39:28 <gmaxwell> (the other point about privacy is that the non-private behavior also lets you easily see when a single user is using more than their fair share)
820 2013-03-06 04:41:25 oxygenerator has joined
821 2013-03-06 04:41:32 <PRab> An individual can already have almost perfect privacy if they are currently careful (TOR + use every address only once + mixer). To me that sounds more like a client side task than a network wide issue.
822 2013-03-06 04:41:38 pacpac has joined
823 2013-03-06 04:42:16 JStoker has joined
824 2013-03-06 04:42:26 <gmaxwell> PRab: nah, alas it's not so.
825 2013-03-06 04:42:39 JStoker has quit (Excess Flood)
826 2013-03-06 04:42:43 <PRab> How so...?
827 2013-03-06 04:43:40 oxygenerator has quit (Read error: Connection reset by peer)
828 2013-03-06 04:44:13 <gmaxwell> PRab: You pay someone, you are an ultratorusing ninja. Someone wants to know who you are. They look at the history of that coin and see it came from 1Gmaxwell, and then they come put the screws to me to find out what I know. Basically if I don't also behave in a privacy preserving way I compromise the privacy of anyone I trade with.
829 2013-03-06 04:44:14 hydrogenesis has quit (Ping timeout: 245 seconds)
830 2013-03-06 04:44:47 <gmaxwell> So generally, all things equal the system should make preserving privacy more efficient than not, so that the people who do care won't have it compromised by people who are more indifferent.
831 2013-03-06 04:46:00 JStoker has joined
832 2013-03-06 04:46:00 JStoker has quit (Excess Flood)
833 2013-03-06 04:46:24 <gmaxwell> There are other fun thingsâ address reuse makes users more vulnerable to ECDSA compromises. ... and address reuse makes it attractive to talk about forcing people to block undesirable things.
834 2013-03-06 04:47:14 <PRab> Ah, multiparty collusion. For security, I always get my mind stuck in a world of "everybody hates everybody else"
835 2013-03-06 04:47:21 ahbritto has joined
836 2013-03-06 04:47:25 ahbritto_ has joined
837 2013-03-06 04:47:39 Apexseals has joined
838 2013-03-06 04:47:42 JStoker has joined
839 2013-03-06 04:47:42 JStoker has quit (Excess Flood)
840 2013-03-06 04:47:43 <PRab> +1 for no (minimal) address reuse.
841 2013-03-06 04:48:25 JStoker has joined
842 2013-03-06 04:48:45 <gmaxwell> On the plus side, normally we can't do fair loadbalancing of the network because we cant tell one user with two transactions from two users. So one thought was thrown out about depriortizing address txn that perform local reuse, because its voluntarily showing that you're using more of the network... and avoiding reuse is generally good.
843 2013-03-06 04:50:20 <PRab> At first glance I like that idea. I don't even (again, first glance) see a problem with limiting it to 1 tx per address per block.
844 2013-03-06 04:51:15 <gmaxwell> yea, that was some of the thinking.. its easy to compute too.. just record what addr you've already added and don't allow the second one. (or only allow it if it has increasingly high fees, or whatever).
845 2013-03-06 04:52:00 <PRab> +1 this is the sort of data I want to experiment with.
846 2013-03-06 04:52:19 ahbritto_ has quit (Ping timeout: 276 seconds)
847 2013-03-06 04:52:27 ahbritto has quit (Ping timeout: 276 seconds)
848 2013-03-06 04:53:09 <PRab> just started -txindex=1 -reindex=1. Should be done by tomorrow morning, so I should be able to take a better look at what sort of raw data I can get then.
849 2013-03-06 04:54:18 <gmaxwell> oh a reindex doesn't take that long.. I think my laptop was doing one in about an hour or so-ish.
850 2013-03-06 04:55:03 <warren> txindex=1 reindex is much slower though
851 2013-03-06 04:55:19 <PRab> yeah, its cranking along. 97000 blocks remaining, but its midnight here and I need to go to bed.
852 2013-03-06 04:55:22 <gmaxwell> warren: my figure is w/ txindex=1.
853 2013-03-06 04:55:27 <warren> ah
854 2013-03-06 04:55:27 <gmaxwell> PRab: goodnight.
855 2013-03-06 04:55:38 <PRab> Later.
856 2013-03-06 04:55:54 <gmaxwell> warren: did you actually check that it was much slower? it shouldn't be _that_ much slower.
857 2013-03-06 04:56:38 <warren> My memory might be hazy. I ended up not needing txindex=1 like I thought, so I forgot about it.
858 2013-03-06 04:56:54 <gmaxwell> ::nods::
859 2013-03-06 05:04:24 <Luke-Jr> PRab: also, note tor can be traced by governments
860 2013-03-06 05:06:10 <nethershaw> by "traced" you mean "endpoint attacks" and "sophisticated, mathematically complex statistical analysis combined with deep packet inspection," of course.
861 2013-03-06 05:07:02 <nethershaw> They can't just throw a switch. They have to want it, and care, and have a reason, which assumes they know something about you in the first place.
862 2013-03-06 05:07:14 freakazoid_ is now known as freakazoid
863 2013-03-06 05:07:46 welovecp has quit (Ping timeout: 240 seconds)
864 2013-03-06 05:08:31 <nethershaw> "Traced." What a funny TV word that is.
865 2013-03-06 05:16:15 JZavala has quit (Ping timeout: 256 seconds)
866 2013-03-06 05:16:18 bitit has quit (Remote host closed the connection)
867 2013-03-06 05:16:18 i2pRelay has quit (Remote host closed the connection)
868 2013-03-06 05:16:18 holorga has quit (Remote host closed the connection)
869 2013-03-06 05:16:18 random_cat has quit (Write error: Broken pipe)
870 2013-03-06 05:17:36 bitit has joined
871 2013-03-06 05:18:25 holorga has joined
872 2013-03-06 05:22:06 i2pRelay has joined
873 2013-03-06 05:22:26 discrete has joined
874 2013-03-06 05:35:01 idstam has joined
875 2013-03-06 05:38:15 coolsa has quit (Quit: ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)
876 2013-03-06 05:41:51 pacpac has quit (Ping timeout: 245 seconds)
877 2013-03-06 05:41:52 hydrogenesis has joined
878 2013-03-06 05:43:07 brwyatt is now known as brwyatt|Away
879 2013-03-06 05:47:06 ahbritto has joined
880 2013-03-06 05:47:06 ahbritto has quit (Changing host)
881 2013-03-06 05:47:06 ahbritto has joined
882 2013-03-06 05:53:40 JZavala has joined
883 2013-03-06 05:56:01 freakazoid has quit (Read error: Connection reset by peer)
884 2013-03-06 06:01:14 BTCOxygen is now known as Oxygen
885 2013-03-06 06:01:36 Oxygen is now known as BTCOxygen
886 2013-03-06 06:03:02 BTCOxygen is now known as Oxygen
887 2013-03-06 06:03:10 Oxygen is now known as BTCOxygen
888 2013-03-06 06:07:35 nowan_ has quit (Ping timeout: 255 seconds)
889 2013-03-06 06:13:23 iddo has quit (Ping timeout: 252 seconds)
890 2013-03-06 06:13:32 iddo has joined
891 2013-03-06 06:16:34 hydrogenesis has quit (Remote host closed the connection)
892 2013-03-06 06:17:20 abrkn has joined
893 2013-03-06 06:17:28 gjs278 has quit (Ping timeout: 276 seconds)
894 2013-03-06 06:18:09 gjs278 has joined
895 2013-03-06 06:18:15 <yebyen> is this patch approaching the right way to go about lowering the minimum difficulty (for a testnet): https://github.com/yebyen/testnet-debian/commit/1015515def2a1c2d9ce57b9613e65dd5733e2b4a
896 2013-03-06 06:19:04 <Luke-Jr> yebyen: erm, specifically for Debian? O.o
897 2013-03-06 06:19:19 <yebyen> debian supplies 0.7.2 source packages
898 2013-03-06 06:19:39 <yebyen> therefore i jumped through hoops to get -checkpoint=0 like functionality
899 2013-03-06 06:19:57 <warren> why are you mining on a slow ARM device?
900 2013-03-06 06:20:17 <yebyen> my friend has an nvidia onboard chip and I want him to 51% my network
901 2013-03-06 06:20:33 <xjrn> Luke-Jr: while i do value my ssd and SD might tip the scales in favor of using a usb-3 passport to hold my bt-qt, i think gmaxwell repeatedly and accurately points out that fees are already built to hush the noise floor
902 2013-03-06 06:20:35 <yebyen> (i can play with this device on my lunch break and put it away after)
903 2013-03-06 06:20:46 <gjs278> you won't kill your ssd by writing to it
904 2013-03-06 06:20:52 <Luke-Jr> xjrn: fees don't work on SD
905 2013-03-06 06:21:02 <yebyen> so far it doesn't seem to be attempting to lower the difficulty
906 2013-03-06 06:21:15 <Luke-Jr> xjrn: I think gmaxwell would agree that SD is an unusual case
907 2013-03-06 06:21:26 <Luke-Jr> gjs278: yes you can
908 2013-03-06 06:21:37 <gjs278> you can
909 2013-03-06 06:21:37 <xjrn> Luke-Jr: if there's a megabyte block, the SD would be squeezed out right>
910 2013-03-06 06:21:38 <gjs278> he will not
911 2013-03-06 06:21:49 <Luke-Jr> xjrn: no, SD would squeeze out legit uses
912 2013-03-06 06:21:52 <gjs278> you have to torture test it for months to kill them now
913 2013-03-06 06:22:02 <Luke-Jr> xjrn: #bitcoin for this
914 2013-03-06 06:22:07 <xjrn> gjs278: my ssd's are for chopping up data and snborting it, not holding noise.
915 2013-03-06 06:22:24 <Luke-Jr> xjrn: also, you should upgrade to 0.8
916 2013-03-06 06:23:36 <xjrn> Luke-Jr: hwo does doubling the footprint of the blockchain with an index help with SD?
917 2013-03-06 06:23:38 <gjs278> assuming your usb-3 passport is a hard disk, you'll probably kill that with the spin up spin down faster than you would kill your ssd
918 2013-03-06 06:23:55 <xjrn> gjs278: i don't give a shit about my passport though.
919 2013-03-06 06:23:59 <Luke-Jr> xjrn: huh?
920 2013-03-06 06:24:11 <Luke-Jr> I meant yebyen should upgrade to 0.8, sorry
921 2013-03-06 06:24:27 <Luke-Jr> and 0.8 uses less disk space than previous versions because its index is smaller than the one previously used
922 2013-03-06 06:24:31 <xjrn> qt 0.8 creates an index as large as the blockchain itself, give or take.
923 2013-03-06 06:24:45 <Luke-Jr> xjrn: nonsense
924 2013-03-06 06:24:58 <yebyen> Luke-Jr: i will, but for now I just want to see what else needs to change to get my tegra2 pumping out blocks of some kind
925 2013-03-06 06:25:20 <yebyen> so far i've only been able to produce 1 block before i get impatient and recompile or reset the blockchain
926 2013-03-06 06:26:12 <yebyen> i will gladly submit 0.8 to sid if i can figure this out, without the stupid patches
927 2013-03-06 06:26:26 freewil has quit (Quit: Leaving)
928 2013-03-06 06:27:22 freewil has joined
929 2013-03-06 06:27:40 <yebyen> so far really thrilled to be learning the difference between debian/rules and debuild, about dpkg-source --commit and dpkg-buildpackage
930 2013-03-06 06:27:54 <yebyen> i've built debs before but rarely patched them
931 2013-03-06 06:28:01 <yebyen> and never understood exactly what I was doing
932 2013-03-06 06:28:19 <xjrn> 1.6G blkindex.dat
933 2013-03-06 06:28:20 freewil has quit (Client Quit)
934 2013-03-06 06:30:07 <Luke-Jr> xjrn: yep, that's 0.7 and earlier
935 2013-03-06 06:30:09 <xjrn> Luke-Jr: 1.6 gigs of index for 5.2 gigs of blockchain lacks something in the "index" concept... it might as well be a par2
936 2013-03-06 06:30:13 <xjrn> that;'s 0.8
937 2013-03-06 06:30:16 <Luke-Jr> no
938 2013-03-06 06:30:20 <Luke-Jr> 0.8 does not use blkindex.dat at all
939 2013-03-06 06:30:32 <Luke-Jr> 0.8 uses blocks/rev*, blocks/index, and chainstate/
940 2013-03-06 06:30:37 <Luke-Jr> which total 961 MB here
941 2013-03-06 06:31:01 nus- has joined
942 2013-03-06 06:31:04 <xjrn> v0.8.0.0-unk-beta
943 2013-03-06 06:31:24 <Luke-Jr> xjrn: 0.8 does not use blkindex.dat at all
944 2013-03-06 06:31:29 <Luke-Jr> delete it if you like, it doesn't care
945 2013-03-06 06:31:36 <Luke-Jr> it didn't make it, it doesn't read it
946 2013-03-06 06:31:58 hydrogenesis has joined
947 2013-03-06 06:32:24 <warren> There's a script in the source that cleans up old .bitcoin/ stuff
948 2013-03-06 06:32:29 <xjrn> considering it was a fresh install, save for the wallet, I'm going to leave it where it is. the bitch took hours to build
949 2013-03-06 06:32:42 <Luke-Jr> xjrn: not a fresh install of 0.8, I guarantee you
950 2013-03-06 06:32:49 <warren> xjrn: 0.8 is wayyy faster
951 2013-03-06 06:32:54 RazielZ has joined
952 2013-03-06 06:33:05 <xjrn> its a fresh install of whatever git trunk i built from last week
953 2013-03-06 06:33:15 <yebyen> so can anyone give me a hint how to lower the difficulty?
954 2013-03-06 06:33:53 Diablo-D3 has quit (Quit: This computer has gone to sleep)
955 2013-03-06 06:34:24 grau has joined
956 2013-03-06 06:34:27 <Luke-Jr> xjrn: no, it isn't.
957 2013-03-06 06:34:33 <jgarzik> did a 400k+ transaction float by?
958 2013-03-06 06:34:34 <jgarzik> https://bitcointalk.org/index.php?topic=149577.msg1588998#msg1588998
959 2013-03-06 06:35:01 nus has quit (Ping timeout: 276 seconds)
960 2013-03-06 06:35:35 one_zero has quit ()
961 2013-03-06 06:36:08 one_zero has joined
962 2013-03-06 06:37:40 <yebyen> is it actually not possible to have a difficulty lower than 1?
963 2013-03-06 06:37:57 <yebyen> or just not easy
964 2013-03-06 06:38:41 <lianj> https://github.com/mhanne/bitcoin/commit/878d8b3b404496338a56034b2f01b032f0ae8d3b works for me
965 2013-03-06 06:39:58 <yebyen> i just found that in another place
966 2013-03-06 06:40:51 <yebyen> proofofworklimit is the difficulty?
967 2013-03-06 06:41:02 <yebyen> and target spacing allows blocks to be on average closer together than 10 minutes
968 2013-03-06 06:45:13 <yebyen> damn, bnProofOfWorkLimit is not defined in this way on my source
969 2013-03-06 06:46:11 <jgarzik> 2013-03-06 06:45:39 ERROR: CTransaction::CheckTransaction() : vin empty
970 2013-03-06 06:46:11 <jgarzik> 2013-03-06 06:45:39 ERROR: CTxMemPool::accept() : CheckTransaction failed
971 2013-03-06 06:46:12 <jgarzik> 2013-03-06 06:45:39 Misbehaving: 37.59.115.245:8333 (0 -> 10)
972 2013-03-06 06:46:32 <jgarzik> and several
973 2013-03-06 06:46:34 <jgarzik> 2013-03-06 06:45:39 ERROR: CTxMemPool::accept() : inputs already spent
974 2013-03-06 06:46:34 <jgarzik> 2013-03-06 06:45:39 Misbehaving: 37.59.115.245:8333 (0 -> 0)
975 2013-03-06 06:48:29 m00p has quit (Quit: Leaving)
976 2013-03-06 06:52:06 <xjrn> Luke-Jr i think you're right. that said, SD is only annoying on blockchain front page. a squelch option would fix it for me.
977 2013-03-06 06:53:01 <Luke-Jr> xjrn: #bitcoin-watch is filtered
978 2013-03-06 06:54:19 freewil has joined
979 2013-03-06 06:54:49 <xjrn> gee wonder why
980 2013-03-06 06:55:13 Belkaar has quit (Changing host)
981 2013-03-06 06:55:13 Belkaar has joined
982 2013-03-06 07:00:38 defunctzombie is now known as defunctzombie_zz
983 2013-03-06 07:01:40 <yebyen> ohh well now i have a much lower difficulty
984 2013-03-06 07:01:42 <yebyen> that's nice
985 2013-03-06 07:02:38 agath has quit (Ping timeout: 246 seconds)
986 2013-03-06 07:03:46 nym has quit (Ping timeout: 240 seconds)
987 2013-03-06 07:06:56 licnep has quit (Read error: Operation timed out)
988 2013-03-06 07:18:37 tyn has joined
989 2013-03-06 07:24:43 bitit has quit (Ping timeout: 276 seconds)
990 2013-03-06 07:26:33 <jgarzik> hrm
991 2013-03-06 07:26:39 <jgarzik> are zero-vout transactions permitted?
992 2013-03-06 07:26:47 <jgarzik> i.e. a transaction that is 100% miner fee, burning money
993 2013-03-06 07:36:38 <yebyen> if i only have two blocks, should it be possible for each of my nodes to show 2 immature and 2 confirmations?
994 2013-03-06 07:37:02 <yebyen> possibly some of these will be disconfirmed later?
995 2013-03-06 07:37:13 <yebyen> (eg 4 rewards)
996 2013-03-06 07:37:43 i2pRelay has quit (Ping timeout: 276 seconds)
997 2013-03-06 07:39:03 <yebyen> i guess i will know after nTargetSpacing/=60
998 2013-03-06 07:43:22 oxygenerator has joined
999 2013-03-06 07:43:25 hydrogenesis has quit (Read error: Connection reset by peer)
1000 2013-03-06 07:43:31 oxygenerator is now known as hydrogenesis
1001 2013-03-06 07:46:27 grau has quit (Remote host closed the connection)
1002 2013-03-06 07:47:02 grau has joined
1003 2013-03-06 07:58:31 B0g4r7 has quit (Ping timeout: 276 seconds)
1004 2013-03-06 07:59:45 great_scott has joined
1005 2013-03-06 08:00:13 Goonie has joined
1006 2013-03-06 08:01:54 <great_scott> hey all - quick question - I'm having trouble finding the address from which bitcoins were sent to my bitcoind server. I'm looking at past transactions using the jsonrpc api, and the transactiosn only appear to show my server's addresses/accounts in them
1007 2013-03-06 08:02:28 <great_scott> I'm testing by sending BTCs from a client on my phone. Maybe that's why?
1008 2013-03-06 08:02:32 <Luke-Jr> great_scott: transactions only have receiving addresses, there is no "from..sent"
1009 2013-03-06 08:02:50 <great_scott> oh
1010 2013-03-06 08:02:54 <Luke-Jr> great_scott: you need to make a new receiving address for each transaction so you know what it's for/from
1011 2013-03-06 08:03:05 andytoshi has joined
1012 2013-03-06 08:03:57 <great_scott> thanks Luke-Jr. Ergh, I hate to bring it up, but what does SDice do then to figure out how to turn-around a transaction
1013 2013-03-06 08:04:40 <Luke-Jr> great_scott: SDice is a DDoS attack against bitcoin, and not a good "service" to imitate
1014 2013-03-06 08:04:53 <Luke-Jr> great_scott: it's abusing a coincidence about how Bitcoin-Qt sends transactions
1015 2013-03-06 08:04:59 <Luke-Jr> to try to "guess" a return address
1016 2013-03-06 08:06:01 Mandrius has joined
1017 2013-03-06 08:07:11 t7 has joined
1018 2013-03-06 08:07:20 <great_scott> Is there anything wrong with that aspect / of "guessing" a return address though? Or is that somehow part of the DDoS element
1019 2013-03-06 08:07:56 <gmaxwell> great_scott: you'll get it wrong, send funds to the wrong places where they can potentially never be recovered from.
1020 2013-03-06 08:08:06 <Luke-Jr> ^
1021 2013-03-06 08:08:34 <gmaxwell> Even SD has a warning on it to test with small amounts first. It's a risky assumption which is not always true.
1022 2013-03-06 08:08:51 t7 has quit (Client Quit)
1023 2013-03-06 08:09:13 <Luke-Jr> great_scott: there is some work being done for a payment protocol, which negotiates a proper return address, comments, etc
1024 2013-03-06 08:09:17 <gmaxwell> (and will probably be less true in the future as people's habbits change, and business like coinbase stop doing 2x transactions in order to accomidate it due to the cost of doing so)
1025 2013-03-06 08:12:29 <great_scott> Alright, thanks for the input. I was hoping I could just be lazy about the return payment part for this small project :/
1026 2013-03-06 08:16:14 <great_scott> Night + thanks again - time to go read up on things...
1027 2013-03-06 08:16:23 great_scott has quit (Quit: Leaving)
1028 2013-03-06 08:17:16 nowan has joined
1029 2013-03-06 08:17:36 <andytoshi> it'd be nice if someone wrote a more detailed whitepaper which describes the scripting system
1030 2013-03-06 08:18:04 <gmaxwell> I think I think the wiki page on Script is pretty good.
1031 2013-03-06 08:18:38 <andytoshi> i concur, but if you're thinking of bitcoin in terms of addresses, there might be a language barrier
1032 2013-03-06 08:19:24 ovidiusoft has joined
1033 2013-03-06 08:25:14 dvide has quit ()
1034 2013-03-06 08:27:05 <jgarzik> it sure would be nice, if P2SH redemption transactions w/ non-standard redemption scripts would get relayed
1035 2013-03-06 08:27:14 <jgarzik> but alas
1036 2013-03-06 08:29:00 <Luke-Jr> jgarzik: effectively removing IsStandard? :P
1037 2013-03-06 08:29:20 <lianj> ^^
1038 2013-03-06 08:29:20 <jgarzik> makes P2SH a lot less useful
1039 2013-03-06 08:29:35 <jgarzik> Luke-Jr: obviously
1040 2013-03-06 08:29:56 nym has joined
1041 2013-03-06 08:30:21 Pwngu has quit (Ping timeout: 252 seconds)
1042 2013-03-06 08:32:44 <jgarzik> nuts
1043 2013-03-06 08:32:50 <jgarzik> 1/2 billion market cap
1044 2013-03-06 08:33:40 <Luke-Jr> jgarzik: how much could you drop it? :p
1045 2013-03-06 08:34:08 <jgarzik> Luke-Jr: with my ~200 BTC, not by much
1046 2013-03-06 08:34:11 <gmaxwell> ;;ticker
1047 2013-03-06 08:34:11 <gribble> BTCUSD ticker | Best bid: 46.81000, Best ask: 46.88800, Bid-ask spread: 0.07800, Last trade: 46.80000, 24 hour volume: 108507.49885194, 24 hour low: 38.48373, 24 hour high: 46.93000, 24 hour vwap: 41.45938
1048 2013-03-06 08:34:23 <Luke-Jr> jgarzik: how about if you use all the savings accounts?
1049 2013-03-06 08:34:34 <gmaxwell> ;;bids 20.
1050 2013-03-06 08:34:36 <jgarzik> Luke-Jr: that includes all the savings accounts
1051 2013-03-06 08:34:39 <gribble> There are currently 85347.577 bitcoins demanded at or over 20.0 USD, worth 2774186.57947 USD in total. | Data vintage: 0.0131 seconds
1052 2013-03-06 08:34:48 <Luke-Jr> oh ._.
1053 2013-03-06 08:34:58 <gmaxwell> ;;market buy 2774186.57947
1054 2013-03-06 08:34:58 <gribble> This order would exceed the size of the order book. You would buy 59213.868 bitcoins, for a total of 16175843126987.2285 USD and take the price to 13370133701337.0000. | Data vintage: 18.9638 seconds
1055 2013-03-06 08:35:11 <gmaxwell> ;;market buy 85347.577
1056 2013-03-06 08:35:11 <gribble> This order would exceed the size of the order book. You would buy 59213.868 bitcoins, for a total of 16175843126987.2285 USD and take the price to 13370133701337.0000. | Data vintage: 32.0123 seconds
1057 2013-03-06 08:35:32 <Luke-Jr> gmaxwell: O.o
1058 2013-03-06 08:35:37 <gmaxwell> crazy, you cannot collapse the price to $20 using coins available on the orderbook.
1059 2013-03-06 08:35:46 <gmaxwell> There aren't enough coins available to do it.
1060 2013-03-06 08:36:03 <gmaxwell> ;;asks 49.9999999
1061 2013-03-06 08:36:03 <gribble> There are currently 9524.5949 bitcoins offered at or under 49.9999999 USD, worth 461124.016302 USD in total. | Data vintage: 83.9881 seconds
1062 2013-03-06 08:36:11 <gmaxwell> ;;market sell 9524.5949
1063 2013-03-06 08:36:11 <gribble> A market order to sell 9524.5949 bitcoins right now would net 416117.0525 USD and would take the last price down to 41.2700 USD, resulting in an average price of 43.6887 USD/BTC. | Data vintage: 92.0802 seconds
1064 2013-03-06 08:36:26 <gmaxwell> but for a cost of only 45k you could get it to $50.
1065 2013-03-06 08:36:27 GMP has quit (Ping timeout: 260 seconds)
1066 2013-03-06 08:40:11 sgornick has quit (Ping timeout: 260 seconds)
1067 2013-03-06 08:41:43 hydrogenesis has quit (Quit: Colloquy for iPhone - http://colloquy.mobi)
1068 2013-03-06 08:44:05 Pwngu has joined
1069 2013-03-06 08:47:11 hydrogenesis has joined
1070 2013-03-06 08:48:24 weex has quit (Ping timeout: 248 seconds)
1071 2013-03-06 08:48:56 Pwngu has quit (Ping timeout: 252 seconds)
1072 2013-03-06 08:49:47 <grau> volatility is bad for adoption, no matter what the price is
1073 2013-03-06 08:51:22 weex has joined
1074 2013-03-06 08:54:37 <MC1984> hmm why dows mem usage swing between 150 and 300 seemingly at random
1075 2013-03-06 08:55:10 <MC1984> maybe when a block comes in
1076 2013-03-06 09:01:36 defunctzombie_zz is now known as defunctzombie
1077 2013-03-06 09:02:21 Pwngu has joined
1078 2013-03-06 09:05:55 licnep has joined
1079 2013-03-06 09:07:15 paybitcoin has joined
1080 2013-03-06 09:08:21 Garr255_ has joined
1081 2013-03-06 09:11:36 Garr255 has quit (Ping timeout: 252 seconds)
1082 2013-03-06 09:14:03 toffoo has quit ()
1083 2013-03-06 09:14:13 t7 has joined
1084 2013-03-06 09:17:55 <TD> MC1984, bitcoin doesn't use memory very effectively
1085 2013-03-06 09:18:04 <TD> everything is stored in stl vectors so it requires huge contiguous memory ranges
1086 2013-03-06 09:20:52 sgornick has joined
1087 2013-03-06 09:23:46 kriqCoin has joined
1088 2013-03-06 09:23:50 <kriqCoin> !ticker --last
1089 2013-03-06 09:23:50 <gribble> 44.80000
1090 2013-03-06 09:29:33 nanotube has quit (Remote host closed the connection)
1091 2013-03-06 09:29:33 gribble has quit (Read error: Connection reset by peer)
1092 2013-03-06 09:31:33 <kriqCoin> ticker offline?
1093 2013-03-06 09:31:44 <kriqCoin> !ticker --last
1094 2013-03-06 09:36:10 <sturles> kriqCoin: This don't belong in #bitcoin-dev anyway.
1095 2013-03-06 09:37:05 <sipa> MC1984: the coindb cache is flushed for every block
1096 2013-03-06 09:37:29 nanotube has joined
1097 2013-03-06 09:39:22 <gmaxwell> MC1984: inbound connections influence memory a lot.
1098 2013-03-06 09:39:41 <sipa> jgarzik: a tx has at least one input and at least one output (hard rule)
1099 2013-03-06 09:40:46 gribble has joined
1100 2013-03-06 09:41:38 <MC1984> ok
1101 2013-03-06 09:41:44 [7] has quit (Remote host closed the connection)
1102 2013-03-06 09:44:33 TheSeven has joined
1103 2013-03-06 09:47:24 CaptainBlaze has joined
1104 2013-03-06 09:47:46 oxygenerator has joined
1105 2013-03-06 09:47:51 hydrogenesis has quit (Ping timeout: 260 seconds)
1106 2013-03-06 09:47:54 oxygenerator is now known as hydrogenesis
1107 2013-03-06 09:48:36 ielo has joined
1108 2013-03-06 09:48:41 CaptainBlaze has quit (Client Quit)
1109 2013-03-06 10:03:00 ielo has quit (Ping timeout: 272 seconds)
1110 2013-03-06 10:14:06 rdymac has joined
1111 2013-03-06 10:16:59 hydrogenesis has quit (Read error: Connection reset by peer)
1112 2013-03-06 10:17:17 hydrogenesis has joined
1113 2013-03-06 10:20:56 sgornick has quit (Ping timeout: 245 seconds)
1114 2013-03-06 10:28:00 sgornick has joined
1115 2013-03-06 10:31:51 defunctzombie is now known as defunctzombie_zz
1116 2013-03-06 10:39:57 CodeShark has joined
1117 2013-03-06 10:47:36 Mandrius has quit (Ping timeout: 245 seconds)
1118 2013-03-06 10:48:01 i2pRelay has joined
1119 2013-03-06 10:48:05 FredEE has quit (Quit: FredEE)
1120 2013-03-06 10:48:14 <doublec> 6 blocks in a row found by ozcoin. asics definitely shaking the pool arena up.
1121 2013-03-06 10:50:23 mappum has quit (Ping timeout: 260 seconds)
1122 2013-03-06 10:55:05 <TD> http://ozco.in/content/block-history-bitcoin
1123 2013-03-06 10:55:07 <TD> i don't see that?
1124 2013-03-06 10:55:11 <TD> i see them getting two blocks in a row
1125 2013-03-06 10:55:20 <TD> i don't get why ASIC miners seem to use existing pools. why not just run their own?
1126 2013-03-06 10:55:42 <TD> it doesn't seem economically rational to pay a 1% fee when you could just run your own node and be done with it
1127 2013-03-06 10:58:59 <MC1984> laziness
1128 2013-03-06 10:59:18 <MC1984> well it would hel if fucking p2pool actually worked with the avalons
1129 2013-03-06 10:59:27 <MC1984> what a disaster that they dont
1130 2013-03-06 10:59:51 one_zero has quit ()
1131 2013-03-06 11:00:35 <doublec> TD: https://bitcointalk.org/index.php?topic=14085.msg1588940#msg1588940
1132 2013-03-06 11:00:54 <TD> oh right
1133 2013-03-06 11:01:08 <doublec> also shows here http://blockorigin.pfoe.be/blocklist.php
1134 2013-03-06 11:02:17 <gmaxwell> MC1984: probably will once luke gets access to one to get BFGMiner working on it.
1135 2013-03-06 11:02:59 <MC1984> yeah but most of batch one will be ticking away under peoples desks by then
1136 2013-03-06 11:03:19 <MC1984> same reason why people are still mining on deepbit with 0.3
1137 2013-03-06 11:03:23 <TD> MC1984, if you have an ASIC farm like that you don't need p2pool either
1138 2013-03-06 11:03:24 <gmaxwell> 1%, heck there are people paying 10% (deepbit pps)
1139 2013-03-06 11:03:29 <TD> you can just mine ... the old fashioned way
1140 2013-03-06 11:03:42 <MC1984> peoplelike pools though
1141 2013-03-06 11:03:49 <MC1984> being pat of a team or whatever
1142 2013-03-06 11:03:59 <TD> yes "people" do because it reduces variance. ASIC farms are being setup by companies, who should know better
1143 2013-03-06 11:04:07 <gmaxwell> TD: lots of people also mathfail about how mining works, they think of it as a race and so being 'fastest' matters. Or they fail at reasoning how future difficulty effects their returns.
1144 2013-03-06 11:04:18 * TD shakes his head
1145 2013-03-06 11:04:21 <gmaxwell> TD: no, these "companies" are often totally clueless about this stuff.
1146 2013-03-06 11:04:23 <TD> this is just sad
1147 2013-03-06 11:04:28 <MC1984> distributed computing things have always been much more successful when people can form teams for fun and profit
1148 2013-03-06 11:04:33 <gmaxwell> And hiring me to do math for them costs more than 1% :P
1149 2013-03-06 11:04:36 <TD> hah
1150 2013-03-06 11:04:51 hydrogenesis has quit (Ping timeout: 260 seconds)
1151 2013-03-06 11:04:51 <TD> MC1984, i seriously doubt the asicminer guy gives a crap about fun
1152 2013-03-06 11:11:58 <MC1984> asicminr is different
1153 2013-03-06 11:12:05 <MC1984> i hate that shit
1154 2013-03-06 11:12:17 <MC1984> are people ctually buying into that
1155 2013-03-06 11:13:51 bitit has joined
1156 2013-03-06 11:14:41 rbecker is now known as RBecker
1157 2013-03-06 11:15:08 nanotube has quit (Remote host closed the connection)
1158 2013-03-06 11:15:08 gribble has quit (Remote host closed the connection)
1159 2013-03-06 11:20:09 <Luke-Jr> MC1984: to make it worse, Avalon somehow broke GBT support so you can't use standard decentralized pools either
1160 2013-03-06 11:21:35 nanotube has joined
1161 2013-03-06 11:21:44 <Luke-Jr> and who knows why ASICMiner has only been sighted on already-large miner-fee pools; almost like they are trying to do everything wrong -.-
1162 2013-03-06 11:21:57 <gmaxwell> yea, it's actually kinda hard to solomine on avalon.. you have to install some poolserver. And none of them are luser friendly.
1163 2013-03-06 11:22:08 Hasimir has quit (Ping timeout: 245 seconds)
1164 2013-03-06 11:22:26 <gmaxwell> Luke-Jr: the fee proves its good.
1165 2013-03-06 11:22:30 Hasimir has joined
1166 2013-03-06 11:22:38 <Luke-Jr> although there IS an unidentified 100 Gh/s miner on Eligius - but still nothing compared to the multi-Th they've thrown on the big pools even if it is them
1167 2013-03-06 11:22:42 Hasimir is now known as Guest12813
1168 2013-03-06 11:22:51 <Luke-Jr> gmaxwell: yeah, deepbit is the best pool ever
1169 2013-03-06 11:23:21 <Luke-Jr> gmaxwell: it only supports getwork *without rollntime* and returns True on shares it's rejecting..
1170 2013-03-06 11:23:41 <gmaxwell> I think the formula is goodness = fee * percentage_on_b_i_chart
1171 2013-03-06 11:23:49 _sgstair has joined
1172 2013-03-06 11:23:49 sgstair has quit (Disconnected by services)
1173 2013-03-06 11:23:50 <Luke-Jr> gmaxwell: Avalon users could try my BFGMiner firmware and point it at a bitcoind with GBT
1174 2013-03-06 11:23:50 _sgstair is now known as sgstair
1175 2013-03-06 11:28:20 gribble has joined
1176 2013-03-06 11:33:20 rdymac has quit (Quit: This computer has gone to sleep)
1177 2013-03-06 11:39:23 Hasimir- has joined
1178 2013-03-06 11:40:17 Hasimir- has quit (Changing host)
1179 2013-03-06 11:40:17 Hasimir- has joined
1180 2013-03-06 11:40:53 Guest12813 has quit (Ping timeout: 245 seconds)
1181 2013-03-06 11:40:55 Hasimir- is now known as Hasimir
1182 2013-03-06 11:41:33 drizztbsd has joined
1183 2013-03-06 11:41:33 drizztbsd has quit (Changing host)
1184 2013-03-06 11:41:33 drizztbsd has joined
1185 2013-03-06 11:42:38 RBecker is now known as rbecker
1186 2013-03-06 11:44:52 rdymac has joined
1187 2013-03-06 11:50:43 datagutt has joined
1188 2013-03-06 11:51:16 copumpkin has quit (Ping timeout: 240 seconds)
1189 2013-03-06 11:51:51 copumpkin has joined
1190 2013-03-06 11:52:04 bitit has quit (Remote host closed the connection)
1191 2013-03-06 11:52:21 bitit has joined
1192 2013-03-06 11:53:12 Mandrius has joined
1193 2013-03-06 11:55:47 Hasimir has quit (Read error: Connection reset by peer)
1194 2013-03-06 11:55:51 Hasimir- has joined
1195 2013-03-06 11:56:59 Hasimir- is now known as Hasimir
1196 2013-03-06 11:57:03 Hasimir has quit (Changing host)
1197 2013-03-06 11:57:03 Hasimir has joined
1198 2013-03-06 11:57:22 ielo has joined
1199 2013-03-06 12:05:53 <TD> Graet, why do you think there's no need to increase your block size?
1200 2013-03-06 12:13:00 JZavala has quit (Ping timeout: 245 seconds)
1201 2013-03-06 12:16:49 <Graet> from comments i have read in here
1202 2013-03-06 12:20:13 <TD> Graet, which comments?
1203 2013-03-06 12:21:01 <TD> Graet: if miners don't increase their block size limits, or start to drop transactions they don't care about (like satoshidice), then this is where bitcoin ends - the project can't grow further.
1204 2013-03-06 12:21:09 <TD> Graet: so i'm curious how you got that impression.
1205 2013-03-06 12:21:37 <Graet> i'd love to take the time and dredge through the logs, but i just dont atm sorry
1206 2013-03-06 12:21:49 <TD> so you don't remember?
1207 2013-03-06 12:21:57 <TD> can you paraphrase?
1208 2013-03-06 12:22:08 <Graet> i remember some discussion including some of the devs
1209 2013-03-06 12:22:46 <Graet> sorry, i have had less than 5 hours sleep the last 3 nights, no i cannot remember exactly
1210 2013-03-06 12:23:13 <TD> well, i am one of the devs. if you don't recall the reasons then when you have a bit more time, would you consider setting the flag to increase your limit?
1211 2013-03-06 12:24:15 ielo has quit (Ping timeout: 255 seconds)
1212 2013-03-06 12:24:22 Hasimir has quit (Read error: Connection reset by peer)
1213 2013-03-06 12:25:24 <Graet> sorry, i am really tired and havfe other important stuff to do, can we discuss this another time?
1214 2013-03-06 12:25:49 <Graet> maybe a link to something showing the advantages i can look over :)
1215 2013-03-06 12:26:01 <TD> we can discuss it later, yes. the advantage is that bitcoin traffic can keep growing.
1216 2013-03-06 12:26:07 <TD> you understand the limit we're talking about, right?
1217 2013-03-06 12:26:19 <TD> if miners don't increase their block size limit, transactions will start taking longer and longer to confirm
1218 2013-03-06 12:26:21 <Graet> 256kb blocksize
1219 2013-03-06 12:26:32 <TD> and bitcoin will essentially break, for the purposes of actually paying for things
1220 2013-03-06 12:26:40 <TD> so the "advantage", if you want to call it that, is that bitcoin won't break
1221 2013-03-06 12:26:45 <TD> that should be enough, i'd hope?
1222 2013-03-06 12:26:50 <Graet> do i have to do it tonight?
1223 2013-03-06 12:26:52 <TD> no
1224 2013-03-06 12:26:55 <TD> it's not that urgent
1225 2013-03-06 12:26:56 <Graet> ok
1226 2013-03-06 12:27:01 <Graet> will discuss later, thanks
1227 2013-03-06 12:27:03 ielo has joined
1228 2013-03-06 12:27:04 <TD> ok
1229 2013-03-06 12:27:25 <sipa> in the extreme, an infinite block size means anyone can make payments on the chain, but nobody can validate. an extremely limited blivk size means that nobody can create onchain transactions, but everyone can verify
1230 2013-03-06 12:27:37 bitit has quit (Ping timeout: 276 seconds)
1231 2013-03-06 12:27:39 <sipa> the optimum is clearly somewhere in between
1232 2013-03-06 12:28:22 Hasimir has joined
1233 2013-03-06 12:28:34 Hasimir is now known as Guest13581
1234 2013-03-06 12:29:27 Guest13581 has quit (Changing host)
1235 2013-03-06 12:29:27 Guest13581 has joined
1236 2013-03-06 12:29:34 i2pRelay has quit (Ping timeout: 276 seconds)
1237 2013-03-06 12:29:57 Guest13581 is now known as Mephistopheles
1238 2013-03-06 12:31:00 Mephistopheles is now known as Hasimir
1239 2013-03-06 12:31:10 ovidiusoft has quit (Quit: leaving)
1240 2013-03-06 12:31:11 TD has left ("Leaving")
1241 2013-03-06 12:31:16 TD has joined
1242 2013-03-06 12:32:37 ovidiusoft has joined
1243 2013-03-06 12:32:44 i2pRelay has joined
1244 2013-03-06 12:34:20 Hasimir- has joined
1245 2013-03-06 12:35:14 Hasimir has quit (Disconnected by services)
1246 2013-03-06 12:35:16 Hasimir- has quit (Changing host)
1247 2013-03-06 12:35:16 Hasimir- has joined
1248 2013-03-06 12:35:49 Hasimir- is now known as Hasimir
1249 2013-03-06 12:39:51 bitit has joined
1250 2013-03-06 12:41:14 Shealan has joined
1251 2013-03-06 12:42:02 DamascusVG has quit (Quit: I Quit - http://www.youtube.com/watch?v=9p97zsQ51Rw)
1252 2013-03-06 12:42:12 gigavps has joined
1253 2013-03-06 12:44:03 abrkn has quit (Ping timeout: 255 seconds)
1254 2013-03-06 12:44:53 ielo has quit (Ping timeout: 276 seconds)
1255 2013-03-06 12:46:36 Hasimir- has joined
1256 2013-03-06 12:47:30 Hasimir has quit (Disconnected by services)
1257 2013-03-06 12:47:32 Hasimir- has quit (Changing host)
1258 2013-03-06 12:47:32 Hasimir- has joined
1259 2013-03-06 12:47:48 Hasimir- is now known as Hasimir
1260 2013-03-06 12:57:41 DamascusVG has joined
1261 2013-03-06 12:59:01 Diablo-D3 has joined
1262 2013-03-06 13:00:20 Jynx has left ()
1263 2013-03-06 13:00:40 Hashdog has joined
1264 2013-03-06 13:00:51 Diablo-D3 has quit (Client Quit)
1265 2013-03-06 13:01:04 Diablo-D3 has joined
1266 2013-03-06 13:04:15 abrkn has joined
1267 2013-03-06 13:12:41 Hashdog has quit (Remote host closed the connection)
1268 2013-03-06 13:18:44 axhlf has joined
1269 2013-03-06 13:23:04 AtashiCon has quit (Remote host closed the connection)
1270 2013-03-06 13:27:04 weex has quit (Read error: Connection reset by peer)
1271 2013-03-06 13:27:11 weex has joined
1272 2013-03-06 13:27:11 weex has quit (Changing host)
1273 2013-03-06 13:27:11 weex has joined
1274 2013-03-06 13:30:33 rdymac has quit (Quit: This computer has gone to sleep)
1275 2013-03-06 13:37:53 GMP has joined
1276 2013-03-06 13:38:54 pacpac has joined
1277 2013-03-06 13:40:30 asdasada has joined
1278 2013-03-06 13:40:48 ByteUnit has joined
1279 2013-03-06 13:40:54 gigavps has left ()
1280 2013-03-06 13:43:59 [\\\] has quit (Ping timeout: 260 seconds)
1281 2013-03-06 13:44:19 zooko` has joined
1282 2013-03-06 13:44:24 vampireb has joined
1283 2013-03-06 13:48:32 tyn has quit (Ping timeout: 245 seconds)
1284 2013-03-06 13:49:21 axhlf has quit (Remote host closed the connection)
1285 2013-03-06 13:52:34 Hashdog has joined
1286 2013-03-06 13:55:43 hydrogenesis has joined
1287 2013-03-06 13:56:22 <Luke-Jr> TD: block size shouldn't be increased, miners should start filtering out flooding like they're supposed to
1288 2013-03-06 13:56:43 <TD> and then when it fills back up to 250kb with non-SD transactions?
1289 2013-03-06 13:56:45 <Luke-Jr> without the flooding attacks, 256 kB is far more than sufficient
1290 2013-03-06 13:56:53 <Luke-Jr> for today
1291 2013-03-06 13:57:09 <TD> i'm also equally happy for people to drop the priority of SD transactions
1292 2013-03-06 13:57:10 <Luke-Jr> obviously sometime in the future it'll need addressing for real
1293 2013-03-06 13:57:22 <TD> do you have a patch for that? if so i'll link to it from my forum post
1294 2013-03-06 13:57:40 <Luke-Jr> it's a git branch: https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commit/block_dice
1295 2013-03-06 13:58:06 <Luke-Jr> it's also included in my "eligius" bitcoind branch (for miners/pools)
1296 2013-03-06 14:00:33 SchmalzTech has joined
1297 2013-03-06 14:00:42 <TD> hmm. it'd be better to have a patch that just generically downprioritizes transactions that re-use addresses, imho
1298 2013-03-06 14:00:53 axhlf has joined
1299 2013-03-06 14:01:02 agricocb has quit (Quit: Leaving.)
1300 2013-03-06 14:01:03 <TD> rather than has an explicit blacklist
1301 2013-03-06 14:01:27 pacpac has quit (Ping timeout: 245 seconds)
1302 2013-03-06 14:02:24 D34TH has joined
1303 2013-03-06 14:02:24 D34TH has quit (Changing host)
1304 2013-03-06 14:02:24 D34TH has joined
1305 2013-03-06 14:07:09 <Luke-Jr> grumble @ ASICMiner dividends http://blockchain.info/tx-index/58710945/550f81600de37788b1010ea8a1cbadab24c7d2c25147df6b5765c0e31d5a3551
1306 2013-03-06 14:07:23 <Luke-Jr> TD: I don't have that.
1307 2013-03-06 14:07:26 <sipa> TD: yeah, the only problem is with such a patch that people might consider it a specific anti-SD patch
1308 2013-03-06 14:07:54 <Luke-Jr> sipa: good, miners not blocking SD are being irresponsible
1309 2013-03-06 14:08:55 <sipa> but in general i like the idea of deprioritizing address reuse
1310 2013-03-06 14:09:05 <TD> sipa: the whole point would be that it's not. address re-use is generally a problem for privacy and bloom filtering, if it's softly discouraged that's OK by me.
1311 2013-03-06 14:09:17 kriqCoin has quit (Ping timeout: 245 seconds)
1312 2013-03-06 14:09:17 tyn has joined
1313 2013-03-06 14:09:19 <TD> sipa: SD can easily change to using unique addresses. that would of course annoy Luke-Jr because then it'd be harder for him to block them
1314 2013-03-06 14:09:34 <TD> but perhaps they could publish their root public key, if using deterministic wallets, and that'd make everyone happy :)
1315 2013-03-06 14:09:43 <Luke-Jr> TD: SD can easily stop flooding too, but they don't
1316 2013-03-06 14:09:46 <TD> heh
1317 2013-03-06 14:10:25 <sipa> well, there's a general unwillingness to play nicely, if they're even against introducting compressed keys
1318 2013-03-06 14:10:49 <sipa> they don't even have to stop accepting bets to the old addresses - just publishing new ones would be fine
1319 2013-03-06 14:11:40 <Luke-Jr> if "we need to use one-time addresses to workaround the blocking" is their motive to begin making changes (hopefully including at least compressed keys), that's a step forward at least
1320 2013-03-06 14:11:59 D34TH has quit (Read error: Connection reset by peer)
1321 2013-03-06 14:12:10 D34TH has joined
1322 2013-03-06 14:12:10 D34TH has quit (Changing host)
1323 2013-03-06 14:12:11 D34TH has joined
1324 2013-03-06 14:16:06 <petertodd> OK, here
1325 2013-03-06 14:16:16 <petertodd> here's a legit reason for address re-use: auditable banks.
1326 2013-03-06 14:16:48 <petertodd> If you don't re-use, you'll have to basically provide a seed and have clients scan through a zillion UTXO sums.
1327 2013-03-06 14:17:12 <petertodd> Whereas with re-use it's just a single scriptPubKey UTXO sum.
1328 2013-03-06 14:17:17 TheSeven has quit (Disconnected by services)
1329 2013-03-06 14:17:20 <sipa> petertodd: mhmm
1330 2013-03-06 14:17:26 [7] has joined
1331 2013-03-06 14:17:51 <petertodd> Privacy isn't a big deal in that case, it's specifically not supposed to be private, and for user privacy, the bank is providing it for them.
1332 2013-03-06 14:17:54 hydrogenesis has quit (Quit: Colloquy for iPad - http://colloquy.mobi)
1333 2013-03-06 14:17:57 <petertodd> (e.g. chaum token ledgers)
1334 2013-03-06 14:18:20 <Luke-Jr> petertodd: but it's also abusing the blockchain to convey information ;)
1335 2013-03-06 14:18:40 <petertodd> Luke-Jr: Only to the extent where no other way might be possible.
1336 2013-03-06 14:18:43 <Luke-Jr> I don't see why scanning a zillion UTXOs is difficult
1337 2013-03-06 14:18:52 <petertodd> Luke-Jr: Besides, it's *financial* information.
1338 2013-03-06 14:19:22 <Luke-Jr> petertodd: more relevant, I suppose: there's no reason for more than one aggregation transaction per block
1339 2013-03-06 14:19:22 <petertodd> Because this is for uTx's, who wants to scan a zillion UTXO's just because you're spending a tenth of a penny?
1340 2013-03-06 14:19:26 <TD> petertodd: what's wrong with the seed?
1341 2013-03-06 14:19:49 <TD> petertodd: you can just maintain a buffer of a few hundred keys ahead of what you've actually seen and then each time you see an address get used, add some more to the buffer
1342 2013-03-06 14:21:04 <petertodd> TD: The thing is, this is anti-fraud, so any buffer is problematic. You'd use up a bunch of sequential addresses, say a few hundred or few thousand, then spend the ones in the middle, now the ones at the end are funds the bank controlls, but depending on settings clients will stop scanning and assume they don't actually have.
1343 2013-03-06 14:21:32 <Luke-Jr> petertodd: auditors aren't spending anything..
1344 2013-03-06 14:21:34 <petertodd> TD: You'd need to have a fixed range really, which then limits things. It's ugly all around, while re-using addresses in that case makes life easy.
1345 2013-03-06 14:21:53 <petertodd> Luke-Jr: No, but they're determining if the bank can.
1346 2013-03-06 14:22:53 <TD> ok, well i see bitcoin as removing the need for (non-investment) banks. so i don't really care about that. but even if i did, and if for some reason you're right, they can just pay higher fees on those transactions to bump up the default down-prioritization.
1347 2013-03-06 14:23:07 <petertodd> TD: Well you see O(n^2) scaling as fine so...
1348 2013-03-06 14:23:44 <Luke-Jr> petertodd: any such auditor should simply scan the blockchain from the start, not rely on the UTXO set ;)
1349 2013-03-06 14:23:45 <TD> gah. bitcoin is not O(n^2). you're multiplying it wrong. total work done by the whole network is O(transactions*nodes), but those two quantities are not equal.
1350 2013-03-06 14:24:04 agricocb has joined
1351 2013-03-06 14:24:33 <petertodd> TD: Of course, if it is just a fees / down-prioritization thing, I can probably rest easy, because I always assume in the future fees will be 100% based on block size by profit driven miners, unless we can find a clever way to charge for UTXO use.
1352 2013-03-06 14:24:50 <petertodd> TD: Sigh... so defeat O(n^2) with centralization...
1353 2013-03-06 14:25:04 <TD> num_nodes < num_transactions != centralization
1354 2013-03-06 14:25:04 <TD> anyway
1355 2013-03-06 14:25:38 <petertodd> Luke-Jr: In my example, the auditors are *every user* deciding if they should accept a transfer from a given bank, or deposit at a given bank, because bank identities should be machine evaluatable.
1356 2013-03-06 14:26:42 <Luke-Jr> petertodd: hmm. and the bank can't provide them with a seed + multiple points to scan from?
1357 2013-03-06 14:27:11 vampireb has quit (Quit: Lost terminal)
1358 2013-03-06 14:27:45 JDuke128 has joined
1359 2013-03-06 14:28:16 <petertodd> Luke-Jr: Oh, that's a good idea actually, do a seed and then randomly pick starting points. If every client picks a random one, they can all use some stats to make good probabilistic guesses the size of the funds the bank could possibly control.
1360 2013-03-06 14:28:37 <petertodd> Luke-Jr: Probably good enough if the "re-use addresses" thing is per block only.
1361 2013-03-06 14:29:37 <Luke-Jr> petertodd: eh, I meant to handle the "hole missing because they were spent" case
1362 2013-03-06 14:29:52 <Luke-Jr> petertodd: if you need different sets for different people, I imagine you'd just use another branch on the seed
1363 2013-03-06 14:30:24 <petertodd> Luke-Jr: Right, but holes are naturally going to happen anyway, the banks will never only move off-chain funds - gotta settle accounts with each others for instance.
1364 2013-03-06 14:30:37 <petertodd> Luke-Jr: I mean, the starting points are starting points for each clients audits.
1365 2013-03-06 14:34:38 BNCatDIGISHELL has quit (Quit: changing servers)
1366 2013-03-06 14:34:59 BNCatDIGISHELL has joined
1367 2013-03-06 14:36:09 bitit has quit (Remote host closed the connection)
1368 2013-03-06 14:37:19 bitit has joined
1369 2013-03-06 14:37:21 tigger0 has quit (Ping timeout: 255 seconds)
1370 2013-03-06 14:39:06 bitit has quit (Remote host closed the connection)
1371 2013-03-06 14:40:21 bitit has joined
1372 2013-03-06 14:42:04 _dr has quit (Ping timeout: 250 seconds)
1373 2013-03-06 14:43:01 abrkn has quit (Ping timeout: 245 seconds)
1374 2013-03-06 14:44:03 LargoG has joined
1375 2013-03-06 14:45:44 chmod755 has joined
1376 2013-03-06 14:48:35 hydrogenesis has joined
1377 2013-03-06 14:49:19 [\\\] has joined
1378 2013-03-06 14:52:19 BNCatDIGISHELL has quit (Read error: Connection reset by peer)
1379 2013-03-06 14:53:30 BNCatDIGISHELL has joined
1380 2013-03-06 14:54:20 t7 has quit (Quit: Leaving)
1381 2013-03-06 14:55:28 bitit has quit (Remote host closed the connection)
1382 2013-03-06 14:58:25 LargoG has quit (Ping timeout: 276 seconds)
1383 2013-03-06 14:59:56 chmod755 is now known as rofl!~chmod755@unaffiliated/chmod755|chmod755
1384 2013-03-06 14:59:57 LargoG has joined
1385 2013-03-06 15:06:25 bitit has joined
1386 2013-03-06 15:09:10 [\\\] has quit ()
1387 2013-03-06 15:10:17 CodeShark has quit (Remote host closed the connection)
1388 2013-03-06 15:10:55 CaptainBlaze has joined
1389 2013-03-06 15:17:17 hydrogenesis is now known as oxygenerator
1390 2013-03-06 15:18:24 PhantomSpark has joined
1391 2013-03-06 15:19:38 PhantomSpark has quit (Read error: Connection reset by peer)
1392 2013-03-06 15:20:25 rdymac has joined
1393 2013-03-06 15:22:47 oxygenerator has quit (Quit: Colloquy for iPad - http://colloquy.mobi)
1394 2013-03-06 15:23:42 hydrogenesis has joined
1395 2013-03-06 15:24:04 grau has quit (Remote host closed the connection)
1396 2013-03-06 15:29:52 hydrogenesis has quit (Quit: Colloquy for iPad - http://colloquy.mobi)
1397 2013-03-06 15:31:26 denisx has joined
1398 2013-03-06 15:31:58 swappermall has joined
1399 2013-03-06 15:32:52 andytoshi has quit (Ping timeout: 276 seconds)
1400 2013-03-06 15:41:46 torsthaldo has joined
1401 2013-03-06 15:43:07 <Diablo-D3> [08:56:17] <Luke-Jr> TD: block size shouldn't be increased, miners should start filtering out flooding like they're supposed to
1402 2013-03-06 15:43:10 <Diablo-D3> btw, I agree with this
1403 2013-03-06 15:43:15 t7 has joined
1404 2013-03-06 15:43:28 <Diablo-D3> do the entire block as tx sorted for fee/kb
1405 2013-03-06 15:43:33 <TD> it's something on which reasonable people can disagree
1406 2013-03-06 15:43:49 <Diablo-D3> but we don't have enough traffic to drown out SD
1407 2013-03-06 15:44:04 <Diablo-D3> but theres NO reason why a non-SD tx should ever not make it
1408 2013-03-06 15:46:12 vigilyn2 has quit (Read error: Connection reset by peer)
1409 2013-03-06 15:46:23 vigilyn2 has joined
1410 2013-03-06 15:46:24 <petertodd> If you pay 0.0005BTC in fees per KiB, you're transactions make it into the next block something like 95% of the time.
1411 2013-03-06 15:46:39 <petertodd> (with a min 0.0005BTC fee per tx)
1412 2013-03-06 15:46:41 <MC1984> sd has a right to transaction just by virture of making valid txns
1413 2013-03-06 15:46:52 <MC1984> the only response to sd is to absorb it
1414 2013-03-06 15:47:14 <petertodd> It's a non-issue, and with 1MB blocks we're limited to relatively sane blockchain growth.
1415 2013-03-06 15:47:15 <MC1984> if that means miners making them pay way more, fine
1416 2013-03-06 15:47:21 gems has joined
1417 2013-03-06 15:48:17 <Luke-Jr> MC1984: no
1418 2013-03-06 15:49:03 * gavinandresen resists the urge to talk about max block size⦠must⦠get⦠work⦠done....
1419 2013-03-06 15:49:21 <MC1984> your attitude to sd is extreme, and i think it just as well you cant stop them beyond what you do with eligius
1420 2013-03-06 15:50:13 <petertodd> Diablo-D3: I've got a timestamper running run now that is doing maybe a tx or two an hour, each with a 5mBTC fee; I'll add the logging required to record how long it takes those tx's to get included in a block, but looking at what logs I do have they seem to be included in the next block created about 95% of the time.
1421 2013-03-06 15:50:22 <MC1984> sd is smalltime, and theyre not even TRYING to attack the network. If bitcoin cant absorb it, whats gonna happen when someone DOES really try
1422 2013-03-06 15:50:40 <Diablo-D3> petertodd: yeah, because we don't make enough traffic to push SD out
1423 2013-03-06 15:50:47 <Diablo-D3> petertodd: or anything small, including yours
1424 2013-03-06 15:50:57 <Diablo-D3> if we ran the worlds economy, your TX would NEVER make it in
1425 2013-03-06 15:51:05 <BlueMatt> gavinandresen: seems like thats all anyone wants to talk about these days...
1426 2013-03-06 15:51:19 <petertodd> Diablo-D3: Exactly, and I'd be forced to write the code to put it in coinbases like should be done.
1427 2013-03-06 15:51:28 <petertodd> Diablo-D3: And SD would be forced to do something saner.
1428 2013-03-06 15:51:36 <SomeoneWeird> <MC1984> your attitude to sd is extreme, and i think it just as well you cant stop them beyond what you do with eligius < +1
1429 2013-03-06 15:51:46 comboy has quit (Ping timeout: 264 seconds)
1430 2013-03-06 15:51:54 <Diablo-D3> petertodd: the sane thing for SD is to close shop
1431 2013-03-06 15:52:11 <TD> i think we should limit the size of irc chats, with a prioritization algorithm that demotes any line with the word "block" and "size" in it :)
1432 2013-03-06 15:52:45 <SomeoneWeird> lol.
1433 2013-03-06 15:52:46 _dr has joined
1434 2013-03-06 15:52:53 <gavinandresen> TD: I STRONGLY DISAGREE! THERE SHOULD BE NO LIMIT! EACH IRC CLIENT SHOULD DETERMINE THE LIMIT THEMSELVES!
1435 2013-03-06 15:53:04 <Luke-Jr> MC1984: practical evidence suggests SD *is* trying to attack the network
1436 2013-03-06 15:53:05 <SomeoneWeird> lollll
1437 2013-03-06 15:53:29 <petertodd> gavinandresen: You laugh, but that's a big part of how Freenet chat solutions work...
1438 2013-03-06 15:53:34 <Graet> lol gavinandresen
1439 2013-03-06 15:53:37 CaptainBlaze has quit (Quit: CaptainBlaze)
1440 2013-03-06 15:53:53 _dr has quit (Client Quit)
1441 2013-03-06 15:54:01 <petertodd> Luke-Jr: SD is just my long-term effort to force the blocksize to stay at 1MB and make everyone use my off-chain tx solutions.
1442 2013-03-06 15:54:06 <gavinandresen> petertodd: interesting. I don't know nuthing about freenet, except that it hasn't been successful for some reason
1443 2013-03-06 15:54:13 <BlueMatt> TD: no, we should use a proof of work system to determine the amount you can post
1444 2013-03-06 15:54:29 <BlueMatt> (the higher your target diff, the bigger your block can be
1445 2013-03-06 15:54:44 <Luke-Jr> BlueMatt: can we do proof-of-given-it-enough-thought?
1446 2013-03-06 15:54:46 theorb has joined
1447 2013-03-06 15:54:53 theorbtwo has quit (Ping timeout: 264 seconds)
1448 2013-03-06 15:54:57 <BlueMatt> Luke-Jr: sure, why not?
1449 2013-03-06 15:55:08 theorb is now known as theorbtwo
1450 2013-03-06 15:55:12 <yebyen> i tried a bitcoin blockchain with reduced difficulty (testnet-box) last night and i finally did get it down below 0.0001
1451 2013-03-06 15:55:16 <Luke-Jr> BlueMatt: well, one reason would be if there's trouble coming up with an algorithm
1452 2013-03-06 15:55:17 <Scrat> more miners need to block SD
1453 2013-03-06 15:55:22 <petertodd> gavinandresen: People keep thinking it's unsuccessful, but last time I ran a Freenet node on a decent 'net connection it was pushing hundreds of GB per month of data, so someone is using it for something, if only to flood it.
1454 2013-03-06 15:55:37 <petertodd> gavinandresen: We probably just aren't in the right community to know what content is on there...
1455 2013-03-06 15:55:50 <Luke-Jr> petertodd: it would be pretty funny if 100% of freenet was flooders trying to flood each other out more
1456 2013-03-06 15:55:50 <BlueMatt> Luke-Jr: well, while were making up crap, we can do anything!
1457 2013-03-06 15:55:57 gems has quit (Ping timeout: 245 seconds)
1458 2013-03-06 15:55:58 <Luke-Jr> BlueMatt: we're*
1459 2013-03-06 15:56:01 <MC1984> Luke-Jr thre is no evidence
1460 2013-03-06 15:56:09 <yebyen> but today when I ran the build I left compiling overnight, to set the target lower, I corrupted my blockindex, invalidated my blocks, and couldn't generate another without having difficulty 1.0
1461 2013-03-06 15:56:15 <MC1984> the most you can say is that they really dont give a fuck
1462 2013-03-06 15:56:26 <yebyen> i'm hoping it's some weirdness with how debian/rules applies or does not apply patches
1463 2013-03-06 15:56:28 <petertodd> Luke-Jr: It could be. I just don't know and didn't care enough to delve into the depths to find out what was going on - I didn't want to know too.
1464 2013-03-06 15:56:30 <gavinandresen> petertodd: maybe that's true, and they're solving a problem that I don't have or don't care about (or disapprove of)
1465 2013-03-06 15:56:56 <petertodd> gavinandresen: Yes, truly censoship free data distribution can be used for many things.
1466 2013-03-06 15:57:23 <petertodd> gavinandresen: As can truly censorship free value...
1467 2013-03-06 15:57:46 <gavinandresen> petertodd: what would you think of a max block size set so a crappy broadband user of today could still validate and mine everything, with a limit set to increase by 20% a year (the approximate rate of bandwidth increase these days) ?
1468 2013-03-06 15:57:52 <yebyen> this is the first project that compelled me to want to learn more about building debs
1469 2013-03-06 15:57:53 <HM> [15:53] <petertodd> Luke-Jr: SD is just my long-term effort to force the blocksize to stay at 1MB and make everyone use my off-chain tx solutions. <-- lol
1470 2013-03-06 15:58:28 <petertodd> gavinandresen: In theory, if you could make long-term predictions about how bandwidth will actually increase, I would support that. But until then, it has to be something that *stops* increasing some time in the future.
1471 2013-03-06 15:58:29 <Luke-Jr> gavinandresen: you get bandwidth increases? O.o
1472 2013-03-06 15:58:46 <BlueMatt> gavinandresen: so much for getting work done
1473 2013-03-06 15:58:54 <petertodd> gavinandresen: ...and it has to be backed up by some carefully thought out analysis of the technology of why bandwidth is increasing.
1474 2013-03-06 15:59:06 <MC1984> so gavinandresen posits something similar to what i was (badly) trying to explain yesterday and everyone is interested
1475 2013-03-06 15:59:17 <gavinandresen> petertodd: why? You're acting like once changed, it could NEVER EVER be changed again.
1476 2013-03-06 15:59:19 <HM> gavinandresen: i think the bandwidth (rate) is becoming increasingly irrelevant. my ISP offers 100 Mbps connections but the transfer allowance (GB's) is awful and they have weird traffic shaping and time based throttling
1477 2013-03-06 15:59:35 <petertodd> gavinandresen: But that's it, I'm probably right if we set it too high, and centralization happens.
1478 2013-03-06 15:59:35 <BlueMatt> MC1984: people have been talking about exactly what gavinandresen just said for weeks...probably months
1479 2013-03-06 15:59:39 <BlueMatt> MC1984: actually, years
1480 2013-03-06 15:59:49 <MC1984> NO MY IDEA
1481 2013-03-06 15:59:53 <yebyen> https://github.com/yebyen/testnet-debian
1482 2013-03-06 16:00:15 * Luke-Jr disappears
1483 2013-03-06 16:00:27 <yebyen> the instructions are wrong, the goal is not particularly clear, and I've only provided binaries for armhf
1484 2013-03-06 16:00:30 <yebyen> enjoy!
1485 2013-03-06 16:00:52 <yebyen> also the one that says 'has all the patches' may not really have all the patches.
1486 2013-03-06 16:01:00 <MC1984> increase @ 20% year or whatever and stop at the point to resonably support a reasonable amount of economic activity for the projected peak population of earth
1487 2013-03-06 16:01:01 D34TH_ has joined
1488 2013-03-06 16:01:03 <MC1984> within reason
1489 2013-03-06 16:01:09 D34TH has quit (Read error: Connection reset by peer)
1490 2013-03-06 16:01:41 FredEE has joined
1491 2013-03-06 16:02:03 <HM> in a decade we'll all have 10 Gbps connections but they'll be charging by the webpage
1492 2013-03-06 16:02:06 * HM is a cynic
1493 2013-03-06 16:02:21 <gavinandresen> petertodd: ok. So how long will it take you to do the careful analysis of where bandwidth will top out, and get consensus on that? That sounds like angels-dancing-on-the-head-of-a-pin to me, we can't predict the future
1494 2013-03-06 16:02:22 comboy has joined
1495 2013-03-06 16:02:38 <petertodd> gavinandresen: BTW, I did do a physics based extrapolation on the size of an optimal UTXO set/freenet node hardware implementation, and came up with a rough number of 70m^2 for the 44PB max UTXO limit. Basically a massive chunk of silicon holding storage and CPU's for UTXO validation.
1496 2013-03-06 16:03:19 <gavinandresen> okey dokey.
1497 2013-03-06 16:03:19 <jgarzik> sipa: thanks
1498 2013-03-06 16:03:25 bitit has quit (Ping timeout: 276 seconds)
1499 2013-03-06 16:03:26 <petertodd> gavinandresen: I'll give it a go, but I suspect the real issue is what will drive bandwidth increases, rather than what the tech can do. Can we assume 10x HD streams constantly to each home?
1500 2013-03-06 16:03:37 vampireb has joined
1501 2013-03-06 16:03:39 <petertodd> gavinandresen: Unless you know of any future holodeck technology...
1502 2013-03-06 16:03:53 <gavinandresen> petertodd: I think we can assume that people who want to validate the entire chain will be willing to give up some of their HD streams.
1503 2013-03-06 16:04:21 <petertodd> gavinandresen: Exactly, and we can assume that ISP's still be sizing connections, and importantly bandwidth limits, based on that.
1504 2013-03-06 16:04:27 <gavinandresen> petertodd: ⦠and, again, I think we would be idiots if we bet against technology getting ever better.
1505 2013-03-06 16:04:48 <petertodd> gavinandresen: ...and again, I think we would be idiots if we bet that technology will keep getting better.
1506 2013-03-06 16:04:59 <jgarzik> for a fee burning TX,
1507 2013-03-06 16:05:06 <jgarzik> I guess a zero-value output is required
1508 2013-03-06 16:05:11 <gavinandresen> ⦠and I REALLY think that having fully-validating every-single-transaction nodes be restricted to server closests is Just Fine.
1509 2013-03-06 16:05:13 <petertodd> gavinandresen: Remember, I work in a field that *has* stagnated.
1510 2013-03-06 16:05:19 <jgarzik> what should that output look like? it must be prunable.
1511 2013-03-06 16:05:33 <HM> petertodd: what field?
1512 2013-03-06 16:05:36 <BlueMatt> petertodd: I think we're wasting our time going around in circles saying the same arguments about block size increases and such for days and days :)
1513 2013-03-06 16:05:42 <gavinandresen> (bloom filters and validating transactions that are relevant to ME is plenty, in my humble opinion)
1514 2013-03-06 16:05:45 <petertodd> gavinandresen: If we commit to inflation proofs before then, yes, I could be convinced that's ok.
1515 2013-03-06 16:05:57 <petertodd> HM: analog electronics
1516 2013-03-06 16:06:03 deantrade has joined
1517 2013-03-06 16:06:05 <gavinandresen> what does "commit to inflation proofs" mean?
1518 2013-03-06 16:06:28 <HM> petertodd: at least you can construct a butterworth filter in your sleep
1519 2013-03-06 16:06:37 <gavinandresen> BlueMatt: I agree re: going around in circles. WHich is why I'm trying to find a reasonable compromise that doesn't freak people out.
1520 2013-03-06 16:06:47 <MC1984> can you assume that the internet will always easilycheaply allow an endpoint node in someones house to directly connect to another
1521 2013-03-06 16:06:48 <BlueMatt> gavinandresen: I believe, spv nodes can verify a miner isnt overpaying themselves
1522 2013-03-06 16:07:03 <petertodd> gavinandresen: Have a way that's implemented where you can prove inflation fraud is being done, best way I know of is UTXO merkle sum trees, but I wish someone would come up with a way that isn't so complex; might not be possible.
1523 2013-03-06 16:07:12 <muhoo> $48? really? BTC: the new pre-IPO dot com stock
1524 2013-03-06 16:07:37 <petertodd> HM: ...and cry myself to sleep because my cutting edge designs all have 10 year old parts in them...
1525 2013-03-06 16:07:50 <gavinandresen> petertodd: yeah yeah yeah, assume that is done
1526 2013-03-06 16:07:52 da2ce7_d has joined
1527 2013-03-06 16:07:56 <HM> petertodd: i did an EE degree and wish I'd just stuck to CS
1528 2013-03-06 16:07:57 <deantrade> muhoo: BTC is better than dollars, if it replaces dollars, it would be more than $148,000 per bitcoin of todays USD purchasing power
1529 2013-03-06 16:08:14 bitit has joined
1530 2013-03-06 16:08:15 <BlueMatt> deantrade: so what?
1531 2013-03-06 16:08:20 defunctzombie_zz is now known as defunctzombie
1532 2013-03-06 16:08:23 <petertodd> gavinandresen: Good, and UTXO merkle sum trees are a requiset for my banking stuff too anyway.
1533 2013-03-06 16:08:38 <deantrade> So I think I'm feeding trolls, sorry!
1534 2013-03-06 16:08:58 <BlueMatt> deantrade: there are 10^8 (IIRC) satoshi per btc, so even at worst, you can make pennys
1535 2013-03-06 16:09:30 <deantrade> Oh, I wasn't saying it was a problem. I was saying that $48 is not unreasonable
1536 2013-03-06 16:09:51 <HM> petertodd: i'm somewhere on the systems programmer / systems design region of the spectrum. The stuff you're into made me hate my degree
1537 2013-03-06 16:09:51 da2ce7 has quit (Ping timeout: 256 seconds)
1538 2013-03-06 16:09:59 <BlueMatt> deantrade: oh, heh...yea, Im not used to discussing price here
1539 2013-03-06 16:10:40 <petertodd> HM: Aw, too bad, I love working with hardware - something really awsome about how utterly physical analog is. I mean, I have stuff where just tapping the cables causes enough electrons to move around to screw up the results.
1540 2013-03-06 16:11:12 <petertodd> HM: (I'm deep in the "black magic" side of analog)
1541 2013-03-06 16:11:15 <HM> my 3rd year electronics project malfunctioned if you put your hand 3 inches above the board
1542 2013-03-06 16:11:26 <deantrade> By the way, does anyone have any links to news on the recent increase in market acceptance of bitcoin (so I can get an idea of the cause of its price increase)?
1543 2013-03-06 16:11:33 <HM> hurray for analog electronics
1544 2013-03-06 16:11:41 <petertodd> HM: Yes! It's wonderful, and yet you can go from that, to utterly robust with some subtle changes...
1545 2013-03-06 16:11:45 <BlueMatt> deantrade: ask on #bitcoin or #bitcoin-otc
1546 2013-03-06 16:12:01 <deantrade> BlueMatt: thanks!
1547 2013-03-06 16:12:04 <HM> petertodd: maybe. I just moved it to the back of the table :P
1548 2013-03-06 16:12:17 <HM> robust is for production. working is for getting grades
1549 2013-03-06 16:13:03 <petertodd> HM: Heh, that attitude is why even though in many respects I'm a shitty EE - I suck at the math - I can still be useful and make good designs.
1550 2013-03-06 16:13:10 <HM> in the first year i made a capacitance meter that worked, except i never had time to finish the output scaling. so you needed a calculator to work out what it said
1551 2013-03-06 16:13:18 <petertodd> HM: Nice
1552 2013-03-06 16:13:18 <HM> stuff like that is 3 lines of code -_-
1553 2013-03-06 16:13:39 <HM> crap -> ADC -> code! huzaah!
1554 2013-03-06 16:14:01 <petertodd> HM: Yeah, I've done power supply designs that had 50 parts that could have been replaced by a uC, on the other hand, they were far more robust.
1555 2013-03-06 16:14:02 <muhoo> deantrade: BlueMatt : tho i do have to ask, if the price keeps going up, will the fees stay the same?
1556 2013-03-06 16:14:45 <petertodd> Anyway, I gotta go to work, later.
1557 2013-03-06 16:14:53 <muhoo> mining would be insanely lucrative at like US$200 per tx fee, or something
1558 2013-03-06 16:15:30 <muhoo> also, using btc for buying a pack of gum, or a digital song download, would be impractical
1559 2013-03-06 16:16:39 <jgarzik> Drat, petertodd just left
1560 2013-03-06 16:16:46 <muhoo> but, i suppose that's OT too
1561 2013-03-06 16:16:48 <jgarzik> Asking again... what is the preferred way to burn bitcoins?
1562 2013-03-06 16:16:54 <jgarzik> cannot do a zero-vout
1563 2013-03-06 16:17:10 <jgarzik> so presumably that's a zero-value output, that is instantly prunable/spendable
1564 2013-03-06 16:17:36 <HM> just send them to a wallet and discard the address?
1565 2013-03-06 16:17:42 <HM> or do you need provable discarded?
1566 2013-03-06 16:17:47 <gavinandresen> jgarzik: I'd say send-to-self with large fee, small-but-non-zero output.
1567 2013-03-06 16:17:59 <HM> ooo nice
1568 2013-03-06 16:18:19 <jgarzik> I suppose
1569 2013-03-06 16:18:21 <gavinandresen> jgarzik: ⦠ideally combining several inputs so you decrease the vout set size
1570 2013-03-06 16:18:28 <jgarzik> would prefer a zero-value, anyone-can-spend output
1571 2013-03-06 16:18:36 <jgarzik> so that additional funds is not necessary
1572 2013-03-06 16:18:54 <jgarzik> but yeah, send-to-self works
1573 2013-03-06 16:19:01 <Diablo-D3> hey
1574 2013-03-06 16:19:01 <gavinandresen> jgarzik: mmm. Well, make it a SIGHASH_NONE and it should get spent soon.
1575 2013-03-06 16:19:03 <jgarzik> *are not
1576 2013-03-06 16:19:08 <Diablo-D3> whats the name of that one block chain watcher dameon
1577 2013-03-06 16:19:18 <Diablo-D3> the one that spits out events over socket or whatever
1578 2013-03-06 16:19:29 <gavinandresen> ⦠although that incentivizes a double-spend-flood as everybody smart enough to recognize they can spend it tries to spend it
1579 2013-03-06 16:19:32 <jgarzik> basically, need people to provide proof they burned a tiny bit of money
1580 2013-03-06 16:19:54 <jgarzik> <shrug> people can race to spend zero bitcoins all they want :)
1581 2013-03-06 16:19:58 <gavinandresen> Actually, the double-spend flood shouldn't be too bad
1582 2013-03-06 16:20:06 <jgarzik> I imagine only geeks and people wanting to clean UTXO would bother
1583 2013-03-06 16:20:15 <HM> what about a multisig transaction where one public key was generated from a hash of something else? everyone could see you've generated a key which, in all likelihood, you do not have the private key for
1584 2013-03-06 16:20:23 <jgarzik> hrm, zero value outputs are non-standard though
1585 2013-03-06 16:20:29 <gavinandresen> can't be zero-value, that's not a standard transaction
1586 2013-03-06 16:20:40 <gavinandresen> how small an amount we talking?
1587 2013-03-06 16:20:51 mogri has joined
1588 2013-03-06 16:20:57 <mogri> hi
1589 2013-03-06 16:21:01 <jgarzik> gavinandresen: 0.0001 BTC or thereabouts
1590 2013-03-06 16:21:14 <jgarzik> gavinandresen: a small fee for message processing, sent to <any miner>
1591 2013-03-06 16:21:19 <jgarzik> gavinandresen: as proof of funds spent
1592 2013-03-06 16:21:34 <mogri> so, i've heard about magical daemons which monitor the blockchain and then broadcast events to consumers
1593 2013-03-06 16:21:37 bitit has quit (Ping timeout: 276 seconds)
1594 2013-03-06 16:21:37 darkee has quit (!~darkee@gateway/tor-sasl/darkee|Ping timeout: 276 seconds)
1595 2013-03-06 16:21:38 MobiusL has quit (Ping timeout: 276 seconds)
1596 2013-03-06 16:21:47 <mogri> are these real or is it just another pile of Diablo-D3 bullshit
1597 2013-03-06 16:21:52 <muhoo> mogri: the blockchain api?
1598 2013-03-06 16:22:10 <gavinandresen> jgarzik: mmm⦠piggybacking on some other transaction would be the best way currently
1599 2013-03-06 16:22:27 <muhoo> mogri: also, there are event callbacks in bitcoind
1600 2013-03-06 16:22:32 hydrogenesis has joined
1601 2013-03-06 16:22:47 <mogri> we're looking for an IPN-like solution obviously
1602 2013-03-06 16:22:59 <mogri> we want to notify our webapp when it has been paid
1603 2013-03-06 16:23:11 <gavinandresen> mogri: there were services that did that, not sure if they're still around.
1604 2013-03-06 16:23:20 <mogri> since, you know, paying someone to sit there and watch bitcoin-qt all the time
1605 2013-03-06 16:23:26 <Diablo-D3> gavinandresen: someone was working on a daemon that spit out events over socket
1606 2013-03-06 16:23:28 <mogri> is really not something i want to pay someone to do
1607 2013-03-06 16:23:29 <mogri> ;p
1608 2013-03-06 16:23:30 <Diablo-D3> but I can't remember the name
1609 2013-03-06 16:23:41 <Diablo-D3> mogri: you wouldn't use bitcoin-qt anyhow, you'd use bitcoind
1610 2013-03-06 16:23:55 <mogri> yes, i know that
1611 2013-03-06 16:23:58 <Diablo-D3> but querying bitcoind over the json roc for that is not the optimal solution
1612 2013-03-06 16:24:02 <Diablo-D3> rpc
1613 2013-03-06 16:24:03 <mogri> yes
1614 2013-03-06 16:24:04 rdymac has quit (Quit: This computer has gone to sleep)
1615 2013-03-06 16:24:09 <mogri> i want bitcoind to tell me things
1616 2013-03-06 16:24:19 PhantomSpark has joined
1617 2013-03-06 16:24:21 <muhoo> mogri: use the callback
1618 2013-03-06 16:24:23 <Diablo-D3> yes, and it doesn't have push notification yet which is what you want
1619 2013-03-06 16:24:32 <Diablo-D3> muhoo: thats not in stable yet
1620 2013-03-06 16:24:34 <gavinandresen> mogri: https://en.bitcoin.it/wiki/BitcoinNotify
1621 2013-03-06 16:25:06 <gavinandresen> ⦠which is out of business, but that page has good links to other services which may or may not still be working
1622 2013-03-06 16:25:18 <mogri> running bitcoind is fine
1623 2013-03-06 16:25:28 <BlueMatt> muhoo: fees are up to miners,
1624 2013-03-06 16:25:35 <mogri> we need to anyway, as we want to use single-use addresses for each invoice
1625 2013-03-06 16:25:45 <BlueMatt> jgarzik: something with an OP_RETURN at the beginning, Id say
1626 2013-03-06 16:25:47 PhantomSpark has quit (2!~kvirc@pool-71-251-16-105.nycmny.fios.verizon.net|Read error: Connection reset by peer)
1627 2013-03-06 16:26:02 <Scrat> gavinandresen: all of which are "best effort" services or some BS like that
1628 2013-03-06 16:26:02 <BlueMatt> jgarzik: I think that is the consensus of how-we-would-purge-unspendable-coins-if-we-did-it
1629 2013-03-06 16:26:03 <jgarzik> BlueMatt: agreed, but sadly non-standard
1630 2013-03-06 16:26:06 <Scrat> b.i im looking at you
1631 2013-03-06 16:26:34 <Scrat> mogri: walletnotify is a great solution which works for me (albeit a bit modified)
1632 2013-03-06 16:27:00 <Raccoon> FYI: CNN Article just hit 20 minutes ago. http://money.cnn.com/2013/03/06/technology/innovation/bitcoin/
1633 2013-03-06 16:27:00 <mogri> walletnotify is the bitcoind thing?
1634 2013-03-06 16:27:15 <Scrat> mogri: this https://github.com/bitcoin/bitcoin/pull/1974
1635 2013-03-06 16:27:30 JDuke128 has quit (Quit: [BB])
1636 2013-03-06 16:27:32 <Scrat> you need a transaction DB in order to use it effectively
1637 2013-03-06 16:27:40 <mogri> bleah
1638 2013-03-06 16:27:55 <mogri> so, this callback thing in bitcoin git
1639 2013-03-06 16:28:22 <mogri> any docs on it ?
1640 2013-03-06 16:28:28 <gavinandresen> yes, -walletnotify="command to run when a transaction hits your wallet"
1641 2013-03-06 16:28:35 <gavinandresen> :)
1642 2013-03-06 16:28:47 <Diablo-D3> gavinandresen: wait, thats in 0.8.0?
1643 2013-03-06 16:29:22 <BlueMatt> wow...cnn actually got the "crash" right, "it went from under $1 to over $28, then back to $7 in 2011 alone." note the lack of mention of any crashes to a penny
1644 2013-03-06 16:30:00 <mogri> since i'm having to modify bitcoin anyway to make it compile with uclibc
1645 2013-03-06 16:30:26 <mogri> would you guys like a JSON post-back mechanism ?
1646 2013-03-06 16:30:45 <mogri> i'm not keen on uhm
1647 2013-03-06 16:30:52 <Scrat> walletnotify will trigger on 3 occasions, so you have to keep that in mind: mempool / block inclusion / outgoing tx
1648 2013-03-06 16:30:55 <mogri> running external scripts
1649 2013-03-06 16:31:40 <gavinandresen> Scrat: you've been using -walletnotify ? Happy with it ?
1650 2013-03-06 16:32:41 Guest4210 has joined
1651 2013-03-06 16:32:46 <Scrat> gavinandresen: using this http://pastebin.com/60ujKcrT which is kinda the same thing (i'm watching the directory for changes)
1652 2013-03-06 16:32:47 <gavinandresen> mogri: I wrote a patch a long time ago that did HTTP-JSON-RPC postbacks, but wasn't happy with itâ¦
1653 2013-03-06 16:32:49 <Scrat> and I'm very happy with it
1654 2013-03-06 16:33:27 <gavinandresen> mogri: ⦠mostly because I could see the gazillion features "we" would want to add over time, and I don't like feature-creep
1655 2013-03-06 16:33:48 <gavinandresen> Scrat: ⦠can I cajole you to write up a little wiki page documenting it ?
1656 2013-03-06 16:34:44 PhantomSpark has quit (Read error: Connection reset by peer)
1657 2013-03-06 16:35:06 tyn has quit (Ping timeout: 245 seconds)
1658 2013-03-06 16:35:14 <Scrat> gavinandresen: you mean walletnotify as it is in 0.8 ? I'll see what I can do
1659 2013-03-06 16:35:27 <mogri> hmm
1660 2013-03-06 16:35:29 <gavinandresen> Scrat: yes, as it is in git HEAD
1661 2013-03-06 16:36:00 darkee has joined
1662 2013-03-06 16:36:27 <mogri> bitcoinmonitor seems reasonable
1663 2013-03-06 16:36:38 <mogri> maybe i should just write a tool to create bitcoin keypairs
1664 2013-03-06 16:36:46 <mogri> and not bother with running bitcoind
1665 2013-03-06 16:36:58 <mogri> would that be useful to you guys? a standalone address generator?
1666 2013-03-06 16:37:17 <weex> mogri: there are several tools like that
1667 2013-03-06 16:37:19 toffoo has joined
1668 2013-03-06 16:37:27 <weex> bitaddress.org, github.com/weex/addrgen
1669 2013-03-06 16:37:40 <mogri> weex, cool. you already did my work for me :P
1670 2013-03-06 16:37:51 zooko` is now known as zooko
1671 2013-03-06 16:38:08 PhantomSpark has joined
1672 2013-03-06 16:38:24 <Scrat> gavinandresen: a big problem I see with it is that if it triggers while your backend is down you will lose that tx, so you need extra logic for that incident (get the entire block etc, etc), which is why I made it work like the pastebin snippet instead. it's ugly but it works
1673 2013-03-06 16:38:37 <weex> mogri: you'll find a lot has already been done so always good to check here first
1674 2013-03-06 16:40:41 hydrogenesis has quit (Quit: Colloquy for iPad - http://colloquy.mobi)
1675 2013-03-06 16:40:47 <gavinandresen> Scrat: hmmm⦠seems like the notify might could use "tee" to write to (say) a named pipe connected to your backend and a file, in case the backend was down..
1676 2013-03-06 16:41:04 <mogri> weex, so how do you import the keys you made into a bitcoin wallet.dat ?
1677 2013-03-06 16:41:32 denisx has quit (Quit: denisx)
1678 2013-03-06 16:42:27 <weex> importprivkey
1679 2013-03-06 16:42:32 denisx has joined
1680 2013-03-06 16:42:39 <mogri> neat
1681 2013-03-06 16:42:43 <mogri> then, basically
1682 2013-03-06 16:42:57 <mogri> i can just store the keypairs with each invoice
1683 2013-03-06 16:43:02 <mogri> and have a cron to dump them into a wallet
1684 2013-03-06 16:43:10 <Scrat> gavinandresen: yeah this is probably done in a script: curl the app server, check for curl exit code and it failed append the txid to a specified file
1685 2013-03-06 16:43:10 <mogri> or something
1686 2013-03-06 16:43:35 <weex> you can do what you want
1687 2013-03-06 16:43:43 <weex> gotta protect those keys though
1688 2013-03-06 16:43:47 PhantomSpark has quit (Read error: Connection reset by peer)
1689 2013-03-06 16:44:00 <mogri> yeah
1690 2013-03-06 16:44:04 <mogri> obviously :)
1691 2013-03-06 16:44:05 <weex> would be interesting to have the script encrypt the privkey with a gpg and upload elsewhere
1692 2013-03-06 16:44:22 PhantomSpark has joined
1693 2013-03-06 16:44:49 <mogri> weex, or simply AES256 it
1694 2013-03-06 16:45:33 <mogri> too much noise, not enough signal on #bitcoin :P
1695 2013-03-06 16:46:11 <mogri> but yes
1696 2013-03-06 16:46:15 <mogri> i think i have a plan now
1697 2013-03-06 16:46:25 <weex> does aes do asymmetric encryption?
1698 2013-03-06 16:46:29 snakie has quit (Ping timeout: 248 seconds)
1699 2013-03-06 16:46:51 <helo> i don't think so
1700 2013-03-06 16:48:04 <mogri> nice
1701 2013-03-06 16:48:08 <mogri> importprivkey
1702 2013-03-06 16:48:15 <mogri> is an rpc command
1703 2013-03-06 16:48:18 snakie has joined
1704 2013-03-06 16:48:24 <mogri> so, i can just dump my bitcoind on a tor hidden service or some shit
1705 2013-03-06 16:48:47 <mogri> and have it just send the privkey part immediately to that
1706 2013-03-06 16:48:49 <weex> importprivkey does take a while though since it scans the chain
1707 2013-03-06 16:49:02 <mogri> oh, importprivkey cannot be used immediately ?
1708 2013-03-06 16:49:19 <Scrat> it has to rebuild indices
1709 2013-03-06 16:49:25 <weex> you could mod bitcoind to tell it not to scan so far back
1710 2013-03-06 16:49:33 <weex> but that could get tricky
1711 2013-03-06 16:50:42 <mogri> so, would it be cheaper to just have bitcoind generate the keypair?
1712 2013-03-06 16:50:55 <weex> right
1713 2013-03-06 16:51:15 <weex> you can backupwallet and dump with pywallet if you need to do other stuff
1714 2013-03-06 16:51:47 <weex> or maybe use some other services to watch addresses if you like
1715 2013-03-06 16:51:48 zooko has left ("#tahoe-lafs the secure decentralized storage system")
1716 2013-03-06 16:52:05 <mogri> because, what i am thinking is
1717 2013-03-06 16:52:09 ovidiusoft has quit (Read error: Operation timed out)
1718 2013-03-06 16:52:19 <mogri> user clicks "pay with bitcoin", then it gives them a bitcoin address
1719 2013-03-06 16:52:34 <mogri> it registers that with some bitcoinnotify clone
1720 2013-03-06 16:52:55 <mogri> so, i guess even being a tor hidden service it won't be *too* slow
1721 2013-03-06 16:52:58 * mogri hmms
1722 2013-03-06 16:52:59 <muhoo> mogri: also, there's multibitmerchant, and there"s bitpay.com
1723 2013-03-06 16:53:06 <mogri> they charge fees
1724 2013-03-06 16:53:09 <mogri> i'm cheap
1725 2013-03-06 16:53:10 <mogri> ;p
1726 2013-03-06 16:53:33 <mogri> oh
1727 2013-03-06 16:53:38 <mogri> multibitmerchant is some app
1728 2013-03-06 16:53:49 <helo> mogri: you probably don't want to generate your private keys on an internet-connected machine
1729 2013-03-06 16:54:06 <helo> particularly one that is likely to come under persistent attack
1730 2013-03-06 16:54:15 <mogri> yes, our plan there
1731 2013-03-06 16:54:17 <weex> blockchain.info has a nice api but i like independence as well as freedom
1732 2013-03-06 16:54:21 <mogri> is to have another machine
1733 2013-03-06 16:54:25 <mogri> connected via tor
1734 2013-03-06 16:54:30 <mogri> and otherwise firewalled out
1735 2013-03-06 16:55:49 <muhoo> helo: but you have to get the public keys over to your webserver somehow, presumably over the internet
1736 2013-03-06 16:56:26 <mogri> another option could be to generate say
1737 2013-03-06 16:56:28 <mogri> 10000 keys
1738 2013-03-06 16:56:30 Lolcust has quit (Ping timeout: 255 seconds)
1739 2013-03-06 16:56:38 <mogri> and then they're just ready to go
1740 2013-03-06 16:56:41 <mogri> :P
1741 2013-03-06 16:57:19 Lolcust has joined
1742 2013-03-06 16:57:36 bitafterbit has joined
1743 2013-03-06 16:57:46 <muhoo> and a warning from your server when it runs out of keys
1744 2013-03-06 16:58:09 <mogri> yeah
1745 2013-03-06 16:58:14 <mogri> just prime it with more every few months
1746 2013-03-06 16:58:59 <weex> another way to manage risk is send any btc over a threshold off-server
1747 2013-03-06 16:59:19 <muhoo> i started down the road of writing an ecommerce platform before discovering, 1 i don't eeally need one, and 2 if i did, multibitmerchant has it
1748 2013-03-06 17:03:38 rdymac has joined
1749 2013-03-06 17:06:15 Guest4210 has quit (Quit: Page closed)
1750 2013-03-06 17:06:49 * helo wonders how the oracle db guy is doing
1751 2013-03-06 17:07:17 <weex> helo: was the more than just some irc talk?
1752 2013-03-06 17:09:09 JZavala has joined
1753 2013-03-06 17:09:40 <helo> weex: not sure... i think he's still here.
1754 2013-03-06 17:10:31 <helo> nOgAnOo: are you working on replacing leveldb with oracle?
1755 2013-03-06 17:10:50 <gmaxwell> lol
1756 2013-03-06 17:12:25 <gmaxwell> helo: IIRC it was "fatAgnes" that was all 'lol you guys are incompetent because you're not using my ENTERPRIZE DATABASE', but there was no indication that he was going to actually try doing anything.
1757 2013-03-06 17:12:58 PiZZaMaN2K has joined
1758 2013-03-06 17:14:01 imsaguy is now known as notimsaguy
1759 2013-03-06 17:14:16 notimsaguy is now known as imsaguy
1760 2013-03-06 17:15:12 <helo> someone mentioned something in the last few days about oracle that made me think they were going to try. i don't think it was fatAgnes, but yes he was the one whining.
1761 2013-03-06 17:16:13 PiZZaMaN2K has quit (Changing host)
1762 2013-03-06 17:16:13 PiZZaMaN2K has joined
1763 2013-03-06 17:24:31 ashams has joined
1764 2013-03-06 17:24:31 ashams has quit (Changing host)
1765 2013-03-06 17:24:31 ashams has joined
1766 2013-03-06 17:24:48 aBs0lut30 has joined
1767 2013-03-06 17:26:06 <aBs0lut30> hey guys, I am working on something and need some suggestions on clients/api's to use... the main thing I need is the ability to read comments on incoming transactions and add comments to outgoing transactions, from what I can tell bitcoind lets you add comments on the outgoing side, dont see anything for inbound... is that something it can do, or is there something better to use?
1768 2013-03-06 17:29:13 denisx has quit (Quit: denisx)
1769 2013-03-06 17:35:49 ielo has joined
1770 2013-03-06 17:37:25 deantrade has left ()
1771 2013-03-06 17:37:33 torsthaldo has quit (Remote host closed the connection)
1772 2013-03-06 17:38:09 <sipa> aBs0lut30: transactions don't have comments
1773 2013-03-06 17:38:22 <sipa> aBs0lut30: comments only exist inside a wallet, locally
1774 2013-03-06 17:40:09 AtashiCon has joined
1775 2013-03-06 17:40:59 <gmaxwell> Conversation in #bitcoin reveals that aBs0lut30 is asking because he wants to distinguish customers who are paying him from each other.
1776 2013-03-06 17:42:03 freakazoid has joined
1777 2013-03-06 17:42:16 <Raccoon> -->> CNN Money Reporting on Bitcoin Today, http://money.cnn.com/2013/03/06/technology/innovation/bitcoin/
1778 2013-03-06 17:43:03 <Raccoon> sorry, wrong chan
1779 2013-03-06 17:43:31 Raccoon has left ()
1780 2013-03-06 17:45:55 MobiusL has joined
1781 2013-03-06 17:55:15 vampireb has quit (Quit: Lost terminal)
1782 2013-03-06 17:57:09 [\\\] has joined
1783 2013-03-06 18:00:48 Grouver has joined
1784 2013-03-06 18:01:59 agath has joined
1785 2013-03-06 18:02:07 torsthaldo has joined
1786 2013-03-06 18:02:08 gjs278 has quit (Read error: Connection reset by peer)
1787 2013-03-06 18:04:18 gjs278 has joined
1788 2013-03-06 18:05:07 <yebyen> huzzah! pumping out testnet blocks with short targets and low difficulty
1789 2013-03-06 18:05:44 JZavala has quit (Ping timeout: 250 seconds)
1790 2013-03-06 18:08:24 Varan has joined
1791 2013-03-06 18:08:57 <yebyen> retargets are at 2016 not 2100, right
1792 2013-03-06 18:09:19 <gmaxwell> right.
1793 2013-03-06 18:12:52 D34TH_ is now known as D34TH
1794 2013-03-06 18:12:59 D34TH has quit (Changing host)
1795 2013-03-06 18:12:59 D34TH has joined
1796 2013-03-06 18:17:09 imsaguy has quit (Remote host closed the connection)
1797 2013-03-06 18:17:41 discrete has quit ()
1798 2013-03-06 18:18:19 JZavala has joined
1799 2013-03-06 18:18:51 rdymac has quit (Quit: This computer has gone to sleep)
1800 2013-03-06 18:20:37 MC1984_ has joined
1801 2013-03-06 18:21:08 MC1984 has quit (Read error: Connection reset by peer)
1802 2013-03-06 18:22:34 JZavala has quit (Ping timeout: 245 seconds)
1803 2013-03-06 18:24:55 FredEE_ has joined
1804 2013-03-06 18:26:25 FredEE has quit (Ping timeout: 276 seconds)
1805 2013-03-06 18:26:26 FredEE_ is now known as FredEE
1806 2013-03-06 18:29:04 ovidiusoft has joined
1807 2013-03-06 18:29:09 pacpac has joined
1808 2013-03-06 18:32:16 jaromil has quit (Ping timeout: 276 seconds)
1809 2013-03-06 18:32:40 aBs0lut30 has quit (Quit: A day without sunshine is like .... night)
1810 2013-03-06 18:35:04 PiZZaMaN2K has quit (Ping timeout: 245 seconds)
1811 2013-03-06 18:35:51 WKNiGHT has joined
1812 2013-03-06 18:42:14 saivann has joined
1813 2013-03-06 18:44:27 TD has quit (Quit: Leaving)
1814 2013-03-06 18:45:32 Varan has quit (Quit: Leaving)
1815 2013-03-06 18:47:27 paraipan has joined
1816 2013-03-06 18:47:30 <MC1984_> is there any way to set a cap on the number on connection you get
1817 2013-03-06 18:47:39 rdymac has joined
1818 2013-03-06 18:49:44 <gmaxwell> -maxconnections=<n> Maintain at most <n> connections to peers (default: 125)
1819 2013-03-06 18:50:04 imsaguy has joined
1820 2013-03-06 18:50:30 pacpac has quit (Ping timeout: 245 seconds)
1821 2013-03-06 18:51:44 denisx has joined
1822 2013-03-06 18:54:40 dvide has joined
1823 2013-03-06 18:57:38 pacpac has joined
1824 2013-03-06 18:58:57 <MC1984_> thanks
1825 2013-03-06 18:59:16 <MC1984_> i might limit to 20 o something to try and keep this machine out of swap
1826 2013-03-06 18:59:58 <gavinandresen> you should limit it to eleven
1827 2013-03-06 19:03:25 <MC1984_> why 11?
1828 2013-03-06 19:04:26 <Scrat> it's his favorite number
1829 2013-03-06 19:04:34 <Scrat> even I know this
1830 2013-03-06 19:04:54 discrete has joined
1831 2013-03-06 19:05:45 <MC1984_> cool whats his favourite colour
1832 2013-03-06 19:06:06 <warren> 11
1833 2013-03-06 19:06:42 <Scrat> #111111
1834 2013-03-06 19:06:47 ProfMac has quit (Ping timeout: 245 seconds)
1835 2013-03-06 19:07:51 <sivu> #caccaa
1836 2013-03-06 19:09:11 <MC1984_> im being trolled gently
1837 2013-03-06 19:09:20 <sivu> slush, awake?
1838 2013-03-06 19:10:05 <MC1984_> i like the idea of being a bro to potential SPV users
1839 2013-03-06 19:12:15 chmod755 is now known as chmod755|catfish
1840 2013-03-06 19:15:01 defunctzombie is now known as defunctzombie_zz
1841 2013-03-06 19:15:05 bock has joined
1842 2013-03-06 19:16:23 <sivu> abe import is...slow
1843 2013-03-06 19:16:24 skeledrew1 has quit (Read error: Connection reset by peer)
1844 2013-03-06 19:18:01 freakazoid has quit (Ping timeout: 245 seconds)
1845 2013-03-06 19:18:28 freakazoid has joined
1846 2013-03-06 19:19:58 [\\\] has quit (Ping timeout: 255 seconds)
1847 2013-03-06 19:20:02 jaromil has joined
1848 2013-03-06 19:24:47 pacpac has quit (Ping timeout: 264 seconds)
1849 2013-03-06 19:24:58 eipeace__ has joined
1850 2013-03-06 19:25:04 Pinion has joined
1851 2013-03-06 19:25:28 Pinion is now known as Guest35660
1852 2013-03-06 19:27:07 <jaromil> jgarzik: question - where do you recommend I would start hacking something that uses libpicocoin to wait and confirm a transaction when it has been signed by enough peers, so when it basically has been done?
1853 2013-03-06 19:28:02 <jaromil> my goal is very simple, I'd like to do something in the form of a cgi that can provide a link to a file once a requested payment has been done.
1854 2013-03-06 19:28:26 <jgarzik> jaromil: brd ("block relay daemon") is an initial attempt at a network node; it knows enough to get on the network and watch for transactions or blocks
1855 2013-03-06 19:28:32 testnode9 has quit (Ping timeout: 276 seconds)
1856 2013-03-06 19:28:42 <jaromil> yea I spotted that
1857 2013-03-06 19:28:48 <jaromil> so it should be it
1858 2013-03-06 19:28:53 <jgarzik> jaromil: not sure what is meant by "signed by enough peers". Does that mean a completed transaction that has all appropriate signatures, and is final?
1859 2013-03-06 19:29:02 <jgarzik> jaromil: or does mean "appears in a block"
1860 2013-03-06 19:29:05 <jgarzik> ?
1861 2013-03-06 19:30:06 <jaromil> that is final
1862 2013-03-06 19:31:14 <jaromil> i'm looking for the simpliest, less invasive way to do something like a pay-to-download thing.
1863 2013-03-06 19:31:34 <jaromil> and I love picocoin's code :)
1864 2013-03-06 19:32:33 <jaromil> so by less invasive I mean that I'd prefer to use an existing API rather than adapt a codebase
1865 2013-03-06 19:34:15 rdymac has quit (Remote host closed the connection)
1866 2013-03-06 19:36:21 owowo has joined
1867 2013-03-06 19:36:24 <gmaxwell> jaromil: "signed by enough peers" sounds like a total misunderstanding of how bitcoin works. Bitcoin transactions are not confirmed by your peers directly, and not by signing transactions.
1868 2013-03-06 19:36:57 <gmaxwell> jaromil: unrelated to your question, but you might want to read http://bitcoin.org/bitcoin.pdf when you have a few minutes sometime
1869 2013-03-06 19:38:45 <gavinandresen> "relayed by enough peers" makes sense.
1870 2013-03-06 19:39:27 <muhoo> using the new SPVBlockStore in bitcoinj, i notice the blockchain downloads twice, or appears to: https://www.refheap.com/paste/12161
1871 2013-03-06 19:39:53 owowo has quit (Remote host closed the connection)
1872 2013-03-06 19:39:58 <muhoo> ah, no, the % done calculation loses it's mind, is all, midway through
1873 2013-03-06 19:40:02 <muhoo> nm, sorry
1874 2013-03-06 19:40:42 owowo has joined
1875 2013-03-06 19:40:44 testnode9 has joined
1876 2013-03-06 19:41:49 <muhoo> its not it's! ga!
1877 2013-03-06 19:42:27 Guest35660 has quit (Ping timeout: 252 seconds)
1878 2013-03-06 19:42:39 beethoven8201 has joined
1879 2013-03-06 19:42:44 <beethoven8201> hi bitcoin-dev
1880 2013-03-06 19:42:54 <beethoven8201> reports of no confirms for an hour for many transactions
1881 2013-03-06 19:43:25 <muhoo> nice! SBVBlockStore => 6MB BOBStore => 55MB
1882 2013-03-06 19:44:12 <jgarzik> jaromil: so you want to wait for a certain # of confirmations?
1883 2013-03-06 19:44:26 <jgarzik> (sorry, had to handle RL for a bit)
1884 2013-03-06 19:44:35 <muhoo> beethoven8201: seen a couple reports on that here. curious why myself. not enough miners? miners starting to demand fees now?
1885 2013-03-06 19:44:55 jaromil has quit (Ping timeout: 252 seconds)
1886 2013-03-06 19:45:03 <gavinandresen> last 7 blocks looks like hit the 250K soft block size limit
1887 2013-03-06 19:45:15 <Grouver> Bitcoin was on one of the main dutch radio stations today. :) For about 15 minutes. :)
1888 2013-03-06 19:45:16 <muhoo> gavinandresen: thanks, that makes a lot of sense
1889 2013-03-06 19:45:47 <beethoven8201> muhoo: gavinandresen what does that mean?
1890 2013-03-06 19:45:53 Nesetalis has quit (Ping timeout: 264 seconds)
1891 2013-03-06 19:45:54 <Grouver> Oh pasted that in the wrong chat. Sorry about that.
1892 2013-03-06 19:46:07 <gavinandresen> ⦠and it looks like SatoshiDice increased the fees they pay to 0.001 BTC ?
1893 2013-03-06 19:46:16 <warren> o_O
1894 2013-03-06 19:46:40 <muhoo> beethoven8201: it means there's a soft limit, set by miners and mining software, on the size of a block, IIRC. so there are more tx'es around than will fit in a block. but it's a soft limit, so presumably they can change their settings and up it
1895 2013-03-06 19:46:43 <gavinandresen> So: go ask your favorite mining pool to pretty-please make their blocks bigger. Or include more fees in your fee-paying transactions.
1896 2013-03-06 19:46:55 SchmalzTech has quit ()
1897 2013-03-06 19:47:24 <sivu> the transactions will eventually get included because of the priority tho?
1898 2013-03-06 19:47:44 <chmod755> catfish!~chmod755@unaffiliated/chmod755|+ ask websites to pay 0.01 BTC or more if possible
1899 2013-03-06 19:48:08 <gavinandresen> sivu: depends on what priority they're starting at, and what other higher-priority transactions are sent
1900 2013-03-06 19:48:12 CodeShark has joined
1901 2013-03-06 19:48:35 <muhoo> this worries me. if the price of BTC keeps escalating, the cost of fees will be more than transactions, making bitcoin impractical for those kinds of items
1902 2013-03-06 19:48:43 <sivu> gavinandresen: but the priority does increase over time right? that's what i understood from the wiki
1903 2013-03-06 19:49:15 <muhoo> which maybe is OK, i don't know how the core devs feel about that. maybe bitcoin becomes just a value store, not something you use to buy, say, song downloads (somethign i'm workign on ATM, so i'm not just idly worrying)
1904 2013-03-06 19:49:21 <gavinandresen> sivu: yes, the priority increases over time, but if you start at a very low priority it could, literally, take YEARS for a transaction to get into a block
1905 2013-03-06 19:49:41 toffoo has quit ()
1906 2013-03-06 19:49:51 <gavinandresen> ⦠assuming that years from now miners are still accepting low-fee high-priority transactions.
1907 2013-03-06 19:50:14 <sivu> ah yes, i didn't check how fast it rises
1908 2013-03-06 19:50:32 <gavinandresen> muhoo: fees are really, really small right now, even with the price run-up.
1909 2013-03-06 19:50:56 <gavinandresen> ⦠and raw bitcoin isn't meant for very-small-value transactions
1910 2013-03-06 19:51:13 <muhoo> gavinandresen: thanks, that's pretty much what i suspected, but good to have it confirmed
1911 2013-03-06 19:51:41 <gavinandresen> beethoven8201: where are you seeing reports of no confirms?
1912 2013-03-06 19:51:48 <jgarzik> gavinandresen: RE soft limit
1913 2013-03-06 19:51:53 <jgarzik> gavinandresen: time to bump it in the codebase
1914 2013-03-06 19:51:57 <beethoven8201> gavinandresen: in bitcoin-otc
1915 2013-03-06 19:52:03 <jgarzik> gavinandresen: some mining pools prefer stock bitcoind, where possible
1916 2013-03-06 19:52:14 HiWEB has joined
1917 2013-03-06 19:52:30 <jgarzik> gavinandresen: and we should continue to encourage that with positive reinforcement :)
1918 2013-03-06 19:52:33 <gavinandresen> jgarzik: I'd rather teach them to set it themselves
1919 2013-03-06 19:52:39 <muhoo> though it kind of fucks with my business model a bit, i'm OK with that.
1920 2013-03-06 19:52:45 <gavinandresen> jgarzik: ⦠because I think diversity is good.
1921 2013-03-06 19:52:54 <gmaxwell> 11:51 < jgarzik> gavinandresen: some mining pools prefer stock bitcoind, where possible
1922 2013-03-06 19:52:59 <jgarzik> gavinandresen: pointless, if we are continually bumping the limit
1923 2013-03-06 19:53:01 <gmaxwell> @#$@ you don't need to patch it to set the target.
1924 2013-03-06 19:53:05 <jaakkos> if one wants to resend a 0-fee tx with a fee, does it get dropped by the network as a double spend? does that potentially render the funds unredeemable for extended periods (what period?)
1925 2013-03-06 19:53:05 <jgarzik> gavinandresen: consider The Power Of Defaults
1926 2013-03-06 19:53:09 <gmaxwell> it's a commandline parameter.
1927 2013-03-06 19:53:12 <jgarzik> gmaxwell: agreed, but, ^^^
1928 2013-03-06 19:53:28 <gavinandresen> jgarzik: I'd be ok with making the default "some random value between 250K and max block size."
1929 2013-03-06 19:53:34 <sivu> gavinandresen: so it's possible for the transaction to get stuck in limbo forever if there's no possibility for it to be added into the block. and no way to cancel it
1930 2013-03-06 19:53:40 * muhoo listens intently for the answer to jaakos's question
1931 2013-03-06 19:53:44 <gmaxwell> But in any case, they're too busy mining asicminers few-satoshi payments to each of their shareholders. :P
1932 2013-03-06 19:53:55 <jgarzik> gmaxwell: (a) People use our defaults, and (b) when blocks average 250k currently, it is stupid not to raise it
1933 2013-03-06 19:54:07 <jgarzik> gmaxwell: we communicate a lot through defaults
1934 2013-03-06 19:54:11 <gavinandresen> sivu: yes. There are ideas for making bitcoin clients smarter about realizing that a transaction will never confirm, but nobody has written code to do it.
1935 2013-03-06 19:54:52 <muhoo> doing ecommerce in a world where you risk tx's never confirming, is, um, suboptimal
1936 2013-03-06 19:54:59 <sivu> gavinandresen: so in theory its possible to flood resources of all servers with transactions that will never confirm
1937 2013-03-06 19:55:10 <jgarzik> Soft-limit block size is easily changeable via command line or bitcoin.conf
1938 2013-03-06 19:55:17 <jgarzik> as I did w/ p2pool, and as gmaxwell points out
1939 2013-03-06 19:55:26 <gmaxwell> muhoo: thats always the case.
1940 2013-03-06 19:55:29 <jgarzik> A default is merely useful guidance
1941 2013-03-06 19:55:39 <jgarzik> and useful guidance is larger than 250k now
1942 2013-03-06 19:55:44 <gavinandresen> sivu: ummâ¦. no, there aren't enough unspent transaction outputs to fill up servers' memory
1943 2013-03-06 19:56:00 <muhoo> gmaxwell: also something i suspected, but useful to have confirmation of, thank you.
1944 2013-03-06 19:56:23 <gmaxwell> muhoo: I mean it's true outside of bitcoin too.
1945 2013-03-06 19:56:50 <muhoo> gmaxwell: so i agree with you, my idea of passing tx'es through transparently, one-for-one, is dead in the water. i'll have to store them and batch-redeem them.
1946 2013-03-06 19:57:48 <gavinandresen> jgarzik: I don't see how we can guide miners to the "right" answer on block size. I think they need to decide what the block size / fee tradeoff is.
1947 2013-03-06 19:57:51 <gmaxwell> FWIW, looking at 00000000000000036086374f7433682bacfdbade05714bac6998bf31aad9d993 (most recent block when I started a couple minutes ago) it looks like 80% of transactions are SDICE. (40% to, 40% from)
1948 2013-03-06 19:58:11 <muhoo> then again, wait a minute, that won't fix anything. because they'll be huge tx'es with many many inputs, and might be too big :-(
1949 2013-03-06 19:58:21 <gmaxwell> As a result I don't think raising the size is in the best interest of miners, doing so will just lower their fee income.
1950 2013-03-06 19:58:34 <gmaxwell> (because it'll just cause dice to lower their fees again)
1951 2013-03-06 19:58:43 <jgarzik> gmaxwell: not true
1952 2013-03-06 19:58:46 <gavinandresen> exactly, we need a bit of a price war
1953 2013-03-06 19:58:58 <jgarzik> gmaxwell: that does not follow practical SD fee experience
1954 2013-03-06 19:59:11 * muhoo is really starting to hate SD
1955 2013-03-06 19:59:16 <gmaxwell> well, they increased it now that they are seeing delays, it seems?
1956 2013-03-06 19:59:18 <jgarzik> gmaxwell: SD follows the official client fee relay rules
1957 2013-03-06 19:59:35 <gmaxwell> jgarzik: no, they don't â they have always paid fees in excess of that.
1958 2013-03-06 19:59:57 <jgarzik> gmaxwell: "follow" is a superset of ">= minimum fee"
1959 2013-03-06 20:00:05 <muhoo> they're trying to corner the market on blocks?
1960 2013-03-06 20:00:08 <jgarzik> gmaxwell: they changed, when we changed the fees
1961 2013-03-06 20:00:14 <gmaxwell> (bitcoinj doesn't have any code for the normal fee rules. :( )
1962 2013-03-06 20:00:42 <muhoo> afaict, they are using a very old version of bitcoinj too
1963 2013-03-06 20:01:15 <muhoo> at least what they have up on google code looks like it's from 9 months ago or so
1964 2013-03-06 20:01:32 <sivu> i'm surprised there is a very little competition to satoshidice
1965 2013-03-06 20:01:33 <jgarzik> Anyway, with regards to block size: income-wise, miner seem best served to sweep up all fee-paying transactions up to 1MB
1966 2013-03-06 20:01:46 <jgarzik> soft limit just leaves money on the table for others
1967 2013-03-06 20:01:50 <gmaxwell> jgarzik: increases your orphan rate...
1968 2013-03-06 20:02:04 <muhoo> and if SD pays high fees, that nobody else considers practical, then all your blocks are belong to SD
1969 2013-03-06 20:02:06 <warren> jgarzik: meaning SD will continue to externalize costs
1970 2013-03-06 20:02:08 <gmaxwell> hard to figure out exactly how much, but there is a floor... esp with a 25 BTC subsidy on the table.
1971 2013-03-06 20:02:11 chmod755 is now known as catfish!~chmod755@unaffiliated/chmod755|chmod755
1972 2013-03-06 20:02:27 <jgarzik> nod, all your blocks belong to SD, a current high bidder
1973 2013-03-06 20:02:43 <jgarzik> crowds out others
1974 2013-03-06 20:02:46 <muhoo> that seems pretty horrible to me
1975 2013-03-06 20:02:53 <gavinandresen> jgarzik: ⦠so you should have an easy time lobbying for some big miners to run with a larger block sizeâ¦
1976 2013-03-06 20:03:01 <muhoo> it takes my business model and throws it in the gutter, at least.
1977 2013-03-06 20:03:31 <jgarzik> gavinandresen: c.f. what said before: miners like to say they run vanilla upstream, and look to upstream for network guidance
1978 2013-03-06 20:03:42 <gmaxwell> Its not clear to me that increasing it is good guidance at this time.
1979 2013-03-06 20:04:15 <gmaxwell> Obviously there is not yet enough fee pressure to cause people to choose to not use the most inefficient transaction practices possible.
1980 2013-03-06 20:04:16 <muhoo> well thanks guys, now i understand why there was 1) such a brouhaha last month about block size limits, and 2) why luke-jr hates SD so much
1981 2013-03-06 20:05:14 <muhoo> gmaxwell: so it's a game of chicken?
1982 2013-03-06 20:05:21 <jgarzik> yes
1983 2013-03-06 20:05:33 <muhoo> maybe not such a bad idea, but risky. what if SD really does crowd out all other tx'es?
1984 2013-03-06 20:05:37 <jgarzik> the problem is, it's a game of chicken between SD and normal users who will just get a bad experience
1985 2013-03-06 20:05:57 <jgarzik> muhoo: it's a natural market
1986 2013-03-06 20:06:02 <jgarzik> muhoo: so people will adjust by paying higher fees
1987 2013-03-06 20:06:16 <muhoo> jgarzik: and get in a biddign war with someone with limitless deep pockets?
1988 2013-03-06 20:06:17 <jgarzik> muhoo: or miners will adjust their limits etc.
1989 2013-03-06 20:06:22 <gavinandresen> We should definitely fix the bad experience; the client needs to be much smarter about recomending the "right" fee
1990 2013-03-06 20:06:35 <muhoo> that seems insane. SD can just keep upping the fees and their customers will keep paying it. i do NOT have that flexibility!
1991 2013-03-06 20:06:52 <gmaxwell> gavinandresen: child pays for parent would help things get unstuck...
1992 2013-03-06 20:06:58 <gavinandresen> ⦠well, all of the clients⦠there should be competition among client developers ...
1993 2013-03-06 20:07:20 <jgarzik> let's not compete by being the one providing the bad experience though ;p
1994 2013-03-06 20:07:28 <gavinandresen> agreed
1995 2013-03-06 20:07:42 <sivu> how much of the current price increase is because of SD draws new people to get btc
1996 2013-03-06 20:07:48 <CodeShark> there should be competition among wallet developers. the verification/relay engine still needs a reference implementation
1997 2013-03-06 20:07:52 <gmaxwell> I think the bigger issues right now is not the fee recommendation, its that you're stuck when you regret your decision. Even if a client makes great recommendations users will opt out of them until they get burned.
1998 2013-03-06 20:08:20 <CodeShark> the wallet app and the verification/relay engine app should be completely separate :)
1999 2013-03-06 20:08:40 <muhoo> CodeShark: with SPV clients, they are
2000 2013-03-06 20:08:50 <beethoven8201> I agree with gmaxwell
2001 2013-03-06 20:08:54 <beethoven8201> users will opt out
2002 2013-03-06 20:08:55 <warren> Have we given up on changing the network rules to discourage SD like behavior?
2003 2013-03-06 20:08:55 <gmaxwell> so child pays parent, mempool expiration or some kind of replacement logic would be helpful in letting wallets do smart things.
2004 2013-03-06 20:08:58 <jgarzik> gmaxwell: sure... you know my answer :) transaction mempool expiration
2005 2013-03-06 20:09:07 <jgarzik> no replacement
2006 2013-03-06 20:09:25 <jgarzik> replacement is very difficult to get right
2007 2013-03-06 20:09:28 <gmaxwell> I'm wondering if allowing replacement would be better than expiration. Expiration carries theft risk the replacement wouldn't.
2008 2013-03-06 20:09:49 <gmaxwell> if you only replace when you would have expired, then replacement can be no worse (other than code complexity)
2009 2013-03-06 20:09:53 <beethoven8201> 0 confirms for 1.5 hours
2010 2013-03-06 20:09:57 <gmaxwell> I don't mean nlocktime replacement.
2011 2013-03-06 20:10:03 <gmaxwell> ;;bc,tslb
2012 2013-03-06 20:10:04 <gribble> Time since last block: 4 minutes and 29 seconds
2013 2013-03-06 20:10:29 datagutt has quit (Quit: kthxbai)
2014 2013-03-06 20:10:35 <gavinandresen> If by "replacement" you mean "delete the wallet transaction, mark the inputs as free to spend if no confirmations after X time" then sure
2015 2013-03-06 20:10:43 <gmaxwell> jgarzik: I don't even mean nlocktime replacement. I mean something like soft expiration.. where you'll replace a locked txn with a new one that pays the same parties but has more fee.
2016 2013-03-06 20:10:55 <gmaxwell> gavinandresen: talking about mempool, not wallet.
2017 2013-03-06 20:11:00 <jgarzik> replacement is always more complicated than expiration
2018 2013-03-06 20:11:03 <muhoo> warren: this debate has been goign on for a month now. i'm pretty sure every possibility has been discussed, weighed, and discounted
2019 2013-03-06 20:11:07 <jgarzik> you can DoS via rapid replacement
2020 2013-03-06 20:11:08 <jgarzik> etc.
2021 2013-03-06 20:11:15 <jgarzik> rules for validation are more complicated
2022 2013-03-06 20:11:23 <gmaxwell> jgarzik: no, you can't. Not if you would only replace a transaction that you consider expired.
2023 2013-03-06 20:11:33 <gmaxwell> Yes, it's somewhat more complicated.
2024 2013-03-06 20:11:41 <gavinandresen> I posted about a mempool rewrite on the bitcointalk forums earlier today
2025 2013-03-06 20:12:03 <jaakkos> muhoo: about my question - i think one can craft a tx that uses the 0-fee one as input, but the new tx has a fee. it would then be included - but ofc. this may be extremely difficult if the sender can't communicate with the original recipient (because their signature is needed)
2026 2013-03-06 20:12:10 <jgarzik> gavinandresen: url?
2027 2013-03-06 20:12:14 <gavinandresen> ⦠somebody should do that, I've got a lot on my TODO list alreadyâ¦.
2028 2013-03-06 20:12:20 <gmaxwell> The long transaction delays that happen exactly when replacement for increased fees are needed cause people to accept unconfirmed txn. expiring txn mindlessly greatly increases the risk of unconfirmed txn.
2029 2013-03-06 20:12:46 <gmaxwell> jaakkos: we do not have child pays for parent now, so that would not work.
2030 2013-03-06 20:13:32 <jgarzik> gmaxwell: in general, the problem of "my tx is in limbo" is the one I want solved
2031 2013-03-06 20:13:33 <gavinandresen> jgarzik: wait, no, I'm losing my mind apparently...
2032 2013-03-06 20:13:39 <jgarzik> horrible usability problem for bitcoin
2033 2013-03-06 20:13:41 <jgarzik> since day 1
2034 2013-03-06 20:13:50 * jgarzik isn't picky about the solution
2035 2013-03-06 20:14:06 <gmaxwell> jgarzik: great, I agree. But making it trivally to doublespend transactions in practice isn't needed to solve that.
2036 2013-03-06 20:14:24 <jgarzik> gmaxwell: rofl, hyperbole much?
2037 2013-03-06 20:14:42 <muhoo> gmaxwell: doesn't hyperbole often, AFAICT
2038 2013-03-06 20:14:42 <gmaxwell> jgarzik: Not at all.
2039 2013-03-06 20:15:04 <gmaxwell> jgarzik: IF this is needed it means txn are actually lasting that long in practice.
2040 2013-03-06 20:15:21 <jaakkos> gmaxwell: i don't understand why that would require anything special?
2041 2013-03-06 20:15:21 <jgarzik> gmaxwell: expiring a TX that has been sitting in the mempool for too long does not make it any more or less to "trivially double spend"
2042 2013-03-06 20:15:25 <jgarzik> *likely
2043 2013-03-06 20:15:41 darkee has quit (!~darkee@gateway/tor-sasl/darkee|Remote host closed the connection)
2044 2013-03-06 20:15:49 <jaakkos> or is it prohibited to broadcast a tx that chains to a tx that has not yet confirmed
2045 2013-03-06 20:16:42 darkee has joined
2046 2013-03-06 20:16:42 <gmaxwell> jgarzik: right now, as TD likes to point out, mempool behavior makes TD not work for most people.
2047 2013-03-06 20:17:43 <jgarzik> jaakkos: that's fine. it is called an orphan, and is stored in a buffer limited to 10,000 orphans.
2048 2013-03-06 20:17:46 <gmaxwell> jgarzik: How about this: txn expires from mempool. You add its inputs to a map of pending-expiration inputs. When a new txn comes in you check that list to make sure that it meets a replacement rule. Otherwise its rejected.
2049 2013-03-06 20:18:33 <gmaxwell> The replacement rule would be: "the new txn at pays at least the same amount to all prior outputs, and pays more fee"
2050 2013-03-06 20:19:13 <gmaxwell> (meaning you can't convert change to fees, alas)
2051 2013-03-06 20:20:27 <gmaxwell> I suppose it could be "the new txn at pays at least the same amount to all prior outputs, and pays more fee" OR "has the same inputs and outputs, except one output is diminished by exactly the increase in fee"
2052 2013-03-06 20:21:38 <gavinandresen> gmaxwell: how about a fixed-size memory pool some multiple of max block size. Fill it like you're filling a block, expire transactions that don't fit. If you get a transaction that doesn't fit, don't relay it.
2053 2013-03-06 20:21:39 <gavinandresen> done.
2054 2013-03-06 20:22:02 <gavinandresen> oh, and do the child-pays-for-parent thing.
2055 2013-03-06 20:22:36 <jgarzik> sort the mempool by priority, and set a cap
2056 2013-03-06 20:22:55 <gavinandresen> we might need to teach the re-broadcast code to broadcast the child (as an orphan) before broadcasting the not-enough-fee parent
2057 2013-03-06 20:23:09 <gmaxwell> Where is TD when I need him here to argue for not undermining the limited stickyness of unconfirmed txn. :P
2058 2013-03-06 20:23:16 <jgarzik> Yeah, I had been thinking about that, as a complication of child-pays-for-parent
2059 2013-03-06 20:23:46 <muhoo> how would child pays for parent work?
2060 2013-03-06 20:23:56 <gavinandresen> limited stickyness? Limiting the mempool size means if they don't get confirmed they'll naturally get dropped
2061 2013-03-06 20:24:23 <gmaxwell> gavinandresen: expiring based on stuff not visible to a client is kinda weak just because its hard to tell if a unconfirmed txn you have has any chance of surviving.
2062 2013-03-06 20:24:27 <jgarzik> priority sort gets you stickiness based on priority
2063 2013-03-06 20:24:37 twixed has joined
2064 2013-03-06 20:25:00 <gmaxwell> gavinandresen: it means that you can hear about a txn that pays you, act on it, and then have it replaced by one that doesn't more easily. (e.g. without a miner's help)
2065 2013-03-06 20:25:09 <gavinandresen> gmaxwell: we could have an 'inv_rejected' message if you broadcast a tx that doesn't fit into your peer's mempool. But I'd have to think about cheating that....
2066 2013-03-06 20:25:13 rbecker is now known as RBecker
2067 2013-03-06 20:25:14 <jgarzik> That's why I originally favored a network-wide expire time
2068 2013-03-06 20:25:22 <jgarzik> default mempool expiration to ~48 hours
2069 2013-03-06 20:25:30 <jgarzik> then expectations are built around that
2070 2013-03-06 20:25:34 <jaakkos> jgarzik: "it's called an orphan" - but i don't think it is because everyone already know the 0-fee one which is its parent
2071 2013-03-06 20:25:43 <jgarzik> note "expectations" and not "guarantees" (for obvious reasons)
2072 2013-03-06 20:26:16 <jaakkos> but problem was that the 0-fee one would never confirm
2073 2013-03-06 20:26:24 <jaakkos> so that would force it to confirm
2074 2013-03-06 20:26:29 <gmaxwell> jgarzik: I'd much rather have much shorter horizon that only allows retrying with better fees. The risk of theft makes you artifically have your expire higher than it needs to be for ratelimiting.
2075 2013-03-06 20:26:57 <gavinandresen> gmaxwell: ??? double-spending 0-confirmation transactions feels like a completely orthogonal issue to me.....
2076 2013-03-06 20:27:25 <jgarzik> gmaxwell: yeah I'm not sure where you're going here either
2077 2013-03-06 20:27:28 <gmaxwell> gavinandresen: wow. It's the .. only reason to have a mempool at atll (well larger than the block you're trying to mine)
2078 2013-03-06 20:27:44 <jgarzik> gmaxwell: TX expiration after 48 hours, and then resending with a lower fee should be allowed, if stupid
2079 2013-03-06 20:27:57 <gmaxwell> otherwise you'd just keep 250kb and bump out the lowhanger instantly.
2080 2013-03-06 20:28:32 * jgarzik doesn't see the point of the soft limit, given the hard limit
2081 2013-03-06 20:28:35 <gavinandresen> gmaxwell: the reason to have a mempool larger than the block you're currently mining is so you always have the bestest, highest-fee/priority transactions to mine, even right after you get lucky and solve a block
2082 2013-03-06 20:28:36 <jgarzik> SD loves it, hurts normal users
2083 2013-03-06 20:28:41 <gmaxwell> jgarzik: no point in allowing something any sufficiently rational miner will undermine.. creates dumb expectations (that it'll work)
2084 2013-03-06 20:28:52 <jgarzik> the _easiest_ way to give our users a better experience _for now_ is bumping the soft limit
2085 2013-03-06 20:29:07 <gmaxwell> gavinandresen: No, the reason to have a mempool is to have a soft consensus that inhibits double spending.
2086 2013-03-06 20:29:09 <jgarzik> all this Getting Fees And Expiration Right stuff takes forever
2087 2013-03-06 20:29:50 <sipa> huh, i completely agree with gmaxwell here: the mempool is the only thing that makes the network fight against double spends before there are confirms
2088 2013-03-06 20:29:55 <jgarzik> just changing a constant will set up a better user experience easily and cheaply, and should benefit miners by sweeping more income. if their orphan rate is too high, they can use the existing knob to dial it down.
2089 2013-03-06 20:30:23 <gmaxwell> This is really TD's argument here. I'm normally arguing with him that unconfirmeds are unsafe because this stuff isn't enough, but at the same time it's not nothing.
2090 2013-03-06 20:30:44 <jgarzik> sipa: but does it therefore follow that a 48-hour-without-getting-into-block expiration results in "trivial double spends"?
2091 2013-03-06 20:30:57 <gmaxwell> jgarzik: the risk there is that people realize this, and then get manic about it and set the knob to very low values just in case. :(
2092 2013-03-06 20:31:18 <gmaxwell> e.g. we had miners producing blocks with very few transactions for a while after the last round of orphan paranoia.
2093 2013-03-06 20:31:22 <gavinandresen> gmaxwell: again, I think that's completely orthogonal. I do think that a relay-the-first-double-spend-of-a-txout-you've-recently-seen is a Good Idea, but I wouldn't do that with the mempool
2094 2013-03-06 20:31:33 <sipa> jgarzik: i haven't though about that enough; i think it will lead to clients agressively retransmitting
2095 2013-03-06 20:31:46 <gmaxwell> gavinandresen: oh you've totally misunderstood me.
2096 2013-03-06 20:31:55 <gmaxwell> gavinandresen: I'm not talking about double spend alerts at all.
2097 2013-03-06 20:32:27 <gavinandresen> gmaxwell: ⦠what high-level feature are you talking about, then?
2098 2013-03-06 20:32:45 <gmaxwell> Expiration of txn from the mempool.
2099 2013-03-06 20:32:49 <gmaxwell> gavinandresen: I'm saying that expiring txn from the mempool make it easy (just wait and transmit) to replace them with once that claw the funds back.
2100 2013-03-06 20:33:27 <gmaxwell> So the rational thing to do is to just constantly retransmit any txn paying you as much as you can, to keep it in people's mempools so that one that doesn't pay you can't replace it.
2101 2013-03-06 20:33:38 <gmaxwell> I guess. ugly.
2102 2013-03-06 20:34:19 <gavinandresen> We can't assume inifinite mempools.
2103 2013-03-06 20:34:23 <gmaxwell> gavinandresen: what I suggested instead is that when a mempool txn 'expires' instead you only let certian double spends replace it: ones that pay the same outputs plus additional fee.
2104 2013-03-06 20:34:48 <gmaxwell> (of course that list would also eventually expire too... but it could have a rather large horizon)
2105 2013-03-06 20:35:03 <gmaxwell> gavinandresen: td thinks the mempool should spill onto disk.
2106 2013-03-06 20:35:05 <gavinandresen> who is "you" ? the person being paid or every node on the network?
2107 2013-03-06 20:35:20 <gavinandresen> ⦠and how would you ensure that every node on the network follows those rules?
2108 2013-03-06 20:35:21 <gmaxwell> Every node on the network.
2109 2013-03-06 20:35:45 <gavinandresen> e.g. if it is in a miner's interest to take a higher-fee-paying transaction⦠then I assert some percentage of them will.
2110 2013-03-06 20:36:28 <gavinandresen> Which is why I think fast double-spend alerts are a much better solution
2111 2013-03-06 20:36:39 <gmaxwell> "It's a default" ... thats basically the core of my argument against TD's unconfirmed position: you can't be sure some nodes don't undermine your expectation. TD counter's that in practice people's willingness to facilitate theft is limited, and this makes the theft materially less profitable, which means that more things can accept the risk.
2112 2013-03-06 20:36:44 <gavinandresen> ⦠at least you know as soon as possible that your trading partner is trying to rip you off
2113 2013-03-06 20:37:42 <gmaxwell> gavinandresen: you'd know 48 hours later, when the ripoff replaces the expiring txn in the network. The expiration removes it from being a race (unless you retransmit, in which case its a race to retransmit)
2114 2013-03-06 20:38:38 <sipa> gavinandresen: meh, if miners are not interested in helping soft consensus, they'll just as likely accept replacement transactions directly that never broadcast and never trigger doublespend alerts
2115 2013-03-06 20:38:59 <muhoo> so you're trying to solve the problem of how to allow tx's to sit for a long time waiting to get into a block, without risking double-spends?
2116 2013-03-06 20:39:01 <gavinandresen> sipa: agreed.
2117 2013-03-06 20:39:18 <sipa> if you assume worst-case behaviour, neither technique helps
2118 2013-03-06 20:39:20 * gavinandresen grumbles about getting sucked into another angels-dancing-on-the-head-of-a-pin discussion
2119 2013-03-06 20:40:00 <gmaxwell> This isn't angels on pins. Please go debate this with TD. He will argue that mempool exclusion of conflicts is a core feature of Bitcoin.
2120 2013-03-06 20:40:12 <petertodd> BTW as a practical datapoint, when I was experimenting with never confirm nLockTime, I found that with the help of some fairly well-connected nodes I was running, I could get a double-spend of the non-final transactions relatively quickly, after about a day. This was well pre 0.8, so probably it wasn't a factor of nodes dropping the non-final tx.
2121 2013-03-06 20:40:21 <gmaxwell> (I think he overstates it, but thats not the same as not agreeing somewhat)
2122 2013-03-06 20:40:59 <petertodd> Equally, when I was experimenting with tx's locked for even weeks in advance, every last one eventually got mined even though I never re-broadcast them.
2123 2013-03-06 20:41:28 <gmaxwell> petertodd: soft consensus is currently inhibited somewhat by mempool being in memory only and nodes not syncing the mempool on startup.
2124 2013-03-06 20:41:48 <gavinandresen> bah. I just think we spend too much time arguing over esoteric edge cases and too little time actually making the software work better now.
2125 2013-03-06 20:42:06 <petertodd> gmaxwell: Exactly. Which basically says miner node turnover is high enough to get tx's mined, and low enough to get tx's to stay in the mempool of some nodes for weeks.
2126 2013-03-06 20:42:24 <muhoo> well the real problem now is, what happens to the increasing number of tx's that sit unconfirmed while 80%-100% of block space is SD?
2127 2013-03-06 20:42:47 <petertodd> muhoo: People turn up the tx fees they use for their actually valuable transactions and crowd out SD, problem solved.
2128 2013-03-06 20:42:50 rdymac has joined
2129 2013-03-06 20:43:01 <petertodd> muhoo: It'd help to have recursive fee evaluation that Eligius does.
2130 2013-03-06 20:43:13 <BlueMatt> muhoo: we implement a better priority algorithm, let sd keep paying fees, and encourage miners to help the network by offering high-priority space
2131 2013-03-06 20:43:15 <muhoo> petertodd: presuming they can afford to get in a bidding war with SD, when SD does not give a fuck how high the fees go
2132 2013-03-06 20:43:18 <gavinandresen> seems to me the right behavior is limit the mempool size so "bad" transaction go away. And teach clients to mark unconfirmed incoming transactions as "failed" or something if they're not mined within a reasonable amount of time
2133 2013-03-06 20:43:48 LargoG has quit ()
2134 2013-03-06 20:44:13 <petertodd> gavinandresen: I agree 100%
2135 2013-03-06 20:44:16 <muhoo> petertodd: this is why i'm injecting myself into this, though it's a bit above my level. i care about the outcome of that.
2136 2013-03-06 20:44:41 <BlueMatt> gavinandresen: yep, working on the first part
2137 2013-03-06 20:45:02 <gavinandresen> BlueMatt: nice
2138 2013-03-06 20:45:12 <petertodd> muhoo: I think the recursive fee evaluation is the main thing that needs to be done soon, so a user who has been sent a tx without a fee has a way of getting it confirmed. Or equally, some standard way of paying for a miner to mine the tx that doesn't involve recursive fee eval.
2139 2013-03-06 20:45:47 <BlueMatt> petertodd: working on it
2140 2013-03-06 20:45:48 <gmaxwell> gavinandresen: the simplest way of doing that comes at the cost of making malicious doublespends easier and much more likely in practice, and create incentives for people to flood the network to avoid getting ripped off.. You can achieve the same end without reducing the security of unconfirmed transactions by only allowing higher fee transactions that pay the same party to replace the bad ones.
2141 2013-03-06 20:46:06 <gmaxwell> (and flooding the network will also undermine the replacement you wanted in any case)
2142 2013-03-06 20:46:42 <petertodd> gmaxwell: Well, like it or not, I really think in the future unconfirmed tx's are just going to be even more dangerous, no getting aroudn that issue.
2143 2013-03-06 20:47:16 <petertodd> BlueMatt: Cool, a which category of fee payment solution, recursive eval or non?
2144 2013-03-06 20:47:35 <sipa> luke has a pullreq for recursive fee eval
2145 2013-03-06 20:47:37 <BlueMatt> petertodd: huh?
2146 2013-03-06 20:47:43 <BlueMatt> sipa: yes
2147 2013-03-06 20:47:51 <gavinandresen> gmaxwell: I still don't see how. So: attacker sends transaction. Waits for it to expire from mempools? when it expires from the client's mempool, the client will mark it 'failed'
2148 2013-03-06 20:48:09 <sipa> i'm very much in favor of that idea, but i really uave difficulty following that code
2149 2013-03-06 20:48:10 rdymac has quit (Remote host closed the connection)
2150 2013-03-06 20:48:11 <gavinandresen> ⦠if they don't wait for it to expire from mempools, then they can't send the double-spend....
2151 2013-03-06 20:48:42 <petertodd> BlueMatt: Ok, luke's recursive fee eval, basically means you have to spend the input again, with another tx. A non-recursive eval would be some other method, I dunno, maybe a non-chain micropayment to the miner or something.
2152 2013-03-06 20:48:43 <gmaxwell> gavinandresen: its 48 hours later, the goods have long since shipped. The 'failed' is small consolation.
2153 2013-03-06 20:48:55 <petertodd> BlueMatt: The latter is obviously far harder.
2154 2013-03-06 20:49:03 <gavinandresen> gmaxwell: sigh. shipping 0-confirmed transactions? Really?
2155 2013-03-06 20:49:16 nimdAHK has joined
2156 2013-03-06 20:49:25 <BlueMatt> petertodd: doing it by paying a miner is outside of the scope of fee evaluation at all, though I thought we had an rpc for manually adding a tx (we should)
2157 2013-03-06 20:49:26 <muhoo> if it takes a day for a tx to confirm, then that will have to happen
2158 2013-03-06 20:49:36 <BlueMatt> petertodd: the latter is outside the scope of bitcoind
2159 2013-03-06 20:49:39 <gmaxwell> gavinandresen: you waited 48 hours as a precondition of this discussion. It's a cost/benefit tradeoff.
2160 2013-03-06 20:49:58 <petertodd> BlueMatt: I know it's outside the scope, just curious if you were working on it.
2161 2013-03-06 20:50:11 <muhoo> you'll see people either wanting to ship 0-confs, or blow it off and insist on something like green addresses
2162 2013-03-06 20:50:23 <BlueMatt> petertodd: Im not a large-scale miner, there is little I can do....
2163 2013-03-06 20:50:45 <petertodd> muhoo: Even green addresses you have to be careful with, for instance the Mt. Gox ones do a tx immediately before to transfer the funds to the green address, which means you
2164 2013-03-06 20:50:48 <gmaxwell> I certantly think people shouldn't ship before getting confirmation, but at the same time if it's taking 48 hours they will and they'll be rational to do it in many case... though if its easy to replace long txn with take-backs then the cost side of the formula goes up a lot.
2165 2013-03-06 20:50:58 <petertodd> you're relying on two tx's, and the former could be mutated rentering the latter invalid.
2166 2013-03-06 20:51:18 <gavinandresen> if what is taking 48 hours? transaction volume should be high enough that very-low-fee/priority transactions expire from the mempool fairly fast
2167 2013-03-06 20:51:43 CodeShark has quit (Remote host closed the connection)
2168 2013-03-06 20:51:57 <gmaxwell> gavinandresen: Jeff's proposal was predicated on a specific horizon, if you eliminate that you get different issues.
2169 2013-03-06 20:52:09 xjrn has quit (Ping timeout: 245 seconds)
2170 2013-03-06 20:52:36 <petertodd> Thinking: can we change the default in bitcoind to remove the priority logic for free transactions? IE, for when you send a transaction? Because I suspect it won't be much longer before free ones take inordinant amounts of time to get mined.
2171 2013-03-06 20:52:39 <gavinandresen> ok. I'm stuck on my proposal. What are the issues with: memory-limited mempool, filled up like an extra-large block.
2172 2013-03-06 20:53:24 <gavinandresen> ⦠and clients that are smart enough that if they see their incoming 0-confirmation transactions drop from their mempools they mark them "failed"
2173 2013-03-06 20:53:36 defunctzombie_zz is now known as defunctzombie
2174 2013-03-06 20:54:10 <petertodd> gavinandresen: You thinking have clients do INV requests to get an idea when their tx's are probably being dropped? Or just relying on a time-based assumption?
2175 2013-03-06 20:54:25 <gmaxwell> gavinandresen: so, minor stuff like there is no consistency there.. meaning that I have no idea when its expired at miners only at me. I may not even be able to get the miners a replacement because indermediate nodes haven't expired it yet.
2176 2013-03-06 20:54:59 rdymac has joined
2177 2013-03-06 20:55:36 <gavinandresen> I'm getting confused now-- we're talking about RECEIVING transactions, right?
2178 2013-03-06 20:55:53 rdymac has quit (Read error: Connection reset by peer)
2179 2013-03-06 20:56:14 <gmaxwell> receiving or sending same issues exist.
2180 2013-03-06 20:56:21 rdymac has joined
2181 2013-03-06 20:56:43 <gmaxwell> gavinandresen: more significantly, I pay you. we wait for it to confirm, it's taking a bit. You send the goods because the risk of doing so is worth not losing business. Now I flood txn to push the payment out of mempools and replace it with one to recapture the funds. To counter that the reciever should agressively flood the transaction paying them to keep it in mempools so it can't be replaced with a malicious one.
2182 2013-03-06 20:57:17 <jgarzik> Given the choice of OOM-killing or memory limiting, I think the choice is obvious. And if limiting, you gotta pick which ones to kill.
2183 2013-03-06 20:57:24 <jgarzik> The alternative is kill-all (node restart)
2184 2013-03-06 20:57:36 <jgarzik> which is functionally the same as a node coming online, with empty mempool
2185 2013-03-06 20:57:40 rdymac has quit (Remote host closed the connection)
2186 2013-03-06 20:57:48 <gmaxwell> jgarzik: talk about hyperbole.. oomkilling? good luck finding enough UTXO to spend to run anyone out of memory.
2187 2013-03-06 20:58:11 <jgarzik> gmaxwell: on a memory limited VPS, people already complain
2188 2013-03-06 20:58:34 <gmaxwell> jgarzik: our memory usage is >300x bigger than I've ever seen the mempool get.
2189 2013-03-06 20:58:49 <gmaxwell> You're worrying about the wrong thing right now if you're worrying about memory.
2190 2013-03-06 20:59:23 <gavinandresen> gmaxwell: "doctor, it HURTS when I do thisâ¦."
2191 2013-03-06 20:59:26 <sipa> wellbat some point memory space of the mempool will become an issue
2192 2013-03-06 20:59:32 <gmaxwell> And the mempool could be written out to disk if you were concerned about its memory usage. I'm not saying this is a grand ideaâ but the worst case for that would just be ~doubling the utxo set size.. a few hundred megabytes.
2193 2013-03-06 21:00:15 <sipa> gmaxwell: not entirely true as the mempool holds full txn and not just txouts
2194 2013-03-06 21:00:39 <gmaxwell> sipa: well that was my '~' but perhaps you think that excessively approximate. :P
2195 2013-03-06 21:00:54 <sipa> i think kicking out lowest priority mempool transactuins in low-memory situations
2196 2013-03-06 21:00:58 <sipa> makes sense
2197 2013-03-06 21:00:58 <gmaxwell> sipa: though 'we spent all the utxo' is a bit silly.
2198 2013-03-06 21:01:23 <sipa> whether there should also be a te limit... unconvinced
2199 2013-03-06 21:01:32 <sipa> *time limit
2200 2013-03-06 21:01:40 <gmaxwell> sipa: then I just create txn floods in order to successfully double spend. This is not a grand thing.
2201 2013-03-06 21:02:00 <sipa> not everyone will have the same mempool size, though
2202 2013-03-06 21:02:08 <jgarzik> "transaction in limbo forever" is a problem worth solving
2203 2013-03-06 21:02:16 <jgarzik> determinism++
2204 2013-03-06 21:02:47 <gmaxwell> and again. low memory? right now my mempool is 0.03% of my node's memory usage.
2205 2013-03-06 21:03:10 <jgarzik> that last has nothing to do with low memory. gavinandresen was the one talking about memory limits.
2206 2013-03-06 21:03:23 <jgarzik> transaction behavior should be more predictable to users
2207 2013-03-06 21:03:53 <gavinandresen> I just want to simplify the code, we have too many ad-hoc rules for whether or not to relay transactions
2208 2013-03-06 21:03:57 <gmaxwell> You could increase its size 100x and its still not the most interesting memory user. And if it were at the point, serialize it to disk. Memory usage and expiration policy are orthogonal.
2209 2013-03-06 21:04:18 <sipa> agree about that
2210 2013-03-06 21:04:42 <gavinandresen> determinism is good, keep-it-simple-stupid is also good
2211 2013-03-06 21:05:47 <gmaxwell> jgarzik: on the subject of determinsim, perhaps where you say hours it should be 'blocks/6'. Since blocks are more consisten on the network than time?
2212 2013-03-06 21:07:00 <jgarzik> gmaxwell: original plan was simple rule: expire TX out of mempool, if it does not make it into block within X blocks
2213 2013-03-06 21:07:09 <jgarzik> gmaxwell: suggested values for X were 24 hours, 48 hours, 1 week
2214 2013-03-06 21:07:26 <jgarzik> (i.e. 144, 144*2, 144*7)
2215 2013-03-06 21:07:57 <gmaxwell> fails to actually solve the usability issue, greatly increases the risk of unconfirmed transactions, not quite consistent but perhaps close enough, on the plus side, simple to implement.
2216 2013-03-06 21:08:21 <jgarzik> it makes it possible to start solving the usability issue
2217 2013-03-06 21:08:30 <jgarzik> expiration has to be deployed before you can consider future work
2218 2013-03-06 21:08:36 HiWEB has quit (Quit: Gotta Jibboo)
2219 2013-03-06 21:09:02 <sipa> well gmaxwell's allow-replacement-after-X-te allows the same
2220 2013-03-06 21:09:03 <gmaxwell> having to wait 24/48 hours when you've realized an hour later that you regret your fee still sucks. And what happens when your reciever (or some random grifer) is constantly retransmitting?
2221 2013-03-06 21:09:05 <jgarzik> expiration happens naturally in the wild, as nodes start up, shut down and ignore
2222 2013-03-06 21:09:11 mappum has joined
2223 2013-03-06 21:09:23 axhlf has quit (Remote host closed the connection)
2224 2013-03-06 21:09:35 <gmaxwell> jgarzik: yes, and we can fix that if we likeâ by having newly booted peers pull their neighbors memory pools.
2225 2013-03-06 21:09:46 <jgarzik> we can? :)
2226 2013-03-06 21:10:10 <gmaxwell> Substantially. Recall, you wanted to do that and I NAKed because it would make all txn immortal. :P
2227 2013-03-06 21:13:31 <gmaxwell> jgarzik: I propose instead that after some number of blocks, (some could be lowâ e.g. 6) you make a transaction eligible for replacement. Subject to some simple conditions on the replacing transaction. Its similar to expiration except you don't just let any spend replace it. Then you also have an expire, but the expire would be at something high like 1008 blocks. And eventually nodes save them mempool to disk and sync with peers at ...
2228 2013-03-06 21:13:38 <gmaxwell> ... startup.
2229 2013-03-06 21:14:22 <gmaxwell> (I'd like TD's opinions on the latter half of thatâ the eventual expiration stuff)
2230 2013-03-06 21:14:42 <warren> This is probably a stupid question, but I'll ask anyway. If we are concerned about end-user usability, tx expiration, double spends ... would it be any worse if the protocol had an unconfirmed tx revocation tx? The sender has the unique privkey of the unconfirmed tx, so they presumably could sign some kind of "revocation tx" that proves the sender wants to cancel the previous tx. Perhaps they can include a fee to encourage miners to confirm t
2231 2013-03-06 21:14:42 <warren> he revocation before the other tx. This might enable faster, more certain cancellation from the user's POV, and would be no worse than our current situation?
2232 2013-03-06 21:15:11 ashams has quit (Read error: Connection reset by peer)
2233 2013-03-06 21:15:20 <sipa> gmaxwell: theoretical max mempool size is actually unbounded... it can contains transactions that only spend outputs within the mempool already
2234 2013-03-06 21:16:21 <gmaxwell> sipa: eh, not if you don't allow that. I don't know that accepting those is mempool definitional. It's just convenient.
2235 2013-03-06 21:16:24 <gmaxwell> warren: uhhh.
2236 2013-03-06 21:16:57 <gmaxwell> warren: ignoring malleability, it's already the case that only the sender of a transaction can produce a conflict.
2237 2013-03-06 21:17:28 <gmaxwell> warren: cancellation is just double spending from the perspective of the reciever.
2238 2013-03-06 21:17:33 <jgarzik> gmaxwell: that sounds to me like "enable expire, at a high value" would be an excellent first step, while working on this replacement stuff...
2239 2013-03-06 21:17:42 <warren> Oh. I suppose the receiver could still attempt to flood the original tx to crowd out the cancellation. =(
2240 2013-03-06 21:18:13 <petertodd> You know, frankly I feel it would be better if we just implement transaction replacement by higher fee transactions, and make it clear that unconfirmed is dangerous. (with the higher fee being a step up enough to keep DoS attacks expensive)
2241 2013-03-06 21:18:18 <gmaxwell> jgarzik: certantly at a high enough value I don't have any great complaint about itâ it doesn't make the current situation of adhoc expiration from node restarts worse, though it doesn't make it better.
2242 2013-03-06 21:18:20 <petertodd> And limit the length of unconfirmed chains.
2243 2013-03-06 21:18:33 <gmaxwell> jgarzik: I don't know that it greatly helps with conflicted txn, however.
2244 2013-03-06 21:18:50 <jgarzik> 1008 it is :)
2245 2013-03-06 21:19:20 <gmaxwell> petertodd: how do you prevent someone from flooding the network with a sequence of txn that increase the fee 1e-8 at a time? :P
2246 2013-03-06 21:20:09 * jgarzik needs to do a make-low-value-nonstandard patch too
2247 2013-03-06 21:20:09 <gmaxwell> petertodd: I think it's unfair to have that debate without TD around.
2248 2013-03-06 21:20:10 <petertodd> gmaxwell: Easy, replacement doesn't happen unless the new fee is 0.0005BTC greater than the old. (or whatever increment) Since the length of the unconfirmed chain is limited, they also can't cause a big chain of unconfirmed tx's to all vanish.
2249 2013-03-06 21:21:16 <HM> oh dear
2250 2013-03-06 21:21:20 <petertodd> gmaxwell: Yes, well, I'm putting it out there, I'll debate him later.
2251 2013-03-06 21:21:22 <gmaxwell> petertodd: because sure, an alternative case where we make unconfirmed txn maximally fragile is also a consistent infrastructure. ... though it would change the properties of the bitcoin system and make them less good on average. People's preference on that will depend on how they value the average vs the worst case.
2252 2013-03-06 21:21:28 <HM> Cryptopp segfaulted when i tried to run a 30 second PBKDF2 run
2253 2013-03-06 21:21:53 skeledrew has joined
2254 2013-03-06 21:22:03 <petertodd> gmaxwell: Well, unless mining becomes centralized, in the future as fees become more of the reward of mining, unconfirmed will become more dangerous, end-of-story, so get it over with now.
2255 2013-03-06 21:23:04 <gmaxwell> petertodd: so? it's already dangerous. But all business is dangerous. The fact that there is a risk benefit tradeoff doesn't mean the it's harmeless to increase risk.
2256 2013-03-06 21:23:43 <petertodd> gmaxwell: Yes, but I think it's more harmful long-term if we don't push people to adopting solutions that mitigate that risk now. If you need to accept unconfirmed tx, use another way.
2257 2013-03-06 21:24:13 <petertodd> gmaxwell: Otherwise someone can create my "assurance pool" that will accept any tx, based on fees, and you can be made vulnerable overnight with no way to react.
2258 2013-03-06 21:24:32 <petertodd> *no time to react
2259 2013-03-06 21:25:03 <gmaxwell> petertodd: I think thats a little silly. Why not just accept them and accept some risk? Risk is okay. Of course you have a way to react, you get txn processing insurance from someone who inspects your txn and the network and tells you how much they'll insure the txn against. (for example)
2260 2013-03-06 21:25:22 grau has joined
2261 2013-03-06 21:25:35 xjrn has joined
2262 2013-03-06 21:25:46 discrete has quit (Ping timeout: 240 seconds)
2263 2013-03-06 21:25:55 <jgarzik> On the wallet side, what is technically required to un-spend in bitcoind? Update spent flags, plus delete the wallet tx?
2264 2013-03-06 21:26:11 <petertodd> gmaxwell: Again, the risk can change overnight. By not accepting unconfirmed tx's, the risk is limited to the much less likely to change overnight risk that an extremely large miner starts mining delibrate orphans.
2265 2013-03-06 21:26:23 <warren> gmaxwell: wait, the cancellation tx idea differs from an ordinary double-spend by making it possible to put a stop to flooding of the original tx. Any node that sees the revocation knows to ignore and stop relaying the original tx. This wouldn't work?
2266 2013-03-06 21:26:31 <gmaxwell> jgarzik: deleting the wallet tx is an accounting disaster. That _can't_ be how it's officially supported. But what you're describing should be enough.
2267 2013-03-06 21:26:37 rlifchitz has quit (Ping timeout: 256 seconds)
2268 2013-03-06 21:26:44 <Diablo-D3> wait
2269 2013-03-06 21:26:47 <Diablo-D3> a cancelation tx?
2270 2013-03-06 21:26:54 <warren> Diablo-D3: hypothetical
2271 2013-03-06 21:26:59 <Diablo-D3> please don't do that
2272 2013-03-06 21:27:11 grazs has joined
2273 2013-03-06 21:27:13 <Diablo-D3> it breaks one of the fundamental things of bitcoin
2274 2013-03-06 21:27:25 <warren> Does it? they're only racing their own tx to confirmation.
2275 2013-03-06 21:27:30 <gmaxwell> warren: I can't figure out what you're thinking this would do. It's just a double spend, by definition if you've accepted it you are no longer accepting the other one.
2276 2013-03-06 21:27:54 <sipa> jgarzik: the spent flags are ugly
2277 2013-03-06 21:27:57 <gmaxwell> warren: thats what a double spend is! racing your own transaction to get a confirmation. There is no other kind of doublespend possible.
2278 2013-03-06 21:28:18 <sipa> jgarzik: and i think they're unnecessary: the only reason a txout in a wallet can be marked spent, is because you know of a tx that spent it
2279 2013-03-06 21:28:27 <petertodd> gmaxwell: Why does it have to be an accounting disaster? Change the code to have separate accounting for "pending" and "confirmed", yes, this could be a lot of code, but there is nothing fundementally wrong with the idea.
2280 2013-03-06 21:28:39 <gmaxwell> in any caseâ taking a step back, this is a change to the bitcoin security model and it should be discussed as such. Not as just a mempool memory size optimization or whatever, but as a material change to while kind of security bitcoin provides in practice.
2281 2013-03-06 21:28:55 <Diablo-D3> yeah what gmaxwell said
2282 2013-03-06 21:29:09 <Diablo-D3> if you can practically double spend as part of a protocol change, then why even use bitcoin?
2283 2013-03-06 21:29:19 <gmaxwell> (I think in such a debate I'd probably take your unbounded replacement side, but I would refuse to participate without someone like TD to point out all I'm missing on the other side)
2284 2013-03-06 21:29:19 <Diablo-D3> the whole reason anyone even uses bitcoins because it reduces chargeback scams
2285 2013-03-06 21:29:19 <petertodd> gmaxwell: I agree absolutely, but it's also a change that can happen regardless of our wishes overnight.
2286 2013-03-06 21:29:20 <sipa> jgarzik: so i've argued (but not yet implemented) that the wallet becomes more similar to the mempool, with a mapTxNext to track spends within it
2287 2013-03-06 21:29:30 <sipa> jgarzik: once you have that, marking a tx inactive becomes easy
2288 2013-03-06 21:29:39 <petertodd> gmaxwell: All you need is one big pool that changes their code.
2289 2013-03-06 21:29:46 <warren> Diablo-D3: you're a fool if you accept a 0-conf payment anyway
2290 2013-03-06 21:29:47 <sipa> jgarzik: and drop CWalletTx::vfSpent
2291 2013-03-06 21:29:58 <Diablo-D3> warren: thats beside the point
2292 2013-03-06 21:30:04 <Diablo-D3> cancel should never exist. ever.
2293 2013-03-06 21:30:12 grau has quit (Ping timeout: 260 seconds)
2294 2013-03-06 21:30:14 <warren> How would that harm anyone?
2295 2013-03-06 21:30:25 <gmaxwell> warren: a fool, or a rational agent who has done a careful assessment of risks and benefits in the context of all available information and decided the benefits outweigh the risks.
2296 2013-03-06 21:30:29 <warren> Aside from people who accept 0-conf
2297 2013-03-06 21:31:11 <petertodd> warren: What gmaxwell said...
2298 2013-03-06 21:31:23 xjrn has quit (Ping timeout: 276 seconds)
2299 2013-03-06 21:31:27 <gmaxwell> warren: regardless, there is no need for a _cancel_ txn to accomplish that. You can just allow arbritary double spends and have nodes accept the ones they like the most (presumably paying the most fees)
2300 2013-03-06 21:32:02 <warren> How do you get around the tx flooding issue?
2301 2013-03-06 21:32:06 <Diablo-D3> gmaxwell: wow that'd be weird
2302 2013-03-06 21:32:13 <Diablo-D3> warren: you punish nodes that flood
2303 2013-03-06 21:32:36 <gmaxwell> warren: you only accept ones that are better by some margin.
2304 2013-03-06 21:32:38 <warren> Diablo-D3: how do you track them, if they flood only once to every public node they can find?
2305 2013-03-06 21:33:15 <gmaxwell> warren: you can already do that, and?
2306 2013-03-06 21:33:53 <petertodd> Diablo-D3: Weird yes, but it also meets what miners want if they take the profit maximizing approach of filling every block up completely with the highest fee transactions.
2307 2013-03-06 21:33:59 <gmaxwell> warren: the point being that if you only accept replacements which are better by some margin, you don't get much amplification from such behavior. (it's limited by your ability to iterate the margin)
2308 2013-03-06 21:34:21 <Diablo-D3> so wait
2309 2013-03-06 21:34:24 <Diablo-D3> what is warren trying to do?
2310 2013-03-06 21:34:27 <Diablo-D3> repeat a tx with a better fee?
2311 2013-03-06 21:34:59 <petertodd> Diablo-D3: Yes, but a by a tiny increment, and flood the network that way.
2312 2013-03-06 21:35:14 <warren> Is it widely accepted that a "0-conf accepting rational agent" is rational?
2313 2013-03-06 21:35:20 <petertodd> Diablo-D3: I'm saying that by limiting how small that increment can be, people are paying for the extra bandwith anyway.
2314 2013-03-06 21:35:33 <petertodd> warren: Yes, under strictly controlled conditions.
2315 2013-03-06 21:35:49 <warren> OK, I didn't know that.
2316 2013-03-06 21:36:00 <petertodd> warren: In particular, that you must keep evaluating if the 0-conf risk is acceptable, and as I say, that risk can change drasticly with very little warning.
2317 2013-03-06 21:36:02 nus-- has joined
2318 2013-03-06 21:36:07 <warren> I did preface my idea with "This is probably a stupid question"
2319 2013-03-06 21:36:22 <petertodd> warren: It's not
2320 2013-03-06 21:36:53 <warren> I personally believe the 0-conf risk is never worth taking.
2321 2013-03-06 21:37:21 TD has joined
2322 2013-03-06 21:37:23 <Diablo-D3> so
2323 2013-03-06 21:37:35 <Diablo-D3> why not allow clients to figure out the tx are double spend attempts
2324 2013-03-06 21:37:35 <Goonie> sipa: you asked me about helping with the gitian build. can you elaborate what is needed to do?
2325 2013-03-06 21:37:41 <Diablo-D3> and then include the one that has the highest fee
2326 2013-03-06 21:37:43 <Diablo-D3> and ignore the rest
2327 2013-03-06 21:37:43 <petertodd> warren: Would you accept a 0-conf tx from a family member?
2328 2013-03-06 21:38:02 <Diablo-D3> and only repeat tx that have higher fees than ones already sent
2329 2013-03-06 21:38:14 <petertodd> Diablo-D3: It's a perfectly reasonable thing to do, and would make the double-spend replacement very visible.
2330 2013-03-06 21:38:30 <Diablo-D3> s/sent/repeated/
2331 2013-03-06 21:38:42 <petertodd> Diablo-D3: In fact, I like that visibility, because it'd be better than if a few big pools decided they'll have an out-of-band way of accepting higher fee tx's.
2332 2013-03-06 21:38:45 <Diablo-D3> it'd allow bitcoin clients to automatically fee ramp
2333 2013-03-06 21:38:46 rlifchitz has joined
2334 2013-03-06 21:38:50 <petertodd> Diablo-D3: At least the process is transparent.
2335 2013-03-06 21:38:52 <Diablo-D3> since they also build potential next blocks locally
2336 2013-03-06 21:38:52 <sipa> Goonie: you know what gitian is?
2337 2013-03-06 21:39:00 <warren> petertodd: ah, I see what you mean.
2338 2013-03-06 21:39:01 <Diablo-D3> and know what the min fee to get into a block is
2339 2013-03-06 21:39:06 <Goonie> its for reproducable builds, right?
2340 2013-03-06 21:39:25 <Diablo-D3> so clients would, basically, auto spend tx spam
2341 2013-03-06 21:39:34 <sipa> Goonie: yeah, it's a build system running in a VM, so that builds are bitwise identical, and get signed by developers' gpg keys
2342 2013-03-06 21:39:35 <Diablo-D3> and also try to get the fees right
2343 2013-03-06 21:39:36 <petertodd> Diablo-D3: auto-spend?
2344 2013-03-06 21:39:39 <Diablo-D3> er
2345 2013-03-06 21:39:42 <Diablo-D3> auto-double psend
2346 2013-03-06 21:39:47 <Diablo-D3> *spend
2347 2013-03-06 21:39:51 <Diablo-D3> lets pretend I can type
2348 2013-03-06 21:40:01 <sipa> Goonie: so we know people can (in theory) verify that the published builds match the source code
2349 2013-03-06 21:40:14 <petertodd> Diablo-D3: I purely mean that that transaction replacement is done if the replacing tx has a higher fee than the old tx.
2350 2013-03-06 21:40:18 <Diablo-D3> so like, you tell your bitcoin client, "spend up to x btc in fees"
2351 2013-03-06 21:40:24 <sipa> Goonie: unfortunately, very few people verify, and lately it has even become a problem to find enough people to do builds
2352 2013-03-06 21:40:29 nus- has quit (Ping timeout: 276 seconds)
2353 2013-03-06 21:40:30 <Diablo-D3> your tx gets bumped out of the next potential block
2354 2013-03-06 21:40:33 <petertodd> Diablo-D3: Heck, maybe it can be implemented right now with the existing replacement code...
2355 2013-03-06 21:40:40 <Diablo-D3> client automatically resends new tx with higher fee
2356 2013-03-06 21:40:50 <gmaxwell> petertodd: ... existing replacement code???
2357 2013-03-06 21:40:57 <Diablo-D3> thus pushing it back into the potential block
2358 2013-03-06 21:41:08 <petertodd> Diablo-D3: Oh, nah, that's not possibly unfortunately, because the tx you received is signed with their pubkey, not yours.
2359 2013-03-06 21:41:17 <Diablo-D3> petertodd: no no no, its your tx
2360 2013-03-06 21:41:22 <Goonie> sipa: I can build and check out the hash, and then sign manually. However I would not put my key into gitian, if that's how it works
2361 2013-03-06 21:41:30 <petertodd> gmaxwell: Yes, the code that does replacement but is disabled; anyway, I haven't looked.
2362 2013-03-06 21:41:34 <Diablo-D3> your client would automatically double spend your tx with higher fees when it realizes the fee is too low
2363 2013-03-06 21:41:38 <sipa> Goonie: ok
2364 2013-03-06 21:41:39 <TD> gmaxwell: you summoned me
2365 2013-03-06 21:41:48 <Diablo-D3> petertodd: basically, it turns it into a miners market
2366 2013-03-06 21:42:06 <Diablo-D3> petertodd: all we need on top of that is a p2p protocol for miners to tell clients what their fee structure is
2367 2013-03-06 21:42:13 <petertodd> Diablo-D3: Right, but no-one other than you can double-spend your tx. You can however create a tx resendign the funds of one you got, and with recursive fee evaluation, basically make the total fee bigger than a replacement of the parent tx.
2368 2013-03-06 21:42:14 <Goonie> sipa: also, I cannot audit gitian itself, since I'm mainly a Java dev
2369 2013-03-06 21:42:15 <Diablo-D3> petertodd: so miners can compete in said market
2370 2013-03-06 21:42:26 <Diablo-D3> petertodd: Im saying your client double spends your tx
2371 2013-03-06 21:42:31 <Diablo-D3> petertodd: but does so automatically
2372 2013-03-06 21:42:33 <gmaxwell> TD: what are your thoughts about the durability of unconfirmed txn sitting in the memory pool? should nodes let them get replaced with double spends? under what conditions?
2373 2013-03-06 21:42:38 <petertodd> Diablo-D3: Yeah, although for now, just looking at fee-per-KiB stats is pretty good.
2374 2013-03-06 21:42:56 <TD> satoshi mentioned such a thing once, but also said he thought the complexity wasn't worth it. at least not back then.
2375 2013-03-06 21:42:59 <Diablo-D3> petertodd: the problem with mining, right now, is its a one sided process
2376 2013-03-06 21:43:08 <petertodd> Diablo-D3: It's either costly (orphans) or annoying to game those stats.
2377 2013-03-06 21:43:13 <TD> given how many parts of the code would have to change and how subtle the required changes were
2378 2013-03-06 21:43:16 <EPiSKiNG-> question: will the most recent 100BTC transaction ever get a confirmation? Some have told me no 1LBv9QoqCtW57x3T8sME4TnUczNiWahdJP
2379 2013-03-06 21:43:16 <petertodd> Diablo-D3: One-sided how?
2380 2013-03-06 21:43:18 <TD> this is about increasing fees on a tx?
2381 2013-03-06 21:43:24 <petertodd> TD: Yes
2382 2013-03-06 21:43:24 <Diablo-D3> petertodd: clients are forced to overspend fees because they can't on the fly change fees on their tx
2383 2013-03-06 21:43:32 <petertodd> TD: replacement based on increased fees
2384 2013-03-06 21:43:52 <EPiSKiNG-> I have about 3 or 4 BTC transactions that haven't been confirmed in over 4 hours
2385 2013-03-06 21:44:00 <petertodd> Diablo-D3: Sure, but you'll probably be close; you assuming minute to minute evaluation?
2386 2013-03-06 21:44:00 <Diablo-D3> petertodd: JUST implementing double spend auto replace means 90% of the problem would be solved
2387 2013-03-06 21:44:04 <TD> i think fees are a distraction at this point in the systems evolution, to be honest. they aren't necessary to incentivise mining at the moment, so all they're doing is artificially imposing a cost on something that should be very cheap.
2388 2013-03-06 21:44:19 <Diablo-D3> petertodd: not minute to minute, but competing tx to competing tx
2389 2013-03-06 21:44:20 <TD> so complicated code changes that stand a chance of introducing subtle security bugs don't thrill me
2390 2013-03-06 21:44:31 aethero has joined
2391 2013-03-06 21:44:32 <gmaxwell> TD: the concern is just txn getting stuck waiting for confirmation. Earlier Jeff and Gavin made proposals to just expire mempool txn, Jeff after a timelimit, and gavins was more like "keep two blocks worth and always discard the lowest fee/priority"
2392 2013-03-06 21:44:37 <petertodd> Diablo-D3: Right, but mining is probabalistic anyway, so I suspect the best you can do is "close"
2393 2013-03-06 21:44:41 <TD> the recursive fee calculation seems safer, and even then i believe the patch had subtle bugs
2394 2013-03-06 21:44:45 <petertodd> Diablo-D3: Anyway, let the quants figure that one out.
2395 2013-03-06 21:44:48 <Diablo-D3> petertodd: if(my tx isn't in the next block anymore because of fees) { up fees; double spend; }
2396 2013-03-06 21:44:56 * TD shrugs
2397 2013-03-06 21:45:08 K1773R is now known as OFF!~K1773Rfre@www.darkgamex.ch|K1773R
2398 2013-03-06 21:45:11 <TD> i think people who run nodes should tell them how much resources they're willing to set aside for that node
2399 2013-03-06 21:45:18 <Diablo-D3> petertodd: so clients would auto-size fees correctly and not overspend on fees
2400 2013-03-06 21:45:19 <TD> and then the node should just fill up what it was given to the max
2401 2013-03-06 21:45:21 <petertodd> Diablo-D3: Ah, I see, yeah, that's reasonable. As I say, let people figure out the optimal way to do that; lots of possible approaches.
2402 2013-03-06 21:45:30 <Diablo-D3> thats the most optimal way
2403 2013-03-06 21:45:38 <Diablo-D3> without adding a new messaging protocol
2404 2013-03-06 21:45:44 <petertodd> Diablo-D3: Depends, maybe I don't care about the fee, and want it in the next block regardless?
2405 2013-03-06 21:45:45 <TD> some people won't mind devoting a lot of resources to keeping unconfirmed transactions around for a while. others will. i see no reason to require consistency.
2406 2013-03-06 21:45:57 <Diablo-D3> petertodd: then you set your max fee higher
2407 2013-03-06 21:45:58 <EPiSKiNG-> Is there an issue with unconfirmed transactions right now???
2408 2013-03-06 21:46:13 <gmaxwell> TD: as a resource consumption issue it seems odd.. right now the mempool os 0.03% of our memory usage. The concern isn't resource usage, it's allowing them to be doublespent so fees can be changed.
2409 2013-03-06 21:46:41 <Diablo-D3> petertodd: the client would automatically try to get into the next block regardless: the existing tx option in the GUI would be a maximum
2410 2013-03-06 21:46:44 <TD> yeah that sounds like a highly risky change to solve a problem that is better solved by pushing fees down to zero (ie, with large block sizes)
2411 2013-03-06 21:46:52 <petertodd> Diablo-D3: As I say, I'm not that interested in exactly what the client logic is, that is something that will be developed over time.
2412 2013-03-06 21:47:04 <TD> look how close we came to accidentally deleting the block subsidy check during the ultraprune refactorings
2413 2013-03-06 21:47:05 <Diablo-D3> TD: large block sizes are not the answer, although I'd like to see it enabled
2414 2013-03-06 21:47:08 <gavinandresen> gmaxwell: you're mis-stating why I want to memory-limit; I want to memory-limit to simplify the transaction relaying rules
2415 2013-03-06 21:47:16 <TD> that kind of possibility is quite scary. our testing is still quite weak.
2416 2013-03-06 21:47:25 <Diablo-D3> td: the problem is we need to cut down on spam
2417 2013-03-06 21:47:47 <Diablo-D3> so sinking the SDtanic would be great
2418 2013-03-06 21:47:52 <petertodd> Diablo-D3: Why is it spam, it pays fees? From the miner's point of view SD is not spam, stop saying it is.
2419 2013-03-06 21:47:53 <gmaxwell> gavinandresen: Huh. How does adding expiration simplify the relay rules at all?
2420 2013-03-06 21:48:06 <Diablo-D3> petertodd: SD doesn't pay enough fees.
2421 2013-03-06 21:48:10 <petertodd> Diablo-D3: Stop getting pissed off that some-one is out-bidding you for a limited resource.
2422 2013-03-06 21:48:17 <Diablo-D3> petertodd: a lot of heavy SD gamblers turn off fees
2423 2013-03-06 21:48:21 <gmaxwell> gavinandresen: (sorry, obviously I didn't get that)
2424 2013-03-06 21:48:29 MobiusL has quit (Remote host closed the connection)
2425 2013-03-06 21:48:31 <petertodd> Diablo-D3: For the UTXO consumption, yes, but in general, no.
2426 2013-03-06 21:48:33 <TD> users wallets can always rebroadcast if a tx doesn't confirm, but realistically it'd be annoying if i had to keep my wallet app running until it confirmed
2427 2013-03-06 21:48:41 <gavinandresen> gmaxwell: if you send too-low-fee or too-low-priority transactions that don't get into my (memory-limited) memory pool then they're not relayed
2428 2013-03-06 21:48:47 <petertodd> Diablo-D3: ...and those SD gamblers find they have the same conf-problem as anyone else.
2429 2013-03-06 21:48:51 <TD> i'd like to be able to do what i do today - broadcast a tx, close my app, and be pretty sure the network won't forget about it and it'll get into the next block
2430 2013-03-06 21:48:57 <sipa> TD: rebroadcasting should be responsability of the receiver, imho
2431 2013-03-06 21:48:58 <Diablo-D3> td: thats not what you'd need to do, the last tx you sent would be your final bid for blockspace
2432 2013-03-06 21:49:01 <TD> sipa: or both
2433 2013-03-06 21:49:07 <gavinandresen> gmaxwell: Right now we have ad-hoc rules for "too low fee, too low priority" -- I want to simplify that to exactly match the block filling fules
2434 2013-03-06 21:49:09 axhlf has joined
2435 2013-03-06 21:49:09 <gavinandresen> rules
2436 2013-03-06 21:49:11 <petertodd> TD: Then broadcast your tx with a reasonable fee and it will get confirmed.
2437 2013-03-06 21:49:17 <Diablo-D3> petertodd: /me shrugs
2438 2013-03-06 21:49:27 <TD> ah, but it's not me who really cares that the tx gets confirmed
2439 2013-03-06 21:49:30 <TD> it's the merchant
2440 2013-03-06 21:49:33 <Diablo-D3> petertodd: if SD can't be solved, then I don't want large block sizes
2441 2013-03-06 21:49:46 <TD> *i* know i'm not going to double spend, right? because i'm a trustworthy angel
2442 2013-03-06 21:49:48 <gmaxwell> gavinandresen: Ah! ... doesn't prevent you from burning a lot of bandwidth with it, I guess. Also makes it hard to know if your txn was good enough.
2443 2013-03-06 21:49:50 <petertodd> TD: The merchant, if their wallet is online, will see the tx, include it in their wallet, and rebroadcast as required.
2444 2013-03-06 21:49:52 <TD> that's why recursive fee calculations make sense
2445 2013-03-06 21:49:57 <Diablo-D3> td: what we're discussing is clients automatically doublespending, only using higher tx fees in each doublespend
2446 2013-03-06 21:50:04 Scrat has quit (Ping timeout: 252 seconds)
2447 2013-03-06 21:50:04 <TD> the merchant can decide what the fee should be (if any)
2448 2013-03-06 21:50:07 <gavinandresen> TD: you've already implemented "boomerang" logic for transactions?
2449 2013-03-06 21:50:13 <TD> yes, i know what's being discussed. it's an old idea.
2450 2013-03-06 21:50:17 <petertodd> TD: I still see rebroadcasts of nLockTime'd to 4000 years in the future tx's I made two months ago.
2451 2013-03-06 21:50:22 <petertodd> TD: (from others)
2452 2013-03-06 21:50:24 <Diablo-D3> td: clients already build potential next blocks using tx it already heard, and can reasonably tell if the tx they just spent will actually make it
2453 2013-03-06 21:50:28 <sipa> gavinandresen: boomerang logic?
2454 2013-03-06 21:50:28 <TD> gavinandresen: boomerang?
2455 2013-03-06 21:50:35 <Diablo-D3> td: so if it wont make it, double spend with higher tx fee
2456 2013-03-06 21:50:54 <gavinandresen> maybe I'm mis-remembering-- the idea of "I'll broadcast this txn to N of my peers, and see if I hear about it from the rest of them.
2457 2013-03-06 21:50:55 <Diablo-D3> td: so automatic bidding happens on block space, which benefits both clients and miners
2458 2013-03-06 21:51:00 <TD> petertodd: yeah, sure, if those nodes start to run out of memory it makes sense for them to forget about the transaction
2459 2013-03-06 21:51:03 gdoteof has joined
2460 2013-03-06 21:51:06 <TD> gavinandresen: oh yes. bitcoinj does that.
2461 2013-03-06 21:51:16 <gmaxwell> TD: even you aren't going to argue that the network should resist doublespends, then I guess I'll just go and adopt petertodd's "the network should always replace in mempool txn with ones that have higher priority/fee". (at least then it makes the risks more consistent)
2462 2013-03-06 21:51:18 Scrat has joined
2463 2013-03-06 21:51:18 <petertodd> TD: Right, but the merchant isn't going to run out of memory for transactions to them.
2464 2013-03-06 21:51:20 <TD> gavinandresen: it lets you spend unconfirmed change if it witnessed a bunch of nodes announce it. jim called that boomerang logic.
2465 2013-03-06 21:51:24 <gavinandresen> ⦠so that gives you a very good idea of whether or not the txn you broadcast made it into mempools
2466 2013-03-06 21:51:38 <TD> gmaxwell: i don't think letting people double spend their own transactions makes sense
2467 2013-03-06 21:51:42 <gdoteof> if i wanted to get the functionality of blockchain.info where i can enter an address to see the balance, can i do that with the bitcoin command line directly?
2468 2013-03-06 21:51:49 <gdoteof> or would i need to walk the blockchain and build my own database
2469 2013-03-06 21:51:59 <TD> gmaxwell: as i said already, satoshi was at least willing to consider it, but he also thought it wasn't worth the added risks/complexity, and i think he was right.
2470 2013-03-06 21:52:07 <Diablo-D3> its not more complex
2471 2013-03-06 21:52:14 <petertodd> <sigh> I should go and write a replacement by fees patch...
2472 2013-03-06 21:52:15 <sipa> gdoteof: bitcoind would need a full index from addresses to transactions for that; it doesn't need that, so it doesn't maintain one
2473 2013-03-06 21:52:16 <Diablo-D3> according to petertodd most of the code already exists
2474 2013-03-06 21:52:17 <TD> gavinandresen: yes, for now. if they delete my pending tx after two blocks â¦.
2475 2013-03-06 21:52:26 <petertodd> Diablo-D3: maybe, that was a guess
2476 2013-03-06 21:52:32 <gmaxwell> TD: IIRC satoshi wanted to only permit it under some conditions. Not just as a result of mempool fullness.
2477 2013-03-06 21:52:33 <Diablo-D3> petertodd: meh
2478 2013-03-06 21:52:36 <TD> sorry, any change to bitcoin is complex and risky, given how much is at stake
2479 2013-03-06 21:52:38 <gdoteof> sipa: okay that's what i thought
2480 2013-03-06 21:52:38 <Diablo-D3> petertodd: that makes it less viable then
2481 2013-03-06 21:52:57 <TD> gmaxwell: he didn't even want to permit it, it was more like, "your idea is workable but i don't think we should do it". maybe we can dig up the old thread.
2482 2013-03-06 21:53:09 <petertodd> Diablo-D3: Anyway, a really nice patch for miners, would be better ways of writing their own code to select what transactions they want in their blocks.
2483 2013-03-06 21:53:29 <petertodd> Diablo-D3: Maybe a "israwtxstandard" RPC call for instance.
2484 2013-03-06 21:53:38 <warren> gmaxwell: "the network should always replace in mempool txn with ones that have higher priority/fee" is essentially cancellation
2485 2013-03-06 21:53:52 <petertodd> Diablo-D3: And "add/remove tx from next block" calls.
2486 2013-03-06 21:53:52 <gmaxwell> warren: this is what I was trying to tell you earlier.
2487 2013-03-06 21:54:01 <Diablo-D3> petertodd: well, adding block lists would be nice
2488 2013-03-06 21:54:06 <warren> k
2489 2013-03-06 21:54:13 <Diablo-D3> petertodd: like "drop and do not repeat any tx going to these bitcoin addresses"
2490 2013-03-06 21:54:20 <TD> gavinandresen: what's the problem we're trying to solve here? mempools getting too big and nodes running out of ram?
2491 2013-03-06 21:54:23 <petertodd> Diablo-D3: Yes, easy to do if tx chosing is all done by some external bit of python code or something.
2492 2013-03-06 21:54:26 <gmaxwell> warren: cancellation is equal to but more complicated than just freely allowing the preferred doublespend.
2493 2013-03-06 21:55:00 <petertodd> TD: More that if you realize you should have sent your tx with a higher fee in the first place, right now you can't.
2494 2013-03-06 21:55:08 <gmaxwell> ... that isn't a problem now, and hardly even a conceivable problem.
2495 2013-03-06 21:55:25 <TD> the whole idea of users picking fees for their own transactions never made any sense to me anyway. it's not the user who cares about double spend risk, nor are they in a position to judge what the correct fee is.
2496 2013-03-06 21:55:40 <TD> in theory, futuristic merchants may do a risk analysis of each customer as they do today.
2497 2013-03-06 21:55:56 <Diablo-D3> td: but what I just described fixes that
2498 2013-03-06 21:55:59 <TD> so then the fee would be a function of data the user doesn't even have.
2499 2013-03-06 21:56:12 <petertodd> TD: Well, ideally there should be a mechanism for the recipient to pay the tx fee, recursive eval is one way, albeit inefficient.
2500 2013-03-06 21:56:13 <Diablo-D3> td: clients already build potential next blocks (due to the miner code)
2501 2013-03-06 21:56:14 <TD> better that users always generate free transactions
2502 2013-03-06 21:56:20 <TD> Diablo-D3: SPV clients don't
2503 2013-03-06 21:56:27 <TD> and 99%+ of end users will be on those in future
2504 2013-03-06 21:56:28 grau has joined
2505 2013-03-06 21:56:29 <helo> sorry to interject... foundation fees will retarget apr 1?
2506 2013-03-06 21:56:31 <Diablo-D3> meh
2507 2013-03-06 21:56:49 <Diablo-D3> TD: well, then we go onto plan B, which I also described earlier
2508 2013-03-06 21:57:06 <Diablo-D3> TD: a protocol to ask all of bitcoin who's mining and what their fees are for x potential tx
2509 2013-03-06 21:57:19 <Diablo-D3> td: and then set fee accordingly
2510 2013-03-06 21:57:48 <TD> you don't even know that per-tx fees will ever be required or used in the way you imagine!
2511 2013-03-06 21:57:59 <Diablo-D3> no, but I know they're used that way now
2512 2013-03-06 21:58:01 <TD> so i'm not a fan of hugely complicated global fee consensus systems either
2513 2013-03-06 21:58:07 <warren> Diablo-D3: how do you ensure the responses are truthful?
2514 2013-03-06 21:58:08 <Diablo-D3> thats not complicated at all
2515 2013-03-06 21:58:13 <TD> you know, in the early days of bitcoin, nobody attached fees at all.
2516 2013-03-06 21:58:19 <TD> we could get back to that quite easily if we wanted to
2517 2013-03-06 21:58:30 <Diablo-D3> warren: you do an analysis against the average in the past 10 blocks
2518 2013-03-06 21:58:44 <Diablo-D3> td: yes, and my system would allow that
2519 2013-03-06 21:59:02 <Diablo-D3> td: you'd have miners saying 0 fees are fine
2520 2013-03-06 21:59:10 <Diablo-D3> so clients would start competing for free space in their blocks
2521 2013-03-06 21:59:26 <warren> competing how?
2522 2013-03-06 21:59:43 <TD> what free space? recall that i support making the block size limit floating or non-existent
2523 2013-03-06 21:59:56 <Diablo-D3> TD: then no competition in that case
2524 2013-03-06 21:59:57 <TD> if that happens there will always be free space, and no competition for block space
2525 2013-03-06 21:59:58 <Diablo-D3> just spam away
2526 2013-03-06 22:00:01 <TD> yup
2527 2013-03-06 22:00:15 <Diablo-D3> but miners who can spew out physically shorter blocks will win
2528 2013-03-06 22:00:41 <TD> not necessarily by any means
2529 2013-03-06 22:00:52 <Diablo-D3> the announcement will take longer for longer blocks
2530 2013-03-06 22:01:06 <TD> hardly. we're talking about hashes here. anyway this has become another block size debate
2531 2013-03-06 22:01:19 <Diablo-D3> while the miner reward still exists, an optimal miner would actually not ship ANY tx
2532 2013-03-06 22:01:21 <TD> to sum up - no, i don't think we should allow replacement of transactions in the memory pool. neither did satoshi 3 years ago.
2533 2013-03-06 22:01:46 grau has quit (Remote host closed the connection)
2534 2013-03-06 22:01:51 <TD> and i don't want to write a ton of code so multibit and the android wallet can try to divine what the magic fee numbers are then have transactions get stuck in limbo if they get it wrong
2535 2013-03-06 22:01:57 <mogri> i would suspect that
2536 2013-03-06 22:02:06 <mogri> confirming tx might actually be a bigger game now
2537 2013-03-06 22:02:12 <TD> Diablo-D3: and yet they do. so, what is the purpose of this debate again?
2538 2013-03-06 22:02:21 <mogri> than mining ?
2539 2013-03-06 22:02:26 <Diablo-D3> td: there wasn't a debate, you tried to change it into a block size one
2540 2013-03-06 22:02:46 <TD> hmm
2541 2013-03-06 22:02:48 <TD> well whatever
2542 2013-03-06 22:03:02 <Diablo-D3> mogri: it sorta is, but Ive never seen a block EVER that had significant fees
2543 2013-03-06 22:03:07 <TD> let's just wait until lots of users are complaining about slow confirmation times
2544 2013-03-06 22:03:50 <Diablo-D3> mogri: in fact I've never seen a block with more than 5 BTC in fees
2545 2013-03-06 22:04:08 RBecker is now known as rbecker
2546 2013-03-06 22:04:35 freakazoid_ has joined
2547 2013-03-06 22:05:12 MobiusL has joined
2548 2013-03-06 22:05:49 * sipa seems to have forgotten C++
2549 2013-03-06 22:06:29 freakazoid has quit (Ping timeout: 276 seconds)
2550 2013-03-06 22:08:16 discrete has joined
2551 2013-03-06 22:10:05 <helo> TD: they already are
2552 2013-03-06 22:10:18 <helo> for some values of lots, i guess
2553 2013-03-06 22:10:46 Aaron_TangCryp has joined
2554 2013-03-06 22:12:09 <TD> is there a thread?
2555 2013-03-06 22:12:24 <helo> no, just some people in -otc complaining
2556 2013-03-06 22:12:39 pacpac has joined
2557 2013-03-06 22:12:40 <TD> sipa: what do you think the slowest part of block acceptance is, assuming a full sigcache? writing to leveldb?
2558 2013-03-06 22:14:17 <beethoven8201> http://blockchain.info/tx-index/58760578/6ea6864884934ad40ab01c3ae798ecccacbc8ba7ea55b1ff78f88ae6c6140daa
2559 2013-03-06 22:14:43 <TD> assuming most of the txns in a block were already in the mempool, relaying a block should be extremely fast. you don't have to wait for it to hit disk to start relaying
2560 2013-03-06 22:14:53 <beethoven8201> nearly 3 hours of no confirmation
2561 2013-03-06 22:15:05 <sipa> TD: i've been willing to change that
2562 2013-03-06 22:15:25 <TD> beethoven8201: :(
2563 2013-03-06 22:15:28 <sipa> TD: make a "block data manager" to keeps dirty blocks and block index entries in memory, and writes them in consistent order to disk
2564 2013-03-06 22:15:34 <sipa> TD: in a separate thread
2565 2013-03-06 22:15:53 <sipa> TD: so validation never needs to wait for output
2566 2013-03-06 22:16:03 <helo> anyone have a poolsz graph over time?
2567 2013-03-06 22:16:13 <warren> beethoven8201: you won't have any solution here anytime soon, you're best off double spending to unstuck that
2568 2013-03-06 22:16:14 <TD> sipa: does it need to be in a separate thread? you could send the invs after deciding the block is valid and before writing to disk, on the assumption that by the time the writes are finished the getdata will have arrived
2569 2013-03-06 22:16:19 <gmaxwell> beethoven8201: three hours ago that transaction was spending an unconfirmed input. It has no fees and is low priority.
2570 2013-03-06 22:17:45 <sipa> TD: that would be very ugly, code-wise, i think
2571 2013-03-06 22:17:51 pacpac has quit (Quit: Leaving)
2572 2013-03-06 22:18:26 <beethoven8201> gmaxwell: I cliccked through all the inputs, they all seem confirmed?
2573 2013-03-06 22:18:29 toffoo has joined
2574 2013-03-06 22:19:06 <sipa> TD: or at least require a large refactor to do properly, as the validation is done in several stages, the last of which is only called after the block is written to disk
2575 2013-03-06 22:19:33 <sipa> TD: hmm, i'm too tired now to think about it; i'll have another look later
2576 2013-03-06 22:19:41 <muhoo> is jim burton around here at all?
2577 2013-03-06 22:19:47 <sipa> very rarely
2578 2013-03-06 22:19:59 gritcoin has joined
2579 2013-03-06 22:19:59 <TD> sipa: or use the original suggestion (from luke?) to announce via an inv as soon as a block that has required difficulty is seen, then begin validating the contents
2580 2013-03-06 22:20:10 <TD> sipa: though relay time probably isn't an issue right now anyway
2581 2013-03-06 22:20:24 <muhoo> i was goign to ask if he'd accept a patch to move his fork of bitcoinj to a different groupid so i can have td's bitcoinj and his bitcoinj in my .m2 without maven getting all tangled up
2582 2013-03-06 22:21:37 <muhoo> maybe i'll just do it and throw it over the wall
2583 2013-03-06 22:21:49 <sipa> TD: i'm not sure i like that; personally, i think the largest speed improvement would come from not waiting for IO during validation (that would also speed up IBD. as the time single-threaded decreases)
2584 2013-03-06 22:22:18 <gmaxwell> beethoven8201: they are now, but the at least a quick glance it looked like some were only very recently confirmed.
2585 2013-03-06 22:22:32 Grouver has quit (Quit: HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!)
2586 2013-03-06 22:22:35 <gmaxwell> I wish there were an explorer that showed the priority.
2587 2013-03-06 22:22:36 Aaron_TangCryp is now known as Aaron_Away
2588 2013-03-06 22:22:51 <TD> yeah
2589 2013-03-06 22:22:57 <warren> beethoven8201: what did you use to spend unconfirmed inputs?
2590 2013-03-06 22:23:02 <sipa> anyone willing to try building https://github.com/sipa/secp256k1/blob/master/secp256k1.cpp and explain the compiler errors?
2591 2013-03-06 22:23:07 <sipa> i don't understand it at all
2592 2013-03-06 22:23:08 <muhoo> someone was just asking about that, IIRC he was told that you can calculate it
2593 2013-03-06 22:23:12 <TD> though really, the reason for the slow confirm is simple - block size limit
2594 2013-03-06 22:23:23 <sipa> (need g++ 4.5 on amd64)
2595 2013-03-06 22:23:35 <TD> there's now something approaching $120 worth of fees in unconfirmed transactions, according to b.i
2596 2013-03-06 22:23:39 <beethoven8201> warren: I'm the receiver
2597 2013-03-06 22:23:43 <TD> i wonder which pool will be the first to try and scoop them up
2598 2013-03-06 22:23:46 <beethoven8201> EPiSKiNG-: was the sender
2599 2013-03-06 22:24:36 <gmaxwell> TD: 80% of txn in a block I checked earlier were one user.. SD... This doesn't suggest helthy usage.
2600 2013-03-06 22:24:47 <TD> :(
2601 2013-03-06 22:24:48 <gmaxwell> healthy*
2602 2013-03-06 22:24:51 denisx has quit (Quit: denisx)
2603 2013-03-06 22:25:22 <mogri> sipa, one second
2604 2013-03-06 22:25:49 <sipa> it seems as if it doesn't see the parent class GroupElem<F> in GroupElemJac<F>
2605 2013-03-06 22:27:09 ovidiusoft has quit (Ping timeout: 245 seconds)
2606 2013-03-06 22:28:17 mitzip has joined
2607 2013-03-06 22:30:00 <mogri> it does, *but* protected members aren't inherited in this way. it works with this->
2608 2013-03-06 22:30:26 twixed has quit (Quit: Leaving)
2609 2013-03-06 22:30:48 Aaron_Away is now known as Aaron_TangCryp
2610 2013-03-06 22:30:56 <sipa> wow, really? :o
2611 2013-03-06 22:31:53 <Aaron_TangCryp> Anyone know what's up with the blockchain?
2612 2013-03-06 22:32:30 <gmaxwell> Aaron_TangCryp: ask a better question, please?
2613 2013-03-06 22:32:53 reizuki__ has joined
2614 2013-03-06 22:32:53 reizuki__ has quit (Changing host)
2615 2013-03-06 22:32:53 reizuki__ has joined
2616 2013-03-06 22:35:12 <mogri> yes, it's a quirk with templates. templates do not have a combined scope, so you have to wait until the actual resulting class is constructed
2617 2013-03-06 22:35:38 <mogri> thusly, `this` should be used in template code to reduce ambiguity
2618 2013-03-06 22:36:17 <muhoo> TD: isn't there a pool that blocks SD? why hasn't it scooped those up?
2619 2013-03-06 22:36:29 <TD> eligius
2620 2013-03-06 22:37:12 <Aaron_TangCryp> gmaxwell, Anyone know why No tx's are getting confirmed
2621 2013-03-06 22:37:14 <Aaron_TangCryp> LO
2622 2013-03-06 22:37:16 <Aaron_TangCryp> LOL*
2623 2013-03-06 22:37:50 <TD> muhoo: eligius is small, it only has enough hashpower to find a block a few times a day at most
2624 2013-03-06 22:37:53 <TD> muhoo: http://eligius.st/~wizkid057/newstats/
2625 2013-03-06 22:38:13 <sipa> mogri: i see
2626 2013-03-06 22:38:14 <gmaxwell> Aaron_TangCryp: the last block was 46 minutes ago.
2627 2013-03-06 22:38:36 <sipa> mogri: thanks, i thought i was going mad :p
2628 2013-03-06 22:38:37 <gmaxwell> Aaron_TangCryp: it is reasonable, expected, and normal operation that there are sometimes larger than average gaps between blocks.
2629 2013-03-06 22:39:08 <gmaxwell> ;;bc,tblb 46 minutes
2630 2013-03-06 22:39:16 <gribble> Error: There's really no reason why you should have underscores or brackets in your mathematical expression. Please remove them.
2631 2013-03-06 22:39:18 <Aaron_TangCryp> gmaxwell, FC4B has orders from up to 5 hours ago with 0 confs
2632 2013-03-06 22:39:36 <gmaxwell> ;;bc,tblb 46 m
2633 2013-03-06 22:39:37 <gribble> Error: There's really no reason why you should have underscores or brackets in your mathematical expression. Please remove them.
2634 2013-03-06 22:39:41 <gmaxwell> ;;bc,tblb 46
2635 2013-03-06 22:39:42 <gribble> Error: There's really no reason why you should have underscores or brackets in your mathematical expression. Please remove them.
2636 2013-03-06 22:39:44 <gmaxwell> die
2637 2013-03-06 22:39:50 <gmaxwell> Aaron_TangCryp: what is FC4B?
2638 2013-03-06 22:40:11 <Aaron_TangCryp> gmaxwell, www.fc4b.com
2639 2013-03-06 22:41:21 <muhoo> hmm, methinks for the success of my own business, it's worth investing in some mining and join elgius
2640 2013-03-06 22:41:52 <muhoo> heh, for the *possibility* of my own business. 4-hour confirms would suck.
2641 2013-03-06 22:42:13 <gmaxwell> muhoo: eligius also carries patches that let it selectively prioritize transactions, they have an agreement with mtgox for example to help get txn mtgox is interested in mined.
2642 2013-03-06 22:42:18 <TD> Aaron_TangCryp: yes. right now transactions are stacking up and not confirming because the network ran out of block space
2643 2013-03-06 22:42:30 <TD> Aaron_TangCryp: see the thread in the mining subforum about that
2644 2013-03-06 22:42:38 <Aaron_TangCryp> TD how can this be resolved? and oh okay I will
2645 2013-03-06 22:42:40 <TD> this is really something of a disaster.
2646 2013-03-06 22:42:43 <gmaxwell> well, there is plenty of space, but 80% of it is used by SD.
2647 2013-03-06 22:42:46 <TD> Aaron_TangCryp: miners have to change their configurations
2648 2013-03-06 22:42:56 <TD> phrased another way, there isn't plenty of space ...
2649 2013-03-06 22:43:03 <muhoo> TD: you missed the fun this morning :-)
2650 2013-03-06 22:43:08 <gmaxwell> There is little reason to believe that there wouldn't be 80% of it used by SD with the soft limit bumpted to 500k.
2651 2013-03-06 22:43:21 HM has quit (Remote host closed the connection)
2652 2013-03-06 22:43:28 <TD> we need miners to be more closely monitoring the sizes of blocks and the various pools
2653 2013-03-06 22:43:41 <muhoo> yep, i'm now in the "increasing the limit won't fix shit" camp. unwillingly.
2654 2013-03-06 22:43:41 <TD> right now our monitoring tools are non-existent though :(
2655 2013-03-06 22:43:53 <TD> gmaxwell: i am skeptical demand for SD is infinite
2656 2013-03-06 22:43:58 <gmaxwell> TD: gavin was saying earlier that SD also increased their fees to 0.001 BTC.
2657 2013-03-06 22:44:12 <TD> yeah it seems sometimes they have done that
2658 2013-03-06 22:44:18 <helo> based on my experience in the casino industry, gambling demand is astronomical
2659 2013-03-06 22:44:20 <TD> vorhees needs to be yelled at. BitInstant has to be suffering as well
2660 2013-03-06 22:44:38 <gmaxwell> which means they could have 10x demand while still having higher fees than all the non-SD txn currently and paying no more.
2661 2013-03-06 22:44:55 <midnightmagic> TD: He has been yelled at. They don't care dude.
2662 2013-03-06 22:45:06 <muhoo> i have to say, the best fast-acting hack to get around this is: more sd-blocking mining pools. as icky as mining-censorship is in the long run
2663 2013-03-06 22:45:18 <gmaxwell> who says its even real demand? most of these txn are just coming from prior bets. Could just be one user.
2664 2013-03-06 22:45:39 <TD> yeah, that was my conclusion as well. a lot of those txn look botted
2665 2013-03-06 22:45:49 <petertodd> TD: Anyway, SD isn't even the beginning of our worries; for instance, imagine if someone makes some timestamp by unspendable UTXO (but not provably unspendable) and makes it part of a popular standard? Or somone implements namecoin again, but on Bitcoin? As long as tx's are cheap, any of these nasty things can happen, and there is nothing that would stop it.
2666 2013-03-06 22:46:00 <gmaxwell> muhoo: the censorship stuff doesn't avoid me, people should assume if their txn can be blocked they will be blocked. Better to transact in ways that can't be selectively blocked.
2667 2013-03-06 22:46:07 freakazoid has joined
2668 2013-03-06 22:46:12 <petertodd> TD: We already had those guys who wanted to turn bitcoin into a PKI system.
2669 2013-03-06 22:46:21 freakazoid_ has quit (Ping timeout: 245 seconds)
2670 2013-03-06 22:46:24 <muhoo> gmaxwell: wow, excellent point. hmm.
2671 2013-03-06 22:46:52 <TD> it's rather circular though. if txns are cheap then inefficiency doesn't matter muc
2672 2013-03-06 22:46:58 <TD> much
2673 2013-03-06 22:47:03 <petertodd> muhoo: More importantly, if you pay fees, and mining stays decentralized, someone will pick your TX up, so censorship is only going to have limits economically.
2674 2013-03-06 22:47:14 <TD> the problem we have here is that transactions are expensive, and one entity is profitable enough to outbid the kinds of users we actually do want
2675 2013-03-06 22:47:18 <gmaxwell> muhoo: blockable txn are an ecosystem wide risk. If XXX is blockable, then how long until some crazy regulator thinks they can command bitcoin bussinesses to block it? Better that everyone can say "there is nothing to block".
2676 2013-03-06 22:47:51 <gmaxwell> TD: TXN imply data that must be stored by someone forever. They're fundimentally costly, regardless of the fees.
2677 2013-03-06 22:48:00 <muhoo> gmaxwell: well if the txn's look identical, there's no way to tell which txn is what, right? SD's business is built upon trackable 1SD addresses, or am i misunderstanding?
2678 2013-03-06 22:48:28 <gmaxwell> muhoo: it could just as equally be private between the reciever and sender. e.g. on the website.
2679 2013-03-06 22:48:49 <muhoo> right, so sd should do their shit off-chain, is that right?
2680 2013-03-06 22:49:04 <midnightmagic> except it would mean they have to maintain user balances.
2681 2013-03-06 22:49:16 <midnightmagic> and why would a lazy person do that?
2682 2013-03-06 22:49:17 <gmaxwell> muhoo: there are a bunch of ways to do it.
2683 2013-03-06 22:49:58 <gmaxwell> midnightmagic: doesn't even have to maintain balances/accounts. They could have session ephemerial 'accounts'.
2684 2013-03-06 22:50:06 <muhoo> i've avoided the whole mining world, but now i'm curious. where can i get some basics on how to set up a miner? certainly not here (i hope).
2685 2013-03-06 22:50:38 CodeShark has joined
2686 2013-03-06 22:50:42 HM has joined
2687 2013-03-06 22:50:54 <gmaxwell> You punch in your refund address. It says "great, to play pay to 1apple" then you send it and play as much as you want and either walk away or hit cashout... and after some delay it just pays your balance out to you. No actual account needed.
2688 2013-03-06 22:51:16 <gmaxwell> and it can still do cryptographic proofs of the bets, though it seems no one cares.
2689 2013-03-06 22:52:38 <HM> it's still pretty weak isn't it?
2690 2013-03-06 22:52:44 <HM> we discussed it previously
2691 2013-03-06 22:52:53 <gmaxwell> yes. It proves less than some people think it proves.
2692 2013-03-06 22:53:31 freakazoid has quit (Remote host closed the connection)
2693 2013-03-06 22:53:33 <gmaxwell> and if they really believe their current formula is essential to their business, they could offer the old formula concurrently. ... it _looks_ like the overwhelming majority of their volume is from a few users, presumably those users would prefer the much faster and lower fee direct interface.
2694 2013-03-06 22:54:01 <Aaron_TangCryp> TD can I have a link to that thread you were talking about?
2695 2013-03-06 22:54:15 <TD> https://bitcointalk.org/index.php?topic=149668.0
2696 2013-03-06 22:54:20 freakazoid has joined
2697 2013-03-06 22:55:51 <muhoo> gmaxwell: wait, so... someone could come up with a COMPETITOR to SD, that did it right, and market it as lower fees to the end user?
2698 2013-03-06 22:56:02 <muhoo> and... faster confirmations?
2699 2013-03-06 22:56:20 <muhoo> and, make a metric ass-load of money, while crowding out SD at the same time?
2700 2013-03-06 22:56:38 <muhoo> and unconstipating the blockchain?
2701 2013-03-06 22:56:51 <sipa> muhoo: they'll have to fight against SD's network effect
2702 2013-03-06 22:57:07 * muhoo smells a robin hood opportunity
2703 2013-03-06 22:57:25 <TD> SD has a network effect?
2704 2013-03-06 22:57:28 <TD> i don't see how
2705 2013-03-06 22:57:49 <muhoo> i think i may have found an air shaft in the death star
2706 2013-03-06 22:57:55 <TD> the brutal reality is that SD defined a new market very effectively and - surprise - they are loathe to tweak the winning formula
2707 2013-03-06 22:58:09 <phantomcircuit> sigh
2708 2013-03-06 22:58:11 <gmaxwell> muhoo: people have made all kinds of competitors. They get no traffic. This has fed some conspiracy theories. But who knows.
2709 2013-03-06 22:58:11 <TD> despite the fact that it's become a very expensive one for them
2710 2013-03-06 22:58:20 Ukto has joined
2711 2013-03-06 22:58:24 <TD> they're paying 5 dollar cent fees for some transactions that are barely 10-15 cents in size
2712 2013-03-06 22:58:29 <phantomcircuit> muhoo, i've actually thought about doing that except for the whole illegalness aspect
2713 2013-03-06 22:58:37 <Ukto> can anyone tell me why http://blockchain.info/tx-index/58742145/6fe27fb737471dec3793de3231552f09b64b28f2157bc4700ee540950fe7d368 has not had any confirmations in 5~6hrs? fee was even paid
2714 2013-03-06 22:58:47 <petertodd> TD: They take fees out of your winnings for small txouts...
2715 2013-03-06 22:58:50 <muhoo> phantomcircuit: oh, what they are doing is illegal? that's an even bigger air shaft
2716 2013-03-06 22:58:51 <TD> Ukto: it just confirmed?
2717 2013-03-06 22:59:04 <gmaxwell> Either the conspiracy theories are true, or the formula is "be called satoshi dice" or first mover advantage is surprisingly large. (or all of the above)
2718 2013-03-06 22:59:06 <Ukto> figures
2719 2013-03-06 22:59:24 <TD> Ukto: things are just generally hosed right now because miners have run up against a soft limit on how big the blocks they'll make are
2720 2013-03-06 22:59:26 <Ukto> hours and hours, and then I ask and it confims
2721 2013-03-06 22:59:29 <phantomcircuit> muhoo, they're operating a casino without a license from the state of new york and accepting any and all comers
2722 2013-03-06 22:59:32 <TD> Ukto: so expect slow confirmations for a while until that's resolved
2723 2013-03-06 22:59:45 <Ukto> alright, thanks
2724 2013-03-06 22:59:46 <phantomcircuit> muhoo, they are not complying with FinCEN regulations on reporting of large gambling payouts
2725 2013-03-06 22:59:56 <phantomcircuit> muhoo, so yeah im preeetttty sure it's illegal
2726 2013-03-06 22:59:57 <TD> gmaxwell: given the botted transactions, the whole "are they playing with themselves" thing does seem a bit more credible
2727 2013-03-06 23:00:04 <phantomcircuit> will they actually get in trouble? who the fuck knows
2728 2013-03-06 23:00:27 <TD> muhoo: online gambling is illegal in new york
2729 2013-03-06 23:00:48 <TD> muhoo: it was created by a brit and the servers are/were in ireland. however, for some reason (wtf?) it is now owned by Erik Vorhees of BitInstant
2730 2013-03-06 23:01:01 <TD> because, you know, trolling Mitt Romney wasn't enough for that guy
2731 2013-03-06 23:01:15 <gmaxwell> even in places where the gambling is lawful, its regulated in ways which would be hard to comply with. E.g. in the UK you cannot let minors play.
2732 2013-03-06 23:01:22 xenesis has joined
2733 2013-03-06 23:01:28 <TD> yeah
2734 2013-03-06 23:01:43 <HM> bitcoin only has to care about paying
2735 2013-03-06 23:01:53 <TD> SD is a nice academic experiment in provably fair gaming, and has value as such. as an actual business, it's a lot more questionable
2736 2013-03-06 23:02:10 <HM> if a 16 year old lends his dad money to gamble, that's none of the UK governments business, despite the fact the 16 year old cannot gamble
2737 2013-03-06 23:02:14 gritcoin has quit (Quit: gritcoin)
2738 2013-03-06 23:02:23 <TD> hey, look at the bright side though
2739 2013-03-06 23:02:35 <TD> a sudden seize-up of tx confirmation might pop the current bubble :)
2740 2013-03-06 23:02:52 xenesis has quit (Quit: xenesis)
2741 2013-03-06 23:03:07 <warren> did we actually see a seize up? No.
2742 2013-03-06 23:03:31 <muhoo> it's a slowdown, for sure
2743 2013-03-06 23:04:40 <muhoo> well i have to say this whole whirlwind is so fascinating i haven't done any fiat-paid work in a week.
2744 2013-03-06 23:04:45 <TD> well, there have been 3 people complaining about large transactions that take hours to confirm, in the last 20 minutes or so
2745 2013-03-06 23:04:47 xenesis has joined
2746 2013-03-06 23:05:00 <TD> and bitpay is suffering too. steven just emailed me and gavin.
2747 2013-03-06 23:05:03 <TD> so yes
2748 2013-03-06 23:05:06 <TD> we're seeing a seize-up
2749 2013-03-06 23:05:22 <HM> huh?
2750 2013-03-06 23:05:28 <HM> why is there a seize up?
2751 2013-03-06 23:05:40 <muhoo> a seize up at a moment when CNN is writing stories, and large sudden new visibility
2752 2013-03-06 23:05:47 <muhoo> lovely
2753 2013-03-06 23:05:50 <gmaxwell> HM: the blocks are at the soft limit almost exclusively with SD transactions.
2754 2013-03-06 23:05:51 <TD> because the rate at which new transactions are being created is higher than the rate miners are confirming them
2755 2013-03-06 23:06:12 <gmaxwell> HM: and so very few joe average txn are getting through right now.
2756 2013-03-06 23:06:18 <HM> but if you offer a higher fee you should get through
2757 2013-03-06 23:06:23 <HM> that's how it's supposed to work? :S
2758 2013-03-06 23:06:29 <muhoo> so, am i off-base by suggesting the immediate patch to get the system running again is moar miners?
2759 2013-03-06 23:06:40 xenesis has quit (Client Quit)
2760 2013-03-06 23:06:40 <helo> because sd raised their default fee above the default tx fee?
2761 2013-03-06 23:07:43 <muhoo> i mean, i'm an ops guy. i can't help looking at this as if it were a system groaning under load, and the pagers are going off, and somethign needs to be done
2762 2013-03-06 23:07:52 <helo> muhoo: they just have to change a constant and recompile, or provide a -blockmaxsize=N with N > 250000
2763 2013-03-06 23:08:03 <gmaxwell> helo: there is NO RECOMPILE
2764 2013-03-06 23:08:05 <muhoo> helo: IIRC to increase blocksize is a configuration file change
2765 2013-03-06 23:08:15 <warren> good luck getting the miners to update their bitcoind quickly, even if this channel came up with a solution
2766 2013-03-06 23:08:31 <muhoo> warren: no, they just need to change a conf file and restart, IIUC
2767 2013-03-06 23:08:43 <Happzz> what's SD?
2768 2013-03-06 23:08:43 <freewil> gmaxwell, what is the soft limit
2769 2013-03-06 23:08:45 <warren> muhoo: are mining pools paying attention?
2770 2013-03-06 23:08:51 <gmaxwell> freewil: 250k.
2771 2013-03-06 23:09:00 xenesis has joined
2772 2013-03-06 23:09:04 gritcoin has joined
2773 2013-03-06 23:09:09 <TD> warren: not really, no. most don't seem to show any awareness there even is a limit.
2774 2013-03-06 23:09:15 <TD> see this as a training exercise for the pool operators :)
2775 2013-03-06 23:09:20 <petertodd> (checking) Yup, so out of the past 7 tx's my timestamper has created, all but one confirmed in the next block with 5mBTC fees.
2776 2013-03-06 23:09:20 <HM> miners have no incentive to care about dropped transactions though do they
2777 2013-03-06 23:09:22 <warren> muhoo: there's also economic disincentive to exclude SD. mining pools might want a bidding war of tx fees.
2778 2013-03-06 23:09:32 <Happzz> ... what's SD?
2779 2013-03-06 23:09:35 <muhoo> HM: if inaction causes a crash, maybe they do
2780 2013-03-06 23:09:36 <petertodd> The exception confirmed the block after.
2781 2013-03-06 23:09:40 <muhoo> HM: satoshi dice
2782 2013-03-06 23:09:44 <muhoo> Happzz: satoshi dice
2783 2013-03-06 23:09:47 <gmaxwell> Anyone check to see what the largest fee (per kb) being left on the table is right now in the default settings?
2784 2013-03-06 23:09:48 <muhoo> HM: sorry
2785 2013-03-06 23:09:51 <freewil> gmaxwell, so what is meant by "soft"
2786 2013-03-06 23:09:52 <Happzz> and what's the issue with SD?
2787 2013-03-06 23:10:02 <HM> brb my video drivers are growning at me
2788 2013-03-06 23:10:07 <muhoo> Happzz: look on the wiki page for it :-)
2789 2013-03-06 23:10:09 <gmaxwell> freewil: that it's just a config knob to increase it.
2790 2013-03-06 23:10:11 HM has quit ()
2791 2013-03-06 23:10:13 <petertodd> gmaxwell: I'm guessing not even 5mBTC
2792 2013-03-06 23:10:16 BTC_Bear has joined
2793 2013-03-06 23:11:03 <gmaxwell> petertodd: checking is better than guessing.
2794 2013-03-06 23:11:28 <TD> a miner who set a 1mb block limit could claim an extra $40 ish, i guess
2795 2013-03-06 23:11:34 <petertodd> gmaxwell: gimme a sec to write a script...
2796 2013-03-06 23:11:39 <TD> judging from the current fx rate and b.infos report on pending fees
2797 2013-03-06 23:11:47 <TD> ah ha
2798 2013-03-06 23:11:51 <TD> we have a 418kb block
2799 2013-03-06 23:11:56 <freewil> so what happens when two nodes connected have diff block size settings
2800 2013-03-06 23:12:04 <TD> presumably they set the limit to 500kb and the fees to enter the last 80kb are too high still :(
2801 2013-03-06 23:12:16 HM has joined
2802 2013-03-06 23:12:30 <gmaxwell> TD: restarting your node flushes the memory pool.
2803 2013-03-06 23:12:42 <gmaxwell> TD: and you'll never learn again the txn you lose, usually.
2804 2013-03-06 23:12:42 OneMiner is now known as DoMATH
2805 2013-03-06 23:12:46 <TD> can that be right? b.i is reporting 96btc of fees
2806 2013-03-06 23:12:49 <TD> in the mempool!
2807 2013-03-06 23:12:55 <gmaxwell> TD: so if they did change settings they probably took a bunch out of line.
2808 2013-03-06 23:12:59 DoMATH is now known as OneMiner
2809 2013-03-06 23:13:02 <TD> yeah
2810 2013-03-06 23:13:12 <gmaxwell> TD: we sometimes have goofted up txn, e.g. ones with 100 BTC in fees.
2811 2013-03-06 23:13:19 <muhoo> if elgius is blocking SD and increases its block size, will it claim al those?
2812 2013-03-06 23:13:46 <gmaxwell> muhoo: what if the 96 BTC in fees is mostly SD? :P
2813 2013-03-06 23:13:47 <TD> we need a better tool to monitor the mempool
2814 2013-03-06 23:13:50 BenderCoin has quit (Ping timeout: 250 seconds)
2815 2013-03-06 23:13:54 grau has joined
2816 2013-03-06 23:13:55 <TD> the b.i page kills my chrome tab after a while
2817 2013-03-06 23:14:10 <TD> muhoo: like i said, they only get a block a couple of times per day right now
2818 2013-03-06 23:14:14 <TD> muhoo: so i don't know
2819 2013-03-06 23:14:30 <TD> muhoo: also that's 96 btc in 3500+ txns. i have no idea how those split out but presumably there's one whale tx
2820 2013-03-06 23:14:34 BenderCoin has joined
2821 2013-03-06 23:14:47 <muhoo> gmaxwell: right, last elgius block looks like 2 days ago.
2822 2013-03-06 23:14:53 <sipa> TD: are all of those non-conflicting with eachother?
2823 2013-03-06 23:15:01 <muhoo> can jgarzik point his asicminer at elgius and give them a boost?
2824 2013-03-06 23:15:16 <gmaxwell> 15:12 < Aaron_TangCryp> gmaxwell, We have a customer who paid nearly 1 bitoin in tx fees and has been waiting 2+ hours
2825 2013-03-06 23:15:19 <Luke-Jr> Avalon*
2826 2013-03-06 23:15:25 <TD> no clue. at the moment my top priority is clearing bitcoinj of lock inversions, and switching all the core objects to use cycle detecting locks
2827 2013-03-06 23:15:26 <TD> a
2828 2013-03-06 23:15:27 <TD> f
2829 2013-03-06 23:15:29 <muhoo> avalon, yes
2830 2013-03-06 23:15:36 <TD> after that i might try writing some client-side network visualizations
2831 2013-03-06 23:15:54 agricocb has quit (Remote host closed the connection)
2832 2013-03-06 23:16:08 <Happzz> does bitcoin-qt let me receive at the same address i send from?
2833 2013-03-06 23:16:23 <muhoo> my apologies, again, i'm an ops guy by background (linux sysadmin), and i really feel a strong urge to find a quick patch to get the blockchain unconstipated NOW
2834 2013-03-06 23:16:42 <TD> there is no such patch, unfortunately
2835 2013-03-06 23:16:45 <muhoo> maybe it's a matter of a few miners with asics pointing at elgius until this storm is passed
2836 2013-03-06 23:16:48 <Happzz> anyone?
2837 2013-03-06 23:16:55 <warren> muhoo: you would need 1) an actual solution and 2) mining operators to pay attention
2838 2013-03-06 23:17:09 <BlueMatt> muhoo: there are other pools which dont enforce the soft limit
2839 2013-03-06 23:17:11 <TD> this storm will pass, eventually
2840 2013-03-06 23:17:19 <gmaxwell> muhoo: ironically, luke was complaining earlier today because "asicminer" decided to send 1 satoshi per share of its stock to each of its shareholders.
2841 2013-03-06 23:17:20 <TD> during the last bubble in 2011 we ran out of network sockets, believe it or not
2842 2013-03-06 23:17:27 <TD> these bubbles always stress the system and reveal scalability problems
2843 2013-03-06 23:17:42 <TD> gmaxwell: 1 satoshi?
2844 2013-03-06 23:17:45 <TD> why?!
2845 2013-03-06 23:17:48 gritcoin has quit (Quit: gritcoin)
2846 2013-03-06 23:18:01 <Happzz> does bitcoin-qt let me receive at the same address i send from?
2847 2013-03-06 23:18:09 <gmaxwell> TD: to report to you how many shares they are going to pay dividends on, or something.
2848 2013-03-06 23:18:10 grau has quit (Ping timeout: 250 seconds)
2849 2013-03-06 23:18:22 <sipa> Happzz: you do not send 'from' an address
2850 2013-03-06 23:18:25 <BlueMatt> gmaxwell: oh god...why do people fail so hard?
2851 2013-03-06 23:18:26 axhlf has quit (Remote host closed the connection)
2852 2013-03-06 23:18:31 <muhoo> TD: yes, it seems pretty familiar to me. like a site that got slashdotted
2853 2013-03-06 23:18:34 <gmaxwell> BlueMatt: hey, they're only half the hashpower.
2854 2013-03-06 23:18:36 <Happzz> sipa don't you?
2855 2013-03-06 23:18:45 <muhoo> or i guess reddited nowadays
2856 2013-03-06 23:18:51 <TD> hilarious
2857 2013-03-06 23:18:57 <gmaxwell> BlueMatt: I guess if we don't like it we could change the POW. :P
2858 2013-03-06 23:19:07 gritcoin has joined
2859 2013-03-06 23:19:15 <Happzz> sipa im sure you understood the question tho
2860 2013-03-06 23:19:18 <BlueMatt> gmaxwell: heh, yes, lets change the pow just to punish them!
2861 2013-03-06 23:19:23 <sipa> Happzz: transactions consume coins, produce new coins (with value not exceeding those consumed), and assigns those coins to addresses
2862 2013-03-06 23:19:25 <TD> is asicminer sharding across pools now or did they hit a wall at 4thash?
2863 2013-03-06 23:19:42 <gmaxwell> TD: they are running across multiple pools.
2864 2013-03-06 23:19:46 <sipa> Happzz: the coins you consume may or may not have identifiable addresses they were preciously assigned to
2865 2013-03-06 23:19:51 <TD> ok. well, that's something at least.
2866 2013-03-06 23:19:51 <BlueMatt> TD: why are they even mining on pools?
2867 2013-03-06 23:19:52 <gmaxwell> I think the forum says they have almost 12 TH/s now.
2868 2013-03-06 23:20:16 <Happzz> sipa when a site asks me if the address i send btcs from can also receive some - does bitcoin-qt support that or not
2869 2013-03-06 23:20:23 <sipa> Happzz: yes
2870 2013-03-06 23:20:29 <TD> and another 488kb block!
2871 2013-03-06 23:20:33 <muhoo> Happzz: but it's best to not re-use addresses
2872 2013-03-06 23:20:36 <gmaxwell> man, it's really hard to get fees from the rpc.
2873 2013-03-06 23:20:38 * TD changes his example in the forum post to be 1mb
2874 2013-03-06 23:20:43 <gwillen> Happzz: what site? They sound confused.
2875 2013-03-06 23:20:58 <TD> huh
2876 2013-03-06 23:21:00 gritcoin has quit (Client Quit)
2877 2013-03-06 23:21:04 <TD> what the hell ..
2878 2013-03-06 23:21:05 <Luke-Jr> gmaxwell: getblocktemplate ?
2879 2013-03-06 23:21:17 <TD> right there we go
2880 2013-03-06 23:21:20 <gmaxwell> Luke-Jr: I want to get fees on the mempool txn that _aren't_ in the getblocktemplate.
2881 2013-03-06 23:21:21 <TD> the 94 btc in fees has been claimed
2882 2013-03-06 23:21:26 <TD> someone is going to be very happy
2883 2013-03-06 23:21:26 <Luke-Jr> TD: we are fighting over fees now! :P
2884 2013-03-06 23:21:33 <muhoo> who the hell?
2885 2013-03-06 23:21:46 <muhoo> where's that block?
2886 2013-03-06 23:21:50 <Luke-Jr> gmaxwell: getrawtransaction
2887 2013-03-06 23:21:52 <Luke-Jr> muhoo: Eligius
2888 2013-03-06 23:21:59 <muhoo> :-)
2889 2013-03-06 23:22:07 <TD> http://blockchain.info/tx/13dffdaef097881acfe9bdb5e6338192242d80161ffec264ee61cf23bc9a1164
2890 2013-03-06 23:22:09 <TD> there it is
2891 2013-03-06 23:22:13 <TD> that must surely be a mistake
2892 2013-03-06 23:22:22 <muhoo> Luke-Jr: nice
2893 2013-03-06 23:22:36 * Luke-Jr pokes MagicalTux
2894 2013-03-06 23:22:47 <gwillen> TD: in the past when someone has accidentally sent a huge amount in TX fees due to a typo, I believe the pool gave it back out of the goodness of their heart
2895 2013-03-06 23:22:56 <gwillen> TD: I dunno who mined this one, of course
2896 2013-03-06 23:23:03 <Luke-Jr> gwillen: yay for making the fee fight more complicated
2897 2013-03-06 23:23:04 <TD> yeah
2898 2013-03-06 23:23:19 <Luke-Jr> would at least be nice to get a confirmation of intent on it of course
2899 2013-03-06 23:23:22 <gwillen> yeah
2900 2013-03-06 23:23:29 <gwillen> has anyone identified the tx in question?
2901 2013-03-06 23:23:35 <gwillen> ah, nevermind, I see TD did
2902 2013-03-06 23:24:14 <muhoo> are you sure it isn't just all the tx's that were constipated by SD? no errors or excess fees?
2903 2013-03-06 23:24:14 bitafterbit has quit (Read error: Connection reset by peer)
2904 2013-03-06 23:24:26 <TD> muhoo: one tx. check it out above
2905 2013-03-06 23:24:45 <muhoo> oh, there it is. yes, looks like an erro
2906 2013-03-06 23:24:48 <TD> it seems the steady state for fees is about 2-3btc at the moment
2907 2013-03-06 23:25:03 <TD> which at $45 per coin is still quite a bit!
2908 2013-03-06 23:25:12 <gmaxwell> 13dffdaef0...
2909 2013-03-06 23:25:17 <Luke-Jr> relayed by some website http://www.timeline-cover.net/
2910 2013-03-06 23:25:18 <muhoo> somebody playing with multi sig, maybe?
2911 2013-03-06 23:25:26 <Luke-Jr> so betting it's a non-listening-node
2912 2013-03-06 23:25:29 <TD> the tx looks normal
2913 2013-03-06 23:25:29 <gmaxwell> https://blockexplorer.com/tx/13dffdaef097881acfe9bdb5e6338192242d80161ffec264ee61cf23bc9a1164
2914 2013-03-06 23:25:58 <TD> i hope it's not the result of some degenerate fee solving algorithm
2915 2013-03-06 23:26:13 <gmaxwell> TD: looks like a mistake with the raw transaction api.
2916 2013-03-06 23:26:24 <TD> how can you tell? just because of the bogus fee?
2917 2013-03-06 23:26:44 * TD considers putting sanity checks on bitcoinj fee sizes
2918 2013-03-06 23:26:55 <gwillen> you'd think someone dicking with raw txns would start with a smaller example first
2919 2013-03-06 23:26:55 <Happzz> ;;ticker --last
2920 2013-03-06 23:26:56 <gribble> 44.64985
2921 2013-03-06 23:26:59 <Happzz> lol shit it's dying
2922 2013-03-06 23:27:08 <Happzz> panic sell!
2923 2013-03-06 23:27:10 <sipa> "dying"
2924 2013-03-06 23:27:37 <gmaxwell> TD: bitcoin-qt has implicit sanity limits. More expicit ones might be interesting.
2925 2013-03-06 23:27:51 <gmaxwell> TD: well you can't get a fee that big on that txn in bitcoin-qt.
2926 2013-03-06 23:28:01 <TD> ok
2927 2013-03-06 23:28:08 <gmaxwell> TD: e.g. you can't just set the fee/kb to 94
2928 2013-03-06 23:28:29 <muhoo> they may not be using bitcoin-qt
2929 2013-03-06 23:28:39 <muhoo> maybe they're using some weird client
2930 2013-03-06 23:28:40 <gmaxwell> muhoo: indeed.
2931 2013-03-06 23:29:13 <gmaxwell> the funny thing is that the roundest output is the 0.002 one.
2932 2013-03-06 23:29:17 <Happzz> gmaxwell bitcoin-qt really needs an option to force no-fee for txs that can wait
2933 2013-03-06 23:29:40 <gmaxwell> Happzz: wait where? it will create no fee txn unless it wouldn't relay them itself.
2934 2013-03-06 23:29:43 <muhoo> Happzz: if you've been following this discussion, you'll see why no-fee tx's might get to a point where they'l never confirm
2935 2013-03-06 23:29:52 <gmaxwell> Happzz: lol the funny thing is that you're like the total opposite of this discussion.
2936 2013-03-06 23:30:06 <Happzz> sorry to ruin the party
2937 2013-03-06 23:30:10 <gmaxwell> Happzz: creating a txn that your node won't even realy is a great way to really screw yourself.
2938 2013-03-06 23:30:21 <muhoo> Happzz: thanks for taking over that job from me :-)
2939 2013-03-06 23:30:22 <Happzz> why wouldnt my node relay it
2940 2013-03-06 23:30:34 <sipa> because it has DoS protection rules
2941 2013-03-06 23:30:47 <gmaxwell> (because e.g. you could send 0.01 BTC in a non-relayable TXN, and it could lock up a 100 BTC input in the process.... out comes the hexeditor to save your lost money)
2942 2013-03-06 23:30:48 <sipa> and it doesn't treat your own transactions differently from others
2943 2013-03-06 23:30:50 <Happzz> as far as i understand, it'll just take longer to confirm
2944 2013-03-06 23:31:06 <sipa> no, it won't even get further than your direct peers
2945 2013-03-06 23:31:11 <sipa> in the most likely case
2946 2013-03-06 23:31:13 <gmaxwell> Happzz: no, transactions which are too miserable don't forward because otherwise someone malicious could just flood the network.
2947 2013-03-06 23:31:13 <gdoteof> regarding 'SD' conspiracy.. doesn't SD hvae shareholders? so it would costthem much more than just tx fees to fake the traffic and congest the blockchain?
2948 2013-03-06 23:31:50 <gmaxwell> gdoteof: one of the conspiracy theories is faking traffic in order to pump the share price.
2949 2013-03-06 23:31:53 <muhoo> gdoteof: never attribute to conspiracy what could just be greed. like... bots doing clickfraud. "we have all this traffic, pay us ad revenue!"
2950 2013-03-06 23:32:05 <Happzz> gmaxwell if the network is sleepy today, wouldn't it be best to allow no-fees txs?
2951 2013-03-06 23:32:08 <TD> click fraud is intended to make a profit
2952 2013-03-06 23:32:19 <gmaxwell> Happzz: it's never sleepy.
2953 2013-03-06 23:32:20 <TD> you, by definition, cannot profit over the long run playing SD
2954 2013-03-06 23:32:26 <TD> hence the oddness of bots playing it
2955 2013-03-06 23:32:28 <Luke-Jr> gdoteof: the shares all combined are a small amount of the whole company I think
2956 2013-03-06 23:32:30 <Happzz> like, the fee is supposed to encourage miners to confirm your tx before another one's
2957 2013-03-06 23:32:37 <TD> what's more, playing it very consistently and 24/7
2958 2013-03-06 23:32:58 <muhoo> smells like bot. which'd imply, smells like fraud.
2959 2013-03-06 23:32:58 <gdoteof> gmaxwell: ohh because they have shares, but aren't necessarily paying out dividends on them. that makes sense
2960 2013-03-06 23:33:01 <Luke-Jr> http://blockchain.info/tx-index/58735261/06bfc24d2bdadb024fb80104f4d5005e1f13562f246dc42902920c62ec844453
2961 2013-03-06 23:33:10 <gmaxwell> Happzz: it'll happily generate free txn when you're not rapidly respending coins like a DOS attacker. (though perhaps it shouldn't anymore)
2962 2013-03-06 23:33:14 <Luke-Jr> ^ how is someone sending a 2.2k transaction without a fee in Bitcoin-Qt?
2963 2013-03-06 23:33:21 <gdoteof> TD: yeah that makes sense. i just assumed it was people 'cleaning' coins via SD, but fraud seems likely
2964 2013-03-06 23:33:43 <TD> well, given that the win/loss tx depends on your bet tx, it's not a good way to mix/anonymize coins
2965 2013-03-06 23:33:45 <gmaxwell> Luke-Jr: hm? high priority. You can be free up to 10KB.
2966 2013-03-06 23:34:01 <Luke-Jr> gmaxwell: I thought all transactions over 1 kB required a fee?
2967 2013-03-06 23:34:09 <gmaxwell> TD: thats not so if you have the operators help.
2968 2013-03-06 23:34:32 <gmaxwell> TD: e.g. the operator has the hmac key, so he can help you issue indepedant 'matching' bets to move luck between players.
2969 2013-03-06 23:34:41 <TD> i suppose so
2970 2013-03-06 23:35:02 <gdoteof> oh.. so you can link the payout address to the winning bet publicly? i didn't realize this
2971 2013-03-06 23:35:03 <gmaxwell> TD: e.g. 1dirt bets a bunch via a hmac filter to help him lose, and 1clean then bets through a matching win filter.
2972 2013-03-06 23:35:26 <TD> gdoteof: yeah i tend to become more and more skeptical about SD as time goes on. the number of txns generated is just huge and every time i sample one, it's the result of a long chain of clearly auto-generated bets
2973 2013-03-06 23:35:38 <Happzz> is it possible to broadcast a tx that will not confirm when miners try to validate it?
2974 2013-03-06 23:35:38 <gavinandresen> Luke-Jr: nope, high enough priority transactions up to 17?k (I'd have to look at the code again) can be free
2975 2013-03-06 23:35:45 Diablo-D3 has quit (Quit: This computer has gone to sleep)
2976 2013-03-06 23:35:47 <Luke-Jr> hm
2977 2013-03-06 23:35:50 <Happzz> like, it will show up at the target as received, but after a while it won't confirm at all?
2978 2013-03-06 23:36:03 <gmaxwell> gavinandresen: I thought it was 10, but if you think 17 then thats probably right.
2979 2013-03-06 23:36:14 <gavinandresen> RE: SD and fees: I may have started an untrue rumor, I have no idea if they increased the fees they're paying or if a heavy player decided to increase the fees THEY're paying
2980 2013-03-06 23:36:38 <TD> gdoteof: also it's listed on MPEX, not exactly the most reputable stock exchange in the world. sadly after the Romney ransom episode I wouldn't put some bizarre attempt at manipulation past erik
2981 2013-03-06 23:36:53 <TD> gavinandresen: http://blockchain.info/tx/be69b7f1d8b04cb010d46faa80d553c5c333072c2ec0b12d634719f4b67aa699
2982 2013-03-06 23:37:02 <TD> gavinandresen: that tx comes from a 1dice address and has a 0.001 fee
2983 2013-03-06 23:37:06 <gavinandresen> ⦠also there was a bitcointalk thread about pausing transaction processing a day or two ago, it might be an attacker deciding to waste some coins and be annoying
2984 2013-03-06 23:37:28 knotwork has quit (Ping timeout: 252 seconds)
2985 2013-03-06 23:37:36 <gmaxwell> gavinandresen: no, the fees SD itself are creating are much higher now, for example: http://blockchain.info/tx/8c997ab734e9b7b7359eaf6d77d0999f8d0b251c1e6706ab156aa0e998008c8a
2986 2013-03-06 23:37:50 knotwork_ has joined
2987 2013-03-06 23:37:52 <gmaxwell> (well SD itself is 'paying' they're paid from the players bet.)
2988 2013-03-06 23:37:56 <gavinandresen> ok. Just wanted to be clear I haven't looked carefully
2989 2013-03-06 23:37:59 <TD> fees 0.001, estimated btc transacted 0.00000001 btc
2990 2013-03-06 23:38:00 <TD> haha
2991 2013-03-06 23:38:05 <TD> that's nuts
2992 2013-03-06 23:38:36 <gmaxwell> TD: yea, they set a static fee, I guess. Limitation of (old) bitcoinj was mentioned before on that?
2993 2013-03-06 23:38:55 <TD> right. limitation of current bitcoinj too. though i think fireduck wrote some code to work around that.
2994 2013-03-06 23:39:05 <TD> nobody ever wrote a fee solver so you have to explicitly set the fee you want
2995 2013-03-06 23:39:18 denisx has joined
2996 2013-03-06 23:39:54 <gmaxwell> yea, so they're paying 0.001 BTC fee even on their 'you lost' communication txn.
2997 2013-03-06 23:39:56 <TD> though given their volume you'd assume they'd write a fee solver if it'd save them money
2998 2013-03-06 23:39:58 <warren> gmaxwell: SD eats the fee because they consider the instant response to be important to the player's psychology
2999 2013-03-06 23:40:16 <gavinandresen> ⦠and the players are happy to pay it, apparently
3000 2013-03-06 23:40:24 <warren> yes they do
3001 2013-03-06 23:40:28 <gmaxwell> warren: SD doesn't eat it, they technically remove it from the players' bet. E.g. the amount you're effectively betting is less the fee.
3002 2013-03-06 23:40:28 agricocb has joined
3003 2013-03-06 23:40:49 ByteUnit has quit (Remote host closed the connection)
3004 2013-03-06 23:41:07 <sipa> at least they could make the return also 0.001 BTC, so it's at least spendable
3005 2013-03-06 23:41:10 <sipa> bah
3006 2013-03-06 23:41:22 <gmaxwell> And yes the 'player[s]' pay it. Not clear why. As TD point out most (almost all?) of these txn are coming from a small number of high volume high speed botlike players.
3007 2013-03-06 23:41:54 <muhoo> so, maybe the whole thing is a giant pantomime?
3008 2013-03-06 23:41:55 <OneMiner> Feature request: Add extra TX fees to TXn after the fact. Pile some more on to get into that next block. Feasible?
3009 2013-03-06 23:42:06 <gavinandresen> sipa: making it spendable is a good idea. I think we screwed up with the zero-value-txout being nonstandard, we should have made it less-than-dust == nonstandard
3010 2013-03-06 23:42:27 <sipa> gavinandresen: yeah
3011 2013-03-06 23:42:41 <sipa> though that'd certainly have been more controversial
3012 2013-03-06 23:42:45 <gmaxwell> This is also why I only cringe a little when luke calls it a DDOS attack. It isn't oneâ attacks are about intentions, stupid and greedy isn't malice. But its damn near indistinguishable from one! If I wanted to attack I'd setup a mildly positive EV gambling site and get the orgy of betters to pay a bunch of fees flodding txn to use it. :P
3013 2013-03-06 23:42:49 <gavinandresen> ⦠but complaining about satoshidice is not productive. We need to embrace more transaction volume and fix problems that come up.
3014 2013-03-06 23:43:09 <TD> OneFixt: there's already an open pull req to do that.
3015 2013-03-06 23:43:16 <TD> i think gavinandresen wanted to let it bake for a while or something
3016 2013-03-06 23:43:16 <Happzz> the SD instant reply makes sense tbh
3017 2013-03-06 23:43:19 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
3018 2013-03-06 23:43:25 <OneMiner> TD Sick, thanks. I'm OneMiner. :P
3019 2013-03-06 23:43:33 <gmaxwell> gavinandresen: I wanted to suggest lest than dust as nonstandard (thats why my nodes run) but I thought that would be really really controversial.
3020 2013-03-06 23:43:37 <TD> oops
3021 2013-03-06 23:43:37 <sipa> instant reply certainly makes sense
3022 2013-03-06 23:43:45 <sipa> instant reply via the blockchain is insane
3023 2013-03-06 23:44:17 <warren> Would there be any downsides to insisting that non-compressed keys have a higher fee?
3024 2013-03-06 23:44:30 <Luke-Jr> gavinandresen: it's unreasonable to expect a p2p blockchain to perform better than what even VISA can handle
3025 2013-03-06 23:44:39 <sipa> how about making non-compressed keys nonstandard too? :D
3026 2013-03-06 23:44:55 <Luke-Jr> sipa: that kills 0.4 and 0.5
3027 2013-03-06 23:45:09 <Luke-Jr> sipa: and newer that haven't run -walletupgrade
3028 2013-03-06 23:45:16 <sipa> Luke-Jr: i was kidding
3029 2013-03-06 23:45:17 <denisx> deepbit still running 0.3?
3030 2013-03-06 23:45:24 <Luke-Jr> denisx: last I checked, yes
3031 2013-03-06 23:45:25 <TD> warren: they already do, fee depends on tx size
3032 2013-03-06 23:45:35 <TD> interestingly, mastercard is apparently internally structured somewhat like bitcoin
3033 2013-03-06 23:45:44 <warren> TD: I mean, more weight than size currently adds
3034 2013-03-06 23:45:56 <Luke-Jr> TD: every node verifies every transaction (how?) and stores it forever?
3035 2013-03-06 23:45:56 <sipa> Luke-Jr: well, not entirely - i'd consider it the moment only a tiny fraction of actual transactions were using uncompressed keys
3036 2013-03-06 23:46:30 <TD> Luke-Jr: it's some kind of P2P broadcast network, apparently. i presume they do store transactions (maybe not forever) because mc/visa use them to train ML models
3037 2013-03-06 23:46:39 <TD> it's really not as scary a scaling problem as people tend to think, imo
3038 2013-03-06 23:46:46 <warren> bump up the fee weight for non-compressed keys in default bitcoind. It would have very little downside for anyone.
3039 2013-03-06 23:46:50 <Luke-Jr> sipa: then I'll go on: even newer clients that HAVE run -walletupgrade still use it for older keys from prior, which will linger in the keypool for 100 txns by default
3040 2013-03-06 23:47:14 <gmaxwell> gavinandresen: my own nodes run something like https://people.xiph.org/~greg/dust.patch now.
3041 2013-03-06 23:48:15 <gmaxwell> Though now that I'm not mining for the moment, it doesn't matter much.
3042 2013-03-06 23:50:20 <sipa> wow, it seems i mined a block today!
3043 2013-03-06 23:50:48 <gmaxwell> sipa: did it have 94 btc in fees?
3044 2013-03-06 23:50:48 <gmaxwell> :P
3045 2013-03-06 23:51:00 <gmaxwell> if so, you're buying us lunch.
3046 2013-03-06 23:51:09 <sipa> gmaxwell: 0.19 BTC, and it was p2pool :)
3047 2013-03-06 23:51:16 <gmaxwell> :P
3048 2013-03-06 23:51:49 <sipa> bah, and it seems i temporarily switched to git head because of segfaults
3049 2013-03-06 23:52:10 <sipa> so it has dice transactions :(
3050 2013-03-06 23:53:35 denisx has quit (Quit: denisx)
3051 2013-03-06 23:56:26 <TD> haha
3052 2013-03-06 23:57:03 <Luke-Jr> sipa: might consider 0.8.0.eligius
3053 2013-03-06 23:57:09 <jgarzik> muhoo: jgarzik already pointed his ASIC miner at eligius ;p
3054 2013-03-06 23:57:17 <jgarzik> muhoo: http://eligius.st/~wizkid057/newstats/userstats.php/13rhBJjFFs8SprywCPKfR7Qc4XQzgJ5vz8
3055 2013-03-06 23:57:18 <Luke-Jr> jgarzik: but you stopped! :P
3056 2013-03-06 23:57:29 <Luke-Jr> oh, and started again
3057 2013-03-06 23:57:42 <sipa> Luke-Jr: i usually run my own test branches with some patches applied
3058 2013-03-06 23:58:02 <Luke-Jr> sipa: well, as your "failover" bitcoind then ;p
3059 2013-03-06 23:58:37 <wizkid057> hmm... inconsistant high-rate miners totally amplify my balance graph bug in the stats