1 2013-03-17 00:20:25 <Eleuthria> gmaxwell or jgarzik, are either of you available?  Quick question I wanted to ask in PM
  2 2013-03-17 00:22:45 <rowit> hey all - any suggestions on a good OSX IRC client?
  3 2013-03-17 00:23:15 <Eleuthria> rowit:  Not specifically an IRC client (especially to purists), but when I use OSX I absolutely love Adium as a multi-protocol IM client which supports IRC
  4 2013-03-17 00:23:47 <Eleuthria> I like to keep my IRC chats in the same tabbed windows as my normal IMs
  5 2013-03-17 00:23:59 <jrmithdobbs> gavinandresen: that email sounds about right
  6 2013-03-17 00:24:06 <jrmithdobbs> gavinandresen: might bump it to 90 instead of 60 days though
  7 2013-03-17 00:24:22 <Eleuthria> gavin is in here?  didn't see him
  8 2013-03-17 00:24:29 <gavinandresen> I'm hiding
  9 2013-03-17 00:24:37 <Eleuthria> Can I send you a quick PM for clarifications?
 10 2013-03-17 00:24:41 <gavinandresen> sure
 11 2013-03-17 00:24:50 <jrmithdobbs> in case there actually are any businesses that might want to actually test changes to any bitcoin stuff (like anyone tests ;p)
 12 2013-03-17 00:25:16 <gavinandresen> jrmithdobbs: more than 2 months to test??  that's a sorry business....
 13 2013-03-17 00:25:29 <jrmithdobbs> gavinandresen: i'd say make it a quarter, ya
 14 2013-03-17 00:25:37 <jrmithdobbs> people are slow as shit
 15 2013-03-17 00:26:08 <gavinandresen> not my problem.
 16 2013-03-17 00:26:37 <gavinandresen> If they REALLY want to be slow, then they should implement the workaround in the next two months (create DB_CONFIG file), then take their sweet time upgrading to 0.8.1
 17 2013-03-17 00:26:56 <sipa> people on debian still get 0.3.24 i think...
 18 2013-03-17 00:27:16 <jrmithdobbs> 90 days doesn't seem unreasonable to me =/
 19 2013-03-17 00:28:55 <gavinandresen> okey dokey.  I'm sticking with 60 days, if I had my druthers it would've been 30....
 20 2013-03-17 00:28:56 <rowit> Eleuthria: Thanks! I'll give Adium a shot
 21 2013-03-17 00:30:02 <gavinandresen> Wait, strike that.  If I could, I would've made it eleven days.
 22 2013-03-17 00:30:33 <sipa> no offence, but i think it's wrong to think that you can decide that
 23 2013-03-17 00:30:52 <sipa> of course we can propose an upgrade scheme, i doubt many would disagree
 24 2013-03-17 00:31:38 <copumpkin> BDFL
 25 2013-03-17 00:31:38 <gavinandresen> do we really have to have a long drawn-out discussion on whether 30 or 60 or 90 or 365 days is the right amount of time?
 26 2013-03-17 00:32:07 <sipa> no, but if it's controversial, it may or may not be the best choice
 27 2013-03-17 00:32:37 <sipa> sorry, i'm not helping you with this, and i also don't know what the best timeframe is
 28 2013-03-17 00:33:07 <gavinandresen> mmm.  I'm willing to be the bad guy this time; if it is controversial, then I take the blame.
 29 2013-03-17 00:33:08 <sipa> i'm just very unconfortable with the idea of forcing people to upgrade without time to discuss it
 30 2013-03-17 00:33:41 <gavinandresen> again, they don't have to upgrade-- they can put a DB_CONFIG file in their datadir and continue on, blissfully running 0.3.24....
 31 2013-03-17 00:34:07 <gavinandresen> If they DID have to change software, then I would agree with you, 60 days is not enough time.
 32 2013-03-17 00:35:17 <sipa> same thing
 33 2013-03-17 00:35:32 <sipa> (again, not saying 60 days is not enough - but i like to be cautious)
 34 2013-03-17 00:36:23 <gavinandresen> 
ACTION grumbles about herding cats.....

 35 2013-03-17 00:36:44 <sipa> i'll stop commenting now, since i'm not helping either way
 36 2013-03-17 00:37:39 <gavinandresen> I wonder how long it will take past May 15'th for a large enough block to get mined to kick off the stragglers...
 37 2013-03-17 00:40:28 <Luke-Jr> IMO, there's really no excuse for not applying critical fixes in 2 months
 38 2013-03-17 00:40:49 <Eleuthria> Luke-Jr:  Agreed.  Especially when we've already seen the results of the bug on live.
 39 2013-03-17 00:43:33 <nanotube> gavinandresen: not going to quibble over 60 or 90 days, but i think there should me more alerts in the interim. just to reduce the chance of people missing them before may8 final alert.
 40 2013-03-17 00:44:51 <cyphase> upgrade or bust. literally
 41 2013-03-17 00:44:51 <jaakkos> so, a guy run into this issue with litecoin... i'm quite sure it affects bitcoin as well
 42 2013-03-17 00:45:29 <jaakkos> he starts a new client with no block chain downloaded, but with an imported wallet file
 43 2013-03-17 00:45:47 <jaakkos> the block chain starts to download, and coins appear to his addresses
 44 2013-03-17 00:45:49 <Luke-Jr> gavinandresen: if it helps, you can announce that I'll spin 0.4.x+ backports sometime during the week of Mar 24
 45 2013-03-17 00:46:05 <jaakkos> however, some of these coins were later spent, but the client doesn't know that yet
 46 2013-03-17 00:46:28 <Eleuthria> jaakkos:  That's normal until the full blockchain was downloaded on the client.
 47 2013-03-17 00:46:30 <jaakkos> now the client allows him to create a tx, which attempts to double-spend the outputs
 48 2013-03-17 00:46:35 <Luke-Jr> gavinandresen: side note: increasing the locks to fix this uses about 100 MB more memory
 49 2013-03-17 00:46:40 <Eleuthria> the double spend won't work
 50 2013-03-17 00:46:41 <jaakkos> the network drops the broadcast
 51 2013-03-17 00:46:50 <jaakkos> however, the tx also contained outputs that are *truly* unspent
 52 2013-03-17 00:47:08 <Luke-Jr> jaakkos: yes, it affects Bitcoin as well, known issue
 53 2013-03-17 00:47:10 <jaakkos> now, even when the chain has finished downloading, the client will not get rid of this invalid tx, it shows with 0 confirmations
 54 2013-03-17 00:47:14 <jrmithdobbs> jgarzik: so how cleanly you think libccoin or w/e will bind to node.js? ;p
 55 2013-03-17 00:47:20 <jaakkos> AND... the unspent money is unspendable forever
 56 2013-03-17 00:47:32 <Luke-Jr> jaakkos: until he rebuilds the wallet, yes
 57 2013-03-17 00:47:33 <jrmithdobbs> jgarzik: cause i have some evil agent ideas ;p
 58 2013-03-17 00:47:34 <Eleuthria> Re-running the client with --rescan should fix that
 59 2013-03-17 00:47:35 <jaakkos> Luke-Jr: ok, is this already fixed?
 60 2013-03-17 00:47:41 <rowit1> jaakkos: the whole tx should be discarded by the network.  It sounds like a problem with the client, not the network
 61 2013-03-17 00:47:44 <nanotube> that said, that's probably a quibble also, and the alert schedule is reasonable enough.
 62 2013-03-17 00:47:48 <Luke-Jr> jaakkos: no, it's not an easy fix. maybe 0.9's wallet changes will do it
 63 2013-03-17 00:48:03 <Luke-Jr> rowit1: it is
 64 2013-03-17 00:48:05 <jaakkos> rowit1: yes of course it's discarded but the problem is that now, the client doesn't let him spend money that he should be able to spend.
 65 2013-03-17 00:48:18 <sipa> -rescan won't fix that
 66 2013-03-17 00:48:21 <sipa> -salvagewallet will
 67 2013-03-17 00:49:24 <gavinandresen> nanotube: it might make sense to have the one-month-to-go alert expire after a week instead of 24 hours. Although are there really that many people who run the full client just once a week?
 68 2013-03-17 00:49:27 <jaakkos> alright, i will tell him. interesting problem :) thanks
 69 2013-03-17 00:50:01 <gavinandresen> nanotube: ??? and the people we really want to upgrade/workaround are merchants/services
 70 2013-03-17 00:50:56 <nanotube> gavinandresen: well, sometimes i go a few days without starting the client. so just talking from my own usage pattern. :)
 71 2013-03-17 00:51:13 <nanotube> and by sometimes i mean 'rather often' :)
 72 2013-03-17 00:54:58 <gavinandresen> nanotube: ok, lets plan second alert lasts a week.  People who didn't upgrade but who do set DB_CONFIG will be annoyed??? but they're going to be annoyed after 15 May anyway.
 73 2013-03-17 00:55:51 <jaakkos> the guy is saying -salvagewallet doesn't help, his balance is still 0. 'dumpprivkey' successfully prints key for an address that has unspent coins as seen in an online block explorer.
 74 2013-03-17 00:56:07 <sipa> jaakkos: is he fully synced?
 75 2013-03-17 00:56:11 <jaakkos> yes
 76 2013-03-17 00:56:29 <nanotube> gavinandresen: sounds good. :)
 77 2013-03-17 00:56:31 <sipa> does litecoin even implement -salvagewallet?
 78 2013-03-17 00:56:57 <jaakkos> should -qt fail with unrecognized options? i will ask him...
 79 2013-03-17 00:57:07 <sipa> no
 80 2013-03-17 00:57:12 <sipa> it ignores unknown options
 81 2013-03-17 00:58:39 <cyphase> doesn't look like litecoin supports -salvagewallet
 82 2013-03-17 00:58:48 <jaakkos> ok
 83 2013-03-17 00:58:49 <cyphase> it's not in the options list
 84 2013-03-17 00:59:31 <sipa> gavinandresen: people who don't upgrade to 0.8(.1) will be annoyed anyway by the speed of the software :)
 85 2013-03-17 00:59:50 <gavinandresen> sipa: very true!  they've been annoyed for months....
 86 2013-03-17 01:00:17 <warren> (So here's your chance to make unpopular changes.)
 87 2013-03-17 01:01:40 <warren> cyphase: I hear someone is launching a blockchain-like client-side encrypted wallet service soon.  If that happens, they'll be able to import the offending keys and spend it.
 88 2013-03-17 01:02:03 <warren> oh
 89 2013-03-17 01:02:05 <warren> jaakkos: ^
 90 2013-03-17 01:03:01 <jaakkos> warren: okay :) i'm currently figuring out all possible keys that he might need to dump and import..
 91 2013-03-17 01:03:23 <warren> oh. i suppose manual dump and import will work.
 92 2013-03-17 01:03:38 <jaakkos> the question is, can i be certain that the only keys we need to dump are the ones from the invalid tx?
 93 2013-03-17 01:04:05 <warren> when you import, do you only need to rescan after the last one?
 94 2013-03-17 01:04:41 <jaakkos> i think it will rescan after each import?
 95 2013-03-17 01:04:56 <warren> jaakkos: you can turn off rescan
 96 2013-03-17 01:05:02 <Eleuthria> By default it will rescan after import, but you can tell it not to
 97 2013-03-17 01:14:06 <pete79> should the RPC API include GetAlerts() ?
 98 2013-03-17 01:18:54 <gavinandresen> getinfo tells you about alerts.  There should be an -alertnotify=<command> ???.
 99 2013-03-17 01:20:20 <cyphase> hmm, good point by etotheipi_ on the dev list; the bitcoin conference is going on the weekend of may 15th
