1 2014-01-18 00:00:15 <Snowleaksange> also would like to remake DNS for specifying micropayment domains...
2 2014-01-18 00:02:25 <jcorgan> i think it was something micro-mining, where your browser would request work and send a low difficulty share
3 2014-01-18 00:09:15 <lechuga__> i think its pretty much agreed micropayments have to be off bloackchain
4 2014-01-18 00:09:18 <lechuga__> blockchain*
5 2014-01-18 00:09:45 <lechuga__> how does coinbase's offering work?
6 2014-01-18 00:11:26 <lechuga__> i guess both parties have to be a customer
7 2014-01-18 00:11:42 <lechuga__> which is sort of lame
8 2014-01-18 00:13:13 <lianj> lechuga__: propose something that work with multiple services
9 2014-01-18 00:13:50 <jaakkos> Zarutian: i'm not convinced it's feasible for larger population to handle a cryptographic hash in the url...
10 2014-01-18 00:14:19 <jaakkos> i'm hoping one day there is a better way to share public keys, even if you just use a regular url
11 2014-01-18 00:14:55 <jaakkos> perhaps something like namecoin
12 2014-01-18 00:15:32 <Snowleaksange> ahh nice @ namecoin
13 2014-01-18 00:15:41 <sipa> jaakkos: public keys for what?
14 2014-01-18 00:16:01 <jaakkos> for SSL use on any site/service pointed to by url
15 2014-01-18 00:16:28 <sipa> how do you prevent someone for poisoning the data?
16 2014-01-18 00:16:44 <jaakkos> by not having to trust it
17 2014-01-18 00:17:02 <sipa> that sounds useless
18 2014-01-18 00:17:47 <jaakkos> i haven't really looked into namecoin, but i could imagine something like, you can register a pubkeyhash with an address
19 2014-01-18 00:18:00 <jaakkos> and the first registration is authoritative
20 2014-01-18 00:18:25 <jaakkos> of course there are problems if the site loses the key.
21 2014-01-18 00:21:12 <jaakkos> it's useless to get rid of CAs who obviously can't be trusted? :)
22 2014-01-18 00:22:58 <sipa> i'm very unsure about the implementation details and practicalities, but at least in theory, dnssec sounds like the right way to solve the authentication problem (assuming we want to keep DNS itself as naming system)
23 2014-01-18 00:23:38 <jcorgan> this sort of thing gets a lot of discussion on the cryptography and cypherpunks mailing lists
24 2014-01-18 00:27:43 <jaakkos> sipa: but with dnssec, you still need to predistribute keys who sign the records (and keys)
25 2014-01-18 00:28:27 <jaakkos> and obviously whole world can't use a single key
26 2014-01-18 00:28:57 <sipa> jaakkos: right, but the authority giving the names is the same as the one authenticating it
27 2014-01-18 00:30:11 <sipa> it does solve a different problem actually, never mind
28 2014-01-18 00:31:25 <jaakkos> hmm.. then NSA just chooses DNS providers as their bitches instead of CAs ;)
29 2014-01-18 00:32:19 <sipa> yeah, DNSSEC only helps guaranteeing that the name you see is the one the nameserver wants you to see
30 2014-01-18 00:32:31 <sipa> it doesn't establish any real-world identity
31 2014-01-18 00:34:01 <jaakkos> though they might need more bitches compared to only a few CA ones, since they need separate signing keys for separate sites...
32 2014-01-18 00:34:21 <jaakkos> provided that users are equipped with valid set of public keys from all major dns providers
33 2014-01-18 01:10:22 <Snowleaksange> yeah i would feel a lot better about decentralized dns authority
34 2014-01-18 01:10:38 <Snowleaksange> wouldnt shed a tear over putting existing registrars out of business either
35 2014-01-18 04:39:37 <jcrubino> is possible to have an address that is both valid for litecoin and bitcoin?
36 2014-01-18 04:40:13 <newbie__> I dont think so
37 2014-01-18 04:40:16 <brisque> yes.
38 2014-01-18 04:40:28 <brisque> well, you can use the same keypair but the address will be different.
39 2014-01-18 04:40:56 <jcrubino> here is a testnet address that is valid according to bitcoind and litecoind n2suEzeTKKJchFH9pfPxya7A5yPuUBdykU
40 2014-01-18 04:41:13 <jcrubino> it is a testnet address on both systems
41 2014-01-18 04:41:37 <brisque> functionally though, HASH160 c6de65b0de55103854c1aa2e0537c1f7790ab025 is 1K8XDQwt9abiGHCjaRLeEKvfGFDAYXnmFP or LdMUUdFiEEqmX5ttkZKwWLzRUTaSdWF4Dj depending on the network, but the private key is the same.
42 2014-01-18 04:42:06 <brisque> that is, using the same private key (0xf5061b2b2debd8b52a3d86597e3ae3b4578df11ba73be0d0d80af323a0ea9ea7) I can spend from both addresses.
43 2014-01-18 04:43:02 <newbie__> wow
44 2014-01-18 04:43:44 <brisque> the only thing different between litecoin and bitcoin addresses is the version byte.
45 2014-01-18 04:46:44 <newbie__> any site which provide old market data?
46 2014-01-18 12:23:02 <btcNeverSleeps> in which way is "Reality Keys" related to bitcoin? What do they put into the blockchain?
47 2014-01-18 12:25:05 <brisque> you'll have to give more of a clue than that.
48 2014-01-18 12:25:21 <brisque> I've no idea what you're referring to.
49 2014-01-18 12:26:25 <sipa> reality keys is an oracle service
50 2014-01-18 12:27:35 <brisque> ah, alright.
51 2014-01-18 12:29:47 <btcNeverSleeps> can "Reality Keys" be used to implement a dead man's switch?
52 2014-01-18 12:30:43 <btcNeverSleeps> sipa: when you mean an "oracle service", does it have anything to do with a "random oracle"? (I guess not)
53 2014-01-18 12:32:33 <sipa> qa random oracle would be a sort of oracle
54 2014-01-18 12:34:01 <btcNeverSleeps> I'd be looking for something providing a dead man's switch against computer disconnection: a 3rd party keeping a secret and if the "heartbeat" stops coming for more than two minutes, than it releases the secret. Do you know if such a service already exists somewhere?
55 2014-01-18 12:39:00 <brisque> two minutes?
56 2014-01-18 12:39:38 <brisque> that's an awful tight schedule to keep, especially given networking issues and general server downtime.
57 2014-01-18 13:06:58 <wumpus> also sounds like a prime DoS target
58 2014-01-18 13:33:37 <dansmith_btc> btcNeverSleeps, I could run such a service on a tamper-proof oracle machne for you. How much are you willing to pay per month?
59 2014-01-18 13:34:53 <sipa> for 1 year, that requires over 5 nines of reliability
60 2014-01-18 13:35:13 <sipa> and i guess you want it for a longer period than that
61 2014-01-18 13:37:38 <dansmith_btc> sipa, "5 nines"? pls explain
62 2014-01-18 13:40:07 <dansmith_btc> btcNeverSleeps, check out https://en.bitcoin.it/wiki/Contracts#Trust_minimization:_Amazon_AWS_oracles It links to my thread on btctalk
63 2014-01-18 13:42:53 <sipa> dansmith_btc: 5 nines = 99.999% uptime
64 2014-01-18 13:44:54 <btcNeverSleeps> dansmith_btc: thanks, bookmarked and put on my "to read" list : )
65 2014-01-18 13:45:18 <btcNeverSleeps> dansmith_btc: sipa meant "99.999% uptime"
66 2014-01-18 13:47:33 <btcNeverSleeps> thing is: in my case I'd only need the dead man switch in case someone disconnects (which I know happens but is not that common) and it wouldn't be that much of a big deal if the "dead man switch" service was down for a few minutes. Moreover if the dead man switch server were to "kick in" (i.e. "answer" / do its duty) only, say, 99% of the time, if would still be acceptable.
67 2014-01-18 13:48:27 <btcNeverSleeps> what I'm willing to pay would be in btc and it wouldn't be more from what it cost me to write one ;)
68 2014-01-18 13:49:17 <btcNeverSleeps> "write and run" one. I don't see it much as a DoS target in that there'd be no way for an attacker to know when one of my participant would disconnect and hence there'd be no way to no when I'd need the help of the "dead man switch" server.
69 2014-01-18 13:49:29 <btcNeverSleeps> s / to no / to know /
70 2014-01-18 13:52:11 <wumpus> you could poll from multiple machines on different networks to increase the reliability
71 2014-01-18 14:00:57 <dansmith_btc> btcNeverSleeps, in fact the way my oracle setup works is that you don't even have to trust me as an oracle operator. All you have to do is trust Amazon. So, esentially you can run the oracle machine yourself if you have an AWS account. Anyway, if you choose to hire me, I will not charge you too much, especially if your project is advancing a good cause :)
72 2014-01-18 14:33:55 <warren> wumpus: http://pastebin.com/TpsWCnft
73 2014-01-18 14:34:53 <warren> wumpus: is it really necessary to export the export the source?
74 2014-01-18 15:01:17 <wumpus> warren: no, that's not necessary, could be changed around
75 2014-01-18 15:01:40 <wumpus> warren: only in the final gitian build we want the source (of bitcoin)
76 2014-01-18 17:55:56 <ThomasV> maaku: ping
77 2014-01-18 18:08:58 <maaku> here
78 2014-01-18 18:48:27 <ThomasV> maaku: what makes you think a binary branching tree is more efficient? what are the pros and cons?
79 2014-01-18 19:01:41 <maaku> ThomasV: proof sizes are unacceptable with 256-way branching factors, unless you have a Merkle tree internal to the node
80 2014-01-18 19:04:14 <maaku> at which point you get the same performance characteristics of a binary tree, with loads more complexity
81 2014-01-18 19:05:00 <ThomasV> proofs are longer, sure, but merkle paths are shorter
82 2014-01-18 19:05:46 <gmaxwell> who cares if the path is shorter if it results in much larger proofs? If you care about access times you can always pack nodes when you store them.
83 2014-01-18 19:05:48 <ThomasV> what exactly is unacceptable?
84 2014-01-18 19:08:10 <maaku> ThomasV: with the serialization format I outlined in the BIP, you store the short Merkle paths
85 2014-01-18 19:08:15 <maaku> it's the best of both worlds
86 2014-01-18 19:09:11 <ThomasV> maaku: my point is, there might be an optimum between 2 and 256
87 2014-01-18 19:09:56 <maaku> ThomasV: no, there demonstrably isn't. you don't get any benefit from >2
88 2014-01-18 19:10:18 <ThomasV> all right
89 2014-01-18 19:10:29 <maaku> the proofs are bigger, the hashing performance the same
90 2014-01-18 19:11:52 <maaku> say you use a branching factor of 4
91 2014-01-18 19:12:16 <maaku> now you need two rounds of the hashing function per level instead of one (because you've exceeded the size of one block)
92 2014-01-18 19:13:17 <maaku> but you must store 4 hashes instead of 3 for a path through that same level
93 2014-01-18 19:14:54 <maaku> and when you also consider that 2-way branching is simpler (from a standardization standpoint), the choice seemed obvious
94 2014-01-18 19:15:05 <ThomasV> sure, you must store hashes that are not related to the binary path
95 2014-01-18 19:16:31 <maaku> yeah
96 2014-01-18 19:19:09 <maaku> of course obvious in hindsight - we spent many months in the UBC thread debating various schemes for Merkle compression within a node
97 2014-01-18 19:19:27 <maaku> which I guess was an indication that we knew there was an underlying problem
98 2014-01-18 19:22:06 <ThomasV> maaku: I was thinking that binary branching would indice more database accesses..
99 2014-01-18 19:22:23 <ThomasV> induce
100 2014-01-18 19:22:38 <sipa> nothing prevents you from packing multiple tree levels into a single database entry
101 2014-01-18 19:22:59 <sipa> the semantic structure of the tree doesn't have to match the implementation
102 2014-01-18 19:23:41 <ThomasV> sipa: how would yu do that?
103 2014-01-18 19:23:59 <gmaxwell> 11:05 < gmaxwell> who cares if the path is shorter if it results in much larger proofs? If you care about access times you can always pack nodes when you store them.
104 2014-01-18 19:24:39 <sipa> ThomasV: make every database entry a tree fragment of let's say 8 deep
105 2014-01-18 19:24:42 <gmaxwell> just includes the children with the nodes in the same record. that simulates a larger radix.
106 2014-01-18 19:24:49 <sipa> serialized in some way
107 2014-01-18 19:25:12 <ThomasV> oh I see
108 2014-01-18 19:25:15 <ThomasV> thanks
109 2014-01-18 19:25:51 <sipa> so you get 1 level-0 entry (with semantic levels 0 through 7), and if there's branching beneath, you can have up to 256 level-1 entries (spanning semantic levels 8-15), etc
110 2014-01-18 19:26:23 <maaku> ThomasV: what sipa said :)
111 2014-01-18 19:27:28 <ThomasV> btw, anyone going to the conference in berlin?
112 2014-01-18 19:27:35 <sipa> it's very important i think to end up with a semantic structure that can be representing with various tradeoffs in actual implementations
113 2014-01-18 19:27:42 <sipa> *represented
114 2014-01-18 19:28:28 <ThomasV> indeed
115 2014-01-18 19:28:46 <maaku> this way you make it a user tweakable performance setting, instead of an arbitrary tradeoff written into the structure
116 2014-01-18 19:36:14 <michagogo> cloud|Erm, what's with #3555?
117 2014-01-18 19:36:26 <michagogo> cloud|Why does it consist of 5,109 commits?
118 2014-01-18 19:36:45 <sipa> michagogo|cloud: github fuckup
119 2014-01-18 19:36:53 <michagogo> cloud|Ah.
120 2014-01-18 19:37:03 <michagogo> cloud|Are there actually 5k commits in the git tree now?
121 2014-01-18 19:37:11 <michagogo> cloud|Or is it just that it's displaying incorrectly?
122 2014-01-18 19:37:15 <sipa> it did the same with the previous leveldb subtree merges, after merging
123 2014-01-18 19:37:17 <sipa> no clue
124 2014-01-18 19:37:29 <michagogo> cloud|Heh, I can think of one way to find out
125 2014-01-18 19:37:38 <michagogo> cloud|git fetch upstream
126 2014-01-18 19:37:47 <michagogo> cloud|Gah, I thought I'd opened Git Bash
127 2014-01-18 19:38:53 <sipa> i just got highlighted in a random primecoin commit too
128 2014-01-18 19:38:56 <sipa> i think it's related
129 2014-01-18 19:39:33 <michagogo> cloud|Looks like a false alarm:
130 2014-01-18 19:39:34 <michagogo> cloud|https://www.irccloud.com/pastebin/YazuAqBV
131 2014-01-18 19:40:59 <michagogo> cloud|Hmm, I wonder if `git rebase` retains commits as signed?
132 2014-01-18 19:43:31 <sipa> of course not
133 2014-01-18 19:43:40 <sipa> it changes the commit id, the signature cannot remain valid
134 2014-01-18 19:46:39 <michagogo> cloud|Interestingly, I don't see an option to sign the new commits
135 2014-01-18 19:46:50 <sipa> git commit -S
136 2014-01-18 19:47:08 <michagogo> cloud|sipa: Yes, but git rebase doesn't have the -S option
137 2014-01-18 19:47:16 <michagogo> cloud|(at least not according to the help page...)
138 2014-01-18 19:47:25 <sipa> you can use git commit --amend -S
139 2014-01-18 19:47:40 <michagogo> cloud|--amend?
140 2014-01-18 19:47:46 <michagogo> cloud|Didn't know about that one
141 2014-01-18 19:47:47 <sipa> yes, modify an existing commit
142 2014-01-18 19:47:53 <sipa> it's what rebase is built on top of
143 2014-01-18 19:48:10 <sipa> also allows you to change the author or committer of a commit, or the timestamp
144 2014-01-18 19:48:18 <michagogo> cloud|Interesting
145 2014-01-18 19:48:35 <michagogo> cloud|Can you only amend the last commit? (guessing yes)
146 2014-01-18 19:49:25 <sipa> yes
147 2014-01-18 19:49:43 <michagogo> cloud|So how would one go about rebasing two signed commits?
148 2014-01-18 19:49:55 <sipa> use git rebase, and choose 'edit' for each commit
149 2014-01-18 19:49:58 <sipa> git rebase -i
150 2014-01-18 19:50:08 <sipa> then you get a view with each commit in turn being replayed
151 2014-01-18 19:50:19 <sipa> and you can amend it before continuing the rebase
152 2014-01-18 19:50:34 <sipa> you can of course also do it manually
153 2014-01-18 19:50:50 <sipa> first resetting to the master you want to rebase on
154 2014-01-18 19:51:02 <sipa> and then cherry-pick the to-be-committed commits there
155 2014-01-18 19:51:08 <sipa> and amending them before cherry-picking the next
156 2014-01-18 19:52:38 <lechuga__> ugh any1 know how to pull a new branch from a repo you previously cloned
157 2014-01-18 19:52:46 <lechuga__> but the new branch happened post-clone
158 2014-01-18 19:53:17 <sipa> git fetch upstream
159 2014-01-18 19:53:21 <sipa> git checkout branchname
160 2014-01-18 19:53:29 <lechuga__> sipa savin the day again
161 2014-01-18 19:53:39 <lechuga__> ty
162 2014-01-18 19:55:59 <lechuga__> oh wait thats not my issue
163 2014-01-18 19:56:12 <lechuga__> i cloned a repo in gitorious into my own repo
164 2014-01-18 19:56:25 <lechuga__> and original repo has a new branch
165 2014-01-18 19:56:35 <lechuga__> that i want in my new remote repo on gitorious
166 2014-01-18 19:56:55 <lechuga__> i guess i could re-clone
167 2014-01-18 19:57:02 <lechuga__> but there must be a right way to deal with this
168 2014-01-18 20:01:14 <lechuga__> hmm
169 2014-01-18 20:01:24 <lechuga__> i think i just did it with: git pull repourl ref
170 2014-01-18 20:01:35 <michagogo> cloud|Wait, wth?
171 2014-01-18 20:01:56 <michagogo> cloud|People have sent over 1,300 BTC to a trash address?
172 2014-01-18 20:02:00 <michagogo> cloud|1CounterpartyXXXXXXXXXXXXXXXUWLpVr o_O
173 2014-01-18 20:02:12 <jcorgan> create a local branch, then push that to your own remote repo
174 2014-01-18 20:02:49 <jcorgan> michagogo|cloud: that's a "proof of burn" scheme to create a new coin
175 2014-01-18 20:03:23 <Goonie> jgarzik: Bitpay UX has become not so good lately...
176 2014-01-18 20:06:54 <michagogo> cloud|ACTION cringes
177 2014-01-18 20:07:57 <maaku> michagogo|cloud: a fool and his money ...
178 2014-01-18 20:08:07 <jcorgan> yeah, same here. But at least the rest of our bitcoin is worth 1/100th of 1% more.
179 2014-01-18 20:30:00 <zapsoda> Is there a way to drain all the money from a account? I tried just saying sendfrom(<account>, <address>, getbalance(<account>)) but then the transaction fee leaves me with a negative balance
180 2014-01-18 20:30:49 <sipa> what do you intend to accomplish?
181 2014-01-18 20:33:59 <maaku> zapsoda: that is the correct behavior
182 2014-01-18 20:34:49 <maaku> if it annoys you, use the move command to move positive balance from somewhere else to cancel out the fee
183 2014-01-18 20:35:04 <zapsoda> I want to drain the account without having a negative balance, All I can think of is hardcoding the transaction fee but if there is a way around that I prefer to have it find the fee or somthing
184 2014-01-18 20:35:57 <zapsoda> sipa, I want to have 0 coins left on that account after I use the sendfrom command
185 2014-01-18 20:35:58 <sipa> you understand that accounts are just numbers, right?
186 2014-01-18 20:36:19 <sipa> you don't need to interact with the bitcoin network at all to change them
187 2014-01-18 20:36:28 <sipa> just use the move command
188 2014-01-18 20:36:37 <sipa> which locally moves coins from one account to another
189 2014-01-18 20:36:50 <sipa> sorry, moves *balance* from one account to another
190 2014-01-18 20:36:54 <sipa> without affecting the coins
191 2014-01-18 20:37:04 <zapsoda> I understand that much, But I'm having accounts keep users coins apart so when they withdraw their coins I want to remove all the coins without myself paying the transaction fee
192 2014-01-18 20:37:29 <sipa> ah, i see
193 2014-01-18 20:37:42 <sipa> you want sort of a "i specify the total transaction value, including fee"
194 2014-01-18 20:37:47 <sipa> that's been suggested before
195 2014-01-18 20:37:53 <sipa> but not implemented, afaik
196 2014-01-18 20:38:22 <maaku> zapsoda: that's why you see many sites setting fixed fees
197 2014-01-18 20:41:07 <zapsoda> Ok, Thanks sipa
198 2014-01-18 20:41:19 <zapsoda> I guess thats what ill do
199 2014-01-18 22:03:41 <Goonie> What's the concensus of the switch of default from BTC to mBTC? Is it desirable?
200 2014-01-18 22:04:30 <sipa> why "switch" ?
201 2014-01-18 22:04:46 <sipa> we didn't abandon the us dollar and moved to cents, did we?
202 2014-01-18 22:05:27 <Goonie> sipa: No. But actually I've never seen a bank that would display dollar in units of cents.
203 2014-01-18 22:06:06 <sipa> true
204 2014-01-18 22:08:16 <Goonie> sipa: My question is if a new user downloads a wallet app and it shows mBTC as default will he immediately "get it"?
205 2014-01-18 22:09:01 <Goonie> For example, when he buys $500 worth of Bitcoins and receives 400 rather than 0.4 -- will he be confused?
206 2014-01-18 22:12:14 <bbdude> Goonie, I don't think most new users get bitcoins in general
207 2014-01-18 22:12:44 <Goonie> Well for example they go to a meetup and buy some.
208 2014-01-18 22:14:46 <bbdude> perhaps misled would be a better term, and once bitcoin settles and becomes more adopted, we'll have a better grasp on what the baseline denomination will be
209 2014-01-18 22:15:25 <bbdude> I think there's definitely bound to be confusion this early on for sure
210 2014-01-18 22:17:24 <sipa> Goonie: i think bitcoin-qt already uses mBTC by default
211 2014-01-18 22:17:39 <sipa> not sure though, i haven't used the gui in along time
212 2014-01-18 22:18:28 <jcorgan> i'd vote that if we do it, we go much further. there are currencies like the Korean Won or the Japanese Yen that have 4-5 digits in prices for everday purchases
213 2014-01-18 22:18:29 <bbdude> We've got a lot of folk still using BTC, and if BTC value stays below 1000 USD using mBTC will feel a little weird
214 2014-01-18 22:18:50 <bbdude> Actually I take that back
215 2014-01-18 22:19:19 <sipa> people indeed prefer digits before the dot over digits behind it
216 2014-01-18 22:24:49 <Goonie> where does bitcoin-qt store its settings? I'd expect ~/.bitcoin/bitcoin.conf, but apparently it doesn't
217 2014-01-18 22:25:17 <sipa> no, there's some qt thing for settings
218 2014-01-18 22:25:28 <sipa> that stores it in a platform dependent place
219 2014-01-18 22:26:13 <Goonie> I use Ubuntu
220 2014-01-18 22:26:43 <sipa> ~/.config/something iirc
221 2014-01-18 22:30:39 <maaku> bbdude: a switch to XBT = uBTC equally likely I think
222 2014-01-18 22:31:44 <Goonie> sipa: Thanks, found it. Removed the config and will now try a recent version for what is the default.
223 2014-01-18 22:32:11 <sipa> Goonie: maybe it's only in git head
224 2014-01-18 22:41:01 <jcorgan> maaku: +1 for uBTC
225 2014-01-18 22:42:01 <Goonie> Is this a known error (when compiling)?
226 2014-01-18 22:42:01 <Goonie> ../../../src/qt/libbitcoinqt.a(libbitcoinqt_a-guiutil.o): In function `GUIUtil::isDust(QString const&, long long)':
227 2014-01-18 22:42:02 <Goonie> collect2: error: ld returned 1 exit status
228 2014-01-18 22:42:02 <Goonie> /home/aschildbach/dev/workspace/bitcoin/src/qt/guiutil.cpp:188: undefined reference to `CTxOut::CTxOut(long long, CScript)'
229 2014-01-18 22:42:02 <Goonie> /home/aschildbach/dev/workspace/bitcoin/src/qt/paymentserver.cpp:460: undefined reference to `CTxOut::CTxOut(long long, CScript)'
230 2014-01-18 22:42:02 <Goonie> ../../../src/qt/libbitcoinqt.a(libbitcoinqt_a-paymentserver.o): In function `PaymentServer::processPaymentRequest(PaymentRequestPlus&, QList<SendCoinsRecipient>&)':
231 2014-01-18 22:42:28 <Goonie> (its git master)
232 2014-01-18 22:45:33 <sipa> Goonie: try a make clean first
233 2014-01-18 22:46:15 <Goonie> Ah damn. This make clean should really be documented. Guess I'm running into this issue for the 3rd time now.
234 2014-01-18 22:47:03 <jcorgan> $5 Starbucks coffee == 6250 XBT, with a 100 XBT transaction fee, and dust outputs are <54 XBT
235 2014-01-18 22:58:04 <maaku> jcorgan: and that's a normal-sized currency amount for most of the world
236 2014-01-18 23:04:03 <phillipsjk> ACTION took to long to realize those were current figures.
237 2014-01-18 23:05:37 <phillipsjk> In in the US gas prices are 4 digit.
238 2014-01-18 23:07:53 <phillipsjk> One benefit of 1 XTC == 1 µBTC is that not everybody has that symbol on their keyboard. :D
239 2014-01-18 23:08:48 <scoofy> that's generally abbreviated as 'u'
240 2014-01-18 23:08:51 <scoofy> for this reason
241 2014-01-18 23:10:01 <phillipsjk> It strikes me as a work-around for US-keyboards, not a standard.
242 2014-01-18 23:10:41 <phillipsjk> In electronics we use mew when using pencil/paper.
243 2014-01-18 23:11:13 <jcorgan> is there any actual momentum to getting XBT standardized by ISO, or is it all just wishful thinking on our part
244 2014-01-18 23:11:28 <phillipsjk> Captchas don't work when you try to type those symbols too :P
245 2014-01-18 23:12:15 <phillipsjk> jcorgan, why not both?
246 2014-01-18 23:12:17 <scoofy> personally i will not use XBT anywhere
247 2014-01-18 23:12:39 <scoofy> except maybe when referring some exchange that actually uses that
248 2014-01-18 23:13:58 <scoofy> but then... it's some external organization trying to enforce some set of rules that were created before cryptocurrencies even existed?
249 2014-01-18 23:16:20 <jcorgan> individuals/organizations are of course free to ignore ISO, but it does turn out that voluntary standardization of things can save everyone effort by allowing interoperability
250 2014-01-18 23:17:29 <sipa> XBT is already being used as BTC, no?
251 2014-01-18 23:17:53 <jcorgan> i've been seeing it used more and more, but usually as == 1BTC
252 2014-01-18 23:19:14 <jcorgan> so a way to solve the decimal problem and the lack of ISO standard currency abbreviation would be to get XBT as == 1uBTC
253 2014-01-18 23:19:42 <jcorgan> it also fits nicely with the fact that ISO currencies all have only 2 digits after the decimal, which for XBT would mean 1 satoshi
254 2014-01-18 23:19:51 <Luke-Jr> someone is using XBT as mBTC
255 2014-01-18 23:20:31 <Luke-Jr> tamas IIRC
256 2014-01-18 23:20:38 <scoofy> well there's alread enough confusion with BTC/mBTC/uBTC... confuse it even more with XBT=1BTC=1mBTC=1uBTC ?
257 2014-01-18 23:20:59 <scoofy> it's like trying to shoehorn something to a ruleset that it was not meant to fit
258 2014-01-18 23:21:03 <sipa> XBT = cryptocurrency, undefined unit
259 2014-01-18 23:21:05 <Luke-Jr> (BitsOfProof)
260 2014-01-18 23:21:08 <jcorgan> well, that would be a case for getting it through a widely recognized standards body
261 2014-01-18 23:21:58 <scoofy> so 1 XBT = 1 BTC / 1 mBTC / 1 uBTC / 1 satoshi, depending on the circumstance. I see.
262 2014-01-18 23:22:16 <jcorgan> scoofy: yes, that is the case that has arisen due to lack of attention to this
263 2014-01-18 23:22:26 <Luke-Jr> we should say 1 XBT = 1 TBC to throw ISO off
264 2014-01-18 23:22:28 <Luke-Jr> <.<
265 2014-01-18 23:22:30 <scoofy> that's kinda messed up...
266 2014-01-18 23:23:20 <jcorgan> an noone that i know of has tried to represent XBT as a satoshi, so i'm not sure what the last part of that was
267 2014-01-18 23:25:20 <Goonie> sipa: If I'm not mistaken, current master is still at BTC by default.
268 2014-01-18 23:28:11 <sipa> Goonie: ok, i may have misremembered something about changing it