1 2015-04-02 01:06:56 <fanquake> ;;blocks
2 2015-04-02 01:06:57 <gribble> 350301
3 2015-04-02 01:24:03 <morcos> sipa: not sure of your current timezone, but just in case, are you around?
4 2015-04-02 01:25:08 <sipa> morcos: yes, PDT
5 2015-04-02 01:25:55 <morcos> sipa: it happened in autoprune, because we were pruning (and thus flushing databases) during disk space allocation, which for undo files can happen inside of connectTip where pCoinsTip is intermediate to the view you're updating with the block your connecting
6 2015-04-02 01:26:01 <morcos> i'm sure we can find a way to work around that
7 2015-04-02 01:26:30 <sipa> morcos: that seems dangerous in any case
8 2015-04-02 01:26:34 <morcos> but it was a bit unexpected that it caused an error to flush pcoinsTip and the error was only very rare
9 2015-04-02 01:27:30 <sipa> morcos: would it be infeasible to do pruning from within FlushStateToDisk?
10 2015-04-02 01:27:35 <morcos> well thats what i wanted to get a sense from you on.. it didn't seem dangerous to flush pcoinstip while you were modifying a child cache, but i wasn't sure if i was reasoning about the caches properly
11 2015-04-02 01:28:04 <sipa> i think it can be made safe, but it's tricky
12 2015-04-02 01:28:12 <morcos> Well we were calling FlushStateToDisk is the problem
13 2015-04-02 01:28:24 <sipa> right, i mean, from the current call sites
14 2015-04-02 01:28:50 <sipa> it's more of an architectural concern
15 2015-04-02 01:29:00 <morcos> but thats not where disk space is allocated
16 2015-04-02 01:29:24 <sipa> why does pruning need flushing, actually?
17 2015-04-02 01:30:05 <morcos> practically speaking we could lose the pruning check when allocating undo chunks, b/c they are small anyway, and just doing it inside the allocation of the block chunks seems safer..
18 2015-04-02 01:30:49 <morcos> well we've now updated significant database state on what blocks have_data and the vinfo_files and seemed like we should keep that in lockstep with what exists on disk
19 2015-04-02 01:31:02 <sipa> fair enough
20 2015-04-02 01:32:31 <morcos> i have this perhaps irrational desire to make the pruning code really respect the target more like a limit, hence my desire to build a big enough buffer than the 288 requirement will be very unlikely to cause you to pass the target, and also wanting to make sure that modulo that you never pass the target even temporarily
21 2015-04-02 01:32:51 <morcos> its kind of usless now when there are many other uses of disk space
22 2015-04-02 01:33:15 <morcos> but in the future, i think it might be nice if all the targets were fairly firm so you really knew whether you had enough disk space or not
23 2015-04-02 01:34:42 <morcos> did you take a look at the code change i proposed, do you think its not safe? i couldn't quite put my finger on any danger
24 2015-04-02 01:35:01 <sipa> morcos: i'd need to think through the actual inconsistency
25 2015-04-02 01:37:27 <morcos> yeah i think it would be good whatever we decide on this, to clarify/comment when it is and is not safe to flush state to disk...
26 2015-04-02 01:52:33 <morcos> yeah maybe it would be cleaner to check for autopruning inside FlushStateToDisk, and just add an extra call to that inside FindBlockPos. FindBlockPos is called by a bunch of different things, and it'll be a little bit tricky to track when it might call FSTD, but better than we have it now. And I could just suck it up on not pruning exactly when we're allocating new undo space, since we call FSTD right after that anyway..
27 2015-04-02 01:55:07 <morcos> but regardless of whether we do that or not, let me know what you think about my proposed change, i think i'd still vote for it, even if we don't intentionally flush intermediate state, i don't know why we should make it possibly assert fail if we do. it seems risky someone could introduce it again like we did in autoprune, but it would only assert fail very rarely and not get caught (only got caught here thanks to Rusty)
28 2015-04-02 01:55:32 <sipa> well if we can reduce the assumptions without impacting performance, absolutely
29 2015-04-02 01:57:03 <morcos> yeah, i rewrote that thing 15 different ways trying to keep performance. i think you only potentially lose out if something was intermediate flushed
30 2015-04-02 01:57:35 <sipa> sure
31 2015-04-02 01:57:49 <sipa> i mean if we assume that doesn't happen
32 2015-04-02 01:58:06 <sipa> the code you wrote may even be slightly faster; checking for the fresh flag is faster than IsPruned
33 2015-04-02 01:58:44 <sipa> a unit test would be nice
34 2015-04-02 02:00:39 <morcos> testing exactly what? you already have a very nice unit test that showed me i did it wrong the first few times, oh.. ok so i could add some intermediate flushes to that, is that what you meant?
35 2015-04-02 02:00:55 <sipa> yes
36 2015-04-02 02:01:29 <sipa> if we explicitly want to support intermediate flushes (even without using them right now), i think we should have a test for them
37 2015-04-02 02:03:04 <morcos> ok great, well let me play around with that a little, and if i still think it looks good, then i'll submit a PR and we can all debate the pros/cons
38 2015-04-02 02:04:36 <morcos> in the meantime, i think i'll skip the intermediate flushes in autoprune so its not being held up
39 2015-04-02 02:04:56 <morcos> we were going to rebase shortly, should we still keep the library of commits (so they are basically the same) or would it be helpful to squash the old stuff at least
40 2015-04-02 02:05:17 <sipa> feel free to squash, i think
41 2015-04-02 02:06:03 <morcos> ok, thanks for taking a look.
42 2015-04-02 03:21:19 <gmaxwell> sipa: bitcoind: txmempool.cpp:485: void CTxMemPool::removeCoinbaseSpends(const CCoinsViewCache*, unsigned int): Assertion `coins' failed.
43 2015-04-02 03:22:35 <gmaxwell> well I suppose I should bug matt too, BlueMatt ^
44 2015-04-02 03:26:04 <dcousens> How does an SPV client prove that a transaction is in a block? It would need the relevant leafs in the merkle tree right?
45 2015-04-02 03:26:21 <gmaxwell> dcousens: yes.
46 2015-04-02 03:27:33 <dcousens> gmaxwell: does the protocol currently give that merkle tree back? Or does the SPV client currently just download the merkle trees for blocks which it has been told it has transactions within?
47 2015-04-02 03:27:52 <dcousens> just download all the transactions for blocks which...*
48 2015-04-02 03:28:10 <gmaxwell> no, filtered blocks give the tree fragments.
49 2015-04-02 03:28:15 <phantomcircuit> the protocol supports transmitting partial merkle trees
50 2015-04-02 03:28:48 <dcousens> ok cool, cheers :)
51 2015-04-02 03:32:47 <chronos> What are yall opinions of bintcoin.info's api for developing -- let's say reporting software
52 2015-04-02 03:33:10 <chronos> Just looking for general pros/cons based on your guys' expierence
53 2015-04-02 03:33:21 <phantomcircuit> i would say i have no idea what that is
54 2015-04-02 03:33:29 <chronos> lol
55 2015-04-02 03:33:40 <gmaxwell> Never heard of it.
56 2015-04-02 03:33:43 <gmaxwell> BlueMatt: I don't see how that assertion failure is possible.
57 2015-04-02 03:39:29 <chronos> Really? hmm thought bitcoin.info was well known
58 2015-04-02 03:40:28 <phantomcircuit> chronos, now you're just spamming
59 2015-04-02 03:40:44 <chronos> Err..what?
60 2015-04-02 03:41:04 <chronos> oh cus i said the name twice - only cus i mispelled it first
61 2015-04-02 03:41:52 <phantomcircuit> gmaxwell, removing things during a reorg that way seems like a bad idea
62 2015-04-02 03:42:17 <chronos> I am an idiot.. sorry. i meant blockchain.info
63 2015-04-02 03:42:21 <phantomcircuit> instead copy the transactions somewhere else and then attempt to add them new to the mempool after the reorg
64 2015-04-02 03:42:46 <phantomcircuit> chronos, you mean that which shall not be named
65 2015-04-02 03:43:26 <chronos> Lol well that answers my question
66 2015-04-02 03:44:29 <chronos> not favorable i take it
67 2015-04-02 03:46:12 <gmaxwell> chronos: better question for #bitcoin
68 2015-04-02 03:47:00 <chronos> I reason i ask is because i need a .net implementation.. thats the only one that anyone has reccomended
69 2015-04-02 03:51:24 <phantomcircuit> gmaxwell, the logic in removeCoinbaseSpends looks pretty wrong to me at first glance
70 2015-04-02 03:51:52 <phantomcircuit> assuming mapTx is a map of transactions in the mempool
71 2015-04-02 03:52:16 <phantomcircuit> this would never remove a coinbase since they'd never be in the mempool
72 2015-04-02 03:52:54 <gmaxwell> phantomcircuit: I don't see what you say that? basically it traverses all tx remaining in the mempool and checks their inputs, if any _of the inputs_ are a now-immature coinbase it flags the transaction for removal (and removal of its children).
73 2015-04-02 03:52:58 <phantomcircuit> but maybe im just hungry...
74 2015-04-02 03:53:33 <gmaxwell> its the inputs being tested for coinbaseness, not the transactions in the mempool themselves.
75 2015-04-02 03:54:04 <Luke-Jr> chronos: frankly, blockchain.info is so misinformative and broken that it's a stretch to even call it bitcoin-related; it isn't at all bitcoin development related, so please take it to #bitcoin or somewhere else
76 2015-04-02 03:54:24 <chronos> Thats what i wanted to know
77 2015-04-02 03:54:28 <phantomcircuit> gmaxwell, yes nevermind
78 2015-04-02 03:55:07 <chronos> Thank you
79 2015-04-02 03:55:08 <phantomcircuit> ACTION goes to find food
80 2015-04-02 04:02:35 <StephenM347> Has anyone gone over the bitcoin lightning network proposal? It seems to me that each hashed time lock contract requires funding it with a real bitcoin transaction, as that is how one can guarantee that producing R will reward the result, but I thought the whole point was to be able to use existing micropayment channels.
81 2015-04-02 04:02:39 <StephenM347> What am I missing?
82 2015-04-02 04:09:14 <Luke-Jr> StephenM347: pretty sure it's an *alternative* to "existing" micropayment channels (which afaik only "exist" in theory)
83 2015-04-02 04:10:41 <StephenM347> Luke-Jr: As I think about it more, I think the contract is used as a scriptPubKey in the latest update of the payment channel.
84 2015-04-02 04:11:02 <fanquake1> Did someone post a link to a new version of the paper in channel last night? On the site the latest update is Feb 28
85 2015-04-02 04:46:16 <StephenM347> In the bitcoin lightning network proposal, what if Alice wants to send funds to Carol through Bob but B&C's channel is new and Carol is the only one who has funded? i.e. the channel cannot pay Carol any more than she is already being paid
86 2015-04-02 05:36:17 <Taek> StephenM347: Try these http://rusty.ozlabs.org/?p=450 http://rusty.ozlabs.org/?p=462
87 2015-04-02 05:39:48 <StephenM347> Taek: I'll check em out, thanks for the links
88 2015-04-02 06:32:26 <phantomcircuit> gmaxwell, you can spend a coinbase with a transaction in the same block
89 2015-04-02 06:32:34 <phantomcircuit> so technically that assert is wrong
90 2015-04-02 06:32:47 <phantomcircuit> but i'd be pretty surprised if that's what happened
91 2015-04-02 06:33:03 <phantomcircuit> oh no you cant
92 2015-04-02 06:33:06 <phantomcircuit> im retarded
93 2015-04-02 06:33:07 <phantomcircuit> derp
94 2015-04-02 06:33:13 <phantomcircuit> ACTION goes back to looking
95 2015-04-02 07:36:03 <phantomcircuit> gmaxwell, removeCoinbaseSpends takes pcoinsTip but DisconnectBlock takes the view
96 2015-04-02 07:36:21 <phantomcircuit> so im thinking removeCoinbaseSpends has a different view of things or something weird
97 2015-04-02 07:50:26 <phantomcircuit> why does CCoins::Cleanup only remove spent ouputs at the end of vout?
98 2015-04-02 07:51:25 <phantomcircuit> sipa, ima find you and ask annoying questions
99 2015-04-02 08:06:19 <phantomcircuit> gmaxwell, yeah i think that's it, the pcoinsTip CCoinsCachedView that gets passed to removeCoinbaseSpends isn't the same as the one passed to DisconnectBlock
100 2015-04-02 09:26:40 <bitnumus> Hi all, could i just ask if i'm going mad or not. Didn't -qt used to ask for wallet encryption pass before generating new addresses?
101 2015-04-02 09:28:08 <Jouke> no, it will pick one out of the keypool which gets replenished the moment you unlock your wallet.
102 2015-04-02 09:28:10 <b_lumenkraft> never for me
103 2015-04-02 09:28:47 <bitnumus> Jouke, so on the 100th key it'll ask for password ?
104 2015-04-02 09:29:00 <bitnumus> I was so sure it used to do it for every key
105 2015-04-02 09:29:22 <Jouke> I'm not sure what happens then. It might pick an old key?
106 2015-04-02 09:29:25 <wumpus> if your keypoolsize is 100, then yes, it will ask for the 100th
107 2015-04-02 09:29:39 <bitnumus> wumpus, hi, did it used to ask for every key ?
108 2015-04-02 09:29:43 <wumpus> (it's really a keyqueue, not a keypool)
109 2015-04-02 09:30:00 <wumpus> bitnumus: I don't remember, maybe a long time ago
110 2015-04-02 09:30:16 <wumpus> Jouke: no, it will never give an old key
111 2015-04-02 09:30:21 <Jouke> keyqueue :) /me is going to use that in future reference :)
112 2015-04-02 09:30:23 <bitnumus> yea like a few years maybe, though i thought it did before the latest GUI changes with QR codes and such
113 2015-04-02 09:30:53 <wumpus> latest? QR codes were added years ago
114 2015-04-02 09:31:00 <bitnumus> wumpus, any idea if adding number in keyqueue to GUI is in a feature tracker anywhere?
115 2015-04-02 09:31:06 <bitnumus> because that would be kind of useful for backup purposes
116 2015-04-02 09:31:20 <bitnumus> ergh, its been a while :P time flies
117 2015-04-02 09:31:57 <wumpus> bitnumus: well there has been a pull at some point that made re-generating the keypool a manual action, I think that would have been great for backup purposes, but there wasn't really agreement
118 2015-04-02 09:32:38 <bitnumus> Hmm, it would just be nice to know where the wallet was in terms of keypool
119 2015-04-02 09:32:40 <wumpus> *added an option to make generating the keypool a manual action
120 2015-04-02 09:32:47 <bitnumus> even an overall stat for this
121 2015-04-02 09:33:04 <bitnumus> is that available via API/console or whatever?
122 2015-04-02 09:33:26 <wumpus> I don't think so, but I also don't think it would be very useful, as it provides no hard guarantees
123 2015-04-02 09:33:39 <wumpus> remember, every time you send a transaction the keypool will be refilled
124 2015-04-02 09:33:50 <wumpus> (or unlock for any other reason)
125 2015-04-02 09:34:00 <wumpus> so for backup purposes that wouuld be... meh
126 2015-04-02 09:34:10 <bitnumus> keypool would be refilled randomly? huh?
127 2015-04-02 09:34:18 <wumpus> no, not randomly
128 2015-04-02 09:34:22 <wumpus> just every time it is possible
129 2015-04-02 09:34:43 <bitnumus> its possible that more keys would be added to the pool if there are only 60 used keys out of the 100 ?
130 2015-04-02 09:34:52 <wumpus> for an unlocked wallet that's always, for a locked wallet that's when it is unlocked
131 2015-04-02 09:35:09 <wumpus> it will fill up until 100
132 2015-04-02 09:35:44 <bitnumus> Yea so if there was a counter in the GUI or elsewhere that said 80/100 or something you would not be making backups for the sake of it
133 2015-04-02 09:36:05 <wumpus> but it will normally never get that low
134 2015-04-02 09:36:06 <bitnumus> i've probably made 100 backups and likely only needed one :D
135 2015-04-02 09:36:26 <bitnumus> ah i see, so its not the 100th then, its somewhere in the middle, which seems kind of random'ish
136 2015-04-02 09:36:27 <wumpus> hence "there has been a pull at some point that made re-generating the keypool a manual action" ... that would have made such a counter useful
137 2015-04-02 09:37:15 <wumpus> no, again, it is not somewhere in the middle, it is not random, it will refill the keypool up to the keypool size *automatically* every chance it get
138 2015-04-02 09:37:55 <bitnumus> wow, so it'll keep a pool of 100 unused, but this doesn't effect the "queue" ?
139 2015-04-02 09:38:07 <wumpus> I rest my case
140 2015-04-02 09:38:15 <bitnumus> damn
141 2015-04-02 09:38:40 <bitnumus> ACTION will continue to take many many backups
142 2015-04-02 09:38:46 <wumpus> what I usually do is set an extremely large keysize, more than I will ever do transactions
143 2015-04-02 09:38:52 <wumpus> s/keysize/keypoolsize/
144 2015-04-02 09:40:03 <bitnumus> wumpus, thanks for the info, need to run
145 2015-04-02 09:40:48 <wumpus> btw, keypoolsize is available in 'getwalletinfo', as well as the date of the oldest key in the keypool
146 2015-04-02 10:20:30 <Priidu> when referring to a transaction that was included in an alternate chain that is not a part of the main chain, what would be the proper terminology to use?
147 2015-04-02 10:21:01 <Priidu> "orphaned" is probably not right, as it refers to something else in Bitcoin Core (a transaction whose parent has not yet been received)
148 2015-04-02 10:21:21 <Priidu> but wondering if "extinct" or "detached" would be better
149 2015-04-02 10:22:19 <Priidu> any opinions?
150 2015-04-02 10:29:43 <wumpus> blocks that are not part of the most-pow chain are usually referred to as 'stale'
151 2015-04-02 10:33:21 <Priidu> oh yeah - that one too lol
152 2015-04-02 10:33:34 <Priidu> 'stale' is fine, I guess
153 2015-04-02 10:45:33 <wumpus> yes, although you'd usually not call transactions 'stale' because they go back into the mempool and likely will be mined again later
154 2015-04-02 10:46:14 <wumpus> but the blocks they were in, can be
155 2015-04-02 10:55:19 <Priidu> yes, but well
156 2015-04-02 10:55:38 <Priidu> it's for a sort of history feature
157 2015-04-02 10:58:02 <Priidu> i.e. the transaction is archived in a database and when a daemon can't see it anymore via bitcoind, the status of that particular record should be set to 'stale'
158 2015-04-02 10:59:17 <Priidu> and a new record would be generated for the newly included transaction
159 2015-04-02 10:59:55 <Priidu> "can't see it anymore" as in the blockheight/blockhash first reported doesn't match anymore
160 2015-04-02 11:06:03 <wumpus> right
161 2015-04-02 14:20:38 <ISI_S> ÙÙ
Ùع اÙأزÙ
ات ÙاÙسÙاÙ
Ø© ÙعÙ٠أÙضا Ø£Ù ÙتشاÙر ÙائÙ
Ø© اÙÙات٠اÙخاصة بÙا. اÙØ°ÙÙ ÙÙ
Ù٠أ٠أتصÙر عطÙØ© Ø·ÙÙÙØ© Ù
ع Ø®ÙÙ
Ø© Ø£Ù ÙØ§Ø±Ø¨Ø Ù
Ù Ù٠اØÙ
٠اÙØ£ÙاÙÙØ© ÙÙتطÙع دائÙ
ا Ø¥Ù٠إÙÙاء اÙÙÙÙ
عÙ٠اÙآخرÙÙØ Ù
Ù ÙÙ Ù
ÙÙÙب ÙÙÙا ÙÙعÙØ´ Ù٠اÙÙ
ÙØ·ÙØ©Ø
162 2015-04-02 14:20:40 <ISI_S> اÙØ°Ù ÙعتÙ
د باÙضرÙرة عÙÙ Ù
ساعدة خارجÙØ©Ø Ø§ÙØ°ÙÙ ÙÙ
ÙتÙدÙ
Ùا ÙÙترة Ø·ÙÙÙØ©Ø Ø§Ùذ٠عÙ٠سÙبا ع٠اÙاستعداد ÙØاÙات اÙØ·ÙØ§Ø±Ø¦Ø Ø£ÙÙئ٠اÙØ°ÙÙ ÙعتÙدÙÙ 100Ùª Ù
Ù ARD Ùشرات اÙأخبار اÙÙ
سائÙØ©Ø - ÙÙÙذا Ù
Ø«Ù ÙÙÙÙØ© Ùضع Ù
عا ÙائÙ
Ø© دعÙØ© خاصة Ø¬Ø¯Ø§Ø ÙÙÙÙ ÙÙØ· ÙÙأزÙ
Ø©. إذا زÙ
Ù٠رج٠غÙر
163 2015-04-02 14:20:42 <ISI_S> سارة بصÙØ© خاصة ÙعÙÙ
ÙØ«ÙØ±Ø§Ø ÙÙÙ
ÙÙÙ Ù
عرÙØ© Ø£Ù ÙدÙ٠باع EM ÙÙترة Ø·ÙÙÙØ©Ø ÙاÙأسÙÙ
ÙÙÙا usw.usf Ù
دÙÙ .. - ÙÙÙÙ ÙÙØ· ÙÙ
ا Ùد ÙتصÙر اÙÙ
Ø±Ø¡Ø ANONYMOUS ÙاØدة جدÙرة باÙØÙ
اÙØ©Ø ÙÙÙ٠اÙشخص ثرثارة ÙÙÙ
ساعدة Ù
Ù ÙبÙØ Ø¹Ù٠سبÙ٠اÙÙ
ثاÙØ Ø¯Ù٠رÙÙ٠بعض اÙطعاÙ
Ùتر٠عÙد اÙباب.
164 2015-04-02 14:20:44 <ISI_S> ÙباÙتاÙÙØ Ø³ÙتÙ
اÙÙاذ Ùذا اÙØ´Ø®ØµØ Ù(Ù
ع ÙÙج Ù
اÙرا
165 2015-04-02 14:20:46 <ISI_S> !!) Ø£Ùت Ùست Ù٠خطر Ø£ÙÙسÙÙ
. إذا Ùا٠Ùذا Ù٠أÙضا ÙاÙعÙØ© ÙتÙÙÙØ° ÙÙ ÙÙت ÙاØÙØ ÙÙØ°Ù Ù
سأÙØ© أخرÙ. أر٠أ٠Ùذا Ùجزء Ù
٠اÙاستعداد ÙÙ
ÙاجÙØ© اÙأزÙ
ات اÙÙÙسÙØ©.
166 2015-04-02 14:20:47 <gribble> Error: "!)" is not a valid command.
167 2015-04-02 17:54:19 <gmaxwell> sdaftuar: hm. So what we're trying to accomplish with not using inbound peers is multifolded. But probably the main one is that we're trying to preserve the ability for someone who is listen=0 to not have their bandwidth get hugely spiked by someone IBDing off of them.
168 2015-04-02 17:55:26 <gmaxwell> On people with common consumer broadband that has screwed up bufferbloat someone IBDing off you can result in +1 second RTTs to the internet, which makes their internet connection basically useless. Ultimatelly this should be fixed by some kind of brillant rate limiting.
169 2015-04-02 17:55:50 <gmaxwell> oh! I read the logic of your patch backwards!
170 2015-04-02 17:56:10 <gmaxwell> I thought you were allowing it prior to 288 rather than after 288 ago. Well nevermind then, thats probably fine.
171 2015-04-02 17:57:54 <gmaxwell> for posterity, I think the other major reason we should de-prefer inbound is that inbound peers are self-selecting; and thus more likely to be malicious (e.g. trying to cause delays for us by tarpitting or other annoying behavior).
172 2015-04-02 18:04:48 <sdaftuar> gmaxwell: yep makes sense. do you think it's problematic to have them share in serving the last 288? now that we have the block download timeouts, the damage is limited, but still not nothing
173 2015-04-02 18:07:13 <gmaxwell> I think the biggest risk is that they tarpit our tip-- e.g. they INV a new block to you but never send it and make you suffer the timeout--, but nothing about your change influences that.
174 2015-04-02 18:07:46 <sdaftuar> yep ok
175 2015-04-02 18:07:57 <morcos> gmaxwell: were you testing something in particular that caused that assert to fail in removecoinbasespends. that failed for me recently, but i think it was related to gavins new reorg code (or maybe the reorg code i was trying to write)
176 2015-04-02 18:09:19 <gmaxwell> morcos: no, this is an ordinary node running on the public network (the one my miners/p2pool runs off); the only thing special about it is that it has the check flags turned up.
177 2015-04-02 18:09:41 <gmaxwell> I actually hit another assert today in the new mempool consistency code; on a reorg. Looks like it hit an actual mempool inconsistency.
178 2015-04-02 18:10:45 <morcos> yeah the mempool consistency checks were sorely needed
179 2015-04-02 18:11:25 <gmaxwell> (the trigger behavior is that there were two blocks at height X: X and X' both had transaction A and I was on X, then X'+1 overtook, and during the reorg it bombed out the consistency check on checking the existance of the inputs for transaction B which spent A.
180 2015-04-02 18:11:39 <gmaxwell> unfortunately, my binary is optimized and gdb is mostly useless on it.
181 2015-04-02 18:11:55 <gmaxwell> (and even if GDB was, I likely can't tell how it became inconsistent)
182 2015-04-02 18:12:25 <gmaxwell> My guess is that B was in the mempool before the reorg, and that it hadn't made it as far as reconnecting X' after disconnecting X.
183 2015-04-02 18:12:43 <morcos> oh, so this could be the fix that gavin just PR'ed
184 2015-04-02 18:12:53 <morcos> was A non-standard
185 2015-04-02 18:13:36 <morcos> oh, but it was in X' never mind
186 2015-04-02 18:14:37 <gmaxwell> yea, A is in both X and X' B is in X'+1 I am not sure it was in my mempool before the reorg but if it wasn't it shouldn't have been hit in the consistency check so I assume it was.
187 2015-04-02 18:14:51 <morcos> and i'm confusing myself, whats the new mempool consistency code? i was thinking of sipas block index consistency
188 2015-04-02 18:15:04 <gmaxwell> TXID was 1032af3dc4d4574880091403b930e4921f3319cd8637b436be5f82b9e150c888
189 2015-04-02 18:15:39 <gmaxwell> hm. I thought sipa added some mempool checks too. In any case, I was running both mempool and blockindex consistency on that node. The actual assert it hit was (which may be old)
190 2015-04-02 18:16:07 <gmaxwell> I've had this node on 0.10.branch for a while but only turned up the checks because of sipa's latest changes.
191 2015-04-02 18:16:10 <gmaxwell> txmempool.cpp:576: void CTxMemPool::check(const CCoinsViewCache*) const: Assertion `coins && coins->IsAvailable(txin.prevout.n)' failed.
192 2015-04-02 18:16:19 <morcos> ok, so yeah i think that might do it
193 2015-04-02 18:16:31 <gmaxwell> ACTION looks
194 2015-04-02 18:16:58 <morcos> haven't looked yet, but if A is non-standard, then when you run mempool.check() before you've added X', you'll find B in your mempool but no A
195 2015-04-02 18:17:10 <morcos> because it would have failed to be readded when X was disconnected
196 2015-04-02 18:17:25 <morcos> 5945 would fix that if thats it
197 2015-04-02 18:17:31 <gmaxwell> oh indeed, that sure does look like it could be it.
198 2015-04-02 18:18:19 <morcos> funny i ran over the whole block chain and all the reorgs i've seen Jan - Marc and that didn'thappen once
199 2015-04-02 18:18:49 <gmaxwell> I may be more exposed because that node has a cranked up set of limits.
200 2015-04-02 18:19:18 <gmaxwell> so its much more likely to find something thats in a block non-standard.
201 2015-04-02 18:20:12 <morcos> ? what kind of limits
202 2015-04-02 18:28:53 <gmaxwell> morcos: min relay fee at about 10x the current defaults.
203 2015-04-02 18:29:21 <gmaxwell> I keep having a problem where I think PRs have been merged when they haven't been. :-/ I wish github had some facilities for personal tags.
204 2015-04-02 18:30:17 <kanzure> gmaxwell: personally i use https://github.com/davidlazar/jotmuch
205 2015-04-02 18:30:53 <morcos> ugh, that guy never got back to wumpus, i'm trying to get us a good set of contacts at GitHub so we can maybe get them to do some of these things
206 2015-04-02 18:31:37 <gmaxwell> github has changed a few minor things for us in the past, I think. (well, may be a coincidence that they fixed stuff we were complaining about)
207 2015-04-02 18:33:14 <gmaxwell> I would have nagged about that for 0.10rc if I realized it hadn't gone in.
208 2015-04-02 18:35:09 <morcos> yeah, you're right, we should have thought to tag that .10
209 2015-04-02 18:36:08 <gmaxwell> hm. so I appear to have relayed 1032af3dc4d4574880091403b930e4921f3319cd8637b436be5f82b9e150c888 so I think it wasn't non-standard.
210 2015-04-02 18:40:51 <morcos> could it be you relayed it the first time you saw it but the second time it triggered your free rate limiter
211 2015-04-02 18:42:03 <morcos> seems like it would be too low priority for free relay..
212 2015-04-02 18:42:17 <gmaxwell> good question. lets see. hm. well no logging about the limiter about then.
213 2015-04-02 18:42:23 <gmaxwell> I'm not sure why I relayed it.
214 2015-04-02 18:42:38 <gmaxwell> but I see in my logs that other peers were getdataing it from me, so I must have relayed it.
215 2015-04-02 18:45:59 <gmaxwell> morcos: dunno, priority on that one wasn't insanely low. keep in mind that the signature size there would be ignored for the priority calculation.
216 2015-04-02 18:47:35 <jgarzik> gmaxwell, vaguely related: I always wanted a dry-run mode for sendrawtransaction, to see what happens if I attempted to submit or relay TX'A... but not actually relay it onto the live network
217 2015-04-02 18:47:47 <jgarzik> i.e. test local engine results
218 2015-04-02 18:47:50 <morcos> thought priority had to be 1BTC for 1day or am i remembering wrong, and that was .008 BTC for 1 day
219 2015-04-02 18:48:20 <sipa> 1 BTC for 1 day per 250 bytes
220 2015-04-02 18:48:37 <morcos> yeah, i mean it wasn't that small a tx!
221 2015-04-02 18:52:37 <gmaxwell> morcos: it's 226 bytes, and the size is post adjustment-- it uses the adjusted size which reduces every signature by up to 151 bytes.
222 2015-04-02 18:52:58 <gmaxwell> I have to say, the split of code into lots of subdirectories has made it much harder to find things with grep.
223 2015-04-02 18:53:16 <gmaxwell> morcos: see CTransaction::CalculateModifiedSize in primitives/transaction.cpp
224 2015-04-02 18:56:25 <morcos> yeah, but thats my point. .008 BTC x 1 day / (75 bytes) < 1BTC x 1 day / (250 bytes)
225 2015-04-02 18:56:51 <morcos> thats what git grep is for
226 2015-04-02 18:59:57 <gmaxwell> oh git grep, never used that before. handy.
227 2015-04-02 19:04:12 <gmaxwell> morcos: for that one, it had 104 confirms, value of 0.008 and a modified size of 75. thats a priority of 1109333 the threshold is 57600000. so, indeed. I have no clue why I would have accepted that.
228 2015-04-02 19:13:00 <michagogo> Were there any notable AFD jokes here?
229 2015-04-02 19:13:21 <sipa> not afaik
230 2015-04-02 19:19:01 <gmaxwell> bingo
231 2015-04-02 19:19:06 <gmaxwell> morcos: got it!
232 2015-04-02 19:19:13 <gmaxwell> morcos: I recieved the transaction from a whitelisted peer.
233 2015-04-02 19:19:59 <gmaxwell> kind of obnoxious, I really don't want the always relay behavior for the relay node client.
234 2015-04-02 19:34:39 <iiLezso> Is anyone online?
235 2015-04-02 19:34:48 <iiLezso> I need some advice on where to start
236 2015-04-02 19:39:05 <sipa> sorry, everyone is offline
237 2015-04-02 19:42:33 <jonasschnelli> ;)
238 2015-04-02 19:46:24 <gmaxwell> jonasschnelli: re #5503 super-NAK on 'correctfee', :) Even correctfee is not actually correct. Consider, you author some transaction the slow-as-shit measurment based thing says your fee was too low. So you update the txn, now you sign again.. OOPs now your fee is too high because the signatures turned out smaller this time around. "oh well".
239 2015-04-02 19:47:03 <jonasschnelli> gmaxwell, Yes. Indeed.
240 2015-04-02 19:47:26 <jonasschnelli> i did focus to much of comparison between fees from sendtoaddress and fundrawtx.
241 2015-04-02 19:47:51 <gmaxwell> jonasschnelli: meanwhile, probablity of each n bytes less is something like (1/256)^n. So even if you have 100 inputs, it's not going to make a meaningful difference.
242 2015-04-02 19:48:02 <jonasschnelli> gmaxwell, just figured out that there can be fee deltas >10 sat. if you have multiple inputs...
243 2015-04-02 19:49:07 <gmaxwell> yea, so differences about $0.00003 at current bitcoin prices. :)
244 2015-04-02 19:49:34 <gmaxwell> we lose more to dust-roundown for change. :)
245 2015-04-02 19:50:05 <jonasschnelli> Agreed. I just want to be sure to avoid later complains. :)
246 2015-04-02 19:51:30 <gmaxwell> jonasschnelli: we should eliminate all the signing loop code; its hugely slow. results in having to keep private keys in memory longer than needed, etc. Anyone complaining about approximations in fee calculation at the nano-btc scale should probably be shot; they're spending more than that in wasted energy redoing the signing multiple times. :P
247 2015-04-02 19:52:46 <jonasschnelli> yes. I think the dummy signing in sign.cpp (https://github.com/bitcoin/bitcoin/pull/5503/files) could help here.
248 2015-04-02 19:53:03 <jonasschnelli> The coin-selection-looping-fee-calculation should def. be changed once.
249 2015-04-02 20:56:52 <morcos> gmaxwell: ahh!
250 2015-04-02 22:04:13 <terrantpants> What exactly is the coinbase timestamp?
251 2015-04-02 22:08:08 <gmaxwell> terrantpants: huh? those words are meaningless to me.
252 2015-04-02 22:10:02 <sipa> block timestamp of a coinbase transaction
253 2015-04-02 22:11:05 <sipa> ?
254 2015-04-02 22:17:35 <terrantpants> I was looking at the function that checks for valid blocks to better understand what is going on
255 2015-04-02 22:17:47 <terrantpants> and there is a check for a coinbase timestamp being too early
256 2015-04-02 22:17:51 <terrantpants> how is that even possible?
257 2015-04-02 22:18:02 <terrantpants> or better question why is checked?
258 2015-04-02 22:18:07 <terrantpants> just a sanity check?
259 2015-04-02 22:20:13 <gmaxwell> terrantpants: the string 'coinbase time' doesn't exist in the codebase; can you point out more specifically what you're talking about?
260 2015-04-02 22:20:28 <terrantpants> coinbase timestamp
261 2015-04-02 22:20:42 <terrantpants> ill find the line of code
262 2015-04-02 22:21:42 <terrantpants> 2557
263 2015-04-02 22:21:52 <terrantpants> to 2560
264 2015-04-02 22:22:25 <terrantpants> So its checking to make sure the block didnt get created before the last block? I know I have seen blocks on blockchain.info
265 2015-04-02 22:22:30 <terrantpants> that have timestamps out of order
266 2015-04-02 22:23:12 <terrantpants> oh of main.cpp