1 2012-06-14 00:01:14 <TuxBlackEdo> http://satoshidice.com/full.php?tx=047bb988b484ece0f5b8165b1b1ffd66af33f23e49eab7521d869a23b2d03e9a
2 2012-06-14 00:01:32 <Eliel> wizkid057: in this case, the attack is only possible because they're abusing the blockchain in a specific way.
3 2012-06-14 00:01:39 <TuxBlackEdo> too bad, that guy could have bet on "less then 1"
4 2012-06-14 00:01:48 <TuxBlackEdo> but that would have changed the txid
5 2012-06-14 00:01:52 <sipa> i wouldn't call their specific scheme abuse
6 2012-06-14 00:01:53 Zarutian has joined
7 2012-06-14 00:02:01 <sipa> (the spam issue aside)
8 2012-06-14 00:02:09 <wizkid057> yeah, just spam
9 2012-06-14 00:02:21 <sipa> in fact, the specific scheme is quite ingenious
10 2012-06-14 00:02:30 <wizkid057> http://blockchain.info/charts/n-transactions <--- I wonder when satoshidice started....
11 2012-06-14 00:02:58 <Eliel> wizkid057: no need to wonder :P
12 2012-06-14 00:03:07 <TuxBlackEdo> even worse: http://blockchain.info/charts/blocks-size
13 2012-06-14 00:03:21 <wizkid057> ah yeah
14 2012-06-14 00:03:28 Zarutian has quit (Client Quit)
15 2012-06-14 00:04:04 <wizkid057> well, someone just DDoS 24.22.208.198
16 2012-06-14 00:04:11 <wizkid057> problem solved
17 2012-06-14 00:04:13 <sipa> so... we're close to 400 MB dice spam?
18 2012-06-14 00:04:19 <TuxBlackEdo> http://satoshidice.com/info.php
19 2012-06-14 00:04:23 <TuxBlackEdo> x_x
20 2012-06-14 00:04:50 <TuxBlackEdo> also 1024 blocks means its hitting the upper limit?
21 2012-06-14 00:04:56 <TuxBlackEdo> i mean
22 2012-06-14 00:05:05 <TuxBlackEdo> 1024 txns = upper limit for blocks?
23 2012-06-14 00:05:20 <Eliel> TuxBlackEdo: 1 megabyte is upper limit for a block
24 2012-06-14 00:05:37 <TuxBlackEdo> why do i see 2 blocks in the last 3 hours that have exactly 1024 txns?
25 2012-06-14 00:05:55 <TuxBlackEdo> i am suspecting 1024 is an upper limit for txns in a block
26 2012-06-14 00:06:02 <TuxBlackEdo> or i might be wrong
27 2012-06-14 00:06:24 <luke-jr> I've seen higher
28 2012-06-14 00:06:43 <TuxBlackEdo> luke-jr, block #?
29 2012-06-14 00:06:45 <sipa> TuxBlackEdo: luke only miners power-of-two numbers of transactions
30 2012-06-14 00:06:49 <sipa> *mines
31 2012-06-14 00:07:04 <wizkid057> sipa: why? :D
32 2012-06-14 00:07:05 Maged has joined
33 2012-06-14 00:08:00 <sipa> who knows
34 2012-06-14 00:08:06 <TuxBlackEdo> sipa, i wasn't looking at luke's blocks, i was looking at blockchain.info's front page
35 2012-06-14 00:08:34 <gmaxwell> There is a max size block in new-testnet
36 2012-06-14 00:08:35 <TuxBlackEdo> oh wait that is luke's
37 2012-06-14 00:10:27 * Eliel suspects it's got something to do with power of two number of transactions forming nice and balanced merkle trees.
38 2012-06-14 00:10:31 <wizkid057> well, all the satohidice responses seem to come from 24.22.208.198
39 2012-06-14 00:10:35 <wizkid057> if that helps anyone
40 2012-06-14 00:11:14 <wizkid057> Eliel: thats a problem of some sort?
41 2012-06-14 00:11:21 <luke-jr> TuxBlackEdo: well, I know I've mined 4096 txn blocks before
42 2012-06-14 00:11:56 <BlueMatt> wizkid057: according to the phpinfo output, they are using amazon cloudfront, have fun trying to ddos amazon cloudfront cdn...about as useful as ddosing 0.0.0.0
43 2012-06-14 00:11:57 <Eliel> wizkid057: you can keep the code for generating the merkle tree simpler that way :P
44 2012-06-14 00:12:22 <wizkid057> 198.208.22.24.in-addr.arpa domain name pointer c-24-22-208-198.hsd1.wa.comcast.net.
45 2012-06-14 00:12:26 <wizkid057> doesnt look like amazon to me...
46 2012-06-14 00:12:33 <TuxBlackEdo> yep
47 2012-06-14 00:12:46 <Eliel> luke-jr: did I guess it right, the reason why you only create blocks with power of two number of transactions?
48 2012-06-14 00:12:53 <Matt_von_Mises> Somehow PUSHDATA operations push zero when the number of bytes to push are zero. I don't get how this is looking at the code. Does vector::assign give 0 when the difference between the first and last is 0?
49 2012-06-14 00:12:58 <TuxBlackEdo> wizkid057 is right, that is satoshidice's bitcoind IP
50 2012-06-14 00:13:04 <luke-jr> Eliel: no comment.
51 2012-06-14 00:13:21 <Eliel> o_O why would you keep that a secret.
52 2012-06-14 00:13:22 <BlueMatt> Hostname:Port ip-10-238-154-6.eu-west-1.compute.internal:0
53 2012-06-14 00:13:24 <BlueMatt> amazon
54 2012-06-14 00:13:41 <TuxBlackEdo> BlueMatt, that's satoshidice.com, which is probably a display only site
55 2012-06-14 00:13:49 <luke-jr> Eliel: hmm, do you remember what my original goal for Eligius was? and my use of Bitcoin in general?
56 2012-06-14 00:13:51 <Matt_von_Mises> Apparently OP_PUSHDATA1 0x00 0 OP_EQUAL is valid
57 2012-06-14 00:14:01 <Matt_von_Mises> https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_valid.json#L11
58 2012-06-14 00:14:06 <sipa> we all know luke likes 2-based number systems
59 2012-06-14 00:14:10 <Eliel> luke-jr: well, yes, tonal :)
60 2012-06-14 00:14:13 <TuxBlackEdo> you can hack satoshidice.com and not get any secrets or anything useful, that ip on the other hand has the bitcoind and all the secrets
61 2012-06-14 00:14:17 <wizkid057> BlueMatt: the bitcoin txns dont come from amazon
62 2012-06-14 00:14:27 <TuxBlackEdo> satoshidice.com is more then likely a "display only" site
63 2012-06-14 00:14:35 <BlueMatt> wizkid057: ahh, well then have fun ddosing comcast, that one should be pretty easy
64 2012-06-14 00:14:36 <TuxBlackEdo> kind of like a pastebin
65 2012-06-14 00:14:51 <luke-jr> Eliel: guess what those txn counts look like in tonal
66 2012-06-14 00:14:54 <sipa> Matt_von_Mises: OP_EQUAL compares numbers, nor vectors, right?
67 2012-06-14 00:15:01 <wizkid057> BlueMatt: comcast neighborhood nodes are only a few hundred megabit
68 2012-06-14 00:15:06 <wizkid057> lol
69 2012-06-14 00:15:08 <sipa> Matt_von_Mises: and the empty vector has value 0 too
70 2012-06-14 00:15:22 <BlueMatt> wizkid057: and the end-user is even less...
71 2012-06-14 00:16:04 <wizkid057> BlueMatt: generally, but, DDoS generally isnt all that effective against a single comcast user unless the node is saturated
72 2012-06-14 00:16:16 <Matt_von_Mises> sipa: Oh right⦠so an empty vector is equal to a vector with a zero? I got it.
73 2012-06-14 00:16:22 <wizkid057> since their hardware rate limits stuff to the end user
74 2012-06-14 00:16:30 Joric has quit ()
75 2012-06-14 00:16:32 <wizkid057> and prioritizes tcp streams and such
76 2012-06-14 00:16:51 <sipa> Matt_von_Mises: i haven't played with the script code too closely, so don't take my word for it, but that's my assumption yes
77 2012-06-14 00:18:20 <BlueMatt> wizkid057: prioritizes tcp streams...meh, as long as you can flood the crap out of it, it isnt hard to make any user behind regular internet connections fall over
78 2012-06-14 00:18:48 AntKinGTube has joined
79 2012-06-14 00:19:06 <wizkid057> BlueMatt: dont get me wrong, i completely agree... but i've actually been DoS'd on comcast several times. Could still IRC :P
80 2012-06-14 00:19:31 <wizkid057> not much else, but, connection would work until the node was saturated
81 2012-06-14 00:20:35 <Matt_von_Mises> sipa: Well it looks like C++ equates an empty vector with a vector with zero.
82 2012-06-14 00:20:46 <sipa> Matt_von_Mises: C++ certainly doesn't
83 2012-06-14 00:20:48 <BlueMatt> wizkid057: I dont think running a bitcoin node in that scenario would work very well, esp with satoshidice's tx volue
84 2012-06-14 00:20:58 <sipa> Matt_von_Mises: but OP_EQUAL casts the vectors to CBigNums first
85 2012-06-14 00:21:16 bitcoinbulletin has quit (Ping timeout: 260 seconds)
86 2012-06-14 00:21:41 <sipa> Matt_von_Mises: i'm wrong
87 2012-06-14 00:21:43 <wizkid057> BlueMatt: well, at the very least they're using that IP as their only node
88 2012-06-14 00:22:12 darkskiez has quit (Ping timeout: 245 seconds)
89 2012-06-14 00:22:16 <Matt_von_Mises> sipa: I just looked. It takes the data from the stack and uses ==
90 2012-06-14 00:23:06 darkskiez has joined
91 2012-06-14 00:23:20 <sipa> Matt_von_Mises: indeed
92 2012-06-14 00:25:27 <TuxBlackEdo> All 1680 scanned ports on c-24-22-208-198.hsd1.wa.comcast.net (24.22.208.198) are filtered
93 2012-06-14 00:25:51 <BlueMatt> TuxBlackEdo: wow... no one was advocating you actually do anything...
94 2012-06-14 00:25:57 <TuxBlackEdo> the beauty of NAT
95 2012-06-14 00:27:01 <wizkid057> TuxBlackEdo: i'm waiting for nmap -p1-65535 -P0 24.22.208.198 to finish
96 2012-06-14 00:27:42 <BlueMatt> maybe these things shouldnt be discussed in a logged channel?
97 2012-06-14 00:28:11 <sipa> Matt_von_Mises: maybe OP_0 just pushes an empty vector?
98 2012-06-14 00:28:17 <wizkid057> probably not
99 2012-06-14 00:28:26 <wizkid057> but, nmap isnt illegal! :P
100 2012-06-14 00:28:29 rdponticelli_ has joined
101 2012-06-14 00:28:48 <sipa> wizkid057: most ISP's won't allow you to use their network for it though
102 2012-06-14 00:28:57 <Matt_von_Mises> sipa: I'm trying to figure out now if an empty vector works the same way as a vector with 0
103 2012-06-14 00:29:08 rdponticelli has quit (Ping timeout: 244 seconds)
104 2012-06-14 00:29:10 <sipa> clearly it shouldn't
105 2012-06-14 00:29:22 <wizkid057> wizkid057 TuxBlackEdo: i'm waiting for nmap -p1-65535 -P0 aaa-bbb-ccc-ddd to finish
106 2012-06-14 00:29:28 <wizkid057> lol, log masks IPs
107 2012-06-14 00:29:47 <sipa> which irc client does that?
108 2012-06-14 00:30:00 Matt_von_Mises has left ()
109 2012-06-14 00:30:14 Matt_von_Mises has joined
110 2012-06-14 00:31:02 <Matt_von_Mises> sipa: If BN_mpi2bn gives a 0 big num for size zero, then an empty vector should work the same as a vector with zero.
111 2012-06-14 00:31:17 <Matt_von_Mises> As the bignum casts will give the same.
112 2012-06-14 00:31:24 <sipa> it does
113 2012-06-14 00:33:12 <Matt_von_Mises> Alright so when PUSHDATA operations are given zero bytes to push surely there is no problem pushing a zero?
114 2012-06-14 00:34:24 <Matt_von_Mises> Oddly when pushing zero the size is zero⦠This is all a bit weird.
115 2012-06-14 00:36:33 <Matt_von_Mises> Ah, OP_0 does give an empty vector...
116 2012-06-14 00:38:58 Z0rZ0rZ0r has joined
117 2012-06-14 00:48:27 <jgarzik> sipa: RE empty filter - of course you miss transactions... that's why SPV client must load filter before syncing with blocks or issuing 'mempool' command to discover missed TX's
118 2012-06-14 00:49:04 smtmnyz_ has joined
119 2012-06-14 00:49:45 smtmnyz has quit (Ping timeout: 248 seconds)
120 2012-06-14 01:05:38 faraday__ has quit (Remote host closed the connection)
121 2012-06-14 01:05:38 terry has quit (Remote host closed the connection)
122 2012-06-14 01:05:38 mcorlett has quit (Remote host closed the connection)
123 2012-06-14 01:05:48 AntKinGTube has quit (Ping timeout: 245 seconds)
124 2012-06-14 01:19:44 <Matt_von_Mises> sipa: Does BN_bn2mpi give zero size for zero?
125 2012-06-14 01:19:53 <Matt_von_Mises> If you know that...
126 2012-06-14 01:23:56 Nicksasa has quit (Remote host closed the connection)
127 2012-06-14 01:24:15 osmosis has quit (Quit: Leaving)
128 2012-06-14 01:24:31 <gribble> New news from bitcoinrss: gavinandresen opened issue 1455 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1455>
129 2012-06-14 01:27:22 <Matt_von_Mises> Indeed it is zero size.
130 2012-06-14 01:28:44 theorbtwo has quit (Ping timeout: 252 seconds)
131 2012-06-14 01:31:08 Diablo-D3 has quit (Ping timeout: 244 seconds)
132 2012-06-14 01:32:19 TheSeven is now known as The_Seven
133 2012-06-14 01:33:20 The_Seven is now known as _TheSeven_
134 2012-06-14 01:33:40 _TheSeven_ is now known as TheSeven|Mobile
135 2012-06-14 01:33:40 theorbtwo has joined
136 2012-06-14 01:33:42 TheSeven is now known as Mobile!~quassel@rockbox/developer/TheSeven|TheSeven|Zzz
137 2012-06-14 01:33:43 TheSeven is now known as Zzz!~quassel@rockbox/developer/TheSeven|TheSeven
138 2012-06-14 01:36:16 <Matt_von_Mises> OP_1 OP_1 OP_SUB OP_SIZE OP_0 OP_EQUAL Anyone know is this is valid?
139 2012-06-14 01:36:58 <Matt_von_Mises> I need to get the C++ client testing code working on my computer. Will try that tomorrow.
140 2012-06-14 01:37:10 <luke-jr> Matt_von_Mises: looks like it will always fail
141 2012-06-14 01:37:42 Internet13 has quit (Ping timeout: 256 seconds)
142 2012-06-14 01:38:26 <Matt_von_Mises> From what I know, it is valid
143 2012-06-14 01:38:54 <Matt_von_Mises> Because 1 minus 1 is 0 which is represented as a zero size vector from what I can see.
144 2012-06-14 01:39:01 <Matt_von_Mises> Need to test it.
145 2012-06-14 01:39:11 Mad7Scientist is now known as danieldanielll
146 2012-06-14 01:39:20 <luke-jr> Matt_von_Mises: valid, but fails
147 2012-06-14 01:39:25 <luke-jr> oh
148 2012-06-14 01:39:37 danieldanielll is now known as danieldanielllll
149 2012-06-14 01:39:45 danieldanielllll is now known as danieldaniel
150 2012-06-14 01:40:07 phungi has quit (Quit: Lost terminal)
151 2012-06-14 01:40:08 <Matt_von_Mises> The getvch method for bignums uses BN_bn2mpi. In my test it gives a zero size for 0.
152 2012-06-14 01:40:15 danieldaniel is now known as Guest96327
153 2012-06-14 01:40:25 <Matt_von_Mises> So I can only tell it is valid.
154 2012-06-14 01:40:26 <luke-jr> maybe
155 2012-06-14 01:40:27 minimoose has joined
156 2012-06-14 01:40:48 <Matt_von_Mises> The zero representation in the script is insane.
157 2012-06-14 01:40:59 <Matt_von_Mises> Totally counter-intuitive.
158 2012-06-14 01:41:12 Internet13 has joined
159 2012-06-14 01:41:28 <luke-jr> gavinandresen: you ACK'd #1416 twice :P
160 2012-06-14 01:41:40 <gavinandresen> ACK
161 2012-06-14 01:41:48 * luke-jr wonders when all the ACKs turn into pulls
162 2012-06-14 01:41:57 <gavinandresen> I'm testing 1416 now....
163 2012-06-14 01:42:01 <luke-jr> oh
164 2012-06-14 01:42:06 <luke-jr> I usually do that before ACKing
165 2012-06-14 01:42:09 <luke-jr> <.
166 2012-06-14 01:42:10 <luke-jr> <.<*
167 2012-06-14 01:42:22 <gavinandresen> Yeah, I tested it before, but there have been pulls since that might have broke it
168 2012-06-14 01:43:08 <gavinandresen> (I'm just recompiling/re-running unit tests)
169 2012-06-14 01:43:16 Guest96327 is now known as Mad7Scientist
170 2012-06-14 01:43:42 <luke-jr> i c
171 2012-06-14 01:43:51 agricocb has joined
172 2012-06-14 01:48:25 luke-jr has quit (Ping timeout: 248 seconds)
173 2012-06-14 01:49:28 <BlueMatt> heh, fully sync'd bitcoin, blkindex.dat: 311MB
174 2012-06-14 01:49:48 <gribble> New news from bitcoinrss: gavinandresen opened pull request 1456 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1456>
175 2012-06-14 01:50:02 <BlueMatt> nice
176 2012-06-14 01:51:40 luke-jr has joined
177 2012-06-14 01:52:05 <bayleef> Mine's not even fully sync'd yet and it's 431mb
178 2012-06-14 01:52:17 <gavinandresen> bah, already found a bug, help text is wrong for signrawtx....
179 2012-06-14 01:52:49 <BlueMatt> bayleef: r
180 2012-06-14 01:52:50 Matt_von_Mises has quit (Quit: Leaving.)
181 2012-06-14 01:52:56 <BlueMatt> https://github.com/bitcoin/bitcoin/pull/1405
182 2012-06-14 01:57:37 <BlueMatt> I love how little people care about security or their coins: "The previous client that I used, "Bitcoin 0.3.21 BETA", worked fine."
183 2012-06-14 01:57:43 <BlueMatt> like...wtf?
184 2012-06-14 01:59:07 <gmaxwell> To be fairâ a lot of people only have a few bucks worth.
185 2012-06-14 01:59:55 <BlueMatt> still...
186 2012-06-14 01:59:57 <gmaxwell> It'd probably be worth a few bucks to get a fun story of getting exploited.
187 2012-06-14 02:00:06 osmosis has joined
188 2012-06-14 02:00:28 <BlueMatt> but 0.3.21, why on earth would you ever get 0.3.21?/?
189 2012-06-14 02:00:53 <gmaxwell> hasn't upgraded in a long time?
190 2012-06-14 02:01:06 <BlueMatt> last used bitcoin in april of 2011?
191 2012-06-14 02:01:19 <BlueMatt> or just doesnt like to upgrade?
192 2012-06-14 02:01:26 <BlueMatt> its pretty sad either way
193 2012-06-14 02:01:42 <BlueMatt> in any case, we need to do a way better job of getting people to upgrade
194 2012-06-14 02:03:05 <luke-jr> too much "if it ain't broken, don't fix it" misapplication
195 2012-06-14 02:03:16 <BlueMatt> yea...
196 2012-06-14 02:03:32 <gmaxwell> well, it would help if upgrades were reliably painless. :-/
197 2012-06-14 02:03:32 <bayleef> hmmph. Just synched another machine, got it to latest block and synched my box only from it. That machine didn't have a problem with block 176948. My box instantly saw some invalid signature and won't accept it. wtf n stuff
198 2012-06-14 02:03:37 <luke-jr> I was surprised to see that on Intel's website -.-
199 2012-06-14 02:03:46 <luke-jr> "don't update your BIOS unless you have a problem"
200 2012-06-14 02:04:00 <luke-jr> gmaxwell: hence the stable branches I maintain
201 2012-06-14 02:04:31 <gavinandresen> I thought you said the stable branches got stuck on a block..... (did you email about that? I didn't get it if you did, I think)
202 2012-06-14 02:04:46 <BlueMatt> bayleef: ok, thats really looking like a hardware problem...a. can you double-check that the bitcoin-qt.exe you are running has the same hash as the published ones? after that, try memtest86+
203 2012-06-14 02:05:12 <BlueMatt> gmaxwell: yea...
204 2012-06-14 02:05:44 <gmaxwell> luke-jr: for some of the issues people run into the stable branches don't helpâ I think. E.g. they shutdown uncleanly then upgrade and bdb barfs because the bdb version isn't the same.
205 2012-06-14 02:05:52 <luke-jr> gavinandresen: yes, they did. I haven't writ the email yet
206 2012-06-14 02:05:52 <bayleef> Would hashes still apply if I'm using custom-built binaries? Both me and portage
207 2012-06-14 02:06:06 <gmaxwell> portage? ... gentoo user.
208 2012-06-14 02:06:08 <BlueMatt> bayleef: mmm...probably not
209 2012-06-14 02:06:18 <BlueMatt> try recompiling+reinstalling
210 2012-06-14 02:06:21 <luke-jr> bayleef: huh?
211 2012-06-14 02:06:24 <gmaxwell> Try -fdont-unroll-enough-to-break-everything? :)
212 2012-06-14 02:06:34 <luke-jr> what gmaxwell said too
213 2012-06-14 02:07:20 <gmaxwell> bayleef: what crazy make options do you have? a miscompilation isn't out of the question.
214 2012-06-14 02:08:05 gavinandresen has quit (Quit: gavinandresen)
215 2012-06-14 02:08:36 brwyatt is now known as brwyatt|Away
216 2012-06-14 02:10:13 <bayleef> nothing terribly interesting, -s -j2. Also when I compiled it, I set BDB_PATH=/usr/include/db4.8. CFLAGS is just the default stuff, -o2 -pipe -march=i686
217 2012-06-14 02:10:44 <bayleef> I left any flags the way they were when I compiled myself
218 2012-06-14 02:10:49 darkee has quit (Ping timeout: 276 seconds)
219 2012-06-14 02:11:41 <luke-jr> bayleef: CXXFLAGS is what we want
220 2012-06-14 02:11:56 <luke-jr> and I hope that's -O2
221 2012-06-14 02:11:58 <luke-jr> not -o2
222 2012-06-14 02:14:09 <gmaxwell> hah
223 2012-06-14 02:14:17 <bayleef> and this is me, failing at quoting things properly
224 2012-06-14 02:15:57 brwyatt is now known as Away!~brwyatt@pool-71-244-54-5.dllstx.fios.verizon.net|brwyatt
225 2012-06-14 02:17:13 <bayleef> luke-jr: CXXFLAGS="${CFLAGS}"
226 2012-06-14 02:17:32 <luke-jr> bayleef: failing hard drive?
227 2012-06-14 02:18:03 <luke-jr> someone find a block plz
228 2012-06-14 02:19:41 <bayleef> luke-jr: smartctl -a /dev/sda doesn't seem to think so. Any way to verify that?
229 2012-06-14 02:20:50 <luke-jr> dunno
230 2012-06-14 02:21:01 <luke-jr> bayleef: I suggest setting aside an IBM 5100 for the future.
231 2012-06-14 02:24:37 mosi has quit (work!~mos@217.22.80.138|Read error: Connection reset by peer)
232 2012-06-14 02:24:56 pickett has quit (Remote host closed the connection)
233 2012-06-14 02:24:57 MobiusL has quit (Remote host closed the connection)
234 2012-06-14 02:24:57 paraipan has quit (Write error: Broken pipe)
235 2012-06-14 02:25:34 paraipan has joined
236 2012-06-14 02:25:37 pickett has joined
237 2012-06-14 02:28:12 MobiusL has joined
238 2012-06-14 02:28:37 phungi has joined
239 2012-06-14 02:32:24 <bayleef> luke-jr: So now I get to go run a memory test?
240 2012-06-14 02:36:18 <luke-jr> bayleef: I'd run -checkblocks
241 2012-06-14 02:36:51 phantomcircuit is now known as normal_user
242 2012-06-14 02:37:31 normal_user is now known as phantomcircuit
243 2012-06-14 02:39:57 <luke-jr> REORGANIZE: Connect 6811 blocks; 00000000000005353824..00000000000003c87423
244 2012-06-14 02:40:39 <bayleef> luke-jr: I've tried that already, but that was another blockchain copy, verified that one at level 6 and it still couldn't verify the signature. Should I do that with this one too?
245 2012-06-14 02:45:34 <gribble> New news from bitcoinrss: jgarzik opened pull request 1458 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1458> || joaocalistro opened issue 1457 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1457>
246 2012-06-14 02:50:24 Karmaon has quit (Ping timeout: 265 seconds)
247 2012-06-14 02:51:18 TheSeven has quit (Disconnected by services)
248 2012-06-14 02:51:25 [7] has joined
249 2012-06-14 03:00:08 JZavala has joined
250 2012-06-14 03:07:36 Z0rZ0rZ0r has quit (Ping timeout: 246 seconds)
251 2012-06-14 03:07:55 Z0rZ0rZ0r has joined
252 2012-06-14 03:09:56 Karmaon has joined
253 2012-06-14 03:12:55 rdponticelli_ has quit (Ping timeout: 244 seconds)
254 2012-06-14 03:13:41 eoss has quit (Remote host closed the connection)
255 2012-06-14 03:15:34 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
256 2012-06-14 03:16:46 da2ce7 has joined
257 2012-06-14 03:20:40 Karmaon has quit (Ping timeout: 244 seconds)
258 2012-06-14 03:25:01 Karmaon has joined
259 2012-06-14 03:29:14 _flow_ has quit (Ping timeout: 248 seconds)
260 2012-06-14 03:29:36 osmosis has quit (Quit: Leaving)
261 2012-06-14 03:37:17 _flow_ has joined
262 2012-06-14 03:39:40 one_zero has joined
263 2012-06-14 03:48:03 Karmaon has quit (Ping timeout: 244 seconds)
264 2012-06-14 03:56:03 Maged has quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
265 2012-06-14 04:02:46 dw_ is now known as dw
266 2012-06-14 04:07:53 Clipse has quit (Ping timeout: 256 seconds)
267 2012-06-14 04:12:29 brwyatt has quit (Quit: leaving)
268 2012-06-14 04:13:05 brwyatt has joined
269 2012-06-14 04:14:38 <luke-jr> REORGANIZE: Connect 6814 blocks; 00000000000005353824..00000000000000e44748
270 2012-06-14 04:14:45 <luke-jr> going on an hour nowâ¦
271 2012-06-14 04:14:49 Karmaon has joined
272 2012-06-14 04:16:33 <doublec> what's that from?
273 2012-06-14 04:17:16 <luke-jr> doublec: 0.4.x with the P2SH bug fixed, trying to reorg up to the last block (an hour ago)
274 2012-06-14 04:17:27 <luke-jr> in a single leap
275 2012-06-14 04:18:23 <doublec> ah ok
276 2012-06-14 04:26:16 RainbowDashh has joined
277 2012-06-14 04:39:28 D34TH has quit (Read error: Connection reset by peer)
278 2012-06-14 04:45:55 toffoo has joined
279 2012-06-14 04:46:30 Nolybab has joined
280 2012-06-14 04:47:46 rcorreia has quit (Read error: Operation timed out)
281 2012-06-14 04:48:01 rcorreia has joined
282 2012-06-14 04:48:15 <Nolybab> sure is quiet in here...is quiet in here...quiet in here...in here...here...*
283 2012-06-14 04:49:19 Nolybab has left ()
284 2012-06-14 04:55:49 hnz has quit (Read error: Connection reset by peer)
285 2012-06-14 05:01:25 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
286 2012-06-14 05:03:08 hnz has joined
287 2012-06-14 05:08:08 paraipan has quit (Quit: Saliendo)
288 2012-06-14 05:09:50 hnz has quit (Ping timeout: 252 seconds)
289 2012-06-14 05:12:40 ThomasV has joined
290 2012-06-14 05:13:13 RainbowDashh has joined
291 2012-06-14 05:13:18 ThomasV has quit (Client Quit)
292 2012-06-14 05:13:31 luke-jr has quit (Read error: Connection reset by peer)
293 2012-06-14 05:13:48 luke-jr has joined
294 2012-06-14 05:14:37 hnz has joined
295 2012-06-14 05:16:16 RainbowDashh is now known as pL
296 2012-06-14 05:16:19 pL is now known as PL
297 2012-06-14 05:16:44 paraipan has joined
298 2012-06-14 05:16:46 PL is now known as Guest68196
299 2012-06-14 05:16:57 Guest68196 is now known as RainbowDashh
300 2012-06-14 05:17:58 RainbowDashh is now known as cm
301 2012-06-14 05:18:04 cm is now known as RainbowDashh
302 2012-06-14 05:18:54 luke-jr has quit (Excess Flood)
303 2012-06-14 05:19:15 luke-jr has joined
304 2012-06-14 05:23:18 null_radix has quit (Ping timeout: 245 seconds)
305 2012-06-14 05:25:54 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
306 2012-06-14 05:28:26 gfinn has quit (Ping timeout: 276 seconds)
307 2012-06-14 05:35:24 hnz has quit (Ping timeout: 244 seconds)
308 2012-06-14 05:37:19 X-Scale has quit (Remote host closed the connection)
309 2012-06-14 05:40:23 minimoose has quit (Quit: minimoose)
310 2012-06-14 05:42:08 hnz has joined
311 2012-06-14 05:51:35 dvide has joined
312 2012-06-14 05:52:54 gfinn has joined
313 2012-06-14 05:57:28 imsaguy has quit (Ping timeout: 265 seconds)
314 2012-06-14 06:01:22 RazielZ has joined
315 2012-06-14 06:03:45 brwyatt is now known as brwyatt|Away
316 2012-06-14 06:07:48 m00p has joined
317 2012-06-14 06:10:30 <gribble> New news from bitcoinrss: laanwj opened pull request 1459 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1459>
318 2012-06-14 06:10:55 Staatsfeind has joined
319 2012-06-14 06:11:26 vragnaroda has quit (Disconnected by services)
320 2012-06-14 06:11:33 Staatsfeind is now known as vragnaroda
321 2012-06-14 06:18:02 imsaguy3 has joined
322 2012-06-14 06:18:23 imsaguy3 is now known as imsaguy
323 2012-06-14 06:24:47 ovidiusoft has joined
324 2012-06-14 06:27:58 dvide has quit ()
325 2012-06-14 06:30:18 dvide has joined
326 2012-06-14 06:45:18 nexes has quit (Remote host closed the connection)
327 2012-06-14 06:47:28 setkeh has quit (Quit: Time For a World Without Govorment Internet Interfearence)
328 2012-06-14 06:47:48 setkeh has joined
329 2012-06-14 06:48:13 Karmaon has quit (Ping timeout: 265 seconds)
330 2012-06-14 06:50:30 Nesetalis has joined
331 2012-06-14 06:50:40 Neskia has quit (Ping timeout: 252 seconds)
332 2012-06-14 06:51:45 setkeh has quit (Client Quit)
333 2012-06-14 06:52:53 m00p has quit (Ping timeout: 245 seconds)
334 2012-06-14 06:53:59 setkeh has joined
335 2012-06-14 06:54:22 Maccer has quit (Ping timeout: 246 seconds)
336 2012-06-14 06:56:24 Neskia has joined
337 2012-06-14 06:57:53 Nesetalis has quit (Ping timeout: 245 seconds)
338 2012-06-14 06:59:39 sirk390 has joined
339 2012-06-14 07:02:21 Karmaon has joined
340 2012-06-14 07:05:34 Neskia has quit (Read error: Connection reset by peer)
341 2012-06-14 07:05:51 Nesetalis has joined
342 2012-06-14 07:10:15 Neskia has joined
343 2012-06-14 07:11:09 setkeh has quit (Quit: Time For a World Without Govorment Internet Interfearence)
344 2012-06-14 07:11:21 setkeh has joined
345 2012-06-14 07:11:40 <gribble> New news from bitcoinrss: xanatos opened issue 1460 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1460>
346 2012-06-14 07:11:43 setkeh has quit (Client Quit)
347 2012-06-14 07:11:44 darkee has joined
348 2012-06-14 07:12:15 setkeh has joined
349 2012-06-14 07:12:23 Nesetalis has quit (Ping timeout: 265 seconds)
350 2012-06-14 07:14:39 <BlueMattBot> Project Bitcoin-Test build #304: FAILURE in 33 min: http://jenkins.bluematt.me/job/Bitcoin-Test/304/
351 2012-06-14 07:14:39 <BlueMattBot> * phil.kaufmann: introduce a new StartShutdown() function, which starts a thread with Shutdown() if no GUI is used and calls uiInterface.QueueShutdown() if a GUI is used / all direct uiInterface.QueueShutdown() calls are replaced with Shutdown() - this ensures a clean GUI shutdown, even when catching a SIGTERM and allows the BitcoinGUI destructor to get called (which fixes a tray-icon issue and keeps the tray-icon until Bit
352 2012-06-14 07:14:40 <BlueMattBot> * phil.kaufmann: merge toggleHidden() code into showNormalIfMinimized() to extend the functionality, but keep a simpler toggleHidden() for use in SLOT() macro
353 2012-06-14 07:14:40 <BlueMattBot> * phil.kaufmann: URI-handling code update: added safety checks and tray-notifications
354 2012-06-14 07:15:06 Nolybab has joined
355 2012-06-14 07:18:52 Hasbro has quit ()
356 2012-06-14 07:25:28 tsche has quit (Ping timeout: 244 seconds)
357 2012-06-14 07:25:55 Karmaon has quit (Ping timeout: 265 seconds)
358 2012-06-14 07:26:03 Neskia has quit (Read error: Connection reset by peer)
359 2012-06-14 07:26:04 Nesetalis has joined
360 2012-06-14 07:26:56 <yellowhat> can a transaction appear in more than one block?
361 2012-06-14 07:28:18 Nesetalis has quit (Read error: Connection reset by peer)
362 2012-06-14 07:28:34 Nesetalis has joined
363 2012-06-14 07:30:18 Nolybab has quit ()
364 2012-06-14 07:30:33 TuxBlackEdo has quit (Remote host closed the connection)
365 2012-06-14 07:30:44 tsche has joined
366 2012-06-14 07:34:55 Nesetalis has quit (Read error: Connection reset by peer)
367 2012-06-14 07:36:03 Nesetalis has joined
368 2012-06-14 07:39:39 Motest003 has quit ()
369 2012-06-14 07:42:19 RainbowDashh has joined
370 2012-06-14 07:42:42 Maccer has joined
371 2012-06-14 07:43:43 RainbowDashh has quit (Client Quit)
372 2012-06-14 07:55:26 Maccer has quit (Ping timeout: 244 seconds)
373 2012-06-14 07:58:25 Ahimoth has quit (Ping timeout: 246 seconds)
374 2012-06-14 08:02:40 Prattler has joined
375 2012-06-14 08:04:17 TuxBlackEdo has joined
376 2012-06-14 08:08:55 faraday__ has joined
377 2012-06-14 08:10:20 DamascusVG has quit (Quit: I Quit - http://www.youtube.com/watch?v=9p97zsQ51Rw)
378 2012-06-14 08:14:26 molecular has quit (Ping timeout: 248 seconds)
379 2012-06-14 08:14:59 molecular has joined
380 2012-06-14 08:24:16 Ahimoth has joined
381 2012-06-14 08:28:04 t7 has joined
382 2012-06-14 08:29:32 stalled has quit (Ping timeout: 244 seconds)
383 2012-06-14 08:32:37 darkee has quit (Remote host closed the connection)
384 2012-06-14 08:33:14 darkee has joined
385 2012-06-14 08:38:35 Clipse has joined
386 2012-06-14 08:44:55 stalled has joined
387 2012-06-14 08:46:42 Maccer has joined
388 2012-06-14 08:48:57 toffoo has quit ()
389 2012-06-14 08:52:35 faraday__ has quit (Remote host closed the connection)
390 2012-06-14 08:59:41 <BlueMattBot> Yippie, build fixed!
391 2012-06-14 08:59:42 <BlueMattBot> Project Bitcoin-Test build #305: FIXED in 30 min: http://jenkins.bluematt.me/job/Bitcoin-Test/305/
392 2012-06-14 08:59:42 <BlueMattBot> laanwj: Fix build of testcases after commit 0f10b21719e1b0d9683a142f0a7105e65f095694
393 2012-06-14 09:02:05 JZavala has quit (Ping timeout: 244 seconds)
394 2012-06-14 09:03:00 _Fireball has joined
395 2012-06-14 09:06:46 Turingi has joined
396 2012-06-14 09:08:56 faraday__ has joined
397 2012-06-14 09:23:23 skeledrew has quit (Ping timeout: 244 seconds)
398 2012-06-14 09:32:04 tower has quit (Ping timeout: 265 seconds)
399 2012-06-14 09:35:15 tower has joined
400 2012-06-14 09:39:43 ThomasV has joined
401 2012-06-14 09:40:17 pickett has quit (Remote host closed the connection)
402 2012-06-14 09:44:09 Ahimoth has quit (Ping timeout: 245 seconds)
403 2012-06-14 09:49:41 mcorlett has joined
404 2012-06-14 09:50:08 pickett has joined
405 2012-06-14 09:50:24 hnz has quit (Ping timeout: 245 seconds)
406 2012-06-14 09:55:09 hnz has joined
407 2012-06-14 10:02:54 one_zero has quit ()
408 2012-06-14 10:50:08 agricocb has quit (Quit: Leaving.)
409 2012-06-14 10:53:04 gjs278 has quit (Read error: Connection reset by peer)
410 2012-06-14 10:55:15 Dyaheon- has quit (Ping timeout: 252 seconds)
411 2012-06-14 10:55:33 cdecker has joined
412 2012-06-14 10:58:11 MobiusL has quit (Remote host closed the connection)
413 2012-06-14 10:59:21 MobiusL has joined
414 2012-06-14 11:00:46 gjs278 has joined
415 2012-06-14 11:04:29 pickett has quit (Ping timeout: 276 seconds)
416 2012-06-14 11:05:29 Nicksasa has joined
417 2012-06-14 11:07:07 Clipse has quit (Ping timeout: 244 seconds)
418 2012-06-14 11:07:37 Vitas has joined
419 2012-06-14 11:07:43 pickett has joined
420 2012-06-14 11:10:17 Vitas has quit (Ping timeout: 252 seconds)
421 2012-06-14 11:10:19 Clipse has joined
422 2012-06-14 11:10:57 localhost has joined
423 2012-06-14 11:11:03 tower has quit (Disconnected by services)
424 2012-06-14 11:11:12 tower has joined
425 2012-06-14 11:12:10 Dyaheon has joined
426 2012-06-14 11:12:37 Maccer has quit (Excess Flood)
427 2012-06-14 11:15:35 Joric has joined
428 2012-06-14 11:17:14 p0s has joined
429 2012-06-14 11:29:04 rdponticelli has joined
430 2012-06-14 11:35:51 jurov has joined
431 2012-06-14 11:36:32 TD has joined
432 2012-06-14 11:37:46 Turingi has quit (Read error: Connection reset by peer)
433 2012-06-14 11:39:54 egecko has joined
434 2012-06-14 11:40:11 setkeh has quit (Quit: Time For a World Without Govorment Internet Interfearence)
435 2012-06-14 11:41:45 setkeh has joined
436 2012-06-14 11:41:45 agricocb has joined
437 2012-06-14 11:44:27 <jurov> hi all, i'm developing multiuser/multiwallet patch for bitcoind: https://bitcointalk.org/index.php?topic=71542.msg960484#msg960484
438 2012-06-14 11:45:07 <jurov> and want to get in touch with devs whether it's potentially acceptable
439 2012-06-14 11:47:34 <Joric> did you consider another wallet format? heard 0.7 moves towards that
440 2012-06-14 11:48:10 <TD> hmm
441 2012-06-14 11:48:17 <TD> how comes i am receiving so many orphan transactions
442 2012-06-14 11:48:18 <jurov> I don't touch the disk at all, so far it was only sufficient to use multiple CWallet objects.
443 2012-06-14 11:50:15 <TD> [Tycho]: satoshidice pays fees because bitcoinj doesn't currently contain a fee solver
444 2012-06-14 11:50:23 <TD> so clients work around that by always attaching the minimum fee
445 2012-06-14 11:51:27 <TD> once we fix that, if fireduck upgrades, i imagine SD will pay less in fees (only what is required)
446 2012-06-14 11:51:38 <TD> for now it's "free money"
447 2012-06-14 11:54:42 Maccer has joined
448 2012-06-14 11:59:49 osxorgate has joined
449 2012-06-14 12:06:41 datagutt has joined
450 2012-06-14 12:07:03 hnz has quit (Ping timeout: 240 seconds)
451 2012-06-14 12:12:35 hnz has joined
452 2012-06-14 12:17:02 hnz has quit (Ping timeout: 246 seconds)
453 2012-06-14 12:17:52 minimoose has joined
454 2012-06-14 12:18:12 devrandom has quit (Remote host closed the connection)
455 2012-06-14 12:18:54 devrandom has joined
456 2012-06-14 12:20:50 hnz has joined
457 2012-06-14 12:22:00 <sipa> jurov: moving to another wallet format can happen quite independently from multiwallet support
458 2012-06-14 12:22:17 <sipa> the largest issue with it is that it is still tied to the (single) bdb environment for now
459 2012-06-14 12:22:57 <wumpus> so you solve the 'multiwallet in rpc' problem by using multiple users... interesting
460 2012-06-14 12:23:14 <sipa> so the plan was first moving to another wallet format that's self-contained in a single file, and then adding multiple wallets
461 2012-06-14 12:23:21 <wumpus> it's less invasive than adding a wallet id to all the commands :-)
462 2012-06-14 12:23:47 <sipa> but that's mostly from a UI perspective; for RPC, this is a nice solution that doesn't require such measures
463 2012-06-14 12:24:04 <sipa> wumpus: indeed!
464 2012-06-14 12:24:40 <sipa> or making it stateful and adding a "setwallet" command
465 2012-06-14 12:25:32 <wumpus> I think it's a nice idea, as it also adds another layer of security that makes sense
466 2012-06-14 12:25:49 <sipa> it makes the rpcuser useful :)
467 2012-06-14 12:26:02 <wumpus> yep
468 2012-06-14 12:26:30 <sipa> though you'll probably want to limit non-wallet commands to authorized users only
469 2012-06-14 12:26:52 <sipa> or have some other administrative account which can set permissions/...
470 2012-06-14 12:27:07 <wumpus> the only potential thorny issue I see is user administration
471 2012-06-14 12:27:54 <wumpus> right
472 2012-06-14 12:28:56 <wumpus> some things like removing users would be really dangerous
473 2012-06-14 12:29:07 Clipse has quit (Ping timeout: 252 seconds)
474 2012-06-14 12:30:07 <wumpus> we should be careful not to drag an operating system into bitcoin :P
475 2012-06-14 12:30:58 <jurov> heh... i actually had stray thoughts to add scripting support
476 2012-06-14 12:31:17 <sipa> we already have a scripting language!
477 2012-06-14 12:31:19 <wumpus> hah
478 2012-06-14 12:31:46 <sipa> jurov: anyway, i haven't looked at the code, but i like the idea
479 2012-06-14 12:33:44 Joric has quit ()
480 2012-06-14 12:34:06 <jurov> fine. now, has anyone experience with fundraising for such project?
481 2012-06-14 12:35:06 Maccer has quit (Excess Flood)
482 2012-06-14 12:35:11 <wumpus> nope, my work on this has been mostly unpaid
483 2012-06-14 12:35:31 <sipa> etotheipi raised a few thousand for his work on armory
484 2012-06-14 12:35:51 <sipa> but my work has been unpaid as well
485 2012-06-14 12:36:22 <jurov> hm...i'm independent consultant and don't have anything atm
486 2012-06-14 12:37:31 <jurov> and this solves real need of vps providers. so i'm looking into setting up some escrow for donations
487 2012-06-14 12:38:17 hnz has quit (Ping timeout: 252 seconds)
488 2012-06-14 12:38:54 vigilyn2 has joined
489 2012-06-14 12:39:22 Maccer has joined
490 2012-06-14 12:41:29 Maccer has quit (Excess Flood)
491 2012-06-14 12:42:23 hnz has joined
492 2012-06-14 12:49:43 p0s has quit (Remote host closed the connection)
493 2012-06-14 12:50:27 vigilyn2 has left ("Leaving")
494 2012-06-14 12:54:51 Diablo-D3 has joined
495 2012-06-14 12:58:26 setkeh has quit (Quit: Time For a World Without Govorment Internet Interfearence)
496 2012-06-14 13:08:31 RainbowDashh has joined
497 2012-06-14 13:11:40 RainbowDashh has quit (Client Quit)
498 2012-06-14 13:18:35 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
499 2012-06-14 13:21:04 d4de_ has joined
500 2012-06-14 13:21:04 d4de_ has quit (Changing host)
501 2012-06-14 13:21:04 d4de_ has joined
502 2012-06-14 13:22:58 <gribble> New news from bitcoinrss: laanwj opened pull request 1461 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1461>
503 2012-06-14 13:23:22 _flow_ has quit (Ping timeout: 248 seconds)
504 2012-06-14 13:23:35 ThomasV has quit (Quit: Leaving)
505 2012-06-14 13:24:10 Turingi has joined
506 2012-06-14 13:24:15 brwyatt is now known as brwyatt|Away
507 2012-06-14 13:25:04 _flow_ has joined
508 2012-06-14 13:25:07 d4de_ has quit (Client Quit)
509 2012-06-14 13:25:17 d4de has quit (Remote host closed the connection)
510 2012-06-14 13:25:36 drizztbsd has joined
511 2012-06-14 13:25:39 d4de has joined
512 2012-06-14 13:25:39 d4de has quit (Changing host)
513 2012-06-14 13:25:39 d4de has joined
514 2012-06-14 13:33:13 Clipse has joined
515 2012-06-14 13:39:07 setkeh has joined
516 2012-06-14 13:41:17 gavinandresen has joined
517 2012-06-14 13:43:09 setkeh has quit (Client Quit)
518 2012-06-14 13:45:05 setkeh has joined
519 2012-06-14 13:54:59 <sipa> i wonder
520 2012-06-14 13:55:14 <sipa> why do we need to keep txins of old transactions around?
521 2012-06-14 13:55:38 <sipa> you need the txouts' amounts and scripts
522 2012-06-14 13:55:48 <sipa> and the transaction hash
523 2012-06-14 13:56:02 <tcatm> We need them to verify the chain. don't we?
524 2012-06-14 13:56:12 <sipa> after verifying and storing them
525 2012-06-14 13:56:21 setkeh has quit (Quit: Time For a World Without Govorment Internet Interfearence)
526 2012-06-14 13:56:23 <tcatm> But yes, they could be pruned just as Satoshi described it in his paper.
527 2012-06-14 13:57:44 <sipa> right, it would mean being unable to serve the chain
528 2012-06-14 13:58:24 copumpkin has quit (Quit: Computer has gone to sleep.)
529 2012-06-14 13:58:29 setkeh has joined
530 2012-06-14 13:58:34 _flow_ has quit (Ping timeout: 248 seconds)
531 2012-06-14 14:00:20 ThomasV has joined
532 2012-06-14 14:02:35 setkeh has quit (Client Quit)
533 2012-06-14 14:03:21 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
534 2012-06-14 14:03:24 <gribble> New news from bitcoinrss: xanatos opened issue 1462 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1462>
535 2012-06-14 14:04:26 setkeh has joined
536 2012-06-14 14:04:55 toffoo has joined
537 2012-06-14 14:05:40 <luke-jr> sipa: I just got 0.4.x to reorganize 6814 blocks in a single bdb transaction
538 2012-06-14 14:06:05 <BlueMatt> early blocks?
539 2012-06-14 14:06:07 <luke-jr> took 6 hours, but worked
540 2012-06-14 14:06:13 <luke-jr> BlueMatt: no, the most recent 6814
541 2012-06-14 14:06:17 <luke-jr> as of last night
542 2012-06-14 14:06:24 <BlueMatt> increased lock objects a ton?
543 2012-06-14 14:06:27 <luke-jr> yes
544 2012-06-14 14:06:31 <luke-jr> 100 fold
545 2012-06-14 14:06:35 <BlueMatt> peak memory usage?
546 2012-06-14 14:06:52 <luke-jr> about 768 MB
547 2012-06-14 14:07:41 <luke-jr> hmm
548 2012-06-14 14:07:42 <luke-jr> maybe higher
549 2012-06-14 14:07:53 <gmaxwell> Hm. 6 hours... not sure if thats fast enough to be considered 'worked'.
550 2012-06-14 14:08:06 <gmaxwell> I guess for an unattended server...
551 2012-06-14 14:08:42 <BlueMatt> gmaxwell: 6 hours in one tx vs 6.1 hours in 6814 txes...
552 2012-06-14 14:08:52 <BlueMatt> either way the gui/rpc interface will appear the same
553 2012-06-14 14:09:59 <luke-jr> the important thing is that it finished IMO
554 2012-06-14 14:10:16 <gmaxwell> BlueMatt: well the count won't update along the way, no?
555 2012-06-14 14:10:17 <sipa> gmaxwell: regarding the "merkle root of unspent outputs in coinbase"... i believe it could be calculated on the txids+txout data, so a light node would only need to keep those
556 2012-06-14 14:10:44 <BlueMatt> gmaxwell: currently the block count wont update, no...Im gonna fix that in cblockstore at some point though as it should be easy to do there...
557 2012-06-14 14:11:08 <gmaxwell> sipa: Hm. etothipi was arguing txout data... but I pointed out that it wasn't enough. txids+txout perhaps would be.
558 2012-06-14 14:11:13 <luke-jr> is there any harm in increasing locks 100fold?
559 2012-06-14 14:11:17 _flow_ has joined
560 2012-06-14 14:11:42 Maccer has joined
561 2012-06-14 14:12:17 * luke-jr wonders why the reorg didn't max out any resource constantly
562 2012-06-14 14:12:38 <luke-jr> instead, it has bursts of CPU use
563 2012-06-14 14:13:08 <sipa> i suppose bdb switching between updating to log file, and committing log
564 2012-06-14 14:13:18 <gmaxwell> jrmithdobbs: See that seccomp mode 2 made it into the linux kernel? Would make for a much improved refresh of that capabilities patch.
565 2012-06-14 14:13:23 <BlueMatt> luke-jr: what was you database dir size max?
566 2012-06-14 14:13:43 <luke-jr> BlueMatt: I wasn't monitoring that.
567 2012-06-14 14:13:57 <luke-jr> sipa: I never saw hard drive activity solid
568 2012-06-14 14:13:59 <BlueMatt> if you never closed bitcoin after reorg it should still be at max
569 2012-06-14 14:14:39 <luke-jr> I did :/
570 2012-06-14 14:14:42 <sipa> gmaxwell: would result in a factor 2 less space, imho
571 2012-06-14 14:15:39 <sipa> and maybe it would even make sense to build a new such datastructure for every let's say 1000 blocks
572 2012-06-14 14:16:08 <sipa> as most likely the more recent ones will be accessed much more frequently
573 2012-06-14 14:16:20 <sipa> resulting in better cache usage
574 2012-06-14 14:16:40 copumpkin has joined
575 2012-06-14 14:17:11 <luke-jr> so⦠is there any harm in increasing locks 100fold?
576 2012-06-14 14:17:45 <sipa> luke-jr: what's the effect on base memory usage?
577 2012-06-14 14:18:00 <luke-jr> sipa: I presume none, it's a maximum
578 2012-06-14 14:18:07 <sipa> right
579 2012-06-14 14:19:54 RainbowDashh has joined
580 2012-06-14 14:20:53 <sipa> i think it'd make sense to separate the block-serving and tx-verifying systems entirely
581 2012-06-14 14:21:24 <luke-jr> memory peaked ~1280 MB right before it finished
582 2012-06-14 14:21:46 <sipa> you choose to either keep just block headers, or the full txout merkle tree
583 2012-06-14 14:22:12 <sipa> and independently choose whether (and which) blocks you keep in full to serve to other nodes
584 2012-06-14 14:24:38 <sipa> the txout merkle tree will presumably be more efficient for verification anyway
585 2012-06-14 14:31:44 drizztbsd has quit (Ping timeout: 265 seconds)
586 2012-06-14 14:32:16 lukys has joined
587 2012-06-14 14:33:21 drizztbsd has joined
588 2012-06-14 14:33:53 lukys has left ()
589 2012-06-14 14:35:24 davout has joined
590 2012-06-14 14:37:24 <luke-jr> sipa: weird
591 2012-06-14 14:37:48 <luke-jr> as measured by top (RES), base memory use is 9 times greater (50 MB vs 442 MB)
592 2012-06-14 14:37:53 <luke-jr> as measured by ps (SIZE), it's the same
593 2012-06-14 14:38:19 <luke-jr> does that mean it's spare memory allocations or something? O.o
594 2012-06-14 14:39:07 <sipa> and what is the number reported by ps?
595 2012-06-14 14:39:57 <luke-jr> 103 MB
596 2012-06-14 14:40:35 <luke-jr> I usually prefer ps because it reports swap too
597 2012-06-14 14:41:23 <sipa> i'd expect resident set size to be less than allocated memory...
598 2012-06-14 14:44:14 D34TH has joined
599 2012-06-14 14:44:29 <luke-jr> I don't know how to get allocated memory
600 2012-06-14 14:44:43 <luke-jr> SIZE is "how much disk space would be used if the entire process were in swap"
601 2012-06-14 14:45:07 <luke-jr> which I presume could exclude unused allocations
602 2012-06-14 14:50:02 <wumpus> there is no way to get allocated memory from the OS, as the OS is not concerned with that
603 2012-06-14 14:50:20 <wumpus> it just knows the amount and status of pages mapped to the process
604 2012-06-14 14:50:41 <gmaxwell> It does know if the pages are dirty or not.
605 2012-06-14 14:50:58 <wumpus> which only tells if it was recently used, not wether it was allocated
606 2012-06-14 14:51:11 <jgarzik> pages don't tend to stay dirty for long
607 2012-06-14 14:51:26 <jgarzik> one may make a guess by counting anonymously mapped pages
608 2012-06-14 14:51:30 <wumpus> or freed... some mallloc implementations never give back memory to the OS
609 2012-06-14 14:52:06 <jgarzik> today's glibc allocates via big anon blocks, which does permit some OS reclaim
610 2012-06-14 14:52:15 <jgarzik> sbrk has gone the way of the dodo
611 2012-06-14 14:52:29 <wumpus> yeah, on linux it's good
612 2012-06-14 14:53:27 <luke-jr> wumpus: how about pages mapped?
613 2012-06-14 14:54:06 <wumpus> how does that help? even with some reclaim, it will probably keep around freed memory for quite some time because it might be re-used just after
614 2012-06-14 14:56:58 <luke-jr> I'm checking use immediately after startup :p
615 2012-06-14 14:57:42 <wumpus> well in that case it's certainly more reliable than a long-running process
616 2012-06-14 14:57:50 RainbowDashh has quit (Ping timeout: 265 seconds)
617 2012-06-14 15:12:20 Zarutian has joined
618 2012-06-14 15:13:18 Prattler has quit (Remote host closed the connection)
619 2012-06-14 15:25:59 ThomasV has quit (Quit: Quitte)
620 2012-06-14 15:27:41 <someone42> would it be correct to say that in order to securely generate a P2SH address, all signing devices must be able to independently generate it?
621 2012-06-14 15:27:54 <sipa> "it" being the address?
622 2012-06-14 15:28:01 <someone42> yeah
623 2012-06-14 15:28:16 <sipa> you just need to know the pubkeys involved of all signing devices
624 2012-06-14 15:28:53 <someone42> but how would you know the P2SH address generator isn't replacing pubkeys?
625 2012-06-14 15:29:31 <sipa> the generator can prove it, by revealing the full script
626 2012-06-14 15:29:56 Ahimoth has joined
627 2012-06-14 15:31:17 <someone42> a compromised generator could reveal the correct, full script to the user, but then covertly replace pubkeys when actually generating addresses
628 2012-06-14 15:32:34 <sipa> all users involved tell eachother their pubkeys
629 2012-06-14 15:32:47 <sipa> all users involved generate the address from it
630 2012-06-14 15:33:04 <sipa> all users involved know the address and can see whether the others use it correctly
631 2012-06-14 15:33:13 <sipa> s/users/devices/ if you like
632 2012-06-14 15:34:17 <someone42> ok, so as i understand it, devices need to be able to independently swap pubkeys and generate addresses
633 2012-06-14 15:34:52 chmod755 has joined
634 2012-06-14 15:36:44 <sipa> well, public keys are not a secret
635 2012-06-14 15:37:07 <sipa> to verify that an untrusted address is correct, you do indeed need to know all public keys to verify it
636 2012-06-14 15:40:40 <sipa> ha!
637 2012-06-14 15:40:41 <sipa> $ git fetch -all
638 2012-06-14 15:40:41 <sipa> error: did you mean `--all` (with two dashes ?)
639 2012-06-14 15:46:24 <drizztbsd> git remote update
640 2012-06-14 15:47:23 chrisb__ has joined
641 2012-06-14 15:47:32 <sipa> ha, useful!
642 2012-06-14 15:48:47 Joric has joined
643 2012-06-14 15:48:47 Joric has quit (Changing host)
644 2012-06-14 15:48:47 Joric has joined
645 2012-06-14 15:50:56 <sipa> ;;bc,blocks
646 2012-06-14 15:50:57 <gribble> 184511
647 2012-06-14 15:57:55 chmod755 has quit (Ping timeout: 248 seconds)
648 2012-06-14 15:57:55 t7 has quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0/20120605113340])
649 2012-06-14 15:58:43 paul0 has joined
650 2012-06-14 16:00:22 ciscoftw has joined
651 2012-06-14 16:10:14 chrisb__ has quit (Quit: Leaving)
652 2012-06-14 16:10:34 <epscy> using bitcoind, how many confirms does a received payment need before getinfo will show it as being a part of your balance?
653 2012-06-14 16:10:39 <epscy> i assumed it was one
654 2012-06-14 16:10:55 Karmaon has joined
655 2012-06-14 16:11:02 <sipa> 1
656 2012-06-14 16:11:10 <epscy> sipa: thanks
657 2012-06-14 16:11:22 <sipa> for payments-to-self and change, i believe 0
658 2012-06-14 16:12:39 <luke-jr> who's available to build 0.4.x and 0.5.x gitian binaries? should probably plan to get these up on SFâ¦
659 2012-06-14 16:18:13 Hasbro has joined
660 2012-06-14 16:18:29 Motest003 has joined
661 2012-06-14 16:23:19 sgornick has quit (Ping timeout: 244 seconds)
662 2012-06-14 16:24:47 sgornick has joined
663 2012-06-14 16:27:55 setkeh has quit (Quit: Time For a World Without Govorment Internet Interfearence)
664 2012-06-14 16:28:16 agricocb has quit (Quit: Leaving.)
665 2012-06-14 16:29:25 setkeh has joined
666 2012-06-14 16:31:08 Joric has quit ()
667 2012-06-14 16:34:28 * luke-jr larts rebroad
668 2012-06-14 16:35:23 cdecker has quit (Quit: Leaving.)
669 2012-06-14 16:37:00 agricocb has joined
670 2012-06-14 16:37:12 agricocb has quit (Changing host)
671 2012-06-14 16:37:12 agricocb has joined
672 2012-06-14 16:41:07 <gribble> New news from bitcoinrss: sipa opened pull request 1463 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1463>
673 2012-06-14 16:44:11 RV__ has quit (Quit: Leaving)
674 2012-06-14 16:54:19 t7 has joined
675 2012-06-14 16:55:31 OneFixt has quit (Read error: Connection reset by peer)
676 2012-06-14 16:55:51 OneFixt has joined
677 2012-06-14 16:56:07 <luke-jr> BlueMatt: what exactly does this do? 4d00924 Fix DEBUG_LOCKCONTENTION
678 2012-06-14 16:57:20 RainbowDashh has joined
679 2012-06-14 16:58:20 RainbowDashh has quit (Client Quit)
680 2012-06-14 17:01:09 <BlueMatt> luke-jr: fixes a compile error if compiled with DEBUG_LOCKCONTENTION
681 2012-06-14 17:01:53 <luke-jr> BlueMatt: I only see noop change
682 2012-06-14 17:01:57 <luke-jr> how does it fix it?
683 2012-06-14 17:07:26 RainbowDashh has joined
684 2012-06-14 17:08:24 Eleuthria has joined
685 2012-06-14 17:08:27 <BlueMatt> how is that a noop?
686 2012-06-14 17:08:41 <BlueMatt> sync.h is included before util.h, so printf isnt defined
687 2012-06-14 17:09:13 <luke-jr> ah!
688 2012-06-14 17:09:32 <luke-jr> that's a sneaky hidden bug :/
689 2012-06-14 17:09:34 RainbowDashh has quit (Client Quit)
690 2012-06-14 17:11:19 <wumpus> that's what you get for redefining printf
691 2012-06-14 17:11:33 <wumpus> it's a really evil thing to do
692 2012-06-14 17:11:36 <wumpus> :p
693 2012-06-14 17:11:38 <luke-jr> yeah, we should probably just rename every use to applog or something
694 2012-06-14 17:11:48 <luke-jr> maybe with loglevels too <.<
695 2012-06-14 17:11:55 RainbowDashh has joined
696 2012-06-14 17:11:57 sirk390 has left ()
697 2012-06-14 17:12:52 <wumpus> I don't care about the levels, but renaming sounds good
698 2012-06-14 17:13:26 RainbowDashh has quit (Disconnected by services)
699 2012-06-14 17:13:27 RainbowD_ has joined
700 2012-06-14 17:13:30 RainbowD_ is now known as RainbowDashh
701 2012-06-14 17:16:51 <BlueMatt> meh, its not worth chaning every call to printf and breaking a ton of pulls to do that
702 2012-06-14 17:17:01 <BlueMatt> that bug would still have existed
703 2012-06-14 17:17:07 <wumpus> it is worth it, eventually
704 2012-06-14 17:17:12 <BlueMatt> meh
705 2012-06-14 17:17:26 <BlueMatt> we've never had any problems as a result of redefining printf afaik
706 2012-06-14 17:17:35 <wumpus> it's not just about this bug but also future ones caused by this, and new developers getting confused by it
707 2012-06-14 17:17:46 <wumpus> it's simply something that should not be done
708 2012-06-14 17:17:59 <BlueMatt> redefinition of printf has nothing to do with this bug
709 2012-06-14 17:18:03 <wumpus> printf is a perfectly normal libc function, it has a well-defined meaning
710 2012-06-14 17:18:24 <wumpus> using a macro to redefine it is really ugly
711 2012-06-14 17:19:23 Detritus has quit (Quit: Konversation terminated!)
712 2012-06-14 17:19:33 <BlueMatt> it is, but my point is its not worth changing now
713 2012-06-14 17:19:45 <wumpus> my point is that I disagree on that
714 2012-06-14 17:20:06 <BlueMatt> ok
715 2012-06-14 17:20:34 ThomasV has joined
716 2012-06-14 17:21:06 agricocb has quit (Quit: Leaving.)
717 2012-06-14 17:21:30 Z0rZ0rZ0r has quit (Quit: Leaving)
718 2012-06-14 17:26:42 RainbowD_ has joined
719 2012-06-14 17:26:42 RainbowDashh has quit (Disconnected by services)
720 2012-06-14 17:26:45 RainbowD_ is now known as RainbowDashh
721 2012-06-14 17:27:06 <gribble> New news from bitcoinrss: Diapolo opened pull request 1464 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1464>
722 2012-06-14 17:30:26 agricocb has joined
723 2012-06-14 17:32:10 <gribble> New news from bitcoinrss: Diapolo opened pull request 1465 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1465>
724 2012-06-14 17:34:11 wizkid057 has quit (Read error: Connection reset by peer)
725 2012-06-14 17:34:27 wizkid057 has joined
726 2012-06-14 17:37:17 setkeh has quit (Quit: Time For a World Without Govorment Internet Interfearence)
727 2012-06-14 17:38:08 guruvan has quit (Remote host closed the connection)
728 2012-06-14 17:38:58 guruvan has joined
729 2012-06-14 17:43:24 setkeh has joined
730 2012-06-14 17:47:01 sgornick has quit (Quit: Ex-Chat)
731 2012-06-14 17:48:38 smtmnyz_ is now known as smtmnyz
732 2012-06-14 17:48:46 davout has quit (Remote host closed the connection)
733 2012-06-14 17:49:10 superman2016 has joined
734 2012-06-14 17:50:51 * luke-jr grumbles
735 2012-06-14 17:52:31 <gribble> New news from bitcoinrss: Diapolo opened issue 1466 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1466>
736 2012-06-14 17:53:10 <luke-jr> why do I get the feeling Diapolo broke test_bitcoin? <.<
737 2012-06-14 17:59:23 TD has quit (Quit: TD)
738 2012-06-14 18:02:05 <luke-jr> ah, wumpus fixed it :D
739 2012-06-14 18:03:00 <BlueMatt> read scrollback, jenkins caught it hours ago ;)
740 2012-06-14 18:03:12 <luke-jr> heh
741 2012-06-14 18:07:02 <luke-jr> BlueMatt: will you be available to build 0.4.7 & 0.5.6?
742 2012-06-14 18:08:14 <BlueMatt> Ive gotta get gitian working, but Ill go do that...for when?
743 2012-06-14 18:08:39 <luke-jr> probably in an hour or so
744 2012-06-14 18:08:49 <BlueMatt> uhh...well Ill see
745 2012-06-14 18:08:51 <luke-jr> after I've confirmed they build myself
746 2012-06-14 18:10:12 osxorgate has quit (Quit: Take it easy)
747 2012-06-14 18:11:46 MobiusL has quit (Quit: Ex-Chat)
748 2012-06-14 18:15:30 MobiusL has joined
749 2012-06-14 18:24:13 rdponticelli has quit (Ping timeout: 265 seconds)
750 2012-06-14 18:24:19 Nolybab has joined
751 2012-06-14 18:26:01 Prattler has joined
752 2012-06-14 18:28:56 <BlueMatt> [Tycho]: what is up with sendmulti? you said you were gonna implement it months ago and still havent?
753 2012-06-14 18:31:41 * copumpkin gets some popcorn
754 2012-06-14 18:32:44 <BlueMatt> meh, he wont respond because for some bright reason the other person behind deepbit who doesnt do pr "doesnt like multisend"
755 2012-06-14 18:32:58 <copumpkin> sounds awfully convenient
756 2012-06-14 18:33:28 <copumpkin> in any negotiation, it's never you who doesn't want something. It's your partner/wife/husband/someone unseen
757 2012-06-14 18:33:34 <copumpkin> "if it were up to me I'd do it now"
758 2012-06-14 18:33:41 <copumpkin> "but you know, my wife doesn't want it"
759 2012-06-14 18:33:42 <BlueMatt> yep
760 2012-06-14 18:33:55 MC1984 has quit (Quit: Leaving)
761 2012-06-14 18:34:05 lukys has joined
762 2012-06-14 18:34:10 * BlueMatt wishes this were solidcoin so we could arbitrarily throw deepbit and satoshidice out
763 2012-06-14 18:34:42 <copumpkin> lol
764 2012-06-14 18:34:57 <copumpkin> nothing fundamentally wrong with satoshidice
765 2012-06-14 18:35:06 <BlueMatt> uhh...the lack of sendmulti?
766 2012-06-14 18:35:25 <BlueMatt> if they just bunched up txes each minute, they would decrease their chain load by like 1/10th
767 2012-06-14 18:35:31 <copumpkin> fair enough
768 2012-06-14 18:35:41 <copumpkin> have you contacted the guys behind it?
769 2012-06-14 18:35:43 <BlueMatt> not chain size, mind you, but chain load in terms of txes
770 2012-06-14 18:35:45 <BlueMatt> yes
771 2012-06-14 18:36:07 <BlueMatt> see the rediculously long thread of people refusing to read anything but the first post and responding: https://bitcointalk.org/index.php?topic=87444.0
772 2012-06-14 18:36:11 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
773 2012-06-14 18:37:03 <BlueMatt> and I pmd multiple people asking for comment, but...
774 2012-06-14 18:37:33 <copumpkin> BlueMatt: about the pruning question
775 2012-06-14 18:38:06 <copumpkin> it seems to me like there's no need to _store_ the entire blockchain history is there?
776 2012-06-14 18:38:12 <copumpkin> meaning when you first fire up your client, you "download" all of it
777 2012-06-14 18:38:25 <copumpkin> but discard it as you go along, just remembering the earlier hashes
778 2012-06-14 18:38:41 <Eliel> copumpkin: someone needs to keep it, otherwise there's no-one to download it from.
779 2012-06-14 18:38:47 RainbowDashh has joined
780 2012-06-14 18:38:52 <copumpkin> yeah, but it could be probabilistic
781 2012-06-14 18:39:03 <copumpkin> with 1/10 users keeping it or something :P
782 2012-06-14 18:39:08 <copumpkin> I guess that'd increase strain on them
783 2012-06-14 18:39:12 <copumpkin> or people could opt into being supernodes
784 2012-06-14 18:39:25 erle- has joined
785 2012-06-14 18:40:56 rdponticelli has joined
786 2012-06-14 18:44:25 drizztbsd has quit (Read error: Connection reset by peer)
787 2012-06-14 18:44:29 Maccer has quit (Ping timeout: 244 seconds)
788 2012-06-14 18:44:53 drizztbsd has joined
789 2012-06-14 18:46:07 MC1984 has joined
790 2012-06-14 18:49:11 <lukys> ni'o Is there any way to connect to the network behind an http proxy?
791 2012-06-14 18:50:01 <BlueMatt> lukys: in bitcoin-qt? check the settings dialog, in bitcoind use -proxy
792 2012-06-14 18:50:18 <lukys> That's a socks proxy.
793 2012-06-14 18:50:30 <BlueMatt> I believe if you use socks4 it should be identical?
794 2012-06-14 18:50:38 <lukys> I'm behind an http proxy with authentication.
795 2012-06-14 18:51:48 <lukys> I have a username and password that I need to use to access the internet.
796 2012-06-14 18:51:55 _flow_ has quit (Ping timeout: 248 seconds)
797 2012-06-14 18:53:21 <BlueMatt> oh, yea, we may not support proxy auth...
798 2012-06-14 18:53:43 <lukys> Is that a possibility for future releases?
799 2012-06-14 18:53:54 <BlueMatt> copumpkin: yes, pruning is an option, see the recent thread TD (tried) to start on the bitcoin-dev mailing list
800 2012-06-14 18:54:16 <BlueMatt> lukys: someone would have to implement it, and afaik no one is currently doing that so...patches welcome ;)
801 2012-06-14 18:54:48 <lukys> It's times like this I wish I could code...
802 2012-06-14 18:54:54 <lukys> I keep trying to learn but I'm useless
803 2012-06-14 18:54:57 RV__ has joined
804 2012-06-14 18:57:53 <gmaxwell> lukys: Have patience and keep trying. If you keep at it you'll learn.
805 2012-06-14 18:58:27 <guruvan> after like 20yrs of hacking at linux, I'm starting to learn to write a little code :D
806 2012-06-14 18:58:44 <BlueMatt> lukys: people here will gladly help you if you have questions
807 2012-06-14 18:59:23 <lukys> I've recently started delving into the figurative intestines of Linux. I'm doing LFS at the moment :)
808 2012-06-14 18:59:35 <lukys> That's a nice offer, thank you.
809 2012-06-14 18:59:42 <lukys> It's C++, isn't it?
810 2012-06-14 19:00:14 Maccer has joined
811 2012-06-14 19:00:21 toffoo has quit ()
812 2012-06-14 19:00:46 <gmaxwell> lukys: Learning Linux in detail is actually a great thing to do to learn programming... simply because a lot of the C culture is well embodied in Unix and there is an assumption that programmers are all unix power users and know all this stuff.
813 2012-06-14 19:01:29 _flow_ has joined
814 2012-06-14 19:01:39 <guruvan> ^^ this - this is how I know anything about code - building gentoo & LFS systems is awesome for this
815 2012-06-14 19:02:27 <gmaxwell> Its also a lot easier to get started and more rewarding for beginners to make small changes to the programs you use than it is to write whole big programs. Plus the way you become _good_ at programming once you know how to do it is reading a LOT of code.
816 2012-06-14 19:04:28 <lukys> I just do tutorials and stuff, then try reading things that other people have written and I'm just like "wahh?"
817 2012-06-14 19:04:52 <lukys> I think I need to go on an actual course with a real teacher
818 2012-06-14 19:05:02 <gmaxwell> When I started using Linux back in the SLS and early slackware days all linux was a lot more like gentoo than modern distros are. On my own systems I eventually walked them through the transistions from a.out binaries to elf and libc to glibc, both of which required recompiling everything.
819 2012-06-14 19:06:30 <gmaxwell> I've been recently recommending this to people: http://c.learncodethehardway.org/book/ though it presumes some preexisting programming expirence, it uses a very direct get down to business approach that I think is good.
820 2012-06-14 19:07:00 <Diablo-D3> c the hard way?
821 2012-06-14 19:07:08 <Diablo-D3> isnt it already hard enough?
822 2012-06-14 19:07:54 <gmaxwell> (In some ways C is a good beginning languageâ though it's ruthless and hard the language itself is very small, so once you know the basics you won't find things which are completely foreign to you. C is hard because its very low level and you have to actually think clearly about what you want the machine to do)
823 2012-06-14 19:09:16 <BlueMatt> except then you have to go back and learn oop separately, but, I agree for the most part
824 2012-06-14 19:09:31 <Diablo-D3> C is a good language to think in, imo
825 2012-06-14 19:09:39 <Diablo-D3> its so brutal that it MAKES a programmer out of you
826 2012-06-14 19:09:48 <Diablo-D3> complete with disney musical scene.
827 2012-06-14 19:10:03 * BlueMatt always laughs when people bitch about having to code in c in a class mostly taught in java
828 2012-06-14 19:10:22 <Diablo-D3> I dont know why people hate C so much
829 2012-06-14 19:10:26 <Diablo-D3> its a wonderful language to code in
830 2012-06-14 19:10:30 <BlueMatt> agreed
831 2012-06-14 19:10:39 <luke-jr> yay C
832 2012-06-14 19:11:06 <Diablo-D3> it makes you think about every last line of code
833 2012-06-14 19:11:15 <Diablo-D3> so you're forced to write the best code possibly
834 2012-06-14 19:11:23 <Diablo-D3> none of this lazy shit java fucks you in the ass with
835 2012-06-14 19:13:32 <lukys> I have given C a go.
836 2012-06-14 19:13:45 <lukys> It seems great, I'm just bad at it.
837 2012-06-14 19:14:07 <Diablo-D3> like I said, it makes a programmer out of you
838 2012-06-14 19:14:18 <gmaxwell> Meh. The only way to be bad at it forever is to believe you're good at it.
839 2012-06-14 19:14:19 <lukys> I made a little number guessing game, which worked, but I couldn't figure out how to catch non-integers.
840 2012-06-14 19:14:21 <sneak> hi
841 2012-06-14 19:14:43 <lukys> So it broke if you typed in a letter or something.
842 2012-06-14 19:14:53 <gmaxwell> lukys: use strtol instead of atoi. :)
843 2012-06-14 19:14:54 <sneak> i think i am going to become a cpp hacker
844 2012-06-14 19:15:31 <gmaxwell> lukys: or be crazy and write your own code to iterate over the input and check for characters.
845 2012-06-14 19:15:48 <lukys> I tried that.
846 2012-06-14 19:15:52 Detritus has joined
847 2012-06-14 19:15:55 <lukys> The latter, that is.
848 2012-06-14 19:15:59 <sneak> i like the idea of a reusable set of good code that isn't cocoa
849 2012-06-14 19:16:13 <sneak> and it seems like cpp (via boost and such) has that
850 2012-06-14 19:16:19 <sneak> i mean, i don't think it's an accident that bitcoin uses boost so much
851 2012-06-14 19:16:31 <gmaxwell> sneak: boost makes bitcoin a lot smaller than it would be other wise.
852 2012-06-14 19:16:46 <gmaxwell> Boost also introduces mysterious bugs from time to time. Mixed blessing.
853 2012-06-14 19:16:46 <sneak> i think that cpp+good libs is probably on par these days with, ex, interpereted languages
854 2012-06-14 19:16:52 <sneak> without being written in an interpreted language :)
855 2012-06-14 19:17:34 <BlueMatt> sneak: uhh...should be the other way around there
856 2012-06-14 19:17:44 <BlueMatt> interpreted languages are starting to catch up to cpp
857 2012-06-14 19:17:57 <sneak> i mean, in ease of development
858 2012-06-14 19:18:00 <sneak> rapid prototyping
859 2012-06-14 19:18:05 <sneak> not final output quality, obv compiled wins there
860 2012-06-14 19:19:08 <gmaxwell> maybe, debugability kinda sucks. C++ still admits low level failures like memory corruption, but unlike in C there are a zillion layers of indirection between the crash and your code.
861 2012-06-14 19:19:14 <BlueMatt> I find cpp much easier to develop in, you get errors at compile time...
862 2012-06-14 19:19:19 <BlueMatt> well, sanity errors
863 2012-06-14 19:19:24 TD has joined
864 2012-06-14 19:19:29 <gmaxwell> BlueMatt: you do in java too.
865 2012-06-14 19:19:36 <BlueMatt> gmaxwell: thats half because of boost
866 2012-06-14 19:19:47 <BlueMatt> gmaxwell: and I find java easier to dev in than cpp
867 2012-06-14 19:19:49 <gmaxwell> The python sanity errors at runtime are just absolutely nuts.
868 2012-06-14 19:19:52 <BlueMatt> not that the result is any good...
869 2012-06-14 19:21:31 <gmaxwell> I went through a phase where I said "my time is more valuable than the CPUs' I'll use python for 100% of my single use programs" only to have computations take 10 hours and then die when they were to print the solution because of a typo that the C compiler would have caught.. and meanwhile the same task in C completed in under a half hour.
870 2012-06-14 19:22:20 AlexWaters has joined
871 2012-06-14 19:22:35 <BlueMatt> gmaxwell: yep, I never hit that phrase after being forced to use java for class and then writing c for single-use stuff and realizing its a billion and a half times faster...
872 2012-06-14 19:24:14 <gmaxwell> Java generally makes you write a lot of boilerplate, making it less good for rapid prototyping. Also, the fact that python integers are infinite range makes a lot of code simpler (well, at least for me).
873 2012-06-14 19:24:17 <BlueMatt> (yea, yea java is theoretically quick thanks to its good jit and whatnot, but...)
874 2012-06-14 19:24:27 <Diablo-D3> java boilertype fucking pisses me off
875 2012-06-14 19:24:32 <Diablo-D3> its one of the reasons I quit java
876 2012-06-14 19:24:48 <Diablo-D3> if Im going to write boilerplate, Im going to have fucking cpp do it for me
877 2012-06-14 19:24:51 <BlueMatt> gmaxwell: true, but use any ide and thats all done for you...
878 2012-06-14 19:25:29 <gmaxwell> I saw this the other day: http://blog.sanctum.geek.nz/series/unix-as-ide/
879 2012-06-14 19:25:52 <Diablo-D3> bluematt: thats the fucking problem
880 2012-06-14 19:25:54 <Diablo-D3> ides ruin code
881 2012-06-14 19:26:13 <Diablo-D3> vim, a few xterms with bash or man in them, one to run make in, bam
882 2012-06-14 19:26:14 <Diablo-D3> entire ide
883 2012-06-14 19:26:18 * BlueMatt never uses an ide to code for anything real, but if I have to write java for class or whatever, ide it is
884 2012-06-14 19:26:30 <BlueMatt> Diablo-D3: yep, thats my ide for cpp/c
885 2012-06-14 19:26:56 <lukys> xterminate!
886 2012-06-14 19:27:03 <lukys> >.>
887 2012-06-14 19:27:36 <Diablo-D3> <_<
888 2012-06-14 19:27:46 <jurov> i envy people that remember enough to code in just vim.... i tend to google almost every fking for cycle
889 2012-06-14 19:28:01 <sneak> i can't use gui editors now
890 2012-06-14 19:28:04 <sneak> after spending so much time in vim
891 2012-06-14 19:28:06 <gmaxwell> I spent 15 hours a day last week in a room with a couple of other coders getting a start on a new video codec, mostly prototyping and mathematics work. One of us is a Java+IDE user and he was a lot faster at working on certian tasks. So there are things that kind of enviroment does better.
892 2012-06-14 19:28:09 <sneak> even for personal todo lists
893 2012-06-14 19:29:12 <BlueMatt> gmaxwell: agreed, but it also removes some effort in trying to deal with the ide itself...
894 2012-06-14 19:29:16 <gmaxwell> jurov: the Learn C the hardway book rags on IDEs for causing that kind of short attention span and poor memory. I never use google while programming, I do use man and grep a lot.
895 2012-06-14 19:29:31 maqr has joined
896 2012-06-14 19:29:43 <jurov> gmaxwell, i'd love to... but had to switch language evey year or so
897 2012-06-14 19:29:50 <BlueMatt> gmaxwell: s/man/cplusplus.com/ when working on cpp
898 2012-06-14 19:31:36 datagutt has quit (Quit: kthxbai)
899 2012-06-14 19:32:54 <jurov> anyone knows http://drakon-editor.sourceforge.net/ ? it's rather alien concept but i'm slowly but surely falling in love
900 2012-06-14 19:33:43 <jurov> but it can't import code and generated code can be unmaintainable :(
901 2012-06-14 19:35:59 <sneak> that's cool as hell
902 2012-06-14 19:36:05 <gmaxwell> jurov: There have been lots of visual programming languages made... they're interesting, but other than for dataflow problems (e.g. see Max/MSP, PD, and GNURadio) I've not seen them get wide adoption. Part of the challenge is that text is just a very efficient way to communicate.
903 2012-06-14 19:36:14 RazielZ has quit (Ping timeout: 245 seconds)
904 2012-06-14 19:37:11 <sneak> i am thinking of writing a javascript-to-python transpiler
905 2012-06-14 19:37:24 <sneak> seeing as there's now an llvm-bytecode-to-javascript tool for compiling c to js
906 2012-06-14 19:37:30 <BlueMatt> sneak: Im 99% sure such a thing already exists
907 2012-06-14 19:37:52 <jurov> i agree but walls of text intimidate me.. and drakon scheme actually requires comparable screen estate to equivalent code
908 2012-06-14 19:37:55 <sneak> there's one for the other direction, pyjs
909 2012-06-14 19:38:26 <jurov> sneak, what would you use it for?
910 2012-06-14 19:38:27 <Diablo-D3> [03:24:41] <gmaxwell> I spent 15 hours a day last week in a room with a couple of other coders getting a start on a new video codec, mostly prototyping and mathematics work. One of us is a Java+IDE user and he was a lot faster at working on certian tasks. So there are things that kind of enviroment does better.
911 2012-06-14 19:38:28 <Diablo-D3> thats the problem
912 2012-06-14 19:38:31 <sneak> uglifyjs already spits out a nice AST from javascript
913 2012-06-14 19:38:32 <Diablo-D3> fast != good
914 2012-06-14 19:38:43 <sneak> jurov: well, if it can deal with the output of the c-to-javascript llvm thing
915 2012-06-14 19:38:49 <sneak> then i could make pure python versions of c libs
916 2012-06-14 19:39:02 <gmaxwell> Diablo-D3: it is for single use problem solving.. code that will be run once to a few times and then thrown out.
917 2012-06-14 19:39:16 <sneak> i'm trying to achieve the cross-platform holy grail for some apps i'm writing, and python seems like the path of least resistance in a lot of cases
918 2012-06-14 19:39:32 <sneak> python using only python stdlib is exceptionally portable, and easy to write
919 2012-06-14 19:39:38 <gmaxwell> haha
920 2012-06-14 19:39:40 <gmaxwell> sorry.
921 2012-06-14 19:39:48 <gmaxwell> You have a very narrow definition of portable. :)
922 2012-06-14 19:39:56 <sneak> unix, windows, osx
923 2012-06-14 19:40:30 <gmaxwell> Microcontrollers and other embedded devices? Lots of pretty powerful computers don't have enough memory to run a python interperter. :)
924 2012-06-14 19:40:40 <sneak> you'd be surprised these days
925 2012-06-14 19:41:06 <sneak> i'm in the process of building a home automation product built aroudn the beaglebone... $35 chip that has 256mb ram and full stack
926 2012-06-14 19:41:34 <sneak> it sounds insane but in the next few years "embedded" is going to mean "<=1gb ram"
927 2012-06-14 19:41:39 <gmaxwell> Yes, and the tasks you're asking it to do could be done just as well with a $5 microcontroller that uses 1/20th of the power. ::shrugs::
928 2012-06-14 19:41:47 <sneak> yes but time to market
929 2012-06-14 19:42:02 <BlueMatt> is similar
930 2012-06-14 19:42:08 <sneak> if there were 3 of me, i wouldn't care
931 2012-06-14 19:42:09 <gmaxwell> ::shrugs:: it's not particlarly hard to code for such things. E.g. if you write actually portable C.
932 2012-06-14 19:42:10 <sneak> but there's only one of me
933 2012-06-14 19:42:33 drizztbsd has quit (Remote host closed the connection)
934 2012-06-14 19:42:48 <sneak> i think it's easier to write python and stick to the stdlib and pure python extensions than to write "actually portable C"
935 2012-06-14 19:42:57 Raziel_ has joined
936 2012-06-14 19:43:02 <sneak> certainly faster
937 2012-06-14 19:43:33 <sneak> i agree with your thing up above about the human time/cpu time tradeoff, and how dynamic languages can bite you in the ass
938 2012-06-14 19:43:34 <gmaxwell> Certantly easier to start. Once you consider debugging everything perhaps not, especially if you do run into any performance issues.
939 2012-06-14 19:43:36 <sneak> it's happened to me plenty
940 2012-06-14 19:43:55 Raziel_ has quit (Client Quit)
941 2012-06-14 19:44:17 <gmaxwell> If I didn't already know python fairly well I think I would learn LUA instead, as it appears to strike a better balance in that space.
942 2012-06-14 19:44:23 Raziel_ has joined
943 2012-06-14 19:44:37 <gmaxwell> (I mean in the space of things where python is a reasonable consideration)
944 2012-06-14 19:44:46 <sneak> yeah
945 2012-06-14 19:44:52 <sneak> same, i think... but i already know python.
946 2012-06-14 19:45:06 <sneak> i like that python is also easily embeddable on osx for building native cocoa apps
947 2012-06-14 19:45:21 <sneak> do a python core, with native cocoa ui that talks to it via rpc
948 2012-06-14 19:45:33 <sneak> that's how i'm building the p2p app i'm working on now
949 2012-06-14 19:45:59 <sneak> in-process rpc using shared memory via zeromq
950 2012-06-14 19:46:04 <sturles> Or Forth. Even the simplest 8 bit AVR can run a Forth intepreter.
951 2012-06-14 19:46:45 <gmaxwell> I have a big "meh" feeling about very high level languages for network apps. It's very easy to leak language implementation details into the effective protocol specification making it very hard to write interoperable alternatives in other languages without dealing with a bunch of implicit corner cases.
952 2012-06-14 19:46:59 <gmaxwell> Bitcoin suffers this problem and it's merely written in C++.
953 2012-06-14 19:47:16 <luke-jr> well, that's because Satoshi sucks sometimes
954 2012-06-14 19:47:18 <luke-jr> -.-
955 2012-06-14 19:47:27 <gmaxwell> But e.g. details about how openssl and bdb work manage to leak out into the protocol behavior.
956 2012-06-14 19:47:30 <sneak> gmaxwell: agreed but protobuf helps.
957 2012-06-14 19:47:31 <luke-jr> srsly, you're not supposed to ever access raw memory data like that
958 2012-06-14 19:47:52 <sneak> how does bdb leak out?
959 2012-06-14 19:48:13 Motest031 has joined
960 2012-06-14 19:48:19 Motest003 has quit (Ping timeout: 248 seconds)
961 2012-06-14 19:48:31 <sneak> the on-disk stuff is the part of the bitcoin code i've looked at least
962 2012-06-14 19:49:00 <gmaxwell> sneak: for example, the issues we've had with reorgs turn BDB gotchas into effective protocol rules.
963 2012-06-14 19:49:33 <luke-jr> gmaxwell: ?
964 2012-06-14 19:49:33 <gmaxwell> e.g. an alternative implementation which didn't fail to perform reorgs with 'too many transactions' would be at risk of getting nocked onto different forks from the reference bitcoin nodes.
965 2012-06-14 19:49:42 <sneak> ahh
966 2012-06-14 19:50:00 <luke-jr> gmaxwell: I don't see that as a protocol rule, but a bitcoind bug.
967 2012-06-14 19:50:09 <sneak> yeah, i tend to think going to a higher level language would _prevent_ stuff lik that personally
968 2012-06-14 19:50:27 <sneak> luke-jr: well it's a "bitcoin network" bug, because the bitcoin network runs bitcoind mostly
969 2012-06-14 19:50:31 Ahimoth_ has joined
970 2012-06-14 19:50:32 Ahimoth_ has quit (Changing host)
971 2012-06-14 19:50:32 Ahimoth_ has joined
972 2012-06-14 19:50:35 <sneak> he's got a great point though
973 2012-06-14 19:50:36 <luke-jr> sneak: it was fixed in master
974 2012-06-14 19:50:48 <luke-jr> though I think that fix introduces new similar bugs
975 2012-06-14 19:50:53 <sneak> heh
976 2012-06-14 19:51:12 <sneak> are there public stats on client version breakdowns in the wild?
977 2012-06-14 19:51:35 <luke-jr> sneak: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
978 2012-06-14 19:52:40 <gmaxwell> luke-jr: right, I agree, but my point was that basically the use of all these complicated high level tools in the normative part of the implementation basically turns their subtle and sometimes undocumented behavior into effective rules. You can call them bugs if they're rules we didn't intend, but the program acts the same no matter what you call them.
979 2012-06-14 19:53:09 <ThomasV> question: if I restart bitcoind, my memorypool will accept only newly forwarded transactions. Will it reject all the transactions that depend on currently unconfirmed inputs? (I guess ConnectInputs should fail because the previous input is not in my mempool)
980 2012-06-14 19:53:10 <sneak> i'm really glad there are people thinking this way in the decentralized software world
981 2012-06-14 19:53:32 <sneak> these sorts of "entire network as the program state" things are really cool
982 2012-06-14 19:53:44 <sneak> i've been building distributed systems for the last few years and it's a fun challenge
983 2012-06-14 19:54:12 Ahimoth has quit (Ping timeout: 248 seconds)
984 2012-06-14 19:54:12 Ahimoth_ is now known as Ahimoth
985 2012-06-14 19:54:22 davout has joined
986 2012-06-14 19:54:22 davout has quit (Changing host)
987 2012-06-14 19:54:22 davout has joined
988 2012-06-14 19:57:35 minimoose has quit (Quit: minimoose)
989 2012-06-14 20:02:23 Joric has joined
990 2012-06-14 20:02:23 Joric has quit (Changing host)
991 2012-06-14 20:02:23 Joric has joined
992 2012-06-14 20:02:38 <jgarzik> ThomasV: it will consider the latter orphan transactions, and store those in a special, separate pool
993 2012-06-14 20:03:07 <jgarzik> ThomasV: TX must validate in all ways except actually being connect-able
994 2012-06-14 20:03:35 <ThomasV> jgarzik: I see. I was not sure how a newly started bitcoind could catch up with satoshidice :)
995 2012-06-14 20:10:47 <jgarzik> ThomasV: a newly started bitcoind only catches up to the latest block, not unconfirmed transactions
996 2012-06-14 20:11:18 <ThomasV> huh?
997 2012-06-14 20:11:18 <jgarzik> ThomasV: unconfirmed transactions are considered volatile, and must be retransmitted until they make it into a block
998 2012-06-14 20:11:28 <ThomasV> yes I got that
999 2012-06-14 20:12:41 <jgarzik> ThomasV: a newly started bitcoin does not -request- unconfirmed transactions from remote nodes. it starts receiving TX solicitations immediately, but never requests the TX queue of any remote node.
1000 2012-06-14 20:13:28 <ThomasV> jgarzik: yes, I know. that's why I was wondering why a freshly started bitcoind accepts satoshidice txes at all
1001 2012-06-14 20:13:35 <Joric> is anyone good at licenses? for now i guess MIT prohibits using author's name in ads, BSD endorses it? sounds right..ish?
1002 2012-06-14 20:14:05 <jgarzik> ThomasV: it accepts them as orphan tx's if they cannot be connected. it accepts them as normal tx's if they can be connected.
1003 2012-06-14 20:14:29 <ThomasV> yes.I wasnt aware of that separate pool
1004 2012-06-14 20:17:03 <jgarzik> with all the satoshidice TX's, we have been seeing half-full blocks frequently
1005 2012-06-14 20:17:27 <jgarzik> one wonders how quickly we'll approach 1MB
1006 2012-06-14 20:17:58 <wizkid057> at this rate it probably wont be long
1007 2012-06-14 20:22:37 <gmaxwell> Hm? it'll be infinite.
1008 2012-06-14 20:22:45 <gmaxwell> by default nodes soft limit to half.
1009 2012-06-14 20:22:55 <gmaxwell> And I don't see any miners lifting the soft limit for _this_.
1010 2012-06-14 20:24:10 <gmaxwell> (if they want to go modify the code, better to modify it to just strongly deprioritize or drop the dice txn) and leave the softcap alone.
1011 2012-06-14 20:27:36 <BlueMatt> or is it (finally) time to limit relaying of addresses that have very high volume?
1012 2012-06-14 20:28:01 <gmaxwell> I liked the idea you had about checking the memory pool.
1013 2012-06-14 20:28:41 <gmaxwell> Essentially creating a per address rate limit. Would address these specific trouble areas while encouraging generally good behavior.
1014 2012-06-14 20:28:59 <BlueMatt> been discussing it pretty much all day on bitcointalk: https://bitcointalk.org/index.php?topic=87444.0;all
1015 2012-06-14 20:29:06 <gavinandresen> meh. So they'll create 1,000 1dice addresses and rotate them....
1016 2012-06-14 20:29:20 <gavinandresen> transaction fees are the answer
1017 2012-06-14 20:29:36 <BlueMatt> gavinandresen: yea, but that means they have to put in more effort, and if you're gonna do that, might as well just do multisend
1018 2012-06-14 20:29:41 <gmaxwell> gavinandresen: The argument for not having accounts to combine transactions is that using the addresses is easier.
1019 2012-06-14 20:29:44 <BlueMatt> fixes the underlying issue and gets around the limit
1020 2012-06-14 20:29:59 <jgarzik> BlueMatt: have you directly contacted satoshidice people and asked them to use multisend?
1021 2012-06-14 20:30:03 <gmaxwell> If there are addresses you have to rotate between you might as well not be using 1txn per gamble.
1022 2012-06-14 20:30:04 <Eliel> gavinandresen: if they have to create more addresses, that would curtail the problem because it'll reduce the userfriendlyness.
1023 2012-06-14 20:30:08 <BlueMatt> jgarzik: they commented in that thread
1024 2012-06-14 20:30:14 <luke-jr> jgarzik: not sure multisend helps here <.<
1025 2012-06-14 20:30:17 <BlueMatt> also: discourages green addresses, which also generate too many txes
1026 2012-06-14 20:30:30 <BlueMatt> luke-jr: ofc it does, less txindex.dat volume, which is the biggest issue
1027 2012-06-14 20:30:36 <luke-jr> hmm
1028 2012-06-14 20:31:19 <BlueMatt> (or: allows green addresses to accept a longer confirmation time, which is acceptable for green addresses)
1029 2012-06-14 20:31:33 <gmaxwell> Basically there are a swath of behaviors which are both high in chain bloat and bad for user privacy which involve constantly reusing the same addresses. These activities themselves also don't tend to need fast confirmations, so depriortizing them makes sense.
1030 2012-06-14 20:31:39 <BlueMatt> also: encourages people to use rotating addresses, which is good for user privacy
1031 2012-06-14 20:32:02 <luke-jr> one time someone asked me to use green addresses so they could accept Eligius payouts at 0 confirmationsâ¦
1032 2012-06-14 20:32:13 <gmaxwell> 0_o
1033 2012-06-14 20:32:34 <gavinandresen> I say let users pick their priority via transaction fees. Fix the client so it looks at blocks to figure what a 'reasonable' fee/kb is, and fix the block creation code so it sorts by fee/kb
1034 2012-06-14 20:32:40 <luke-jr> yeah⦠I was like "you don't *really* want to do thatâ¦"
1035 2012-06-14 20:33:07 * jgarzik hopes satoshidice does not crowd out "regular tx", fee paying or not
1036 2012-06-14 20:33:11 <luke-jr> gavinandresen: I have a pullreq for that, a few weeks old now..
1037 2012-06-14 20:33:12 <gmaxwell> gavinandresen: but what happens when you want less than the zero fee priority?
1038 2012-06-14 20:33:18 <BlueMatt> jgarzik: they already are
1039 2012-06-14 20:33:45 <gavinandresen> luke-jr: which pullreq? You wrote code for the client that looks at previous blocks and figures out a reasonable fee/kb ?
1040 2012-06-14 20:33:45 <BlueMatt> gavinandresen: sadly, the impacts of satoshidice are largely on end-users not miners nor satoshidice, as miners get paid anywa
1041 2012-06-14 20:33:54 <luke-jr> gavinandresen: oh, that side, no
1042 2012-06-14 20:33:59 <BlueMatt> the idea is to give end-users a tiny bit of impact on the txes that get confirmed
1043 2012-06-14 20:34:02 <luke-jr> gavinandresen: mine just pays attention to fees when prioritizing
1044 2012-06-14 20:34:05 <gavinandresen> luke-jr: we need both sides of the equation
1045 2012-06-14 20:34:07 <gmaxwell> gavinandresen: because e.g. you're a spamming gambling site that bloats the chain like crazy just so you can use unconfirmed txns... since you don't need confirmations at all you really want less than zero-fee priority (to make up for your bloat)
1046 2012-06-14 20:34:17 PK has joined
1047 2012-06-14 20:34:29 <gmaxwell> jgarzik: it _does_ crowd them out currently.
1048 2012-06-14 20:34:30 <luke-jr> gavinandresen: you can't guess appropriate fees by looking at blocks, though
1049 2012-06-14 20:35:01 <gavinandresen> luke-jr: yeah, yeah, special arrangements with miners will throw things off....
1050 2012-06-14 20:35:03 <luke-jr> https://github.com/bitcoin/bitcoin/pull/1240 is the miner side
1051 2012-06-14 20:35:11 <gmaxwell> people are already all twichy about fees because they feel they can't predict them. Making them depend on blocks will make that worse.
1052 2012-06-14 20:35:25 <gavinandresen> ... but it'd still be better than the fixed, dumb fee rules we have now.
1053 2012-06-14 20:35:52 <luke-jr> gavinandresen: seems like a LOT of coding, for something that needs to be fixed still
1054 2012-06-14 20:35:59 <BlueMatt> gavinandresen: yep, but thats a separate discussion from green-address-relay-discouraging
1055 2012-06-14 20:36:00 <gmaxwell> one reason that people don't set non-zero default fees is because they're per-KB.. so setting 0.01 means you'll pay anywhere from 0.01 to 1 BTC in fees depending on the inputs selected.
1056 2012-06-14 20:36:12 <gavinandresen> We've got a limited resource (space in blocks), the only rational way to allocate it is to create a market.
1057 2012-06-14 20:36:24 * luke-jr thinks the Send screen should let you set a fixed fee
1058 2012-06-14 20:37:24 chrisb__ has joined
1059 2012-06-14 20:37:32 <gmaxwell> gavinandresen: I'm fine with the create a market. But I think that the market should be setup so that the basline behavior allows service worse than zero fee.
1060 2012-06-14 20:37:34 <BlueMatt> gavinandresen: creating a market and letting sites like satoshidice pay their way into every block crowds out a /ton/ of current users
1061 2012-06-14 20:37:44 <BlueMatt> gavinandresen: whereas satoshidice doesnt care if its txes get confirmed fast or not
1062 2012-06-14 20:38:22 Zarutian has quit (Quit: Zarutian)
1063 2012-06-14 20:38:27 <gavinandresen> BlueMatt: if satoshidice doesn't care how fast they get confirmed then they'll set low fees. The default behavior of the client should be to attache a fee high enough to crowd them out.
1064 2012-06-14 20:38:34 Nicksasa has quit (Ping timeout: 244 seconds)
1065 2012-06-14 20:39:02 Diapolo has joined
1066 2012-06-14 20:39:13 <BlueMatt> then you crowd out a ton of existing users who use bitcoin because it is 0 fee and they still get their txes confirmed in some amount of time
1067 2012-06-14 20:39:30 <gmaxwell> well, then we need to do something about the per KB-ness.. because having a 100x dynamic range on the fees you pay isn't acceptable if the minimum amount is non-trivial.
1068 2012-06-14 20:39:36 <BlueMatt> whereas as satoshidice, or really most green address users, will accept a few extra blocks confirmation time
1069 2012-06-14 20:39:46 <BlueMatt> gmaxwell: yes
1070 2012-06-14 20:40:23 <gavinandresen> Why do we need to so something about the per-KB-ness? Getting tiny payouts from a mining pool is bad for the network and should be discouraged....
1071 2012-06-14 20:40:26 <BlueMatt> but as a customer paying for my lunch, I dont wanna have to wait a week to confirm
1072 2012-06-14 20:40:41 <gmaxwell> Right. We have users who we could expect to voluntarily identify as wanting lower priority to leave room for lower fees for normal users. Why ignore that information?
1073 2012-06-14 20:40:52 <gavinandresen> Paying for lunch is a totally separate problem/issue.
1074 2012-06-14 20:41:20 <BlueMatt> gavinandresen: but its exactly the type of transaction that will be crowded out if we start making everyone pay big fees
1075 2012-06-14 20:41:38 <gmaxwell> gavinandresen: Because people are disinterested in setting 0.01/KB due to anxiety about potentially paying a $6 txn fee for a few dollar value transaction.
1076 2012-06-14 20:42:37 <gavinandresen> I'm NOT suggesting that people set the fee, I'm suggesting the client should be smart and suggest "if you want this to confirm quickly, X." "If you don't care, Y" ... for fees
1077 2012-06-14 20:43:21 <luke-jr> gmaxwell: I have a pullreq that sets an upper limit on txn fees attached
1078 2012-06-14 20:43:32 <gmaxwell> Yea, great. So they're going to send 0.5 BTC and get told 'If you want this to confirm quickly pay .8 BTC in fees', and then they say no and get a two week confirmation.
1079 2012-06-14 20:43:45 <gavinandresen> Looking at the fees paid by transactions in the last 50 blocks should get a pretty good idea of what X and Y should be.
1080 2012-06-14 20:44:21 <Diapolo> Are you discussing a QoS-style thing here?
1081 2012-06-14 20:44:30 <gavinandresen> gmaxwell: and the alternative is.....
1082 2012-06-14 20:44:48 <luke-jr> (did anyone lart Diapolo for earlier yet?)
1083 2012-06-14 20:44:49 <ciscoftw> reminds me of this; http://research.microsoft.com/pubs/156072/bitcoin.pdf
1084 2012-06-14 20:45:01 <gmaxwell> gavinandresen: fix the base behavior so that X is more like 0.01 BTC instead of 1 BTC.
1085 2012-06-14 20:45:09 <BlueMatt> ciscoftw: btw, that paper is wrong
1086 2012-06-14 20:45:10 <gavinandresen> back in a few minutes...
1087 2012-06-14 20:45:22 <gmaxwell> ciscoftw: that is so entirely unrelated I have no clue why you're linking to it.
1088 2012-06-14 20:45:26 <Diapolo> luke-jr: What is lart?
1089 2012-06-14 20:45:51 <ciscoftw> regarding fee's
1090 2012-06-14 20:46:06 <luke-jr> Diapolo: Luser Attitude Readjustment Tool :p
1091 2012-06-14 20:46:14 <luke-jr> Diapolo: you broke test_bitcoin ;)
1092 2012-06-14 20:46:36 <BlueMatt> gavinandresen: I think that is absolutely the way fees are gonna end up going, so I have no problem with doing that kind of thing now...but, as gmaxwell puts it, "We have users who we could expect to voluntarily identify as wanting lower priority to leave room for lower fees for normal users. Why ignore that information?"
1093 2012-06-14 20:47:15 <Diapolo> luke-jr: Because no one tried out the pull with Gitian I guess ;)?
1094 2012-06-14 20:47:15 davout has quit (Remote host closed the connection)
1095 2012-06-14 20:47:18 <luke-jr> BlueMatt: why would miners act on it, if it means they lose out on more fees?
1096 2012-06-14 20:47:28 <luke-jr> Diapolo: gitian has nothing to do with it
1097 2012-06-14 20:47:36 <BlueMatt> luke-jr: they wont, thats why end-users and relayers have to act on it
1098 2012-06-14 20:47:37 <gmaxwell> We even have a good metric that they're sending already already: address reuse.
1099 2012-06-14 20:47:49 <luke-jr> BlueMatt: then the original user can simply not broadcast it immediatley
1100 2012-06-14 20:48:02 <Diapolo> luke-jr: Whatever, on my setup that test is not compiled so I couldn't see that error.
1101 2012-06-14 20:48:04 <BlueMatt> luke-jr: ok, and that will get the same result...
1102 2012-06-14 20:48:09 <gmaxwell> luke-jr: do you really care about losing out on a few bitcents? if it means making bitcoin more usable for regular txn?
1103 2012-06-14 20:48:51 <luke-jr> gmaxwell: I don't think the answer is delaying the fee-payers, but encouraging the cheapskates to include fees
1104 2012-06-14 20:49:17 <gmaxwell> luke-jr: 0.0005 BTC is hardly a fee.
1105 2012-06-14 20:49:31 <luke-jr> gmaxwell: then other people should have no problem paying 0.001 BTC
1106 2012-06-14 20:49:31 <Diapolo> I somehow dislike the idea of pay more to get a faster TX ... reminds me of a net neutrality debate somehow.
1107 2012-06-14 20:49:42 <gmaxwell> Diapolo: it's pretty fundimental to the system.
1108 2012-06-14 20:49:52 <jgarzik> BlueMatt has a fair point, IMO. It is analagous to voluntarily-provided IP ToS/DSCP hints
1109 2012-06-14 20:50:40 <luke-jr> IMO, the transaction fee is the analogy to IP ToS/DSCP hints
1110 2012-06-14 20:51:00 <BlueMatt> oh, this discussion sparked another good pruning thing we could do to txindex -> dont write txes that are being fully spent later in the same block to txinex
1111 2012-06-14 20:51:16 <luke-jr> BlueMatt: that would probably help
1112 2012-06-14 20:51:17 <gmaxwell> The neat thing is that the things which don't need confirmations are also the things creating a lot of excessive txn (because the security processes they use create more txn), and they're also easily identifyable by their address reuse.
1113 2012-06-14 20:51:53 <Diapolo> To get a clue, what is the current goal in terms of the fees?
1114 2012-06-14 20:52:05 <Diapolo> or let's say long term goal
1115 2012-06-14 20:52:09 <luke-jr> Diapolo: the purpose of fees in Bitcoin, is to subsidize the miners' costs
1116 2012-06-14 20:52:12 Joric_ has joined
1117 2012-06-14 20:52:13 Joric_ has quit (Changing host)
1118 2012-06-14 20:52:13 Joric_ has joined
1119 2012-06-14 20:52:34 <ciscoftw> bitminter
1120 2012-06-14 20:52:58 <luke-jr> as things stand right now, I expect a lot of GPU miners are going to disappear in the fall
1121 2012-06-14 20:53:33 <Nolybab> hello...been lurking for a while, just returned to my keyboard
1122 2012-06-14 20:53:44 Joric has quit (Ping timeout: 245 seconds)
1123 2012-06-14 20:53:45 <Diapolo> Yes, but what is that how much thing going on with the fees? Is there a fear the network will suffer when we reach 25BTC per block?
1124 2012-06-14 20:53:59 <wizkid057> luke-jr: if this happened pretty quickly, wouldnt that cause some issues as far as greatly delaying blocks for a while?
1125 2012-06-14 20:54:01 <luke-jr> Diapolo: that's one side of the equation
1126 2012-06-14 20:54:13 <luke-jr> wizkid057: yes
1127 2012-06-14 20:54:21 <luke-jr> until the difficulty catches up
1128 2012-06-14 20:54:47 <wizkid057> perhaps a solution to this should be something along the lines of the difficulty adjusting more quickly for the first month after a block reward change
1129 2012-06-14 20:55:07 <luke-jr> wizkid057: that'd make hardforks
1130 2012-06-14 20:55:11 <Diapolo> btw. are there any testnet3 nodes up, it takes ages for testnet blocks to mature for me ...
1131 2012-06-14 20:55:20 <gmaxwell> wizkid057: I don't really think there is an issue there.
1132 2012-06-14 20:55:26 <wizkid057> luke-jr: people have like, 5 months to upgrade....
1133 2012-06-14 20:55:33 <Diapolo> currently I even don't get a connection to a node
1134 2012-06-14 20:55:38 <luke-jr> wizkid057: and there's still people using 0.3
1135 2012-06-14 20:55:43 <Nolybab> is the link ciscoftw posted familiar to everyone (newbie here, obviously)
1136 2012-06-14 20:55:53 <gmaxwell> Diapolo: sure, but not much mining. I only mine after 20 minutes have passed.
1137 2012-06-14 20:56:30 <luke-jr> wizkid057: and we have much more important reasons to hardfork, but opted not to thus far
1138 2012-06-14 20:56:44 * wizkid057 shrugs
1139 2012-06-14 20:56:49 <gmaxwell> wizkid057: you're presuming irrational behavior in any case. There is no reason to expect a pointwise discontinuity in hashrate.
1140 2012-06-14 20:57:07 <wizkid057> there's pleanty of reason...
1141 2012-06-14 20:57:16 <gmaxwell> wizkid057: if mining becomes unprofitable for you you should be getting rid of your gear _before_ the change to get ahead of the flooded market.
1142 2012-06-14 20:57:42 <wizkid057> mining is always profitable for me, but, thats not the norm
1143 2012-06-14 20:58:03 <gmaxwell> I didn't mean you you, I meant the platonic you.
1144 2012-06-14 20:58:30 <wizkid057> you also assume that most miners even realize that this date is approaching
1145 2012-06-14 20:58:32 <luke-jr> gmaxwell: only if you expect to profit from resale
1146 2012-06-14 20:58:36 Prattler has quit (Quit: Ex-Chat)
1147 2012-06-14 20:59:12 <jgarzik> luke-jr: transaction fee is different. consider real-world shipping: rates and classes of service are separate, though clearly related. you might pay same rate, but select a different class of freight service (slower, yet more reliable).
1148 2012-06-14 20:59:38 <luke-jr> jgarzik: I don't think Bitcoin has "slower, yet more reliable" service :P
1149 2012-06-14 20:59:44 <gmaxwell> It could.
1150 2012-06-14 20:59:46 <luke-jr> speed and reliability are the same thing
1151 2012-06-14 20:59:50 <luke-jr> gmaxwell: how?
1152 2012-06-14 20:59:54 <jgarzik> irrelevant to overall analogy
1153 2012-06-14 21:00:10 <gmaxwell> For example, one reason to have low priority txn would be to keep them around for replacement in order to save fees.
1154 2012-06-14 21:00:29 <luke-jr> â¦
1155 2012-06-14 21:00:48 <gmaxwell> e.g. I send you 1 BTC low priority, but before its mined, I find I need to send you more.. so I replace it with a 2 BTC payment and make just one txn instead of two.
1156 2012-06-14 21:00:51 <luke-jr> why would a miner hold off mining a transaction just so you could remove the fee?
1157 2012-06-14 21:01:03 <gmaxwell> and since you trusted my unconfirmed txns this didn't delay anything.
1158 2012-06-14 21:01:22 <luke-jr> hmm
1159 2012-06-14 21:01:28 <gmaxwell> not remove the fee, but use less blockspace kilobytes.
1160 2012-06-14 21:01:35 <luke-jr> I suppose
1161 2012-06-14 21:01:56 <gmaxwell> gavinandresen: also wrt tiny inputs, since we're getting closer to pruning we ought to have a priority fee metric that rewards people for reducing the number of open txn in the blockchain.
1162 2012-06-14 21:02:48 egecko has joined
1163 2012-06-14 21:03:52 <gmaxwell> e.g. using the net change in pruned blockchain size plus some constant as the fee metric instead of the size of the transaction.
1164 2012-06-14 21:05:32 <wizkid057> can we prune satoshidice from existance?
1165 2012-06-14 21:05:41 <BlueMatt> has anyone spent more time acking https://github.com/bitcoin/bitcoin/pull/1405 ?
1166 2012-06-14 21:05:59 <gmaxwell> wizkid057: I already suggested the tool for that.
1167 2012-06-14 21:06:20 <wizkid057> gmaxwell: did i miss it?
1168 2012-06-14 21:06:36 <gmaxwell> wizkid057: No, you didn't. I suggested using a prediction market.
1169 2012-06-14 21:06:47 <wizkid057> oh, lol
1170 2012-06-14 21:06:56 MobiusL has quit (Remote host closed the connection)
1171 2012-06-14 21:07:18 Prattler has joined
1172 2012-06-14 21:09:54 <[Tycho]> Can anyone tell me if deprioritizing 1dice is good or bad ?
1173 2012-06-14 21:10:15 <BlueMatt> [Tycho]: thats what we're discussing
1174 2012-06-14 21:10:26 <BlueMatt> actually, more broadly, deprioritizing high-use addresses
1175 2012-06-14 21:10:30 <BlueMatt> including deepbit
1176 2012-06-14 21:10:48 <BlueMatt> [Tycho]: I think the consensus is generally good
1177 2012-06-14 21:11:08 <gmaxwell> I don't know that anyone thinks depriortizing it is _bad_... maybe just pointless.
1178 2012-06-14 21:11:36 <BlueMatt> as long as they're using 1dice its not ;)
1179 2012-06-14 21:12:15 sacredchao has quit (Ping timeout: 276 seconds)
1180 2012-06-14 21:12:25 <gmaxwell> well maybe.. I mean, the volume of txn still exists and will need to go in sometime.
1181 2012-06-14 21:12:27 <luke-jr> [Tycho]: the rationale seems to be that using the same address means green addresses means you can wait longer for confirmations because they're accepted at 0conf anyway
1182 2012-06-14 21:12:56 <luke-jr> I think more important is getting the people complaining to pay fees ;)
1183 2012-06-14 21:13:00 <BlueMatt> gmaxwell: well it could still encourage multisend
1184 2012-06-14 21:13:02 sacredchao has joined
1185 2012-06-14 21:13:04 <jgarzik> [Tycho]: IMO it is mainly a question of whether or not satoshidice are harming "regular users"
1186 2012-06-14 21:13:15 <jgarzik> [Tycho]: is satoshidice increasing confirmation times for everyone else?
1187 2012-06-14 21:13:17 <jgarzik> if so...
1188 2012-06-14 21:13:32 <BlueMatt> yes
1189 2012-06-14 21:13:36 <BlueMatt> they are
1190 2012-06-14 21:13:38 mxmxmx has left ()
1191 2012-06-14 21:13:41 <gmaxwell> I don't think the existance of harm is in question, only the magnitude. People are showing up confused and angry about long confirmation times. But perhaps it's only a few people.
1192 2012-06-14 21:13:52 mxmxmx has joined
1193 2012-06-14 21:14:20 <luke-jr> gmaxwell: so those people should be told to pay 0.001 BTC fees
1194 2012-06-14 21:14:28 <luke-jr> and do what we can to make it easier
1195 2012-06-14 21:14:32 <Diapolo> So to nail it down is to decrease priority for things that could be considered background-noise in the network :D.
1196 2012-06-14 21:14:37 <luke-jr> so, allowing adding fees after the fact, for example
1197 2012-06-14 21:15:13 <luke-jr> oh, there's another ideaâ¦
1198 2012-06-14 21:15:19 <luke-jr> instead of trying to guess fees up front
1199 2012-06-14 21:15:26 <gmaxwell> luke-jr: people spaz out and get angry about 0.0005 up front.
1200 2012-06-14 21:15:30 <[Tycho]> Yes, they are.
1201 2012-06-14 21:15:31 <luke-jr> just track priorities in the client
1202 2012-06-14 21:15:36 <luke-jr> and add fees as blocks ignore your txn
1203 2012-06-14 21:15:41 <gmaxwell> luke-jr: auto fee bidding would be a big incentive to intentionally delay txn in order to cause them to bid up.
1204 2012-06-14 21:15:47 <[Tycho]> That's why I'm now messing with priority things.
1205 2012-06-14 21:16:14 <BlueMatt> [Tycho]: while you're at it, multisend would be nice ;)
1206 2012-06-14 21:16:28 <luke-jr> gmaxwell: is that a problem?
1207 2012-06-14 21:16:32 <luke-jr> gmaxwell: people would still be setting maximum bids
1208 2012-06-14 21:16:40 <[Tycho]> No, that's completely different part.
1209 2012-06-14 21:16:43 <luke-jr> and they can't delay them *forever*
1210 2012-06-14 21:16:52 <BlueMatt> yes they can
1211 2012-06-14 21:17:01 <luke-jr> BlueMatt: not if they ever want a fee
1212 2012-06-14 21:17:18 <luke-jr> every block MinerA delays accepting TxnA, is a block MinerB might take it
1213 2012-06-14 21:17:30 <luke-jr> so as long as we have a competitive mining marketâ¦
1214 2012-06-14 21:17:40 <luke-jr> it's either "take it or leave it" pretty much
1215 2012-06-14 21:17:40 <BlueMatt> oh, you are saying >0 fees
1216 2012-06-14 21:18:01 <gmaxwell> luke-jr: Perhaps.
1217 2012-06-14 21:18:31 <luke-jr> BlueMatt: yeah, 0 fee txns might get left waiting always
1218 2012-06-14 21:18:35 <luke-jr> but IMO that's ok
1219 2012-06-14 21:18:42 <luke-jr> charity cases can wait :P
1220 2012-06-14 21:18:45 <BlueMatt> luke-jr: its not imo
1221 2012-06-14 21:19:06 <luke-jr> I don't mean they wait forever
1222 2012-06-14 21:19:10 <BlueMatt> we shouldnt design a system that results in encouraging 0-fee txes never being acepted
1223 2012-06-14 21:19:14 <luke-jr> but at some point, it will be obvious they're not being bid up
1224 2012-06-14 21:19:18 <BlueMatt> but they likely will
1225 2012-06-14 21:19:19 <luke-jr> and some nice miner will confirm them
1226 2012-06-14 21:19:35 <luke-jr> BlueMatt: likely they will be accepted *eventually*
1227 2012-06-14 21:19:42 <BlueMatt> ok, but the incentives are that they wont
1228 2012-06-14 21:19:59 <luke-jr> only in the same sense that they are now
1229 2012-06-14 21:20:05 <luke-jr> there is no reason for miners to accept them now either
1230 2012-06-14 21:20:08 Xunie has quit (Remote host closed the connection)
1231 2012-06-14 21:20:19 <BlueMatt> ok, but it increases incentives in your system
1232 2012-06-14 21:20:24 <luke-jr> no
1233 2012-06-14 21:20:28 <gmaxwell> It does, but meh.
1234 2012-06-14 21:20:40 <luke-jr> gmaxwell: it increases the incentive to *never* confirm 0fees?
1235 2012-06-14 21:20:46 Diapolo has left ()
1236 2012-06-14 21:20:46 <BlueMatt> yes, because its possible that you will eventually get a fee
1237 2012-06-14 21:20:50 <gmaxwell> Why accept it? it may be more later... and if someone else accepts it.. so what?
1238 2012-06-14 21:20:57 <luke-jr> BlueMatt: that's an unavoidable reality.
1239 2012-06-14 21:21:06 <luke-jr> gmaxwell: OK, so why accept it now?
1240 2012-06-14 21:21:08 Xunie has joined
1241 2012-06-14 21:21:11 <gmaxwell> it makes it more likely. Though I dunno if I care.
1242 2012-06-14 21:21:36 <gmaxwell> luke-jr: because it likely won't ever be increased now, so not accepting just makes bitcoin suck. (unless it's a DOS attack, in which case.. great!)
1243 2012-06-14 21:21:41 <BlueMatt> luke-jr: shifting the option to add fees to tx receiver I like
1244 2012-06-14 21:21:55 <BlueMatt> letting the user add more later I dont
1245 2012-06-14 21:22:10 <gmaxwell> I think like all complicated issues the solution to this is "all of the above"
1246 2012-06-14 21:22:22 <luke-jr> gmaxwell: but we *need* the ability to increase fees IMO
1247 2012-06-14 21:22:32 <luke-jr> gmaxwell: at the very least, it's far more important than leeches who don't pay them
1248 2012-06-14 21:22:35 <gmaxwell> Yes, there should be fee replacements, yes there should be fee recommendations, yes there should be deprioritization of obvious low prio transactions.
1249 2012-06-14 21:22:52 <BlueMatt> luke-jr: Im sorry you are a miner and consider 0fee txes leeches, I consider them important bitcoin sers
1250 2012-06-14 21:22:55 <BlueMatt> users
1251 2012-06-14 21:23:17 <jgarzik> 0-fee users are very important to bitcoin's adoption right now
1252 2012-06-14 21:23:47 <gmaxwell> meh, everyone is a leech now. The way I look at it future bitcoin users are subsidizing our chain bloat in order to foster the adoption of bitcoin which will allow them to exist in the future. But I'm weird.
1253 2012-06-14 21:23:49 <BlueMatt> and I think they will continue to be as long as bitcoin is growing
1254 2012-06-14 21:23:55 cardpuncher_ has joined
1255 2012-06-14 21:23:59 <luke-jr> they're important, but not so important that they can't wait
1256 2012-06-14 21:24:09 <BlueMatt> disagree entirely
1257 2012-06-14 21:24:13 MobiusL has joined
1258 2012-06-14 21:24:19 TD has quit (Quit: TD)
1259 2012-06-14 21:24:21 <gmaxwell> (I say everyone is a leech because a 0.0005 btc fee is nothing currently.. its a fraction of a cent.. you lose more to rounding up on taxes in typical transactions with cash)
1260 2012-06-14 21:24:50 <luke-jr> gmaxwell: sure, to an extent, everyone is leeching off the subsidy right now
1261 2012-06-14 21:25:04 <gmaxwell> luke-jr: people have weird mental interactions with fees. If you only have a few btc then a 0.0005 btc feeâ a fraction of a centâ for some reason makes a lot of people obsess and become unhappy.
1262 2012-06-14 21:25:11 t7 has quit (Ping timeout: 244 seconds)
1263 2012-06-14 21:25:30 <gmaxwell> bitcoin has to be more attractive as a system for people to get over that, but nothing will create that attraction except time and adoption.
1264 2012-06-14 21:25:32 <ThomasV> gmaxwell: it's because there is the mental overhead of having to think about it
1265 2012-06-14 21:25:34 <luke-jr> gmaxwell: I think part of that is they don't have the choice to wait
1266 2012-06-14 21:25:36 <BlueMatt> and as long as we are as small as we are, thats an important problem imho
1267 2012-06-14 21:26:09 <BlueMatt> 0fee txes should be useable for as long as we can make them
1268 2012-06-14 21:26:09 cardpuncher_ has left ()
1269 2012-06-14 21:26:17 <gmaxwell> ThomasV: I've found that pointing out to people that the default mandatory fees can never go over 0.05 BTC with the current software really helps some people relax, which supports that theory.
1270 2012-06-14 21:26:38 <luke-jr> BlueMatt: txn_prio allows 0fee txes to be mined when the recipient adds a fee ;)
1271 2012-06-14 21:26:43 <someone42> what about allocating a fixed portion (eg. 10%) of maximum block size for 0 fee tx?
1272 2012-06-14 21:27:05 <jgarzik> there is already a free tx area, of a sort
1273 2012-06-14 21:27:07 <BlueMatt> luke-jr: which is a good feature for the future, but isnt related to my statement
1274 2012-06-14 21:27:21 <BlueMatt> someone42: only way to do that, really, is a hardfork
1275 2012-06-14 21:27:25 <gmaxwell> BlueMatt: I agree, but at the same time we must not compromise what makes the system valuable. E.g. a conspiracy of miners to totally block 1dice txn would enable zero fees but would call the value of bitcoin itself into question.
1276 2012-06-14 21:27:37 <Nolybab> bingo gmaxwell
1277 2012-06-14 21:27:43 dvide has quit ()
1278 2012-06-14 21:27:45 <someone42> jgarzik: oh, cool
1279 2012-06-14 21:27:45 <BlueMatt> gmaxwell: agreed
1280 2012-06-14 21:27:59 <BlueMatt> gmaxwell: but deprioritizing 1dice so that we can have 0fee txes work doesnt
1281 2012-06-14 21:28:02 <ThomasV> 1dice increased miners revenue
1282 2012-06-14 21:28:15 <gmaxwell> someone42: so if I'm a miner that doesn't want zero fee txn in my blocks I'll just fill that 10% with txn to myself.
1283 2012-06-14 21:28:19 <gmaxwell> ThomasV: only very slightly.
1284 2012-06-14 21:28:55 <luke-jr> gmaxwell: I think his point wasn't to require that 10%, but only let you use free txns to fill the block to max
1285 2012-06-14 21:28:57 <gmaxwell> ThomasV: not even enough to pay for the disk space the chain growth takes up.
1286 2012-06-14 21:29:12 <luke-jr> gmaxwell: so you can only get to 90% capacity with fees
1287 2012-06-14 21:29:17 <ThomasV> gmaxwell: only because of the block reward.
1288 2012-06-14 21:29:17 <jgarzik> if we could get it down to just a few bytes, encoding fee policy metadata in coinbase would be interesting
1289 2012-06-14 21:29:34 <jgarzik> (not a new idea, I grant)
1290 2012-06-14 21:29:35 <luke-jr> someone42: also note that in the future, we don't need/want to appease 0fee txns at all ;)
1291 2012-06-14 21:29:58 <luke-jr> jgarzik: the latest idea for that is an alert-like broadcast system, so they can be updated
1292 2012-06-14 21:30:01 <gmaxwell> jgarzik: no need to do that.. Just use the coinbases public key to signmessage fee statements... then nodes don't have to carry that data around 1000 years from now. :)
1293 2012-06-14 21:30:06 <ThomasV> when we drop to 25btc/block, todays fees will represent 1% of their revenue
1294 2012-06-14 21:30:06 <luke-jr> jgarzik: so we include a pubkey hash in the coinbase
1295 2012-06-14 21:30:45 <ThomasV> 1dice is a great thing IMO
1296 2012-06-14 21:30:54 <ThomasV> it's a stress test for btc
1297 2012-06-14 21:31:11 <jgarzik> I don't think there needs to be an alert-like system. We can calculate by looking at last N blocks, plus some OOB metadata
1298 2012-06-14 21:31:31 <jgarzik> calculate sufficient to make good recommendations about fees
1299 2012-06-14 21:31:54 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
1300 2012-06-14 21:32:14 <gmaxwell> ThomasV: er. it could just as easily be done on testnet or a closed system. We're not actually learning anything from it.
1301 2012-06-14 21:32:17 Raziel_ has quit (Quit: Leaving)
1302 2012-06-14 21:32:31 <BlueMatt> ThomasV: I think you're falling into the logical fallacy gmaxwell pointed out is rampant when criticizing wikipedia: because you see a mistake and correct it, you cant complain that wikipedia is broken: you are part of the system
1303 2012-06-14 21:32:45 <luke-jr> jgarzik: no, you can't, because past fees don't tell you anything about what fees *you* need to pay
1304 2012-06-14 21:32:46 Joric_ is now known as Joric
1305 2012-06-14 21:33:04 <gmaxwell> the _only_ thing about that site is the number of complete idiots who are using bots to play it at high speed. Automating a net negative expectancy game is something I never expected!
1306 2012-06-14 21:33:05 <BlueMatt> part of the system isnt to accept problems that are caused by 1dice, its to fix them
1307 2012-06-14 21:33:11 <jgarzik> luke-jr: sure they do, especially combined with metadata from various sites
1308 2012-06-14 21:33:56 <luke-jr> jgarzik: so when 75% of transactions have bulk fees prepaid privately, and the other 25% start getting stuck because they don't pay a fee?
1309 2012-06-14 21:33:57 RainbowDashh has joined
1310 2012-06-14 21:34:14 Ummon has joined
1311 2012-06-14 21:34:16 <ThomasV> gmaxwell: they have fun from it. that's why negative expectancy games exist
1312 2012-06-14 21:34:28 <gmaxwell> ThomasV: but !! automated!
1313 2012-06-14 21:34:49 <jgarzik> gmaxwell: hehe
1314 2012-06-14 21:35:10 <ThomasV> yeah. I think that we will have to live in a world where the block limit is reached, and transaction compete through fees
1315 2012-06-14 21:35:15 <gmaxwell> I thought I understood slot machines with the lever pulling and the blinking lights... Oh well.
1316 2012-06-14 21:35:23 <jgarzik> luke-jr: you want informed self-tuning system. history and OOB metadata both play a role, but are not the complete picture individually.
1317 2012-06-14 21:35:52 <jgarzik> gmaxwell: it's perfect for Americans... literally instant gratification
1318 2012-06-14 21:36:05 <gmaxwell> ThomasV: So here is the point I've made about this before: That world is viable when it's also a world where bitcoin is firmly established and widely used. The economic utility of widely used bitcoin will justify dealing with the fees.
1319 2012-06-14 21:36:27 <gmaxwell> ThomasV: If we reach that state _before_ the value of bitcoin is well established, then it will discourage people from adopting it.
1320 2012-06-14 21:36:51 <gmaxwell> ThomasV: so we should do what we can as a community to forstall that point in time in order to increase the system's chances of success.
1321 2012-06-14 21:37:29 <ThomasV> gmaxwell: the negaative expectancy of 1dice is just another fee in the game. ant that fee does not discourage people from playing. so I don't see why the miner fee would discourage more rational players
1322 2012-06-14 21:37:50 <luke-jr> looks like I can release bitcoind 0.5.6 for OSX
1323 2012-06-14 21:37:54 <gmaxwell> ThomasV: Prior to dice I wasn't so worried about reaching this situation too early because there was some proportionality... more txns meant more users meant more value in the system.
1324 2012-06-14 21:37:58 <luke-jr> gmaxwell: did you ever get gitian working?
1325 2012-06-14 21:38:13 <gmaxwell> ThomasV: because that traffic makes bitcoin suck for users who don't want to gamble too.
1326 2012-06-14 21:38:34 <gmaxwell> ThomasV: it makes it take longer to install a full node and it makes transactions confirm slowly for everyone.
1327 2012-06-14 21:39:05 eoss has joined
1328 2012-06-14 21:39:07 <gmaxwell> And the dice users don't even care much about the slow confirmations since their system works with zero confirms (made possible only due to the bloaty behavior)
1329 2012-06-14 21:39:20 <gmaxwell> luke-jr: no. :( though I didn't make a third pass at it yet.
1330 2012-06-14 21:39:37 <ThomasV> gmaxwell: why don't you stop worrying and learn to love the Dice!
1331 2012-06-14 21:39:38 <gmaxwell> (third pass = installing newer ubuntu on the host vm)
1332 2012-06-14 21:39:52 <gmaxwell> ThomasV: because I'd like bitcoin to survive.
1333 2012-06-14 21:39:52 <luke-jr> gmaxwell: what if we tell Dice they have two choices 1) we throw together some hacks to deprioritize and/or filter their stuff; or 2) they pay a developer to implement more Dice-friendly ways of scaling with their load
1334 2012-06-14 21:40:02 <ThomasV> it will :)
1335 2012-06-14 21:40:12 <gmaxwell> ThomasV: only because people will worry.
1336 2012-06-14 21:40:17 <gmaxwell> And I'm part of that system.
1337 2012-06-14 21:40:48 <BlueMatt> ThomasV: same logical fallacy
1338 2012-06-14 21:41:15 <gmaxwell> luke-jr: I do not like that.
1339 2012-06-14 21:41:54 <gmaxwell> It goes back to what I said before about not compromising the things that make bitcoin valuable. Giving users, even abusive ones, ultimatums is good fud material.
1340 2012-06-14 21:42:09 PK has quit ()
1341 2012-06-14 21:42:18 <gmaxwell> About the only thing I think would justify that is an overpowering ASIC attacker.
1342 2012-06-14 21:44:25 <Diablo-D3> DMC DMC DMC DMC
1343 2012-06-14 21:44:34 <BlueMatt> /kick Diablo-D3
1344 2012-06-14 21:44:48 <Diablo-D3> :<
1345 2012-06-14 21:44:54 <BlueMatt> how's that going, btw?
1346 2012-06-14 21:44:58 <Diablo-D3> very well
1347 2012-06-14 21:45:46 t7 has joined
1348 2012-06-14 21:46:47 TD has joined
1349 2012-06-14 21:47:11 <BlueMatt> TD: we've been discussing future fee structures, if you're interested
1350 2012-06-14 21:47:53 <TD> ok
1351 2012-06-14 21:48:02 <TD> i'm heading to bed soon
1352 2012-06-14 21:48:38 wizkid057 has quit (Quit: bbiaf)
1353 2012-06-14 21:48:38 <luke-jr> gmaxwell: well, depends how it's worded
1354 2012-06-14 21:50:39 <BlueMatt> luke-jr: see the thread: https://bitcointalk.org/index.php?topic=87444.0
1355 2012-06-14 21:51:00 agricocb has quit (Quit: Leaving.)
1356 2012-06-14 21:51:02 <BlueMatt> its a similar concept
1357 2012-06-14 21:52:27 <luke-jr> SgtSpike = Dice?
1358 2012-06-14 21:53:22 <BlueMatt> no, fireduck
1359 2012-06-14 21:54:29 <Nolybab> yeah, then just wait till someone puts dice in facebook, linking wallets to facebook accounts then dice goes viral...maybe just in time for the fall halving.
1360 2012-06-14 21:54:33 lukys has left ()
1361 2012-06-14 21:54:51 <ThomasV> lol
1362 2012-06-14 21:55:09 <ThomasV> but that would go against fb's tos
1363 2012-06-14 21:55:16 <Nolybab> not necessarily
1364 2012-06-14 21:55:23 <BlueMatt> hence why we look at rate-limiting forwarding txes from/to the same address now
1365 2012-06-14 21:55:34 <Nolybab> technically, even by law, bitcoin is not a 'currency', at lest it's still being debated
1366 2012-06-14 21:55:41 <Nolybab> it's like the zynga relationship with facebook
1367 2012-06-14 21:55:45 <Nolybab> or paypal with ebay
1368 2012-06-14 21:55:54 <Nolybab> looks parasitic, but really symbiotic
1369 2012-06-14 21:56:03 <Nolybab> the key is to understand the symbiosis
1370 2012-06-14 21:56:10 <Nolybab> cause-->effect
1371 2012-06-14 21:58:01 <ThomasV> 1dice transactions are not spam. they are paying fees.
1372 2012-06-14 21:58:14 <BlueMatt> yes. they. are.
1373 2012-06-14 21:58:35 <BlueMatt> they pay fees to miners, but they are spam to everyone
1374 2012-06-14 21:58:45 <ThomasV> to everyone?
1375 2012-06-14 21:58:46 tower has quit (Ping timeout: 244 seconds)
1376 2012-06-14 21:58:57 <BlueMatt> everyone who runs a client that stores the chain
1377 2012-06-14 21:59:20 <luke-jr> BlueMatt: alternate solution to subsidy crash?
1378 2012-06-14 21:59:24 <ThomasV> oh but you don't need to store the chain to play dice :)
1379 2012-06-14 21:59:40 <BlueMatt> ThomasV: I dont care about dice users
1380 2012-06-14 21:59:55 <luke-jr> ThomasV: you mean to be a victim of dice
1381 2012-06-14 22:00:20 <Nolybab> not spam...noise...because they also increase the computation requirements to statistically analyze the network, especially when you introduce many, many 'quasi-centralized' server-side hubs that transmit into the network...maybe dice actually does a 'service' to the network from that perspective
1382 2012-06-14 22:00:24 mologie has quit (Ping timeout: 245 seconds)
1383 2012-06-14 22:00:26 tower has joined
1384 2012-06-14 22:01:20 <BlueMatt> luke-jr: the dice fees wont help anyone when the subsidy decreases. And I never said we shouldnt have transactions which pay fees, but we should do that in a way that is a result of real growth in bitcoin, not the result of one site
1385 2012-06-14 22:01:27 <ThomasV> if you create a currency system with almost free transactions, noise has to be expected
1386 2012-06-14 22:01:28 <Nolybab> actually scratch that part bout the centralization...can just filter that out
1387 2012-06-14 22:01:35 <BlueMatt> because one site doesnt help anyone and just makes people who want to pay 0fee mad
1388 2012-06-14 22:01:36 <Nolybab> well, we want noise
1389 2012-06-14 22:01:48 <BlueMatt> Nolybab: I call that spam
1390 2012-06-14 22:01:58 <Nolybab> who am i to say 'we'...just a newbie here
1391 2012-06-14 22:02:34 <Nolybab> here's a question
1392 2012-06-14 22:02:44 <luke-jr> BlueMatt: would Amazon.com not be real growth?
1393 2012-06-14 22:03:06 <Nolybab> nvm
1394 2012-06-14 22:03:10 <Nolybab> i'll save it...more research
1395 2012-06-14 22:03:13 <ThomasV> BlueMatt: you call it spam. fine. that's your point of view. now bitcoin is an open system, it does not belong to you. other people do not call it spam.
1396 2012-06-14 22:03:18 <BlueMatt> luke-jr: amazon would encourage people to pay one tx/order, not one tx per item
1397 2012-06-14 22:03:31 <BlueMatt> ThomasV: I never said it was spam
1398 2012-06-14 22:03:34 <BlueMatt> I said I call that spam
1399 2012-06-14 22:03:46 <ThomasV> <BlueMatt> yes. they. are.
1400 2012-06-14 22:04:21 <weex> satoshidice isn't going away. i think this is the test and imagine satoshi at 100x this tx rate
1401 2012-06-14 22:04:21 <BlueMatt> that was in response to you claiming they arent spam /because/ thy pay fees
1402 2012-06-14 22:04:26 <BlueMatt> which is unrelated to the issue at hand
1403 2012-06-14 22:04:40 copumpkin has quit (Quit: Computer has gone to sleep.)
1404 2012-06-14 22:04:43 <BlueMatt> weex: no one wants them to go away
1405 2012-06-14 22:04:46 <ThomasV> what is the issue at hand?
1406 2012-06-14 22:05:04 <BlueMatt> weex: this is atest, and we are failing, so we should change incentive structures so that this kind of failure isnt possible in the future
1407 2012-06-14 22:05:24 <BlueMatt> ThomasV: the drastic increase in load on full nodes for no reason
1408 2012-06-14 22:05:33 <BlueMatt> s/no reason/no reason other than the laziness of individuals/
1409 2012-06-14 22:06:01 <weex> as a user, i might want to be warned that if i pay less than x it might delay my transaction being confirmed... is how to do that the issue at hand?
1410 2012-06-14 22:06:43 <BlueMatt> weex: that is one thing that I think eveeryone agrees should be done
1411 2012-06-14 22:07:03 <ThomasV> I think we should let the free market take care of this issue
1412 2012-06-14 22:07:22 <BlueMatt> ok, lets let bitcoin die
1413 2012-06-14 22:07:30 <BlueMatt> or let bitcoin continue to fail
1414 2012-06-14 22:07:45 <Nolybab> bluematt: what's the one thing everyone agrees should be done?
1415 2012-06-14 22:08:24 <BlueMatt> Nolybab: when processing a new transaction that will need a fee to go in a block quickly, alert the user to the issue and let them opt to pay 0 fee and wait a (potentially long) time to confirm
1416 2012-06-14 22:08:26 <ThomasV> Nolybab: not increasing the block size :)
1417 2012-06-14 22:09:40 <weex> increasing block size creates a fork?
1418 2012-06-14 22:09:53 <TD> we've always known large numbers of transactions would force a transition to thin clients
1419 2012-06-14 22:09:59 <BlueMatt> ThomasV: the issue is: bitcoin has adoption partially because of its low fee structure and (moderately) fast confirmation times. Throwing that all out the window in the interest of the free market seems...broken
1420 2012-06-14 22:10:15 <BlueMatt> TD: but an overnight transition to such may cause issues...
1421 2012-06-14 22:10:20 <ThomasV> 0.01 is still low
1422 2012-06-14 22:10:29 <Nolybab> very fast, very convenient, basically 'free'
1423 2012-06-14 22:10:33 <BlueMatt> TD: and forcing the transition because of one site seems...
1424 2012-06-14 22:10:33 <TD> better now than later. right now there aren't many bitcoin users and those which do exist, are tolerant of bumps in the road
1425 2012-06-14 22:10:52 <TD> if in future bitcoin has huge numbers of users, upgrading the infrastructure could be much harder
1426 2012-06-14 22:11:05 <BlueMatt> ThomasV: encouraging satoshidice will result in fees a whole lot higher than 0.01...
1427 2012-06-14 22:11:14 <ThomasV> BlueMatt: no
1428 2012-06-14 22:11:32 <ThomasV> players will no longer play if fees are higher
1429 2012-06-14 22:11:53 <ThomasV> only more 'legitimate' uses will remain
1430 2012-06-14 22:12:14 <ThomasV> well, players will still play, but not at high frequency
1431 2012-06-14 22:12:19 <BlueMatt> TD: (partially) agreed, but thats not the only issue, forcing regular users to have to use fees when we have useful information on sites that really dont need fast confirmations and ignoring that seems wrong
1432 2012-06-14 22:12:48 <weex> have any mining pools de-prioritized satoshi txns?
1433 2012-06-14 22:12:50 <TD> the current use of fees to control system load is not a long term sustainable solution. if the software scaled better it would be unnecessary
1434 2012-06-14 22:12:59 <TD> ditto for the fixed block limit
1435 2012-06-14 22:13:14 <BlueMatt> ThomasV: and yet by that point you've thrown a bunch of people who are using bitcoin for more sane purposes. Keep in mind that people playing satoshidice arent being logical to begin with, applying logic to their actions probably wont work very well
1436 2012-06-14 22:13:35 <ThomasV> lol
1437 2012-06-14 22:13:36 <Nolybab> and farmville is logical? :)
1438 2012-06-14 22:13:53 <ThomasV> I apply logic to their wallet, not to their actions
1439 2012-06-14 22:13:53 <Nolybab> mainstream != logical
1440 2012-06-14 22:14:16 <TD> there are two reasonable solutions: implement SPV mode in bitcoin-qt, or encourage users to migrate to SPV reimplementations like MultiBit (or both)
1441 2012-06-14 22:14:28 Apexseals has quit ()
1442 2012-06-14 22:14:29 <ThomasV> TD: "scaled better"? care to explain?
1443 2012-06-14 22:14:30 <Nolybab> what is SPV implemenation?
1444 2012-06-14 22:14:35 <BlueMatt> TD: ack, but I dont see that changing very quickly, whereas bitcoin is a production network, trying to switch to a largely-spv-based model with no option for things like p2pool quickly doesnt seem smart to me
1445 2012-06-14 22:14:35 <TD> bitcoin-qt would need to start in SPV mode and make the transition to full when possible
1446 2012-06-14 22:14:45 <TD> it's complicated, but bitocin already is complicated :)
1447 2012-06-14 22:15:00 <Nolybab> understood...i'll see what i can research
1448 2012-06-14 22:15:03 <TD> BlueMatt: p2pool users would just run full nodes. it's still easily possible, even with satoshidice
1449 2012-06-14 22:15:14 <TD> Nolybab: read satoshis paper. spv == simplified payment verification
1450 2012-06-14 22:15:30 <Nolybab> i read the paper, just didn't make the connection with the acronym, thx
1451 2012-06-14 22:15:37 <BlueMatt> TD: last night my node was seeing around 30% cpu just processing satoshidice txes, that kind of growth doesnt work
1452 2012-06-14 22:15:55 <BlueMatt> TD: and thats on a tmpfs, so its pretty much just cpu checking sigs
1453 2012-06-14 22:16:10 <TD> if you were a miner you'd be seeing 100% load on your gpu anyway. so we migrate to a world where miners need to be using dedicated machines
1454 2012-06-14 22:16:14 <TD> as they probably already do
1455 2012-06-14 22:16:37 _Fireball has quit (Quit: HydraIRC -> http://www.hydrairc.com <- IRC with a difference)
1456 2012-06-14 22:16:49 <Nolybab> need to turn BitCoin in the 'switzerland' of cybercash
1457 2012-06-14 22:16:55 <TD> scalability has been one of the key question marks people have raised over bitcoin as a technology. even satoshi himself wasn't sure it could work.
1458 2012-06-14 22:17:04 <BlueMatt> my point is we start to move to needing more than a moderate dedicated machine to run bitcoind
1459 2012-06-14 22:17:06 <TD> so for the project to succeed these doubts must be proven wrong
1460 2012-06-14 22:17:32 <TD> yes. i think that was always on the cards, if things go well. the long term goal would be for bitcoin to be at least competitive with paypal, right?
1461 2012-06-14 22:17:38 <TD> if not visa/mc and eventually ..... everything
1462 2012-06-14 22:17:56 <Prattler> there is a huge difference: scalability when the whole world is using it and scalability to benefit a small group of people while everyone's paying for it
1463 2012-06-14 22:18:17 <BlueMatt> and a slow transition to that can allow for that, imho, but a drastic one at the hands of one or two sites doesnt seem sane
1464 2012-06-14 22:18:20 <TD> apparently not so small, unless you believe somebody is automating satoshidice despite staistical guarantee of loss?
1465 2012-06-14 22:18:25 <BlueMatt> especially if its so easy to work around
1466 2012-06-14 22:18:33 <BlueMatt> TD: people are, there are bots
1467 2012-06-14 22:18:37 <TD> work arounds will undermine confidence in obsevers
1468 2012-06-14 22:18:45 <TD> BlueMatt: that problem will probably solve itself when they run out of money :)
1469 2012-06-14 22:18:55 rdponticelli has quit (Ping timeout: 244 seconds)
1470 2012-06-14 22:19:06 <ThomasV> what TD said :)
1471 2012-06-14 22:19:12 <TD> i think the solution probably looks like this:
1472 2012-06-14 22:19:47 <TD> - start to implement more scalability fixes in bitcoind, like chain pruning, SPV mode and transitions to full nodes
1473 2012-06-14 22:19:51 <BlueMatt> ok, less of a work around, more of a prioritization to utilize information we already have
1474 2012-06-14 22:20:12 <BlueMatt> TD: I did block index pruning (not the blocks themselves, just the index)
1475 2012-06-14 22:20:32 <TD> - continue to develop bitcoinj, so users have something they can run in the meantime, it may not be as fully featured as bitcoin-qt or as good for the network, but it's nearly "ready"
1476 2012-06-14 22:20:34 <TD> BlueMatt: that's cool
1477 2012-06-14 22:20:42 <Prattler> increase min fee to 0.005 and we're good short term, but legit new comers should still get free transactions somehow...
1478 2012-06-14 22:20:49 <BlueMatt> people are moving to spv clients, and thats great
1479 2012-06-14 22:20:51 <TD> - encourage people to consider running full nodes as a way to contribute to the network
1480 2012-06-14 22:21:06 <BlueMatt> we do, but thats rapidly becoming infeasible
1481 2012-06-14 22:21:08 <TD> right now it's not at all obvious that bringing up nodes is helpful. nothing on the website, forums or wiki suggests that
1482 2012-06-14 22:21:24 <someone42> there's also no incentive to run a full node
1483 2012-06-14 22:21:36 <BlueMatt> someone42: better trust model
1484 2012-06-14 22:21:42 <someone42> tx fees go to miners
1485 2012-06-14 22:21:45 <TD> there's no incentive for people to write patches to bitcoin either, yet people do.
1486 2012-06-14 22:22:07 <gmaxwell> someone42: tx fees are hardly an incentive.
1487 2012-06-14 22:22:19 <TD> someone42: miners have to have a full node running somewhere along the line
1488 2012-06-14 22:22:19 <BlueMatt> TD: in any case, in order to continue growing, I strongly believe the ability to have 0fee txes and low-fee txes confirm rapidly is very important
1489 2012-06-14 22:22:25 <BlueMatt> sites like sd break that
1490 2012-06-14 22:22:39 <TD> BlueMatt: sure, i fully agree, but high transaction volumes only cause issues because we deliberately throttled the system
1491 2012-06-14 22:22:47 <TD> (well, satoshi did)
1492 2012-06-14 22:22:50 <TD> to give time to make it scale better
1493 2012-06-14 22:22:53 <gmaxwell> Thats not so.
1494 2012-06-14 22:23:01 <gmaxwell> You can move around the problems but not make them go away.
1495 2012-06-14 22:23:05 <TD> if it was not satoshidice, it would be general growth in usage, or some other site that seems less frivolous
1496 2012-06-14 22:23:21 <gmaxwell> Without the throttle we'd instead have the problem that the chain is growing by gigabytes per day and we'd rapidly lose decentralization.
1497 2012-06-14 22:23:26 <gavinandresen> We need to embrace transaction volume
1498 2012-06-14 22:23:43 <BlueMatt> in the end, rate-limiting forwarding high-use address txes doesnt really slow them down, but it can keep total load on network down (lower txindex usage by encouraging multisend) but it does help bitcoin keep growing
1499 2012-06-14 22:23:49 <ThomasV> gavinandresen: +1
1500 2012-06-14 22:23:50 <Nolybab> who was it posted this link: http://research.microsoft.com/pubs/156072/bitcoin.pdf
1501 2012-06-14 22:23:55 <gmaxwell> TD: General usage, unlike dice, would come with an increased overall utility of Bitcoin. (more people/places accepting it)
1502 2012-06-14 22:23:57 <Prattler> We need to embrace transaction volume that pays for itself and leave some for newbies to test out the system.
1503 2012-06-14 22:23:57 <TD> decentralization != enthusiasts running full nodes on their laptop, no more than the web is centralized because popular websites happen to be very resource intensive to run
1504 2012-06-14 22:24:00 <gavinandresen> ... and if that means you can't run a full node on your home DSL and 500gb hard disk, so be it
1505 2012-06-14 22:24:08 <Prattler> ATM satoshidice is not paying for itself
1506 2012-06-14 22:24:25 <TD> it isn't? SD pays fees even when it doesn't need to
1507 2012-06-14 22:24:27 <gmaxwell> so the added costs would be justified by bitcoin being more rewarding to participate in. This growth has little to no reward connected to it.
1508 2012-06-14 22:24:36 <TD> mostly due to my code not supporting paying the minimum they need to :)
1509 2012-06-14 22:24:52 <gmaxwell> TD: the fees don't even pay for the diskspace used on miners. They're basically irrelevant.
1510 2012-06-14 22:24:55 copumpkin has joined
1511 2012-06-14 22:25:13 <TD> disk space is trivially cheap. i doubt it will ever be a bottleneck.
1512 2012-06-14 22:25:30 <BlueMatt> it is...
1513 2012-06-14 22:25:32 <gavinandresen> CPU was the bottleneck last time we did the back-of-the-envelope calculations
1514 2012-06-14 22:25:33 <gmaxwell> I didn't say it was, I'm just saying that the fees they're paying are not worth calling non-zero.
1515 2012-06-14 22:25:37 <BlueMatt> disk speed atleast
1516 2012-06-14 22:25:49 * TD shrugs
1517 2012-06-14 22:26:11 <TD> there'll always be usages we don't approve of. i'm personally ok with SD, but wouldn't be OK with people stuffing arbitrary files into txouts or trying to use the block chain as a DNS system
1518 2012-06-14 22:26:12 <Diablo-D3> I want to make a band named year zero
1519 2012-06-14 22:26:15 <BlueMatt> why should we not attempt to prioritize more legitimate and fair uses of the system over things like sd?
1520 2012-06-14 22:26:24 <Diablo-D3> so I can release an album named year zero
1521 2012-06-14 22:26:31 <Diablo-D3> with a track titled year zero on it
1522 2012-06-14 22:26:32 <TD> theymos was always in favor of the DNS idea. such debates are inevitable. scalability makes them irrelevant though
1523 2012-06-14 22:26:39 <gavinandresen> because "we" won't be able to agree what is legitimate
1524 2012-06-14 22:26:41 <gmaxwell> the base fee isn't intended to support the network, it's intended to stop "while true; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.01; done" which it does...
1525 2012-06-14 22:26:45 <Diablo-D3> just so I can make an mp3 that has year = 0 in the mp3 tags
1526 2012-06-14 22:26:58 <TD> right. gavin speaks a lot of sense.
1527 2012-06-14 22:27:21 <Diablo-D3> gmaxwell: yes but
1528 2012-06-14 22:27:24 <Diablo-D3> what if Im a dick
1529 2012-06-14 22:27:32 <gmaxwell> BlueMatt: legitimate isn't the right criteria. Bleh, you do your own argument a disservice.
1530 2012-06-14 22:27:33 <Diablo-D3> and tell DMC's bitcoind to do all tx even feeless
1531 2012-06-14 22:27:44 <gavinandresen> I think the only really hard question is whether or not the block size should be fixed forever at 1MB.
1532 2012-06-14 22:28:04 <TD> i've always seen it as a temporary limit, albeit one that'll be a PITA to change, as it's a hard fork
1533 2012-06-14 22:28:07 <BlueMatt> agreed, and its sane that we try to scale and accept the huge volume they provide, but that doesnt mean we shouldnt try to discourage people from over-using what they need
1534 2012-06-14 22:28:15 <Diablo-D3> gavinandresen: that should change actually
1535 2012-06-14 22:28:18 <gmaxwell> I don't think there is any legitimicy question. The green address / zero-confirm chain usecases create a lot of TXN bloat naturally, but they are also trivially identifyable and don't have a need for fast confirmation.
1536 2012-06-14 22:28:32 <Diablo-D3> I would support a BIP that increases it to 16
1537 2012-06-14 22:28:37 <TD> there are some quick fixes / low hanging fruit
1538 2012-06-14 22:28:46 <TD> fireducks code is not using compressed pubkeys, afaik
1539 2012-06-14 22:28:58 <TD> it's on my TODO list to fix that in bitcoinj then persuade him to upgrade
1540 2012-06-14 22:29:08 <Diablo-D3> td: heh, I wanna do compressed databases on my shit
1541 2012-06-14 22:29:16 <TD> have all the duplicate sig checks been fixed after the cache work?
1542 2012-06-14 22:29:19 * Diablo-D3 is going to code a bitcoin client at some point
1543 2012-06-14 22:29:29 <Diablo-D3> just so I can see what lugh does
1544 2012-06-14 22:29:30 <TD> i seem to remember there was a lot of redundant work going on
1545 2012-06-14 22:29:31 <gavinandresen> Diablo-D3: if we change it, it should float, with default rules that let the majority of miners decide what a reasonable maximum size is.
1546 2012-06-14 22:29:39 * TD nods
1547 2012-06-14 22:29:46 t7 has quit (Ping timeout: 244 seconds)
1548 2012-06-14 22:29:51 <TD> yeah, you don't want to guarantee hard forking changes in the event of sucess
1549 2012-06-14 22:29:53 <BlueMatt> TD: yes, pretty much
1550 2012-06-14 22:29:55 <TD> well, ideally
1551 2012-06-14 22:29:56 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1552 2012-06-14 22:30:00 <Diablo-D3> gavinandresen: you mean as in reject blocks that are too big?
1553 2012-06-14 22:30:07 <gavinandresen> Diablo-D3: yes
1554 2012-06-14 22:30:18 <Diablo-D3> so what stops me from being a dick and rejecting blocks with txes in them?
1555 2012-06-14 22:30:19 <gavinandresen> ... where "too big" is up to the miners to decide.
1556 2012-06-14 22:30:52 <TD> BlueMatt: what tx rate gave you 30% resource usage, by the way?
1557 2012-06-14 22:30:52 <Diablo-D3> (saying I, say, have 10TH of power)
1558 2012-06-14 22:30:57 <TD> sounds like 1-2 per second?
1559 2012-06-14 22:31:05 <BlueMatt> TD: its roughly that
1560 2012-06-14 22:31:14 <BlueMatt> TD: more like 1/2sec
1561 2012-06-14 22:31:18 mologie has joined
1562 2012-06-14 22:31:23 <BlueMatt> (its a core2duo, admittedly, but still)
1563 2012-06-14 22:31:29 <Diablo-D3> gavinandresen: I mean, if someone gets 51%, they dont have to perform a 51% attack
1564 2012-06-14 22:31:30 <TD> 0.5 tps?
1565 2012-06-14 22:31:35 <BlueMatt> yea
1566 2012-06-14 22:31:37 <Diablo-D3> they can perform a "lets fuck transactions" attack
1567 2012-06-14 22:31:38 <Prattler> Not being able to run a mining node because bitcoin has taken over the world is ok, but not because someone is abusing the network.
1568 2012-06-14 22:31:42 <TD> so 30% of one core? doesn't sound too bad
1569 2012-06-14 22:31:47 <BlueMatt> the tx volume from sd last night was pretty ridiculous
1570 2012-06-14 22:31:52 <Diablo-D3> just by either accepting gigantic blocks, or rejecting blocks with txes
1571 2012-06-14 22:32:07 <TD> paypal is 40tps, more or less.
1572 2012-06-14 22:32:09 <Prattler> if bitcoin is small, blocks must stay small, too
1573 2012-06-14 22:32:15 <Diablo-D3> Prattler: wrong.
1574 2012-06-14 22:32:21 <Diablo-D3> block size has zero control over bitcoin success
1575 2012-06-14 22:32:25 <gmaxwell> gavinandresen: "meh". So 50% of miners decide that 1GB blocks are okay, and then push out all nodes that aren't part of their private 10gbps backbone. I mean, this would not kill bitcoin by itself but it would potentially make it kind of pointless.
1576 2012-06-14 22:32:25 <BlueMatt> Prattler: but you have to get there first, and sd (IMO) prevents us from doing so
1577 2012-06-14 22:32:38 <Diablo-D3> especially if Im a dick and just write a self optimizing database
1578 2012-06-14 22:33:03 <TD> i disagree that SD prevents us from being successful. i see it this way
1579 2012-06-14 22:33:17 <TD> anyone who cares about convenience or startup time is NOT using bitcoin today, because they will have tried it and given up already
1580 2012-06-14 22:33:20 <BlueMatt> in the current way it works, IMHO they strongly do
1581 2012-06-14 22:33:28 <BlueMatt> not because of the spv issue, because of the fee issue
1582 2012-06-14 22:33:36 <BlueMatt> and transaction delay issue
1583 2012-06-14 22:33:55 <weex> where's the best place to see info on tx delay?
1584 2012-06-14 22:34:15 <Diablo-D3> satoshis dice may actually MAKE us successful
1585 2012-06-14 22:34:16 <BlueMatt> last night, mempools hit 9000 txes
1586 2012-06-14 22:34:28 <gmaxwell> TD: the counter evidence is people showing up angry in #bitcoin asking whats wrong and why their txn are not confirming.
1587 2012-06-14 22:34:30 <BlueMatt> Diablo-D3: Id bet its total userbase is lower than you think
1588 2012-06-14 22:34:47 <Diablo-D3> bluematt: thats not directly related
1589 2012-06-14 22:34:55 <gmaxwell> Diablo-D3: most of the dice volume appears to just be bots playing.
1590 2012-06-14 22:34:56 <BlueMatt> Diablo-D3: no, but its close
1591 2012-06-14 22:35:12 <Diablo-D3> gmaxwell: so what stops everybody from increasing fees?
1592 2012-06-14 22:35:40 <Diablo-D3> we'd only need like half the pools/farms out there to increase their fee per kbs to shut SD out
1593 2012-06-14 22:36:01 enquirer has quit (Quit: back soon)
1594 2012-06-14 22:36:10 <gmaxwell> Diablo-D3: I mean, I already have. But I'm just like a tenthousanth of the hashpower. ::shrugs:: What stopped some pools from fixing their nodes for a month after BIP16 was making all their blocks get orphaned? A lot of miners are asleep at the wheel.
1595 2012-06-14 22:36:11 <BlueMatt> TD: the spv issue causes problems because we are essentially shifting overnight, but those arent really /that/ significant
1596 2012-06-14 22:36:15 <Diablo-D3> it'd slow SD down to getting their tx only on hosts that participate
1597 2012-06-14 22:36:26 <Prattler> I believe that blockchain size is one of the very important factors to bitcoin's success. At least in the current infancy.
1598 2012-06-14 22:36:29 <Diablo-D3> gmaxwell: this is true =/
1599 2012-06-14 22:36:29 erle- has quit (Ping timeout: 244 seconds)
1600 2012-06-14 22:36:36 <TD> ok, how about this
1601 2012-06-14 22:36:42 <Diablo-D3> Prattler: thats a very uninformed opinion
1602 2012-06-14 22:36:57 <gmaxwell> Prattler: thats my view. That during bitcoin's infancy every speedbump hurts.
1603 2012-06-14 22:37:07 <TD> people playing satoshidice don't really care about confirmation time, as noted. they just want the instant feedback of seeing their win or loss show up as pending. there's no particular reason those transactions have to be in the memory pool or mined by everyone
1604 2012-06-14 22:37:14 <gmaxwell> When bitcoin is more widely used its network effect will justify coping with the costs.
1605 2012-06-14 22:37:19 <Prattler> that's a personal opinion. If I explain someone the principles of bitcoin and they can't try it out now.. well.. they'll say I'm crazy, and they're right.
1606 2012-06-14 22:37:26 <gmaxwell> TD: Right.
1607 2012-06-14 22:37:30 ovidiusoft has quit (Ping timeout: 265 seconds)
1608 2012-06-14 22:37:36 <Diablo-D3> Prattler: yes, but bitcoin currently does not optimize network usage
1609 2012-06-14 22:37:55 <TD> so nothing, in theory, stops satoshidice from handing back the win or loss transactions directly back to the client. and then sending them to a co-operating mining pool to be mined in bulk
1610 2012-06-14 22:38:00 <Diablo-D3> if I cant download the chain at 1gbit/sec, then how is bitcoin so awesome
1611 2012-06-14 22:38:21 <TD> if that pool finds one block per day, and it consists only of SD transactions, it doesn't really affect the game
1612 2012-06-14 22:38:22 <BlueMatt> TD: thats partially what Im suggesting, but with less forcing sd to do it themselves
1613 2012-06-14 22:38:32 <gmaxwell> TD: this was why I was suggesting we have nodes deprioritize txn which have repeated addresses (basically the green address / dice use case where confirmation time isn't important)
1614 2012-06-14 22:38:58 <Nolybab> bluematt, what do you mean, forcing sd to do 'what' themselves?
1615 2012-06-14 22:39:11 <TD> i think in future handing transactions around outside the network will become more common, and is something to encourage anyway. so implementing it now seems more general than exploiting the consistency of the 1dice addresses
1616 2012-06-14 22:39:17 <BlueMatt> Nolybab: force them to make deals with mining pools
1617 2012-06-14 22:39:41 <BlueMatt> TD: we arent exploiting the consistency, we are allowing them to opt-into low priority
1618 2012-06-14 22:39:52 <gmaxwell> TD: well, it would be making address consistency a way to signal low priority.
1619 2012-06-14 22:39:55 <TD> i mean, having transactions get passed back and forth without being broadcast, can be used for many things.
1620 2012-06-14 22:40:00 <gmaxwell> Which is a natural match.
1621 2012-06-14 22:40:05 <BlueMatt> TD: I agree that will become more common, but I see little way to force it and I dont believe encouraging it to help
1622 2012-06-14 22:40:11 <gmaxwell> Though oob txn is good too.
1623 2012-06-14 22:40:16 <TD> low fees seem like a more direct signal :)
1624 2012-06-14 22:40:25 <gmaxwell> TD: except they can't go below zero.
1625 2012-06-14 22:40:29 <TD> BlueMatt: i don't think fireduck is an opponent, exactly
1626 2012-06-14 22:40:53 <TD> BlueMatt: he's been pretty swamped with making SD scale. btw, his experience is invaluable in learning what it takes to run a really huge/active site
1627 2012-06-14 22:41:05 <TD> his setup is pretty crazy. the wallet is built on amazon dynamo
1628 2012-06-14 22:41:08 Apexseals has joined
1629 2012-06-14 22:41:14 <TD> anyway, his code is open source too
1630 2012-06-14 22:41:27 <Diablo-D3> td: oh really?
1631 2012-06-14 22:41:29 <TD> if we make it easy for him to do this and encourage it, and it's not a serious UX hit for his players, i think he'd probably do it
1632 2012-06-14 22:41:30 <Diablo-D3> thats interesting
1633 2012-06-14 22:41:51 <BlueMatt> TD: and how do we make it easy?
1634 2012-06-14 22:41:56 <ThomasV> gavinandresen: how would the majority of miners decide on maximum block size?
1635 2012-06-14 22:41:58 <TD> i can implement some of this, though right now i'm working on (doh) proper fee support :)
1636 2012-06-14 22:42:13 <TD> BlueMatt: plumbing :/
1637 2012-06-14 22:42:31 <TD> right now the sd ui is "copy an address using the clipboard and send coins to it"
1638 2012-06-14 22:42:37 <BlueMatt> TD: still have to convince sd that its better for them, which is really kinda isnt...
1639 2012-06-14 22:42:38 chrisb__ has quit (Quit: Leaving)
1640 2012-06-14 22:42:54 <TD> it could be "click a link that instructs bitcoin-qt to POST a serialized transaction to a given endpoint and parse transactions from the response"
1641 2012-06-14 22:43:06 <gavinandresen> ThomasV: they'd reject blocks that were too big....
1642 2012-06-14 22:43:11 * gavinandresen away again
1643 2012-06-14 22:43:15 <TD> BlueMatt: *shrug* i can talk to fireduck about it. we've already discussed a few things when he contributed some patches back to me
1644 2012-06-14 22:43:21 <weex> ThomasV: couldn't you add max block size as another parameter that is calculated at the same time as difficulty?
1645 2012-06-14 22:43:53 <ThomasV> gavinandresen: I mean, how would the agree?
1646 2012-06-14 22:44:24 <TD> BlueMatt: then i guess we'd need to find a pool that was willing to accept a bumload of transactions every so often from him directly, bypassing the mempool. those transactions have to get mined sooner or later, so it doesn't reduce overall load, mind you
1647 2012-06-14 22:44:58 <BlueMatt> TD: it decreases the load of memorypools significantly, and Id say it would be much better for bitcoin
1648 2012-06-14 22:45:18 <BlueMatt> TD: but we need to make it easy for pools and clients
1649 2012-06-14 22:45:21 <BlueMatt> which is very difficult
1650 2012-06-14 22:45:27 <TD> it makes the confirmation delays occur in a spike instead of spread out over time i guess. also it may be easier for him to pay a flat rate to some miner pools
1651 2012-06-14 22:45:38 <TD> there are already pools that accept private submission of transactions
1652 2012-06-14 22:45:41 <BlueMatt> whereas letting them opt-into low-priority by using the same address is fairly easy and has similar results
1653 2012-06-14 22:46:10 <BlueMatt> really? which ones?
1654 2012-06-14 22:46:18 <BlueMatt> the mtgox-eligius deal is just tx list last I heard?
1655 2012-06-14 22:46:22 <TD> i think eligius had a deal with mtgox at one point
1656 2012-06-14 22:46:36 <TD> i thought eligius was un-sticking transactions that got sent to mtgox with the wrong fees
1657 2012-06-14 22:46:40 <BlueMatt> I thought those were relayed through network and mtgox just gave a list of what to accept, luke-jr?
1658 2012-06-14 22:46:40 <TD> they used to anyway
1659 2012-06-14 22:47:05 <TD> well, boils down to the same thing. whether you provide a list of hashes or the transactions themselves makes little difference technically
1660 2012-06-14 22:47:36 <BlueMatt> changes the delay structure back to spread out, though
1661 2012-06-14 22:47:43 <TD> anyway, it also means marking txns in the wallet as "not broadcastable" and somehow communicating that to users
1662 2012-06-14 22:47:51 <BlueMatt> which is the largest issue here imho
1663 2012-06-14 22:48:05 <TD> which isn't especially easy. but it means that, for instance, if i wanted to send money to you in a low-inflation world where miners charge fees routinely, i could do it for free
1664 2012-06-14 22:48:28 <TD> you just keep the tx from me around and trust i won't double spend it away, then pass them onwards until the value hits somebody who doesn't trust the sender and falls back on the services of miners
1665 2012-06-14 22:49:22 <BlueMatt> yep
1666 2012-06-14 22:49:44 <TD> i think "sending money for free to people who trust me" is a pretty neat selling point, if we implement it.
1667 2012-06-14 22:49:54 <BlueMatt> oob txes are interesting, but I think they are harder and takes more effort than things like limiting txes from addresses
1668 2012-06-14 22:50:30 <TD> well, sure, but that approach is less targeted and might have unintended side effects. doesn't deepbit use a single address for tons of payout transactions?
1669 2012-06-14 22:50:36 <TD> 1VayNert or something?
1670 2012-06-14 22:51:04 <TD> it feels like a less direct way to solve the issue. and the time for solving things in a solid, decentralized way ..... is now. when the attention of the world is elsewhere.
1671 2012-06-14 22:51:54 <BlueMatt> yes, deepbit does...but it doesnt care about waiting either
1672 2012-06-14 22:51:59 <BlueMatt> the point is its an opt-in
1673 2012-06-14 22:52:22 <BlueMatt> and really, pretty much every use I can think of of repeated addresses is willing to wait
1674 2012-06-14 22:52:29 <TD> it's not really opt-in if you take behavior that previously had no consequence, and suddenly assign new meaning to it.
1675 2012-06-14 22:52:37 <BlueMatt> imho, it doesnt just solve this issue, it helps others
1676 2012-06-14 22:52:59 <BlueMatt> and it is perfectly decentralized, you are letting each client do it, not just the miners
1677 2012-06-14 22:53:19 <BlueMatt> also it gives clients a tiny say in the incentive structure that they are a part of as relayers
1678 2012-06-14 22:53:46 <BlueMatt> green addresses dont care about waiting, high-volume donations can wait...
1679 2012-06-14 22:54:56 <TD> ok, what if satoshidice set fees to zero unless the size rules required it to be higher
1680 2012-06-14 22:55:21 <Joric> is there a service determining a relation between two bitcoin addresses? i'm tired of writting everything by myself
1681 2012-06-14 22:55:25 <TD> then users could attach a trivial fee and "win", given a sensible set of tx ordering rules
1682 2012-06-14 22:55:25 <BlueMatt> it would take quite a while to implement with the current upgrade-apathy out there...by the time it was in wide-spread use, it would be opt-in
1683 2012-06-14 22:56:20 Eleuthria has left ()
1684 2012-06-14 22:56:35 <TD> the current issue is that SD is always attaching a fee so always "wins" over the standard transactions made by clients, right
1685 2012-06-14 22:56:52 <TD> i mean the short term issue
1686 2012-06-14 22:57:38 <gmaxwell> Not just that, but also because users don't want to pay fees far in excess of their txn values which can easily happen now when they apply fees manually.
1687 2012-06-14 22:57:43 <BlueMatt> are you saying double-spend to always beat sd?
1688 2012-06-14 22:58:02 <TD> no
1689 2012-06-14 22:58:09 <TD> i'm saying SD should stop always setting a fee
1690 2012-06-14 22:58:46 <TD> given that they don't care about confirm times, that's a good signal, right?
1691 2012-06-14 22:58:51 <BlueMatt> that wont help people who want to pay 0-fee, which I really believe continues to be important until bitcoin is significantly bigger
1692 2012-06-14 22:58:53 <TD> the problem is, it's hard for fireduck to do that
1693 2012-06-14 22:58:58 <TD> well, you can't have it both ways
1694 2012-06-14 22:59:12 <TD> you want to deprioritize the transactions of somebody who is willing (currently) to pay for priority, over people who aren't
1695 2012-06-14 22:59:19 <TD> even though the fee needed, if SD was fixed, would be trivial
1696 2012-06-14 22:59:24 <sipa> wow, long discussion here it seems
1697 2012-06-14 22:59:29 <sipa> what did i miss?
1698 2012-06-14 22:59:48 <BlueMatt> sipa: idea is this: rate-limit relaying of txes using a given address
1699 2012-06-14 22:59:56 <TD> either the scalability limits must be raised, or people who care about confirm speed must pay for the limited resources, but right now you're just working backwards from "i don't like sd" to a policy that is targeted at them specifically
1700 2012-06-14 23:00:25 <gmaxwell> TD: that is provably not an accurate description of my position at least.
1701 2012-06-14 23:00:39 <gmaxwell> Because I suggested the repeated address deprio long before SD existed.
1702 2012-06-14 23:00:47 <BlueMatt> TD: not my position either
1703 2012-06-14 23:01:06 <gmaxwell> Moreover, I don't think anyone here dislikes SD except purely due to the volume. There are a lot of gambling sites, I'm indifferent to them.
1704 2012-06-14 23:01:28 <BlueMatt> TD: last I heard, you said sd pays fees because they may otherwise have unforwardable txes and cant check?
1705 2012-06-14 23:01:32 <TD> yes
1706 2012-06-14 23:01:49 <TD> it's something i'm working on fixing atm. they'd probably use the same fee policy as bitcoin-qt otherwise.
1707 2012-06-14 23:02:32 <TD> if a node can see the full contents of the mempool, it should be possible to advise the user what kind of fee would result in what kind of confirm time, right? if you guess that most miners use the default policies
1708 2012-06-14 23:03:16 <sipa> at least eligius and deepbit use custom policies already
1709 2012-06-14 23:03:22 <BlueMatt> TD: I purposely dont want to touch fee rules with this, I still think the min-fee stuff is important and dont think it plays a real role in the decision here, aside from prioritization /after/ the single-address stuff is considered
1710 2012-06-14 23:03:42 <Prattler> TD, transactions cost $0.05 or whatever for the network as a whole. We are just willing to subsidise it to real users, because there is additional adoption gain. There is very little value in subsidising SD bots. So it makes sense to allow free transactions AND at the same time limit SD.
1711 2012-06-14 23:04:37 <TD> see what i mean? you're assuming that SD traffic is "bad" and not "real users" whereas traffic from bitcoin-qt is "good" because it's "real users"
1712 2012-06-14 23:05:03 <gavinandresen> Prattler: see https://bitcointalk.org/index.php?topic=3332.0 for back-of-the-envelope what does a transaction cost
1713 2012-06-14 23:05:07 <TD> is there even any reason for SD to use single addresses beyond vanity?
1714 2012-06-14 23:05:08 ThomasV has quit (Ping timeout: 248 seconds)
1715 2012-06-14 23:05:14 <BlueMatt> sipa: essentially: let people opt-into lower-than-0-fee priority by using the same address over and over. When you think about who uses the same address repeatedly, IMHO it makes a lot of sense
1716 2012-06-14 23:05:18 <TD> it could easily have been implemented, afaict, with addresses that change on every page load
1717 2012-06-14 23:05:24 <BlueMatt> TD: not true
1718 2012-06-14 23:05:33 <Prattler> SD traffic is bad because it doesn't pay enough fees, or at least doesn't distribute the fees well. Traffic from bitcoin-qt is "good" because it's "real users".
1719 2012-06-14 23:05:40 <BlueMatt> sd traffic isnt bad or not-real, its traffic that doesnt care about confirmation delays
1720 2012-06-14 23:05:50 <gmaxwell> TD: if it did then it might as well have accounts, and if it did that it wouldn't be a big source of additional transactions.
1721 2012-06-14 23:05:51 <TD> Prattler: you're making no sense. SD traffic wins over "real user" (ugh) traffic, because it DOES pay fees, always
1722 2012-06-14 23:05:56 <TD> even when it doesn't need to
1723 2012-06-14 23:06:35 <BlueMatt> TD: yea, they could, but that encourages them to put in a bit more effort, and then they might as well just do multisend or accounts
1724 2012-06-14 23:06:48 <gmaxwell> The criteria isn't "real users" it's that its simply generating a transaction load disproportional with the userbase relative to all other popular uses of bitcoin.
1725 2012-06-14 23:06:57 <Prattler> ok, if you're a drug dealer, and it costs you $100 dollars to buy, will you sell for $50 or give a new victim for free? I would give a newbie for free. It is better for the system!
1726 2012-06-14 23:07:08 * Prattler nods at gmaxwell.
1727 2012-06-14 23:09:10 <TD> people will come up with things that generate non-trade transactions in future too
1728 2012-06-14 23:09:34 <TD> one thing i've thought about, for instance, is having android wallets merge/split outputs at night in order to try and avoid fees
1729 2012-06-14 23:09:48 <gmaxwell> And the load is disproportional because of their method of safely not needing confirmations and because of the 'accountless' UI method. These are abstract elements of their behavior that aren't specific to any party.
1730 2012-06-14 23:10:04 <TD> are you going to decide this is bad because those transactions don't represent "real" users and find hacks to deprioritize them? we need to look for general solutions
1731 2012-06-14 23:10:12 <gmaxwell> TD: it's pretty easy to do that as a side effect of existing transactions.
1732 2012-06-14 23:10:37 <gmaxwell> e.g. when you make a transaction take additional inputs and/or produce additional change outputs for that purpose.
1733 2012-06-14 23:10:59 <gmaxwell> TD: and those txn being deprioritized would be the right thing in any case, they aren't time critical.
1734 2012-06-14 23:12:01 <BlueMatt> TD: again, no these transactions arent "bad" because they arent "real" users, a ton of them are. The goal is to discourage actions that generate significantly more load than is required for the same result
1735 2012-06-14 23:12:01 <TD> unless i wake up and decide i want to buy something just after a defrag tx. the people who care about delays are the receivers not the senders.
1736 2012-06-14 23:12:05 <nanotube> how about a central repository of biometric user ids, and each user id gets a monthly quota of free transactions? </duck>
1737 2012-06-14 23:12:33 <TD> if fees were calculated recursively then senders would never have to care about their transactions getting "stuck" in a queue
1738 2012-06-14 23:12:36 <BlueMatt> wait, I think nanotube's got it, lets do that one
1739 2012-06-14 23:12:48 <TD> a receiver who decided he didn't want to wait for a transaction to confirm would re-spend it to themselves with a larger fee
1740 2012-06-14 23:12:50 <gmaxwell> TD: well we should have smarter logic such that a high prior txn which depends on a low prio one gets considered as a group.
1741 2012-06-14 23:12:55 <TD> senders would never attach fees. this was discussed before.
1742 2012-06-14 23:13:02 <TD> yeah
1743 2012-06-14 23:13:10 <sipa> gmaxwell: luke implemented that already
1744 2012-06-14 23:13:21 <gmaxwell> I know.
1745 2012-06-14 23:13:34 <TD> i think that's a pretty fundamental improvement actually because it changes how people see confirmations. for senders it's now "fire and forget". receivers can choose confirm time based on their own risk analysis
1746 2012-06-14 23:14:01 MiningBuddy has quit (Remote host closed the connection)
1747 2012-06-14 23:14:09 spq has quit (Read error: Connection reset by peer)
1748 2012-06-14 23:14:11 <gmaxwell> Payment protocol is much better though.. since it doesn't require a two step transaction.
1749 2012-06-14 23:14:13 MiningBuddy has joined
1750 2012-06-14 23:14:24 * sipa thinks transactions shouldn't be submitted to the network by the senders, but by the receiver
1751 2012-06-14 23:14:34 spq has joined
1752 2012-06-14 23:14:42 <gmaxwell> And it also makes sure all the transmitted values are right, makes sure the reciever knows how to do refunds and knows who was paying them, allows the addresses to be fresh, etc.
1753 2012-06-14 23:14:50 <BlueMatt> TD: agreed, but why cant we have sites select that their transactions dont need any priority, and let users who want to use 0 fees get confirms quickly without making the receiver do the work?
1754 2012-06-14 23:15:17 <BlueMatt> s/the work/extra cost/
1755 2012-06-14 23:16:08 <TD> people can select that their transactions are unimportant already using fees. that's pretty much the purpose of fees, once you take out the anti DoS code. zero fees is an illusory selling point, we all know one day inflation will disappear and somehow mining will still need to get funded.
1756 2012-06-14 23:16:11 <BlueMatt> even if we dont do it with given addresses, what about optional per-tx ToS?
1757 2012-06-14 23:16:29 <BlueMatt> TD: absolutely, but, for now, its a strong selling point
1758 2012-06-14 23:16:45 maaku has quit (Quit: maaku)
1759 2012-06-14 23:16:48 <TD> if receivers pay fees, for most users who just want to buy socks, it will be much like credit cards ..... there will still be fees, but they'll be paid by the merchants and just included into the cost
1760 2012-06-14 23:16:50 <BlueMatt> even if it will disappear, its still a strong selling point while we have it
1761 2012-06-14 23:16:55 <TD> so psychologically it will remain the same
1762 2012-06-14 23:16:58 <gmaxwell> td: people can select that their transactions are unimportant already using fees < they can't indicate that they are less important than zero fee that way.. no way to distinguish between multiple zero fee txn.
1763 2012-06-14 23:17:13 jurov is now known as jurov|away
1764 2012-06-14 23:17:40 <gmaxwell> TD: amusingly it's been the merchants I've seen most stressed out over fees.. mostly because since they aren't manually tending to the transaction they feel like they don't control them.
1765 2012-06-14 23:17:42 <TD> so anyone who cares about confirm time should ensure a fee gets attached at some point. today it's a PITA because of the sender-attaches model and end users don't really know what kind of fees to attach
1766 2012-06-14 23:17:46 <TD> it's over complicated
1767 2012-06-14 23:17:54 <TD> yeah, well, that's understandable.
1768 2012-06-14 23:18:02 <BlueMatt> and while bitcoin is in its infancy, pushing things like 0 fee is important, because it helps us grow to a point where when fees become essentially mandatory, we can withstand it
1769 2012-06-14 23:18:24 <gmaxwell> mostly people feel better when they get pointed to the fact that the automatic anti-dos fees can't go over 0.05 BTC.
1770 2012-06-14 23:18:25 tower has quit (Remote host closed the connection)
1771 2012-06-14 23:18:26 <TD> so recursively calculating fees solves these problems in one go. buyers get to keep their psychologically valuable zero fees. merchants are in control. people can indicate how much they care about a bunch of txns confirming by spending them to themselves.
1772 2012-06-14 23:18:54 <TD> we'll get SD fixed so it only attaches anti-DoS fees when necessary
1773 2012-06-14 23:19:02 <TD> so their transactions will end up at the bottom of the queue
1774 2012-06-14 23:19:17 <BlueMatt> thats the point, they wont be at the bottom for some time
1775 2012-06-14 23:19:28 <BlueMatt> merchants dont want to pay fees, even if they can
1776 2012-06-14 23:19:30 <gmaxwell> TD: yea, great and then some ignorant user sends the merchant 0.5 btc using 500 inputs and the merchant is annoyed that they need a 1BTC fee to get a higher fee/KB than the dice background noise.
1777 2012-06-14 23:19:42 paul0 has quit (Quit: paul0)
1778 2012-06-14 23:19:43 <BlueMatt> what about merchants who want to avoid fees and just make their users wait a bit longer for confirms?
1779 2012-06-14 23:20:26 <TD> avoiding that situation is why you'd want wallets to be defragged in the background, right? if you need to build gigantic transactions to send small amounts of value, somebody is gonna lose ..... sender or buyer, at least merchants can expect and absorb the cost
1780 2012-06-14 23:20:38 tower has joined
1781 2012-06-14 23:20:56 <TD> BlueMatt: that's fine, right? if it's going to take 2 days to ship the item anyway, waiting is no problem. and some merchants may choose to never broadcast the tx and get it confirmed.
1782 2012-06-14 23:21:35 <TD> BlueMatt: if you're an amazon customer with 500 successfully paid purchases behind you, you're buying from the same IP as always and you logged in with a second factor, maybe amazon thinks you're not gonna double spend and just lets it stay unconfirmed for a month until payroll time
1783 2012-06-14 23:21:38 <BlueMatt> TD: no, Im talking about merchangs, say, mtgox when it was smaller, who dont want to spend the money on fees, and make their users suffer
1784 2012-06-14 23:21:59 <BlueMatt> digital-goods making the user wait longer for using btc
1785 2012-06-14 23:22:12 <TD> in the receiver-pays model, senders never suffer. senders fundamentally don't care about confirmations because they aren't the ones who fear a double spend
1786 2012-06-14 23:22:16 <gmaxwell> Well compeition would handle that except for the network effects that make competition not exist in exchanges.
1787 2012-06-14 23:22:30 <TD> the fact that they're expected to attach fees today is weird and backwards, it's just a quirk of how the protocol is designed
1788 2012-06-14 23:22:55 <TD> it's always the receiver who wants/needs confirmations
1789 2012-06-14 23:23:02 <TD> so it makes sense that it's the receiver who pays for them
1790 2012-06-14 23:23:57 <gmaxwell> the reciever may not be online, alas. Thus the design. Making the reciever pay them requires either the reciever be online to get paid or that that the parties lose control over the amount being sent.
1791 2012-06-14 23:24:19 <sipa> I don't think that is the original design.
1792 2012-06-14 23:24:26 <sipa> The original design was IP transactions.
1793 2012-06-14 23:24:42 <TD> yeah
1794 2012-06-14 23:24:50 <sipa> Sure, in cases where the receiver isn't online and you're doing a personal or anonymous donations, you want the current system.
1795 2012-06-14 23:25:00 <TD> the first time i talked to satoshi i got the impression he implemented addresses later, and saw them as a fallback
1796 2012-06-14 23:25:05 <TD> obviously, ideas changed
1797 2012-06-14 23:25:35 <TD> gmaxwell: well, or the sender attaches a small anti-DoS fee and then it sits around in the mem pool waiting for delivery. but yeah, not totally ideal.
1798 2012-06-14 23:25:47 <sipa> After time, it seems that since no alternative for transmitting transactions appeared, the blockchain turned into a communication channel.
1799 2012-06-14 23:26:03 <TD> gmaxwell: OTOH store-and-forward is a solved problem since the 70s. attach your tx to an email or send it via instant messenger or facebook or whatever
1800 2012-06-14 23:26:10 <TD> no need to reinvent these wheels
1801 2012-06-14 23:26:14 <gmaxwell> Its the worlds worst communication channel. :(
1802 2012-06-14 23:26:14 <sipa> Indeed.
1803 2012-06-14 23:26:27 <gmaxwell> TD: and yet people are doing so, poorly, via the blockchain.
1804 2012-06-14 23:26:46 <TD> yeah. that's what bitcoin-qt supports out of the box :) it's all just plumbing, in the end
1805 2012-06-14 23:26:56 <gmaxwell> In some cases its because there are no ready options with the kind of plausable denyability properties that bitcoin txn have.
1806 2012-06-14 23:26:58 <sipa> I really would like to change the notion that every key is an address - an address is a destination for a payment, and I'd rather see URL's being used for that than key hashes.
1807 2012-06-14 23:27:43 <TD> yeah. i think we all agree on the general direction. just the ordering of tasks to get there is a bit up in the air right now :)
1808 2012-06-14 23:28:00 * TD needs to finish the fee code in bitcoinj and other things before being able to really help with this stuff
1809 2012-06-14 23:28:02 <gmaxwell> E.g. mtgox doesn't want to connect to some underground site when when of their users transfers funds from mtgox to there in order to execute a payment protocol with them. Thus green addresses.
1810 2012-06-14 23:28:10 <TD> and i need to go to bed
1811 2012-06-14 23:28:27 toffoo has joined
1812 2012-06-14 23:28:57 TD has quit (Quit: TD)
1813 2012-06-14 23:30:59 rdponticelli has joined
1814 2012-06-14 23:37:55 AlexWaters has quit (Quit: Leaving.)
1815 2012-06-14 23:44:14 vigilyn has quit (Read error: Connection reset by peer)
1816 2012-06-14 23:48:04 RV__ has quit (Ping timeout: 245 seconds)
1817 2012-06-14 23:49:04 maaaa is now known as galambo
1818 2012-06-14 23:50:10 ciscoftw has quit ()
1819 2012-06-14 23:51:28 <sipa> 225786870 bytes unspent txouts; 736217 unspent txs
1820 2012-06-14 23:51:47 <sipa> as of block 184511
1821 2012-06-14 23:53:49 <[Tycho]> And how much spent ones ?
1822 2012-06-14 23:53:56 <sipa> 5 million or so
1823 2012-06-14 23:54:01 <sipa> oh
1824 2012-06-14 23:54:03 <[Tycho]> In bytes
1825 2012-06-14 23:54:19 <sipa> i'm confusing txs with txouts
1826 2012-06-14 23:56:07 <sipa> gmaxwell: using just a merkle tree with txids + unspent txouts, i believe the entire set of data necessary to do full verification can be serialized to something around 300 MiB in size
1827 2012-06-14 23:56:24 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
1828 2012-06-14 23:56:55 Matt_von_Mises has joined
1829 2012-06-14 23:57:11 <sipa> without any compression
1830 2012-06-14 23:59:55 AntKinGTube has joined