1 2012-06-07 00:54:43 <D34TH> sipa: i think that cosmetic issue runs deeper than purely cosmetic
  2 2012-06-07 00:55:07 <D34TH> after about 2 hours of a node being alive it suddenly reports diff is 1 until restarted
  3 2012-06-07 05:38:16 <Habbie> how is a txid generated? is it simply a hash of the transaction?
  4 2012-06-07 05:38:43 <sipa> yes
  5 2012-06-07 05:39:14 <Habbie> thanks
  6 2012-06-07 06:41:18 <weex> it would be better if bitcoin-qt estimated and showed minutes left in syncing rather than the three lines when one hovers over the orange spinning arrows
  7 2012-06-07 06:41:34 <weex> the percent complete is going to be increasingly meaningless
  8 2012-06-07 06:43:18 <weex> I'd rather see:  Block 182991 (402 left to download)
  9 2012-06-07 06:43:54 <weex> oh it says that
 10 2012-06-07 09:00:12 <TheSeven> is there an RPC call that returns all accounts with their balances and all associated addresses?
 11 2012-06-07 09:00:52 <TheSeven> or do I have to use listaccounts and then getaddressesbyaccount for each account?
 12 2012-06-07 09:07:10 <freewil> TheSeven, yup pretty sure you answered your own question
 13 2012-06-07 09:07:27 <TheSeven> well, that's one thing it's badly lacking then
 14 2012-06-07 09:07:41 <TheSeven> along with stuff like renaming accounts or retroactively changing transaction comments
 15 2012-06-07 09:10:43 <freewil> yeah maybe
 16 2012-06-07 09:10:56 <freewil> i think all that can be accomplished now with the lower-level existing commands
 17 2012-06-07 09:11:02 <freewil> except for changing tx commits
 18 2012-06-07 09:11:05 <freewil> comments*
 19 2012-06-07 09:11:10 <freewil> can that be done in the gui?
 20 2012-06-07 09:28:59 <sipa> accounts are not exposed at all in the gui
 21 2012-06-07 10:43:03 <TheSeven> freewil: listreceivedbyaddress can be abused to get all addresses from all accounts :)
 22 2012-06-07 10:43:36 <freewil> ha, hows that
 23 2012-06-07 10:43:48 <TheSeven> so just two requests total
 24 2012-06-07 10:45:01 <freewil> that wont give you the addresses if nothing has been sent to them yet though
 25 2012-06-07 10:46:32 <TheSeven> there's an includeempty flag :)
 26 2012-06-07 11:11:05 <TheSeven> what the hell...
 27 2012-06-07 11:11:17 <TheSeven> listaccounts seems to omit some accounts
 28 2012-06-07 11:34:27 <freewil> TheSeven, what do you mean?
 29 2012-06-07 11:35:45 <TheSeven> freewil: well, listreceivedbyaddress returns addresses that are owned by accounts that weren't returned by listacounts
 30 2012-06-07 11:36:33 <freewil> are you calling it with minconf=0
 31 2012-06-07 11:36:43 <TheSeven> yes
 32 2012-06-07 11:37:24 <freewil> might be a bug
 33 2012-06-07 11:37:52 <freewil> https://github.com/bitcoin/bitcoin/issues/new
 34 2012-06-07 11:38:38 <freewil> if you could put together some example output that would be awesome
 35 2012-06-07 11:39:17 <TheSeven> ah, I think I have an idea what might be going on
 36 2012-06-07 11:39:40 <TheSeven> those addresses seem to be the ones listed in the "address book" tab of bitcoin-qt
 37 2012-06-07 11:39:57 <TheSeven> i.e. listreceivedbyaddress lists addresses that aren't owned by the waller
 38 2012-06-07 11:40:03 <TheSeven> wallet*
 39 2012-06-07 11:41:24 <freewil> i think listreceivedbyaddress ONLY shows addresses owned by the wallet
 40 2012-06-07 11:41:29 <freewil> those should be the receiving addresses
 41 2012-06-07 11:41:44 <TheSeven> well, it listed the testnet faucet donation address over here
 42 2012-06-07 11:41:48 <freewil> on the other hand, not so sure about the gui but the address book probably shows addresses that you sent to
 43 2012-06-07 11:42:54 <freewil> hmm that doesnt seem right
 44 2012-06-07 11:43:11 <TheSeven> I see no other way to even assign non-owned addresses to accounts
 45 2012-06-07 11:43:30 <TheSeven> but apparently bitcoin-qt abuses accounts to store the address book labels
 46 2012-06-07 11:43:39 <freewil> yeah i wonder if its a glitch in the gui maybe
 47 2012-06-07 11:43:55 <freewil> either how it stores or retrieves
 48 2012-06-07 11:44:03 <TheSeven> should I upload the wallet in question somewhere?
 49 2012-06-07 11:44:30 <freewil> yeah that would probably be helpful
 50 2012-06-07 11:44:35 <freewil> example output/screenshots too
 51 2012-06-07 11:50:16 <freewil> maybe that is expected behavior though
 52 2012-06-07 11:50:28 <freewil> if the gui uses accounts to store addresses you send to
 53 2012-06-07 11:50:43 <TheSeven> http://dl.dropbox.com/u/23683845/bitcoin-bug-nonowned-addr-in-account/wallet.dat
 54 2012-06-07 11:50:45 <TheSeven> http://dl.dropbox.com/u/23683845/bitcoin-bug-nonowned-addr-in-account/bitcoin-qt%20showing%20address%20in%20address%20book.png
 55 2012-06-07 11:50:46 <TheSeven> http://dl.dropbox.com/u/23683845/bitcoin-bug-nonowned-addr-in-account/rpc-listaccounts-0.txt
 56 2012-06-07 11:50:47 <TheSeven> http://dl.dropbox.com/u/23683845/bitcoin-bug-nonowned-addr-in-account/rpc-listreceivedbyaddress-0-true.txt
 57 2012-06-07 11:50:53 <TheSeven> i think that's pretty much all you need
 58 2012-06-07 12:19:48 <Joric> http://www.extremetech.com/computing/125019-mac-botnet-grows-to-600000-274-of-them-in-cupertino
 59 2012-06-07 12:20:08 <Joric> a botnet of 600,000 infected macs discovered
 60 2012-06-07 12:21:15 <Joric> i wonder what about linux
 61 2012-06-07 12:28:17 <Eliel> Joric: linux is much less homogeneous than macs
 62 2012-06-07 12:28:40 <Eliel> that question would make sense if you wondered about an individual distribution
 63 2012-06-07 12:30:30 <Eliel> like Ubuntu or Fedora
 64 2012-06-07 12:32:00 <Eliel> however, you usually don't need to install software on linuxes through 3rd parties. That means the only danger is if someone compromises the distro's update system and uses that.
 65 2012-06-07 12:32:23 <Eliel> (the only danger for large scale infection, that is)
 66 2012-06-07 12:32:31 <TheSeven> oh, some popular software is distributed as directly downloaded deb packages
 67 2012-06-07 12:33:17 <TheSeven> just think the non-opensource versions of virtualbox or whatever
 68 2012-06-07 12:33:55 <TheSeven> which means you're going to run into the same issues with those apk downloads on android, which are already spreading quite a lot of malware
 69 2012-06-07 12:34:13 <Eliel> TheSeven: oh sure, but how large portion of the users install those, what do you think?
 70 2012-06-07 12:34:27 <TheSeven> I'd say more than on android
 71 2012-06-07 12:35:25 <TheSeven> or, to think of something more commonly installed: skype
 72 2012-06-07 12:35:50 <Eliel> oh yes, skype would be a potential malware vector.
 73 2012-06-07 12:36:12 <TheSeven> not only skype itself, but that distribution model in general
 74 2012-06-07 12:36:26 <TheSeven> if people trust skype, teamviewer and whatever there, why not some clever scareware distributor?
 75 2012-06-07 12:36:50 <TheSeven> social engineering will take care of that, as it has on the mac
 76 2012-06-07 12:38:10 <Eliel> the easiest way around this is to offer safe inter-distribution install methods for most of the stuff people want to install.
 77 2012-06-07 12:40:01 <Eliel> educating people to avoid installing stuff through other sources is not likely to work. People won't learn unless it bites them in their own behind if they don't.
 78 2012-06-07 12:42:06 <TheSeven> well, I'd be happy if most of that stuff would even be shipped as deb packages
 79 2012-06-07 12:42:21 <TheSeven> what I really hate is these shellscript-wrapped binary installers, like the one nvidia is using
 80 2012-06-07 12:42:39 <TheSeven> which you often just can't uninstall without lots of remnants
 81 2012-06-07 12:43:17 <TheSeven> IMO the easiest way to solve this in the long term is to implement some kind of application containment, like android is doing it
 82 2012-06-07 12:43:51 <Eliel> TheSeven: thankfully, most distros provide packaged versions of those.
 83 2012-06-07 12:44:31 <TheSeven> of that nvidia thing maybe, but lots of other software is distributed in similar ways without alternatives
 84 2012-06-07 12:46:38 <Eliel> most of those are fringe software though.
 85 2012-06-07 12:46:53 <Eliel> not used enough to interest malware creators
 86 2012-06-07 12:47:29 <TheSeven> yeah, I consider this more of an annoyance
 87 2012-06-07 12:47:36 <TheSeven> a malware creator would go for debian packages for sure
 88 2012-06-07 13:21:22 <ciscoftw> i know this question was answered a couple days ago, but i just cant believe there isnt any commands via bitcoind to give connected peer statistics... i mean a retard android app does it
 89 2012-06-07 13:22:55 <Joric> probably intentional, security/anonymity issues
 90 2012-06-07 13:23:16 <chmod755> ciscoftw: just add the commands you want....
 91 2012-06-07 13:23:24 <ciscoftw> oh is that all?
 92 2012-06-07 13:23:50 <ciscoftw> 'getpeerinfo' done. thannnnnnnnnks
 93 2012-06-07 13:24:19 <sipa> ciscoftw: i was actually planning on adding that soon
 94 2012-06-07 13:24:33 <ciscoftw> sipa: please man, that would be super awesome
 95 2012-06-07 13:26:15 <ciscoftw> the specific info that would be awesome is; connected peer ip, height, time, and client version
 96 2012-06-07 13:26:16 <Joric> it actually was the first thing i implemented in my bitcoinj-based client http://img196.imageshack.us/img196/8236/bitcointool201109290629.png
 97 2012-06-07 13:26:44 <sipa> ciscoftw: you don't actually know peer's height, only their advertized height at connection time
 98 2012-06-07 13:26:46 <Joric> though even bitcoinj doesn't have methods for that, the api is pretty restrictive
 99 2012-06-07 13:27:10 <sipa> ciscoftw: you can infer things from sent block invs though
