1 2013-11-06 00:20:07 <andytoshi> is there a way i can use a different sending address than receiving address on the mailing list?
2 2013-11-06 00:23:21 <Luke-Jr> andytoshi: there is no sending addre.. oh wait
3 2013-11-06 00:23:22 <Luke-Jr> :P
4 2013-11-06 00:24:08 <lianj> Luke-Jr: :D
5 2013-11-06 00:24:20 <andytoshi> haha :)
6 2013-11-06 00:24:49 <andytoshi> my email client is not set up to send mail from my home address, since the domain points at a residential IP
7 2013-11-06 00:24:58 <andytoshi> which is blcklisted
8 2013-11-06 00:25:59 <gwern> (reposting here at the urging of another person) so I have a funny little problem with my local bitcoind and I'd like to hear if other people think my interpretation is right. some time ago for a bet (http://www.reddit.com/r/SilkRoad/comments/1pko9y/the_bet_bmr_and_sheep_to_die_in_a_year/) I did a 'getnewaddress' and then 'sendtoaddress' 4btc to https://blockchain.info/address/1AZvaBEJMiK8AJ5GvfvLWgHjWgL59TRPGy when I do listtransactions I see ...
9 2013-11-06 00:26:05 <gwern> ... '..."address" : "1AZvaBEJMiK8AJ5GvfvLWgHjWgL59TRPGy", / "category" : "receive", / "amount" : 4.00000000,...' *then* '..."address" : "1AZvaBEJMiK8AJ5GvfvLWgHjWgL59TRPGy", "category" : "send", "amount" : -4.00000000,...', and 'getbalance 1AZvaBEJMiK8AJ5GvfvLWgHjWgL59TRPGy' yields 0.00000000 even though you can see blockchain.info disagrees. now when I try to do a 'sendfrom 1AZvaBEJMiK8AJ5GvfvLWgHjWgL59TRPGy' I get 'error: ...
10 2013-11-06 00:26:09 <andytoshi> the sourceforge mailing-list page gives me nothing, so i think it's safe to assume there's no way to do this ... sourceforge is not known for being full of features
11 2013-11-06 00:26:11 <gwern> ... {"code":-6,"message":"Account has insufficient funds"}'. am I correct in thinking this is a bug in bitcoind and I do in fact have 4btc in 1AZ and if I do 'dumpprivkey' to a wallet like blockchain.info I can transfer the 4 bitcoins elsewhere without problem?
12 2013-11-06 00:27:46 <Luke-Jr> gwern: no, you probably lost the funds because bc.i confused you
13 2013-11-06 00:27:58 <Luke-Jr> gwern: coins aren't "in" addresses, they're in wallets.
14 2013-11-06 00:28:47 <gwern> Luke-Jr: I hope you aren't right. losing 4btc is no joke
15 2013-11-06 00:28:54 <Luke-Jr> gwern: the (opaque) wallet uses private keys to control them internally, and will in some cases change which private key is used for some amount
16 2013-11-06 00:29:07 <Luke-Jr> gwern: well, if you didn't try messing with wallet internals, you should be fine
17 2013-11-06 00:29:21 <Luke-Jr> but if you went using low-level RPCs like dumpprivkey and such, you're bound to lose something
18 2013-11-06 00:29:36 <gwern> define 'messing with wallet internals'... I thought I was doing something perfectly safe - just a 'getnewaddress' and a 'sendtoaddress'
19 2013-11-06 00:29:46 <Luke-Jr> gwern: if that's all you did, you should be okay
20 2013-11-06 00:30:09 <Luke-Jr> gwern: is it possible the funds haven't confirmed at all yet?
21 2013-11-06 00:30:17 <gwern> no. this was 1400 confirms ago
22 2013-11-06 00:30:27 <Luke-Jr> what does getinfo say (use pastebin.com)
23 2013-11-06 00:30:51 <gwern> I did do a call to dumpprivkey to see what the output looked like... now you're probably going to tell me that it has side-effects and is not referentially transparent >.>
24 2013-11-06 00:31:21 <Luke-Jr> nah, no side effects in itself
25 2013-11-06 00:31:28 <c0rw1n> you have a beckup of wallet before dumpprivkey right?
26 2013-11-06 00:31:54 <gwern> c0rw1n: yeah, I did a harddrive backup yesterday so there should be 2 copies of my .bitcoin from yesterday there
27 2013-11-06 00:31:55 <c0rw1n> hmm someone said -salvagewallet might fic it (i have no idea)
28 2013-11-06 00:32:09 <Luke-Jr> what does getinfo say (use pastebin.com)?
29 2013-11-06 00:33:04 <gwern> Luke-Jr: http://pastebin.com/gKnr6T45
30 2013-11-06 00:34:10 <Luke-Jr> gwern: first, you have a fundamentally wrong conception
31 2013-11-06 00:34:16 <Luke-Jr> gwern: addresses are not accounts or wallets
32 2013-11-06 00:34:28 <Luke-Jr> they're only used to receive funds
33 2013-11-06 00:34:33 <Luke-Jr> nothing else
34 2013-11-06 00:34:49 <Luke-Jr> they *point* at an account in a wallet, but they aren't either of those in themselves
35 2013-11-06 00:35:14 <Luke-Jr> when you ran getnewtransaction, you specified the name of the account the address would point to
36 2013-11-06 00:35:28 <Luke-Jr> if you didn't specify an account, the address was made to point at the "" account
37 2013-11-06 00:36:09 <Luke-Jr> despite bc.i's misinformation, addresses do NOT have balances or anything like that
38 2013-11-06 00:36:32 <Luke-Jr> listtransactions should also tell you the account the funds went to
39 2013-11-06 00:37:10 <gwern> the 'account' parameter in all is ""
40 2013-11-06 00:37:12 <Luke-Jr> listaccounts will tell you every account in the wallet and its balance
41 2013-11-06 00:37:19 <Luke-Jr> gwern: ok, then your account in question is ""
42 2013-11-06 00:37:48 <Luke-Jr> sendfrom "" "1someaddress" 4
43 2013-11-06 00:38:07 <gwern> what
44 2013-11-06 00:38:26 <gwern> oh man I didn't even notice that it said 'sendfrom <fromaccount> <tobitcoinaddress>' <-- 'fromaccount' rather than 'fromaddress'
45 2013-11-06 00:38:55 <phantomcircuit> gwern, the only way to do fromaddress is with rawtransactions
46 2013-11-06 00:39:02 <Luke-Jr> gwern: there is no from address
47 2013-11-06 00:39:07 <Luke-Jr> ACTION glares at phantomcircuit
48 2013-11-06 00:39:07 <phantomcircuit> and you shouldn't be messing with those if you dont understand how that works
49 2013-11-06 00:39:20 <phantomcircuit> Luke-Jr, you'll just confuse him more
50 2013-11-06 00:39:24 <Luke-Jr> gwern: transactions are only ever *to* an address
51 2013-11-06 00:39:33 <Luke-Jr> phantomcircuit: no, I'm de-confusing him
52 2013-11-06 00:40:06 <phantomcircuit> gwern, Luke-Jr is right, but if you want to spend the transaction output in transaction 4f928080f37291920a505e282a2deb64129c7b39295b20e134dfe67bcf67b065
53 2013-11-06 00:40:14 <phantomcircuit> you'll need to use the rawtransactions api
54 2013-11-06 00:40:18 <phantomcircuit> gwern, what was the bet?
55 2013-11-06 00:40:19 <Luke-Jr> gwern: the "from address" blockchain.info is showing is really the address coins had been *previously sent to*, and unrelated to the transaction you're looking at
56 2013-11-06 00:40:37 <gwern> phantomcircuit: that sheep / blackmarket reloaded would shutdown in a year. no one bit.
57 2013-11-06 00:40:45 <gwern> Luke-Jr: gahh. I feel more confused than ever
58 2013-11-06 00:41:36 <sipa> gwern: what a transaction does, is assigning some coins to some address (script really, butforget that for now)
59 2013-11-06 00:42:04 <sipa> gwern: inputs of a transactions are _coins_
60 2013-11-06 00:42:17 <sipa> specific coins created by a previous transactions
61 2013-11-06 00:42:19 <Luke-Jr> gwern: it's usually best to just ignore blockchain.info really
62 2013-11-06 00:42:51 <sipa> gwern: you can talk about the address a particular coin you're spending was previously assigned to
63 2013-11-06 00:43:08 <sipa> and within a wallet that may make sense (it's micromanagement, though)
64 2013-11-06 00:43:32 <gwern> sipa: well, for the bet I wanted an address with 4 bitcoins which could sign a message and prove I had 4 bitcoins to bet with. it was the logical implementation of that desire, as far as I knew
65 2013-11-06 00:43:54 <sipa> yup, makes sense
66 2013-11-06 00:44:33 <sipa> the problem is mixing abstraction layers
67 2013-11-06 00:44:51 <sipa> you can either talk about wallets, or about addresses that hold coins
68 2013-11-06 00:45:07 <sipa> both are possible, but mixing them is very confusing
69 2013-11-06 00:45:24 <gwern> I guess I thought of my wallet as being basically a sort of hashtable/map with public keys/addresses as the key and a balance of bitcoins.
70 2013-11-06 00:45:31 <sipa> (and i doubt i'm helping you know)
71 2013-11-06 00:45:40 <sipa> right
72 2013-11-06 00:45:53 <sipa> that is not the case
73 2013-11-06 00:45:54 <gwern> * and a value of bitcoins
74 2013-11-06 00:46:10 <sipa> the balance of a wallet is just the sum of the values of the unspent coins assigned to keys your wallet is able to spend from
75 2013-11-06 00:46:28 <lianj> ^
76 2013-11-06 00:46:30 <sipa> but there is no balance anywhere in the system internally
77 2013-11-06 00:46:46 <qwertyoruiop> let's talk theoretically. let's say i take the blockchain 10 blocks before a retarget and let's say i mine those 10 blocks in some amount of time
78 2013-11-06 00:46:46 <sipa> that's only how it is presented by the client
79 2013-11-06 00:47:27 <qwertyoruiop> and put fake timestamps in those blocks to make the difficulty algorithm retarget to a lower difficulty than the one that it really is
80 2013-11-06 00:47:31 <sipa> gwern: a wallet is a set of keys and a set of coins
81 2013-11-06 00:48:01 <sipa> qwertyoruiop: and it wi
82 2013-11-06 00:48:11 <sipa> ll not help you take over the chain
83 2013-11-06 00:48:13 <qwertyoruiop> then keep mining to make sure i can chunk out 1 block every 10 minutes
84 2013-11-06 00:48:23 <sipa> as the nodes look at the total amount of work in a chain
85 2013-11-06 00:48:30 <sipa> not their length in number of blocks
86 2013-11-06 00:50:36 <gwern> alright, so straightforward solutions... the overall wallet balance is the correct balance for me, including the 4btc. the specific address balance is 0 and is wrong but I guess the overall wallet is right. so I can send all the bitcoin to a wallet like blockchain.info and then do a getnewaddress and withdraw all the bitcoin to the newaddress. this avoids messing with the account parameter or dumpprivkey
87 2013-11-06 00:52:10 <gwern> since the recipient address would be generated by blockchain.info's software, there shouldn't be any issues with the wallet internals overwriting or erasing bitcoins, and once the balance has left my local wallet, it should be safe to transfer back in or I can erase the local wallet and start fresh
88 2013-11-06 00:52:46 <c0rw1n> (good thing you have backups)
89 2013-11-06 00:52:51 <qwertyoruiop> isn't amount of work a ratio between how much time it took to generate n blocks and n where n is the number of blocks that have to be found for a retarget?
90 2013-11-06 00:53:09 <sipa> gwern: no need for the coins to leave your walley
91 2013-11-06 00:53:14 <gwern> c0rw1n: yeah, so I can recover from any error but something that gets committed to the network
92 2013-11-06 00:53:25 <sipa> gwern: just send them to an address of your own
93 2013-11-06 00:53:34 <gwern> sipa: that's what started thi whole mess!
94 2013-11-06 00:53:45 <sipa> if you really must have them on a particular address
95 2013-11-06 00:54:09 <sipa> i don't see how coins leaving and entering your wallet changes anything
96 2013-11-06 00:54:23 <qwertyoruiop> i believe he wants to start fresh
97 2013-11-06 00:54:25 <qwertyoruiop> with a new wallet
98 2013-11-06 00:54:31 <qwertyoruiop> to make sure he doesn't have any fuckup
99 2013-11-06 00:54:33 <gwern> well, I did need them on a particular address for the bet, but now I just want to send 3 bitcoins back to the original owners who loaned me them - only to discover all this weirdness
100 2013-11-06 00:55:10 <sipa> qwertyoruiop: work is the sum of the difficulties in the blocks of a chain
101 2013-11-06 00:55:33 <sipa> qwertyoruiop: if you change block's timestamp, it may become easier to mine them, but they become worth less as well
102 2013-11-06 00:55:59 <qwertyoruiop> why is that?
103 2013-11-06 00:56:12 <sipa> to prevent your attack :p
104 2013-11-06 00:57:04 <qwertyoruiop> if i keep my attack secret, mine a block with a transaction that spends all mined coins to an exchange address, get enough blocks to have a bigger chain than the main chain and only then publish the chain
105 2013-11-06 00:57:06 <qwertyoruiop> how can they lose value?
106 2013-11-06 00:57:27 <sipa> lose value?
107 2013-11-06 00:57:29 <sipa> oh!
108 2013-11-06 00:57:35 <qwertyoruiop> you say "worth less"
109 2013-11-06 00:57:39 <sipa> i don't mean worth less in terms of bitcoin
110 2013-11-06 00:57:41 <c0rw1n> supply and demand
111 2013-11-06 00:57:57 <sipa> i mean worth less to nodes deciding which chain to consider the right one
112 2013-11-06 00:58:07 <qwertyoruiop> oh
113 2013-11-06 00:58:11 <sipa> they look at how hard it was to mine a chain
114 2013-11-06 00:58:14 <qwertyoruiop> so if a chain has a lower difficulty
115 2013-11-06 00:58:17 <sipa> not at how long it is
116 2013-11-06 00:58:23 <qwertyoruiop> ah
117 2013-11-06 00:58:31 <qwertyoruiop> interesting
118 2013-11-06 00:58:39 <qwertyoruiop> that's not something i read in the bitcoin whitepaper
119 2013-11-06 00:59:00 <sipa> the paper misses many details that are necessary in practice
120 2013-11-06 00:59:18 <qwertyoruiop> is there a writeup of bitcoin as it is today?
121 2013-11-06 00:59:30 <sipa> github.com/bitcoin/bitcoin :)
122 2013-11-06 00:59:42 <qwertyoruiop> that's helpful
123 2013-11-06 00:59:45 <sipa> whivh is not a useful answer, i know
124 2013-11-06 01:00:05 <sipa> there are some things explained on the wiki, in forum posts and on stackexchamge
125 2013-11-06 01:00:38 <sipa> but no comprehensive complete picture
126 2013-11-06 01:01:31 <qwertyoruiop> hmm, yet if someone faked timestamps in the last retarget cycle to make difficulty skyrocket..
127 2013-11-06 01:01:46 <gwern> so the impression I am getting here is that you guys think that the 4 bitcoins are not actually at risk here and I am just misunderstanding bitcoin and 'sendfrom'?
128 2013-11-06 01:01:52 <qwertyoruiop> would that be feasible?
129 2013-11-06 01:02:05 <qwertyoruiop> gwern: i understood that you have the private key of the addr with the 4btc
130 2013-11-06 01:02:10 <qwertyoruiop> if you do your coins are safe
131 2013-11-06 01:02:11 <qwertyoruiop> don't worry
132 2013-11-06 01:03:26 <qwertyoruiop> http://brainwallet.org/ helps you see if your priv key is the actual priv key for the address in question. detach your box from the internet before using it to prevent possible stolen privkey
133 2013-11-06 01:04:03 <gwern> this has been such a disillusioning experience. I thought I understood bitcoin as a nice system of public/private keys in a double-ledger setup with one's wallet just being a simple map of keys/values
134 2013-11-06 01:04:24 <qwertyoruiop> (gwern, i thought that was the case too)
135 2013-11-06 01:04:30 <gwern> but no, it's something murkier i don't understand at all, apparently
136 2013-11-06 01:04:33 <c0rw1n> it is, but the accounts layer is confusing
137 2013-11-06 01:04:35 <qwertyoruiop> (if that makes you feel less stupid-)
138 2013-11-06 01:04:58 <c0rw1n> hey devs what is the accounts thing for? sets of keys?
139 2013-11-06 01:05:31 <phantomcircuit> c0rw1n, it's an accounting thing
140 2013-11-06 01:05:41 <c0rw1n> yes and?
141 2013-11-06 01:05:43 <phantomcircuit> just as it implies
142 2013-11-06 01:06:04 <c0rw1n> okay now I'm confused
143 2013-11-06 01:06:16 <c0rw1n> (again)
144 2013-11-06 01:06:26 <qwertyoruiop> so a wallet is a set of accounts
145 2013-11-06 01:06:34 <qwertyoruiop> and each account is a set of pub/priv key pairs?
146 2013-11-06 01:06:40 <phantomcircuit> c0rw1n, http://en.wikipedia.org/wiki/Accounting
147 2013-11-06 01:07:31 <c0rw1n> ah so those accounts. I'm MORE confused.
148 2013-11-06 01:07:39 <phantomcircuit> qwertyoruiop, addresses are assigned to accounts, but when you send from an account it can come from any of the unspent transaction outputs in the wallet
149 2013-11-06 01:07:55 <phantomcircuit> the only way in which it is from an account is that an accounting record is added to the wallet
150 2013-11-06 01:08:07 <qwertyoruiop> that honestly makes no sense
151 2013-11-06 01:08:28 <c0rw1n> so gwern could order the 4btc from that .bitcoin to an abitrary address he controls? Right?
152 2013-11-06 01:08:28 <phantomcircuit> qwertyoruiop, it actually does as an accounting system
153 2013-11-06 01:08:57 <phantomcircuit> personally i dont think the accounting system is robust enough for anything serious at all
154 2013-11-06 01:08:59 <qwertyoruiop> so if i have two accounts and send 4 coins to an addr assigned to the first and 7 to an addr assigned to the second
155 2013-11-06 01:09:07 <c0rw1n> (notwithstanding the seven levels of indrections)
156 2013-11-06 01:09:10 <qwertyoruiop> then spend 7 coins from the first account
157 2013-11-06 01:09:18 <qwertyoruiop> i also spend 3 coins from the second one?
158 2013-11-06 01:09:21 <phantomcircuit> qwertyoruiop, you'll have a negative account balance
159 2013-11-06 01:09:23 <c0rw1n> i think you can't
160 2013-11-06 01:09:27 <c0rw1n> wait you can?
161 2013-11-06 01:09:33 <phantomcircuit> c0rw1n, im pretty sure you can
162 2013-11-06 01:09:36 <phantomcircuit> but i might be wrong
163 2013-11-06 01:09:36 <sipa> qwertyoruiop: coins have nothing to do with addresses
164 2013-11-06 01:09:40 <sipa> coins belong to the wallet
165 2013-11-06 01:09:45 <sipa> and nothing else
166 2013-11-06 01:09:51 <sipa> accounts are just numbers
167 2013-11-06 01:09:56 <c0rw1n> wtf devs
168 2013-11-06 01:10:04 <sipa> so if your wallet is shared among several people
169 2013-11-06 01:10:12 <phantomcircuit> qwertyoruiop, the only reason that addresses are assigned to accounts is that it makes the generation of the credit record automatic
170 2013-11-06 01:10:13 <sipa> you know who owns how much of it
171 2013-11-06 01:10:26 <phantomcircuit> beyond that it's just a very simple version of quickbooks
172 2013-11-06 01:10:28 <c0rw1n> sipa why nbot several wallets?
173 2013-11-06 01:10:29 <qwertyoruiop> so this whole account thing
174 2013-11-06 01:10:41 <qwertyoruiop> is just a way to keep track of who spends what
175 2013-11-06 01:10:47 <qwertyoruiop> and a pretty simple one
176 2013-11-06 01:10:47 <sipa> c0rw1n: for almost everything, multiple wallets is the better solution
177 2013-11-06 01:10:56 <qwertyoruiop> it seems pretty pointless IMO
178 2013-11-06 01:11:08 <sipa> it is useful, but only for one specific use case
179 2013-11-06 01:11:11 <phantomcircuit> qwertyoruiop, correct and i agree but other people disagree
180 2013-11-06 01:11:13 <sipa> shared wallets
181 2013-11-06 01:11:15 <c0rw1n> i'm a business owner and it seems pointless to me
182 2013-11-06 01:11:25 <c0rw1n> fwiw
183 2013-11-06 01:11:30 <phantomcircuit> sipa, it's not useful for that at all because of the backup problem
184 2013-11-06 01:11:36 <sipa> phantomcircuit: agree
185 2013-11-06 01:11:59 <phantomcircuit> it's only useful for personal accounting where if you lose all of your records you can recreate them from memory
186 2013-11-06 01:12:03 <phantomcircuit> or other records
187 2013-11-06 01:12:07 <sipa> it's a halfway implemented and confusing system
188 2013-11-06 01:12:09 <phantomcircuit> otherwise it's completely worthless
189 2013-11-06 01:12:11 <sipa> but it does make sense
190 2013-11-06 01:12:22 <qwertyoruiop> it would make sense if it was implemented
191 2013-11-06 01:12:27 <qwertyoruiop> the right way
192 2013-11-06 01:12:42 <phantomcircuit> qwertyoruiop, building a complete and proper accounting system into bitcoind is not a great idea
193 2013-11-06 01:12:43 <qwertyoruiop> but it just seems pointless and confusing as it is right now
194 2013-11-06 01:12:44 <sipa> i don't think the right way is using bitcoind at all for such purposes
195 2013-11-06 01:12:53 <qwertyoruiop> so why is an incomplete one there?
196 2013-11-06 01:12:54 <c0rw1n> so why build accounts into it?
197 2013-11-06 01:13:00 <qwertyoruiop> you should either have it all or none
198 2013-11-06 01:13:05 <sipa> because at a time, someone needed it :)
199 2013-11-06 01:13:23 <sipa> i wasn't even around
200 2013-11-06 01:13:25 <qwertyoruiop> having an halfway completed one seems to contribute to bloat
201 2013-11-06 01:13:29 <firepacket> what is wrong with the accounts system exactly?
202 2013-11-06 01:13:31 <gwern> how old is the account stuff? is it original?
203 2013-11-06 01:13:44 <qwertyoruiop> an user called altoid needed it i guess?
204 2013-11-06 01:13:44 <qwertyoruiop> :p
205 2013-11-06 01:13:47 <c0rw1n> you can't have all of accounting in bitcoind, it wouldn't be compatible with any single tax system anyway
206 2013-11-06 01:14:04 <sipa> gwern: originally bitcoin was a gui-only, windows-only, no-rpc program
207 2013-11-06 01:14:32 <gwern> sipa: I know, but I don't know if this accounting stuff was in the original
208 2013-11-06 01:14:47 <sipa> gwern: threre was no RPC!
209 2013-11-06 01:14:50 <phantomcircuit> firepacket, it's impossible to guarantee that you have a current backup short of making a full backup of your wallet after you assign an address to an account which happens both when you generate a transaction or you receive a transaction with an output you can spend
210 2013-11-06 01:14:52 <c0rw1n> apeared in .8.something
211 2013-11-06 01:14:56 <c0rw1n> afaict
212 2013-11-06 01:15:01 <sipa> accounts only exist in the RPC system
213 2013-11-06 01:15:29 <sipa> accounts were introduced in 0.3.1x i think
214 2013-11-06 01:15:39 <sipa> 0.3.17 or 0.3.18
215 2013-11-06 01:15:52 <sipa> maybe earlier
216 2013-11-06 01:15:56 <firepacket> how is that related to accounting? that is because it doesnt use deterministic wallet generation
217 2013-11-06 01:15:57 <sipa> mid 2010
218 2013-11-06 01:16:17 <sipa> firepacket: what does accounting have to do with key generation?
219 2013-11-06 01:16:29 <firepacket> accounts are just used to organize the addresses in the wallet
220 2013-11-06 01:16:35 <sipa> NO
221 2013-11-06 01:16:37 <qwertyoruiop> no
222 2013-11-06 01:16:40 <qwertyoruiop> that's why it's fucked up
223 2013-11-06 01:16:41 <c0rw1n> no?
224 2013-11-06 01:16:41 <phantomcircuit> sipa, this is part of why i want to remove the feature entirely, it's super confusing to people
225 2013-11-06 01:16:46 <firepacket> ??
226 2013-11-06 01:16:46 <sipa> accounts are just numbrrs
227 2013-11-06 01:16:57 <c0rw1n> yeah, remove that plz, makes zero sense
228 2013-11-06 01:16:58 <qwertyoruiop> you can create 5 accounts and say
229 2013-11-06 01:17:03 <qwertyoruiop> i spend 1 coin from first
230 2013-11-06 01:17:09 <qwertyoruiop> then 2 coins from second etc
231 2013-11-06 01:17:12 <c0rw1n> negative accounts balances wtff
232 2013-11-06 01:17:14 <qwertyoruiop> and you keep track of the expenses
233 2013-11-06 01:17:20 <Belxjander> "key group" assignments?
234 2013-11-06 01:17:22 <qwertyoruiop> and the total wallet had 3 btcs
235 2013-11-06 01:17:25 <phantomcircuit> i've told a number of people not to use the accounts feature for shared wallets and im sure for each of them there's 10 people who didn't go on irc and ask
236 2013-11-06 01:17:25 <sipa> phantomcircuit: in favor
237 2013-11-06 01:17:26 <qwertyoruiop> right?
238 2013-11-06 01:17:42 <phantomcircuit> sipa, now you just have to convince gmaxwell
239 2013-11-06 01:17:42 <qwertyoruiop> so why exactly is it there
240 2013-11-06 01:17:42 <sipa> qwertyoruiop: yup
241 2013-11-06 01:17:43 <phantomcircuit> ACTION runs
242 2013-11-06 01:17:44 <Belxjander> why not just rework the "Accounts" feature as being each "Account" is its own Wallet with a name?
243 2013-11-06 01:17:47 <qwertyoruiop> if noone should even ues it
244 2013-11-06 01:17:50 <qwertyoruiop> *use
245 2013-11-06 01:18:00 <sipa> Belxjander: how about just implementing support for multiple wallets
246 2013-11-06 01:18:06 <qwertyoruiop> you should keep it simple, not bloat bitcoin with half made things that do not work
247 2013-11-06 01:18:15 <c0rw1n> why? just add the keys
248 2013-11-06 01:18:17 <firepacket> i still have no idea what you mean
249 2013-11-06 01:18:20 <sipa> people do use it
250 2013-11-06 01:18:28 <c0rw1n> badly, it seems
251 2013-11-06 01:18:36 <Belxjander> sipa: I'm considering writing a Wallet Application with a background "BitCoinD" as a "FileSystem Handler"
252 2013-11-06 01:18:38 <c0rw1n> srsly, gwern is a smart guy
253 2013-11-06 01:18:40 <firepacket> when running bitcoind for a website, each user account on the site corresponds to an account in bitcoind
254 2013-11-06 01:18:47 <firepacket> its used to make bitcoind multiuser
255 2013-11-06 01:18:51 <sipa> firepacket: yup
256 2013-11-06 01:19:01 <firepacket> okay... so whats the problem?
257 2013-11-06 01:19:02 <sipa> it's a shared-user wallet
258 2013-11-06 01:19:19 <firepacket> it's confusing because they show up as labels?
259 2013-11-06 01:19:26 <sipa> it is comfusing, and it is impossible to backup
260 2013-11-06 01:19:35 <sipa> but it does work for that one purpose
261 2013-11-06 01:19:40 <firepacket> yeah but that's just because the wallet generation isnt deterministic
262 2013-11-06 01:19:55 <sipa> not sure how that is related at all
263 2013-11-06 01:20:01 <firepacket> the way the accounts work isn't related to that
264 2013-11-06 01:20:29 <sipa> ok
265 2013-11-06 01:20:46 <sipa> mixing accounts with label was a bad choice, yeah
266 2013-11-06 01:21:14 <sipa> afk
267 2013-11-06 01:53:21 <andytoshi> http://pastebin.com/AvHbfGAv
268 2013-11-06 01:53:27 <andytoshi> i have a assertation failure
269 2013-11-06 01:54:00 <gmaxwell> andytoshi: you are compiled against the bastardized openssl libraries in fedora.
270 2013-11-06 01:54:13 <gmaxwell> I guess we need to figure out a way to make it refuse to compile.
271 2013-11-06 01:54:19 <andytoshi> cool, i'll fix that then
272 2013-11-06 01:54:20 <andytoshi> thx
273 2013-11-06 01:54:33 <gmaxwell> andytoshi: warren has enbettered libraries.
274 2013-11-06 01:54:46 <andytoshi> ..you may want to just check for EC extensions somehow at runtime and refuse to start
275 2013-11-06 01:54:53 <andytoshi> i have them
276 2013-11-06 01:54:58 <andytoshi> ./configure just did not notice them i think
277 2013-11-06 01:55:31 <andytoshi> because they are in /usr/local/ssl/, and the bastardized libraries are also somewhere
278 2013-11-06 01:58:42 <skinnkavaj> gmaxwell: what is your opinion about PhotoShares?
279 2013-11-06 01:58:51 <gmaxwell> skinnkavaj: never heard of it
280 2013-11-06 01:58:59 <skinnkavaj> gmaxwell: https://bitcointalk.org/index.php?topic=325261.0
281 2013-11-06 01:59:04 <skinnkavaj> its another proof of work
282 2013-11-06 01:59:41 <gmaxwell> oh it's _those people_
283 2013-11-06 01:59:42 <skinnkavaj> gmaxwell: only cpu mining, do you believe that?
284 2013-11-06 01:59:50 <gmaxwell> I will never again review their work, sorry.
285 2013-11-06 02:00:00 <skinnkavaj> gmaxwell: come on
286 2013-11-06 02:00:06 <skinnkavaj> it was not posted by the same guy
287 2013-11-06 02:00:15 <skinnkavaj> i think he hired a guy to come up with photoshares
288 2013-11-06 02:00:18 <skinnkavaj> please review it
289 2013-11-06 02:01:14 <gmaxwell> I reviewed their prior "memory hard" proof of work, and I came up with an algebraic simplification that reduced its memory requirements from 128 mbytes to 8kbytes. I also came up with another attack that let you mine it memory free (though it was sometime incorrect but not enough to matter).
290 2013-11-06 02:01:42 <gwern> ouch. math is hard, let's go shopping...
291 2013-11-06 02:02:01 <gmaxwell> And then I explained this, including with code implementing the attacks. And then they clamed that the code was just a placeholder (nevermind that they'd written pages of text about how awesome their algorithim was, they'd asked for review, etc)
292 2013-11-06 02:02:52 <gmaxwell> Now, I was a bit of a dick in my analysis, but the lesson I walked away from this was that reviewing their work is a waste of time because they won't catch the obvious message: Creating strong cryptographic functions is hard and shouldn't be done except as a very last resort.
293 2013-11-06 02:03:25 <skinnkavaj> gmaxwell: you cannot assume they have not listened to you, don't be so arrogant
294 2013-11-06 02:03:38 <gmaxwell> (and probably shouldn't be done at all except by people with a strong grounding and experience analyzing and breaking other structures)
295 2013-11-06 02:04:02 <sipa> "Everyone is smart enough to come up with a mechanism they themselves can't break."
296 2013-11-06 02:04:03 <gwern> skinnkavaj: hm, sounds like a bet! you can bet gmaxwell say 10btc that if he thoroughly reviews their code and breaks their algorithm again, they will misbehave like before
297 2013-11-06 02:04:06 <gmaxwell> skinnkavaj: they didn't, they rushed out _another_ hastily designed homegrown thing which had little reason for existing.
298 2013-11-06 02:04:08 <andytoshi> skinnkavaj: if the moral is "don't make your own cryptographic functions", and they are now asking for a review of a cryptographic function they made..
299 2013-11-06 02:05:28 <gmaxwell> Yea, my argument wasn't that their function was bad (which it was)... it was they had no need to write their own and _shouldn't be_, because it's hard. I don't even believe I'd do better than them. (well okay, I'd probably do better than /them/ but it's something I avoid doing this).. but it's a message they wouldn't recieve and couldn't recieve because promoting their wizbang function is critical to how they market themselves as better than o
300 2013-11-06 02:05:50 <gmaxwell> (well shouldn't be because its hard and because there are already well known things which work okay)
301 2013-11-06 02:06:05 <sipa> gmaxwell: as better than o[...]
302 2013-11-06 02:06:14 <gmaxwell> as better
303 2013-11-06 02:06:14 <gmaxwell> than other things.
304 2013-11-06 02:06:16 <sipa> (hint: /script load splitlong.pl)
305 2013-11-06 02:06:26 <gwern> ACTION endorses splitlong.pl as well
306 2013-11-06 02:06:34 <gmaxwell> sipa: thanks, I restarted irssi last night. :P
307 2013-11-06 02:06:48 <sipa> gmaxwell: ... why on earth would you do such a thing? :o
308 2013-11-06 02:07:05 <gmaxwell> because I had like 400 windows again.
309 2013-11-06 02:07:25 <sipa> haha
310 2013-11-06 02:07:26 <theorbtwo> /win close, up, enter...
311 2013-11-06 02:07:28 <sipa> i'm at 104
312 2013-11-06 02:07:44 <sipa> theorbtwo: /wc is shorter
313 2013-11-06 02:07:53 <gmaxwell> theorbtwo: quiting is faster once you have 400.
314 2013-11-06 02:08:21 <sipa> if only irssi would re-load history into a window if you rejoin/reopen a channel/pm
315 2013-11-06 02:08:44 <gmaxwell> yea, thats part of how I get so much.
316 2013-11-06 02:27:13 <MC1984_> why dont you just rip them again and claim your 500o dollar then
317 2013-11-06 02:27:16 <MC1984_> assuming theyd pay
318 2013-11-06 02:27:46 <MC1984_> As well as being an altcoin, ProtoShares is a way to own BitShares before they are launched.
319 2013-11-06 02:27:57 <gwern> MC1984_: yeah, I think that' the problem. if they've welshed before, one should only be willing to try if they find a trustworthy escrow/arbitrator...
320 2013-11-06 02:27:57 <MC1984_> yep my big red flag just went up
321 2013-11-06 02:28:16 <MC1984_> welshed?
322 2013-11-06 02:28:29 <B0g4r7> So help me understand this Selfish Mining paper: http://arxiv.org/abs/1311.0243
323 2013-11-06 02:28:46 <B0g4r7> Why are they saying that 33% is enough to pwn the network?
324 2013-11-06 02:28:58 <Luke-Jr> because they're trolls
325 2013-11-06 02:29:09 <B0g4r7> Someone else help me understand plz.
326 2013-11-06 02:29:12 <Luke-Jr> go read the discussion we've already had
327 2013-11-06 02:29:29 <B0g4r7> How far back?
328 2013-11-06 02:29:34 <Luke-Jr> the last 24 hours I think
329 2013-11-06 02:29:55 <B0g4r7> Bah, stupid short buffer.
330 2013-11-06 02:29:57 <gwern> MC1984_: welshed is an old ethnic slur I enjoy using because it doesn't strike most people as a slur. so much the same way as I like to use 'niggardly'
331 2013-11-06 02:30:10 <Luke-Jr> This channel is logged: http://bitcoinstats.com/ | There iâ¦
332 2013-11-06 02:30:13 <gwern> which looks like a slur but isn't one, and dares people to misundertand
333 2013-11-06 02:30:25 <MC1984_> im actually welsh
334 2013-11-06 02:30:33 <gwern> all the better!
335 2013-11-06 02:30:55 <MC1984_> i feel o-offended
336 2013-11-06 02:30:56 <MC1984_> i think
337 2013-11-06 02:30:59 <gwern> ACTION also keeps a stock of anti-dutch slurs. 'dutch courage', 'dutch wife'...
338 2013-11-06 02:31:18 <B0g4r7> I only have 3 hours worth.
339 2013-11-06 02:31:31 <B0g4r7> Maybe my work client has a longer buffer.
340 2013-11-06 02:31:32 <gwern> (and if you use the phrase 'finger in the dike' in spoken conversation, it sounds like you're homophobic!)
341 2013-11-06 02:31:40 <MC1984_> B0g4r7 tldr its a real issue but blown out of proportion
342 2013-11-06 02:32:12 <B0g4r7> hmm, 'k...
343 2013-11-06 02:32:22 <B0g4r7> I guess I'll try and read their whole paper.
344 2013-11-06 02:45:47 <gwillen> Hello bitcoin devs! I have a stuck TX. I used "getrawtransaction" + "sendrawtransaction" to ask -qt to rebroadcast, and it said {"code":-22,"message":"TX rejected"}. (The tx was originally sent from -qt in the GUI.) decoderawtransaction works fine. signrawtransaction with an empty privkey list says "complete:true". What might be occurring?
345 2013-11-06 02:53:26 <lianj> gwillen: prolly already in the memory pool
346 2013-11-06 02:54:05 <gwillen> lianj: It had better already be in the pool, since this is the same bitcoin-qt that generated the transaction :-)
347 2013-11-06 02:54:15 <gwillen> lianj: but I thought I could use sendrawtransaction to ask it to rebroadcast it?
348 2013-11-06 02:54:26 <gwillen> It's got an adequate fee but it's been stuck for hours.
349 2013-11-06 02:54:41 <lianj> nope rebroadcast wont work
350 2013-11-06 02:54:46 <gwillen> ..... neeeeeeevermind, forget I said anything.
351 2013-11-06 02:54:50 <gwillen> It just appeared in a block.
352 2013-11-06 02:54:55 <gwillen> Crisis averted. :-)
353 2013-11-06 02:55:29 <gwillen> lianj: Did it used to work? I found a wiki article claiming it would.
354 2013-11-06 02:55:35 <gwillen> (on bitcoin.it I think, I'd have to go check.)
355 2013-11-06 02:56:06 <lianj> im not totally sure but recall its some kind of bug
356 2013-11-06 02:56:13 <lianj> could be wrong though
357 2013-11-06 03:07:05 <gwillen> lianj: ok, thanks
358 2013-11-06 03:08:22 <andytoshi> is openssl statically or dynamically linked?
359 2013-11-06 03:09:32 <andytoshi> i am still getting this assertation failure even after setting the SSL paths correctly
360 2013-11-06 03:11:40 <andytoshi> wait, i lied, i did not set the CRYPTO paths..
361 2013-11-06 03:15:37 <Luke-Jr> andytoshi: everything *should* be dynamic by default
362 2013-11-06 03:15:41 <Luke-Jr> static linking is just bad
363 2013-11-06 03:16:56 <andytoshi> agreed, but i think it is static nonetheless :P
364 2013-11-06 03:17:14 <EPiSKiNG-> anyone know why this hasn't confirmed yet?? https://blockchain.info/address/1HiuxtBsWPKaqkxJYysrNvuPDQmMnj1vFW
365 2013-11-06 03:17:24 <EPiSKiNG-> looks like several blocks have passed with room for it
366 2013-11-06 03:17:31 <andytoshi> i set CRYPTO_LIBS and CRYPTO_PTAH and SSL_LIBS and SSL_PATH, and it seems to be using the /usr/local/ssl paths now...
367 2013-11-06 03:17:54 <andytoshi> but it'll be another ten minutes before compilation is done so idk
368 2013-11-06 03:28:11 <ekkis> evening everyone? I'm looking for someone worth interviewing. any thoughts?
369 2013-11-06 03:30:45 <Luke-Jr> ekkis: about what?
370 2013-11-06 03:39:05 <ekkis> Luke-Jr: I've been chatting with Scott Hanselman. he wants to interview someone in the bitcoin community. if you don't know him, he's an evangeliser for Microsoft and has a large audience. an interview with him is like having an audience with the pope
371 2013-11-06 03:39:28 <ekkis> he's asked me to introduce him to someone but I don't know anybody, so I thought I'd ask here
372 2013-11-06 03:40:32 <B0g4r7> Gavin seems like a natural choice, if he's available for such.
373 2013-11-06 03:41:39 <Luke-Jr> ekkis: would be fun to slip in a "people should stop using Microsoft products" :D
374 2013-11-06 03:47:59 <lianj> Luke-Jr: just "bitcoin-qt.exe is build on linux" :p
375 2013-11-06 03:48:27 <ekkis> heh? I don't think he'd really care
376 2013-11-06 03:48:38 <Luke-Jr> you just said he's an evangeliser for Microsoft
377 2013-11-06 03:48:46 <ekkis> but it would give bitcoin more visibility
378 2013-11-06 03:49:11 <ekkis> Scott is very active, lots of people watch his videos and subscribe to his tweets
379 2013-11-06 03:49:48 <ekkis> so if you guys know anyone who's core to the project or has been fundamental in some way, let me know
380 2013-11-06 03:50:04 <lianj> like Luke-Jr said, gavin
381 2013-11-06 03:50:14 <ekkis> who is gavin?
382 2013-11-06 03:50:47 <Luke-Jr> ekkis: one of the two bitcoin developers on a salary to work on bitcoin full time
383 2013-11-06 03:51:07 <ekkis> oh, this? http://en.wikipedia.org/wiki/Gavin_Andresen
384 2013-11-06 03:51:20 <ekkis> I see him logged in here?
385 2013-11-06 03:51:41 <ekkis> yip. he certainly seems like _the_ person to talk to
386 2013-11-06 03:52:41 <ekkis> is he reachable here?
387 2013-11-06 03:53:05 <Luke-Jr> probably soon
388 2013-11-06 03:53:13 <Luke-Jr> he usually gets up in an hour or two I think
389 2013-11-06 03:53:25 <lianj> maybe better write a formal email
390 2013-11-06 03:53:30 <ekkis> ah? he's GMT0?
391 2013-11-06 03:53:41 <Luke-Jr> no, Australia
392 2013-11-06 03:53:44 <ekkis> sure? do you have contact info for him?
393 2013-11-06 03:53:55 <Luke-Jr> it's not private info..
394 2013-11-06 03:54:03 <ekkis> ok
395 2013-11-06 03:54:12 <gwern> australia? perhaps gavin was the *real* DPR
396 2013-11-06 03:55:35 <BlueMatt> Luke-Jr: we have two paid devs?
397 2013-11-06 03:55:49 <BlueMatt> ekkis: check out the list at http://bitcoin.org/en/press
398 2013-11-06 03:56:03 <BlueMatt> ekkis: asking people on that list is always the best bet
399 2013-11-06 03:56:07 <Luke-Jr> BlueMatt: jgarzik
400 2013-11-06 03:56:28 <BlueMatt> Luke-Jr: I dont think bitpay pays him to work full-time on bitcoind, afaiu he works on bitpay codebase lots too
401 2013-11-06 03:56:31 <BlueMatt> but I may be wrong
402 2013-11-06 03:57:02 <Luke-Jr> BlueMatt: last I checked, he had near zero involvement in BitPay's normal operations
403 2013-11-06 03:57:59 <Luke-Jr> I get the impression he just works on whatever he wants Bitcoin-related, and is available to them if they have emergencies/questions/etc
404 2013-11-06 03:58:08 <melvster> ;;bids 266
405 2013-11-06 03:58:11 <gribble> There are currently 0 bitcoins demanded at or over 266.0 USD, worth 0.0 USD in total. | Data vintage: 0.0042 seconds
406 2013-11-06 03:58:20 <lianj> Luke-Jr: think so too
407 2013-11-06 03:58:37 <melvster> ;;asks 266
408 2013-11-06 03:58:38 <gribble> There are currently 1445.6042 bitcoins offered at or under 266.0 USD, worth 382161.363132 USD in total. | Data vintage: 27.4152 seconds
409 2013-11-06 04:31:37 <ekkis> Luke-Jr: ok. I wrote Gavin and mentioned you suggested him as an ideal candidate. we'll see if he replies...
410 2013-11-06 04:32:03 <gavinandresen> he never replies to ANYTHING....
411 2013-11-06 04:33:17 <ekkis> gavinandresen: haha? you're awake. did you see my mail?
412 2013-11-06 04:33:47 <gavinandresen> just got back from lunch, haven't read email yet...
413 2013-11-06 04:34:11 <Luke-Jr> ekkis: that was actually B0g4r7 I think, but Gavin's a good candidate ;)
414 2013-11-06 04:35:09 <ekkis> oh, it's the middle of your day. I've been talking with Scott Hanselman who'd like to interview someone on the subject of bitcoin. In case you don't know the name, he's a big evangelist for Microsoft and has a quite large following. you'd be an ideal candidate and I wondered if you'd be up for it
415 2013-11-06 04:35:45 <gavinandresen> ekkis: sure, have him email me: gavin@bitcoinfoundation.org
416 2013-11-06 04:36:04 <ekkis> awesome. here's a bit of info on scott: http://www.hanselman.com, if you care
417 2013-11-06 04:36:22 <ekkis> thanks!! and take care for now
418 2013-11-06 04:37:10 <andytoshi> ;;bc,blocks
419 2013-11-06 04:37:11 <gribble> 268183
420 2013-11-06 04:37:49 <ekkis> ACTION has a pretty good notion that an interview with gavinandresen is not insubstantially less difficult than an audience with the pope
421 2013-11-06 04:38:29 <gavinandresen> I'm much easier to talk with than the pope. I don't even make you kiss my ring.
422 2013-11-06 04:38:42 <ekkis> haha
423 2013-11-06 04:39:07 <gwern> perhaps off topic, but I just learned my credit union has been charging me $1.5 when I look up my balance at an atm. I hope bitcoin puts all the banks out of business
424 2013-11-06 04:40:05 <ekkis> gwern: it will. I have little doubt of it
425 2013-11-06 04:40:30 <cazalla> gwern: that's common practice
426 2013-11-06 04:40:47 <gwern> cazalla: yes. that's why I said 'all', not 'my'
427 2013-11-06 04:41:24 <cazalla> l2onlinebanking
428 2013-11-06 04:42:08 <gwern> (got locked out years ago by anti-hacking measures and no longer live in the state so I can physically visit a branch and reset my account)
429 2013-11-06 04:42:31 <cazalla> l2bitcoin then :P
430 2013-11-06 04:42:39 <ekkis> this technology is going to change everything. it's the beginning of the end. it will defund governments and displace the ruling elite, giving the power to the common man. it means the end of currency devaluation and the sacking of the wealth of nations by the few. it means the end of war
431 2013-11-06 04:43:03 <gwern> cazalla: oh, I do. but I still have to pay rent and buy groceries in dollars
432 2013-11-06 04:43:10 <Belxjander> gwern: I have to visit my bank back in NZ to sort out the new chipped card they sent me and set the pin number on it (currently its entirely useless as a card as I can not set a pin without a physical visit)
433 2013-11-06 04:43:48 <Belxjander> gwern: so I can understand how annoying a lack of access to your own accounts can be
434 2013-11-06 04:44:22 <gwern> yeah. I'm thinking of opening an account at a local credit union. this nickel-and-diming drives me nuts
435 2013-11-06 04:45:22 <Belxjander> gwern: I have 3 Bank accts back in NZ and 2 bank accts here in Japan...
436 2013-11-06 05:04:29 <mrkent> Anyone going to the december vegas conference?
437 2013-11-06 05:05:14 <ekkis> I really should
438 2013-11-06 05:06:47 <Luke-Jr> I think I'm all conferenced out
439 2013-11-06 05:07:53 <ekkis> yeah. I know the feeling. I've been lying low, focusing on code instead
440 2013-11-06 05:10:25 <Luke-Jr> what coding do you do?
441 2013-11-06 05:10:53 <groglogic> any interest in seeing a kind of beefy "white hat" attack sandbox/service for Bitcoin? for regressions but also for testing attack theories that invevitably come up. test >> code >> theory. probably building on 'testnet', but with lots more stuff. i can write up a detailed proposal for dev feedback. maybe pitch to BF for funding... reactions? if this exists already too, let me know
442 2013-11-06 05:11:26 <Luke-Jr> groglogic: how is it any different from testnet? :p
443 2013-11-06 05:12:45 <groglogic> Luke-Jr: good question. but from my early impressions of it, it would be a superset of what it provides/enables. from everything i've read/seen about testnet, it's not doing what I'm envisioning
444 2013-11-06 05:17:52 <soixante> hi ⦠what is doing to solution BTC selfish miner ?
445 2013-11-06 05:18:20 <justusranvier> Anyone want to speak in Austin next March 6th, the Thursday before SXSW?
446 2013-11-06 05:18:53 <groglogic> ekkis: i like your opimism/vision there, but never underestimate a nation state with a large powerful military, ruled by lawyers ;-)
447 2013-11-06 05:19:17 <groglogic> ekkis: and arguably bankers, etc.
448 2013-11-06 05:20:26 <groglogic> soixante: people are analyzing it and there are more detailed discussions on bitcointalk and the mailing list
449 2013-11-06 05:21:10 <ekkis> groglogic: militaries are powerless in cyberspace
450 2013-11-06 05:21:36 <ekkis> soixante: it's not a real threat
451 2013-11-06 05:22:11 <ekkis> groglogic: yes, nations would seek to destroy the system but even in that, they're divided. China for example, has all but endorsed it by now
452 2013-11-06 05:23:53 <groglogic> ekkis: all this cyberspace runs on hardware in meatspace, where people with guns can come and f*ck shit up, at will
453 2013-11-06 05:26:20 <groglogic> I personally think that as long as at least 1 modern high-tech nation with a big military backs or allows Bitcoin, it will survive. that may be the US gov, that may be China, who knows. as with the "incentive" architecture of Bitcoin itself, I think as long as something makes it in a nation's leadership best interests to allow (or at least not fuck with) Bitcoin, it will survive. turn any serious potential enemies in
454 2013-11-06 05:26:21 <groglogic> to allies, in other words
455 2013-11-06 05:28:26 <owowo> To the moon!!! â(°0°)â
456 2013-11-06 05:28:29 <owowo> :P
457 2013-11-06 05:29:21 <groglogic> taxation is one big potential threat/opportunity (ala the ancient Chinese: crisis = opportunity). starving governments of taxation revenue is a threat to them. however if you flip that on its head and devise a way to build-in automatic taxation, you could not only mitigate that threat, you also have the upside of, say, automating taxes (hear "tax" think "fee"; same math-wise, just questino of where it pays out to)
458 2013-11-06 05:29:47 <ekkis> groglogic: yes but to destroy bitcoin they'd need to destroy the internet and remember that DARPA designed it primarily with the notion that the system should widthstand substantial damage. it's resilient. aside from that, destroying the net would mean destroying so much more than bitcoin
459 2013-11-06 05:30:16 <Luke-Jr> ekkis: it would be trivial for most governments to destroy Bitcoin right now
460 2013-11-06 05:30:56 <groglogic> Luke-Jr: I think it would be hard for Lichteinstein to do. impossible for the Vatican
461 2013-11-06 05:31:25 <owowo> dude, do not underestimate old men loving young ones!
462 2013-11-06 05:31:42 <ekkis> groglogic: aside from that, a contingency of small nations, each of whose governments are sufficiently powerless to interfere with it is giving rise to a user base. look at India, the Argentine, a lot of the Africas, where currencies are for shite and BTC provides a great alternative
463 2013-11-06 05:31:49 <Luke-Jr> groglogic: I said most, not all.
464 2013-11-06 05:31:54 <groglogic> i never underestimate the power of old gay men wearing bright red cloaks
465 2013-11-06 05:32:24 <groglogic> Luke-Jr: I know. was having fun
466 2013-11-06 05:32:50 <ekkis> groglogic: automating taxes. there's a thought
467 2013-11-06 05:33:27 <ekkis> Luke-Jr: so long as there's at least one copy of the blockchain somewhere in the world and of the source code, the whole thing can spring right back up after a major assault
468 2013-11-06 05:33:44 <ekkis> so I'm not convinced that the system is that vulnerable
469 2013-11-06 05:33:53 <gmaxwell> This is offtopic for #bitcoin-dev.
470 2013-11-06 05:34:35 <ekkis> yes, you're right. sorry about that
471 2013-11-06 05:34:40 <groglogic> ekkis: totally. i've got an incomplete sketch of what such a system would look like. challenging parts are things like taxing real property, and taxing the exchange of real property, or deeds/instruments. not impossible, just harder. pretty easy to build-in automatic tax extraction of money-only exchanges
472 2013-11-06 05:35:15 <gmaxwell> I suggest moving the conversation to #bitcoin
473 2013-11-06 05:35:29 <groglogic> gmaxwell: sorry. you're right. myself i thought i was in #bitcoin. :-(
474 2013-11-06 05:36:30 <gmaxwell> Happens to me all the time.
475 2013-11-06 05:36:50 <ekkis> the "contract" support in the protocol is very interesting. I haven't spent much time with scripting yet but the project I'm working on will benefit from that? in fact I have a killer app for those scripting facilities
476 2013-11-06 05:37:38 <groglogic> gmaxwell: i once got #kitties mixed up with #quantum-mechanics ... but nobody could tell the diff
477 2013-11-06 05:38:04 <Luke-Jr> â¦
478 2013-11-06 05:38:14 <gmaxwell> Your jokes were simultaneously alive and dead?
479 2013-11-06 05:38:29 <ekkis> I'm not ready yet but at some point I'll come back for guidance. I did work in Forth a long time ago
480 2013-11-06 05:38:36 <groglogic> simultaneously both funny and not. </off-topic-further>
481 2013-11-06 05:38:57 <ekkis> all right. good night everyone. back to code
482 2013-11-06 05:59:58 <toffoo> days like this make me want to kiss gavinandresen's ring
483 2013-11-06 06:07:13 <owowo> ya, days like when you order a triple grande cappucino at starbucks and you pay 55! cent more then the week before, inflation. Would not have happened if they would take Bitcoin.
484 2013-11-06 06:08:09 <owowo> but hey, govt. says: "There is no inflation."
485 2013-11-06 06:08:45 <owowo> I must be imagining things again.
486 2013-11-06 06:21:03 <BlueMatt> can someone addnode public.us-east.relay.mattcorallo.com:8334 or public.eu.relay.mattcorallo.com:8334 (mainnet, despite what the port indicates) so I can make sure its all working?
487 2013-11-06 06:22:35 <BlueMatt> or port 8335
488 2013-11-06 06:26:57 <Tril> bluematt trying.
489 2013-11-06 06:30:08 <Tril> BlueMatt I'm connected to both and not receiving any blocks it appears
490 2013-11-06 06:30:37 <BlueMatt> Tril: yes, they do not forward blocks normally, they will only forward new blocks/txn
491 2013-11-06 06:30:46 <BlueMatt> and no txn on port 8334, only txn on 8335
492 2013-11-06 06:30:51 <BlueMatt> (see ml post for details)
493 2013-11-06 06:32:56 <Tril> so they will send me new blocks?
494 2013-11-06 06:33:13 <BlueMatt> if they're working right, yes
495 2013-11-06 06:40:32 <Tril> BlueMatt: yeah, I just got that block sent from both
496 2013-11-06 06:40:41 <BlueMatt> nice, thanks for testing
497 2013-11-06 06:40:53 <BlueMatt> ACTION -> bed
498 2013-11-06 06:40:53 <Tril> 2nd one got marked as misbehaving since I had the block.
499 2013-11-06 06:40:57 <Tril> yw
500 2013-11-06 06:41:01 <BlueMatt> did it get a dos score?
501 2013-11-06 06:41:07 <Tril> 0 -> 0
502 2013-11-06 06:41:12 <BlueMatt> ok, yea, makes sense
503 2013-11-06 06:41:18 <BlueMatt> as long as it doesnt get a dos score thats fine
504 2013-11-06 06:58:01 <Tril> BlueMatt: while syncing blockchain it sends a copy to your relay node
505 2013-11-06 06:58:09 <Tril> slowing the sync down
506 2013-11-06 07:23:53 <Tril> I suspect this means every peer will send you every new block, too, I think you're dossing yourself by announcing you have 0 blocks
507 2013-11-06 07:26:55 <gmaxwell> Tril: announcing you have zero blocks does nothing.
508 2013-11-06 07:27:09 <gmaxwell> Tril: why do you believe that you're sending blocks to him?
509 2013-11-06 07:28:04 <Tril> tcpdump.
510 2013-11-06 07:29:34 <gmaxwell> Tril: what are you actually seeing in tcpdump?
511 2013-11-06 07:30:44 <Tril> I had client behind a few days and peered only to Matt, it received new blocks, then I added a peer with actual blocks and it started sending a lot of packets to Matt. I didn't verify the actual block was being sent but it was definitely wasting my bandwidth so I shut off the peer
512 2013-11-06 07:32:09 <gmaxwell> Tril: it should have been sending INVs to matt and thats it.
513 2013-11-06 07:32:21 <gmaxwell> (for each of the new blocks as it accepted them)
514 2013-11-06 07:40:52 <Tril> maybe. is there a wireshark module or something I can monitor that? I forgot the protocol is binary
515 2013-11-06 07:47:08 <Luke-Jr> Tril: yes.
516 2013-11-06 08:03:25 <MarkProffitt> Can someoen answer som questions about this Greedy Miner issue? I'm particularly interested in the risk of double spending rather than people getting more coins.
517 2013-11-06 08:04:19 <gmaxwell> MarkProffitt: I answered your question some time ago in #bitcoin.
518 2013-11-06 08:04:53 <MarkProffitt> I didn't see any answer
519 2013-11-06 08:05:07 <MarkProffitt> I saw some insults and orders to leave
520 2013-11-06 08:05:45 <gmaxwell> 23:47 <@gmaxwell> MarkProffitt: thats not really the kind of issue they're claiming. It's basically an argument that the incentives encourage the mining to be eventually controlled by one party... which would break our decenteralization assumptions.
521 2013-11-06 08:05:49 <gmaxwell> 23:48 <@gmaxwell> MarkProffitt: but they appear to have significantly overhyped the concern, even within that narrow demain, and technical verdicts are mixed if there is even an issue at all. The underlying thing they're wiring about has been known since 2010.
522 2013-11-06 08:06:23 <MarkProffitt> My question IS
523 2013-11-06 08:06:24 <MarkProffitt> aoeu: this is off the original topic a bit but if a group can gain control, I see a potential for a government to do that not to get value of the coins but to ruin the value. Since they have unlimited (stolen) resources they have a very good incentive.
524 2013-11-06 08:07:05 <MarkProffitt> Is there a way to detect that? If so, is there a defense?
525 2013-11-06 08:07:52 <gmaxwell> Detect _what_?
526 2013-11-06 08:09:22 <gmaxwell> MarkProffitt: The subject of the paper you're asking about is that the authors argume that if a cartel of miners performs a certian attack it is more profitable for miners to join the cartel to mine alone, and eventually there would only be the cartel. This isn't just "foo gains control".
527 2013-11-06 08:09:35 <gmaxwell> And, if it's possible, it's highly highly detectable.
528 2013-11-06 08:22:00 <UukGoblin> gmaxwell, ah, nice, that's exactly what I suggested to conman yesterday ;)
529 2013-11-06 08:22:35 <UukGoblin> well, I suggested to have cgminer do this
530 2013-11-06 08:22:47 <gmaxwell> UukGoblin: yea, luke implemented that eons ago.
531 2013-11-06 08:22:49 <UukGoblin> i.e. submit blocks straight to bitcoind
532 2013-11-06 08:22:50 <Belxjander> Hello UukGoblin
533 2013-11-06 08:23:18 <UukGoblin> cool
534 2013-11-06 08:23:21 <UukGoblin> hi :)
535 2013-11-06 08:26:32 <MarkProffitt> gmaxwell, before I ask anymore questions, is English your first language?
536 2013-11-06 08:27:03 <gmaxwell> MarkProffitt: Do many non-native speakers use repeated-word emphasis?
537 2013-11-06 08:29:47 <MarkProffitt> I have read in multiple places that the BitCoin protocol can be disrupted in some way if a large number of users collude. One amount suggested that it would require 51% to cause the problem.
538 2013-11-06 08:30:21 <MarkProffitt> If that occurs, what does it allow? How could it be detected? Is there a defense?
539 2013-11-06 08:32:12 <gmaxwell> MarkProffitt: Bitcoin is a system which is broadly autonomous zero-trust: Each system independently validates the rules; But the ordering of transactions cannot be decided autonomously for fundamental reasons, and so it uses a consensus process to decide the transaction ordering.
540 2013-11-06 08:32:58 <gmaxwell> MarkProffitt: Of course, any consensus process which didn't have the consensus controlled by a majority would just beâ by definitionâ subject to control by a minority... which is hardly better.
541 2013-11-06 08:33:45 <gmaxwell> MarkProffitt: in bitcoin the "majority" is one over computing powere being applied to authenticate the historyâ though computing power is a bit fuzzy, its more accurate to think of it as consensus of the majority of energy spent authenticating the history.
542 2013-11-06 08:34:50 <gmaxwell> If someone spends more energy (in the forum of computational solutions) on an alternative history, sum total, than the existing oneâ then they can replace the existing one. The replacement, of course, must conform to all the rules, but it may play out transactions in a different order and thus change who gets paid.
543 2013-11-06 08:36:36 <gmaxwell> As you might be sensing from my comment above about consensus and majority and minorities, there isn't really much that can directly be done about that. All security systems have assumptions, Bitcoin's assumptions include that no coalition of dishonest parties controls the majority of computing power being applied to it, nor can the honest pariticipants be substantially prevented from commuincating.
544 2013-11-06 08:37:30 <gmaxwell> How altruistic vs self-interested the "honest" parties are required to be for the systme to be long term stable is something of an open question.
545 2013-11-06 08:37:46 <MarkProffitt> " Bitcoin's assumptions include that no coalition of dishonest parties controls the majority of computing power" <-- What happens if that assumption is flase?
546 2013-11-06 08:38:39 <MarkProffitt> If I understand correctly there two different scenarior: 1) before all coins are mined; 2) after all the coins have been mined
547 2013-11-06 08:38:52 <gmaxwell> MarkProffitt: the dishonest group can rearrage transactions after users though they were settled, redirecting funds. They can also block transactions. Depending on how much of a majority they have and can keep it, they can replace transactions back in time, though it takes more and more work to go futher back.
548 2013-11-06 08:39:32 <gmaxwell> MarkProffitt: the rate subsidy (newly created coins) falls off geometrically over timeâ halving every 4 years, so there aren't just two states.
549 2013-11-06 08:39:48 <MarkProffitt> Does that mean they are effectively taking coins away from people?
550 2013-11-06 08:40:41 <MarkProffitt> "voiding checks" ?
551 2013-11-06 08:40:44 <gmaxwell> MarkProffitt: Say they pay you, then they replace history where they first paid those same coins to me. The system's rules doesn't allow the same coin to be spent twice, so in the new history the payment to you is prevented. You would see the coins go away.
552 2013-11-06 08:41:26 <gmaxwell> It would have to be their own coins, or coins of someone who was cooperating with them... they can't freely write history: it must agree with the rules since every node imposes all the rules for themselves.
553 2013-11-06 08:41:41 <MarkProffitt> So it is counterfiting, but the technicalities cause it to happen in revierse
554 2013-11-06 08:42:04 <gmaxwell> MarkProffitt: well, it's not counterfiting in that the total number of coins is not increased.
555 2013-11-06 08:42:15 <MarkProffitt> Yes, I was making an analogy
556 2013-11-06 08:42:23 <gmaxwell> It's like writing a check with invisible ink where the payee changes later. :)
557 2013-11-06 08:42:42 <MarkProffitt> OK, yes, that is my understanding
558 2013-11-06 08:43:04 <MarkProffitt> What would indicate that was happening?
559 2013-11-06 08:43:13 <phantomcircuit> MarkProffitt, it's the equivalent of a chargeback
560 2013-11-06 08:43:24 <phantomcircuit> except it would be exceptionally difficult to do
561 2013-11-06 08:43:32 <gmaxwell> in any case, it all follows naturallyâ physics prevents a globally consistent autonoymous view of ordering, so they "vote" on the order... and if you're the majority in a vote... well, there you go.
562 2013-11-06 08:43:35 <phantomcircuit> more so than reversing an international wire transfer
563 2013-11-06 08:43:54 <gmaxwell> MarkProffitt: people would observe large reorginizations of the chain... one history being replaced with another.
564 2013-11-06 08:44:17 <gmaxwell> Plus the people who got ripped off would presumably notice. :) (the software keeps track of the revoked payment, showing it as 0-confirms forever after)
565 2013-11-06 08:44:27 <MarkProffitt> So one way to watch for that is to keep arichived copies of the chain for comparisons?
566 2013-11-06 08:44:51 <gmaxwell> all nodes save all blocks they see, they never delete any of them even if they're abandoned.
567 2013-11-06 08:44:55 <gmaxwell> so they're already doing this.
568 2013-11-06 08:45:08 <gmaxwell> There are some webpages that visualize chain reorgs, e.g. http://blockchain.info/orphaned-blocks
569 2013-11-06 08:45:47 <gmaxwell> (because the speed of light / communications is finite there is normally a small amount of reorginization, this is why its recommended that transactions not be considered fully settled with an untrusted counterparty until after several confirmations)
570 2013-11-06 08:45:48 <MarkProffitt> So "re-writes" are already detected
571 2013-11-06 08:46:12 <gmaxwell> MarkProffitt: yes, and logged, and stored and tracked, etc.
572 2013-11-06 08:47:00 <gmaxwell> they can be triggered by techinical bugs (though in those cases the parallel chains are almost identical and so there is no theft there), so many people are watching for ones which are unusually long.
573 2013-11-06 08:47:25 <gmaxwell> (1 deep rewrites happen a couple times a day, 2 deep is more rare, beyond that they're worth inspecting manually)
574 2013-11-06 08:47:41 <MarkProffitt> So, if this is happening, the wallets and maybe IP address involved would need to be changed or else they could be recognized as bad actors through statistics?
575 2013-11-06 08:48:36 <gmaxwell> MarkProffitt: presumably anyone smart (? welll, really resourceful) enough to make trouble that way would not be easily identified by any simple characteristic like that.
576 2013-11-06 08:49:29 <gmaxwell> already standard software mines every block do a different address (in bitcoin the _only_ source of privacy is pseudoanonymity, so generally users are recommended to use a new address for each transaction)
577 2013-11-06 08:49:34 <MarkProffitt> I know of several groups with the resources to do that, so I'm wondering if there is a way to counteract the problem.
578 2013-11-06 08:50:14 <gmaxwell> There isn't. But generally "groups" with resources to do that (in particular with impunity) have much easier avenues available to undermine Bitcoin, for example, by making it unlawful.
579 2013-11-06 08:50:58 <MarkProffitt> That worked so well for everything else :P
580 2013-11-06 08:52:13 <MarkProffitt> One problem is "charge backs". Anything else they could do?
581 2013-11-06 08:52:31 <gmaxwell> 21:43 < gmaxwell> ekkis: but it's less good even as that if its liquidity is hurt... I like to point out: Illicitly copied movies still make you laugh, unlawful drugs still get you high. These things work even if no one you know will partake... but outlaw money? Money like goods get their value from people's willingness to accept them. Even outlaws have little use for an outlaw money, since they need to pay for rent and food and such.
582 2013-11-06 08:53:21 <gmaxwell> 21:44 < gmaxwell> ekkis: Also, from a technical perspective, Bitcoin's security model _requires_ the conspicious expendature of energy... it's not secure if driven too far underground.
583 2013-11-06 08:53:25 <gmaxwell> :)
584 2013-11-06 08:54:04 <MarkProffitt> Is that true after all the coin have been mined?
585 2013-11-06 08:54:07 <gmaxwell> MarkProffitt: a majority cartel can block transactions that they don't like (... assuming they can identify them, this may be non-trivial if users use bitcoin correctly with a new address for every transaction)
586 2013-11-06 08:55:05 <gmaxwell> MarkProffitt: Yes. The creation of new coin is 'just' an (important) side effect. Mining exists for the purpose of securing the transaction history, the coins had to be released somehow and so giving it to the miners aligns the incentives (mostly).
587 2013-11-06 08:55:36 <gmaxwell> (First and foremost mining is the computational vote that determines the consensus transaction order!)
588 2013-11-06 08:56:30 <gmaxwell> perhaps someday Bitcoin is "too big to fail"â too economically significant to too many people to be simply regulated away. That day surely isn't today, however. :)
589 2013-11-06 08:57:06 <gmaxwell> And maybe it might limp along underground otherwise... but its hard to say how useful or secure it would be in such a state.
590 2013-11-06 09:04:39 <MarkProffitt> Who determines the $/BitCoin price?
591 2013-11-06 09:04:50 <sipa> you
592 2013-11-06 09:05:05 <MarkProffitt> So that has no connection to the protocol?
593 2013-11-06 09:05:11 <sipa> the price is what people agree about to pay for it
594 2013-11-06 09:05:19 <sipa> who sets the gold price?
595 2013-11-06 09:05:44 <sipa> it has nothing to do with the protocol indeed
596 2013-11-06 09:06:03 <MarkProffitt> I'm thinking about a different issue now.
597 2013-11-06 09:09:34 <gmaxwell> MarkProffitt: what determines the price of a share of IBM stock?
598 2013-11-06 09:10:23 <MarkProffitt> Some code at the NYSE
599 2013-11-06 09:10:38 <gmaxwell> ...
600 2013-11-06 09:10:46 <gmaxwell> ACTION gives up
601 2013-11-06 09:11:44 <MarkProffitt> That is a weak point in lots of trading systems
602 2013-11-06 09:12:34 <MarkProffitt> Of course that has nothing to do with BitCoin protocol.
603 2013-11-06 09:13:16 <gmaxwell> MarkProffitt: people open orders offering to buy or sell at prices they specify. (an order book). Other people come along and choose to trade at the best available prices or open more orders. The exchange sites report the order books and the sequences of trades, along with a last price (and weighed average, etc)
604 2013-11-06 09:13:29 <gmaxwell> and this has nothing to do with the Bitcoin protocol.
605 2013-11-06 09:13:50 <gmaxwell> Bitcoin is bitcoin, it doesn't give a flying@#$@# how many seashells you think its worth today. :)
606 2013-11-06 09:15:28 <MarkProffitt> There is a very big problem in that to solve, but I'm too busy with other things to deal with that anytime soon.
607 2013-11-06 09:15:57 <MarkProffitt> gmaxwell, thanks for all of the information
608 2013-11-06 09:16:00 <sipa> MarkProffitt: unsure what problem you are talking about.
609 2013-11-06 09:16:39 <sipa> if you mean price volatility, the only thing that will improve upon that is growing the (native) Bitcoin economy
610 2013-11-06 09:16:41 <MarkProffitt> sipa, causing financial stampedes.
611 2013-11-06 09:17:13 <sipa> that again has nothing to do with the protocol, and certainly nothing we can change throiugh software
612 2013-11-06 09:17:42 <MarkProffitt> You can change it through software, but I'm not sure how at the moment.
613 2013-11-06 09:18:19 <sipa> good; bring it up again when you know how
614 2013-11-06 09:18:46 <MarkProffitt> I might, would someone here be interested in coding it?
615 2013-11-06 09:19:42 <sipa> if you really convince me that something is a good idea, i will certainly consider coding it
616 2013-11-06 09:19:55 <MarkProffitt> BitCoin actually does reduce the problem a little
617 2013-11-06 09:20:20 <sipa> but i'm extremely sure that you cannot fix price stability through the client software
618 2013-11-06 09:20:59 <MarkProffitt> Its not an issue of stability, its an issue of tricking people into a herd action.
619 2013-11-06 09:21:18 <sipa> oh, you want to fix human sociology? :)
620 2013-11-06 09:21:19 <MarkProffitt> Pump & dump
621 2013-11-06 09:21:55 <sipa> again, i fail to see what the client code has anything to do with it
622 2013-11-06 09:22:06 <MarkProffitt> If the currency used is BitCoins then fake transactions are much less likely, that reduces how much can be done.
623 2013-11-06 09:22:44 <sipa> right
624 2013-11-06 09:23:17 <MarkProffitt> Think about how gold or silver prices are manipulated today. There is far more metals contracts than actual metal.
625 2013-11-06 09:23:42 <MarkProffitt> Some insiders, possibly at the exchanges allow that to occur.
626 2013-11-06 09:26:14 <MarkProffitt> Someone at an exchange could enter a transaction that never occurred, cause people to believe the price had changed and when they start trading on that false belief the insider can cash out and maybe make the fake trade real to hide the fraud.
627 2013-11-06 09:26:35 <MarkProffitt> That is not possible with BitCoin
628 2013-11-06 09:29:44 <MarkProffitt> Some sort of distributed $ / BitCoin trading system could deal with manipulations but I don't think people want to record how they spent their BitCoins. But maybe they would for currency exchanges.
629 2013-11-06 09:31:08 <MarkProffitt> I'm just saying this off the top of my head so feel free to point out any flaws.
630 2013-11-06 09:31:15 <gmaxwell> MarkProffitt: trade frontrunning generally doesn't work, because people will know if they had orders that didn't execute even though the last price crossed them, as its required that the best price executes first.
631 2013-11-06 09:32:05 <MarkProffitt> You are assuming the rules are being followed by the "referee"
632 2013-11-06 09:32:18 <MarkProffitt> I'm assuming well placed fraud
633 2013-11-06 09:36:08 <MarkProffitt> Here is a suggestion to prvent that. How about extending a BitCoin transaction with another amount and unit, such as "999, USD" which also gets included for hashing so it can be confirmed later. That would make all such transactions public and still pseudo anaonymous.
634 2013-11-06 09:36:49 <MarkProffitt> It doesn't need to be the same protocol as BitCoin, it could be a parallel system.
635 2013-11-06 09:37:07 <gmaxwell> ACTION makes a bunch of transactions marked 1.0 BTC 99999999999999999999999999999999999999.99 USD.
636 2013-11-06 09:38:45 <MarkProffitt> gmaxwell :))
637 2013-11-06 09:41:18 <Mike_B> test
638 2013-11-06 09:41:25 <Mike_B> aha, now i can talk :)
639 2013-11-06 09:41:31 <Mike_B> i was like shit, why is everyone just ignoring me?
640 2013-11-06 09:41:57 <Mike_B> gmaxwell, i saw your response to the selfish-mine thing. thought it was very good - if someone can pull off a huge sybil attack to segregate miners from one another, selfish-mine is the least of anyone's worries
641 2013-11-06 09:42:06 <Mike_B> but i was curious why you thought the proposed solution of having nodes relay all blocks (instead of just the first they see) would lead to more problems?
642 2013-11-06 09:42:44 <gmaxwell> Mike_B: well a couple things, their solution wasn't just relay all but to pick blocks randomly to mine on next. This actually _removes_ the incentive to announce your blocks quickly.
643 2013-11-06 09:43:43 <Mike_B> gmaxwell: for which party - the honest miners or the selfish miners?
644 2013-11-06 09:43:49 <gmaxwell> Relaying by itself has two (minor) problems: one is that its potential dos attack vector (though perhaps that can be engineered around), and two is a bit more subtle. Bitcoin is a consensus system, it's trying to get all nodes onto the same state and thats very important. It is not in a nodes self interest to help a neighbor reach a different state than its on.
645 2013-11-06 09:44:19 <gmaxwell> Mike_B: for all miners. Basically it enables their attack absent the sybils, at least for sufficiently large miners.
646 2013-11-06 09:44:37 <Mike_B> gmaxwell: don't the honest miners still have an incentive to announce their blocks quickly so that they reap the block reward?
647 2013-11-06 09:44:38 <gmaxwell> Because you can announce your block way late and still be the preferred next block for half the network.
648 2013-11-06 09:45:44 <Mike_B> ok, i see what you mean
649 2013-11-06 09:45:53 <gmaxwell> Mike_B: to be rewarded your block must be the survivor in the chain. You announce fast, then someone else delays and announces later. Half the network switches to try to extend the later block (even you, in their proposal!). If that block gets extended instead of yours then it gets rewarded.
650 2013-11-06 09:46:21 <midnightmagic> Mike_B: Additionally, if everyone announced late, there would be more reorgs, which means the effective hashrate of bitcoin would be less, which means the blockchain isn't as strong as it could otherwise have most-efficiently been.
651 2013-11-06 09:46:38 <Mike_B> did the proposed solution have a cap on how late you can announce a block?
652 2013-11-06 09:46:51 <Mike_B> like for instance, say i announce a solution to an alternate block #2
653 2013-11-06 09:47:11 <gmaxwell> changing that decision to something else is actually a frequent bad suggestion. (People make it when they realize that propagation differences results in the network randomly being split brain from time to time, so they suggest instead to pick based on block ID) so I've actually responded to _that_ point a couple times, and even run simulations of it.
654 2013-11-06 09:47:34 <gmaxwell> (basically in a network with latency, picking the first block you hear is uniquely good for convergence time)
655 2013-11-06 09:47:45 <Mike_B> does the proposed solution expect honest miners would randomly try working on my forked block #2 in addition to whatever the latest normal block is?
656 2013-11-06 09:47:51 <gmaxwell> Mike_B: no. And I'm not sure that it can and still have the property.
657 2013-11-06 09:48:15 <gmaxwell> Mike_B: instead of, basically each miner would flip a coin.
658 2013-11-06 09:48:33 <gmaxwell> People have subsiquently pointed out that their simulation had no consideration for latency at all.... :(
659 2013-11-06 09:48:53 <Mike_B> i'm still trying to figure out at which point miners know to ignore announced blocks as too old
660 2013-11-06 09:49:10 <gmaxwell> Mike_B: when there is a longer chain.
661 2013-11-06 09:49:43 <Mike_B> ok, so right now, the current block is 268,217
662 2013-11-06 09:50:00 <Mike_B> if i were to announce an alternate 268,217, half of the miners would randomly flip to mining on that, under this guy's proposed solution?
663 2013-11-06 09:50:08 <Mike_B> but, if i were to announce an alternate 268,216, nobody would flip?
664 2013-11-06 09:50:12 <gmaxwell> yes. right.
665 2013-11-06 09:50:54 <gmaxwell> (petertodd also pointed out this proposal would further incentivize miners trying to remine the current block to steal feesâ I think I actually didn't understand it when petertodd said it, but now that I realized it myself, ouch)
666 2013-11-06 09:51:22 <Mike_B> ok, got it. so then wouldn't it still be in your best interest to announce as soon as possible?
667 2013-11-06 09:51:46 <Mike_B> for instance, say right now, i have block 268,218 privately mined, but i don't tell anyone. then you mine a different block 268,218 and announce it
668 2013-11-06 09:52:37 <Mike_B> if i wait another 5 minutes before announcing my block, the rest of the network is spending time hashing your block, increasing the chances my block will fail
669 2013-11-06 09:53:11 <Mike_B> i thought that the selfish-mine strategy, in this case, was "if the network announces a block and you have exactly one private block, announce ASAP so the network can help you establish your block as the winner"
670 2013-11-06 09:54:31 <gmaxwell> Mike_B: no, the selfish strategy in this case to delay announcing until you hear a compeating block show up. you get all the extra time to try to get two ahead, and you're only worse off by theâ sayâ one second lead the other block had on you in the rest of the network.
671 2013-11-06 09:55:15 <midnightmagic> and what happens when 5-6 peer blocks are announced one after the other
672 2013-11-06 09:55:21 <gmaxwell> e.g. network is on 100, you find a 101, you delay announcing until someone else announces a 101. You announce, and half the network ends up on you because of the random rule.
673 2013-11-06 09:55:31 <Mike_B> gmaxwell, that's the scenario i'm describing above
674 2013-11-06 09:55:48 <MarkProffitt> So you have 1 block complete and are well on the way to the 2nd block before you release the 1st causes your competitor to waste their time
675 2013-11-06 09:55:59 <Mike_B> i have 268,218 already mined but i don't announce it, so I have a lead of 1. then you mine a different block 268,218. the selfish strategy would be for me to announce mine as soon as you do, right? then i use the sybil attack to make sure everyone only hears about my block and not yours.
676 2013-11-06 09:56:03 <gmaxwell> And if your hashrate is high enough thats a win. (basically the benefit of exclusion trumps other people mining on your block until the competitor shows up)
677 2013-11-06 09:56:29 <gmaxwell> Mike_B: in the case where nodes are doing the random choice thing you don't need a sybil attack.
678 2013-11-06 09:56:43 <gmaxwell> they'll mine your late block anyways!
679 2013-11-06 09:56:47 <Mike_B> gmaxwell: that's what i'm saying
680 2013-11-06 09:57:14 <Mike_B> the proposed solution transforms the requirements for the attack from "sufficient hashing power + sybil attack" to "sufficient hashing power"
681 2013-11-06 09:57:23 <Mike_B> right?
682 2013-11-06 09:57:36 <gmaxwell> Mike_B: right.
683 2013-11-06 09:58:07 <MarkProffitt> So their "solution" is either stupid or evil.
684 2013-11-06 09:58:11 <Mike_B> gmaxwell: but what i'm asking is, why are you saying it makes sense, if the proposed change is implemented, for the selfish miners to delay announcing when you do?
685 2013-11-06 09:58:18 <gmaxwell> and it doesn't really answer the tradeoffs question, because it appears they simulated the network as an interlocked finite state machine, rather than timesteps for latency.
686 2013-11-06 09:58:58 <Mike_B> it seems like if the proposal were adopted, then the strategy, when the machine is in the state 0' (meaning I have one private block and you announce a competing public block), would be for me to announce right away
687 2013-11-06 09:59:08 <Mike_B> then watch as the network propagates my forked block without requiring a sybil attack at all
688 2013-11-06 09:59:15 <gmaxwell> Mike_B: I'm saying that it makes sense for them to delay. When right now, absent an information advantage (and maybe with one) is very very strongly in your interest to announce ASAP.
689 2013-11-06 09:59:54 <gmaxwell> We're failing to communicate somehow. I'm not sure how, but its probably my fault. I'm kinda communicated out.
690 2013-11-06 10:00:03 <Mike_B> fair enough
691 2013-11-06 10:00:08 <Mike_B> you've probably been being asked questions about this all day?
692 2013-11-06 10:00:17 <gmaxwell> no. I've been busy with other things.
693 2013-11-06 10:01:01 <midnightmagic> gmaxwell: He's not grokking where the advantage is in delaying under the paper's proposed solution. What is the quantity of the benefit to delaying under the random-switch model.
694 2013-11-06 10:01:16 <gmaxwell> Mike_B: let me try again. Today, (absent sybil attacks and the paper being completely valid) miners are all very strongly incentivized to announce as fast as possible.
695 2013-11-06 10:01:31 <Mike_B> midnightmagic: right. gmaxwell: right.
696 2013-11-06 10:01:44 <gmaxwell> Mike_B: The paper argues that with an information advantage a selfish miner would be better off delaying until they hear another compeating block.
697 2013-11-06 10:02:07 <gmaxwell> Mike_B: they say: make the best block selection random among all options, so now the information advantage is irrelevant.
698 2013-11-06 10:02:58 <gmaxwell> Mike_B: I say, okay, the advantage is irrelevant, but you've actually _strenghtened_ (or created where there was none before) the advantage for a large (e.g. 40% hashpower) miner to delay their blocks.
699 2013-11-06 10:04:08 <gmaxwell> E.g. even if the papers analysis is wrong, even if the big miner has no information advantage.. random selection means that he should delay his blocks if he's big enough that the benefit of other people mining on his block doesn't offset his benefit from keeping it private plus still getting half of other people to mine on it.
700 2013-11-06 10:05:57 <Mike_B> ok
701 2013-11-06 10:06:24 <Mike_B> what would be his benefit from keeping it private if he has no information advantage?
702 2013-11-06 10:06:30 <Mike_B> and if the paper's analysis were wrong?
703 2013-11-06 10:07:32 <gmaxwell> Mike_B: his benefit is that he has a head start in getting 2 ahead compared to the rest of the network.
704 2013-11-06 10:08:07 <Mike_B> what did you mean by "information advantage?" I thought by that, you meant having a private block mined.
705 2013-11-06 10:08:11 <gmaxwell> e.g. network is at 100. He has a 101 and is working on 102. Network finds another 101 and he announces his. Maybe before then he finds 102.
706 2013-11-06 10:08:31 <gmaxwell> Mike_B: information advantage means the sybil attack.
707 2013-11-06 10:08:40 <Mike_B> aha, ok
708 2013-11-06 10:08:48 <gmaxwell> E.g. he knows before the network does when the network finds a block, he can influence that blocks forwarding, etc.
709 2013-11-06 10:09:34 <Mike_B> ok, so before i respond, the reason the information advantage becomes irrelevant with the proposed solution is that if nodes are caught only relaying one block and dropping others, they're identifying themselves as malicious and the network can ignore them, right?
710 2013-11-06 10:09:46 <gmaxwell> no, not at all.
711 2013-11-06 10:10:34 <gmaxwell> it doesn't matter because announcing your blocks faster than the other guy doesn't matter anymore. Their idea of a sybil attack is kinda odd in that they assume the attacker can't prevent the block from getting out completely, but only that they can get ahead of it.
712 2013-11-06 10:10:56 <gmaxwell> and it doesn't matter anymore because nodes don't just prefer the first block they heard.
713 2013-11-06 10:11:27 <Mike_B> gmaxwell: ok, but say this change is implemented. then, i still do a sybil attack. say i can somehow control 50% of the nodes relaying blocks on the network
714 2013-11-06 10:12:05 <Mike_B> so half of the network only hears my relays, because i only relay mine and preferentially ignore the other competing block.
715 2013-11-06 10:12:19 <Mike_B> then, as for the other half of the network - half of it works on my block, half works on your block.
716 2013-11-06 10:12:26 <gmaxwell> Mike_B: if it's only 50% then the blocks will still make it around, they may be delayed a bit, but they'll still make it. If you're actually assuming the attacker has _partitioned_ the network then there is no saving it.
717 2013-11-06 10:12:44 <Mike_B> ah ok, i see what you mean
718 2013-11-06 10:12:48 <gmaxwell> if an attacker can partition the honest network bitcoin cannot be secure while that attack is going on.
719 2013-11-06 10:13:32 <Mike_B> ok, so then when you write this
720 2013-11-06 10:13:33 <Mike_B> Mike_B: I say, okay, the advantage is irrelevant, but you've actually _strenghtened_ (or created where there was none before) the advantage for a large (e.g. 40% hashpower) miner to delay their blocks.
721 2013-11-06 10:13:47 <gmaxwell> thats one of the reasons I wasn't super impressed with the paper. Basically it poses an attacker which is very powerful, in an envirment where miners are greedy instead of lazy/alturistic (which is more like reality today), but not quite so powerful that we're doomed no matter what you do.
722 2013-11-06 10:13:53 <Mike_B> the reason you've strengthened the advantage is because you've removed the requirement "be able to perform a sybil attack." right?
723 2013-11-06 10:14:21 <gmaxwell> Mike_B: yes. And maybe removed the requirement "the papers analysis is correct".
724 2013-11-06 10:14:51 <Mike_B> analysis of which specific part?
725 2013-11-06 10:14:56 <Mike_B> the effects of the proposed change?
726 2013-11-06 10:15:37 <gmaxwell> no, their model of how effective a weak (non-partitioning) sybil attack would be for creating the weird incentives.
727 2013-11-06 10:15:52 <gmaxwell> As I mentioned it seems they didn't simulate latency.
728 2013-11-06 10:15:58 <midnightmagic> also it presumes miners are short-term greedy, and a tragedy of the commons is inevitable in that case: if all miners went selfish and the network were destroyed, the long-term worth of the economy of bitcoin and its deflationary currency and the enormous benefits in the long run are destroyed.
729 2013-11-06 10:15:58 <Mike_B> oh, i see
730 2013-11-06 10:16:27 <midnightmagic> it is not rational to participate in the destruction of bitcoin -- were the paper correct.
731 2013-11-06 10:16:34 <gmaxwell> Right and their assumption of miner's beeing greed-rational instead of lazy-altruistic-crazy
732 2013-11-06 10:16:43 <gmaxwell> er greedy-rational
733 2013-11-06 10:16:56 <Mike_B> gmaxwell: but you agree, in the case where i have one private block and then while i'm working on my lead you trump me, that should that scenario occur, i need to announce asap, so the network starts working on my block.
734 2013-11-06 10:16:57 <sipa> midnightmagic: by rational, we often refer to short-term greedy
735 2013-11-06 10:17:11 <gmaxwell> Mike_B: yep.
736 2013-11-06 10:17:32 <sipa> midnightmagic: not because that's more meaningful, but because it's much easier to quantify
737 2013-11-06 10:18:03 <Mike_B> ok, i see
738 2013-11-06 10:18:12 <Mike_B> so the guy in the paper proposed this change because it fixes gamma at 50%
739 2013-11-06 10:18:26 <gmaxwell> midnightmagic: I like to say greedy-rational for a short term / myopic utility maximizer. Use of the word greedy there seems to disambiguate long term interests. (e.g. as in a greedy algorithim)
740 2013-11-06 10:18:44 <Mike_B> so under the assumption that it's easy for miners to get enough colluding nodes that they can raise gamma up past 50%, that makes sense
741 2013-11-06 10:18:51 <Mike_B> otherwise, it doesn't make sense
742 2013-11-06 10:18:56 <gmaxwell> Mike_B: it's kinda like he fixes the sybil attack by giving every miner a sybil attack. :P
743 2013-11-06 10:19:35 <Mike_B> gmaxwell: right, every miner gets a 50% sybil attack, the reason he's doing that is because it prevents the apocalyptic scenario he talks about where gamma eventually grows without bound and gets arbitrarily close to 1