1 2014-10-08 00:09:41 <dhill> [6~[6~[6~[6~/win 5
  2 2014-10-08 00:09:49 <dhill> nuts
  3 2014-10-08 00:09:51 <dhill> sorry
  4 2014-10-08 00:13:02 <blast_> you need 8's to win
  5 2014-10-08 00:13:06 <blast_> obv
  6 2014-10-08 02:38:31 <HaltingState> Previous output in the form TXHASH:INDEX, what is index parameter in transaction input?
  7 2014-10-08 02:49:45 <phantomcircuit> HaltingState, output
  8 2014-10-08 03:33:27 <dgenr8> HaltingState: txin:vout
  9 2014-10-08 03:36:37 <dgenr8> HaltingState: txid:vout rather
 10 2014-10-08 03:51:55 <webdeli> If I sell a sell a bitcoin and attach a right to it... can that right be forever tracked or does mixing effectively stop the tracking of a specific set of Satoshis?
 11 2014-10-08 03:52:41 <webdeli> An answer pointing to a wikipage / whitpaper / github repo etc is a perfectly adequate answer.
 12 2014-10-08 03:53:01 <webdeli> Assume I have a medium level of knowlege already.
 13 2014-10-08 03:53:33 <copumpkin> "a specific set of satoshis"
 14 2014-10-08 03:53:43 <legendary> with mixing you wouldnt know who some of the bitcoins went to
 15 2014-10-08 03:53:53 <legendary> new outputs would be created
 16 2014-10-08 03:54:12 <legendary> some would go to one guy
 17 2014-10-08 03:54:14 <legendary> some to another
 18 2014-10-08 03:54:15 <copumpkin> there's no such thing as a specific set of satoshis, unless I'm misunderstanding you
 19 2014-10-08 03:54:55 <sipa> webdeli: you may want to look up 'colored coins'
 20 2014-10-08 03:56:01 <webdeli> ok.. I have heard it referred to.. what's the underlying mechanic for colored coins in a sentence?
 21 2014-10-08 03:56:16 <sipa> but you have to realize that every transactions *destroys* the input coins and creates new ones... you can define your own rules about how particular extra properties of particular coins get tracked through to the new coins when being spent, if you write the software for doing so, and all others users of coins with such properties do so too
 22 2014-10-08 03:57:13 <sipa> in a way, every bitcoin transaction perform mixing
 23 2014-10-08 03:57:28 <webdeli> Can a coin be 'desaturated' of colour by intent or mistake? .. or ... Does the fundamental mechanics of the distributed ledger make in always 100% possible to track and trace the specific satoshis to which a right attaches, regardless of thier flow through time?
 24 2014-10-08 03:57:57 <webdeli> Background here is twofold:
 25 2014-10-08 03:58:26 <webdeli> One rights attachment as a my enquiry..
 26 2014-10-08 03:58:59 <sipa> webdeli: read my sentence again
 27 2014-10-08 03:59:08 <webdeli> Two... curious to know how real the spector of future adversarial green flag / red flagged satoshis is.
 28 2014-10-08 03:59:12 <sipa> every transaction *destroys* the original coins
 29 2014-10-08 03:59:28 <copumpkin> coins don't really have an identity to begin with
 30 2014-10-08 03:59:29 <sipa> you can define your own rule for whatever you want to track and how it is inherited
 31 2014-10-08 03:59:35 <copumpkin> the name is somewhat misleading
 32 2014-10-08 03:59:38 <webdeli> sipa: the colored coins or the every transaction is mixing one?
 33 2014-10-08 04:00:10 <sipa> webdeli: first learn how bitcoin transactions work please
 34 2014-10-08 04:00:37 <webdeli> ok ok ok.. I will.
 35 2014-10-08 04:00:53 <webdeli> Andreas' book is still a few days away.
 36 2014-10-08 04:01:02 <webdeli> And the wiki scratches my eyeballs.
 37 2014-10-08 04:01:03 <sipa> don't read it
 38 2014-10-08 04:01:19 <sipa> the book seems to be wrong in any ways
 39 2014-10-08 04:01:20 <webdeli> But ill get over myself and get the hard yards done inspite of the hurdles.
 40 2014-10-08 04:01:36 <sipa> start by reading the developer documentation on bitcoin.org
 41 2014-10-08 04:01:45 <sipa> *many
 42 2014-10-08 04:02:09 <webdeli> sipa: roger that.... opportunity come dressed in overalls looking like hard work. I get it. Stop short-cutting.
 43 2014-10-08 04:02:16 <webdeli> I will. Thank you so much.
 44 2014-10-08 04:02:27 <sipa> feel free to ask specific questions here
 45 2014-10-08 04:03:41 <webdeli> If I sell you a bitcoin - can I tract it's satoshi's forever and offer a redemeable right to the holder of any satoshi through time.
 46 2014-10-08 04:04:17 <copumpkin> [23:59:06]  <copumpkin>
 47 2014-10-08 04:04:24 <copumpkin> [23:59:13]  <copumpkin>
 48 2014-10-08 04:04:24 <webdeli> Can I as the seller alway tally the satoshi through time to know at any time in the future how many satoshis with the right attached to them could be redemmed.
 49 2014-10-08 04:05:07 <sipa> webdeli: the short answer is no
 50 2014-10-08 04:05:07 <webdeli> ok.... then to understand that better (coins have no identity)  I need to go back to dev docs.
 51 2014-10-08 04:05:15 <sipa> the longer answer is maybe
 52 2014-10-08 04:05:17 <webdeli> sipa: thank you.
 53 2014-10-08 04:05:24 <webdeli> I appreciate that.
 54 2014-10-08 04:05:31 <sipa> but to understand, please learn how bitcoin transactions work
 55 2014-10-08 04:05:58 <webdeli> I will do just that. again - sincerely thankyou for the quick response.
 56 2014-10-08 04:18:45 <kgreenek> is there any way to create a transaction where the recipient can specify a value up to, but not more than a certain amount?
 57 2014-10-08 04:20:53 <sipa> kgreenek: ?
 58 2014-10-08 04:20:54 <kgreenek> er, that would probably require more than one transaction.
 59 2014-10-08 04:21:13 <sipa> the receiver specifying the value?
 60 2014-10-08 04:21:16 <kgreenek> something like, first send to a 2-of-2 like in a micropayment channel
 61 2014-10-08 04:21:22 <kgreenek> yeah
 62 2014-10-08 04:21:47 <kgreenek> I'm trying to figure out a way to design something like a credit card auth/capture/settle
 63 2014-10-08 04:22:13 <sipa> the receiver can always send a bunch back...
 64 2014-10-08 04:22:35 <kgreenek> yeah I guess that would work lol. just makes the accounting weird. and taxes..
 65 2014-10-08 04:22:54 <sipa> don't confuse bitcoin transactions with payments
 66 2014-10-08 04:23:06 <sipa> your accounting does not track individual dollar bills
 67 2014-10-08 04:23:19 <sipa> nor should it concern itself with individual bitcoin transactions
 68 2014-10-08 04:23:21 <kgreenek> true
 69 2014-10-08 04:23:58 <kgreenek> the wallet couldn't tell which transaction was the refund though.
 70 2014-10-08 04:24:09 <kgreenek> so the ui for a wallet would look confusing for something like that
 71 2014-10-08 04:24:17 <kgreenek> i.e. think of filling up gas at a pump
 72 2014-10-08 04:24:23 <kgreenek> first they auth something like $100
 73 2014-10-08 04:24:31 <kgreenek> then settle for the actual amount at the end
 74 2014-10-08 04:25:08 <kgreenek> on your credit card account, the first $100 transaction goes away after the transaction settles
 75 2014-10-08 04:27:29 <phantomcircuit> kgreenek, micropayment channel combined with a refund of the difference is the correct way to do that i believe
 76 2014-10-08 04:27:44 <phantomcircuit> the key incite is that the "auth" is the same as a charge + refund in reality
 77 2014-10-08 04:28:21 <kgreenek> hmm how would that refund work, combined with a micropayment channel
 78 2014-10-08 04:28:38 <kgreenek> so first the user and merchant lock up funds in a 2-of-2
 79 2014-10-08 04:29:03 <kgreenek> and the user has a refund transaction that is signed by the merchant for the full amount. but it has some nlocktime (24 hours)
 80 2014-10-08 04:29:18 <kgreenek> now the micropayment channel is open for 24 hours
 81 2014-10-08 04:31:18 <phantomcircuit> something like that
 82 2014-10-08 04:36:11 <kgreenek> hmm but then how can the merchant settle for an arbitrary amount later.
 83 2014-10-08 04:38:51 <phantomcircuit> kgreenek, there is a much easier way
 84 2014-10-08 04:39:06 <phantomcircuit> which is basically exactly identical to how the auth with a card works
 85 2014-10-08 04:39:17 <phantomcircuit> the customer simply pays the merchant the full amount
 86 2014-10-08 04:39:22 <phantomcircuit> then the merchant does a refund
 87 2014-10-08 04:39:31 <kgreenek> yeah I can't think of a better way
 88 2014-10-08 04:39:49 <kgreenek> the only drawback with that is that if the merchant goes offline, then you end up losing the full amount
 89 2014-10-08 04:40:12 <phantomcircuit> with bitcoin you can prevent one issue there which is the merchant's system dies and never does the refund with nlocktime stuff
 90 2014-10-08 04:40:32 <phantomcircuit> but that is probably only a marginal improvement in 99.999% of use cases
 91 2014-10-08 04:40:45 <kgreenek> yeah true
 92 2014-10-08 04:41:16 <kgreenek> so the accounting would get weird in the wallet with this. it would be nice if the wallet could associate the refund to the original transaction somehow, to show only the final amount
 93 2014-10-08 04:41:48 <kgreenek> payment protocol?
 94 2014-10-08 04:42:41 <kgreenek> oh there we go. the user provides a refund address in the Payment message in response to a PaymentRequest
 95 2014-10-08 04:43:33 <kgreenek> so if your wallet is generating a new address for every payment, if it sees a refund sent to the refund address, it knows that it's uniquely associated with that one payment.
 96 2014-10-08 04:43:56 <kgreenek> and could display it as if it were "settling" the previous transaction.
 97 2014-10-08 04:44:07 <kgreenek> does that make sense?
 98 2014-10-08 04:46:21 <phantomcircuit> kgreenek, yup
 99 2014-10-08 04:46:57 <kgreenek> kind of changes the symantics of that refund address. but as far as I know it's not widely used today.
100 2014-10-08 04:47:02 <kgreenek> cool :)
101 2014-10-08 04:47:40 <kgreenek> semantics*
102 2014-10-08 05:01:02 <phantomcircuit> kgreenek, only slightly
103 2014-10-08 05:09:26 <BlueMatt> sipa: wanna close #5062
104 2014-10-08 05:29:20 <webdeli> sipa: Are you a contrib to bitcoin ref client?
105 2014-10-08 05:32:11 <BlueMatt> webdeli: dont ask to ask, just ask
106 2014-10-08 05:32:48 <BlueMatt> (unless its security-sensitive, then email bitcoin-security@lists.sourceforge.net)
107 2014-10-08 05:33:18 <webdeli> Ah..ok - sipa - what is your github username so I can go blame the sourcecode for your commits.
108 2014-10-08 05:33:50 <webdeli> Extending out of my intention to go away and learn as per your earlier advice.
109 2014-10-08 05:33:53 <BlueMatt> tried sipa?
110 2014-10-08 05:34:08 <BlueMatt> (sipa's github/irc is the same)
111 2014-10-08 05:37:52 <webdeli> Roger that. thanks.
112 2014-10-08 05:44:56 <webdeli> Ah... only 375 commits (Like 4th most) what does Sipa know about bitcoin... (so kidding).
113 2014-10-08 05:45:19 <webdeli> So... yeah... thank you again Sipa for earlier response / advice.
114 2014-10-08 06:42:48 <moio> hi - I am currently using ChromaWallet (http://chromawallet.com/) on testnet and I get 500 errors. Is TestNet experiencing problems currently?
115 2014-10-08 06:43:46 <BlueMatt> if chromawallet is having problems, chromawallet is the source of the problems
116 2014-10-08 06:44:06 <BlueMatt> ofc they could be unrelated to mainnet, but still
117 2014-10-08 06:44:27 <moio> BlueMatt, http://faucet.xeno-genesis.com/ is also down, and chromawallet works fine on mainnet, that's why I am asking
118 2014-10-08 06:45:23 <moio> 
ACTION tries bitcoin-qt now

119 2014-10-08 07:22:03 <wumpus> sipa: hmm did you see my comment here https://github.com/bitcoin/bitcoin/pull/5057#issuecomment-58316716   ; I think it makes sense to run the "Recursively process..." loop for known blocks, just in case there are still some unprocessed successors in mapBlocksUnknownParent, this is more robust in case of interruptions
120 2014-10-08 07:36:37 <sipa> wumpus: yes, i think you're right
121 2014-10-08 07:36:41 <sipa> i'll fix it
122 2014-10-08 07:36:45 <wumpus> ok thanks
123 2014-10-08 07:43:49 <BlueMatt> sipa, wumpus: so....headers first today? :)
124 2014-10-08 07:44:05 <wumpus> ACK
125 2014-10-08 07:46:46 <wumpus> it's hard to believe :)
126 2014-10-08 07:53:28 <sipa> wumpus: i also believe you' re right that SetPos can' t seek forward
127 2014-10-08 07:53:36 <sipa> fixing ythat too
128 2014-10-08 07:53:52 <sipa> BlueMatt: running my ssh server on port 2222 makes it reachable from hotel wifi
129 2014-10-08 07:54:00 <sipa> which, despite that, still sucks
130 2014-10-08 07:54:17 <wumpus> I always run my ssh servers on port 443 ;)
131 2014-10-08 07:59:05 <sipa> wumpus: pushed a new version, though i can't test currnetly
132 2014-10-08 07:59:38 <sipa> it really just deserializes every block now, but skips the ones already processed
133 2014-10-08 08:01:42 <wumpus> ok with me - optimization can always be done later, let's aim for robustness foremost
134 2014-10-08 08:03:54 <wumpus> I'll test it
135 2014-10-08 08:19:05 <wumpus> seems to work fine - at height 184375 now
136 2014-10-08 09:40:18 <moio> guys, does anyone have an idea on what this means? http://paste.lisp.org/display/143963 (bitcoind 0.9.3 here)
137 2014-10-08 09:51:06 <phantomcircuit> moio, something probably bad
138 2014-10-08 09:51:18 <phantomcircuit> likely your hw is broken and doing weird things
139 2014-10-08 09:54:19 <wumpus> moio: does the sync continue after that?
140 2014-10-08 09:55:18 <wumpus> the main chain has 0000000000000000032292c6a4e00a367fc561e4502ccd17fde270bcf51368f7 and 00000000000000003e8f0f5e6f2b94bf37ea0ce03a779bfa03981723e69d1691 as blocks 299039 and 299040, so it correctly sees that as a fork
141 2014-10-08 09:55:29 <moio> wumpus, yes but the server got in safe mode
142 2014-10-08 09:57:08 <moio> wumpus, should I redownload the chain and swap it?
143 2014-10-08 09:57:12 <wumpus> no
144 2014-10-08 09:57:25 <wumpus> as I see it, nothing is wrong
145 2014-10-08 09:57:37 <wumpus> you just got a fork @ 299039 then continued on the main chain
146 2014-10-08 09:57:57 <wumpus> not sure why the client was put into safe mode, but you can safely exit it
147 2014-10-08 09:58:04 <moio> what about the "Chain state database corruption likely." message?
148 2014-10-08 09:58:23 <moio> note that safe mode is actually on testnet. Not sure if that makes any difference
149 2014-10-08 09:58:23 <wumpus> well it happens that clients suddenly the main chain as a corrupted fork
150 2014-10-08 09:58:42 <wumpus> in that case it's database corruption
151 2014-10-08 09:59:12 <moio> wumpus, ok. What should I do to clear the corruption
152 2014-10-08 09:59:14 <moio> ?
153 2014-10-08 09:59:14 <wumpus> nothing
154 2014-10-08 09:59:30 <wumpus> it's fine, just continue
155 2014-10-08 09:59:46 <moio> what about the safe mode? can I switch back to regular mode?
156 2014-10-08 09:59:56 <wumpus> I think so. I already said that didn't I?
157 2014-10-08 10:00:22 <moio> oh right. I did not read your sentence correctly, sorry
158 2014-10-08 10:00:41 <wumpus> if it continues, and there are no errors while verifying along the main chain, it was wrongly put into safe mode
159 2014-10-08 10:02:02 <moio> ok. I'll try and report back if I have further issues. Thanks for your help and patience, I am still a noob :-)
160 2014-10-08 10:04:09 <wumpus> well thanks for reporting it, it may be a bug
161 2014-10-08 10:06:25 <wumpus> i think the safe mode is meant to be temporary
162 2014-10-08 10:20:56 <Emcy> bitcoin has safe mode?
163 2014-10-08 10:27:16 <amtri> safe mode?
164 2014-10-08 10:28:44 <hearn> Emcy: it used to
165 2014-10-08 10:28:49 <hearn> probably it should once again
166 2014-10-08 10:28:54 <hearn> (albeit, triggered in a different way)
167 2014-10-08 10:31:12 <wumpus> yes, it has a safe mode, it can be triggered by suspected database corruption or strange forking conditions
168 2014-10-08 10:31:18 <Emcy> what was the purpose of safe mode
169 2014-10-08 10:31:51 <wumpus> mostly warning when conditions on the network are uncertain
170 2014-10-08 10:33:22 <Emcy> hm why would you take that out
171 2014-10-08 10:33:27 <wumpus> ie, making sure you don't send transactions when there is a large fork in progress
172 2014-10-08 10:33:31 <wumpus> yes, why would you?
173 2014-10-08 10:34:32 <wumpus> I'm fairly sure it was never taken out, there was just a guy here who managed to trigger it with 0.9.3
174 2014-10-08 10:36:29 <hearn> the old safe mode was triggerable by a satoshi signed alert
175 2014-10-08 10:36:32 <hearn> that was taken out
176 2014-10-08 10:36:45 <wumpus> it's no longer triggerable by a signed alert
177 2014-10-08 10:37:53 <hearn> right, i see, current safe mode disables all RPCs when strWarning != ""
178 2014-10-08 10:38:47 <wumpus> it disables some RPCs, not all, just those with okSafeMode=false https://github.com/bitcoin/bitcoin/blob/master/src/rpcserver.cpp#L240
179 2014-10-08 10:39:10 <wumpus> excluding the wallet, that's just send and signrawtransaction
180 2014-10-08 10:39:38 <hearn> and mining
181 2014-10-08 10:39:47 <hearn> oh, no, oops
182 2014-10-08 10:39:49 <hearn> read wrong column
183 2014-10-08 10:40:01 <wumpus> disabling mining would be very bad :)
184 2014-10-08 10:40:06 <hearn> yeah. perhaps mining should be made dependent on safe mode.
185 2014-10-08 10:40:17 <hearn> well, if your node thinks its forked, maybe that's the best thing to do
186 2014-10-08 10:40:34 <hearn> otherwise you are paying for electricity and paying pool payouts, but aren't going to get any block rewards
187 2014-10-08 10:40:35 <wumpus> that makes it a serious DoS to trigger safe mode accidentally
188 2014-10-08 10:40:44 <wumpus> you could just halt big miners
189 2014-10-08 10:41:17 <wumpus> also - mining will be necessary to restore the network
190 2014-10-08 10:41:35 <hearn> at the moment, *only* the fork warning triggers that. so to mount such a DoS you'd already need to be able to fork the chain quite deeply
191 2014-10-08 10:41:53 <hearn> (72 blocks)
192 2014-10-08 10:42:05 <wumpus> possibly, but believe me, stopping mining would have dangerous consequences, this discussion has been done before
193 2014-10-08 10:42:07 <hearn> sure, of course, but then they can restart with -disablesafemode and carry on once they are fixed (most likely, upgraded)
194 2014-10-08 10:42:37 <hearn> given how the code works, it's not possible for all mining to stop this way - some miners have to be on the other side of the fork
195 2014-10-08 10:42:51 <hearn> it's only miners who have fallen hopelessly behind the chain head who would get this warning
196 2014-10-08 10:43:05 <wumpus> you can't assume that always to be the case
197 2014-10-08 10:43:24 <hearn> you mean if someone adds more cases to GetWarnings("rpc") in future?
198 2014-10-08 10:43:26 <stonecoldpat> to be 72 blocks into a fork, seems a bit more worrying than triggering safe mode? (if this is what your talking about?)
199 2014-10-08 10:43:27 <wumpus> miners can decide for themselves to stop if they detect safe mode
200 2014-10-08 10:44:09 <Emcy> you took out satoshis alert?
201 2014-10-08 10:44:16 <Emcy> alert key
202 2014-10-08 10:44:24 <hearn> no. it was handed on to gavin and theymos, iirc
203 2014-10-08 10:44:30 <wumpus> and no, you don't need a 72-deep fork to trigger safe mode, the guy posting above had a 2-deep fork
204 2014-10-08 10:44:37 <hearn> what was taken out was satoshis ability to stop the system with his signing key
205 2014-10-08 10:44:54 <Emcy> ........he had that ability?
206 2014-10-08 10:45:00 <Emcy> does anyone else?
207 2014-10-08 10:45:14 <wumpus> that has been removed a looong time ago
208 2014-10-08 10:45:16 <hearn> yeah he did once. it was added after one of the disasters, possibly the overflow bug
209 2014-10-08 10:46:01 <wumpus> nowadays the alert just pops up a warning (in the ui) and/or launches alertnotify so that people can take their own decision as to what to do with it
210 2014-10-08 10:46:11 <hearn> wumpus: right, sorry, the code says 7 blocks within 72 of ours
211 2014-10-08 10:46:33 <hearn> wumpus: not sure how he managed to get rpc safe mode after 2 blocks. there must be a code path i'm not seeing
212 2014-10-08 10:46:55 <hearn> i wonder if it can be affected by a fork crossing a difficulty transition
213 2014-10-08 10:47:08 <hearn> the "7 blocks" is tested in a slightly odd way, by multiplying block work
214 2014-10-08 10:49:55 <wumpus> yes, it's odd
215 2014-10-08 16:51:19 <Taek42> reading "Bitcoin Developer Guide"
216 2014-10-08 16:51:34 <Taek42> I don't think it discusses the inflation rate at all
217 2014-10-08 16:51:54 <Taek42> eg that the coinbase is 50 initially, and halves every 210,000 blocks
218 2014-10-08 17:05:03 <BlueMatt> wumpus/sipa: whats up with headers first?
219 2014-10-08 17:05:28 <BlueMatt> looks like latest changes were tested?
220 2014-10-08 17:09:49 <gmaxwell> Taek42: subsidy is the word you want.
221 2014-10-08 17:10:54 <Taek42> thanks. Is there a reason that subsidy is not covered in the developer guide, or can it be considered a bug?
222 2014-10-08 17:12:41 <Taek42> *subsidy is covered per-block, but they don't discuss the legal values for subsidies
223 2014-10-08 17:26:06 <wumpus> BlueMatt: yes, I have done a full reindex with them
224 2014-10-08 17:26:40 <wumpus> and I'm running that code on two nodes
225 2014-10-08 18:00:08 <dfletcher> hi what is the second argument to the CTxIn constructor doing? (it's also called vout in createrawtransaction) ?
226 2014-10-08 18:01:05 <wumpus> vout is the output number
227 2014-10-08 18:01:41 <dfletcher> ok what does that mean heh. the index in vout in the previous tx?
228 2014-10-08 18:02:04 <wumpus> yes
229 2014-10-08 18:02:10 <dfletcher> ahhh ok
230 2014-10-08 18:02:21 <dfletcher> suspected that, wanted to be sure. thanks wumpus
231 2014-10-08 18:17:05 <sipa> Taek42: you're very welcome to improve it