1 2016-06-21 00:47:41 <jl2012> Got enough blocks for csv
 2 2016-06-21 01:11:12 <gmaxwell> jl2012: assuming no big reorgs! :)
 3 2016-06-21 12:48:45 <Perkova> hello
 4 2016-06-21 12:48:55 <Perkova> I am looking for a answer on a problem with the Blocktrail PHP SDK
 5 2016-06-21 12:49:03 <Perkova> or rather some new insight.
 6 2016-06-21 12:50:00 <Perkova> Does anybody know if the blocktrail php sdk has some functionality built in to deduct the fees in the walletinterface pay function
 7 2016-06-21 12:50:30 <Perkova> And I mean deducting the fee from the transaction being created.
 8 2016-06-21 14:06:28 <wumpus> not sure anyone here knows, may be better to ask blocktrail
 9 2016-06-21 17:38:02 <Ylbam> question : non CSV signaling blocks will be rejected at next difficulty adjustment. am I right?
10 2016-06-21 17:44:06 <Ylbam> it looks like it's not the case as said yoghurt on core's slack: "The signal bit is available for another soft fork immediately after activation"
11 2016-06-21 18:42:23 <s7r> what is the eta for increasing the hash for payments from 160 to 256 in P2SH scripts?
12 2016-06-21 18:43:19 <s7r> will this change address format or generation process? I am trying to generate in advance for long term a p2sh address so need to know. will we be using in parallel 160 bit and 256 bit hashes for p2sh addresses?
13 2016-06-21 18:43:56 <arubi> s7r, I'm curious, what are you referring to?
14 2016-06-21 18:44:29 <s7r> https://bitcoincore.org/en/2016/01/26/segwit-benefits/#increased-security-for-multisig-via-pay-to-script-hash-p2sh
15 2016-06-21 18:44:36 <gmaxwell> s7r: current behavior will continue to work, presumably until some cryptographic break makes it necessary to disable.
16 2016-06-21 18:45:04 <gmaxwell> to do otherwise would confsciate people's coins.
17 2016-06-21 18:45:17 <s7r> ok, and the new 256 bit hash addresses will look totally different and work in parallel, unrelated, correct?
18 2016-06-21 18:45:19 <arubi> oh, so this is about p2wsh which is 256bit hash
19 2016-06-21 18:45:40 <arubi> p2sh(p2wsh) is still 160 bit hash, paying to a 256 bit hash
20 2016-06-21 18:45:52 <arubi> well, not paying, the redeemscript hash is ^
21 2016-06-21 18:45:59 <s7r> I don't understand the difference between p2sh and p2wsh
22 2016-06-21 18:46:31 <arubi> paying to native p2wsh is paying to a script hash that is 256 bits, a sha256 of the redeem script
23 2016-06-21 18:46:47 <arubi> paying to p2sh is paying to a script hash that is 160 bits, a hash160 of the redeem script
24 2016-06-21 18:47:35 <arubi> so, unless you use native p2wsh, which pays to a segwit program, you will not benefit from 256 bit hash of the redeem script
25 2016-06-21 18:48:27 <s7r> understood.
26 2016-06-21 18:48:39 <s7r> thanks.
27 2016-06-21 18:48:57 <arubi> cheers
28 2016-06-21 18:49:15 <s7r> using the old p2sh even after segwit softfork is completed will work exactly as now and provide the same level of security eg 160 bit
29 2016-06-21 18:50:49 <arubi> right
30 2016-06-21 18:51:38 <s7r> arubi: thanks. one last thing. the combination CHECLOCKTIMEVERIFY with p2wsh will work exactly as with the current p2sh?
31 2016-06-21 18:53:23 <arubi> s7r, I'd guess yes, I haven't tried using ctlv yet so I can't tell for sure
32 2016-06-21 18:53:52 <gmaxwell> I would advise against using locktimes far in the future.
33 2016-06-21 18:54:10 <arubi> is there an asteroid approaching?
34 2016-06-21 18:54:47 <s7r> I need 12 months or worst case scenario 24 months.
35 2016-06-21 18:55:09 <s7r> I would need less if we had a relative checklocktimeverify implemented, but that isn't coded yet right?
36 2016-06-21 18:55:43 <arubi> you mean CSV?  isn't that what it is?
37 2016-06-21 18:56:26 <arubi> gmaxwell, I mean.. why not far into the future?  genuinely curious
38 2016-06-21 18:56:58 <s7r> no, RCLTV. what we have now is absolute checklocktimeverify. it is based on an absolute time/height. RCLTV will be based on the age of the coins, clock starts ticking after address is funded
39 2016-06-21 18:57:26 <s7r> me too ^
40 2016-06-21 18:58:34 <arubi> s7r, I'm lost as how that is not what csv does
41 2016-06-21 18:59:31 <arubi> "allowing funds of a txout to be locked for a number of blocks or a duration of time after its inclusion in a block"
42 2016-06-21 18:59:57 <s7r> csv == check sequence verify ?
43 2016-06-21 19:00:01 <arubi> yea
44 2016-06-21 19:00:18 <s7r> that is also draft.. i mean it's not implemented yet
45 2016-06-21 19:00:41 <s7r> the same RCLTV. Didn't read CSV's specs yet so you might be right
46 2016-06-21 19:00:49 <arubi> s7r, says "status": "locked_in" here :)
47 2016-06-21 19:00:59 <arubi> s7r, really, it's in the news.  it just locked in
48 2016-06-21 19:01:24 <s7r> what was the cli command to see softfork adoption?
49 2016-06-21 19:01:35 <arubi> bitcoin-cli getblockchaininfo
50 2016-06-21 19:03:40 <s7r> i don't see anything about bip112
51 2016-06-21 19:06:15 <arubi> s7r, https://bitcoin.org/en/release/v0.12.1#first-version-bits-bip9-softfork-deployment
52 2016-06-21 19:07:36 <s7r> that is confusing. bip 112 is marked as draft. not final
53 2016-06-21 19:07:45 <s7r> https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
54 2016-06-21 19:09:20 <arubi> heh, I guess it's not very effective then :)  but it /is/ happening now
55 2016-06-21 19:09:54 <s7r> ok. so right now i can use csv?
56 2016-06-21 19:10:14 <arubi> I don't think it's enforced yet, only going to be
57 2016-06-21 19:11:59 <gmaxwell> arubi: because people have proposed things that would make old style transactions invalid. For example people around bitcoin "classic" wanted a "hardfork segwit" that would change the transaction format.
58 2016-06-21 19:12:17 <gmaxwell> s7r: soft fork bips are not final until in active established use in the network.
59 2016-06-21 19:13:27 <gmaxwell> arubi: or, for example, if there were a ecdsa or ripemd160 break that made any coins spendable with a few months of cpu time, the network might need to to prohibit moving old unswept coins after some transition, but long locktimed coins could not make a transition.
60 2016-06-21 19:13:48 <arubi> oh good point.
61 2016-06-21 19:14:32 <s7r> good point.
62 2016-06-21 19:14:47 <s7r> gmaxwell: why do we need bip68 and bip112? doesn't bip112 already do the relative lock time thing?
63 2016-06-21 19:15:41 <gmaxwell> 68 is what creates a relative lock. 112 is what makes it possible for a public key to require that a transaction have a relative lock.
64 2016-06-21 19:16:26 <s7r> ^ that's why it's important to ask the best
65 2016-06-21 19:16:31 <s7r> thanks.