1 2015-11-01 09:11:50 <jtimon> ping 6068...
  2 2015-11-01 13:54:39 <bitcoin-dev825> How can I decode the "hex" field to an address in "scriptPubKey" from a raw transaction?
  3 2015-11-01 13:59:39 <afk11> bitcoin-dev825: https://en.bitcoin.it/wiki/Script see the bottom.
  4 2015-11-01 14:09:16 <bitcoin-dev825> afk11: specifically where? It says http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html here "It contains the destination address expressed in hex, not Base58Check" but having trouble decoding it to an address
  5 2015-11-01 14:10:56 <afk11> ok. Avoid thinking of things in hex it means binary. You see the part that says 'public key hash' underneath the line you pasted?
  6 2015-11-01 14:12:05 <afk11> Well, addresses consist of a hash, a prefix (indicating what type of address it is) and a checksum. You have pay-to-pubkey-hash, or pay-to-script-hash addresses.
  7 2015-11-01 14:13:51 <bitcoin-dev825> Right, i see, I can tell what type it is from "type" : "scripthash"
  8 2015-11-01 14:14:44 <afk11> Going from Address to Script involves validating the address, determining which address type it is based on the first byte, taking the hash from the address (20 bytes of binary), and constructing the necessary output script for that type
  9 2015-11-01 14:16:25 <afk11> But for the reverse - just classify the script, if it's either of the two types, just extract the hash and rebuild the address.
 10 2015-11-01 14:17:13 <bitcoin-dev825> is the hash that last 20 bytes ?
 11 2015-11-01 14:18:38 <bitcoin-dev825> or is the "hex" field the hash? Still a little confused
 12 2015-11-01 14:21:23 <afk11> the hash is embedded in the script. See sections on this page: https://en.bitcoin.it/wiki/Transaction#Types_of_Transaction
 13 2015-11-01 14:23:20 <afk11> the hash is only one part of these scripts. ScriptPubKey.hex != the hash. But since you're probably looking at bitcoind, does hash160 come up for pay-to-script-hash outputs?
 14 2015-11-01 14:57:08 <bitcoin-dev825> afk11: sorry, this is what I'm looking at. http://pastebin.com/91dG58aR from decoderawtransaction - the "hex" field
 15 2015-11-01 15:20:07 <freemason> i buy 666 bit
 16 2015-11-01 15:23:05 <jaromil> jtimon: pong 6068...
 17 2015-11-01 15:33:25 <afk11> bitcoin-dev825: the hash in the case you posted is the 'asm' value starting with 18. Look in the hex for where that starts. hint: after 0x14, which in decimal is 20...
 18 2015-11-01 17:38:06 <cryptohustlin> Anyone familiar with mongoDB?
 19 2015-11-01 18:26:17 <Luke-Jr> is it just me, or is BIP 113 a hardfork deployed as a softfork? :|
 20 2015-11-01 18:36:55 <sipa> Luke-Jr: hmm!
 21 2015-11-01 18:37:07 <sipa> Luke-Jr: i'm inclined to think you are right
 22 2015-11-01 18:37:44 <sipa> a transaction whose timestamp is between blocktime and blockmedianpasttime will be accepted past bip113, and not accepted before
 23 2015-11-01 18:38:35 <Luke-Jr> I can't think of a way to fix this.
 24 2015-11-01 18:39:17 <Luke-Jr> without destroying the usefulness
 25 2015-11-01 18:42:11 <rusty> sipa: can't it be fixed statistically, by adding 12 hours to blockmeadianpasttime for the comparison?
 26 2015-11-01 18:44:36 <sipa> rusty: that would mean that a 12 hour interval between two blocks could result in an irreconcilable fork?
 27 2015-11-01 18:44:44 <sipa> rusty: not sure that is acceptable
 28 2015-11-01 18:44:51 <rusty> sipa: as I said, "statistically" avoided :)
 29 2015-11-01 18:45:07 <sipa> rusty: worst cases matter, not averages :)
 30 2015-11-01 18:45:24 <rusty> sipa: at some offset, the tradeoff may become acceptable.
 31 2015-11-01 18:45:53 <sipa> i don't think a miner-triggerable condition that forks the network is acceptable under any condition
 32 2015-11-01 18:45:56 <rusty> sipa: you could soft fork in a requirement that blocks be < some value apart.
 33 2015-11-01 18:46:39 <sipa> rusty: that's even scarier...
 34 2015-11-01 18:47:03 <rusty> sipa: not really, you're always allowed to produce blocks in the past.
 35 2015-11-01 18:47:25 <sipa> fair enough
 36 2015-11-01 18:47:48 <sipa> though it interferes with the network's ability to adjust difficulty correctly
 37 2015-11-01 18:49:09 <rusty> sipa: not as much as the factor of 4 clamp does, in the case where we're producing one block every 12 hours!
 38 2015-11-01 18:49:28 <sipa> yes, they're all edge cases
 39 2015-11-01 18:51:50 <rusty> sipa: 12 hours gives a 0.99999385 prob of finding a block.  Over 100 years, that's almost certain to happen though.  Need more than 12 hours then.
 40 2015-11-01 18:52:39 <sipa> rusty: i don't care about averages :)
 41 2015-11-01 18:53:06 <Luke-Jr> would it screw up difficulty that much, if the subsequent miners continued to pull it forward until it caught up?
 42 2015-11-01 18:53:09 <sipa> rusty: if mining was purely random, you would be right
 43 2015-11-01 18:53:19 <rusty> sipa: but yeah, it's a mess.  Luke-Jr, nice spotting.
 44 2015-11-01 18:53:22 <sipa> rusty: but mining is controlled by economic incentives
 45 2015-11-01 18:53:49 <sipa> you could use std::max(nBlockTime, GetMedianTimePast() + 12 hours) or so
 46 2015-11-01 18:54:30 <Luke-Jr> not sure that solves the problems BIP 113 wants to solve
 47 2015-11-01 18:54:54 <Luke-Jr> hm, maybe
 48 2015-11-01 18:55:38 <Luke-Jr> in the meantime, we have merged mempool-only BIP 113. is this going to create invalid blocks?
 49 2015-11-01 18:55:45 <sipa> no
 50 2015-11-01 18:55:52 <sipa> oh, it could
 51 2015-11-01 18:55:54 <rusty> Luke-Jr: yes.
 52 2015-11-01 18:55:58 <sipa> we should revert
 53 2015-11-01 18:56:05 <Luke-Jr> except for the validity check in GBT I guess
 54 2015-11-01 18:56:07 <sipa> Luke-Jr: can you comment on the PR?
 55 2015-11-01 18:56:14 <Luke-Jr> yeah
 56 2015-11-01 18:56:22 <rusty> "this bitcoin stuff is hard"
 57 2015-11-01 18:56:51 <sipa> using std::max(nBlockTime, GetMedianTimePast() + 12 hours) will under non-adverserial conditions solve the problem in 0.99999385% of the cases :)
 58 2015-11-01 18:57:22 <sipa> and in other cases degenerate into current behaviour
 59 2015-11-01 18:57:29 <sipa> without forking
 60 2015-11-01 18:58:05 <rusty> sipa: note that I pulled the 12 hour number out of my nether regions.  There may be a better value...
 61 2015-11-01 18:58:22 <sipa> of course
 62 2015-11-01 18:58:59 <Luke-Jr> (I'm glad this isn't the same 'softfork' hearn was saying "should be" a hardfork..)
 63 2015-11-01 19:01:36 <rusty> Luke-Jr: it's a hardfork conspiracy!
 64 2015-11-01 19:02:52 <jtimon> wumpus: ping #6068, should I rebase or close ?
 65 2015-11-01 19:08:34 <jtimon> re bip113 well, I think the "simplest" solution then it's deploy it as a hardfork, it's still something uncontroversial
 66 2015-11-01 19:09:03 <jtimon> that may delay it's deployment though
 67 2015-11-01 19:18:13 <gmaxwell> I just tuned into the channel to suggest what sipa was wuggesting with the max().
 68 2015-11-01 19:18:52 <gmaxwell> but thats a little unfortunate because it does slide the times people are using further out.
 69 2015-11-01 19:19:25 <sipa> well you can use max(blocktime, getmediantimepast() + 1 hour), which on average has very little effect
 70 2015-11-01 19:19:36 <Luke-Jr> well, we could alternatively redefine nLockTime to use epoch different by 86400 :P
 71 2015-11-01 19:19:50 <sipa> but it will in 50% of the cases fail to result in bip113's intended goal
 72 2015-11-01 19:21:26 <gmaxwell> yea, I was thinking 1 hour but thinking that it will have the effect of not ending sniping.
 73 2015-11-01 19:22:16 <Luke-Jr> brb
 74 2015-11-01 19:23:50 <gmaxwell> jtimon: 113 is a very mild improvement, as a hardfork it is not worth doing at all.
 75 2015-11-01 19:28:37 <Luke-Jr> gmaxwell: well, could throw it in with some other hardfork
 76 2015-11-01 19:31:30 <rusty> I'd prefer we produce a scale of impact, rather than simplifying to hard vs soft forks.  ie. who gets effected, and how badly.
 77 2015-11-01 19:31:36 <gmaxwell> It would need to be 12 or 24 hours;  +1hour as the property that realtime+2 hours almost always snipes.
 78 2015-11-01 19:32:58 <gmaxwell> Fine. It is not worth a flag day update where every developer of bitcoin node software and every user of  bitcoin node software must update their software or no longer participate on the network.
 79 2015-11-01 19:33:25 <gmaxwell> Enforcement of lowS nearly ended armory.
 80 2015-11-01 19:37:14 <Lightsword> gmaxwell, any insight into what’s been going on with armory? They dropped OSX support on a bug fix release even…which seems a bit crazy since it doesn’t look like they even changed any of the dependencies, I was able to get it to compile at least with a few minor tweaks to the build system and PR’d those.
 81 2015-11-01 19:38:01 <Luke-Jr> it's hard to build for OS X without using OS X :/
 82 2015-11-01 19:38:12 <Lightsword> Luke-Jr, that was my guess....
 83 2015-11-01 19:38:28 <gmaxwell> Lightsword: my understanding was that it was almost unusable on OSX in any case?
 84 2015-11-01 19:38:29 <Lightsword> but you would think they would have access to at least one OSX box
 85 2015-11-01 19:38:44 <Lightsword> gmaxwell, I haven’t really had any issues with it
 86 2015-11-01 19:39:09 <gmaxwell> Lightsword: ah, I'd heard reports that parts of the UI were unclickable and such, or displayed impossibly small, on OSX.
 87 2015-11-01 19:39:22 <jtimon> gmaxwell: I was assuming putting it with other small improvements or schedule it far away in the future
 88 2015-11-01 19:39:35 <Lightsword> gmaxwell, some of the earlier releases had been a little buggy but nothing all that bad
 89 2015-11-01 19:40:06 <gmaxwell> jtimon: the motiviation for doing it now, however, is that MTP will change the times people are using on transactions, which has an influence on how CLTV applications are constructed.
 90 2015-11-01 19:40:07 <Lightsword> 0.93.2 was fine for the most part until we hit the Low-S issue
 91 2015-11-01 19:40:21 <Lightsword> 0.93.3 that I compiled myself also seems to be ok
 92 2015-11-01 19:41:30 <gmaxwell> Lightsword: In any case, I don't really have much insight that the public doesn't. People are not spending time maintaining it.  I'd offered them to fix their lowS behavior myself, but they said they had a release in the works.  Really the lowS fix itself is probably less work for them than producing a release.
 93 2015-11-01 19:42:05 <jtimon> gmaxwell: I see, by the time you could deploy it, the CLTV, CSV related software will already be made to work without it and it won't be worth it
 94 2015-11-01 19:42:19 <gmaxwell> jtimon: what? no
 95 2015-11-01 19:42:27 <jtimon> does bip68/112 depend on bip113 ?
 96 2015-11-01 19:42:45 <gmaxwell> no. they have nothing to do with it.
 97 2015-11-01 19:43:02 <sipa> bip68 does
 98 2015-11-01 19:43:11 <sipa> bip112 does not
 99 2015-11-01 19:43:44 <jtimon> well, the way I see it bip112 depends on bip68, so...
