1 2014-04-12 00:19:01 <sipa> ProfMac: It's CNode, not CPeer
  2 2014-04-12 00:19:13 <sipa> ProfMac: and submitblock actually works differently, as it bypasses the inv mechanism
  3 2014-04-12 00:21:03 <listtransactions> Hey, are there any devs here? I'm having a problem with listtransactions in Bitcoin 0.9.1.
  4 2014-04-12 00:21:46 <listtransactions> I tried migrating a wallet that was on 0.8.6 to 0.9.1, and suddenly listtransactions started showing change transactions.
  5 2014-04-12 00:23:03 <listtransactions> As I'm tracking how much BTC is going into which accounts, this makes the feature useless to me, as it's reporting BTC going randomly into different accounts.
  6 2014-04-12 00:24:36 <gmaxwell> listtransactions: no one else has reported something like that. Is it possible you also restored an old wallet at the same time.
  7 2014-04-12 00:24:40 <gmaxwell> ?
  8 2014-04-12 00:27:36 <listtransactions> What do you mean at the same time?
  9 2014-04-12 00:28:21 <listtransactions> I opened 0.9.1, let it download the blockchain, then closed it, replaced the wallet.dat with the one from 0.8.6, then opened it.
 10 2014-04-12 00:28:33 <listtransactions> As soon as I started sending transactions, change started showing up in listtransactions.
 11 2014-04-12 00:29:24 <listtransactions> There was a time when both 0.8.6 and 0.9.1 were running at the same time, on different computers with two copies of the wallet.dat, but I didn't think this would be an issue, as it has a large key pool.
 12 2014-04-12 00:29:54 <listtransactions> The thing is, the change transactions didn't show up in 0.8.6.
 13 2014-04-12 00:31:10 <tommygunner> you know you can control the change address in 0.9.1
 14 2014-04-12 00:31:22 <listtransactions> The API said that was only for sending raw transactions
 15 2014-04-12 00:31:29 <listtransactions> The API doc, I mean
 16 2014-04-12 00:33:24 <tommygunner> have a look at the send tab
 17 2014-04-12 00:33:37 <listtransactions> All I have is bitcoind
 18 2014-04-12 00:33:40 <listtransactions> Ubuntu server
 19 2014-04-12 00:34:51 <sipa> listtransactions: can you put the output of listtransactions somewhere?
 20 2014-04-12 00:34:54 <sipa> (pastebin)
 21 2014-04-12 00:36:41 <listtransactions> I may need to redact some info, account names and addresses.
 22 2014-04-12 00:37:49 <listtransactions> Do you need a specific part that involves change transactions, or any section?
 23 2014-04-12 00:41:41 <sipa> yeah, just some evidence
 24 2014-04-12 00:41:57 <listtransactions> Okay, I found one.
 25 2014-04-12 00:42:51 <listtransactions> http://pastebin.com/embed_js.php?i=9KVJxjdC
 26 2014-04-12 00:43:14 <listtransactions> I sent the ~0.07 BTC to 14fD3mzRfBB7ziP5bzb49pw4aMLVjzm64e
 27 2014-04-12 00:43:30 <listtransactions> And some change ended up in someone's account
 28 2014-04-12 00:45:11 <listtransactions> I just looked up the txid in 0.8.6, and only the 0.07 transaction shows up there.
 29 2014-04-12 00:45:59 <sipa> the "..." indicates something non-empty?
 30 2014-04-12 00:46:56 <sipa> so, if the behaviour changed, that's a bug in any case
 31 2014-04-12 00:47:42 <sipa> but i'm not sure what the right behaviour should be, as it seems you have an account associated with that 'change' address 17R...
 32 2014-04-12 00:48:55 <sipa> what does validateaddress 17Rj... say; on both 0.8.6 and 0.9.1?
 33 2014-04-12 00:49:51 <listtransactions> The ... indicates the account. It's someone's account name, so I don't want to link it to their address.
 34 2014-04-12 00:49:58 <listtransactions> Let me check validateaddress
 35 2014-04-12 00:50:23 <sipa> in particular, the 'account' field
 36 2014-04-12 00:51:36 <listtransactions> 0.9.1 says it belongs to that person's account
 37 2014-04-12 00:51:44 <listtransactions> 0.8.6 doesn't list the account
 38 2014-04-12 00:52:09 <listtransactions> It might be an address that was assigned in one client and not the other
 39 2014-04-12 00:52:17 <listtransactions> Hmmm
 40 2014-04-12 00:52:24 <listtransactions> There's a large key pool in the wallet
 41 2014-04-12 00:52:39 <sipa> well, if you assign the change address to some account, sends to it will be regarded as incoming payments
 42 2014-04-12 00:53:22 <sipa> the question is only whether you did that, or the system did that on itself
 43 2014-04-12 00:53:26 <sipa> the latter would be a bug
 44 2014-04-12 00:53:27 <listtransactions> Okay... suppose one version of the wallet is in 0.8.6. Then I send the wallet to 0.9.1.
 45 2014-04-12 00:53:31 <sipa> the former incorrect usage
 46 2014-04-12 00:53:49 <sipa> 'one version of the wallet' ?
 47 2014-04-12 00:53:51 <listtransactions> I take a snapshot of the wallet and send it. While it's sending, I keep sending transactions in 0.8.6.
 48 2014-04-12 00:54:00 <sipa> are you running the same wallet in two setups at once?
 49 2014-04-12 00:54:05 <listtransactions> Then, when the wallet arrives in 0.9.1, I assign new addresses.
 50 2014-04-12 00:54:37 <listtransactions> Could some of those new addresses be change addresses, since there's a key pool?
 51 2014-04-12 00:54:41 <sipa> yes
 52 2014-04-12 00:54:48 <listtransactions> That must be it
 53 2014-04-12 00:54:57 <sipa> if you have two setups in parallel using the same wallet file, all kinds of hell will break lose
 54 2014-04-12 00:55:04 <listtransactions> Thanks, this was really worrying me.
 55 2014-04-12 00:55:05 <sipa> including double-spending yourself
 56 2014-04-12 00:55:53 <listtransactions> Okay. Makes sense.
 57 2014-04-12 00:56:31 <listtransactions> One more thing
 58 2014-04-12 00:56:57 <listtransactions> On 0.8.6, using sendmany something causes change transactions to show up in the wallet, too.
 59 2014-04-12 00:57:13 <listtransactions> This is without two wallets running at the same time
 60 2014-04-12 00:57:20 <listtransactions> sometimes*
 61 2014-04-12 00:58:02 <listtransactions> Is there a way to set the change address, so that sendtoaddress and sendmany will use just one address for change?
 62 2014-04-12 00:58:16 <sipa> they always use only one address for change
 63 2014-04-12 00:58:20 <sipa> and they always use a fresh one
 64 2014-04-12 00:58:23 <sipa> from the keypool
 65 2014-04-12 00:58:46 <sipa> so, one that has not been either used as change before, or given out by getnewaddress
 66 2014-04-12 00:59:21 <sipa> you could in theory do a setlabel on that address, if you have seen it (perhaps by seeing it in another wallet) already anyway
 67 2014-04-12 00:59:33 <sipa> that could cause that, i guess
 68 2014-04-12 00:59:42 <sipa> it's not removed from the keypool if you do setlabel
 69 2014-04-12 00:59:48 <listtransactions> Hmm. I wonder how this happened, then.
 70 2014-04-12 01:00:16 <listtransactions> I've never used setlabel
 71 2014-04-12 01:00:49 <sipa> eh, setaccount
 72 2014-04-12 01:00:56 <listtransactions> Oh
 73 2014-04-12 01:01:36 <listtransactions> Still, never used that back when this happened. It's certainly possible that getnewaddress was called right in the midst of when sendmany was being called, could that cause any issues?
 74 2014-04-12 01:01:56 <sipa> no
 75 2014-04-12 01:02:05 <sipa> i don't think so
 76 2014-04-12 01:02:26 <listtransactions> So if I send a transaction now, the change will only go to addresses that have never been used before?
 77 2014-04-12 01:03:09 <sipa> if you're using wallet files in several places, 'never been used' isn't the right word
 78 2014-04-12 01:03:18 <listtransactions> No, only one place.
 79 2014-04-12 01:03:25 <sipa> 'never been given out or used as change by this instance of the wallet'
 80 2014-04-12 01:04:08 <listtransactions> Well, I could swear that's not what happened--it seemed to go into addresses that were pretty old.
 81 2014-04-12 01:05:05 <sipa> is the wallet encrypted?
 82 2014-04-12 01:05:06 <listtransactions> But I can't be absolutely certain nothing odd was going on the time, it was a while ago.
 83 2014-04-12 01:05:08 <listtransactions> No
 84 2014-04-12 01:05:16 <sipa> then certainly not
 85 2014-04-12 01:05:46 <listtransactions> Hm. Okay, well, it's good to understand how this works.
 86 2014-04-12 01:05:50 <listtransactions> Thanks for all your help.
 87 2014-04-12 01:05:52 <sipa> yw
 88 2014-04-12 01:26:50 <Luke-Jr> hm
 89 2014-04-12 01:27:10 <Luke-Jr> it would be a shame to merely remove accounts in 0.10, since HD wallets will make accounts backup-safe
 90 2014-04-12 01:27:15 <Luke-Jr> could*
 91 2014-04-12 01:27:53 <Luke-Jr> and an additional layer for accounts couldn't do the same
 92 2014-04-12 01:30:59 <gmaxwell> Luke-Jr: no it can't make accounts backup safe.
 93 2014-04-12 01:31:17 <Luke-Jr> gmaxwell: why not?
 94 2014-04-12 01:31:23 <gmaxwell> tell me how a move or a sendfrom is supposted to survive backup? how the names of the acocunts will survive backup?
 95 2014-04-12 01:31:32 <gmaxwell> er survive without a backup. :P
 96 2014-04-12 01:32:14 <Luke-Jr> move = ok, remove this
 97 2014-04-12 01:32:23 <Luke-Jr> sendfrom = change address from a per-account chain
 98 2014-04-12 01:49:17 <gmaxwell> Luke-Jr: your sendfrom answer is incomplete, ... you need to know what account was charged and what was credited. Even if you force all transactions to have change you only can learn one account that way.
 99 2014-04-12 01:55:56 <Luke-Jr> gmaxwell: sendfrom only affects one account
