1 2012-08-10 00:01:02 <forrestv> sipa, any idea why?
  2 2012-08-10 00:01:16 <forrestv> satoshidice with 1 satoshi? q:
  3 2012-08-10 00:12:29 <Diablo-D3> hey gmaxwell
  4 2012-08-10 00:12:31 <Diablo-D3> hey sipa
  5 2012-08-10 00:12:37 <Diablo-D3> I have invented a new term
  6 2012-08-10 00:12:40 <Diablo-D3> because of blizzard
  7 2012-08-10 00:12:46 <Diablo-D3> "low sodium encryption"
  8 2012-08-10 00:13:28 <abracadabra> sodium chloride?
  9 2012-08-10 00:13:51 <Diablo-D3> salt.
 10 2012-08-10 00:14:14 <abracadabra> ;)
 11 2012-08-10 00:16:04 <Ferroh> um..
 12 2012-08-10 00:16:21 <Ferroh> in blockchain.info's wallet_api, you just send the username and password as GET vars? :/
 13 2012-08-10 00:16:22 <Ferroh> http://blockchain.info/mywallet_api
 14 2012-08-10 00:17:45 <Ferroh> I guess it's not necessarily insecure since it's via SSL
 15 2012-08-10 00:17:54 <Ferroh> but it's a pretty lame design imo
 16 2012-08-10 00:19:28 <Ferroh> I could see someone testing that by writing out a URL that includes their password
 17 2012-08-10 00:19:41 <Ferroh> and now their password is cached in the browser history
 18 2012-08-10 00:19:58 <Ferroh> also the server is going to log that request
 19 2012-08-10 00:20:02 <Ferroh> ...in plaintext
 20 2012-08-10 00:20:18 <Diablo-D3> Ferroh: are you shitting me?
 21 2012-08-10 00:20:55 <Ferroh> am I saying something wrong, or are you as surprised that he authenticates with GET vars?
 22 2012-08-10 00:22:08 <Diablo-D3> yes
 23 2012-08-10 00:22:55 <Ferroh> oh, which part did I get wrong?
 24 2012-08-10 00:23:14 <Ferroh> the "not necessarily insecure" part? :)
 25 2012-08-10 00:23:57 <luke-jr> "For the moment it requires sharing your wallet password and second password, this will requirement will be removed in future."
 26 2012-08-10 00:24:19 <Ferroh> ergh, yeah there's also that
 27 2012-08-10 00:24:31 <Diablo-D3> Ferroh: sorry, yes and yes in that order
 28 2012-08-10 02:04:22 <derpingtonIII> Has anyone thought about integrating a bitcoin wallet with a browser, so that people can do one click payments?
 29 2012-08-10 02:06:13 <weex> derpingtonIII: i believe there's a firefox addon out there but it's not really an idea i like much
 30 2012-08-10 02:06:26 <weex> using a mobile wallet is kind of nice though...just don't keep too much funds there
 31 2012-08-10 02:09:51 <luke-jr> derpingtonIII: it's already done, more or less
 32 2012-08-10 02:10:19 <derpingtonIII> lukejr where would I find it?
 33 2012-08-10 02:10:23 <luke-jr> derpingtonIII: just Bitcoin-Qt's implementation is buggy, so it was disabled in 0.6
 34 2012-08-10 02:10:30 <luke-jr> derpingtonIII: it'll probably be fixed for 0.7
 35 2012-08-10 02:10:58 <derpingtonIII> ah.
 36 2012-08-10 03:10:51 <gmaxwell> 19:01 < forrestv> satoshidice with 1 satoshi? q:
 37 2012-08-10 03:11:05 <gmaxwell> ^ yes, every losing transaction results in a 1 satoshi output.
 38 2012-08-10 03:11:37 <gmaxwell> Which, of course, doesn't get spent.
 39 2012-08-10 03:11:43 <forrestv> ah :/
 40 2012-08-10 03:11:53 <luke-jr> gmaxwell: why not?
 41 2012-08-10 03:12:17 <luke-jr> I've spent 1-satoshi outputs before!
 42 2012-08-10 03:12:40 <Gladamas_> the 1-satoshi tx is just to verify that it was a loss, without visiting the site
 43 2012-08-10 03:12:44 <gmaxwell> luke-jr: because the solver will pretty much never pick a very tiny input unless it happens to exactly fit what you need.. and who makes payments of x.xxxxxxx[^0] btc?
 44 2012-08-10 03:13:22 <luke-jr> gmaxwell: it does it for me <.<
 45 2012-08-10 03:13:30 <forrestv> has any thought been given to changing the solver to prefer to consolidate inputs?
 46 2012-08-10 03:13:51 <luke-jr> forrestv: perhaps the miner rules should do that too
 47 2012-08-10 03:14:40 <gmaxwell> forrestv: Well, a while back I did some code that post processed the decision so add extra inputs in when there was room (before going to the next fee level)... but it created a lot of address linkages bad for privacy.
 48 2012-08-10 03:15:01 <forrestv> luke-jr, what do you mean by that? give consolidating transactions higher priority..?
 49 2012-08-10 03:15:03 <gmaxwell> (in theory it would be good for privacy by better disguising the change output, but it practice it didn't seem like it was)
 50 2012-08-10 03:15:29 <luke-jr> forrestv: possibly; but it might encourage splitting up if not thought out well
 51 2012-08-10 03:16:31 <forrestv> hm.. ideally we'd have some sort of scripting language that miners publish in blocks that describes their fee policy (to handle complex things like this)
 52 2012-08-10 03:16:58 <forrestv> and clients could examine those and give the human estimates of the expected time-to-confirm for different fee choices :)
 53 2012-08-10 03:17:28 <forrestv> otherwise, choices like that don't really affect anything
 54 2012-08-10 03:21:57 <luke-jr> forrestv: well, gmaxwell had a genius idea for autodetecting it
 55 2012-08-10 03:22:15 <luke-jr> watch the transactions that don't get into blocks, and see what the insufficient fees are like
 56 2012-08-10 03:24:23 <forrestv> i guess that works, but you have to guess why they're being rejected. if miners only take size into account, that's simple, but otherwise...
 57 2012-08-10 03:26:52 <gmaxwell> forrestv: Right, it's a slick method but it only really solves for one unknown. (The lambda for fee vs badness, but not the weights for badness)
 58 2012-08-10 03:28:29 <gmaxwell> forrestv: I'd before been suggesting that priority go from  sum(age*value)/size to  sum(age*value)/(2*size-input_size)  (or similar, with whatever scaling gets it to largely agree with the current typical usage.
 59 2012-08-10 03:28:51 <gmaxwell> But it introduces more magic behavior and needs some clamps in order to not get weird results.
 60 2012-08-10 03:36:24 <iisword> what about making a custom client that redirecting the transaction at a specialized mining pool that focused on consolidating transactions to help the network and require the owners of those transactions to mine some or pay a transaction fee. If the pool didn't have enough transactions, it would look at lower priority first and would use the 50 BTC from solving to increase hashing and/or pay miners.
 61 2012-08-10 04:10:15 <gmaxwell> iisword: I'm not sure what problem you're trying to address there.
 62 2012-08-10 04:11:09 <gmaxwell> My bigger concern is that users will bankrupt themselves gambling and have wallets with thousnds of 1e-8 outputs but no value, then just delete them... and we'll never be able to clear out those txouts. Not the end of the world, but it would be unfortunate.
 63 2012-08-10 04:13:53 <amiller> if there's not a way to reclaim old unspent txouts then there's clearly a divergent behavior rather than a stabilizing one
 64 2012-08-10 04:13:55 <amiller> zooko basically convinced me of that
 65 2012-08-10 04:14:21 <midnightmagic> gmaxwell: it would be nice to help deepbit and p2pool users to spend their bits-at-a-time earnings without paying ridiculoud fees.
 66 2012-08-10 04:14:22 <amiller> that's another one of those basic ideas that gets repeated in various ways over and over isn't it
 67 2012-08-10 04:15:03 <midnightmagic> zooko doesn't think reallocating old unspent tx is a solution anymore, last I spoke with him.
 68 2012-08-10 04:15:23 <amiller> hmm, surprising to me.
 69 2012-08-10 04:15:54 <gmaxwell> amiller: most of the people who complain about that do so for the wrong reasons. Besides they _will_ go unspendable at some point, after the system upgrades cryptosystems.
 70 2012-08-10 04:16:36 <midnightmagic> the issue is probably a human one: we all signed on with the rules as they are; some of us have built systems which can't actually reveal wallet keys for years, or decades. if the system changes so that money goes away without being spent, part of the expected value also disappears to long-term storage'rs.
 71 2012-08-10 04:16:49 <amiller> i believe that, but that's even better reason to give the problem a name and aggregate all the details about it
 72 2012-08-10 04:17:41 <midnightmagic> broken cryptosystems being a necessary exception of course.
 73 2012-08-10 04:17:44 <amiller> upgrading cryptosystems isn't part of the protocol so my point about divergence stands
 74 2012-08-10 04:17:46 <gmaxwell> midnightmagic: right, I think we can only solve that through a cryptosystem upgrade, as ~everyone will agree that zombie coins returning to ecdsa crackers will be worse than losing some coins that can't be spent in the following decade or whatever.
 75 2012-08-10 04:18:54 <midnightmagic> sorry, you're postulating an ecdsa crack of some sort as a prerequisite to a cryptosystem upgrade, correct?
 76 2012-08-10 04:19:22 <gmaxwell> midnightmagic: or at least the appearence of one on the horizon.
 77 2012-08-10 04:20:25 <gmaxwell> amiller: In any case, you realize that miners could actually prune their unspent txout trees too so long as they were always guerenteed to be able to fetch copies of them from nodes spending them or giving them blocks spending them.
 78 2012-08-10 04:20:35 <gmaxwell> (This works in the current protocol, it's just not the current norm)
 79 2012-08-10 04:21:01 <gmaxwell> So at least all txouts could, in theory, be compressed to the space they take up in the tree.
 80 2012-08-10 04:21:58 <amiller> yeah those are my assumptions already; still it's space in the tree, that's the resource we're basically competing over
 81 2012-08-10 04:22:05 <amiller> anyway i don't meant to actually discuss it now
 82 2012-08-10 04:22:26 <amiller> "iisword: I'm not sure what problem you're trying to address there." <--- my point was that you know what problem it's addressing because it's recognizable and it's been discussed before
 83 2012-08-10 04:22:49 <gmaxwell> amiller: no, you totally misunderstood that.
 84 2012-08-10 04:23:02 <amiller> consolidating transac...... yeah nvm i think i did
 85 2012-08-10 04:23:05 <gmaxwell> I was just talking about wanting to avoid txout bloat above. I'm fine with that.
 86 2012-08-10 04:23:31 <gmaxwell> But I don't reconize any of the things iisword listed off helping to achieve that.
 87 2012-08-10 04:23:57 <gmaxwell> (AFAIK there isn't any mining pool component to the issue there)
 88 2012-08-10 04:24:16 <midnightmagic> amiller: by divergent, you are saying that value diverges due to old unspent txn (potentially coming back and wreaking havoc on stability) or you're saying what the 28c3 presentations said: eventually all useful amounts of bitcoins will be lost or destroyed?
 89 2012-08-10 04:24:49 <gmaxwell> The latter bit is what I was referring to when I said "most of the people who complain about that do so for the wrong reasons"
 90 2012-08-10 04:25:38 <gmaxwell> midnightmagic: I think amiller was just saying it makes bitcoin non-scalable. The size diverges (becomes progressively larger) over time, independant of current usage.
 91 2012-08-10 04:25:53 <amiller> yeah that one
 92 2012-08-10 04:26:20 <amiller> at least with regard to the active state
 93 2012-08-10 04:26:33 <gmaxwell> I did figuring out this before and basically decided it was irrelevant. The growth under reasonable assumptions is so slow.
 94 2012-08-10 04:27:42 <gmaxwell> So long as you postulate any contined decrease in storage costs it should be no worst than constant in terms of cost, even if it's perpetually growing in terms of size.
 95 2012-08-10 04:27:57 <midnightmagic> I'm confident waiting 10 minutes to get a single confirmation will irritate people enough that another instant mechanism of transacting will rise and replace bitcoin for smaller txn values.
 96 2012-08-10 04:27:58 <gmaxwell> But I do generally agree that making it better is better.
 97 2012-08-10 04:28:27 <amiller> i'm of the opinion that any strategy effectively involves paying rent on the storage consumed by utxo in the database
 98 2012-08-10 04:28:43 <amiller> it doesn't have to be much, and it certainly doesn't have to be proportional to the amount of btc, just the amount of resource taken up in the tree
 99 2012-08-10 04:28:57 <midnightmagic> utxo heh heh
100 2012-08-10 04:29:29 <midnightmagic> Feel like I'm reading Lewis Carroll..
101 2012-08-10 04:30:18 <gmaxwell> s/10 minutes/30 minutes every 4 hours, 60 minutes every few days/
102 2012-08-10 04:30:25 <amiller> in that view, it's really (bit*bit)coin
103 2012-08-10 04:30:39 <amiller> bit is a pun, since bit can mean a bit of storage in the active-state, but it can also mean a bit of difficulty, which is how time is measured
104 2012-08-10 04:30:40 <midnightmagic> Are you the one that "discovered" that pun the other day?
105 2012-08-10 04:30:48 <amiller> yeah i think so
106 2012-08-10 04:31:45 <gmaxwell> amiller: you could simply cap the horizon, then the fees related to respending txn are how you pay rent.
107 2012-08-10 04:31:47 <BTC_Bear> Butt in: Attrition if it follows physical rates would about 1%-10% (depending), without the ability to 'print' more money, it will collapse. We can't print more. So, you change currencies with a paralleling chain over a period of years. After the transfer the first chain is dropped. Not sure, but the client would need to handle two 'authorized' chains. Then drop one after say 5 years. Rinse and Repeat as needed. Just a lay opinion.
108 2012-08-10 04:32:06 <gmaxwell> BTC_Bear: Welcome to failing, you're in good company.
109 2012-08-10 04:32:12 <midnightmagic> BTC_Bear: Or you just increase divisional precision.
110 2012-08-10 04:32:15 <gmaxwell> ^ That.
111 2012-08-10 04:32:33 <amiller> gmaxwell, the point is the rent on a txo is a different quantity than the fee in a txn
112 2012-08-10 04:32:47 <amiller> because a transaction occurs once and is complete, but a utxo stays until another transaction occurs
113 2012-08-10 04:32:53 <BTC_Bear> Sorry, I disagree with increasing divisional precision. For reasons, I stated in the forum.
114 2012-08-10 04:33:02 <midnightmagic> BTC_Bear: Link?
115 2012-08-10 04:33:03 <gmaxwell> BTC_Bear: sorry for you.
116 2012-08-10 04:33:19 <gmaxwell> There is already a ludicrous amount of divisional precision.
117 2012-08-10 04:33:25 <midnightmagic> BTC_Bear: Did you know there are only twice as many people as bears in Yukon?
118 2012-08-10 04:33:34 <amiller> so you'd plunk down a stack of satoshis on a utxo cell, if it takes 10 bytes and you pay for 100*(bytes*block), then after 10 blocks it gets reclaimed
119 2012-08-10 04:33:34 <BTC_Bear> midnightmagic: basically, It was tantamount to stock splitting.
120 2012-08-10 04:33:41 <luke-jr> lol
121 2012-08-10 04:33:51 <gmaxwell> amiller:  Whatever ratio you want, there is some time horizon that gives the same average cost.
122 2012-08-10 04:33:53 <amiller> do you see the quantity i'm referring to by bytes*block or bit*bit, it's like kilowatt hour
123 2012-08-10 04:34:10 <amiller> gmaxwell, assuming all utxos are identical size
124 2012-08-10 04:34:11 <gmaxwell> BTC_Bear: it's not.
125 2012-08-10 04:34:30 <midnightmagic> BTC_Bear: Moving the decimal place IMO is stock splitting. Being able to chop a penny up into pieces is just increasing fungibility: Gold for example can be physically (in our macro-perspective) divided essentially into useless specks we can't humanly see..
126 2012-08-10 04:34:34 <amiller> also you would get the balance if you remove the transaction yourself
127 2012-08-10 04:34:36 <gmaxwell> BTC_Bear: you get something like that if you "move the dot" or idiotic things like that... but thats idiotic.
128 2012-08-10 04:34:53 <BTC_Bear> gmaxwell: Whether it is or isn't, the market will decide. We will find out however. As it will need to be done otherwise.
129 2012-08-10 04:35:10 <gmaxwell> We already have support in the software to change the units you're using.
130 2012-08-10 04:35:11 <midnightmagic> BTC_Bear: It's all just psychological anyway. Where would dollar parity have come from but the decimal place?
131 2012-08-10 04:35:29 <amiller> it's 21 million 'cuz of black jack.
132 2012-08-10 04:35:36 <amiller> *snake eyes*
133 2012-08-10 04:35:44 <BTC_Bear> midnightmagic: but what happens when stocks split? All things being equal say nothing should happen, but stuff does happen.
134 2012-08-10 04:35:58 <midnightmagic> amiller: :-) 20999999.97690000 you mean!
135 2012-08-10 04:36:02 <gmaxwell> BTC_Bear: but there is no denominated change.
136 2012-08-10 04:36:11 <gmaxwell> BTC_Bear: I believe you're confused.
137 2012-08-10 04:36:27 <gmaxwell> Changing the allowed subdivision is utterly invisible to the users.
138 2012-08-10 04:36:32 <BTC_Bear> Probably, it happens frequently.
139 2012-08-10 04:36:53 <midnightmagic> BTC_Bear: Yes, stuff definitely happens. Weird stuff that only makes sense if you take into account humans' terrible counting abilities. :)
140 2012-08-10 04:36:55 <gmaxwell> AFAICT, we saw no change when the client started allowing people to enter values with more precision than 0.01.
141 2012-08-10 04:38:03 <midnightmagic> But if a human sees: 10.01 or sees: 10.01000001, a human is going to pretend that Satoshi doesn't exist. They're only seeing the decimal point.
142 2012-08-10 04:38:42 <gmaxwell> s/enter/enter and display/
143 2012-08-10 04:38:49 <midnightmagic> BTC_Bear: Was it recently that you made that post?
144 2012-08-10 04:39:18 <BTC_Bear> no, a few months back. The post about attrition was a year ago.
145 2012-08-10 04:39:58 <midnightmagic> doh. You say "for reasons I stated in my post" and I have trouble not looking for it.
146 2012-08-10 04:40:10 <BTC_Bear> gmaxwell: I will have to ponder that. IF people don't know, what they don't know won't hurt them.
147 2012-08-10 04:40:46 <BTC_Bear> We are talking financial markets, perception is everything, math is second place.
148 2012-08-10 04:43:02 <midnightmagic> Nobody puts Math in the corner..
149 2012-08-10 04:43:03 <amiller> woe unto those who would join the wrong blockchain because of perceptions rather than math
150 2012-08-10 04:43:18 <amiller> fools and their money are soon parted; they'll be happier there anyway
151 2012-08-10 04:44:10 <midnightmagic> I once came upon a fork in the road. No, really, I still have it, it's great for salad.
152 2012-08-10 04:44:28 <BTC_Bear> lol
153 2012-08-10 04:44:54 <midnightmagic> you lol but I'm making a pun out of reality.
154 2012-08-10 04:45:00 <amiller> superman2coin: skims off the .000001 (you mean the take a satoshi leave a satoshi jar?)
155 2012-08-10 04:45:34 <amiller> I'd prefer just to refer to the money supply as 1. Everything is just a portion of the total. Any other interpretation is equivalent to that anyway
156 2012-08-10 04:47:00 <amiller> or at least maybe that's an easy way to argue why that the decimal place / divisibility doesn't matter
157 2012-08-10 04:49:14 <BTC_Bear> Ok, lets assume divisibility is the answer. Then the fees will charged will have to be proportional to the divisibility. Otherwise the cost of using those smaller denominations will increase. Hence, inflation.
158 2012-08-10 04:49:24 <BTC_Bear> s/will/being/
159 2012-08-10 04:50:23 <amiller> that's a storage/scaling issue now though rather than a money supply issue
160 2012-08-10 04:50:35 <amiller> the same thing happens if people just want to use it more
161 2012-08-10 04:54:21 <amiller> in the worse case it would be _possible_ for users to put one satoshi in every utxo, that gets twice as bad if you split
162 2012-08-10 04:54:44 <amiller> if there's a good solution to the first case (i hope there is), then divisibility not be an issue
163 2012-08-10 04:55:50 <BTC_Bear> Not that I will be around to see it, but I kind of hope division is what is used. I will pass down stored BTC to the great grandkids and tell them "wait for the right moment" after people think the money is gone and not saved take over the world. :))
164 2012-08-10 04:57:36 <BTC_Bear> Which will cause the Great Depression in the year of our Lord 2240.
165 2012-08-10 04:58:29 <luke-jr> use great grandkids to troll everyone else? <.<
166 2012-08-10 05:00:04 <BTC_Bear> I try not to troll, it happens but I try not to do it. Even you, I respect your beliefs. Might not agree with them all but I respect them.
167 2012-08-10 05:11:25 <amiller> i don't know that much about the gossip network works
168 2012-08-10 05:11:31 <amiller> does it behave basically like a distributed hash table?
169 2012-08-10 05:11:44 <amiller> does it coopt anything from the bittorrent dht or something like kademlia
170 2012-08-10 05:19:03 <BTC_Bear> I believe they work like the old school trick of saying something to the first kid and getting something different out of the last kid.
171 2012-08-10 05:21:21 <BTC_Bear> ie. instead of reciting the whole chapter on GW crossing the Potomic, the last kid just says: GW crossed the Potomic and saves a lot of time reading
172 2012-08-10 05:26:55 <BTC_Bear> amiller: thanx, hanging around here helps sometimes. :)  Address Please, a donation for inspiration.
173 2012-08-10 05:54:10 <BTC_Bear> And the solution is: The Tomyknockers Protocol, that is it so far, got to admit, its apropos.
174 2012-08-10 06:57:55 <Eliel> midnightmagic: a ripple-style network for accepting transactions immediately could work (http://www.ripplepay.com/)
175 2012-08-10 06:58:23 <Eliel> midnightmagic: for allowing 0-conf acceptance, that is.
176 2012-08-10 06:59:38 <Eliel> if you limit the system so it'll just be used for fast transaction confirmation, there's is much less trust required for the people using it.
177 2012-08-10 07:04:38 <sipa> there is no problem with 0-conf transactions if you trust the sender
178 2012-08-10 07:06:58 <jeremias> and you have to trust only for 10-20 minutes
179 2012-08-10 07:12:46 <Eliel> jeremias, sipa: sure, I don't see a huge need for that, but it is there.
180 2012-08-10 07:13:51 <Eliel> a ripple-style network just for catching cheaters (the very few who would and can) would work pretty well.
181 2012-08-10 07:14:17 <Eliel> it would also provide a fallback in case the main bitcoin-system has bigger troubles someday.