100 2015-11-01 19:44:21 <gmaxwell> oh I forget that 68 also supported relative time.
101 2015-11-01 19:44:26 <Lightsword> gmaxwell, yeah, sounds like they just haven’t been keeping up on doing releases, I think they have been mainly focusing on enterprise work, are there any decent high-security HD full node wallets other than armory at this point?
102 2015-11-01 19:44:35 <gmaxwell> In any case the "dependency" isn't real.
103 2015-11-01 19:45:29 <gmaxwell> jtimon: Software can't "be made to work without it"; it's an incentives problem for miners that you can't simply work around.
104 2015-11-01 19:45:33 <jtimon> the question is rather, even if we forget about bip113 completely, we can just move on with bip68/112, right?
105 2015-11-01 19:45:56 <gmaxwell> if time based locktimes are widely used, and there are lots of fees to be collected in mining them, miners are constantly incentivized to push their time forward to pick them up.
106 2015-11-01 19:46:49 <jtimon> gmaxwell: oh, yeah, I remember now. then I don't see why it couldn't eventually be deployed as a hardfork...
107 2015-11-01 19:47:30 <gmaxwell> jtimon: yes, it's not 'needed' for 68/112's operation.  But it is needed for the health of the network in the presence of widespread time based locktime use; and it's much easier to deploy a MTP fix when there isn't yet widespread locktime use, because it will require changes to locktime user behavior.
108 2015-11-01 19:48:32 <jtimon> yeah, that's what I meant earlier, minus it will always be worth it (just much more costly)
109 2015-11-01 19:48:40 <gmaxwell> jtimon: because unless severely bad things are happening already it would be hard to justify flagdaying all the deployed stuff.  (which may, e.g. include HSMs that cannot be updated but must be replaced and all kinds of other fun things)
110 2015-11-01 19:50:30 <jtimon> so what you are saying is that either the problem gets fixed soon as a softfork or will likely never be solved ?
111 2015-11-01 19:51:07 <gmaxwell> No, I'm saying that it needs to be fixed soon as a soft fork or the eventual solving will be disruptive, and may involve funds loss for people.
112 2015-11-01 19:51:37 <jtimon> ok, gotcha, thanks
113 2015-11-01 19:52:00 <gmaxwell> or actually, that it needs to be addressed in IsStandard soon, or the eventual fix will increase in its disruptiveness as adoption of CLTV increases.
114 2015-11-01 19:52:17 <gmaxwell> but that can't be done if we don't know the eventual behavior.
115 2015-11-01 19:55:12 <gmaxwell> in any case, I don't see any real option for the moment except to back out that change.
116 2015-11-01 19:55:40 <jtimon> yep, I was just wondering, what to do after that
117 2015-11-01 19:56:05 <gmaxwell> I think we should do the +N hours max offset thing but it deserves more consideration than a few minutes impression.
118 2015-11-01 19:57:26 <btcdrak> ouch, nice catch Luke-Jr!