1 2015-07-22 00:07:32 <phantomcircuit> bleh takes ages to verify the 1MB blocks :|
  2 2015-07-22 00:15:13 <CodeShark> especially when there's craploads of inputs in a single transaction
  3 2015-07-22 00:19:41 <phantomcircuit> CodeShark, >30 minutes now to catch up 30 days on an 8 core cpu
  4 2015-07-22 00:20:31 <CodeShark> as I continue to say, cost of validation is the biggest problem with the protocol...and fixing this should be top priority
  5 2015-07-22 00:21:01 <CodeShark> if we're going to do a hard fork, this should be at the top of the list :)
  6 2015-07-22 00:21:33 <phantomcircuit> CodeShark, iirc there's basically only one thing we can do fundamentally and that is to reduce the cost of the signature operations
  7 2015-07-22 00:21:44 <phantomcircuit> but that's at best a 4-8x improvement
  8 2015-07-22 00:21:54 <phantomcircuit> and would be suppper disruptive
  9 2015-07-22 00:22:00 <CodeShark> right - we need algorithmic improvements
 10 2015-07-22 00:22:17 <CodeShark> beyond just increasing speed of specific operations
 11 2015-07-22 00:24:38 <CodeShark> there might be significant optimizations possible if we're willing to sacrifice determinism, no? i.e. allowing for a negligible failure rate
 12 2015-07-22 00:26:17 <CodeShark> or perhaps ultimately requiring that miners provide SNARKs or SNARGs
 13 2015-07-22 00:27:17 <phantomcircuit> CodeShark, probabilistic payments is one such solution
 14 2015-07-22 00:27:43 <phantomcircuit> unfortunately the opcodes necessary for that were disabled
 15 2015-07-22 00:27:54 <CodeShark> how do probabilistic payments work?
 16 2015-07-22 00:28:07 <phantomcircuit> (and that's way harder to support than lightning)
 17 2015-07-22 00:28:42 <phantomcircuit> CodeShark, to pay your 0.01 BTC; I pay you 1.00 BTC with a probability of 1:100 of the payment being valid
 18 2015-07-22 00:29:23 <CodeShark> oh, hmmm - sounds that only certain use cases would really be sensible for that
 19 2015-07-22 00:29:28 <CodeShark> *sounds like
 20 2015-07-22 00:29:32 <phantomcircuit> hash preimages and xor is technically enough to make it work
 21 2015-07-22 00:29:35 <phantomcircuit> (but not very well)
 22 2015-07-22 00:29:39 <CodeShark> lightning doesn't address the cost of blockchain validation - it just addresses the need to commit every transaction to it
 23 2015-07-22 00:30:24 <phantomcircuit> CodeShark, both are the same approach; leverage the strong guarantees bitcoin makes to build offchain solutions with strong gurantees
 24 2015-07-22 00:31:31 <CodeShark> but we still have the problem of validating the blockchain - although with SNARKs it might be possible to outsource the proofs
 25 2015-07-22 00:32:27 <phantomcircuit> CodeShark, get the offchain scaling solutions to work and then soft fork a massive reduction in blocksize
 26 2015-07-22 00:33:12 <CodeShark> even a reduction in blocksize doesn't fundamentally solve the blockchain validation scaling issue
 27 2015-07-22 00:36:43 <phantomcircuit> CodeShark, no but a reduction in the rate at which the validation time is growing might allow the rate at which validation becomes cheaper to overtake
 28 2015-07-22 00:37:02 <phantomcircuit> currently validation cost is clearly growing faster than the cost is dropping
 29 2015-07-22 00:37:07 <CodeShark> right
 30 2015-07-22 00:37:09 <phantomcircuit> net positive increase in validation costs
 31 2015-07-22 00:46:02 <CodeShark> which might actually be ok if 1) we could securely outsource validation and 2) the cost were taken into account in network fees
 32 2015-07-22 00:47:57 <phantomcircuit> CodeShark, yesh except your cant and wat fees dont effect validation except as a lame anti spam proxy
 33 2015-07-22 00:51:19 <CodeShark> if miners were required to include SNARKs...haven't done the math, though - not sure how practical that is
 34 2015-07-22 00:52:01 <phantomcircuit> CodeShark, zk-SNARKS are far too new to be relied upon
 35 2015-07-22 00:52:16 <phantomcircuit> give them... a decade or more
 36 2015-07-22 00:52:21 <CodeShark> you think that long?
 37 2015-07-22 00:52:37 <phantomcircuit> (im sure i'll get an angry message about saying that from someone)
 38 2015-07-22 00:52:50 <phantomcircuit> CodeShark, do it as a sidechain
 39 2015-07-22 00:52:59 <phantomcircuit> then you can do it tomorrow and only risk those funds
 40 2015-07-22 00:53:01 <phantomcircuit> horray!
 41 2015-07-22 00:54:06 <CodeShark> what's your main concern? security? efficiency? both?
 42 2015-07-22 00:54:40 <CodeShark> we should probably move this over to wizards
 43 2015-07-22 08:42:27 <Luke-Jr> wumpus: should I rebase and reopen "require configuring mining policy before mining works"?
 44 2015-07-22 08:44:29 <phantomcircuit> Luke-Jr, which pr #?
 45 2015-07-22 08:44:50 <Luke-Jr> phantomcircuit: 3229
 46 2015-07-22 08:51:32 <phantomcircuit> Luke-Jr, seems like a good idea
 47 2015-07-22 09:47:51 <wumpus> Luke-Jr: yes. I think that's a good idea.
 48 2015-07-22 09:48:23 <wumpus> better than having to change the default in the code every time
 49 2015-07-22 09:54:38 <wumpus> although I suppose this only applies to mining...
 50 2015-07-22 10:40:36 <venzen> hi, i'm graphing mempool fees. Is the shortest route to calculating tx fee as follows? 1) getrawtransaction "tx", 2) decoderawtransaction "tx", 3) get the total outputs, 4) getrawtransaction (for each vin) and calc total inputs, 5) fee = total vout - total vin
 51 2015-07-22 10:43:12 <venzen> *5) fee = total vin - total vout
 52 2015-07-22 10:54:19 <sipa> venzen: making bitcoind print them out as they come in will be much more efficient
 53 2015-07-22 10:54:30 <sipa> but if you need it after the fact, yes
 54 2015-07-22 10:54:55 <sipa> as the utxo database entries used to compute thebfees for validation are removed after seeing the tx in the blockchain
 55 2015-07-22 10:55:31 <sipa> actually, the undo blocks also contain this information, but that's not ezposed through rpc
 56 2015-07-22 11:10:11 <MrTratta> does anyone know if there's a server of RelayNode for testnet?
 57 2015-07-22 11:10:39 <sipa> BlueMatt: ^
 58 2015-07-22 11:10:41 <sipa> ?
 59 2015-07-22 11:12:02 <MrTratta> couldn't find any mention on the site or in the source code so i assume there's none. I think it may be reasonable to have one and if nobody is inclined to run it I guess I could run oen
 60 2015-07-22 11:12:08 <MrTratta> s/oen/one
 61 2015-07-22 11:43:17 <mjerr> whats the chance someone else fetching a tx, resigning a signature from a multisig input (that he has the priv key of) and broadcasting it again, to change the txid? Are there any tests on this? It obviously depends on the connectivity of the original sender and of the 'attacker', which tx ends with the miner that includes it in the next block
 62 2015-07-22 11:52:03 <sipa> mjerr: no need for multisig; the author of a transaction can always re-sign, to create a new signature
 63 2015-07-22 11:52:43 <mjerr> Yea sure, but if he gives away a partly signed transaction
 64 2015-07-22 11:52:55 <mjerr> and the other party cosigns and broadcasts it
 65 2015-07-22 11:53:13 <mjerr> what are the odds of interefering and resigning again, and having it included in the next block
 66 2015-07-22 11:57:52 <sipa> you're just asking what the chances are for a double spend
 67 2015-07-22 11:58:36 <mjerr> Hm - havent thought about it this way
 68 2015-07-22 11:59:19 <sipa> well, a double spend that can't change fees or dependency chains is not the double spending problem in general
 69 2015-07-22 11:59:45 <sipa> but if there is money to be earned by doing it, someone will find a way
 70 2015-07-22 12:00:00 <sipa> bip62 was designed for solving part of this problem
 71 2015-07-22 12:00:20 <sipa> but not the author signing again, which can't be prevented
 72 2015-07-22 12:00:36 <sipa> it can be madenharmless through normalized transaction ids
 73 2015-07-22 12:00:41 <mjerr> what would be your educated guess, if I broadcast a tx to a very well connected node, it would probably still be possible, even though with low odds
 74 2015-07-22 12:01:19 <mjerr> hm, at least the attacker cannot earn money, would rather be vandalism
 75 2015-07-22 12:01:27 <mjerr> in my case
 76 2015-07-22 12:05:03 <sipa> asking about chances is a silly question
 77 2015-07-22 12:05:10 <sipa> the question is how much it would cost
 78 2015-07-22 12:05:44 <mjerr> And would a child tx of the mutated with a very high fee push it through? children pays parent is not yet implemented I think
 79 2015-07-22 12:05:59 <sipa> cpfp is not widely deployed
 80 2015-07-22 12:06:43 <mjerr> but a miner, who deployed it, would discard the first tx in favor of the mutated, right?
 81 2015-07-22 12:07:16 <mjerr> which can go either way actually, as the first party can increase the fee on a child tx aswell
 82 2015-07-22 12:07:22 <mjerr> would just waste everybodys money
 83 2015-07-22 12:10:01 <mjerr> is it still controversial, or are the miners too lazy to implement it?
 84 2015-07-22 12:17:20 <morcos> sipa: have you observed what kind of effect your dFeeRateMultiplier has in practice?   I think in my simulations it only ever got up to 1.5, but that might be an artifact of the very small mempool.  I was actually more concerned with the other side.  If the mempool is capped at 300 and someone floods it from 210 to 300 very quickly, its by definition going to take > 15 hours to drain during which time seems like the multipl
 85 2015-07-22 12:19:05 <harding> morcos: your text got cut off at: seems like the multipl
 86 2015-07-22 12:19:29 <morcos> ier could get quite high? (whoops)
 87 2015-07-22 12:25:57 <sipa> morcos: i've seen it make fees go up to 3300 satoshi/kb
 88 2015-07-22 12:26:06 <sipa> with 64 mb cap
 89 2015-07-22 12:27:30 <morcos> isn't that kind of weird that the effect wasn't bigger?  i don't think 3300 satoshi's should have been enough to really slow down the tx rate, but maybe the stress test only came in small bursts and blocks naturally cleared out the mempool to bring it back to aimed usage?
 90 2015-07-22 12:28:27 <morcos> what do you think about my concern in practice that it could serve as an attack vector?
 91 2015-07-22 12:29:15 <morcos> i want to try out a few more ideas and am trying to decide whether i should revert that change or not first
 92 2015-07-22 12:44:13 <morcos> sipa: i think there must be something wrong with it.  i printed out some more debugging information and there was a 3 hour period where i was at least 25% over the aimed usage, and yet the min relay fee only went up to 1012
 93 2015-07-22 12:48:58 <venzen> sipa: thanks for your earlier reply re: mempool fees: "making bitcoind print them out as they come in will be much more efficient"
 94 2015-07-22 12:49:54 <venzen> sipa: is that exposed via rpc? or how do you suggest getting at fees as txns come in?
 95 2015-07-22 12:59:43 <morcos> sipa: ugh, never mind, its just screwed up in my simulation
 96 2015-07-22 13:00:00 <morcos> sipa: but my concerns still hold about using it in practice
 97 2015-07-22 13:02:19 <jtimon> the more I think about it, the less sense it makes to require 75% to start applying a local node policy, only the 95% for starting to consensus enforce it makes sense sipa petertodd thoughts?
 98 2015-07-22 13:10:01 <drazisil> harding: upgraded https://github.com/bitcoin-dot-org/bitcoin.org/pull/969 to cover all instances.
 99 2015-07-22 13:10:45 <harding> drazisil: thanks.  I'll take a look at it later today.