100 2014-04-12 01:56:09 <Luke-Jr> unless it's a send-to-self, in which case you know the account of the receiving address..
101 2014-04-12 01:57:07 <gmaxwell> okay true. but still— accounts are _much_ less useful without move.
102 2014-04-12 01:57:35 <gmaxwell> and the account code is terrible cruft in the codebase, whole seperate paths to implement things.
103 2014-04-12 01:57:42 <Luke-Jr> right
104 2014-04-12 01:57:58 <Luke-Jr> but an overlay accounting system *can't* use the HD keys in a smart way :<
105 2014-04-12 01:58:15 <Luke-Jr> it *could* implement "move" on top of this
106 2014-04-12 02:01:21 <gmaxwell> Luke-Jr: presumably full hdwallet support will add different functionality for that... e.g. getnewaddress <branch_id>
107 2014-04-12 02:09:34 <kallisti> Hi, I have a quick question regarding hard-forks. Would it be possible to resolve hard-forks by creating a client with a hard-encoded "merge" transaction that contains the info about the last same block, the first different block(s), a merge height (block #) and a min-version to end the lifetime of the elder client? Such a transaction would accept all transactions on both forks until the point of merger so no coins are lost.
108 2014-04-12 02:10:38 <sipa> kallisti: no, because hard forks don't exist from the point of view of the system
109 2014-04-12 02:10:50 <sipa> it's two sets of nodes which consider eachother's blocks invalid
110 2014-04-12 02:11:11 <kallisti> sipa, that isn't always the case, but it is a worst case
111 2014-04-12 02:11:14 <gmaxwell> kallisti: it's not clear to me what problem you're attempting to solve.  Ignoring accidents, there doesn't need to be any 'resolve' since the system itself can cordinate making incompatible changes.
112 2014-04-12 02:11:21 <sipa> kallisti: yes it is- that is a hard fork
113 2014-04-12 02:11:34 <kallisti> I'm talking about creating a third client which accepts both versions for the sake of merging a hard fork
114 2014-04-12 02:11:41 <gmaxwell> kallisti: you may have a definition problem here. The words hard fork mean what sipa describes.
115 2014-04-12 02:12:16 <kallisti> I understand what a hard fork is, and how people lose money because of them
116 2014-04-12 02:12:29 <kallisti> So I'm investigating solutions.
117 2014-04-12 02:12:47 <gmaxwell> kallisti: how people lose money?  Bitcoin has not had such an event.
118 2014-04-12 02:13:09 <kallisti> BS!
119 2014-04-12 02:13:22 <gmaxwell> kallisti: you cannot 'merge' a seperate chain reliably without inflating the supply of coins. (if there is no contradiction then you can just include the nonconflicting transactions in both and there is nothing to merge)
120 2014-04-12 02:13:24 <kallisti> Bitcoin did have a hard fork
121 2014-04-12 02:13:44 <kallisti> And anyone that paid $$ for coins on the losing fork, lost money
122 2014-04-12 02:13:44 <sipa> yes, one
123 2014-04-12 02:13:50 <sipa> no, not true
124 2014-04-12 02:13:59 <sipa> those transactions were mined on both sides
125 2014-04-12 02:14:01 <gmaxwell> kallisti: No, not really, I assume you're talking about the non-determinstic rejection of large blocks last year. This was not really a hard fork it was something odd.
126 2014-04-12 02:14:13 <sipa> except one, which was repaid later
127 2014-04-12 02:14:18 <gmaxwell> kallisti: and thats not the case, no one lost money.
128 2014-04-12 02:14:33 <sipa> the _only_ solution to a hard fork is above the technology
129 2014-04-12 02:14:40 <sipa> a hard fork is when the technology has failed
130 2014-04-12 02:15:00 <kallisti> I wasn't aware that both sides mined the same transactions.
131 2014-04-12 02:15:16 <sipa> without double-spend attacks each transaction just ends up on both sides
132 2014-04-12 02:15:23 <gmaxwell> of course they did. (also, even if they hadn't that by itself doesn't make anyone lose money)
133 2014-04-12 02:16:18 <kallisti> Actually, what happens if there is a fork and I buy coins that were mined on the losing fork?
134 2014-04-12 02:16:24 <gmaxwell> to lose money, there has to be a successful double spend attack, which was unsuccessful on the chain you follow but the chain you follow isn't ultimately succesful. And this is largely orthorgonal to hard forks, as it can happen just as well without any hard forking.
135 2014-04-12 02:16:39 <kallisti> Since those coins don't exist, I lose money, correct?
136 2014-04-12 02:16:44 <gmaxwell> kallisti: can't happen easily, newly mined coins are impossible to move for 100 blocks.
137 2014-04-12 02:17:08 <gmaxwell> (specifically to prevent that kind of risk)
138 2014-04-12 02:18:33 <kallisti> Regardless, would it be possible to create a new transaction that stitches together two hard-forks?
139 2014-04-12 02:18:45 <kallisti> Say the fork is at block 100
140 2014-04-12 02:19:04 <gmaxwell> kallisti: you're not defining what you're talking about clearly enough to get an answer.
141 2014-04-12 02:19:21 <kallisti> So the transaction would contain the hash at 100, and the two hashes at 101, a merge point, and a minimum version to reject one of the client types
142 2014-04-12 02:19:33 <sipa> transactions are independent from blocks, for starters, so it would be sort of a merger-block, not a merger-transaction
143 2014-04-12 02:19:55 <phantomcircuit> gmaxwell, iirc there was a successful double spend in the hard fork between 0.7 and 0.8
144 2014-04-12 02:20:03 <sipa> phantomcircuit: yes, one
145 2014-04-12 02:20:06 <gmaxwell> phantomcircuit: yes though they paid it back.
146 2014-04-12 02:20:08 <sipa> and it was repaid
147 2014-04-12 02:20:10 <phantomcircuit> ah
148 2014-04-12 02:20:21 <phantomcircuit> technically i think it still counts even if it was paid back :P
149 2014-04-12 02:20:26 <sipa> sure
150 2014-04-12 02:20:34 <sipa> we had a hard fork, and the system was at risk
151 2014-04-12 02:21:19 <gmaxwell> I still think hard fork is not a very accurate description of what happened there, ... it was .. "something screwy", since some of the pre-0.8 nodes accepted that chain.
152 2014-04-12 02:21:24 <kallisti> @Sipa, the system technically is always at risk
153 2014-04-12 02:21:26 <gmaxwell> kallisti: you're still not defining what is actually being accomplished there.
154 2014-04-12 02:22:21 <kallisti> If micrsoft were to include a new version of bitcoin in one of their upgrades, that everyone automatically gets, where bitcoin is integrated with their desktop, and that version created a new fork it would put everyone at risk.
155 2014-04-12 02:22:45 <sipa> maybe, but there's nothing we can do about that
156 2014-04-12 02:22:55 <sipa> we can't make their software accept something it doesn't
157 2014-04-12 02:22:58 <kallisti> Hense why I am working on the fork issue because it is a security flaw in the system
158 2014-04-12 02:23:16 <sipa> and we won't accept things we consider invalid
159 2014-04-12 02:23:22 <sipa> a hard fork is a disagreement about the rules
160 2014-04-12 02:23:27 <sipa> you don't fix it with technology
161 2014-04-12 02:23:30 <kallisti> It may not be a gaping hole that hackers can use, but it is a risk that may be able to be eliminated.
162 2014-04-12 02:23:36 <gmaxwell> and we must not accept what we consider invalid, or the system is not secure.
163 2014-04-12 02:23:36 <sipa> you fix it by making people agree on the rules
164 2014-04-12 02:23:50 <gmaxwell> 19:21 <@gmaxwell> kallisti: you're still not defining what is actually being accomplished there.
165 2014-04-12 02:25:21 <sipa> so what have you accomplished? in addition to the two sets of nodes with each their own chain, you introduce a new chain that is accepted only by people running your metanode, which has a chain that neither of the two other parties accept either
166 2014-04-12 02:25:28 <sipa> end result: 3 chains
167 2014-04-12 02:25:34 <sipa> and they don't resolve
168 2014-04-12 02:25:36 <kallisti> @gmaxwell, the two hard-fork solutions I've come up with are a less political (mathmatical) resolution to hard-forks and this second solution to "merge" the forks. Though it is clear this wouldn't be a transaction, it would be a block so I'm not sure how well it would work.
169 2014-04-12 02:26:08 <gmaxwell> kallisti: You haven't actually described what the resulting end state is at all though.
170 2014-04-12 02:26:12 <kallisti> @sipa, not true
171 2014-04-12 02:26:27 <gmaxwell> you're just saying "merge" as if it were apparent what that means precisely. It isn't.
172 2014-04-12 02:26:34 <kallisti> Basically I'm talking about creating a new client that allows merge transactions
173 2014-04-12 02:26:41 <sipa> kallisti: okay.
174 2014-04-12 02:26:57 <kallisti> So when the time comes that a fork happens, hopefully both clients already support this type of transaction
175 2014-04-12 02:26:58 <sipa> kallisti: what requirements are there for the two chains it allows merging?
176 2014-04-12 02:27:03 <gmaxwell> kallisti: "merge transactions"? Colorless green ideas sleep furiously.
177 2014-04-12 02:27:29 <kallisti> If the two different chains are both driven by clients that support a merge transaction than a merge would be possible
178 2014-04-12 02:27:48 <sipa> you haven't answered my question
179 2014-04-12 02:27:52 <gmaxwell> or any of mine.
180 2014-04-12 02:27:56 <kallisti> If the two clients pre-date merge support, than you are right, there would just become a new fork.
181 2014-04-12 02:28:21 <jcorgan> kallisti: so, what precisely is a merge transaction?
182 2014-04-12 02:28:37 <sipa> kallisti: okay; we add merge blocks to the client. under which conditions is a merge block valid? certainly the two chains it derives from must individually already be valid?
183 2014-04-12 02:28:44 <sipa> kallisti: agree?
184 2014-04-12 02:28:58 <kallisti> @gmaxwell the requirements rae as I stated, the matching block and the forking blocks (hashes) would be part of the merge transaction
185 2014-04-12 02:29:05 <kallisti> rae=are
186 2014-04-12 02:29:15 <sipa> kallisti: pleae answer my question
187 2014-04-12 02:29:53 <kallisti> I think your both basically asking the same question
188 2014-04-12 02:30:12 <sipa> kallisti: you're saying that a merge block is valid simply if it references two chains?
189 2014-04-12 02:30:17 <gmaxwell> I don't think we are, though both questions would make things more clear.
190 2014-04-12 02:31:07 <sipa> kallisti: so i can create an invalid block chain (which pays me 42 million BTC), and then merge it with the real one, and people would accept that?
191 2014-04-12 02:31:10 <kallisti> @sipa when I came in here I was thinking along the lines of transactions
192 2014-04-12 02:31:20 <sipa> BLOCK CHAINS ARE NOT TRANSACTIONS
193 2014-04-12 02:31:24 <kallisti> I honestly need to go back to the drawing board to figure  out the validation
194 2014-04-12 02:31:37 <sipa> no, that's the very first thing you should think about
195 2014-04-12 02:31:49 <sipa> validation is what we're trying to solve here
196 2014-04-12 02:31:52 <kallisti> For the newest client, validation is simple because its hard-coded, the client is already expecting the merge.
197 2014-04-12 02:32:19 <kallisti> I'm not sure how the existing clients would know if they should accept the merge or not
198 2014-04-12 02:32:20 <sipa> please come back once you're figured out exactly how to validate it
199 2014-04-12 02:32:24 <gmaxwell> kallisti: I think we want to know is "what do you hope to accomplish, specifically, not with ill defined words like 'merge'" and then "under what conditions will what you propose act" and "what will be the resulting final state of the system after it acts"
200 2014-04-12 02:32:28 <jcorgan> kallisti: think of it in these terms: at the tip of each chain, their is a distinct but overlapping UTXO set, and after a merge block, there is only one UTXO set.  Define how you get from two to one.
201 2014-04-12 02:32:28 <sipa> i'm not talking about existing clients at all
202 2014-04-12 02:32:32 <sipa> we upgrade everyone
203 2014-04-12 02:32:36 <kallisti> But regardless, the merge record is an end-of-life for one of the clients
204 2014-04-12 02:32:50 <sipa> and we assume you can magically merge the states of two valid chains as well
205 2014-04-12 02:33:19 <sipa> you still will need to require that your merger can only merge two otherwise valid transactions
206 2014-04-12 02:33:34 <sipa> and the problem is exactly that there are two sets of clients which don't agree on what is valid!
207 2014-04-12 02:33:50 <kallisti> @jcorgan I'm aware there are database issues with this, as I said, I'm trying to solve the issue, I didn't say I've solved it.
208 2014-04-12 02:34:49 <jcorgan> its not a database issue.  you need to precisly define what happens to the unspent txouts on each chain, and how clients after a merge block reconcile differences between them.
209 2014-04-12 02:34:54 <sipa> i don't think you understand what you're trying to solve
210 2014-04-12 02:36:49 <kallisti> @jcorgan the idea is that both parts of the chain become valid, not much different than the physical structure of an actual chain
211 2014-04-12 02:37:14 <gmaxwell> I don't understand what issue you think you're solving. I have some suspicion that you may be trying to solve one that didn't exist; since earlier you seemed to indicate that you thought that everyone who transacted in the losing side lost funds.
212 2014-04-12 02:37:22 <kallisti> @jcorgan this structure was before I knew transactions can and do exist in both forks
213 2014-04-12 02:38:18 <gmaxwell> kallisti: so a classical example of a hard fork would be something like I mine a block that pays me 2 billion non-existing bitcoins. the other nodes don't accept this since it violates the rules, so it's a hard fork relative to them.
214 2014-04-12 02:38:23 <gmaxwell> What would you propose to do there.
215 2014-04-12 02:39:54 <kallisti> @gmaxwell, regardless of the solution, that block obviously couldn't be accepted
216 2014-04-12 02:40:13 <gmaxwell> Thats what a hard fork is... so you propose to merge that, no?
217 2014-04-12 02:40:54 <kallisti> The validation issue isn't yet solved as to how merge blocks would be validated
218 2014-04-12 02:41:06 <kallisti> But they would be generated by being hard-coded into clients
219 2014-04-12 02:42:15 <gmaxwell> I'm still no closer to having any idea what exactly you're trying to do. Can you try telling me what you want to accomplish without using the word merge (or any obvious synonym)
220 2014-04-12 02:42:19 <gmaxwell> ?
221 2014-04-12 02:43:39 <kallisti> I already stated that @gmaxwell
222 2014-04-12 02:44:03 <kallisti> I'm trying to find a permanent solution to dealing with hard-forks which eliminates risk when hard-forks occur.
223 2014-04-12 02:44:19 <gmaxwell> What risk do you wish to eliminate?
224 2014-04-12 02:44:37 <kallisti> And I'm not talking about intentional hard forks, I'm talking about big ones, with big mining power on both sides of the fork.
225 2014-04-12 02:45:33 <jcorgan> kallisti: please describe the risks you wish to eliminate in terms of risks to whom, and what the bad outcome is you would prevent
226 2014-04-12 02:45:37 <kallisti> The risk of buying coins that evaporate due to being on a losing fork.
227 2014-04-12 02:46:21 <kallisti> more specifically, the risk of buying coins that were mined on a losing fork.
228 2014-04-12 02:46:48 <gmaxwell> kallisti: okay, that risk is already largely addressed by the fact that newly created coins can't be moved for 100 blocks, and if there is a 'invalid' fork that long your client will begin warning you that you shouldn't trust transactions.
229 2014-04-12 02:47:30 <gmaxwell> (and 100 blocks is long enough that even without the warnings generally you'll know that something is wrong and not to trust transactions you've recieved)
230 2014-04-12 02:47:39 <kallisti> @gmaxwell, I've never been one to accept the statusquo
231 2014-04-12 02:48:32 <kallisti> If the system isn't perfect, it will be compromised and people will eventually lose money. Google murphy's law.
232 2014-04-12 02:48:54 <warren> surprised you let that go for so long
233 2014-04-12 02:49:00 <gmaxwell> I guess something could have gone wrong with my ban button.
234 2014-04-12 02:49:06 <jcorgan> it was good practice :)
235 2014-04-12 02:49:30 <gmaxwell> I at least wanted to clear up any honest misunderstanding.
236 2014-04-12 03:00:33 <davec> hmm looking at the code importprivkey should return null when attempting to import a duplicate key, but I seee
237 2014-04-12 03:00:36 <davec>         // Don't throw error in case a key is already there
238 2014-04-12 03:00:39 <davec>         if (pwalletMain->HaveKey(vchAddress))
239 2014-04-12 03:00:42 <davec>             return Value::null;
240 2014-04-12 03:00:52 <davec> $ ./bitcoind -testnet importprivkey $(./bitcoind.exe -testnet dumpprivkey <address redacted>)
241 2014-04-12 03:00:55 <davec> error: {"code":-4,"message":"Error adding key to wallet"}
242 2014-04-12 03:20:30 <davec>  hmm looking at the code, importprivkey should return null when attempting to import a duplicate key, but I see:
243 2014-04-12 03:20:34 <davec> $ ./bitcoind -testnet importprivkey $(./bitcoind.exe -testnet dumpprivkey <address redacted>)
244 2014-04-12 03:20:42 <davec> error: {"code":-4,"message":"Error adding key to wallet"}
245 2014-04-12 03:22:25 <kallist> @gribble, I'll be taking this security risk to the media since you can't be civil
246 2014-04-12 03:22:31 <kallist> Goodbye
247 2014-04-12 03:24:42 <warren> gribble can't be civil?
248 2014-04-12 03:25:22 <gmaxwell> davec: I had no idea it was supposted to return null, and knew it returned an error.
249 2014-04-12 03:26:04 <gmaxwell> davec: I don't think the precise behavior is especially important in that case, the documentation for that api doesn't specify it.
250 2014-04-12 03:26:35 <davec> right, I don't think it's a big deal either way, but I just found it odd since I see
251 2014-04-12 03:26:38 <davec>         // Don't throw error in case a key is already there
252 2014-04-12 03:26:40 <davec>         if (pwalletMain->HaveKey(vchAddress))
253 2014-04-12 03:26:43 <davec>             return Value::null;
254 2014-04-12 03:36:52 <phantomcircuit> davec, probably  the code underlying that function was changed after the comment
255 2014-04-12 03:37:10 <phantomcircuit> generally speaking it's safer for things to explode than to silently fail
256 2014-04-12 03:41:45 <akstunt600> http://rt.com/usa/weev-appeal-conviction-vacated-972/
257 2014-04-12 03:41:51 <akstunt600> finally letting weev out
258 2014-04-12 03:42:51 <HaltingState> gmaxwell, "two-way pegging method " that you invented; do you have link
259 2014-04-12 03:43:01 <HaltingState> "Greg Maxwell then proposed a two-way pegging method that enables Bitcoin to connect with a sidechain which is a mathematically-controlled peg between Bitcoin main and the other chain network"
260 2014-04-12 03:43:20 <phantomcircuit> gmaxwell, you have a different name for it now right?
261 2014-04-12 03:43:27 <phantomcircuit> something without comical sexual inuendo
262 2014-04-12 03:43:49 <HaltingState> "i love blockchain pegging"
263 2014-04-12 03:43:56 <phantomcircuit> lol
264 2014-04-12 03:45:02 <HaltingState> https://bitcointalk.org/index.php?topic=321228.0
265 2014-04-12 03:45:04 <HaltingState> coinswap i think
266 2014-04-12 03:52:35 <kallisti> I have advised my media contact that there is a risk in bitcoin that if a hard-fork occurs, and the dispute lasts more than 100 blocks that anyone buying bitcoins mined on what eventually becomes the losing fork will lose money.  I was working on solving this problem myself but administrators here couldn't be adults about the situation.  So now it will be up to individuals to decide if they're willing to accept this level of risk or not, otherwise
267 2014-04-12 03:52:36 <kallisti>  this issue will need to be resolved by bitcoin developers.
268 2014-04-12 03:53:12 <kdomanski> adios
269 2014-04-12 03:53:41 <maaku> HaltingState: coinswap is something different
270 2014-04-12 03:56:01 <maaku> HaltingState: see adam3us' message to the development list re: pegging
271 2014-04-12 03:56:02 <maaku> btw maybe 'pegged cross-chain assets' would at least avoid the -ing connotation of that word
272 2014-04-12 03:57:34 <brady2600> meh just go with pegging, it will make it popular
273 2014-04-12 03:58:09 <phantomcircuit> yeah the random guy in the phillipines with his super connections
274 2014-04-12 03:58:11 <phantomcircuit> right
275 2014-04-12 03:58:34 <brady2600> call it greg-pegging, to give credit.
276 2014-04-12 04:19:47 <brady2600> where is the config dir on unix  .bitcoin?
277 2014-04-12 04:22:10 <rdbell> brady2600: Should be /home/<user>/.bitcoin normally
278 2014-04-12 04:22:14 <rdbell> ~/.bitcoin
279 2014-04-12 04:53:00 <Tiraspol> http://i.imgur.com/5X9CbCn.png
280 2014-04-12 04:55:43 <kdomanski> uh, is that Gavin on the left?
281 2014-04-12 05:01:44 <w1zman> it mark k
282 2014-04-12 05:01:46 <w1zman> it's
283 2014-04-12 05:05:26 <Guest69296> lol
284 2014-04-12 05:08:00 <kdomanski> ah
285 2014-04-12 11:36:27 <hno> theymos, what happened with http://blockexplorer.com/testnet? Showed correct data yesterday but now it's gone back to 2014-03-21?
286 2014-04-12 11:37:17 <vetch> hno: test.bitcore.io testnet.btclook.com
287 2014-04-12 11:44:12 <Luke-Jr> hno: I don't think theymos has anything to do with blockexplorer.com?
288 2014-04-12 11:44:54 <vetch> Luke-Jr: he wrote it, didn't he?
289 2014-04-12 11:45:07 <Luke-Jr> pretty sure that was tcatm
290 2014-04-12 11:45:13 <Luke-Jr> but I don't think he runs it anymore, either
291 2014-04-12 11:46:09 <vetch> at any rate, it hasn't scaled well and is less than ideal for anything
292 2014-04-12 11:46:36 <vetch> hno: oh, and this one is probably the best of all of them http://test.webbtc.com/
293 2014-04-12 11:47:31 <dexX7> https://www.biteasy.com/testnet is very fast
294 2014-04-12 11:48:00 <dexX7> huh no blocks for 3 days?
295 2014-04-12 11:48:28 <vetch> yep, looks like it's fast but completely broken.
296 2014-04-12 11:48:44 <dexX7> yup :/
297 2014-04-12 11:49:11 <vetch> yeah it's stuck on my orphan chain
298 2014-04-12 11:49:41 <rnicoll> vetch, I've written so many things like that "It does the wrong thing REALLY QUICKLY! It's like 100 times faster than the right thing..."
299 2014-04-12 11:50:41 <vetch> rnicoll: sounds about right. biteasy.com is really fast but doesn't bother with reorganisations.
300 2014-04-12 11:51:39 <rnicoll> vetch, I should add, I'm doing much better these days :)
301 2014-04-12 12:21:38 <jeremias> I'm trying to play around with BIP 0070
302 2014-04-12 12:21:58 <jeremias> will Output.script be in most cases standard Bitcoin address?
303 2014-04-12 12:22:33 <sipa> presumably
304 2014-04-12 12:23:49 <jeremias> k
305 2014-04-12 12:24:06 <jeremias> has any wallets/merchants started to implement BIP 0070 yet?
306 2014-04-12 12:24:11 <jeremias> or have any implementations?
307 2014-04-12 12:24:20 <sipa> bitpay, bitcoin core, bitcoinj
308 2014-04-12 12:24:23 <vetch> Bitcoin Core supports BIP70 as of 0.9
309 2014-04-12 12:25:42 <jeremias> hmm, maybe try it out with low-value items from bitpay
310 2014-04-12 12:26:02 <aschildbach> jeremias: and Bitcoin Wallet for Android/BlackBerry/Nokia X
311 2014-04-12 12:26:16 <jeremias> ok cool
312 2014-04-12 12:27:24 <jeremias> aschildbach: does your wallet nowadays have also blackberry/nokia versions? :)
313 2014-04-12 12:27:29 <jeremias> that's cool
314 2014-04-12 12:27:52 <aschildbach> jeremias: The blackberry version is ~2 years old already I think.
315 2014-04-12 12:27:59 <aschildbach> Nokia X support is brand new.
316 2014-04-12 12:28:33 <aschildbach> Amazon rejected the app because of the GPL license.
317 2014-04-12 12:28:43 <jeremias> ah, I see
318 2014-04-12 12:29:34 <jeremias> aschildbach: does android wallet send automatically refund address as well?
319 2014-04-12 12:29:43 <jeremias> eg. how well it implements BIP 0070?
320 2014-04-12 12:30:09 <aschildbach> jeremias: Yes it sends a refund address. There is no way (yet) for the payee to tell the payer if a refund is possible.
321 2014-04-12 12:31:02 <aschildbach> I'd say it implements BIP70 fully.
322 2014-04-12 12:31:31 <jeremias> cool
323 2014-04-12 12:32:02 <jeremias> can thos google protocol buffers extended easily
324 2014-04-12 12:32:18 <aschildbach> yes its quite easy
325 2014-04-12 12:32:47 <aschildbach> fields are just numbered
326 2014-04-12 12:33:13 <jeremias> ok
327 2014-04-12 12:33:33 <aschildbach> We have been using this a the wallet format since 3 years.
328 2014-04-12 12:33:36 <jeremias> so you can add new fields on the bottom, and that won't cause problems?
329 2014-04-12 12:33:42 <jeremias> protocol buffers?
330 2014-04-12 12:33:45 <vetch> sipa: do you know if the Tor browser bundle blocks bitcoin: URI? it's a fairly ridiculous privacy issue if they don't..
331 2014-04-12 12:33:55 <aschildbach> Yes protocol buffers.
332 2014-04-12 12:34:01 <jeremias> as a wallet format?
333 2014-04-12 12:34:10 <jeremias> isn't it more like for messaging?
334 2014-04-12 12:34:20 <jeremias> eg. how do you store it?
335 2014-04-12 12:34:45 <jeremias> well, I guess I have lot's to learn
336 2014-04-12 12:35:12 <aschildbach> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/bitcoin.proto
337 2014-04-12 12:35:19 <aschildbach> You can use it for both.
338 2014-04-12 12:35:53 <jeremias> I see
339 2014-04-12 12:35:56 <aschildbach> I mean where is the difference between a structure you send through a wire and one you write to disc?
340 2014-04-12 12:36:30 <jeremias> well, I understand that it can be done
341 2014-04-12 12:37:03 <aschildbach> The only gotcha is Protobuf generally leaves message delimiting to the protocol layer above.
342 2014-04-12 12:37:17 <aschildbach> A file is delimited automatically. A stream is not.
343 2014-04-12 12:39:30 <jeremias> aschildbach: so, if I create payment request from Android Wallet, how does it broadcast the request?
344 2014-04-12 12:40:29 <aschildbach> I've summed all forms of payment request up: https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
345 2014-04-12 12:40:48 <aschildbach> Generally, you can scan a QR code or tap via NFC.
346 2014-04-12 12:41:44 <aschildbach> I did not find a way to put payment requests into an e-mail attachment with the correct mime type (the email client ignore the type).
347 2014-04-12 12:44:00 <jeremias> hmm, so it encodes the protobuf PaymentRequest object to the QR code?
348 2014-04-12 12:44:47 <jeremias> but the bitpay model is providing the object via web service?
349 2014-04-12 12:46:22 <wumpus> jeremias: it encodes a URI like bitcoin:?r=https://server.com/paymentrequest into the QR code, not the payment request (which can be fairly large, too large to fit into QR codes conveniently)
350 2014-04-12 12:46:52 <aschildbach> jeremias: Regarding QR-codes, Bitcoin Wallet support either BIP72 (sort of), which means using a BIP21 URI + an URL where to fetch the BIP70 PR
351 2014-04-12 12:47:11 <jeremias> yeah I know about that... but the android wallet probably isn't doing that, because normal users don't have SSL certificates and probably don't want to run web server on their devices?
352 2014-04-12 12:47:33 <aschildbach> jeremias: Also, there is experimental support for putting the BIP70 payment request into the URL directly.
353 2014-04-12 12:48:17 <aschildbach> jeremias: Bitcoin Wallet currently does not sign, although there is an experimental branch for it.
354 2014-04-12 12:48:29 <aschildbach> jeremias: You can import a cert into your phone and sign with that.
355 2014-04-12 12:50:05 <jeremias> so does it means that everyone who wants to request payments using the new protocol have to get certificates?
356 2014-04-12 12:50:23 <jeremias> or use the old method?
357 2014-04-12 12:51:30 <wumpus> vetch: AFAIK the tor browser bundle doesn't do any 'special' URI handling at all
358 2014-04-12 12:51:47 <wumpus> vetch: no bitcoin, no magnet, nothing
359 2014-04-12 12:52:17 <sipa> jeremias: signing is optional
360 2014-04-12 12:52:43 <wumpus> all of the URI types launching an external application would be a privacy leak in one way or the other, at least of the external application isn't configured to use tor, which would be a bad assumption to make
361 2014-04-12 12:52:46 <aschildbach> jeremias: X.509 PKI is optional. Depending on your usecase, it's perhaps not even recommended to use that.
362 2014-04-12 12:53:04 <aschildbach> jeremias: Can you tell about your usecase?
363 2014-04-12 12:53:07 <vetch> wumpus: alright. bit of a trap if the user expects only the old bitcoin: URI without payment requests though.
364 2014-04-12 12:53:23 <jeremias> aschildbach: I don't have specific usecase, I'm more like playing around with the tech
365 2014-04-12 12:53:28 <wumpus> vetch: well if the user has configured bitcoin client to use tor (which he should) there is no problem
366 2014-04-12 12:53:29 <jeremias> developing django-bitcoin
367 2014-04-12 12:54:15 <jeremias> hmm, so it could work via .onion addresses
368 2014-04-12 12:54:18 <wumpus> vetch: if not, you're leaking your IP all over the place anyway if you make (or even receive) a payment
369 2014-04-12 12:54:29 <aschildbach> jeremias: Ok, I see. If you feel like it, have a look at my bip72-bluetooth branch which implements BIP72 via Bluetooth.
370 2014-04-12 12:54:53 <vetch> wumpus: uncomfortable notion.
371 2014-04-12 12:54:56 <wumpus> jeremias: sure, why not
372 2014-04-12 12:55:14 <aschildbach> jeremias: And based on that, there is bip70-sign, which implements payment request signing on the wallet side. It works, but its a little bit rough still.
373 2014-04-12 12:55:31 <wumpus> vetch: just use tor
374 2014-04-12 12:56:09 <vetch> wumpus: I think that's probably worse. attracts attention.
375 2014-04-12 12:56:58 <jeremias> hmm
376 2014-04-12 12:57:02 <jeremias> I like the tor solution more
377 2014-04-12 12:57:08 <wumpus> well, if you're in a country where even tor gets you into trouble, I'd suggest being really careful with bitcoin
378 2014-04-12 12:57:14 <vetch> wumpus: but all the same, it's an accessible solution.
379 2014-04-12 12:58:31 <wumpus> (I mean running a non-exit tor node, tor exit nodes are known to attract all kinds of unwelcome attention, but that's not the default)
380 2014-04-12 12:58:44 <jeremias> well, I guess if you want to transfer the data over securely, there is two alternatives: tor, or https -urls
381 2014-04-12 12:58:57 <jeremias> if I understand correctly
382 2014-04-12 12:59:09 <vetch> wumpus: in reality probably almost all countries are hostile to Tor to some degree.
383 2014-04-12 12:59:53 <jeremias> vetch: not really
384 2014-04-12 13:00:01 <wumpus> vetch: this is getting off topic for #bitcoin-dev...
385 2014-04-12 13:00:07 <vetch> yep, sorry.
386 2014-04-12 13:00:30 <jeremias> well, I don't see the problem id anything technical is not on the table
387 2014-04-12 13:01:03 <jeremias> we have visited the central police in Finland one time with Bitcoin presentation, and they were quite a positive both towards tor and bitcoin
388 2014-04-12 13:01:29 <jeremias> err, positive is probably not the right word, but anyway
389 2014-04-12 13:16:54 <rnicoll> sipa, I'm doing terrible things to the Bitcoin payment protocol, and trying to merge it into Dogecoin. Are you the best person to talk to for some opinions on decisions to be made (mostly branding)?
390 2014-04-12 13:18:01 <vetch> (hahaha)
391 2014-04-12 13:18:33 <jeremias> lol
392 2014-04-12 13:31:41 <sipa> rnicoll: such protocol, much payment
393 2014-04-12 13:32:24 <rnicoll> sipa, very wow, yes :)
394 2014-04-12 13:32:26 <vetch> isn't dogecoin miles away from the bitcoin head? I doubt the payment protocol would even merge at all
395 2014-04-12 13:32:47 <rnicoll> vetch, we've got a client based on 0.9, which is basically release ready apart from making BPP work
396 2014-04-12 13:33:28 <vetch> that's surprising
397 2014-04-12 13:33:36 <rnicoll> sipa, the main question is, are you happy for us to call it Bitcoin payment protocol when we're implementing it? It's your work, want to keep the name, but equally if you want to distance yourselves I'd understand
398 2014-04-12 13:33:39 <rnicoll> vetch, we try :0
399 2014-04-12 13:33:40 <rnicoll> :)
400 2014-04-12 13:34:04 <wumpus> rnicoll: at least it should make a 'woof' sound after succesfully fetching a payment request
401 2014-04-12 13:34:18 <rnicoll> wumpus, I will see what I can do
402 2014-04-12 13:36:15 <rnicoll> sipa, well, I'm going to be working on a request generator/test framework, will be here if you want to go "Nooooo, don't call it Bitcoin anything!"
403 2014-04-12 13:38:21 <wumpus> rnicoll: if it implements BIP70 on an alternative chain it can still be called BIP70, but won't calling it 'bitcoin payment protocol' confuse people that use it?
404 2014-04-12 13:38:48 <wumpus> just 'payment protocol
405 2014-04-12 13:38:50 <vetch> just "payment protocol"
406 2014-04-12 13:38:52 <wumpus> would do
407 2014-04-12 13:38:59 <wumpus> heh
408 2014-04-12 13:39:12 <vetch> well, we're in agreement at least.
409 2014-04-12 13:39:31 <rnicoll> wumpus, vetch, yeah, that would work. As said, I mostly want to give you guys credit. Can just call it "payment protocol" in the client and credit you guys in docs
410 2014-04-12 13:43:55 <rnicoll> last question; obviously we either have to not use "main" and "test" for the network labels, or alternatively use a different MIME type so Dogecoin requests aren't easily mixed up. I'd personally rather keep the MIME type and use "main-doge" and "test-doge", but again wanted feedback...
411 2014-04-12 13:44:57 <wumpus> sounds sensible to me
412 2014-04-12 13:45:29 <wumpus> on the other hand keeping the mime type the same can give you problems, which application gets to handle it?
413 2014-04-12 13:46:11 <rnicoll> wumpus, well the.... oh... oh that's not good... new MIME type it is :)
414 2014-04-12 13:46:14 <wumpus> if the bitcoin payment request is configure to launch bitcoin, then it will error out if it sees main-doge or test-doge
415 2014-04-12 13:47:42 <wumpus> in theory there could be some kind of generic BIP90 dispatcher that routes the payment request to the right app based on the network, but that would be hard to coordinate, and you probably have used a different URI scheme as well already
416 2014-04-12 13:48:13 <sipa> rnicoll: i don't care :)
417 2014-04-12 13:48:32 <rnicoll> also, while I'd rather not clutter the MIME namespace too much, given we're a long way off most coins getting to this point, probably overthinking it
418 2014-04-12 13:48:56 <rnicoll> sipa, awesome. Just easier to ask and find you don't care, than release and suddenly you're "Our protocol!"
419 2014-04-12 13:50:13 <sipa> rnicoll: though you should probably ask gavin/mike/... many others rather than me if you really worry abour that
420 2014-04-12 13:50:41 <rnicoll> sipa, will do, thanks!
421 2014-04-12 14:26:46 <aschildbach> rnicoll: I would differentiate by mime-type rather than by network field.
422 2014-04-12 14:27:01 <aschildbach> For exactly the dispatching reason.
423 2014-04-12 14:27:21 <rnicoll> aschildbach, yeah, that seems to be the feedback so far, and makes sense. Also means if we diverge on implementation later, it's not a hell of a mess to unpick
424 2014-04-12 14:27:31 <aschildbach> Exactly
425 2014-04-12 14:28:43 <rnicoll> oh, also, if you guys are surprised we have a 0.9-derived client (and many thanks to everyone who worked on 0.9, it's great stuff) near launch, imagine how much I'm not looking forward to Litecoin finding out
426 2014-04-12 14:30:45 <rnicoll> and yes I mean 0.9.1 of course, not 0.9
427 2014-04-12 14:30:59 <vetch> not that there's any functional difference between them
428 2014-04-12 14:31:48 <rnicoll> the OpenSSL version bump might be important for something :)
429 2014-04-12 14:32:22 <sipa> well, it's not like heartbleed is actually a serious bug or anything, right?
430 2014-04-12 14:32:28 <rnicoll> especially as I think payment protocol requests can be fetched via HTTPS direct from the client?
431 2014-04-12 14:32:42 <rnicoll> sipa, yeah, probably not worth worrying about :)
432 2014-04-12 14:43:04 <ZoltanTokay> http://www.reddit.com/r/Bitcoin/comments/22utb0/mtgox_release_document_to_ask_for_refund/
433 2014-04-12 14:43:58 <dexX7> <Apocalyptic> ^ malware
434 2014-04-12 14:55:39 <Luke-Jr> [13:43:46] <rnicoll> last question; obviously we either have to not use "main" and "test" for the network labels, or alternatively use a different MIME type so Dogecoin requests aren't easily mixed up. I'd personally rather keep the MIME type and use "main-doge" and "test-doge", but again wanted feedback… <-- or both..
435 2014-04-12 14:55:57 <Luke-Jr> the network field exists specifically to differentiate
436 2014-04-12 14:57:16 <rnicoll> Luke-Jr, well, from discussion using a different MIME type is more sensible, anyway, so that solves that issue as a side-effect
437 2014-04-12 15:14:06 <hno> Luke-Jr, blockexplorer.com/testnet says "All times are UTC. Tell me (theymos) if you find any bugs."
438 2014-04-12 15:36:17 <wumpus> rnicoll: Luke-Jr: using both is a good idea; if for some reason the bitcoin payment requests ends up in the client for another chain (or vice versa), it can show an error
439 2014-04-12 15:37:41 <rnicoll> wumpus, also a good point. Also means if someone decides to fork from our client, it's not as hard to adapt
440 2014-04-12 15:44:37 <hno> and blockexplorer.com/testnet works again.
441 2014-04-12 15:59:13 <hno> the testned difficulty magic.. do work even if someone is generating blocks "in future"?
442 2014-04-12 15:59:43 <vetch> yep
443 2014-04-12 15:59:53 <vetch> time warp 20 minutes, solve an easy block
444 2014-04-12 16:05:08 <hno> so the one who is minint
445 2014-04-12 16:05:38 <hno> so the one who is mining "in the future" gets first chance?
446 2014-04-12 16:06:00 <vetch> well no, they just have a higher target than anybody mining at the present time
447 2014-04-12 16:06:11 <vetch> (higher target meaning significantly easier)
448 2014-04-12 16:06:41 <vetch> you can only do that a few times before your blocks start getting rejected anyway.
449 2014-04-12 16:07:20 <hno> just noticed that i had not found any blocks today which made me wonder.
450 2014-04-12 16:08:23 <vetch> a miner mined for a very long time with a fast ASIC, the difficulty of testnet is sky high
451 2014-04-12 16:09:03 <vetch> 1024
452 2014-04-12 16:09:20 <shesek> but it'll reset back to normal quite fast
453 2014-04-12 16:09:23 <shesek> in 20 minutes iirc
454 2014-04-12 16:09:32 <vetch> just for one block.
455 2014-04-12 16:10:25 <shesek> right... and after that it'll reset again in 20 minutes
456 2014-04-12 16:10:37 <shesek> so we'll basically have a block every 20 minutes instead of 10
457 2014-04-12 16:19:00 <maaku> which is sufficient for testing :P
458 2014-04-12 16:48:46 <ProfMac> I am reading source to understand the client.  My first task is to understand the source code related to sending a block out to the peers on the network.  I started with Submitblock on git, and I have looked at https://dev.visucore.com/bitcoin/doxygen.  Hearn told me "ProfMac: push_inventory puts the CInv into a queue for the CPeer" but I have not made progress looking for that.  I would appreciate any more hints anyone can shar
459 2014-04-12 16:54:06 <wumpus> ProfMac: peers request the block using "getdata", after which the clients sends back a "block" message (see ProcessGetData)
460 2014-04-12 16:55:35 <rnicoll> 
ACTION vaguely remembers grepping for CPeer yesterday, but also couldn't find it

