1 2015-11-04 00:00:28 <jtimon> otherwise you can't handle reorgs
  2 2015-11-04 00:03:58 <jtimon> https://github.com/bitcoin/bitcoin/pull/6816/files#r42987352
  3 2015-11-04 00:08:01 <jtimon> rusty:  I see, so then you don't need to pass a versionBitsState struct to UseRule/IsValid, from the point of view of the C++ libconsensus API, it's always like if you were calculating it from genesis and Consenus::Params and CBlockIndex* should be enough
  4 2015-11-04 00:08:34 <rusty> jtimon: yeah, internal caching does give a neater API
  5 2015-11-04 00:08:58 <jtimon> agreed
  6 2015-11-04 00:11:04 <jtimon> so we have our API, no? bool Consensus::UseRule(int rule, const Consensus::Params& consensusParams, const CBlockIndex& blockIndex)
  7 2015-11-04 00:11:20 <rusty> jtimon: no.  int rule is a terrible idea :)
  8 2015-11-04 00:11:55 <jtimon> how do you access the appropriate element in the array contained in consensusParams otherwise?
  9 2015-11-04 00:12:10 <rusty> jtimon: bool Consensus::IsActive(const BIP &BIP, ...)
 10 2015-11-04 00:12:16 <jtimon> you need that to access the bit of the bip and the expiry
 11 2015-11-04 00:12:55 <jtimon> but const BIP &BIP is just consensusParams.vDeployments[rule]
 12 2015-11-04 00:13:09 <jtimon> you already have it in consensusParams
 13 2015-11-04 00:14:08 <jtimon> imagine you have to expose UseRule as a C API, then passing the BIP class is the terrible idea
 14 2015-11-04 00:14:58 <jtimon> forget about CBlockIndex in that API because that's not going to be solved in the short term
 15 2015-11-04 00:17:05 <rusty> jtimon: -ETIMEDOUT.  I've wasted too much time.  You go with whatever API you want, and push it into bitcoin-core.  I've spent too long not working on lightning :(
 16 2015-11-04 00:17:17 <jtimon> in the CPP (in the implementation of UseRule) you can have a BIP class that extends from the struct Softfork and has a copy constructor from a Softfork and has all the methods you want BIP(consensusParams.vDeployments[rule])
 17 2015-11-04 00:17:38 <sipa> jtimon: no reason why any of this would be exposed as an API at all
 18 2015-11-04 00:17:49 <sipa> it's internal logic for implenenting block validity
 19 2015-11-04 00:17:51 <sipa> no?
 20 2015-11-04 00:18:21 <jtimon> well, yes, it would be VerifyBlock
 21 2015-11-04 00:19:21 <sipa> right
 22 2015-11-04 00:19:59 <sipa> well you'd have a validation flag per bit, i guess
 23 2015-11-04 00:20:04 <sipa> which you can pass in
 24 2015-11-04 00:20:08 <jtimon> yes, I guess then respecting Consensus::Params is enough and the BIP class and BIP99.IsValid is fine
 25 2015-11-04 00:20:39 <sipa> And the block logic uses the BIP object to determine whether the flag should be set or not
 26 2015-11-04 00:22:09 <jtimon> rusty: sorry, I allowed my C-preference for libconsensus to get in the way, after making VersionBitsBIPActivation a C-compatible struct in Consensus::Params and making the map and internal caching structure there's no interference with libconsensus' future C API
 27 2015-11-04 00:23:21 <jtimon> bool Consensus::IsActive(const BIP &BIP, const Consensus::Params& consensusParams, const CBlockIndex& blockIndex) is fine
 28 2015-11-04 00:24:20 <jtimon> and there's no need for CheckVersion or CalculateState
 29 2015-11-04 00:26:47 <jtimon> the int rule is only needed if you want to maintain a common UseRule that is also used for the old rules, but I'm fine with having a separate UseRuleOld
 30 2015-11-04 00:59:06 <dcousens> is there way to check what block a transaction is in via the RPC?
 31 2015-11-04 00:59:57 <dcousens> nvm
 32 2015-11-04 00:59:59 <dcousens> getrawtransaction
 33 2015-11-04 01:31:10 <arowser> The boot build fail when I try to cross compile bitcoin from MAC on ubuntu 14.04.3, error msg is "./boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found"
 34 2015-11-04 01:49:33 <Nickyo9> its not romur! bitcoin going to hit 1500$ due to this news!!! coindesk lie to us! http://www.nasdaqtoday.com/Overstock-has-confirmed-that-Nasdaq-is-using-blockchain
 35 2015-11-04 01:50:08 <rusty> Nickyo9: not here.  Leave please.
 36 2015-11-04 01:57:09 <mappum> is there a rough ETA for the proposed bips 65,68,112,113 soft fork? (or whichever of those are accepted)
 37 2015-11-04 01:57:36 <mappum> and will that soft fork be deployed as Bitcoin Core 0.12?
 38 2015-11-04 02:02:45 <rusty> jtimon: I've hacked up a versionbits variant which should be closer to consensus-ready.  Pushed, but untested.
 39 2015-11-04 02:04:50 <rusty> jtimon: now I'm *really* done :)
 40 2015-11-04 02:04:58 <aj> mappum: 65/cltv is supposed to be end of the month, in 0.11 and backported to 0.10. 68/112/csv were wanting more testing but could be "near term"; 113 needs to be an isStandard check first apparenlty
 41 2015-11-04 02:05:08 <aj> mappum: (based on the irc meeting logs)
 42 2015-11-04 02:06:53 <mappum> aj: thanks. how often/when are the irc meetings?
 43 2015-11-04 02:08:10 <aj> mappum: weekly, thursday 19:00 UTC -- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011147.html
 44 2015-11-04 02:08:45 <mappum> aj: cool, good to know. thanks for the info
 45 2015-11-04 02:35:01 <Nickyo9> OKCoin rising up due to the nasdaq news BITCOIN TO 1000$++++ http://www.nasdaqtoday.com
 46 2015-11-04 02:41:08 <Luke-Jr> !ops
 47 2015-11-04 02:44:57 <gmaxwell> thats malware.
 48 2015-11-04 02:45:20 <gmaxwell> Luke-Jr: midnightmagic please make sure you specifcally call out these links as malware too. Saves people from clicking.
 49 2015-11-04 02:46:56 <Luke-Jr> gmaxwell: I didn't even know :x
 50 2015-11-04 02:47:19 <rusty> gmaxwell: we need BIP62 for lightning, BTW.
 51 2015-11-04 02:48:51 <rusty> gmaxwell: aj pointed it out, we use one-sided anchor tx to a 2x2, with a pre-setup "all back to one party" 2x2 transaction.  If I malleate your anchor tx, I can hold your funds to ransom.
 52 2015-11-04 02:49:57 <rusty> gmaxwell, sipa: does this mean I need to add it to my TODO list to implement BIP62 and start pushing it?
 53 2015-11-04 02:50:09 <gmaxwell> if its 2 of 2 bip62 cannot prevent it from being malleated.
 54 2015-11-04 02:50:26 <gmaxwell> Because they can just resign.
 55 2015-11-04 02:51:11 <gmaxwell> I belief we shold flesh out luke-jr's idea for cleanly deploying segregated witness in bitcoin as a soft fork and see what that looks like.
 56 2015-11-04 02:51:43 <gmaxwell> As it's a complete fix, and not a bunch of pathing around and praying that we caught all the cases and haven't introduced others.
 57 2015-11-04 02:51:44 <aj> gmaxwell: can't only the second signer of a tx re-sign it?
 58 2015-11-04 02:52:09 <gmaxwell> aj: no, absolutely not. The signature doesn't cover signatures.
 59 2015-11-04 02:52:11 <rusty> gmaxwell: no, the initial tx is normal, just to a 2x2 output.
 60 2015-11-04 02:52:38 <rusty> gmaxwell: the 2x2 your given as a refund spends it.  If taht initial tx is malleated, the refund tx is useless.
 61 2015-11-04 02:53:06 <aj> gmaxwell: wow, crazy
 62 2015-11-04 02:53:36 <rusty> aj: yeah, it makes for interesting design problems with lightning, that's why we have only single-sided anchors for example.
 63 2015-11-04 02:53:38 <Luke-Jr> rusty: why BIP62 vs normalized txids, SW, and/or anti-malleability fix?
 64 2015-11-04 02:54:43 <rusty> Luke-Jr: timeline.  I know what #bitcoin-wizards is like, anything in discussion now is years away from deployment.  My LN design explicitly only relies on extant BIPs.
 65 2015-11-04 02:54:53 <gmaxwell> rusty: okay, then technically something BIP62 like may be enough IFF the initial coins are a plain p2pkh/p2pk/p2sh-multisig. Why is CLTV not used for the refund in that case, however?
 66 2015-11-04 02:55:28 <rusty> gmaxwell: because the anchor tx needs to go into the chain.  There's no good timeout value for CTLV.
 67 2015-11-04 02:55:30 <aj> gmaxwell: for singe-sided anchors, that's fine though, the dual-signed tx is the commitment, and we don't build on top of that until it's published in the blockchain
 68 2015-11-04 02:55:39 <gmaxwell> I think BIP62 is not closer than soft-fork seg witness. BIP62 did not move forward as was because of what a source of repeated problems and hairballing is.
 69 2015-11-04 02:55:57 <gmaxwell> rusty: you're going to author a refund, right, this refund has a locktime, no?
 70 2015-11-04 02:56:14 <IDoTrades> bitcoin going to hit 1500$ due to this news!!! coindesk lie to us! http://www.nasdaqtoday.com/Overstock-has-confirmed-that-Nasdaq-is-using-blockchain
 71 2015-11-04 02:56:16 <aj> gmaxwell: refund has a CSV delay
 72 2015-11-04 02:56:24 <rusty> gmaxwell: yes....
 73 2015-11-04 02:56:50 <gmaxwell> malware
 74 2015-11-04 02:56:51 <rusty> gmaxwell: no, refund doesn't ahve a locktime, sorry.
 75 2015-11-04 02:57:34 <rusty> gmaxwell: refund is the first commit tx.
 76 2015-11-04 02:58:19 <rusty> gmaxwell: there's no timeout on the anchor transaction.  Placing one there means a fight between limiting how long your refund is delayed and how long the channel can live.
 77 2015-11-04 02:58:45 <rusty> (the output of the commit tx is complicated, yes, but that's not relevant here)
 78 2015-11-04 03:01:17 <rusty> Since BIP62 is basically "don't do stupid shit", I disagree about readiness.  It may not be complete, but it's certainly better than now.
 79 2015-11-04 03:01:22 <gmaxwell> In any case, BIP62 was not deployed for a reason, and has been being deployed incrementally instead, at least the parts that made sense. It's a less than half solution at best (though perhaps a half thats useful to you here) and had repeated soundness failures.  And it was disruptive enough that it had to be opted into.
 80 2015-11-04 03:02:46 <rusty> gmaxwell: There's a fair argument that new tx restrictions should always be opted into, though.
 81 2015-11-04 03:03:22 <gmaxwell> Thats not the argument here; it really intrusively limits script behavior (which is also a risk to implementation correctness).
 82 2015-11-04 03:04:22 <aj> gmaxwell: intrusively == lots of details to verify for correctness? it doesn't actually make anything impossible or even harder does it?
 83 2015-11-04 03:04:35 <gmaxwell> and still leaves most things totally vulnerable; witness AJ's assu[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Danymption above.
 84 2015-11-04 03:05:01 <phantomcircuit> gmaxwell, wat
 85 2015-11-04 03:05:57 <gmaxwell> rusty: don't you need anti-malleability for the whole chain of transactions generally, including signers redoing their signatures?
 86 2015-11-04 03:06:44 <rusty> gmaxwell: no.  I never build a chain of txs; the original lightning paper had that issue.
 87 2015-11-04 03:06:46 <aj> gmaxwell: (in my defense it wasn't an assumption; i couldn't figure out the answer from the docs or code last time i looked, so took the opportunity to get an expert answer ;)
 88 2015-11-04 03:09:04 <rusty> gmaxwell: SW is wonderful, but we won't see it in 2016.  I will work on BIP62 if nobody else does.
 89 2015-11-04 03:10:07 <phantomcircuit> rusty, you use CSV to switch the channel direction right?
 90 2015-11-04 03:10:17 <rusty> phantomcircuit: <sigh>  No.
 91 2015-11-04 03:10:34 <rusty> https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf
 92 2015-11-04 03:14:16 <phantomcircuit> rusty, horray something to read :)
 93 2015-11-04 03:14:22 <aj> phantomcircuit: (the channel is bidirectional natively; it doesn't switch directions)
 94 2015-11-04 03:14:37 <phantomcircuit> oh this is the double anchor design
 95 2015-11-04 03:17:10 <gmaxwell> I think we are more likely to see it in 2016 than BIP62.
 96 2015-11-04 03:18:02 <gmaxwell> aj: don't feel that I was being critical your assumption was not unreasonable-- it's the natural one, and one of the many problems of BIP62.
 97 2015-11-04 03:18:42 <aj> gmaxwell: i was just being defensive :)
 98 2015-11-04 03:18:48 <gmaxwell> That it really is no improvement except in certian narrow cases (which happen to be common).
 99 2015-11-04 03:19:20 <gmaxwell> rusty: please do not waste your time.
100 2015-11-04 03:19:50 <rusty> gmaxwell: what, implementing lightning?
101 2015-11-04 03:20:45 <gmaxwell> trying to rescue BIP62. It is more complex to implement than soft-fork seg witnees currently appears to be, and it is necessarily incomplete, and difficult to prove sound (and kept having soundness errors over its life).
102 2015-11-04 03:47:25 <dcousens> gmaxwell: wont SW cause disruptive changes?
103 2015-11-04 03:47:48 <dcousens> Like major ones
104 2015-11-04 03:47:50 <dcousens> Structurally?
105 2015-11-04 03:49:38 <gmaxwell> dcousens: Can you make your question more specific?
106 2015-11-04 03:49:57 <phantomcircuit> gmaxwell, it'll break all the wallets
107 2015-11-04 03:50:02 <gmaxwell> no it won't.
108 2015-11-04 03:50:03 <dcousens> gmaxwell: SW is the separation of the data and the witness, aka the transaction and the signatures.  Won't that cause major disruption for like, everything
109 2015-11-04 03:50:19 <phantomcircuit> although i guess we could rewrite transactions the same was the highs->lows stuff works
110 2015-11-04 03:50:33 <gmaxwell> dcousens: no, luke came up with a formulation while discussing BIP130 which is compatible with the existing transaction format.
111 2015-11-04 03:50:48 <dcousens> gmaxwell: nice, any link?
112 2015-11-04 03:51:11 <gmaxwell> phantomcircuit: oh _forcing_ you to use that would be disruptive, but there is no need to force it.
113 2015-11-04 03:51:25 <phantomcircuit> gmaxwell, yeah that's what i think he was thinking
114 2015-11-04 03:51:26 <gmaxwell> even BIP62 at its height of belief would have been opt in. :)
115 2015-11-04 03:51:45 <gmaxwell> dcousens: mailing list an in here, but the  .. have t orun
116 2015-11-04 03:52:13 <dcousens> gmaxwell: ah, the ML, welp.  Haha, ok I'll have a look through
117 2015-11-04 04:06:28 <gmaxwell> dcousens: back, in any case it's straight forward. a new opcode would say "no signature here" and then the signature is required to be empty (or empty beyond p2sh, if it were used with that). Then, if all your inputs are done that way, the normal txid is the SW txid.  Signatures get tacked on to the end of the transaction. Bitcoin Core used to relay data tacked onto the end of transactions (with no a
118 2015-11-04 04:06:34 <gmaxwell> ccounting or validation of it), so this would bring that back with validation of the signatures.
119 2015-11-04 04:57:31 <moli> i got a spam from  [BitcoinNews] (~IDoTrades@31.6.10.26) when entering this channel
120 2015-11-04 05:09:28 <gmaxwell> moli: likely malware, hope you didn't follow any links it gave you.
121 2015-11-04 05:10:03 <moli> gmaxwell: i didn't
122 2015-11-04 07:28:18 <bitcoin519> is it possible to run two instances of bitcoind with different data-dirs but share the same blockchain files?
123 2015-11-04 07:29:46 <wumpus> you can run as many bitcoind instances as you like, but they cannot share anything
124 2015-11-04 07:31:56 <bitcoin519> wumpus: so they would need their own seperate copies of the blockchain?
125 2015-11-04 07:32:05 <wumpus> yes
126 2015-11-04 07:32:40 <wumpus> you can use pruning to make them only store part of the block chain
127 2015-11-04 07:32:57 <bitcoin519> is that compatible with the wallet portion of bitcoind though?
128 2015-11-04 07:33:31 <wumpus> in master/0.12 it is
129 2015-11-04 07:34:05 <bitcoin519> oh cool! I'll check that out
130 2015-11-04 08:38:22 <fimp> hi. Do you know in which cases "bitcoind gettransaction" returns -1 (minus one) confirmations?
131 2015-11-04 08:38:29 <fimp> I've had a couple of cases with this
132 2015-11-04 08:41:06 <jouke> aren't they doublespends?
133 2015-11-04 08:43:12 <jonasschnelli> fimp, jouke:  -1  : not in blockchain, and not in memory pool (conflicted transaction)
134 2015-11-04 08:43:29 <jonasschnelli> 0  : in memory pool, waiting to be included in a block
135 2015-11-04 08:44:13 <jouke> but gettransaction only returns wallet transactions right? So the transaction was probably malleated?
136 2015-11-04 08:44:22 <jouke> (and thus "doublespent")
137 2015-11-04 08:45:34 <jonasschnelli> very likely conflicted (double spend). Happens regularly when playing around in regtest...
138 2015-11-04 09:52:16 <ThomasV> ops: please ban IDoTrades, he is spamming with malware
139 2015-11-04 09:52:43 <ThomasV> (links to a video that requires to install "flash player")
140 2015-11-04 09:53:26 <ThomasV> midnightmagic: ^
141 2015-11-04 10:02:41 <midnightmagic> oh he's back is he
142 2015-11-04 10:33:12 <ThomasV> midnightmagic: thanks
143 2015-11-04 10:41:38 <midnightmagic> np
144 2015-11-04 11:15:56 <VVTRader> We going to 3000$ read the news!! http://www.nasdaqtoday.com/Overstock-has-confirmed-that-Nasdaq-is-using-blockchain
145 2015-11-04 11:34:30 <VVTRader> We going to 3000$ read the news!! http://www.nasdaqtoday.com/Overstock-has-confirmed-that-Nasdaq-is-using-blockchain
146 2015-11-04 11:42:22 <ThomasV> midnightmagic: see VVTRader
147 2015-11-04 11:42:33 <ThomasV> that's the same link
148 2015-11-04 11:47:15 <midnightmagic> Unfortunately some of the bots we use elsewhere weren't, I guess welcome? Here, so some of the on-message boot stuff available elsewhere, here isn't.
149 2015-11-04 13:09:05 <jtimon> more thoughts on replacing the Container in #6907 ? https://github.com/bitcoin/bitcoin/pull/6907#discussion_r43473571
150 2015-11-04 13:10:32 <jtimon> I'm happy to change it for something equivalent, but it was simpler to me to just implement it than to compare several possibilities (and probably my choice would have been questioned anyway)
151 2015-11-04 13:11:46 <jtimon> jonasschnelli: C++11 smart pointer are not an option, but I bet there's something similar and easy to port to c++11 smart pointers in boost
152 2015-11-04 13:13:12 <jonasschnelli> jtimon: maybe we should use a boost managed pointer and switch to c++11 when we start porting to c++11?
153 2015-11-04 13:13:47 <jonasschnelli> But i'm also fine with Container class... but then we should not use "Container" as class name in the global namespace IMO.
154 2015-11-04 13:15:43 <jtimon> http://www.boost.org/doc/libs/1_59_0/libs/smart_ptr/scoped_ptr.htm seems very close (although actually my container gives more guarantees because the get returns a const ref instead of a non-const pointer)
155 2015-11-04 13:16:24 <jtimon> jonasschnelli: ok, if we keep the container, we can obviously change the name to something less generic
156 2015-11-04 13:17:04 <jtimon> or define a BitcoinTemplates namespace or something
157 2015-11-04 13:18:04 <jtimon> I guess I'll just continue the discussion in the PR...
158 2015-11-04 13:18:17 <jonasschnelli> I would prefer the scoped_ptr from the boost library...
159 2015-11-04 13:19:09 <jtimon> yeah, the advantage of my template is very small and we are getting it by encapsulating the global behind Params() anyway
160 2015-11-04 13:20:19 <jtimon> thanks
161 2015-11-04 13:49:29 <rubensayshi> hmm nLocktime makes a TX non standard and not accepted into mempool right?
162 2015-11-04 13:53:21 <jgarzik_> rubensayshi, not accepted into block or mempool
163 2015-11-04 13:53:27 <jgarzik_> rubensayshi, it is still standard
164 2015-11-04 14:05:52 <JackH> hey guys, where do we have a testnet faucet?
165 2015-11-04 14:09:01 <instagibbs> JackH, http://tpfaucet.appspot.com/
166 2015-11-04 14:09:08 <instagibbs> first one on google results..
167 2015-11-04 14:10:06 <nkuttler> um, that only has 19 coins left? better use mine..
168 2015-11-04 14:10:29 <nkuttler> not that it really matters though
169 2015-11-04 14:57:27 <jtimon> rubensayshi: it is standard but non-final (that's why it doesn't enter the mempool)
170 2015-11-04 14:57:39 <rubensayshi> ok
171 2015-11-04 14:57:58 <rubensayshi> so nodes don't keep it around at all? ( I couldn't find the relevant code :/ )
172 2015-11-04 16:21:25 <instagibbs> nope. I'd like to know how to have it check all but finality, if there's a way.
173 2015-11-04 16:21:33 <instagibbs> Seems useful for testing
174 2015-11-04 16:23:02 <gmaxwell> instagibbs: one way might be via a block proposal.
175 2015-11-04 16:23:18 <gmaxwell> Though some extra flags would need to be added to accept block proposals from more than 2 hours in the future.
176 2015-11-04 16:23:48 <gmaxwell> thats probably an elegant way to test transactions overall, since you can pack up a dependency chain into a block.
177 2015-11-04 18:00:04 <wangchun> We've lately got lots of 20000-sigop blocks, it seems someone is flooding the network with 144-sigop and 225-sigop transactions
178 2015-11-04 18:00:27 <wangchun> #bitcoin-core-dev no longer used?
179 2015-11-04 18:10:18 <Lightsword_> wangchun, thought you might find this interesting, I hacked together a pool block change benchmarking tool http://poolbench.antminer.link/
180 2015-11-04 18:15:16 <bsm1175321> wangchun: #bitcoin-core-dev is specific to Satoshi's code (AFAIK), your question is probably better asked here.  Can you provide a link for such a tx?
181 2015-11-04 19:00:30 <wangchun> bsm117532: bitcoin getblocktemplate | grep '"sigops" : [0-9][0-9][0-9]' you'll see
182 2015-11-04 19:12:57 <arubi> *cough* "[0-9]\{3\}"
183 2015-11-04 19:15:05 <mcelrath> or: bitcoin-cli getblocktemplate | grep '"sigops": [0-9]{3,}'
184 2015-11-04 19:15:41 <mcelrath> I've got 3 right now, one with 466 sigops.  Why reject these?
185 2015-11-04 19:22:31 <dhill> 20000 per block, 4000 per tx?
186 2015-11-04 19:57:09 <dhill> someone kicked in CLTV for testnet it appears
187 2015-11-04 20:19:14 <davec> Yep.  All of the nodes on testnet which haven't upgraded to CLTV code yet are continuing the chain that is invalid per CLTV rules
188 2015-11-04 20:22:57 <nkuttler> um, is cltv relesed yet? i thought only merged?
189 2015-11-04 20:28:40 <davec> Doesn't matter.  Anyone doing IBD on the testnet chain one the new code (whether now or when released later) will hit the activation of the CLTV soft fork and then reject the first v3 block after the activation
190 2015-11-04 20:38:52 <wizkid057> is there really no bitcoin RPC call besides GBT that returns the "bits" field?
191 2015-11-04 20:39:39 <wizkid057> for the current difficulty I mean
192 2015-11-04 20:42:36 <davec> not that I know of.  Everything else is the difficulty as a ratio
193 2015-11-04 20:43:38 <davec> (and of course part of getblock/getblockheader, but that's not the current)
194 2015-11-04 20:43:54 <wizkid057> yeah
195 2015-11-04 20:43:59 <wizkid057> hmm
196 2015-11-04 20:48:40 <davec> Regarding the CLTV thing, either there wil end up being a massive reorg on testnet or a check will have to be added to only consider v4 blocks after a certain timestamp.
197 2015-11-04 20:49:42 <belcher> regarding CLTV, does anyone know if it can be used on regtest from the latest release? or does master need to be compiled to try it out?
198 2015-11-04 20:54:20 <dhill> anyone running master with bip65 soft-fork logic should be stuck on testnet at 582929
199 2015-11-04 21:34:05 <gmaxwell> davec: yes, it kicked in last weekend. The CLTV side has a vast supermajority hashpower fortunately, so no compatibility issue.
200 2015-11-04 21:35:04 <gmaxwell> I think this leave the question closed on if soft fork signaling should have a start at date.
201 2015-11-04 21:35:10 <gmaxwell> rusty: ^ re BIP9.
202 2015-11-04 21:38:43 <Lightsword_> has anyone else ever done pool block propagation benchmarking like this before? http://poolbench.antminer.link/ I’m seeing ~10 seconds for blocks to get out of china
203 2015-11-04 21:42:30 <morcos> gmaxwell: sdaftuar ran the analysis we talked about last meeting for chains of txs in blocks
204 2015-11-04 21:42:51 <morcos> the results were surprising to me at first, but then upon reflection i guess it makes sense
205 2015-11-04 21:43:04 <morcos> there are considerably long chains of txs contained within single blocks
206 2015-11-04 21:43:26 <morcos> but given that almost all of the time there is very little fee pressure to make it in a block
207 2015-11-04 21:43:58 <morcos> you would expect that if you had a chain of txs all paying reasonable fees, that they'd pretty much all get included in the next block
208 2015-11-04 21:44:50 <morcos> and that to the extent that one of the txs towards the beginning and lower fees (which might be why we got a chain in the first place).  that at the point that one could be included, they all would
209 2015-11-04 21:45:43 <morcos> thats just guesswork as to whats going on.  but around 40% of blocks contain at least one chain that would have violated the proposed limits
210 2015-11-04 21:49:25 <gmaxwell> morcos: I guess we need to look at those chains then. :(
211 2015-11-04 21:49:45 <sipa> morcos: wow
212 2015-11-04 21:49:57 <morcos> gmaxwell: yeah when sdaftuar gets back online i'll ask him about publishing his data
213 2015-11-04 21:50:20 <morcos> but he calculated for each tx in each block its package counts, so we can do any analysis we want
214 2015-11-04 21:50:37 <morcos> but what do you mean by look at them?
215 2015-11-04 21:55:57 <morcos> For instance the first one I looked at 21a8d6742912328c02360ba22313f0be27608fc031e2973745b96da2da1a1f85 is a tx that has 241 descendants, that look to mostly be a serial chain of spending change that were issued in relatively quick succession
216 2015-11-04 21:57:35 <morcos> heh, its not spending change, its using that txs output to pay for the fees of other txs
217 2015-11-04 21:59:10 <morcos> thats interesting, maybe some kind of wallet service which covers fees for their users
218 2015-11-04 22:02:50 <morcos> but silly them they first consolidated a bunch of in-chain utxo's to one unconfirmed utxo, and then spent that one serially
219 2015-11-04 22:06:27 <sipa> cfields: do you have any way through which i can easily run leveldb's unit tests in windows?
220 2015-11-04 22:06:39 <sipa> crosscompile/wine/travis/depends/...
221 2015-11-04 22:07:02 <cfields> sipa: sure, should just be a quick hack or two
222 2015-11-04 22:07:30 <sipa> i want to merge bitcoin/leveldb#9 nowish, but i'd like to run its own unit tests at least once...
223 2015-11-04 22:07:53 <cfields> sipa: i should think you could just change the target in the bitcoin makefile, and then do a typical cross build
224 2015-11-04 22:08:23 <cfields> sec
225 2015-11-04 22:08:26 <sipa> thanks!
226 2015-11-04 22:15:23 <cfields> sipa: actually, looks even easier than that
227 2015-11-04 22:16:44 <cfields> sipa: make CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar LDFLAGS=-static TARGET_OS=OS_WINDOWS_CROSSCOMPILE check
228 2015-11-04 22:17:16 <sipa> how will it know to invoke wine?
229 2015-11-04 22:17:22 <cfields> (from leveldb dir, ofc)
230 2015-11-04 22:17:48 <cfields> sipa: in linux, that's actually handled via a kernel module. It should just work (tm).
231 2015-11-04 22:18:40 <cfields> magic# is checked in the binary before running as long as binfmt_misc is installed/inserted.
232 2015-11-04 22:18:42 <sipa> heh, the leveldb unit tests invoke geteuid, which windows doesn't have
233 2015-11-04 22:18:46 <sipa> nobody every ran these tests
234 2015-11-04 22:18:56 <cfields> sipa: oh yep, forgot i had to hack that out.
235 2015-11-04 22:19:22 <sipa> CorruptionTest.recovery fails
236 2015-11-04 22:19:32 <sipa> wumpus: looks related
237 2015-11-04 22:19:49 <sipa> db/corruption_test.cc:168: Assertion failure s.ok() IO error: C:\users\pw\Temp\leveldb\test\\db_test\000003.log: Invalid handle.
238 2015-11-04 22:23:15 <sipa> oh, this fails on current leveldb too
239 2015-11-04 22:37:56 <farghaly> can input-output reference make recursion and stack overflow ?
240 2015-11-04 22:38:42 <gmaxwell> farghaly: an input is identified by the cryptographic hash of a transaction, so you cannot make A depend on B if B depends on A.
241 2015-11-04 22:39:09 <gmaxwell> In Bitcoin Core, almost nothing of it goes onto the stack.