100 2015-07-22 13:18:10 <drazisil> harding: cool. may be a good time to merge https://github.com/bitcoin-dot-org/bitcoin.org/pull/968 as well, I took a glance at your staging page and it looks solid.
101 2015-07-22 13:30:26 <drazisil> Why does the mac version have the qy name still, vs core everywhere else?
102 2015-07-22 13:41:51 <drazisil> after some research, opened https://github.com/bitcoin/bitcoin/issues/6463 since it seems to have been fixed in the past
103 2015-07-22 13:48:25 <jtimon> venzen: maybe you're interested in #6445
104 2015-07-22 13:48:51 <wumpus> there was some problem last time we tried to rename the executable for mac, eg it resulted in situations in which two versions could get installed at the same time
105 2015-07-22 13:49:06 <wumpus> but I only vaguely remember, the whole discussion should be in pull requests
106 2015-07-22 13:50:32 <jtimon> venzen: (assuming you're fine with adding a LogPrintf(), recompiling, running and looking at the logs is enough for you)
107 2015-07-22 13:50:49 <venzen> jtimon: excuse my ignorance is that a github patch number?
108 2015-07-22 13:50:58 <drazisil> I think I found the relevant pr and linked it, it only mentioned spaces. I'm not a mac dev per say, but I believe you kept the -qy for the filename and just changed display, I think this one just was missed.
109 2015-07-22 13:52:35 <venzen> jtimon: i can edit the code and recompile, no problem
110 2015-07-22 13:52:37 <jtimon> venzen: that's a pull request (aka PR) [a proposal for a change] to bitcoin core, you can read it here: https://github.com/bitcoin/bitcoin/pull/6445
111 2015-07-22 13:52:54 <venzen> jtimon: thanks a lot
112 2015-07-22 13:54:06 <jtimon> so you can fetch that, add a LogPrintf on Consensus::CheckTxInputs an get the fees into the log every time they are calculated for the first time
113 2015-07-22 13:55:37 <jtimon> venzen: no problem, I'm acting purely on self-interest since you seem to have a good excuse to test on top of that branch. Please, let me know if my code gives you any problem
114 2015-07-22 13:56:23 <jtimon> venzen: actually, please post on https://github.com/bitcoin/bitcoin/pull/6445 if that code gives you any problems
115 2015-07-22 13:59:39 <jtimon> venzen: if you are only interested in fees that have been accepted in a mined block, then just put your LogPrintf in main.cpp::ConnectBlock instead
116 2015-07-22 14:00:06 <venzen> jtimon: sure, i'll have a look and post any issues there
117 2015-07-22 14:01:18 <jtimon> venzen: great, thanks! (although as said if  you are only interested in fees that have been accepted in a mined block, you don't need that patch)
118 2015-07-22 14:02:00 <jtimon> actually, you don't really need that patch, but as said I think it's a good excuse to use it
119 2015-07-22 14:03:50 <venzen> jtimon: what i really want is to have the fees as they arrive and plot them, maybe i can extend the patch to have an RPC call
120 2015-07-22 14:04:07 <venzen> s/them/txns
121 2015-07-22 14:04:28 <venzen> s/they/txns
122 2015-07-22 14:04:58 <venzen> i want to measure mempool fee levels and plot their averages, etc
123 2015-07-22 14:06:15 <venzen> jtimon: thanks this will be useful and i'll feedback when i have something usable
124 2015-07-22 14:07:04 <jtimon> venzen: awesome
125 2015-07-22 14:09:29 <jtimon> venzen: both that you want to plot that and that you find my patch useful to do so
126 2015-07-22 14:16:21 <kakobrekla> what am i missing here? http://dpaste.com/0HW7GKP.txt
127 2015-07-22 14:19:51 <gavinandresen> kakobrekla: blockchain.info and bitcoind just have different definitions of "total received" when you're sending change back to the same address.  I think.
128 2015-07-22 14:20:14 <kakobrekla> hrm
129 2015-07-22 14:21:08 <kakobrekla> yes i see what you mean.
130 2015-07-22 15:48:11 <sipa> venzen: no, it's not exposed through rpc; just saying that if you modify the binary, you can get per-tx fees *much* mire efficiently
131 2015-07-22 16:24:32 <venzen> sipa: thanks for confirming
132 2015-07-22 17:41:49 <cfields> jtimon: ping
133 2015-07-22 17:50:07 <jtimon> cfields: pong
134 2015-07-22 17:51:41 <kakobrekla> shouldnt 'getbalance' return 'balance' and not 'total received' ? http://dpaste.com/039FQVK.txt
135 2015-07-22 17:52:52 <kakobrekla> is it even possible to get spendable balance with a single call?
136 2015-07-22 17:54:47 <helo> kakobrekla: as far as i can tell, it does return spendable balance
137 2015-07-22 17:55:12 <helo> oh, you're passing it an address
138 2015-07-22 17:57:12 <kakobrekla> each address has itsself as account name, because it is genius that you can getbalance only by 'account name'
139 2015-07-22 17:58:23 <kakobrekla> so, how must i massage bitcoin-cli to spit out the spendable 2 btc on the address instead of 12k?
140 2015-07-22 18:00:24 <helo> i'm afraid the answer is, "addresses don't have balances", see https://en.bitcoin.it/wiki/Address#Address_balances
141 2015-07-22 18:01:07 <kakobrekla> they have a spendable amount of them, dont they ?
142 2015-07-22 18:01:14 <kakobrekla> on*
143 2015-07-22 18:01:43 <kakobrekla> well, 'unlock' a certain spendable amount
144 2015-07-22 18:01:45 <helo> this is a better discussion for #bitcoin, since it isn't related to development changes
145 2015-07-22 18:02:13 <kakobrekla> call it and egg or an orange, but just wanna know if such basic call exists, apparently such things is visible from cli
146 2015-07-22 18:02:16 <kakobrekla> er gui
147 2015-07-22 18:02:26 <helo> but that wiki entry is a good explanation
148 2015-07-22 18:03:22 <kakobrekla> you can see you own spendable/unspent outputs in gui, but not in cli
149 2015-07-22 18:03:33 <kakobrekla> thats how it is?
150 2015-07-22 18:06:14 <jtimon> kakobrekla: not sure if "getbalance *" serves you, but, yes, #bitcoin
151 2015-07-22 18:07:11 <kakobrekla> why, the devs cant handle the question?
152 2015-07-22 18:08:15 <helo> people monitor this channel for important development information, and this is noise
153 2015-07-22 18:08:27 <jtimon> kakobrekla: this channel is for development, usage questions belong in #bitcoin where you hopefully will get an answer faster
154 2015-07-22 18:09:00 <kakobrekla> yes i can see how this chan is for important dev stuff as it is dead.
155 2015-07-22 18:11:26 <kakobrekla> as for dev part, at least 2 calls seem to do the same thing, one with a silly name.
156 2015-07-22 18:23:32 <kakobrekla> got my answer, bitcoind cant do it.
157 2015-07-22 18:29:54 <wumpus> try 'listunspent'
158 2015-07-22 18:30:29 <wumpus> it lists all unspent outputs in your wallet, including the address they were sent to and the amount
159 2015-07-22 18:42:48 <kanzure> jgarzik: miners pick fees, not bitcoin developers.
160 2015-07-22 18:46:39 <jgarzik> kanzure, Miner fee picking is constrained within the subset of what the software allows (block size)
161 2015-07-22 18:47:13 <jgarzik> kanzure, If the software stays at 1MB forever, what happens to fees?
162 2015-07-22 18:49:18 <jgarzik> kanzure, Further historical data shows that many miners - fewer now, after stress tests - simply take the soft limit defaults, thus relying on suggestive guidance
163 2015-07-22 18:49:20 <kanzure> jgarzik: so your claim is that a certain block size enforces miner policy?
164 2015-07-22 18:49:46 <kanzure> ok, so that sounds like "i just want to be careful about defaults"
165 2015-07-22 18:49:53 <kanzure> s/just//
166 2015-07-22 18:50:42 <warren> How many of the miners are actually using defaults now?  One of those threads said maybe 90% have changed defaults.
167 2015-07-22 18:52:51 <midnightmagic> petertodd seems to think currently almost all miners do not follow historical patterns and that most choose their limit explicitly. https://github.com/bitcoin/bitcoin/pull/6231#issuecomment-123439465
168 2015-07-22 18:53:26 <jgarzik> warren, I don't agree with the 90% number as that doesn't seem to match long run averages - however - it is true that far fewer use them now
169 2015-07-22 18:53:29 <midnightmagic> he seems to also get flamed a lot, so he seems to say things fairly carefully.
170 2015-07-22 18:53:30 <denisx> my pool uses defaults ;)
171 2015-07-22 18:53:41 <midnightmagic> quiet you ;-)
172 2015-07-22 18:54:43 <Luke-Jr> jgarzik: merchants pick what the software allows (block size), not developers
173 2015-07-22 18:58:03 <jgarzik> Luke-Jr, That seems to be false, as merchants are nearly universal in wanting a larger block size
174 2015-07-22 19:00:45 <Luke-Jr> jgarzik: wanting in what sense, though? as an unbounded ideal before concerns for practicality, or as a realistic change they actively will to occur?
175 2015-07-22 19:04:19 <midnightmagic> Also who cares what a merchant who isn't actually running a node thinks?
176 2015-07-22 19:08:34 <denisx> is there an option to make the output of getblocktemplate non-pretty or compact?
177 2015-07-22 19:08:54 <denisx> or is this only possible with a change in the code?
178 2015-07-22 19:14:23 <Luke-Jr> midnightmagic: well, if I want to pay them, I have to care what payment they accept
179 2015-07-22 19:15:20 <Luke-Jr> denisx: how do you mean? isn't it already compact?
180 2015-07-22 19:16:02 <denisx> Luke-Jr: no, one item per line, indented with lots of spaces
181 2015-07-22 19:16:17 <denisx> also spaces between items
182 2015-07-22 19:17:35 <Luke-Jr> denisx: I don't get that from my bitcoind
183 2015-07-22 19:17:50 <Luke-Jr> are you sure you're not using bitcoin-cli, which pretty-prints anything?
184 2015-07-22 19:18:32 <denisx> Luke-Jr: yes, I use bitcoin-cli
185 2015-07-22 19:18:39 <denisx> I thought it would only passthrough the data
186 2015-07-22 19:19:42 <Luke-Jr> denisx: no, it parses and pretty-prints it
187 2015-07-22 19:19:59 <Luke-Jr> denisx: the actual result from bitcoind is always compact
188 2015-07-22 19:20:19 <denisx> Luke-Jr: ah ok, I didnt knew that, thanks
189 2015-07-22 19:22:51 <denisx> Luke-Jr: ok, tcpdump says you’re right ;)
190 2015-07-22 20:00:10 <BlueMatt> MrTratta: the relay network for testnet is -addnode=bitcoin-seednode.bluematt.me :p
191 2015-07-22 23:37:29 <jtimon> petertodd: (or anyone else who knows) can you enumerate PRs related to cltv that have been merged in 0.12.99 ?
192 2015-07-22 23:38:04 <jtimon> in commits I'm seeing cb54d17
193 2015-07-22 23:38:08 <petertodd> jtimon: https://github.com/bitcoin/bitcoin/pull/6351 is the only thing that needs to happen
194 2015-07-22 23:39:36 <petertodd> midnightmagic: "he seems to also get flamed a lot, so he seems to say things fairly carefully." <- you mean me? that 90% figure wasn't *that* careful - might have actually been, say, 80% or something IIRC, but either figure proves my point anyway
195 2015-07-22 23:40:06 <petertodd> midnightmagic: bit of uncertainty re: slush
196 2015-07-22 23:40:29 <jtimon> no, petertodd I just want to rebase all the non-activated merged things back to 0.11 (I only see #6368), and then back to 0.10 as well (so the PRs merged on 0.11.99 are useful as well)
197 2015-07-22 23:40:56 <petertodd> jtimon: non-activated, you mean CLTV stuff in general? or the mempool only bit?
198 2015-07-22 23:41:14 <jtimon> I mean cltv in general
199 2015-07-22 23:41:30 <petertodd> jtimon: I do have it on my todo list to port CLTV to v0.11.x, but if you want to do it that'd be good - a great way to get another eye on the code
200 2015-07-22 23:41:43 <jtimon> from master to 0.10, I can do it myself, but maybe you had a list or something
201 2015-07-22 23:42:01 <petertodd> jtimon: it's just the two pull-reqs, nothing more
202 2015-07-22 23:44:53 <jtimon> petertodd: so just #6368 and #6124 ? great, thanks
203 2015-07-22 23:45:06 <petertodd> jtimon: yup, just them
204 2015-07-22 23:45:55 <petertodd> jtimon: some further work needs to be done for things like actually renaming OP_NOP2 in some places, but there's no need to make that part of the backport (nor has that code even been written anyway)
205 2015-07-22 23:45:59 <jtimon> the confirmation will probably save me some time, thanks
206 2015-07-22 23:47:26 <jtimon> petertodd: yeah I know the backport won't be complete at this point, but I want everything that has already been merged back in time, the final backport can be completed later
207 2015-07-22 23:48:23 <petertodd> jtimon: yup - I'd say release v0.11.x and v0.10.x w/o those frills to reduce risk. No need to do tht stuff until v0.12.0
208 2015-07-22 23:49:56 <jtimon> petertodd: no need for bitcoin core at all, it's just to help me rebase other things dependent on cltv, no need to reinvent the wheel for things that have already been merged upstream
209 2015-07-22 23:57:22 <moa> petertodd: are there any new RPC calls planned to accompany/utilise CLTV?
210 2015-07-22 23:57:34 <petertodd> moa: none that I know of
211 2015-07-22 23:58:35 <jtimon> moa: I believe nLockValue and adapting your scripts is enough (althogh the wallet can of course use it too)