461 2014-04-12 16:55:36 <wumpus> "inv" messages (that tell a peer that you have a certain object) are sent to peers in SendMessages
462 2014-04-12 16:56:05 <wumpus> (among other places, but that's where the queue is processed)
463 2014-04-12 17:01:21 <sipa> ProfMac: it's CNode, not CPeer
464 2014-04-12 17:01:36 <sipa> ProfMac: and block announcenent works different from normal relay
465 2014-04-12 17:01:53 <sipa> announcement just broadcasts the block immediately  to all peers
466 2014-04-12 17:02:03 <sipa> without waiting for a getdata after an inv
467 2014-04-12 17:05:10 <ProfMac> wumpus, sipa, thanks.  I'll go read more.  I do want to focus very narrowly on the handling of new blocks.
468 2014-04-12 17:05:39 <sipa> by new, you mean just miner, or just received?
469 2014-04-12 17:05:49 <sipa> *just mined
470 2014-04-12 17:11:45 <ProfMac> sipa, Oh, since I'm trying to learn code from zero orientation, I probably should chose something very narrow so I have some hope to get it.  I have assumed that Submitblock is used by mining pool software.  I have the eloipool source, but I have not read it & verified my assumption.
471 2014-04-12 17:11:58 <sipa> yup
472 2014-04-12 17:12:05 <ProfMac> good
473 2014-04-12 17:18:58 <cbeams> There are a couple places online where @gmaxwell refers to the "block tester test suite". Is this referring to @BlueMatt's 'test-scripts' repo, or something else?
474 2014-04-12 17:20:29 <sipa> yes
475 2014-04-12 17:20:43 <sipa> there are several layers here, i guess
476 2014-04-12 17:21:13 <sipa> pulltester runs some script that builds bitcoin for several platforms (including windows) and runs its unit teats
477 2014-04-12 17:22:05 <sipa> the unit tests (in the bitcoin repo) have support for bluematt's comparison tool (if installed), which feeds it certain sequences of invalid blocks
478 2014-04-12 17:26:30 <cbeams> thanks, sipa.
479 2014-04-12 17:48:43 <defunctzombie> what is the upper limit on how many private keys the bitcoin-qt software can store?
480 2014-04-12 18:04:04 <c0rw1n> disk space
481 2014-04-12 18:21:02 <midnightmagic> ..  realistically the wallet can't grow much larger than a GB or so without making the startup extend into 10-30 minutes.
482 2014-04-12 18:21:42 <c0rw1n> that slow? Ø_Ø
483 2014-04-12 18:22:13 <c0rw1n> oh 1G ok not 1k addresses (am an idiot)
484 2014-04-12 18:24:12 <midnightmagic> I'm restarting a wallet I have here that's.. mm.. 204MB and I'll tell you how long it takes for the wallet to load, I have logtimestamps turned on
485 2014-04-12 18:24:36 <vetch> why is the bitcoin.it wiki behind cloudflare now?
486 2014-04-12 18:24:40 <midnightmagic> this particular one is very very slow.
487 2014-04-12 18:24:48 <c0rw1n> they got ddosed?
488 2014-04-12 18:25:41 <vetch> cloudflare was used to cover up the fact that bitcointalk.org was compromised. I thought theymos was totally against it.
489 2014-04-12 18:25:49 <vetch> theymos owning the wiki now.
490 2014-04-12 18:26:04 <midnightmagic> ... wat
491 2014-04-12 18:26:23 <vetch> uh, you remember late last year when the domain of bitcointalk.org was stolen?
492 2014-04-12 18:26:55 <vetch> at that point cloudflare was used because they sign any domain of their customers with no identification.
493 2014-04-12 18:27:43 <midnightmagic> i thought it wasn't actually stolen
494 2014-04-12 18:28:02 <vetch> the name servers were changed, close enough
495 2014-04-12 18:30:26 <vetch> but anyway, the wiki's SSL is broken.
496 2014-04-12 18:32:09 <c0rw1n> isn't ssl broken everywhere as of now?
497 2014-04-12 18:32:38 <vetch> broken as in, browsers refuse to connect to it rather than plausibly insecure.
498 2014-04-12 18:50:33 <midnightmagic> yeah, so that wallet is still loading.
499 2014-04-12 18:57:27 <c0rw1n> 26 minutes and counting, that's under 10MB/minute
500 2014-04-12 19:06:32 <PRab> Any idea why bitcoind doesn't follow Junctions on windows?
501 2014-04-12 19:07:18 <PRab> I copied the data dir to my ssd then did "mklink /J" and it puked when I tried to start it up.
502 2014-04-12 19:07:40 <PRab> When I did "mklink /D" it worked just fine.
503 2014-04-12 19:08:13 <c0rw1n> they have symlinks on windows? in practice, not onl in the filesystem capabilities? since when?
504 2014-04-12 19:08:28 <PRab> Windows vista
505 2014-04-12 19:08:40 <c0rw1n> ok
506 2014-04-12 19:08:52 <c0rw1n> same volume?
507 2014-04-12 19:09:11 <PRab> Nope, one is C:\ the other is F:\
508 2014-04-12 19:09:31 <c0rw1n> i think hardlinks can't be done across volumes
509 2014-04-12 19:09:55 <PRab> correct, but I never tried to use a hardlink.
510 2014-04-12 19:10:09 <PRab> that would have been "mklink /H"
511 2014-04-12 19:10:33 <c0rw1n> ok. idk the syntax of windows mklink
512 2014-04-12 19:10:59 <c0rw1n> what happens when you try while the f: is mounted in a directory under c: ?
513 2014-04-12 19:11:40 <PRab> I hadn't tried that.
514 2014-04-12 19:11:59 <c0rw1n> i have no idea if that would change anything
515 2014-04-12 19:12:21 <c0rw1n> but the ways of windows are strange and mysterious
516 2014-04-12 19:12:27 <PRab> If I have some free time, I'll give it a shot.
517 2014-04-12 19:12:41 <PRab> I think the same thing about linux sometime.
518 2014-04-12 19:12:52 <c0rw1n> heh, not like you can type man mklink :\
519 2014-04-12 19:13:49 <midnightmagic> c0rw1n: There. It finished.   wallet              2594019ms; on a 32-cpu machine with 128GB ram, and the wallet in that case lives on a SSD volume. The wallet is 204500992 bytes big.
520 2014-04-12 19:13:58 <midnightmagic> c0rw1n: It's possible that my wallet is more complex than normal peoples'.
521 2014-04-12 19:14:13 <midnightmagic> The SSD is a very quick Samsung 840 pro
522 2014-04-12 19:14:27 <c0rw1n> 40 minutes -_Ø
523 2014-04-12 19:23:42 <kuzetsa> midnightmagic: wow, 200 mb wallet?
524 2014-04-12 19:23:57 <kuzetsa> mine's still less than 5mb
525 2014-04-12 19:35:39 <J_levin> Am watching a talk about Researchers trying to get some information from developers
526 2014-04-12 19:36:03 <J_levin> I am doing some work on the incentives of miners to include more transactions in blocks
527 2014-04-12 19:37:19 <J_levin> I want to get some feedback on two dynamics that I am analysing
528 2014-04-12 19:37:54 <J_levin> The increase in the size of a block slows propagation. This means that the probability of another block being found and beating your block round the network has increased. This is the true marginal cost of including an extra transaction in a block as the cost of computation is negligible.
529 2014-04-12 19:49:45 <gmaxwell> J_levin: there are some complincations, not all miners and not all of the world forward blocks in the manner you thin.
530 2014-04-12 19:50:11 <gmaxwell> J_levin: for example p2pool preforwards the transasctions and as a result must send much less data when it finds a block.
531 2014-04-12 20:16:07 <J_Levin> Thanks @gmaxwell I understand that not all pools will propagate blocks and transactions in the same way. I want to assess some of the claims that the marginal cost of including a transaction is high. If as you say there are different ways to ensure faster propagation, I still think it is important to understand the incentives driving this behaviour
532 2014-04-12 20:16:57 <J_Levin> The other interesting dynamic is The increase in the size of a block also means that due to the slower propagation, miners that have not heard about the new block will be working on a block that is more likely to be orphaned (working on an old problem). This is a negative externality on the network and increases the profitability of the miner producing the bigger block and those that were quick to hear about it.
533 2014-04-12 20:17:31 <GAit> is it me or there seems to be some issue with cloudflare certificate and the bitcoin wiki?
534 2014-04-12 20:21:32 <gmaxwell> J_Levin: just making sure you're aware of that.
535 2014-04-12 20:21:58 <J_Levin> does that mean that P2Pool propagates blocks faster?
536 2014-04-12 20:22:32 <gmaxwell> J_Levin: it does, and /very/ seldom has an orphan block.
537 2014-04-12 20:23:07 <J_Levin> @gmaxwell do you know where I can find some reliable orphan data for P2Pool?
538 2014-04-12 20:24:53 <gmaxwell> unfortunately the recent data is less useful because P2Pool's relative hashrate has fallen to low enough that its harder to make observations of the real orphan rate.  The author of p2pool probably has the best historic data.
539 2014-04-12 20:26:52 <gmaxwell> J_Levin: people have written pretty extensively about their own informal analysises of block propagation as a function of size, but I don't think any of their work has been especially rigorous.  Though there has been some data published that finds a size dependence (as expected), though that data is before 'modern' bitcoin software existed which caches the validation so relaying a block involves very little computation.
540 2014-04-12 20:28:42 <J_Levin> @gmaxwell Good to know. We are working on providing a more rigorous approach and data source using distributed nodes but unfortunately will not be finished before I need to submit this paper
541 2014-04-12 20:30:42 <J_Levin> @gmaxwell when that paper talks about propagation delays, do you think most of that is attributed to computation at each hop or something else?
542 2014-04-12 20:31:54 <gmaxwell> considering that we went from 2 seconds of computation on slower computers for larger blocks to more like 100ms, I think most of it was computation, not serialization delay.
543 2014-04-12 20:32:11 <gmaxwell> The bitcoin reference software also has a 100ms sleep in the message handling loop that adds considerable latency.
544 2014-04-12 20:33:20 <sipa> does it still?
545 2014-04-12 20:33:24 <sipa> i believe 0.9 removed that
546 2014-04-12 20:33:33 <J_Levin> @gmaxwell Great stuff, the 100ms sleep is independent of block size I presume.
547 2014-04-12 20:33:49 <hno> J_Levin, there is counter factors to that in improved network latency in general. I have looked into all of our blocks which have become stale and it's always either been very very close (within a couple of seconds) hits found by other pools or operational issues outside bitcoin. So no block propagation due to size is not worrying me much, and even thinking of increasing it a bit.
548 2014-04-12 20:35:24 <gmaxwell> sipa: it's still there. It sometimes skips it when it knows it already has mode data to process.
549 2014-04-12 20:35:41 <gmaxwell> But when it actually runs out of data it sleeps.
550 2014-04-12 20:36:24 <J_Levin> hno, thanks for that. The reason that I would suggest it is very close is due to the information propagation. It is highly unlikely after approximately 8 seconds that another block can beat yours round the network for two reasons: 1. Less miners are working on a conflicting block 2. Your block is more likely to be included in the main chain even given a partition
551 2014-04-12 20:36:26 <gmaxwell> ThreadMessageHandler needs a semaphore to avoid it completely, I htink.
552 2014-04-12 20:39:33 <J_Levin> I think optimal block size strategy for pools is likely to depend on share of the hashing rate and connectivity to the network. Am trying to formalise the model over the next week and would like to have it peer reviewed.
553 2014-04-12 20:40:41 <hno> Optimal is quite subjective. There is other factors involved than only maximising coin generation.
554 2014-04-12 20:41:38 <ProfMac> There is something I don't understand here.  I assume that two competing blocks will not have identical work.  I am also assuming that "work" is the number of leading 0 bits in the hash.  I also have heard that the client accepts the block chain with the largest work.  Given all this, I assume that all the clients should accept the same block, no matter which it receives first.  Yet, i don't think that happens.
555 2014-04-12 20:42:02 <ProfMac> Unfortunately, I have not read enough code to understand all of this from what the source says.
556 2014-04-12 20:43:04 <ProfMac> Is there an advantage to a miner to keep mining a little longer, in the hopes of producing a competing block with larger work?
557 2014-04-12 20:43:45 <sipa> ProfMac: all your assumptions are wrong
558 2014-04-12 20:43:58 <ProfMac> Please help clarify.
559 2014-04-12 20:44:01 <sipa> ProfMac: two competing blocks have almost always the same work
560 2014-04-12 20:44:12 <sipa> work is defined as the expected number of hashes needed to satisfy the target
561 2014-04-12 20:44:17 <ProfMac> (all, that's somehow interesting itself.)
562 2014-04-12 20:44:30 <sipa> so it doesn't depend on the hash of the block; only on its difficulty
563 2014-04-12 20:45:37 <sipa> also, the actual rule is: nodes consider the chain active which: 1) is valid  2) among the valid ones, has the most work  3) among those with the same work, has the earliest seen tip block
564 2014-04-12 20:47:16 <hno> And is work of a chain then measured as sum of the difficulty of the block chain?
565 2014-04-12 20:47:41 <ProfMac> This is probably the area where I will learn the source code after I finish understanding all of Submitblock.  Do you have some hints for where to read, such as procedure names or file name+line numbers?
566 2014-04-12 20:48:30 <J_Levin> hno, I agree there are many other factors that play a role in mining strategy, I still think that it is important to get to grips with the economic incentives if profit were the only motive. Could you provide some other objectives that you pursue as part of your strategy?
567 2014-04-12 20:49:25 <J_Levin> Does anyone know who runs this http://bitcoinstats.com/network/propagation/ and if the data is available?
568 2014-04-12 20:50:54 <ProfMac> sipa: thanks.
569 2014-04-12 20:50:59 <gmaxwell> it's cdecker's work, and they should make it available if you request it.
570 2014-04-12 20:50:59 <hno> Pools also need to consider reputation, and everyone mining also keep in mind the viability of the network as it's all in our interest that bigcoin surives and does well.
571 2014-04-12 20:51:04 <gmaxwell> If they don't let me know.
572 2014-04-12 20:51:12 <hno> bitcoin.
573 2014-04-12 20:51:29 <hno> J_Levin ^
574 2014-04-12 20:52:38 <hno> J_Levin, from a coin generation perspectove alone there is nothing that stops us from mining coinbase transaction only. But if we did that then bitcoin would not work, and it would be meaningless for us to mine in the long run.
575 2014-04-12 20:53:38 <ProfMac> Can a 51% attack go back 2016 blocks, mine an alternate valid chain for a long time, and catastrophically gain control when their now long chain becomes the highest difficulty?
576 2014-04-12 20:54:05 <sipa> ProfMac: that's a 51% attack
577 2014-04-12 20:54:16 <sipa> it allows rewriting the chain (with valid blocks)
578 2014-04-12 20:54:46 <J_Levin> thanks hno, one thing that I also thought about was are there punishment strategies available to prevent such behaviour. Could pools with significant hashing power refuse to mine on top of 0 transaction blocks?
579 2014-04-12 20:54:58 <ProfMac> neglecting checkpoints, can it go back as far as it has computation resources to succeed with?
580 2014-04-12 20:55:13 <sipa> ProfMac: which is to the genesis block, yes
581 2014-04-12 20:55:21 <sipa> J_Levin: they can shun them, but not refuse
582 2014-04-12 20:55:40 <ProfMac> Thanks.
583 2014-04-12 20:55:46 <sipa> J_Levin: refusing would cause a fork, unless a majority of the hashpower would decide to implement such a rule (which turns it into a softforking change)
584 2014-04-12 20:56:10 <hno> J_Levin, perhaps, but 0 transaction block happens every now and then today by how pools operate. There is a small window after a block is found until the pool have learnt what transactions to include.
585 2014-04-12 20:57:34 <cbeams> how can a block be "found" (solved?) without any transactions?
586 2014-04-12 20:57:42 <hno> we did mine one such block some time ago.
587 2014-04-12 20:57:45 <cbeams> and in any case, wouldn't any block have at least a generation transaction?
588 2014-04-12 20:58:12 <sipa> yes, they means blocks with only a coinbase
589 2014-04-12 20:58:14 <hno> cbeams, sure, the coinbase generation transaction is always there. That is inserted by the pool.
590 2014-04-12 20:58:52 <J_Levin> sipa, the interesting thing for me here is that say a miner had 30% of the network hashpower and made a statement about how they would shun blocks with 0 transactions in. Then the other 70% of the hashpower would have to make an assessment whether over 50% had adopted the same strategy. There need not be explicit rule making to move to this new equilibrium
591 2014-04-12 20:59:50 <cbeams> interesting. I was actually just wondering about this anyway: so a miner (or pooL) creates a new block with nothing more than its coinbase, and then the block gets solved before any transactions have had a chance to be added to it?
592 2014-04-12 21:00:16 <sipa> J_Levin: not if it's just shunning (shunning means you allow such blocks still, but prefer newer blocks with the same work if they have more transactions than just the coinbase)
593 2014-04-12 21:00:17 <hno> J_Levin, that might indeed happen if some large miner for some strange reason routinely starts to mine empty blocks. But the likelyhood for that happening is imho below 0.
594 2014-04-12 21:00:49 <hno> not counting operational error.
595 2014-04-12 21:01:04 <J_Levin> hno, glad to hear it!
596 2014-04-12 21:01:48 <J_Levin> sipa, is refusing not in the strategy set?
597 2014-04-12 21:01:59 <hno> Why not routinely mine empty blocks:
598 2014-04-12 21:02:29 <hno> - Mining empty blocks undermines your reputation, meaning less hashrate wants to use the pool.
599 2014-04-12 21:02:42 <sipa> J_Levin: only if you know a majority of the hashrate does implement the same rule
600 2014-04-12 21:03:40 <hno> - Mining empty blocks undermines the bitcoin network as such, greatly risking the bitcoin value. Miners want value to be stable and increasing. Not unreliable and decreasing.
601 2014-04-12 21:05:01 <J_Levin> Sorry to keep pushing this but it is really useful for my understanding. Is this only due to the economically rational strategy is to mine on the longest chain? My understanding is that the information about what strategies miners are pursuing are private
602 2014-04-12 21:05:55 <sipa> J_Levin: if you implement a stronger validity rule than the majority of the network, you will end up on your own chain, as you'll refuse the one the rest builds
603 2014-04-12 21:05:58 <midnightmagic> cbeams: They mean non-coinbase tx. But it is possible to have a generation transaction that pays less than the reward.
604 2014-04-12 21:06:03 <sipa> J_Levin: which means an irreconsilable fork
605 2014-04-12 21:06:24 <J_Levin> thanks sipa
606 2014-04-12 21:06:29 <topynate> hno: it's a prisoner's dilemma situation. so long as the other miners carry on putting txs in blocks, you can cheat by mining empty blocks without seriously affecting the price
607 2014-04-12 21:07:05 <topynate> or rather your gain due to cheating might outweigh the harm you do. so tragedy of the commons, rather than PD, i guess
608 2014-04-12 21:07:46 <ProfMac> Does the transaction fee, in principle, put pressure against just that behavior?
609 2014-04-12 21:08:29 <hno> cbeams, yes, pools can start mine on a new block as soon as it hears about the previous block. There is then a slight delay before it receives a list of transactions to include in the block. This is from an slightly asymmetric path in how pools get block information.
610 2014-04-12 21:09:07 <hno> ProfMac, yes the transaction fees also put pressure agains such behavior.
611 2014-04-12 21:09:09 <topynate> ProfMac: yes, there has to be a fee per kilobyte that makes it profitable to include a transaction.
612 2014-04-12 21:09:29 <sipa> ProfMac: no
613 2014-04-12 21:09:51 <sipa> ProfMac: because if you refuse a transaction, and a competitor miner includes it, you still have to do the work of validating it
614 2014-04-12 21:10:03 <J_Levin> topynate, it gets slightly stranger when you consider the other participants that you are affecting when you include another transaction. The people that hear about a very big block are in a relatively strong position for the next block given the large block gets accepted. The miners that hear about the big block late due to its size are at a relative disadvantage for the next block.
615 2014-04-12 21:10:20 <sipa> ProfMac: eh, i didn't answer your actual question
616 2014-04-12 21:10:28 <sipa> ProfMac: assuming a limit block space and competition for it, yes
617 2014-04-12 21:14:45 <hno> J_Levin, that's very marginal I think. The disadvantage is more at the slower propagating block than the miners.
618 2014-04-12 21:15:31 <hno> the slower a block propagates the higher risk of it getting forked. But from perspective of each miner the risk is much lower.
619 2014-04-12 21:15:56 <hno> as each miners hash rate is small in relation to the whole network.