100 2012-06-07 13:27:26 <ciscoftw> what dissector is being used for bitcoin traffic?
101 2012-06-07 13:27:50 <sipa> i know someone once wrote a wireshark plugin for bitcoin
102 2012-06-07 13:28:10 <ciscoftw> yeah, i cant get it to compile...
103 2012-06-07 13:28:41 <ciscoftw> figured it would be more heavily used by you guys... but sounds like its not very important
104 2012-06-07 13:32:29 <ciscoftw> http://i.qkme.me/366nwi.jpg
105 2012-06-07 13:32:58 <sipa> should i recognize that person?
106 2012-06-07 13:33:23 <ciscoftw> not if you dont watch US tv
107 2012-06-07 13:33:40 <sipa> good, i don't
108 2012-06-07 13:41:00 <micah> i'm trying to build bitcoin, but I am getting a compiler error: http://paste.debian.net/173316/ -- anyone have a clue?
109 2012-06-07 13:41:28 <sipa> micah: your version of db++ is too old
110 2012-06-07 13:42:15 <micah> sipa: what is the minimum version?
111 2012-06-07 13:42:27 <sipa> 4.7 or 4.8, i suppose
112 2012-06-07 13:42:42 <micah> hm, i am using libdb5.1++
113 2012-06-07 13:42:50 <sipa> huh
114 2012-06-07 13:42:52 <sipa> sure?
115 2012-06-07 13:43:12 <micah> hm, maybe not.
116 2012-06-07 13:43:14 <sipa> (as in: sure you don't have multiple versions installed, and it's picking an older one)
117 2012-06-07 13:43:27 <micah> i see now that it was compiled against libdb4.6++
118 2012-06-07 13:48:58 <graingert> we need a stanard wallet serialization
119 2012-06-07 13:49:02 <graingert> wallet.dat must die
120 2012-06-07 13:50:12 <sipa> we need a standard wallet interchange format - i disagree about a common wallet format
121 2012-06-07 13:50:21 <sipa> and yes, wallets in bdb must die
122 2012-06-07 13:51:53 <Joric> sipa, i don't like the 'sec' in the dumpwallet's json :) did you consider another naming?
123 2012-06-07 13:52:14 <sipa> what would you change it to?
124 2012-06-07 13:52:25 <Joric> hell knows
125 2012-06-07 13:52:41 <Joric> blockchain.info uses 'priv' for all formats
126 2012-06-07 13:52:52 <sipa> after deterministic wallets are done, i'll probably rework that dump thing
127 2012-06-07 13:54:17 <luke-jr> :p
128 2012-06-07 13:54:46 <luke-jr> I'm spending way too much time on this stuff anyway, so I'll just take a break ;)
129 2012-06-07 13:57:27 <Joric> sipa, regarding compressed privkeys, noticed signature has an id byte it uses +4 for compressed keys though it's maybe too late
130 2012-06-07 14:03:56 <someone42> is the satoshi client going to use BIP 0032 deterministic wallets?
131 2012-06-07 14:04:11 <TheSeven> why does bitcoin treat generation transactions specially in various transaction listings?
132 2012-06-07 14:04:30 <sipa> someone42: when i implement it :)
133 2012-06-07 14:04:33 <TheSeven> or rather why does it deny the fact that a generation transaction does have a destination address?
134 2012-06-07 14:05:05 <sipa> TheSeven: historical reason i guess; i believe luke submitted a pullreq to fix that
135 2012-06-07 14:14:03 <luke-jr> TheSeven: I have a pullreq out to fix that
136 2012-06-07 14:14:18 <luke-jr> oops, sipa already said that
137 2012-06-07 14:14:25 <sipa> Joric: yes?
138 2012-06-07 14:14:36 <luke-jr> TheSeven: https://github.com/bitcoin/bitcoin/pull/1409
139 2012-06-07 14:19:14 <Joric> sipa, first byte of the signature is 27 for uncompressed keys and 27+4 for compressed thought that could've been used in a key version aswell
140 2012-06-07 14:20:48 <Joric> guess discussing that is pretty pointless now
141 2012-06-07 14:22:00 <sipa> Joric: the reasoning for not doing that is that i felt that private keys and addresses are somehow related; since obviously addresses can't have a separate version byte when they are compressed, i didn't use the version byte to denote compressedness for secrets either
142 2012-06-07 14:22:26 <sipa> some have criticized it already; i doubt it's really a problem - people shouldn't be seeing those too often anyway
143 2012-06-07 15:25:04 <MrVisioN> hello, i was wondering... is there any way to set up a payment reference within a transaction?
144 2012-06-07 15:25:34 <MrVisioN> I mean, is there a way to add a string, or an int, or somehow a number to identify a transaction?
145 2012-06-07 15:26:20 <MrVisioN> User 1 sends 1 btc to a wallet and adds a payment reference. impossible?
146 2012-06-07 15:28:50 <weex> MrVisioN: you could have them send a unique amount
147 2012-06-07 15:29:19 <weex> other than that there's no comment field that will show up for the recipient
148 2012-06-07 15:29:47 <weex> the best way to id payments is by giving a unique address to each user
149 2012-06-07 15:29:51 <weex> or customer
150 2012-06-07 15:53:51 <MrVisioN> weex but that's the cheepest solution ever!!!
151 2012-06-07 15:54:11 <MrVisioN> for example in your website coindl
152 2012-06-07 15:55:22 <MrVisioN> there's a song which costs 0.003 btc, so whenever you want to send those btc to your main wallet you will loose 0.0005btc so you will have 0.003
153 2012-06-07 15:55:40 <MrVisioN> sorry
154 2012-06-07 15:55:46 <MrVisioN> you will have 0.0025 btc
155 2012-06-07 15:56:23 <MrVisioN> loosing a 16.666%
156 2012-06-07 15:57:04 <MrVisioN> i think the protocol needs to implement a field with an id
157 2012-06-07 15:57:21 <MrVisioN> for example, imagine i want to subscribe to a magazine
158 2012-06-07 15:57:27 <MrVisioN> i have to pay each month 1 btc
159 2012-06-07 15:57:48 <MrVisioN> maybe i want to remember the magazine's address in order to set up an autopayment
160 2012-06-07 15:58:23 <MrVisioN> so because i might change of wallet, the best way to identify the payment is with a reference number
161 2012-06-07 16:00:25 <helo> i don't think bitcoin is really intended to be used for micropayments
162 2012-06-07 16:02:18 <guruvan> satoshi certainly came to that realization
163 2012-06-07 16:05:10 <gruvfunk> greetings all, experiencing an oddity, I think
164 2012-06-07 16:05:52 <gruvfunk> sent btc to an address, took a long while to appear on blockchain.info, but it did, hit 3 confirmations with an estimated 3 minutes to finish
165 2012-06-07 16:06:18 <gruvfunk> but I refreshed and it turned to Unconfirmed Transaction! with Unknown/Never time to finish confirming
166 2012-06-07 16:06:29 <gruvfunk> should I be concerned?
167 2012-06-07 16:07:24 <luke-jr> MrVisioN: there is a way to send an email tied to the transaction, but it's not implemented  yet
168 2012-06-07 16:07:44 <luke-jr> MrVisioN: you're "supposed" to setup a receiving address per payer though
169 2012-06-07 16:13:47 <weex> also, for such a small transaction I wouldn't look at the fee as a percentage but a very minimal daily cost of doing business
170 2012-06-07 16:13:56 <weex> and yes I know MrVisioN is gone
171 2012-06-07 17:28:14 <Matt_von_Mises> OpenSSL dylibs do not work. Somehow it seems I have an outdated 32 bit version of OpenSSL when it was 64 bits before. No idea how that happpened. Ergh. Nightmare this is, I've hit a brick wall with my project.
172 2012-06-07 18:26:13 <BlueMatt> sipa: Im very disappointed you dont recognize the most interesting person in the world
173 2012-06-07 18:37:17 <sipa> BlueMatt: ?
174 2012-06-07 18:50:17 <BlueMatt> http://i.qkme.me/366nwi.jpg
175 2012-06-07 18:56:26 <sipa> ok, no idea :)
176 2012-06-07 18:58:14 <BlueMatt> (its a fairly poorly done, imho, ad for a beer where that guy is supposed to be the most interesting man in the world, and drinks this beer)
177 2012-06-07 18:59:06 <sipa> and who is it?
178 2012-06-07 19:00:09 <BlueMatt> just some random guy the ad campain works hard to keep under wraps: http://en.wikipedia.org/wiki/The_Most_Interesting_Man_in_the_World
179 2012-06-07 19:00:22 <BlueMatt> sorry, http://en.wikipedia.org/wiki/Jonathan_Goldsmith
180 2012-06-07 19:02:56 <BlueMatt> hey, IBD with -autoprune is faster
181 2012-06-07 19:03:12 <BlueMatt> (by a few seconds, but still)
182 2012-06-07 20:32:41 <avengre> does testnet3 qt client automatically solo mine?
183 2012-06-07 21:02:08 <RastaAssasin> can some shed some light on how new transactions are added to a block why is it that some transactions seem to get stuck even though they have fees attached while newer transactions get placed in a block? Is there a time when all transactions must be put into a block or they are discarded ? N.B. reason for asking I have a few satoshi dice transactions that have been waiting for over 16
184 2012-06-07 21:03:19 <gribble> New news from bitcoinrss: Diapolo opened issue 1430 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1430>
185 2012-06-07 21:06:31 <RastaAssasin> Any senior bitcoin experts here ?
186 2012-06-07 21:16:32 <BlueMatt> RastaAssasin: there are no rules, its up to individual miners
187 2012-06-07 21:17:12 <gmaxwell> RastaAssasin: you can't confirm a transaction without the ancestors also being confirmed (earlier or at the same time)
188 2012-06-07 21:17:13 <BlueMatt> (aside from the transaction has to be valid, ie not spend non-existent coins, have a valid signature, etc)
189 2012-06-07 21:17:21 <BlueMatt> oh, gmaxwell is around
190 2012-06-07 21:17:33 <gmaxwell> that blockchain spamming site you mentioned sometimes builds enormous chains of unconfirmed transactions.
191 2012-06-07 21:17:59 <gmaxwell> I have no idea why it does this, you should probably complain to its operator if its bothering you.
192 2012-06-07 21:18:34 <gmaxwell> Also, because they've been making confirmations slower for other bitcoin users, some miners may be handling them with lower priority regardless of the fees.
193 2012-06-07 21:18:59 <gmaxwell> BlueMatt: kinda here.
194 2012-06-07 21:23:12 <RastaAssasin> Oh thanks for the info
195 2012-06-07 21:23:58 <RastaAssasin> I thought about that and wondered iif that could b the situation where miners can choose not to include dice transactions
196 2012-06-07 21:24:05 <RastaAssasin> I though it was not possible
197 2012-06-07 21:24:19 <BlueMatt> miners gladly can (and I know some do)
198 2012-06-07 21:24:20 <RastaAssasin> i thought once the fee was there it had to be accepted
199 2012-06-07 21:24:27 <nanotube> <gmaxwell> that blockchain spamming site you mentioned <- haha very subtle. :)
200 2012-06-07 21:24:41 <BlueMatt> satoshi dice transactions are, after all, very, very spammy and kinda suck for most bitcoin users
201 2012-06-07 21:25:24 <RastaAssasin> but the bitcoin network should be resilient enough to cope with transactions of that nature
202 2012-06-07 21:25:40 <nanotube> and it is coping just fine
203 2012-06-07 21:25:42 <BlueMatt> it copes with them fine, but that doesnt mean it doesnt suck for its users
204 2012-06-07 21:25:52 <RastaAssasin> :) i get you
205 2012-06-07 21:26:02 <BlueMatt> take a look at your datadir, its 2g, and a huge chunk of that is /just/ satoshidice
206 2012-06-07 21:26:18 <BlueMatt> it also takes significantly longer to download the blockchain
207 2012-06-07 21:26:30 <BlueMatt> like hugely significant, not just a % but huge
208 2012-06-07 21:26:32 <gmaxwell> RastaAssasin: it copes with it fine, but that doesn't make it a good thing.
209 2012-06-07 21:26:35 <RastaAssasin> But at the end of the day all the transactions will get in a block as long as the previous inputs are confirmed
210 2012-06-07 21:26:47 <guruvan> it's kind of gotten to a point wher it might be nice to have the client easily able to send coin from a specific address, so that one might "preconfirm availability of funds" before sending or receiving payments - to avild getting caught waiting for a transaction based on a dice transaction to clear
211 2012-06-07 21:27:16 <gmaxwell> RastaAssasin: no guarantee of that... they could be delayed forever, especially if the involved parties stop broadcasting them.
212 2012-06-07 21:27:37 <gmaxwell> I suspect that if that site gets doublespent that it will wedge them.
213 2012-06-07 21:28:53 <RastaAssasin> now i'm starting to get scared of playing that spammy site's game
214 2012-06-07 21:31:40 <RastaAssasin> ok another question, usually i would see the unconfirmed coins show up in the wallet but now a transaction was sent to me and i see it in blockchain but i dont see it in my client any at all how is that ? im speaking of this particualr transaction http://blockchain.info/tx-index/8129067/6eefa00402519cbd3a7551a3180ecdb28b635e97230026e4d53d7be5f7987937
215 2012-06-07 21:35:55 <RastaAssasin> gmaxwell what do you think of that ?
216 2012-06-07 21:38:43 <xorgate> so i hadn't fired up the bitcoin-qt app for a while, and now it's resyncing. as far as i can see it's just downloading, but using a lot of cpu time, why?
217 2012-06-07 21:41:34 <TuxBlackEdo> RastaAssasin, some transactions take a bit of time to confirm
218 2012-06-07 21:44:20 <BlueMatt> xorgate: its checking blocks, contrary to (somewhat) popular belief, bitcoin's chain sync is limited almost entirely by disk and cpu, not bandwidth or peer bandwidth
219 2012-06-07 21:44:28 <BlueMatt> specifically, cpu checking signatures
220 2012-06-07 21:44:36 <gmaxwell> RastaAssasin: is your client up to date with the chain and have you been swapping wallet files?
221 2012-06-07 21:46:06 <RastaAssasin> client is up to date and yes i swap wallets sometimes
222 2012-06-07 21:46:08 <BlueMatt> RastaAssasin: note the tx you linked is unconfirmed, so its not in the blockchain, also note that some people dont forward satoshidice transactions, and that your transaction may simply be slow propagating through the network
223 2012-06-07 21:47:29 <RastaAssasin> oh ok, i'm just hoping this doesnt get lost in the system
224 2012-06-07 21:48:02 <xorgate> BlueMatt fair enough, thanks
225 2012-06-07 21:49:26 <BlueMatt> RastaAssasin: thats very unlikely, but considering satoshidice's practices, its likely that your transaction may take some time to confirm
226 2012-06-07 21:49:35 <RastaAssasin> How would you determin which pools are ignoring dice transactions ?
227 2012-06-07 21:50:02 <BlueMatt> afaik no major pools are currently
228 2012-06-07 21:50:26 <RastaAssasin> no major pools are accepting ?
229 2012-06-07 21:50:39 <BlueMatt> ignoring
230 2012-06-07 21:51:08 <xorgate> what's the motivation behind not forwarding satoshidice tx ?
231 2012-06-07 21:51:16 <RastaAssasin> oh wheew...
232 2012-06-07 21:51:29 <amtran> they think they can hash faster by ignoring tx
233 2012-06-07 21:51:40 <BlueMatt> amtran: that is 110% not true
234 2012-06-07 21:51:56 <BlueMatt> xorgate: the transactions spend disk space and bandwidth of every bitcoin user
235 2012-06-07 21:52:04 <BlueMatt> (and there are a /ton/ of them)
236 2012-06-07 21:52:06 <gmaxwell> xorgate: not wanting the bitcoin blockchain to grow hundreds of megs a month purely due to wasteful churn from some inefficiently implemented gambling site instead of broader actual usage, with resulting slowdowns for serious transactions where confirmations are actually needed.
237 2012-06-07 21:52:42 <BlueMatt> amtran: satoshi designed the system very specifically so that accepting transactions or rejecting them costs miners nothing on top of standard mining costs
238 2012-06-07 21:53:02 <BlueMatt> amtran: and no pool op doesnt get that
239 2012-06-07 21:53:05 <amtran> yeah but that doesnt mean the vast majority of miners are as intelligent as satoshi
240 2012-06-07 21:53:22 <BlueMatt> (sorry, misread your comment) but still, most pool ops are not stupid
241 2012-06-07 21:53:51 <xorgate> so to be clear, forwarding != 'including the tx in the block youre trying to find' ?
242 2012-06-07 21:54:26 <amtran> xorgate: yes
243 2012-06-07 21:54:33 <BlueMatt> botnet controlling and virus-writing people likely are, but there is little evidence that plays a significant role in bitcoin mining power (though it obviously plays some role)
244 2012-06-07 21:54:44 <BlueMatt> xorgate: every node forwards, not every node mines
245 2012-06-07 21:55:35 <xorgate> BlueMatt ok but some clients say 'this tx goes to 1dicexxxxxx, let me just not send it to others' ?
246 2012-06-07 21:55:43 <BlueMatt> yes
247 2012-06-07 21:56:13 <amtran> ok i have a question if youre such a clever guy why are you playing satoshis dice
248 2012-06-07 21:56:14 <BlueMatt> more generally, some people dont forward transactions that go to/from very heavyily used addresses
249 2012-06-07 21:56:24 <xorgate> how does a client find peers?
250 2012-06-07 21:56:51 <amtran> oh nevermind that was "rastaassassin" that started this discussion
251 2012-06-07 21:57:12 <RastaAssasin> gmaxwell the previous comment about maybe being stuck forever if involved parties stop broadcasting, who specifically would have to stop broadcasting? I dont fully understand the broadcast system if it gets sent out through say 20 nodes as long as one of those nodes stays online the transaction will stand a chance of getting added ?
252 2012-06-07 21:57:15 <BlueMatt> similar to any other p2p network, peers exchange addresses with each other, bootstrap by asking well-known servers for a list of peers
253 2012-06-07 21:57:58 <xorgate> oh wait i forgot there's also the irc chan i think? but it could happen that your peers are all in on this 'not including sathoshidice' and then you're somewhat screwed
254 2012-06-07 21:58:12 <xorgate> i mean the peers you decide to connect to
255 2012-06-07 21:58:15 <gmaxwell> RastaAssasin: the sender/recipents of txns will keep reannouncing them while they aren't mined... unless they go away.
256 2012-06-07 21:58:18 <BlueMatt> the irc chan is now disabled by default
257 2012-06-07 21:58:22 <amtran> i dont think peers are still sent through irc
258 2012-06-07 21:59:34 <RastaAssasin> oh i c how that could be a problem now
259 2012-06-07 21:59:53 <sipa> irc is disabled by default since 0.6.0
260 2012-06-07 22:01:18 <amtran> does artforz come here or gavin
261 2012-06-07 22:01:36 <sipa> gavin comes here frequently
262 2012-06-07 22:01:46 <sipa> haven't seen artforz in like a year
263 2012-06-07 22:02:20 <xorgate> i'm having some trouble understanding why people would care about satoshidice.. they want bitcoin to succeed so why try to drop (delay is more like it?) transactions, that would just make the system weaker
264 2012-06-07 22:02:34 <amtran> i want to talk about GetNextWorkRequired with someone
265 2012-06-07 22:03:03 <amtran> shit like satoshis dice makes bitcoin weaker
266 2012-06-07 22:03:12 <sipa> maybe
267 2012-06-07 22:03:13 <gmaxwell> xorgate: because the uncontrolled flood of transactions from that site are delaying transactions for other users who actually need confirmations to be secure against reversal.
268 2012-06-07 22:03:14 <amtran> ^^ personal opinion
269 2012-06-07 22:03:59 <xorgate> gmaxwell how does this delay come about? afaik it matters not how many tx in a block, right?
270 2012-06-07 22:04:03 <gmaxwell> It alo increases the operating cost of bitcoin relative to its real economic activity and userbase size.
271 2012-06-07 22:04:05 <Quaix> so can bitcoin handle all the traffic is it becomes 10x as popular? If just one site can have an adverse effect...
272 2012-06-07 22:04:23 <sipa> Quaix: normal growth is not a problem
273 2012-06-07 22:04:54 <gmaxwell> xorgate: What "matters not"?
274 2012-06-07 22:05:20 <sipa> if bitcoin becomes more resource intensive because of increased usage, people will adapt
275 2012-06-07 22:05:58 <sipa> but increased resources without increased usefulness of the economic platform it provides may be problematic
276 2012-06-07 22:06:11 <sipa> i am unsure for now how to classify satoshidice
277 2012-06-07 22:06:29 <xorgate> gmaxwell i mean, what's the difference between a block with 1 tx and one with 100? a miner can just include them without affecting the mining operation
278 2012-06-07 22:06:42 <sipa> xorgate: blocks have a limited size
279 2012-06-07 22:06:43 <gmaxwell> Increased usage brings its own benefits along with its costs. Increased load without those benefits just discourages more real use of the system. My own opinion of satoshidice is strongly negative imply because it is enormously inefficient compared to the next technical alternative.
280 2012-06-07 22:07:19 <amtran> satoshis dice user : "so you mean i can buy weed on bitcoin without having to leave the house?"
281 2012-06-07 22:07:26 <xorgate> sipa that... sounds like a flaw (?)
282 2012-06-07 22:07:41 <gmaxwell> xorgate: it makes the block substantially larger, which means more storage and computational cost for all participating users. And as sipa says, blocks have a maximum size, otherwise some trouble maker could have just made bitcoin unusuable two years ago before it had much usage.
283 2012-06-07 22:08:28 <xorgate> is the size of a block proportional to the amount of tx? meaning a block has a max amount of tx possible?
284 2012-06-07 22:09:06 <Eliel> xorgate: it's a limit that will be increased in an update someday.
285 2012-06-07 22:09:11 <Eliel> when necessary
286 2012-06-07 22:09:23 <xorgate> sounds like it's necessary now :)
287 2012-06-07 22:09:33 <gmaxwell> xorgate: no. It's absolutely not.
288 2012-06-07 22:09:57 <xorgate> idunno i understand why one would feel negative, but on the other hand it's just another use of the system
289 2012-06-07 22:10:31 <gmaxwell> Right now the blockchain can grow at a rate of 52gbytes/year. Do you really want a 54GByte blockchain a year from now while bitcoin has the same level of users that it has now?
290 2012-06-07 22:11:11 <amtran> sounds like bitcoin is going to have to go DHT eventually
291 2012-06-07 22:11:18 <gmaxwell> ...
292 2012-06-07 22:11:25 <RastaAssasin> i understand the point that the dice increase the network load and storage but, on the other hand i think it also brings in new users and fresh money into the system which is needed for bitcoin to flourish so i would not bash it any at all more like support it
293 2012-06-07 22:11:29 <luke-jr> LOLOL
294 2012-06-07 22:11:40 <luke-jr> gmaxwell: we need a bot that silences on "DHT"
295 2012-06-07 22:12:02 <gmaxwell> RastaAssasin: there are _lots_ of gambling sites.. All others work without producing new transactions for every trivial play.
296 2012-06-07 22:12:35 <luke-jr> RastaAssasin: Dice is AFAIK illegal
297 2012-06-07 22:12:51 <luke-jr> so, it brings the wrong kind of users/money
298 2012-06-07 22:13:14 <gmaxwell> luke-jr: at least here it's a pretty excellent metric for people who are contributing buzzwords instead of insight.
299 2012-06-07 22:13:55 <amtran> luke-jr: bitcoin 2.0 won't hash using a cryptographic function (like SHA256). put that in your pipe :) and it will use a DHT
300 2012-06-07 22:14:46 <gmaxwell> amtran: DHT's don't don anything really useful in the context of what we do. Nor are any particularly attack resistant, even if they did.
301 2012-06-07 22:14:47 <luke-jr> amtran: &
302 2012-06-07 22:14:50 <wizkidO57> anyone had a chance to check into the issue i submitted about sendrawtx?
303 2012-06-07 22:15:02 <luke-jr> gmaxwell: correct me if I'm wrong, but isn't hashing inherently cryptographical?
304 2012-06-07 22:15:07 <amtran> you'll see!!!
305 2012-06-07 22:15:24 <gmaxwell> amtran: and luke's comment was because I've long griped about clueless people claiming DHT's are the solution to every problem that sounds remotely like a distributed computing problem.
306 2012-06-07 22:15:47 <gmaxwell> So it's sort of funny now whenever someone shows up and says "Use a DHT!!"
307 2012-06-07 22:16:46 <wizkidO57> wouldnt that be pretty insecure for something like this?
308 2012-06-07 22:17:07 <Eliel> it very much would.
309 2012-06-07 22:17:21 <phantomcircuit> wizkidO57, no but it would be slow as all hell
310 2012-06-07 22:18:19 <amtran> well when you're talking about exponential growth of a distributed file system (the origin of bitcoin) it would seem DHT is a pretty good solution
311 2012-06-07 22:18:56 <wizkidO57> phantomcircuit: already takes days to download the blockchain, so, why not make everything slow? :P
312 2012-06-07 22:20:04 <Eliel> phantomcircuit: it'd make individual reads slow but you could do them all at once :P
313 2012-06-07 22:20:33 <phantomcircuit> Eliel, actually because the blockchian is a linked list you cant
314 2012-06-07 22:20:58 <xorgate> ok so, sounds like there's a proposal to increase max blocksize. But doing so does not fix any structural issues, just give some breathing room. Correct?
315 2012-06-07 22:21:24 <amtran> no because the issue is the clients forwarding cleartext transactions not hashing
316 2012-06-07 22:21:37 <Eliel> phantomcircuit: that depends a lot on what data the nodes keep locally.
317 2012-06-07 22:21:38 <wizkidO57> phantomcircuit: well, theres the problem. Obviously the solution is to make the blockchain not be a linked list, then use a distributed hash table...
318 2012-06-07 22:22:23 <phantomcircuit> wizkidO57, it's core to the algorithm that makes bitcoin secure...
319 2012-06-07 22:22:43 <wizkidO57> :)
320 2012-06-07 22:22:54 <hnz> and use one of these modern nosql-databases like couchdb instead of bdb?
321 2012-06-07 22:23:02 <wizkidO57> i was being facetious
322 2012-06-07 22:23:13 <wizkidO57> hehe
323 2012-06-07 22:23:15 <hnz> rot13 may also be faster than sha256.
324 2012-06-07 22:23:30 <wizkidO57> oh sweet, rot13
325 2012-06-07 22:23:32 <wizkidO57> +1
326 2012-06-07 22:23:56 <hnz> wizkidO57: rot14? ;)
327 2012-06-07 22:24:18 <Eliel> it's a good thing the speed of the hashing algorithm is almost meaningless then :)
328 2012-06-07 22:24:22 <amtran> after a certain number of confirmations does it really matter what hashing function you use...
329 2012-06-07 22:24:58 <wizkidO57> hnz: :D
330 2012-06-07 22:25:00 <Eliel> no, the hash algo is not important, other than that you can't easily reverse it.
331 2012-06-07 22:25:14 <amtran> i guess bitcoin isn't so much of an innovation in cryptography as people make it out to be ...
332 2012-06-07 22:25:39 <hnz> amtran: the innovation is that someone put all the pieces together to create what is now bitcoin
333 2012-06-07 22:26:01 <amtran> yeah but your joke about rot13 isn't a joke at all. why not use rot13
334 2012-06-07 22:26:20 <Eliel> amtran: rot13 is reversible
335 2012-06-07 22:26:22 <wizkidO57> its not really a hash...
336 2012-06-07 22:26:27 <Eliel> and not a hash either :P
337 2012-06-07 22:26:31 <amtran> cryptograhpicly secure hashing function is irrelevant to the function of bitcoin
338 2012-06-07 22:26:55 <wizkidO57> amtran: make an alt chain that uses rot13 :P
339 2012-06-07 22:26:59 <Eliel> amtran: no it's not. it's very much required feature of the hashing function
340 2012-06-07 22:27:26 <Eliel> bitcoin can't work with a hashing function that can be reversed easily.
341 2012-06-07 22:27:44 <wizkidO57> oh wow, just realized i'm on the wrong nick
342 2012-06-07 22:28:08 <amtran> reversing the function must be computationally difficult but there is no requirement that it be cryptographically secure
343 2012-06-07 22:28:23 <hnz> amtran: for the integrity of the blockchain you need some way to prove, that the old parts are part of the chain. this is done using crypthographically secure hashes
344 2012-06-07 22:28:52 <amtran> isnt that what the dsa is for
345 2012-06-07 22:29:15 <Eliel> amtran: with dsa, you need centralized trust.
346 2012-06-07 22:29:21 <wizkid057> the blocks themselves are secured only by SHA256 and a target
347 2012-06-07 22:30:52 <Eliel> amtran: with cryptographic hash functions and mining, you can trust that it's damn expensive to falsify history.
348 2012-06-07 22:30:56 <gmaxwell> amtran> well when you're talking about exponential growth < bitcoin's growth is strictly linear.
349 2012-06-07 22:31:43 <hnz_> amtran: you call hash functions with the property that it is quite easy to hash but very hard to reverse it (and to find another value which hashes to the same hash) cryptographic hash function. it is just the name for this property.
350 2012-06-07 22:31:43 <wizkid057> using my $100,000,000 cluster
351 2012-06-07 22:31:48 <wizkid057> lol
352 2012-06-07 22:33:00 <amtran> once the transaction is confirmed on the block chain the hashing algorithm doesnt matter
353 2012-06-07 22:33:18 <hnz_> amtran: you could use dsa, but it is more complicated. you need a key for that. if you only need hashing you don't use a signature algorithm because a hashing algorithm is easier and faster.
354 2012-06-07 22:35:07 <hnz> amtran: if i start at the beginning i trust the genesis block because it is in the client. to trust block 2 i first need to know that it depends on block 1. so it needs at least a hash of block 1
355 2012-06-07 22:35:14 <hnz> the network here sucks :/
356 2012-06-07 22:36:18 <amtran> http://en.wikipedia.org/wiki/List_of_hash_functions#Non-cryptographic_hash_functions
357 2012-06-07 22:37:24 <amtran> http://google-opensource.blogspot.com/2011/04/introducing-cityhash.html
358 2012-06-07 22:41:17 <Eliel> amtran: I don't think you're quite understanding what the cryptographic hash function feature is needed for. If we don't have that, It'll be way too easy to find hash collisions and that will basically make the whole system untrustworthy for anything.
359 2012-06-07 22:41:50 <amtran> if its stored in a dht how will there be collisions
360 2012-06-07 22:42:07 <amtran> the hash function is only a proof of work
361 2012-06-07 22:43:09 <Eliel> dht is completely irrelevant here. What is relevant is that if the hash is not cryptographically secure, anyone can create a block that has the same hash as earlier block but with different transaction data.
362 2012-06-07 22:43:28 <amtran> and those blocks will be rejected
363 2012-06-07 22:43:52 <Eliel> by the existing network, sure. But how will new nodes decide?
364 2012-06-07 22:44:19 <Eliel> also, how will you tell the two versions apart? they have the same hash
365 2012-06-07 22:44:45 <Eliel> in a DHT, you have to ask by hash
366 2012-06-07 22:44:59 <amtran> but thats different than the proof of work
367 2012-06-07 22:45:16 <amtran> the proof of work only has to survive through a few confirmations
368 2012-06-07 22:45:32 <Eliel> it ceases to be a proof of work if you can forge it.
369 2012-06-07 22:45:33 <amtran> and then its pretty irrelevant (not in bitcoin as it is today)
370 2012-06-07 22:45:33 <graingert> would there be any use in the block chain for "transactions seen"
371 2012-06-07 22:45:50 <graingert> eg tx that have not been checked
372 2012-06-07 22:45:52 <graingert> just seen
373 2012-06-07 22:45:57 <amtran> but bitcoin 2.0 this will be true
374 2012-06-07 22:46:49 <Eliel> amtran, anyway, I need some sleep. I don't know if you're trolling or if you really are too thickheaded to get it.
375 2012-06-07 22:46:59 <Eliel> so, I give up
376 2012-06-07 22:47:15 <amtran> ok me too :)