100 2013-03-17 01:23:35 <pete79> gavinandresen: thanks
101 2013-03-17 01:26:07 <gavinandresen> cyphase: I hear they have computers and the Internet in San Jose??? actually, I know they do, I used to live there.
102 2013-03-17 01:27:22 <sipa> but but... if the blockchain fails there won't _be_ an internet anymore
103 2013-03-17 01:27:24 <sipa> oh, wait
104 2013-03-17 01:27:45 <cyphase> gavinandresen, yea, yea, okay. just something to think about :P
105 2013-03-17 01:35:08 <etotheipi_> I don't know about you guys, but I'd prefer to be at home on my command&control center when there's a disaster... not deciding whether to go to my scheduled talk or let the hard fork grow
106 2013-03-17 01:35:26 <etotheipi_> </exaggeration>
107 2013-03-17 01:35:56 <sipa> so bring you command&control center along :)
108 2013-03-17 01:41:05 <cyphase> yea, doesn't yours fit in your pocket?
109 2013-03-17 01:49:31 <jrmithdobbs> seriously, it's 2013
110 2013-03-17 02:04:46 <ProfMac> any clue ---->  Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/mina/filter/SSLFILTER
111 2013-03-17 02:32:33 <jorash> hi guys... is the source code for the btc hashing algo (not just SHA256, but also the particulars of btc) available for download?
112 2013-03-17 02:37:03 <etotheipi_> jorash: sha256(sha256(X)) is used for block headers,  ripemd160(sha256(X)) is for publickey->address
113 2013-03-17 02:37:04 <etotheipi_> that's it
114 2013-03-17 02:38:05 <jorash> thank you
115 2013-03-17 02:39:00 <nanotube> jorash: the whole client is foss. you can grab it off bitcoin.org and read. there are also docs on the wiki. specifically see ,,(bc,wiki block hashing algo)
116 2013-03-17 02:39:01 <gribble> https://en.bitcoin.it/wiki/Block_hashing_algorithm | Jan 16, 2013 ... Block hashing algorithm. From Bitcoin. Jump to: navigation, search. When generating, you constantly hash the block header. The block is also ...
117 2013-03-17 03:01:34 <warren> Is it wise for the distributed leadership to be together in one place? =)
118 2013-03-17 03:05:21 <Graet> better than being in pieces in several places :P
119 2013-03-17 03:28:04 <warren> Does the Version field of the block header really need 4 bytes?  (not a problem, just surprised)
120 2013-03-17 03:32:17 <jgarzik> warren: at the moment, no
121 2013-03-17 03:32:32 <Allicoin> #bitcoin-cad
122 2013-03-17 03:32:42 <jgarzik> jrmithdobbs: bind?  no idea
123 2013-03-17 03:34:51 <Allicoin> JOIN #bitcoin-cad
124 2013-03-17 03:35:06 <Allicoin> JOIN <#bitcoin-cad>
125 2013-03-17 03:35:25 <Allicoin> I don't know what I am doing.... this is not very intuative
126 2013-03-17 03:35:41 <keystroke> type a / before the join /join #bitcoin-cad
127 2013-03-17 03:36:40 <Allicoin> thanks!
128 2013-03-17 03:37:02 <keystroke> sure :)
129 2013-03-17 03:38:18 <jgarzik> Regarding SatoshiDICE... <dooglus> They don't charge the 0.0005 BTC fee to losing payouts any more (as of about a week, I think) so the smallest payout now is 0.5% of the 0.01 BTC min bet, or 5000 satoshis.
130 2013-03-17 03:38:25 <jgarzik> https://bitcointalk.org/index.php?topic=80312.msg1632751#msg1632751
131 2013-03-17 03:39:19 <keystroke> so they got rid of some of the dust?
132 2013-03-17 03:50:25 <Nothing4You> bitcoin-qt stuff doesn't seem to be configured to use qt paths
133 2013-03-17 03:50:39 <Nothing4You> after installing it no longer compiles
134 2013-03-17 03:51:24 <Nothing4You> there is no /usr/bin/lrelease on my system, there are /usr/lib/qt4/bin/lrelease and /usr/bin/lrelease-qt4 though
135 2013-03-17 03:52:33 <Nothing4You> that gives some "RCC: Error in 'src/qt/bitcoin.qrc': Cannot find file 'locale/bitcoin_countrycode.qm"
136 2013-03-17 03:52:50 <Nothing4You> it ignores that error and keeps building
137 2013-03-17 03:53:04 <Nothing4You> then
138 2013-03-17 03:53:19 <Nothing4You> cd /home/rschwab/build/bitcoin-git/src/bitcoin-build; /bin/sh share/genbuild.sh /home/rschwab/build/bitcoin-git/src/bitcoin-build/build/build.h
139 2013-03-17 03:53:19 <Nothing4You> -DQT_NETWORK_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt/mkspecs/linux-g++-64 -Isrc -Isrc/json -Isrc/qt -Isrc/leveldb/include -Isrc/leveldb/helpers -I/usr/include/qt5 -I/usr/include/qt5/QtNetwork -I/usr/include/qt5/QtGui -I/usr/include/qt5/QtCore -Ibuild -o build/bitcoin.o src/qt/bitcoin.cpp
140 2013-03-17 03:53:19 <Nothing4You> g++ -c -m64 -pipe -fstack-protector-all -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -D_REENTRANT -fdiagnostics-show-option -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -Wstack-protector -fPIE -DQT_GUI -DBOOST_THREAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DUSE_UPNP=1 -DSTATICLIB -DUSE_IPV6=1 -DHAVE_BUILD_INFO -DLINUX -D_FILE_OFFSET_BITS=64 -DQT_NO_DEBUG
141 2013-03-17 03:53:22 <Nothing4You> In file included from src/qt/bitcoin.cpp:4:0:
142 2013-03-17 03:53:25 <Nothing4You> src/qt/bitcoingui.h:4:23: fatal error: QMainWindow: No such file or directory
143 2013-03-17 03:53:30 <Nothing4You> compilation terminated.
144 2013-03-17 03:53:32 <Nothing4You> make: *** [build/bitcoin.o] Error 1
145 2013-03-17 04:06:53 <dooglus> jgarzik: is that news to you?
146 2013-03-17 04:11:48 <dooglus> jgarzik: I've seen no word from Erik about it.  This is where I heard about the change: https://bitcointalk.org/index.php?topic=150405.msg1603585#msg1603585
147 2013-03-17 04:15:45 <jgarzik> dooglus: News to me, yes.  But we don't track these sorts of things as we should.
148 2013-03-17 04:16:49 <dooglus> jgarzik: I've not actually looked to see if it's true at all - but parrot it as if it is...
149 2013-03-17 04:17:04 <jgarzik> dooglus: As a major user of the network, there should be better tracking of their behavior
150 2013-03-17 04:17:06 <jgarzik> dooglus: hehe
151 2013-03-17 04:17:37 <dooglus> someone should make annoying posts of their behaviour to the development forum every day, say?
152 2013-03-17 04:17:44 <jgarzik> hehehe
153 2013-03-17 04:21:10 <warren> dooglus: someone asked me if I was the whale yesterday.
154 2013-03-17 04:23:40 <dooglus> were you insulted?
155 2013-03-17 04:24:19 <warren> Surprised to have been found out.
156 2013-03-17 04:25:28 <dooglus> ah...
157 2013-03-17 04:27:43 <warren> (joking, of course)
158 2013-03-17 04:44:09 <muhoo> so much drama in the BTC
159 2013-03-17 04:44:24 <muhoo> it's hard being snoop d o double-g
160 2013-03-17 04:45:16 <grau_> dooglus: so its confirmed SD is no longer dusting? I reconed, and asked yesterday in forums but got no reply.
161 2013-03-17 04:47:04 <jgarzik> grau_: we can answer this question ourselves, with the blockchain data :)
162 2013-03-17 04:47:22 <warren> grau_: if we only had a convenient way to query the block chain...
163 2013-03-17 04:47:26 <jgarzik> grau_: surely bitsofproof has a fancy query ready for this :)
164 2013-03-17 04:48:07 <grau_> jgarzik: you got me :)
165 2013-03-17 04:48:41 <grau_> I saw that yesterday, but also sow a downtime of SD. I did not know if its malfunction or change
166 2013-03-17 04:48:41 <muhoo> really, has nobody put the blockchain into a queryable database?
167 2013-03-17 04:49:06 <grau_> muhoo: bitsofproof does
168 2013-03-17 04:49:16 <jgarzik> grau_: once post dooglus linked above indicated the change may have happened a week ago
169 2013-03-17 04:49:17 <grau_> if you have the patience
170 2013-03-17 04:49:34 <jgarzik> grau_: anyway, the data is in your hands to answer the question :)
171 2013-03-17 04:49:47 <grau_> jgarzik: no. The first change was just increasing dust granurality
172 2013-03-17 04:50:08 <grau_> jgarzik: yesterday something else changed.
173 2013-03-17 04:51:12 <grau_> jgarzik: to be honest: I have one instance of bitsofproof that runs in sync and that is now running with LevelDB
174 2013-03-17 04:51:27 <warren> grau_: not surprising for a polluter to change behavior to avoid calls for regulation.  It's no guarantee that they or someone else can't do it in the future though.
175 2013-03-17 04:51:32 <grau_> jgarzik: to get a relational one in sync takes days
176 2013-03-17 04:52:06 <jgarzik> grau_: a simple per-block iteration is surely possible though
177 2013-03-17 04:52:35 <grau_> jgarzik: sure, I would have to write a few lines of code to do whatever query
178 2013-03-17 04:53:46 <phantomcircuit> relational dbs max out at about 5k inserts/second with 1 index
179 2013-03-17 04:54:03 <phantomcircuit> assuming you're not querying the db simultaneously
180 2013-03-17 04:54:11 <phantomcircuit> days would be a long time
181 2013-03-17 04:55:10 <grau_> phantomcircuit: When inserting new blocks in the relational configuration bitsofproof needs seconds to insert.
182 2013-03-17 04:55:38 <grau_> The reason is that it normalizes txout and txin and indexes by address
183 2013-03-17 04:56:01 <grau_> I however think that it is just a question of budget you need to get relational a good performance
184 2013-03-17 04:56:04 <phantomcircuit> i assume you've already removed all of the foreign key constraints
185 2013-03-17 04:56:19 <phantomcircuit> it mostly isn't
186 2013-03-17 04:56:22 <grau_> phantomcircuit: no I did not.
187 2013-03-17 04:56:29 <phantomcircuit> do that
188 2013-03-17 04:56:39 <phantomcircuit> that si usually a huge performance boost
189 2013-03-17 04:56:45 <grau_> phantomcircuit: The point of relational db is to have them
190 2013-03-17 04:56:47 <phantomcircuit> and is only an integrity issue if you care
191 2013-03-17 04:57:03 <phantomcircuit> grau_, remove them and add them after that batch insert
192 2013-03-17 04:57:25 <phantomcircuit> or even change them to deferred and insert more than 1 block at a time
193 2013-03-17 04:57:59 <grau_> phantomcircuit: I already use batch inserts. Disabling indices for download is an option
194 2013-03-17 04:58:32 <phantomcircuit> grau_, if you're starting from zero and building the database
195 2013-03-17 04:58:40 <phantomcircuit> remove the foreign key constraints
196 2013-03-17 04:58:45 <phantomcircuit> and indexes
197 2013-03-17 04:58:54 <phantomcircuit> then add them at the end of the batch insert
198 2013-03-17 04:59:02 <grau_> phantomcircuit: The whole point of relational db is to enable data mining with a tradeoff of online processing performance
199 2013-03-17 04:59:05 <phantomcircuit> as long as you'r enot querying the db while you're building it
200 2013-03-17 04:59:08 <phantomcircuit> you'll be fine
201 2013-03-17 04:59:31 <phantomcircuit> alternatively you can have a binary pair of databases
202 2013-03-17 04:59:36 <phantomcircuit> one which is building
203 2013-03-17 04:59:45 <phantomcircuit> one which is live and query able
204 2013-03-17 04:59:51 <phantomcircuit> then trade off between them
205 2013-03-17 04:59:52 <grau_> phantomcircuit: I do not have a problem. It works, just slower than LevelDB which is not a surprise
206 2013-03-17 04:59:55 <phantomcircuit> h4x
207 2013-03-17 05:00:05 <phantomcircuit> shrug
208 2013-03-17 05:01:05 <grau_> phantomcircuit: It still has a performance to keep up with the online tx. It just takes days to sync (just like 0.7)
209 2013-03-17 05:01:31 <phantomcircuit> i guess with 0.7 you can put it on a tmpfs and it doesn't take days though
210 2013-03-17 05:17:14 <doublec> hope all those pools on version 1 blocks realise we're 14% away from a supermajority causing their blocks to be orphaned
211 2013-03-17 05:22:23 <cyphase> woo, mined a block on testnet
212 2013-03-17 05:23:02 <cyphase> after 5 failed attempts
213 2013-03-17 05:23:30 <warren> difficulty = 4.00000000
214 2013-03-17 05:23:47 <cyphase> yea, i know
215 2013-03-17 05:24:06 <warren> I've been mining testnet for days and I have nothing.
216 2013-03-17 05:24:27 <cyphase> how many mh/s?
217 2013-03-17 05:24:32 <dooglus> recent 'dusting': http://blockchain.info/tx-index/60950169
218 2013-03-17 05:24:47 <warren> 0.17Mh/s
219 2013-03-17 05:25:07 <cyphase> warren, try changing algorithms
220 2013-03-17 05:25:12 <cyphase> which one are you using now?
221 2013-03-17 05:25:34 <warren> presumably sha256 with a 2% cpulimit
222 2013-03-17 05:25:45 <cyphase> i mean which implementation
223 2013-03-17 05:26:08 <cyphase> switching from c to cryptopp_asm32 gave me a ~20x improvement
224 2013-03-17 05:26:18 <warren> https://github.com/downloads/pooler/cpuminer/pooler-cpuminer-2.2.3-linux-x86_64.tar.gz
225 2013-03-17 05:27:02 <warren> I just turned it on for no purpose.
226 2013-03-17 05:27:13 <iwilcox> dooglus: Meh.  Thought SD had raised "you lost" stuff over dusty thresholds?
227 2013-03-17 05:35:15 <dooglus> iwilcox: here's a more recent one - it seems they return 0.5% of min bet 0.01: http://blockchain.info/tx-index/60968447
228 2013-03-17 05:36:42 <iwilcox> Now you've got me questioning whether I imagined their change.  *finds bitcointalk post*
229 2013-03-17 05:37:11 <dooglus> iwilcox: they lose 10% in fees, you only lose 1.9% on average, so this is a net losing bet for them
230 2013-03-17 05:37:33 <iwilcox> Heh, poor SD :)
231 2013-03-17 05:38:13 <dooglus> for you too, of course.  only the miners win
232 2013-03-17 05:40:09 <iwilcox> dooglus: I read this: https://bitcointalk.org/index.php?topic=150493.msg1603675#msg1603675
233 2013-03-17 05:40:30 <iwilcox> and checked a few txns and it seemed true.  Perhaps it changed back after SD's recent downtime.
234 2013-03-17 05:40:39 <petertodd> 0.00005 is still an unspendable transaction too. To spend it ads 120 bytes to a transaction, 120/1000 * 0.0005 = 0.00006, so a 0.00001 BTC loss.
235 2013-03-17 05:42:19 <dooglus> petertodd: except the first 10k is free?
236 2013-03-17 05:42:26 <petertodd> oops, wait, forgot the pubkey, so 153bytes * 0.0005BTC/KB = 0.0000765BTc, so a 0.0000265BTC net loss.
237 2013-03-17 05:42:42 <Ant0> umm
238 2013-03-17 05:42:45 <Ant0> something weird is happening
239 2013-03-17 05:42:47 <petertodd> Only because of miner charity, don't expect that forever.
240 2013-03-17 05:42:54 <Ant0> on blockchain they say I have 50 BTC
241 2013-03-17 05:43:08 <petertodd> Also the priority code won't let you spend that for a long time in the free 10k anyway.
242 2013-03-17 05:43:19 <Ant0> 53.10055731 BTC $ 2,495.72
243 2013-03-17 05:43:26 <Ant0> but thats not true
244 2013-03-17 05:43:26 <Ant0> :s
245 2013-03-17 05:43:41 <dooglus> petertodd: your size calculation is nearly right though.  I make it 147 to 149 bytes per input
246 2013-03-17 05:43:48 <iwilcox> Ant0: Have you messed about with wallet imports/exports?
247 2013-03-17 05:44:04 <grau_> Ant0: which block?
248 2013-03-17 05:44:25 <petertodd> dooglus: Yeah, I just added them up in my head. Depends on luck w/ the signature size as you know.
249 2013-03-17 05:44:27 <dooglus> petertodd: and the priority code will let you spend it very soon if you mix it with a big enough input
250 2013-03-17 05:44:50 <Ant0> nope iwilcox
251 2013-03-17 05:44:54 <dooglus> petertodd: eg. blockchain.info/tx-index/50754520
252 2013-03-17 05:45:02 <Ant0> it started this morning
253 2013-03-17 05:45:07 <Ant0> I have added two read only wallets
254 2013-03-17 05:45:21 <petertodd> dooglus: Well sure, but that just means you're paying the fee with that big input. Still doesn't help the case where you've spent all your big coins and are wondering if it's worth it to keep the wallet around.
255 2013-03-17 05:45:44 <dooglus> petertodd: right.  dust is hard to spend.
256 2013-03-17 05:46:23 <petertodd> dooglus: Newbies throw away dust wallets all the time because they get frustrated - that's the problem. Similar problem with coinad and it's ilk.
257 2013-03-17 05:47:03 <warren> Is there an anonymous way to donate and discard a dust wallet?
258 2013-03-17 05:47:10 <dooglus> petertodd: dust wallets are slow to spend from too
259 2013-03-17 05:47:33 <petertodd> warren: Maybe, but this is a newbie problem, so I can't see that helping.
260 2013-03-17 05:47:35 <dooglus> warren: I've had a dust wallet emailed to me before to spend the dust for them
261 2013-03-17 05:48:32 <warren> petertodd: in the long-term we need to tax the uneconomically small tx's to make it cost too much to create to begin with.
262 2013-03-17 05:48:59 <petertodd> warren: gmaxwell has some neat pre-payment ideas in that realm
263 2013-03-17 05:49:21 <warren> where were they posted?
264 2013-03-17 05:49:50 <petertodd> https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas is his general dump of ideas
265 2013-03-17 05:49:59 <petertodd> not sure if that specific one is in there
266 2013-03-17 05:50:08 <warreng> warren: hello!
267 2013-03-17 05:51:06 <warreng> i like your nick.
268 2013-03-17 05:55:30 <SomeoneWeird> lol
269 2013-03-17 06:44:32 <warren> oh
270 2013-03-17 06:44:51 <warren> Ant0: I think there's a bug in blockchain where a read-only wallet fails to become spendable later if you add a privkey
271 2013-03-17 06:45:33 <Ant0> warren I didnt added the priv key
272 2013-03-17 06:45:45 <warren> ok, misunderstood you
273 2013-03-17 06:45:50 <Ant0> but both my read only wallet seems to have "received" around 25 ghost btc each
274 2013-03-17 07:17:16 <spilk> Could anyone send me some test coins for testing? mvKW3a5gBzAmM4X8qA9DJosEQz15FnbkMn
275 2013-03-17 07:17:49 <warren> spilk: http://testnet.mojocoin.com/
276 2013-03-17 07:18:06 <spilk> i tried some of the faucets, but nothing ever showed up
277 2013-03-17 07:18:21 <lianj> synced yet?
278 2013-03-17 07:19:10 <spilk> thats what i was wondering. Qt shows 59795 blocks as being completed (most recent being 11mins ago) but bitcoind shows 107651 blocks
279 2013-03-17 07:41:29 <dooglus> iwilcox: the pos you linked to seems to be true.  SD's smallest dust is now 5000 satoshis - which is still dust
280 2013-03-17 07:48:43 <iwilcox> dooglus: Yeah, upon re-reading it properly I realised that.  D'oh!
281 2013-03-17 08:22:44 <Ant0> damn im running out of food
282 2013-03-17 08:22:52 <Ant0> and no money :p
283 2013-03-17 08:23:18 <Ant0> 14GPNioy3mi3D9iMge67j5UAoEy5hT4btn btc pls :P
284 2013-03-17 08:23:24 <Ant0> just kidding
285 2013-03-17 08:23:33 <Ant0> ups wrong chat lol
286 2013-03-17 08:23:42 <Ant0> sorry^2
287 2013-03-17 08:27:01 <da2ce7_d> this notice: http://bitcoin.org/may15.html?utm_source=twitterfeed&utm_medium=twitter&utm_campaign=Feed%3A+Feedhintbitcoin+%28Feedhint.com%2Fbitcoin%29
288 2013-03-17 08:27:13 <da2ce7_d> needs to have a 'draft' flag on it
289 2013-03-17 08:27:20 <da2ce7_d> since people are already linking to it.
290 2013-03-17 08:27:45 <da2ce7_d> and may get confused that there is no 0.8.1 version yet.
291 2013-03-17 08:27:57 <Joric> set_lg_dir ? what's lg
292 2013-03-17 08:29:11 <da2ce7_d> gavinandresen: ^^
293 2013-03-17 08:29:12 <HansDollar> Could anyone answer a question about the bitcoin protocol for me? Specifically, in regard to parsing transaction messages... it seems the Wiki entry for the protocol is either wrong, or I'm just confused.
294 2013-03-17 08:30:05 <grau> HansDollar: ask
295 2013-03-17 08:31:27 <HansDollar> grau: The protocol example shows that in the hex output of a tx message, there is supposed to be a byte that says how many outpoints there are. Just as there is a similar such byte for inpoints. The problem is, where the inpoint value is correct, the outpoint value is not...
296 2013-03-17 08:32:51 <HansDollar> Is it not the Wiki page says "1+\t tx_out count\tvar_int\t Number of Transaction outputs" but I'm consistently seeing it read "30" for that byte (on transactions with one outpoint), which is 48 after a base_10 conversion.
297 2013-03-17 08:34:18 <HansDollar> sorry, that should have been, "Is it not? The Wiki..."
298 2013-03-17 08:34:32 <Guest56048> .
299 2013-03-17 08:34:38 <grau> paste the hex dump you are talking about.
300 2013-03-17 08:34:55 <grau> on the wiki ?
301 2013-03-17 08:35:05 <HansDollar> https://en.bitcoin.it/wiki/Protocol_specification#tx
302 2013-03-17 08:35:19 <HansDollar> The transaction example shows number of outputs is a var_int type.
303 2013-03-17 08:36:01 <Apexseals> lol man
304 2013-03-17 08:36:07 <Apexseals> nvidia cards still havent gotten any better at mining
305 2013-03-17 08:36:10 <grau> It also shows the hex broken down
306 2013-03-17 08:36:16 <Apexseals> msi gtx 670 power edition.  105mh/s
307 2013-03-17 08:36:20 <grau> and out is 02
308 2013-03-17 08:36:54 <Apexseals> i could pre-order a 30gh/s mini rig...but ugh...they wont be selling for a long time
309 2013-03-17 08:36:58 <Apexseals> erm,  shipping
310 2013-03-17 08:37:02 <rebroad_> what is the reason debug.log ever contains IP addresses?
311 2013-03-17 08:37:29 <HansDollar> grau: Yes, I see that. I'm reading the hex as it is defined, and everything else is parsing correctly (pk_scripts, inputs, values, etc...) but the byte for # of outpoints doesn't seem to be a var_int as it says it is on the protocol page.
312 2013-03-17 08:37:50 <rebroad_> I mean, can they perhaps only be shown when a node misbehaves.. I'd like to include some logged for block downloading so that each connected node is given a number, without it being easy to associate with the IP address.
313 2013-03-17 08:38:41 <grau> It might be that the page is inconsitent, but be assured that on the wire nr. of txouts is var_int
314 2013-03-17 08:39:21 <HansDollar> Meaning, I grab the version, number of inputs, the previous output, read the script length, read the number of bytes the script length says to read, read 4 bytes for sequence, and the next byte is supposed to be number of outpoints... but it seems wrong
315 2013-03-17 08:40:15 <grau> HansDollar: parsing it with my eyes hower looks correct. Sequence is FFFFFFF and therafter you get 02
316 2013-03-17 08:40:15 <HansDollar> For a tx with 1 outpoint, I always see that byte show "30" instead of the "01" it should be.
317 2013-03-17 08:40:49 <HansDollar> The example is correct. It doesn't correlate to the txs I'm seeing come in from the network.
318 2013-03-17 08:41:31 <grau> Then your parser is wrong.
319 2013-03-17 08:41:43 <HansDollar> I'm doing it by hand just to verify.
320 2013-03-17 08:41:51 <grau> I wrote a parser myself. It is a pain.
321 2013-03-17 08:42:14 <HansDollar> If it was a different value every time I saw it, I would think otherwise, but every tx I see with 1 outpoint shows "30" for that byte value.
322 2013-03-17 08:42:38 <grau> Then the parser is definitelly wrong
323 2013-03-17 08:43:12 <grau> what language are you using?
324 2013-03-17 08:43:19 <HansDollar> Not running them through a parser. I'm verifying it by hand compared to the example to understand the protocol, so that I can write a parser.
325 2013-03-17 08:43:32 <HansDollar> I think maybe python. Not sure yet.
326 2013-03-17 08:43:57 <grau> There are lots of python parser on github. look for Armory for start.
327 2013-03-17 08:44:21 <grau> or there is pynode from jgarzik
328 2013-03-17 08:44:31 <HansDollar> Armory is far too big for what I need to do. I'll take a look at pynode though
329 2013-03-17 09:36:24 <bVector> is it possible for two transactions to have the same transaction id?
330 2013-03-17 09:46:59 <lianj> bVector: no. only if you found a sha256 collision which highly unlikely
331 2013-03-17 09:50:57 <tockitj> bVector, it is possible
332 2013-03-17 09:51:27 <bVector> how hard would it be in terms of computational time for a single system or a gpu?
333 2013-03-17 09:51:55 <tockitj> more than universe lifetime probably
334 2013-03-17 09:52:02 <iwilcox> The best known attack on SHA256 is, well, 2^255.5
335 2013-03-17 09:52:39 <iwilcox> (C'mon, guys!) :)
336 2013-03-17 09:52:43 <tockitj> odds to do it would be very much against you - but it *is* possible
337 2013-03-17 09:53:06 <saulimus> people do win the lottery, don't they... ;)
338 2013-03-17 09:53:27 <tockitj> we'll this is a bit harder than winning lottery (:
339 2013-03-17 09:53:38 <iwilcox> The point is you'd be a fool to try it because you'd expect it to cost you more in electricity than you'd make.
340 2013-03-17 09:54:25 <tockitj> more like winning 10-20 lotteries in sequence (:
341 2013-03-17 09:54:26 <bVector> how do you make money by generating two txid's that are the same? :P
342 2013-03-17 09:54:44 <tockitj> iwilcox, but he might also get it from first try ? (:
343 2013-03-17 09:54:47 <iwilcox> tockitj: Well, sure, for some order of magnitude of 'more'
344 2013-03-17 09:55:13 <iwilcox> bVector: Dunno, you're the one trying it ;)
345 2013-03-17 09:56:36 <lianj> who said he is trying it. maybe just think he found one
346 2013-03-17 09:58:04 <tockitj> i'd like to see that coallision then (:
347 2013-03-17 09:58:17 <lianj> ^^
348 2013-03-17 09:58:48 <iwilcox> It's the sort of thing that might get exploited as part of some larger swiss-cheese attack I guess.  Say the client forgot to 'AND' the conditions: txid matches, can produce m for hash(m), have private key matching sig(tx)
349 2013-03-17 09:59:22 <iwilcox> So you never know.
350 2013-03-17 10:26:44 <CodeShark> how do I edit en.bitcoin.it wiki pages?
351 2013-03-17 10:27:29 <CodeShark> or rather, how can I get permissions to edit?
352 2013-03-17 10:33:28 <Graet> login, make a micro btc payment and once it goes through you get permission CodeShark
353 2013-03-17 10:33:59 <CodeShark> micropayment to whom?
354 2013-03-17 10:36:12 <CodeShark> the help docs don't seem to say anything regarding people who are already very familiar with bitcoin and want to contribute
355 2013-03-17 10:36:21 <CodeShark> only for people who don't know anything about bitcoin
356 2013-03-17 10:38:38 <Graet> i fou8nd out when i wnet back to edit my pools details on the pools page and found i was unable to, when you go to login there is a link you can click, apparently it is to stop ppl spamming
357 2013-03-17 10:39:33 <CodeShark> oh, hmm - thanks
358 2013-03-17 12:00:39 <sipa> CodeShark: just go to the login page, it has instructions
359 2013-03-17 13:09:46 <pizzacat> does anyone know if a 0.7.2 blockchain can be copied to a 0.6.2 client? i keep getting exceptions
360 2013-03-17 13:24:31 <Vinnie_win> When I go to blockchain.info all I see is "SatoshiDICE...."
361 2013-03-17 13:27:38 <Ant0> true Vinnie_win
362 2013-03-17 13:27:41 <Ant0> pft
363 2013-03-17 14:02:51 <KipIngram> Man, it takes *forever* to synch the blockchain...
364 2013-03-17 14:03:32 <sipa> which version?
365 2013-03-17 14:03:57 <joe_k> would be kind of interesting to have packaged blockchains on s3 for people to snarf at full tilt without p2p, then bring up to date with p2p
366 2013-03-17 14:04:34 <sipa> joe_k: you mean bootstrap.dat ?
367 2013-03-17 14:04:53 <KipIngram> I understand why the blockchain needs to be available, but does the client routinely use the whole thing?  Could the "older part" be replaced by a crc or something for "routine use"?
368 2013-03-17 14:05:03 <aXs__> last 0.8 i started clean synced in less than a day
369 2013-03-17 14:05:14 <Scrat> joe_k: packaged blockchains require trust. bootstrap does not. http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/bootstrap.dat.torrent/download
370 2013-03-17 14:05:15 <sipa> KipIngram: not if you're running a fully validating node
371 2013-03-17 14:05:35 <sipa> KipIngram: if you can't afford the storage it needs, you can run a more lightweight client like Multibit
372 2013-03-17 14:05:54 <KipIngram> I can afford the storage.
373 2013-03-17 14:06:12 <KipIngram> I'm just in the learning phase and trying to absorb as much as possible.
374 2013-03-17 14:06:20 <sipa> ok :)
375 2013-03-17 14:06:27 <joe_k> Scrat: easy enough to verify the package on the first p2p block received.   but yes i suspected someone already did it.  then again, a torrent is still p2p
376 2013-03-17 14:06:48 <Ant0> http://img.imgur.com/YNVYxiT.png <-- what?
377 2013-03-17 14:06:48 <joe_k> for me p2p is usually slower than direct client-to-server, maybe b/c i have 35mbit cable
378 2013-03-17 14:07:10 <sipa> joe_k: feel free to put on a webserver
379 2013-03-17 14:07:18 <joe_k> oh sure i might
380 2013-03-17 14:07:20 <Scrat> joe_k: I'll pm you a direct link
381 2013-03-17 14:07:22 <sipa> bittorrent is just a convenient medium for mass distribution
382 2013-03-17 14:07:30 <sipa> i think some people host bootstrap.dat on http
383 2013-03-17 14:07:47 <sipa> Ant0: solo asic miners?
384 2013-03-17 14:08:49 <Ant0> or the CIA
385 2013-03-17 14:08:50 <Ant0> :P
386 2013-03-17 14:12:48 <Graet> that only shows 7 of about 28 pools
387 2013-03-17 14:13:35 <Graet> http://blockorigin.pfoe.be/top.php actually tries (and succeeds ) to be accurate
388 2013-03-17 14:15:22 <aXs__> Graet: i don't see mtred
389 2013-03-17 14:15:59 <Graet> where?
390 2013-03-17 14:16:04 <aXs__> Graet: on the top
391 2013-03-17 14:16:19 <Graet> #10?
392 2013-03-17 14:16:33 <aXs__> ah
393 2013-03-17 14:16:38 <Graet> :)
394 2013-03-17 14:17:03 <aXs__> Graet: i was ctrl-f "mtred" .. thanks pointing that out :)
395 2013-03-17 14:17:14 <Graet> welcome :)
396 2013-03-17 14:17:41 <Graet> https://bitcointalk.org/index.php?topic=123726.0  << Ant0
397 2013-03-17 14:18:17 <Ant0> gona read it thx Graet
398 2013-03-17 14:18:24 <Graet> :)
399 2013-03-17 14:21:56 <Luke-Jr> gavinandresen: erm, pretty sure the may15 page has a config recommended that does *not* completely fix the problem..
400 2013-03-17 14:22:31 <Luke-Jr> double-checking
401 2013-03-17 14:23:31 <Luke-Jr> yeah, looks like the lock limit there will work up to reorgs 2 deep - that will usually be okay, but 292692 is needed to handle up to 6 deep
402 2013-03-17 14:24:11 <Luke-Jr> will post to ML since you seem AFK
403 2013-03-17 14:26:27 <sipa> Luke-Jr: i get 117000
404 2013-03-17 14:26:31 <sipa> for a 6 deep reorg, max
405 2013-03-17 14:26:38 <sipa> (assuming at least one signature per txin)
406 2013-03-17 14:27:29 <sipa> even somewhat less
407 2013-03-17 14:38:17 <sipa> 114036
408 2013-03-17 14:41:03 <Luke-Jr> sipa: counting the 5 blocks that have to be undone, plus 6 to replay?
409 2013-03-17 14:41:22 <Luke-Jr> I wonder if we should be addressing CVE-2013-2292 in this hardfork somehow..
410 2013-03-17 14:41:47 <sipa> Luke-Jr: counting 6 being undone, and 7 being reconnected
411 2013-03-17 14:42:38 <sipa> Luke-Jr: calculated as 1000000 bytes, minus size of a header, minus size of the minimal coinbase
412 2013-03-17 14:43:04 <sipa> Luke-Jr: that results in one almost-1M transaction left, which then gets 1 output and as many inputs as possible
413 2013-03-17 14:43:19 <sipa> each input having at least one signature
414 2013-03-17 14:43:30 <Luke-Jr> sipa: I didn't realize the header counted toward the 1000000, and I forgot a coinbase
415 2013-03-17 14:43:35 <sipa> results in 8809 txins
416 2013-03-17 14:43:43 <sipa> which means 8811 txids affected
417 2013-03-17 14:44:08 <Luke-Jr> I'm counting inputs at 0-length scriptSig
418 2013-03-17 14:44:20 <sipa> yeah, then it'a certainly a lot more
419 2013-03-17 14:44:46 <Luke-Jr> don't want a hostile miner to be able to exploit it..
420 2013-03-17 15:48:07 <Scrat> looks like b.i has stopped sending unconfirmed inputs
421 2013-03-17 15:48:20 <Scrat> piuk's mailbox must have been full of angry SD players :p
422 2013-03-17 16:01:09 <egecko> nice. my code ran over night
423 2013-03-17 18:05:30 <glitch003> so this might be a stupid question, but how does the bitcoin client know the addresses of the other nodes the first time it launches?
424 2013-03-17 18:06:17 <gmaxwell> glitch003: there is a built in list of 500 starting points, it also queries several dns names that return working nodes. Once it finds some it learns about more via the network.
425 2013-03-17 18:06:54 <glitch003> that makes sense, thanks
426 2013-03-17 18:07:22 <skinnkavaj> sipa: thanks for this http://bitcoin.sipa.be/
427 2013-03-17 18:24:00 <yokosan> https://bitcointalk.org/index.php?topic=154240.0 thoughts? comments? fixes?
428 2013-03-17 18:27:10 <lianj> better sell fast
429 2013-03-17 18:28:20 <dd444> are there any currencies like bitcoins in development yet?
430 2013-03-17 18:29:02 <bVector> wat
431 2013-03-17 18:29:08 <bVector> you mean like bitcoins?
432 2013-03-17 18:29:20 <dd444> yes but a new one
433 2013-03-17 18:29:24 <Eleuthria> Sure, dozens
434 2013-03-17 18:29:31 <dd444> cool
435 2013-03-17 18:29:40 <bVector> bitcoins are in development and is similar to bitcoins
436 2013-03-17 18:29:49 <dd444> can you name any?
437 2013-03-17 18:29:49 <Eleuthria> They're all worthless, but they exist ;p
438 2013-03-17 18:29:52 <owowo> called scamcoins
439 2013-03-17 18:30:05 <bVector> dd444: bvectorcoins
440 2013-03-17 18:30:11 <bVector> do you want to buy some?
441 2013-03-17 18:30:11 <dd444> cool
442 2013-03-17 18:30:15 <dd444> dunno
443 2013-03-17 18:30:16 <Eleuthria> PPCoin, Novacoin, Solidcoin, Devcoin, Litecoin, i0coin, ixcoin, Liquidcoin
444 2013-03-17 18:30:20 <Eleuthria> etc., etc.
445 2013-03-17 18:30:29 <bVector> dont forget bvectorcoins
446 2013-03-17 18:30:36 <owowo> owowowcoin
447 2013-03-17 18:30:49 <dd444> what one is the most popular?
448 2013-03-17 18:30:51 <Eleuthria> Everybody knows Guildcoins are the way of the future.
449 2013-03-17 18:30:59 <bVector> they're currently the most popular coins and are growing the fastest, let me know how you'd like to pay for some
450 2013-03-17 18:31:26 <dd444> k
451 2013-03-17 18:31:29 <dd444> cool
452 2013-03-17 18:32:15 <owowo> but payment only in bitcoin
453 2013-03-17 18:41:48 <dd444> ok but can you buy other things with guildcoins?
454 2013-03-17 18:42:03 <Eleuthria> You can buy Bitcoins with them of course ;p
455 2013-03-17 18:42:16 <dd444> cool
456 2013-03-17 18:42:20 <sipa> dd444: i think the only mildly succesful altcoin is litecoin
457 2013-03-17 18:42:24 <Eleuthria> if you find somebody dumb enough to trade
458 2013-03-17 18:42:36 <sipa> and guildcoins are a joke by Eleuthria i think, as he runs btc guild
459 2013-03-17 18:42:56 <dd444> they have the monopoly then?
460 2013-03-17 18:42:58 <Eleuthria> Naw, I'm going back to the hardfork and renaming it to Guildcoins (/sarcasm)
461 2013-03-17 18:43:16 <sipa> i guess bitcoin has a large first-mover advantage
462 2013-03-17 18:43:32 <sipa> and no altcoin has added any very significant improvements over it, imho
463 2013-03-17 18:44:04 <Eleuthria> LTC at the very least offers two things.  Faster confirmations (not revolutionary enough)
464 2013-03-17 18:44:30 <Eleuthria> And different hash algorithm so it couldn't be crushed by a few Avalons.
465 2013-03-17 18:45:02 <Eleuthria> But neither of those is enough to justify the valuation since they're basically unspendable
466 2013-03-17 18:45:04 <sipa> i'm sure it could be crushed by a hypothetical and perhaps slightly more expensive Avaliteons
467 2013-03-17 18:49:39 <Eleuthria> Is pull 2373 the only required update to the old 0.8 for moving forward with the 0.7->0.8 transition?
468 2013-03-17 18:50:38 <sipa> Eleuthria: 0.8.1 was just tagged
469 2013-03-17 18:52:18 <Eleuthria> Hmm...I'm confused by the change to "start enforcing 21 March 2013"
470 2013-03-17 18:53:19 <Eleuthria> Wouldn't that mean in the next few days we could have another hard fork if a block was designed maliciously?
471 2013-03-17 18:53:27 <sipa> just as we can now
472 2013-03-17 18:53:38 <Eleuthria> But if for example....Guild updated to 0.8.1 right now
473 2013-03-17 18:53:59 <sipa> the problem is that the extra rule on itself also has a risk for forking, if less than 50% of mining power updates to 0.8.1
474 2013-03-17 18:54:19 <sipa> because certain blocks can be acceptable to 0.7.x but not to the temporary rule in 0.8.1
475 2013-03-17 18:55:30 <sipa> so there is a short delay before it becomes active, to give miners the time to upgrade
476 2013-03-17 18:55:37 <gmaxwell> Eleuthria: 0.7.x is not entirely self-consistent.
477 2013-03-17 18:56:42 <sipa> Eleuthria: note that 0.8.1 also limits the size of created blocks immediately, so there is no risk of accidentally _creating_ a forking block before thursday
478 2013-03-17 18:58:33 <Eleuthria> But since the affected transaction part doesn't take effect until Thursday, lets say more than 50% of hash power moved to 0.8.1 before Thursday.
479 2013-03-17 18:58:52 <sipa> ok
480 2013-03-17 18:58:54 <Eleuthria> Is it possible for a block under 500kb to still trigger that, if it was designed specifically to do that?
481 2013-03-17 18:59:05 <Eleuthria> And force a hard fork prior to Thursday
482 2013-03-17 18:59:07 <daedalus2027> hi, did the network split again?
483 2013-03-17 18:59:48 <gmaxwell> daedalus2027: why are you asking that?
484 2013-03-17 18:59:48 <sipa> Eleuthria: a 500 KiB block can't exceed the 10000 lock limit
485 2013-03-17 19:00:25 <sipa> if it was very specifically designed to, maybe
486 2013-03-17 19:00:37 <sipa> but that would require transactions with tons of empty txin scripts, for example
487 2013-03-17 19:00:38 <Eleuthria> That's my biggest concern with upgrading right now.
488 2013-03-17 19:00:48 <Eleuthria> I know accidentally it would be virtually impossible.
489 2013-03-17 19:01:12 <daedalus2027> gmaxwell: beacuse im geting a tons of errors after the block height=216315
490 2013-03-17 19:01:23 <gmaxwell> daedalus2027: tons of errors?
491 2013-03-17 19:01:37 <gmaxwell> daedalus2027: Can you please provide more details? What errors?
492 2013-03-17 19:01:49 <daedalus2027> gmaxwell: yes http://pastebin.com/EENDXTkj
493 2013-03-17 19:02:05 <gmaxwell> In any case, height 216315 is a long time back now
494 2013-03-17 19:02:21 <daedalus2027> gmaxwell: i am not sure in what version of the client should i be
495 2013-03-17 19:02:30 <gmaxwell> daedalus2027: your database is corrupt.
496 2013-03-17 19:02:43 <gmaxwell> I assume thats an older version?
497 2013-03-17 19:02:55 <daedalus2027> yes i am in 7.0.2
498 2013-03-17 19:03:15 <daedalus2027> shoul i upgrade?
499 2013-03-17 19:03:20 <gmaxwell> daedalus2027: are you a large mining pool or solo miner?
500 2013-03-17 19:03:54 <daedalus2027> gmaxwell: solo miner in a pool
501 2013-03-17 19:04:18 <gmaxwell> Do you mean p2pool?
502 2013-03-17 19:04:40 <daedalus2027> nope i am in deepbit
503 2013-03-17 19:04:54 <sipa> then you're not a solo miner :D
504 2013-03-17 19:05:10 <sipa> your miner software isn't even connected to your own bitcoind
505 2013-03-17 19:05:24 <gmaxwell> Then you are not a miner, as far as the bitcoin system is concerned. You're just selling computer time to deepbit, and what version of bitcoin you run is irrelevant. You should upgrade 0.8, it will fix your corrupted database and all will be good.
506 2013-03-17 19:05:26 <daedalus2027> yes
507 2013-03-17 19:06:08 <daedalus2027> thank you
508 2013-03-17 19:07:16 <sipa> Eleuthria: in theory, a 500000 byte block can affect up to 12193 txids, but it would require several specially-crafted blocks in a row to even build the inputs for that
509 2013-03-17 19:14:42 <sipa> Eleuthria: one way to be even more sure, is run 0.7.x, and have a 0.8.1 connect to that 0.7.x (and nowhere else), and use the 0.8.1 to build blocks
510 2013-03-17 19:15:13 <Eleuthria> But then I'm still sitting behind the 0.7 bottleneck on processing new blocks
511 2013-03-17 19:15:34 <sipa> ah, that's the problem; not the speed of createnewblock
512 2013-03-17 19:15:35 <sipa> right
513 2013-03-17 19:15:40 <Eleuthria> It's both
514 2013-03-17 19:16:12 <Eleuthria> but I'd be adding delay of 0.7 confirming the new block, then relaying it to 0.8, which then processes the block (though much faster), and then can finally produce new work
515 2013-03-17 19:16:24 <sipa> right; no solution
516 2013-03-17 19:16:31 <Eleuthria> Well, its a compatibility solution
517 2013-03-17 19:16:42 <Eleuthria> But it leaves me no better than just using 0.7
518 2013-03-17 19:16:51 <sipa> yes, i understand
519 2013-03-17 19:17:15 <sipa> but it's a very hasty soft fork we're doing essentially now, with the temporary 0.8.1 rule
520 2013-03-17 19:17:36 <sipa> if not everyone starts enforcing it at the same time, we risk more forks
521 2013-03-17 19:18:13 <epylar> i was wondering why descriptions of the satoshi dice problem usually say 'they pay transaction fees so they usually get priority over "legitimate" transactions'.. couldn't legitimate transactions pay transaction fees too?
522 2013-03-17 19:18:23 <epylar> it seems like the dice fees are pretty low
523 2013-03-17 19:18:26 <Eleuthria> yes
524 2013-03-17 19:18:44 <Eleuthria> The sdice problem is highly overstated
525 2013-03-17 19:19:03 <sipa> they are filling my hard disk, and aren't paying me for that
526 2013-03-17 19:19:15 <sipa> yes, i voluntarily run my node, so i shouldn't expect payment
527 2013-03-17 19:19:25 <petertodd> epylar: They pay double the "standard" 0.0005 fee that is recommended generally, and people don't seem to realize it is a market.
528 2013-03-17 19:19:29 <Eleuthria> Silk Road does too sipa ;p
529 2013-03-17 19:19:29 <warren> epylar: what is an appropriate tx fee in fiat?
530 2013-03-17 19:19:33 <sipa> but i run it because i believe it contributes to building a global payment system that is worth having
531 2013-03-17 19:20:03 <sipa> and if it is mainly being used for purposes that i do not feel are economically useful for the system, it may drop my incentive to run that node
532 2013-03-17 19:20:04 <epylar> i'm not sure what's appropriate, but it does create more incentive to mine by raising the "market" transaction fee
533 2013-03-17 19:20:27 <epylar> sipa: the disk usage thing i do see as a problem
534 2013-03-17 19:21:09 <epylar> do we expect fairly useless things like dice to grow larger over time?
535 2013-03-17 19:21:18 <gmaxwell> epylar: when I looked a couple weeks ago they were paying 0.001 BTC on all transactions, meaning a large data size (e.g. 100k) transacition might need to pay as much as 0.1 BTC to be ahead...
536 2013-03-17 19:21:22 <epylar> or be drowned out by useful transactions as bitcoin becomes more accepted?
537 2013-03-17 19:21:23 <petertodd> epylar: http://blockchain.info/charts/transaction-fees-usd is interesting, since the fork it looks like the fees collected by miners have dropped significantly.
538 2013-03-17 19:21:44 <epylar> 0.1 is pretty high.. about $5 today.
539 2013-03-17 19:21:52 <Eleuthria> petertodd:  That's because dice was down for a while I believe
540 2013-03-17 19:22:08 <petertodd> epylar: I figure as people realize you can use the blockchain for storage there is no end to the amount of data people will want to put into it.
541 2013-03-17 19:22:11 <epylar> wow, that's some spike
542 2013-03-17 19:22:13 <Eleuthria> And fewer dice transactions are getting confirmed because the bitcoind BTC Guild rolled back to had an anti-dice patch in it from a long time ago
543 2013-03-17 19:22:24 <gmaxwell> epylar: it's just from one transaction that paid a very large fee.
544 2013-03-17 19:22:42 <petertodd> Eleuthria: I know, which shows you that tx fees are significant. (but yeah, as gmaxwell says for the big spike)
545 2013-03-17 19:23:18 <petertodd> Eleuthria: Pales in comparison to the block reward, but thing of the pool ops that pay their bills with fees.
546 2013-03-17 19:23:36 <Eleuthria> pales in comparison might be a bit strong
547 2013-03-17 19:23:43 <warren> Eleuthria: delaying SD payouts has the benefit of shaking confidence in its users, which may lead to solving the problem
548 2013-03-17 19:23:54 <Eleuthria> when I was running 0.8 with larger block sizes, the fees added 2-3% to the total block reward quite often
549 2013-03-17 19:23:57 <warren> in the short-term at least
550 2013-03-17 19:24:07 <epylar> i know we can use the merkle tree pruning and have most people run light clients, but we'll always have a bunch of nodes that have to store every transaction.  so what are the current thoughts on solving the general problem of spamming the chain?
551 2013-03-17 19:24:35 <petertodd> Eleuthria: Sure, which as I say is a pool ops margin - people running the mining hardware don't care.
552 2013-03-17 19:24:36 <sipa> i think the only viable solution to that is limiting the block size
553 2013-03-17 19:24:40 <sipa> to some extent
554 2013-03-17 19:24:51 <Eleuthria> petertodd:  Except many pools share tx fees
555 2013-03-17 19:25:11 <Eleuthria> Including BTC Guild on PPLNS, which over half its users are now using
556 2013-03-17 19:25:11 <petertodd> Eleuthria: Oh, I didn't realize that's happening now.
557 2013-03-17 19:25:58 <warren> epylar: One current problem is our fee structure has a tiny flaw.  Per KB size in the block chain is not our only cost.  We are failing to charge fees proportional to the growth of economically unspendable uxto that is nearly permanent cost separate from the block size.
558 2013-03-17 19:26:00 <epylar> so limiting the block size has the effect of increasing the market transaction fee rate, and crowding out the spammy stuff?
559 2013-03-17 19:26:19 <gmaxwell> epylar: among other effects.
560 2013-03-17 19:26:40 <sipa> in general, it keeps it viable for many people to run validating nodes
561 2013-03-17 19:26:57 <sipa> (which doesn't mean the block size must forever remain what it is now)
562 2013-03-17 19:27:08 <epylar> i suppose there's no way to prune ancient history by storing some sort of self-signed summary?  (and of course at least one person would still have to hold the entire history)
563 2013-03-17 19:27:27 <epylar> also there are a very large number of potential addresses
564 2013-03-17 19:27:33 <epylar> so maybe that wouldn't save much space.
565 2013-03-17 19:27:37 <sipa> epylar: sure there is; it's called the unspent transaction output set
566 2013-03-17 19:27:47 <sipa> since 0.8, the client stores this explicitly
567 2013-03-17 19:27:51 <epylar> ah.
568 2013-03-17 19:27:59 <sipa> and it contains all data necessary to validate future transactions
569 2013-03-17 19:29:41 <epylar> well that's nice.  is there a mechanism to legitimately remove all history older than a certain number of years, say, to the point where it's permanently gone?  that's kind of tricky because the unspent set isn't explicitly validated by any future blocks.. it's just a summary of the past.
570 2013-03-17 19:29:47 <epylar> you'd have to trust central signing authorities
571 2013-03-17 19:30:21 <sipa> if you have the UTXO set (~160 MB now), you can validate all transactions
572 2013-03-17 19:30:28 <sipa> no need for blocks
573 2013-03-17 19:30:35 <epylar> understood, but you have to trust whoever gives you the UTXO set
574 2013-03-17 19:30:43 <sipa> you don't- you build it yourself
575 2013-03-17 19:30:48 <gmaxwell> epylar: a normal node does not make use of historical data once it has validated except for the purpose of giving it to other nodes.
576 2013-03-17 19:30:49 <sipa> by validating history
577 2013-03-17 19:30:55 <sipa> that doesn't mean you need to _keep_ history
578 2013-03-17 19:31:08 <epylar> but it does need to exist at least once.. no way to permanently remove it for everyone.
579 2013-03-17 19:31:17 <epylar> so we do incur a permanent cost of a sort with every transaction
580 2013-03-17 19:31:23 <epylar> permanent recurring even.
581 2013-03-17 19:31:24 <Eleuthria> Do we know the peak size of the UTXO set?
582 2013-03-17 19:31:35 <Eleuthria> Like on X date it reached it's highest size of Y MB?
583 2013-03-17 19:31:38 <gmaxwell> epylar: the security model of bitcoin precludes that??? then you'd have to trust that they didn't steal or make up a bunch of coins if you don't check.
584 2013-03-17 19:31:46 <epylar> sipa: i can see that removing some of the ongoing storage cost, though.  just need to temporarily store some things for validation.
585 2013-03-17 19:32:03 <epylar> and temp space availability goes up all the time.  drives keep getting bigger.
586 2013-03-17 19:32:10 <gmaxwell> Eleuthria: I would be surprised if any block in the last year has shrank it.
587 2013-03-17 19:32:19 <epylar> ancient history would be fairly easy to distribute on physical media if it came to that
588 2013-03-17 19:32:23 <gmaxwell> Certantly its unusual for it to shrink.
589 2013-03-17 19:32:25 <epylar> wouldn't have to use network resources
590 2013-03-17 19:32:41 <Eleuthria> gmaxwell:  Would be unusual, but if a lot of old outputs got consolidated (moved to sell off for fiat for example)
591 2013-03-17 19:32:44 <Eleuthria> It could shrink it
592 2013-03-17 19:32:49 <gmaxwell> epylar: the maximum size, assuming that 0 value txouts don't get mined is about 44 petabytes.
593 2013-03-17 19:33:36 <gmaxwell> Eleuthria: sure. and such transactions happen, I'd just be surprised if any recent block was net shrinking, there are a lot of very small outputs being created that are never consumed.
594 2013-03-17 19:33:55 <gmaxwell> sipa: do you still have the script to do txouts by value by time? An updated graph would be interesting.
595 2013-03-17 19:34:07 <warren> gmaxwell: if clients had a "discard" button that donated dust keys to *somewhere* ...
596 2013-03-17 19:34:20 <epylar> well, let's see, hard drive space goes up by a factor of maybe 20 or so per decade?
597 2013-03-17 19:34:40 <Eleuthria> What file does the UTOX set get saved to in 0.8?
598 2013-03-17 19:34:46 <Eleuthria> *TXO
599 2013-03-17 19:35:01 <TD> it's a leveldb
600 2013-03-17 19:35:05 <epylar> or wait, maybe between 20-30
601 2013-03-17 19:35:12 <gmaxwell> warren: yea, I'd review and support a patch to add a "throw away wallet" that published all your privkeys somewhere.
602 2013-03-17 19:35:39 <warren> gmaxwell: where should somewhere be?
603 2013-03-17 19:35:50 <epylar> 2013, 4 tb -> 2023, 120 tb -> 2033, 3.6 pb -> 2043, 108 pb.
604 2013-03-17 19:35:52 <gmaxwell> Eleuthria: the data is in chainstate/ though the accurate size is available via rpc.
605 2013-03-17 19:36:00 <epylar> so somewhere between 2033 and 2043 we might reasonably see drives that could hold 44 petabytes?
606 2013-03-17 19:36:07 <Eleuthria> Ah, what's the RPC call for that? :)
607 2013-03-17 19:36:16 <sipa> epylar: gettxoutsetinfo
608 2013-03-17 19:36:19 <sipa> eh, Eleuthria
609 2013-03-17 19:36:35 <gmaxwell> (note: slow rpc command)
610 2013-03-17 19:36:43 <Eleuthria> lol
611 2013-03-17 19:36:46 <Eleuthria> Now you tell me ;p
612 2013-03-17 19:36:53 <Eleuthria> not that slow
613 2013-03-17 19:36:57 <gmaxwell> well it's not that slow.
614 2013-03-17 19:37:05 <Eleuthria> 154,706,669 bytes, not bad
615 2013-03-17 19:37:20 <Eleuthria> You could store that in RAM on most cheap VPS
616 2013-03-17 19:37:34 <gmaxwell> Eleuthria: thats the idea, it's a major part of why 0.8 is fast.
617 2013-03-17 19:37:34 <TD> indeed
618 2013-03-17 19:38:24 <sipa> Eleuthria: the actual database is larger than that, as it has indexing and bloom filters and other overhead
619 2013-03-17 19:38:30 <gmaxwell> Eleuthria: but the growth (at least last time sipa charted it) seemed to have the same rate as the overall ... at least after the introduction of SD. :(  http://bitcoin.sipa.be/pruning-size.png
620 2013-03-17 19:38:33 <sipa> but it could be serialized to that size, without further compression
621 2013-03-17 19:39:36 <gmaxwell> (see, around block 100k we saw nice divergence where the utxo was clearly more scalable than the whole chain, but then that breaks down as tiny ouputs started to be created enmass :()
622 2013-03-17 19:39:57 <Eleuthria> Yeah :/
623 2013-03-17 19:40:26 <gmaxwell> It's still better though, but less so. Thus the concern about outputs which aren't even economical to spend.
624 2013-03-17 19:40:31 <TD> sipa: in future the keys could be prefixed with a hotness tag, so outputs that some heuristic judges are likely to unspent for a long time could be moved to a separate key range that doesn't fill up the memory cache
625 2013-03-17 19:40:36 <Eleuthria> I guess I don't have the same hatred of sdice because the few times I gamble it doesn't send me back satoshis
626 2013-03-17 19:40:48 <Eleuthria> It's only the people making micro-bets that get back satoshi-sized responses
627 2013-03-17 19:41:12 <gmaxwell> TD: we can also just keep likely hot utxo explicitly in the cache.
628 2013-03-17 19:41:23 <TD> eventually wallets can start to auto-defrag themselves and the micropayments can start to get mopped up
629 2013-03-17 19:41:27 <sipa> did someone say splay tree?
630 2013-03-17 19:41:51 <gmaxwell> sipa: can't commit a splay tree. :P
631 2013-03-17 19:42:00 <sipa> details!
632 2013-03-17 19:42:03 <TD> well, leveldb isn't a splay tree, but things that were recently written are in memory anyway
633 2013-03-17 19:42:04 <gmaxwell> lol
634 2013-03-17 19:42:08 <TD> heh
635 2013-03-17 19:42:11 <warren> Eleuthria: Deciding to deal with the uneconomical dust uxto issue isn't necessarily a moral judgement of SD.
636 2013-03-17 19:42:25 <gmaxwell> TD: You don't think people will be furious about auto-defrag that has net-cost?
637 2013-03-17 19:42:26 <Eleuthria> warren:  Agreed
638 2013-03-17 19:42:57 <sipa> TD: and recently written data is at a higher level
639 2013-03-17 19:43:00 <TD> in the long long long run, we may want to end up with the utxo db split across multiple disks, so it can benefit from increased spindles
640 2013-03-17 19:43:24 <TD> gmaxwell: i was thinking wallets could just fill up to whatever the next fee level is without actually going over it
641 2013-03-17 19:43:25 <petertodd> warren: All they have to do is increase the 'you lost' return tx.
642 2013-03-17 19:43:42 <gmaxwell> most of the committed utxo discussion has a high branching factor, in part for storage parallelism.
643 2013-03-17 19:44:02 <sipa> wait, the discussion has a branching factor?
644 2013-03-17 19:44:08 <TD> gmaxwell: also wallets that are always on can submit free transactions that mop up satoshis when they know the user isn't likely to want to make a spend with them, eg, at night, so it's ok if they take a little longer to confirm
645 2013-03-17 19:44:17 <petertodd> TD: I don't think anyone hasn't been assuming that... it's important for miners anyway so they can validate new blocks fast.
646 2013-03-17 19:44:22 <sipa> http://xkcd.com/761/
647 2013-03-17 19:44:32 <petertodd> TD: (as utxo > ram obviously)
648 2013-03-17 19:44:38 <gmaxwell> TD: there isn't a next fee level anymore, gavin changed the fee calculation to be continuous. I whined a bit that this removes the incentive to sweep, but it's the case that the fee motivation was continuous anyways.
649 2013-03-17 19:44:38 <TD> well, currently utxo < ram
650 2013-03-17 19:45:00 <TD> gmaxwell: i thought it was per kb, when did it change?
651 2013-03-17 19:45:28 <gmaxwell> TD: with the prioritize by fee logic that went in .. in 0.7.0 (IIRC?)
652 2013-03-17 19:45:29 <TD> sipa: lol
653 2013-03-17 19:46:22 <gmaxwell> TD: see also, https://github.com/bitcoin/bitcoin/issues/1722
654 2013-03-17 19:47:31 <TD> what a weird-ass cast
655 2013-03-17 19:47:55 <gmaxwell> Fundimentally the change is right... miner income depends on the non-quantized fees per kb. The quantized behavior was just an incentive, if we want one (and think miners will agree) we should make it explicit.
656 2013-03-17 19:48:17 <TD> anyway, i'm assuming that after the block size limit is removed all transactions will get included very fast anyway, even if they're low priority
657 2013-03-17 19:48:39 <gmaxwell> lol
658 2013-03-17 19:48:39 <sipa> block size limit _removed_ ?
659 2013-03-17 19:48:41 <sipa> wtf?
660 2013-03-17 19:48:42 <gmaxwell> Good luck with that.
661 2013-03-17 19:49:02 <petertodd> TD: Thanks, I've had a lot of interest in my new blockchain backup service.
662 2013-03-17 19:49:23 <TD> you know what i mean. removed == automatically/manually set to levels where block size always meets demand for transactions
663 2013-03-17 19:49:33 <TD> ie, people are not attempting to outbid each other for an artificially scarce resource
664 2013-03-17 19:49:34 <sipa> i hope we never do that
665 2013-03-17 19:49:40 <petertodd> TD: I'm starting a new pool actually to get my "unspendable but not provably so" outputs mined too.
666 2013-03-17 19:49:59 <jgarzik> sipa: +1
667 2013-03-17 19:50:15 <jgarzik> TD: that's a fundamentally broken system
668 2013-03-17 19:50:15 <sipa> increasing it along with increasing computation power, sure
669 2013-03-17 19:50:17 <petertodd> TD: Like, imagine I'm a pop star, and I want to make sure my music is still around 20 years from now when I'm inexplicably remembered again.
670 2013-03-17 19:50:53 <TD> shrug. if you want to make a backup service that sucks compared to its competition, go ahead.
671 2013-03-17 19:51:04 <TD> i predict usage will be low
672 2013-03-17 19:51:09 <jgarzik> TD: Satoshi obviously wanted fees to support the system long term.  If there is no scarcity, there are no fees.
673 2013-03-17 19:51:22 <TD> i don't believe that's correct at all
674 2013-03-17 19:51:29 <TD> but we've been around this a million times already
675 2013-03-17 19:51:45 <petertodd> TD: Sucks? Nah, we're offering security and quality! Where else can you *know* your data is secure, just by performing a transaction?
676 2013-03-17 19:51:48 <TD> trying to come up with a block size limit that's "big enough but not too big" is a doomed exercise in central planning
677 2013-03-17 19:51:49 <jgarzik> TD: The current situation, where block subsidy dominates other incentives, clouds thinking on block size
678 2013-03-17 19:52:29 <sipa> i'm not convinced about that either, but i don't think such an assumption is even needed to see why a block size following transaction demand risks (= not certain) killing decentralization
679 2013-03-17 19:53:23 <epylar> i'm always forgetting my passwords to things