1 2015-11-25 01:17:09 <kenrestivo> just for giggles, i'm trying to crosscompile bitcoind for arm. i'm getting this failure: "configure: error: libdb_cxx missing" but that library is very much present in /usr/lib/libdbd_cxx.so (as a symlink)
  2 2015-11-25 01:17:33 <kenrestivo> my args are ./configure --with-gui=no --with-incompatible-bdb --host=arm-linux-gnueabihf
  3 2015-11-25 01:19:10 <Luke-Jr> kenrestivo: headers?
  4 2015-11-25 01:19:57 <Luke-Jr> kenrestivo: also.. you can't use native libs for cross-compiling..
  5 2015-11-25 01:22:23 <kenrestivo> oh, of course. i have to look into installing all the build dependencies in arm architecture, i forgot to do that. thanks.
  6 2015-11-25 01:34:11 <kenrestivo> nice. though it still gets confused, i.e.
  7 2015-11-25 01:34:14 <kenrestivo> checking whether the Boost::System library is available... yes
  8 2015-11-25 01:34:26 <kenrestivo> configure: error: Could not find a version of the boost_system library!
  9 2015-11-25 01:34:50 <kenrestivo> well configure, make up your mind. is it ... yes? or is it "Could not find". fwiw, the library is there, in armhf arch
 10 2015-11-25 05:24:49 <Fistful_of_Coins> has the sidechain proposal test version source been released?
 11 2015-11-25 05:26:03 <phantomcircuit> Fistful_of_Coins, elements project alpha
 12 2015-11-25 05:26:16 <phantomcircuit> there was a whole press release and everything...
 13 2015-11-25 05:27:49 <Fistful_of_Coins> awesome, thanks, ya i remember hearing about it but i couldn't find it.
 14 2015-11-25 10:22:37 <jtimon> regarding SPV nodes and schism hardforks...it would be nice to have a way to signal that a schism hardfork is happening
 15 2015-11-25 10:23:05 <jtimon> previously the block version could be used, but not after versionbits
 16 2015-11-25 10:23:53 <jtimon> and schism hardforks have no miner upgrade confirmation, so they shouldn't use versionbits
 17 2015-11-25 10:24:03 <jtimon> mhmm
 18 2015-11-25 10:24:59 <sipa> you can still "demand" that the first split-off block is invalid according to the old rules
 19 2015-11-25 10:25:12 <sipa> for example by setting block version = 0
 20 2015-11-25 10:25:21 <sipa> which is invalid according to bip34
 21 2015-11-25 10:25:49 <jtimon> sipa: but that conflicts with versionbits, what if some uncontroversial softforks were being deployed at the same time?
 22 2015-11-25 10:26:18 <sipa> a hard fork can change all those rules
 23 2015-11-25 10:26:33 <jtimon> making sure the first split-off block is invalid according to the old rules may not be something visible to SPV nodes
 24 2015-11-25 10:27:29 <jtimon> sipa yes they can, but if the softforks were truly uncontroversial, the creators of the schism hardfork don't want to stop those
 25 2015-11-25 10:28:01 <sipa> so they can add a rule that the schism itself is ignored for the purpose of bip9
 26 2015-11-25 10:28:22 <jtimon> ?? they don't want to ignore the hardfork they create
 27 2015-11-25 10:29:12 <sipa> for the purpose of bip9, the first block on the forked off chain is ignored
 28 2015-11-25 10:29:24 <sipa> and only that block gets a vereion=0
 29 2015-11-25 10:29:34 <jtimon> oh, I see
 30 2015-11-25 10:29:48 <sipa> or even better, bip9 only looks at the lower 28 bits, i think
 31 2015-11-25 10:30:23 <sipa> it could just be required that in the schism, the high bit of version is set (so it looks like negative numbers to old clients)
 32 2015-11-25 10:30:38 <jtimon> yes, I was thinking about using some part of the version to signal a schism hardfork for X blocks, but as you say just one block may be enough
 33 2015-11-25 10:30:56 <tulip> huh, the block version number is signed?
 34 2015-11-25 10:31:02 <jtimon> sipa, yes, that looks even better
 35 2015-11-25 10:31:04 <sipa> tulip: unfortunately, yes
 36 2015-11-25 10:31:23 <sipa> tulip: and bip34 wiped out half of the available space as a result :)
 37 2015-11-25 10:31:46 <jtimon> sipa thanks, I will include that recommendation in the schism hardfork section of bip99
 38 2015-11-25 10:32:14 <sipa> jtimon: a new schism after that could undo it :)
 39 2015-11-25 10:32:16 <tulip> sipa: that's truly bizarre, I wasn't aware of that facet.
 40 2015-11-25 10:32:54 <jtimon> that should prevent "innocent bystanders" from getting hurt (assuming that the creators of the schism hardfork don't want to hurt bystanders)
 41 2015-11-25 10:34:50 <jtimon> sipa: yes, a schism hardfork even with 100% of the hashpower can be undone by users with another schism hardfork: an ASIC-reset one (changing pow), that's what I'm trying to explain to rusty, gavinandresen and peter R (although that thread was moderated to bitcoin-discuss)
 42 2015-11-25 10:35:31 <jtimon> where they insist one disagreeing with me on whether people can disagree undefinitely or not
 43 2015-11-25 10:35:43 <jtimon> ironically enough
 44 2015-11-25 10:36:51 <jtimon> s/insist one/insist on/
 45 2015-11-25 10:46:10 <rusty> sipa: a single block with weird version would be in the noise anyway for BIP9.
 46 2015-11-25 10:49:50 <aj> jtimon: (re: "disagree indefinitely" -- nice ;)
 47 2015-11-25 11:00:58 <jtimon> rusty but the version implementing the schism hardfork can make bip9 ignore the negative version block
 48 2015-11-25 11:01:19 <rusty> jtimon: I'm saying don't bother.
 49 2015-11-25 11:01:26 <jtimon> s/version implementing/ruleset implementing
 50 2015-11-25 11:02:14 <rusty> jtimon: an unknown block version counts as a vote against, but you still need 99 other votes against.
 51 2015-11-25 11:02:21 <jtimon> rusty: not bother and let SPV nodes not know whether they are following a chain with the old rules or a chain with a hardfork change to the rules?
 52 2015-11-25 11:02:53 <jtimon> rusty: there's no notion of "voting" (aka miner upgrade confirmation) for schism hardforks
 53 2015-11-25 11:02:56 <rusty> jtimon: no, I mean, don't take it into account when calculating BIP9 states.
 54 2015-11-25 11:03:41 <jtimon> well, usually you will reject a chain with a negative block version (but the schism hardfork can allow that versioning for one block)
 55 2015-11-25 11:04:38 <rusty> jtimon: sure, but that's not a BIP9 issue.  BIP9 will already ignore the version if it's not b001...
 56 2015-11-25 11:04:43 <jtimon> but I see what you are saying, you mean the voting of the softforks
 57 2015-11-25 11:05:12 <sipa> rusty, jtimon: i think you're talking past each other
 58 2015-11-25 11:05:22 <jtimon> rusty: yep, this is a BIP99 issue, a recommendation for deploying schism hardforks in a way that spv users can notice
 59 2015-11-25 11:05:55 <rusty> jtimon: Yes.  BIP9 != BIP99 :)
 60 2015-11-25 11:06:01 <jtimon> yes
 61 2015-11-25 11:06:25 <jtimon> but bip99 mentions and assumes bip9
 62 2015-11-25 11:07:16 <jtimon> do you disagree with the recommendation?
 63 2015-11-25 11:07:59 <rusty> I think BIP9 doesn't care about a single block, and it's not worth the (admittedly minor) complexity of fixing it?
 64 2015-11-25 11:08:47 <sipa> i think the recommendation should be just "an intentional hard fork should be made inacceptable to old nodes, including those that only verify headers"
 65 2015-11-25 11:09:11 <sipa> it's not hard to come up with ways to accomplish that, even in a BIP9 world
 66 2015-11-25 11:09:22 <rusty> sipa: does that apply even if the hard fork would otherwise not effect SPV nodes?
 67 2015-11-25 14:07:15 <bedeho> is OP_CHECKLOCKTIMEVERIFY actually in production now?
 68 2015-11-25 14:12:41 <jonasschnelli> bedeho: it's available, but the softfork has not triggered yet. 365/1000
 69 2015-11-25 14:13:54 <jonasschnelli> maybe sipa has somewhere a v4 blocks evolution chart
 70 2015-11-25 14:15:28 <sipa> http://bitcoin.sipa.be/ver-50k.png
 71 2015-11-25 14:19:46 <bedeho> jonasschnelli, sipa : thanks
 72 2015-11-25 14:36:52 <bedeho> jonasschnelli, sipa : any feeling on how long that is likely to take to get enough support (bip65)?
 73 2015-11-25 14:37:48 <jonasschnelli> bedeho: very hard to say...
 74 2015-11-25 14:37:58 <jonasschnelli> depends on how fast miners are upgrading...
 75 2015-11-25 14:39:30 <bedeho> I see, well I have a paychan implementation Id like to switch over to using checklocktimeverify to avoid malleability, so trying to guague when it will be widely available.
 76 2015-11-25 14:40:12 <sipa> bedeho: you need 95% adoption to be certain
 77 2015-11-25 14:40:44 <bedeho> seems like there was a big spike in acks in mid November, would it be fair to say that this rate of turnover is likely to last?
 78 2015-11-25 14:40:44 <sipa> could take days, or months
 79 2015-11-25 14:40:51 <bedeho> months :/
 80 2015-11-25 14:42:50 <sipa> bip34 and bip66 took months
 81 2015-11-25 14:43:37 <sipa> see http://bitcoin.sipa.be/ver-ever.png
 82 2015-11-25 14:47:46 <sturles> What is the difference between activation and enforcement?
 83 2015-11-25 14:48:34 <sipa> activation = the rule is active (so blocks won't be accepted that violate the new rule)
 84 2015-11-25 14:48:48 <sipa> enforcement is a point of no return
 85 2015-11-25 14:48:53 <sipa> the name is confusing, agreed
 86 2015-11-25 14:51:41 <kanzure> servo has an interesting strategy for onboarding new contributors by leaving open easy-to-fix bugs https://news.ycombinator.com/item?id=10627095
 87 2015-11-25 14:52:18 <bedeho> sipa, so what is enforcement? not sure I understood the distinction
 88 2015-11-25 14:53:45 <sipa> bedeho: after 95%, all future blocks are required to be v4, so the rule can't go back to deactivated if miners would back out
 89 2015-11-25 15:03:08 <bedeho> sipa, had to think about that one, but think I get it now, the point is that activation can be temporary? it can dip down again and potentially never recover
 90 2015-11-25 15:04:25 <sipa> yes
 91 2015-11-25 15:04:44 <sipa> it can also just randomly flap due to statistical variance
 92 2015-11-25 17:15:37 <Technocrat7> Question: Where did the first bitcoin came from and how was it distributed?
 93 2015-11-25 17:15:47 <Technocrat7> come*
 94 2015-11-25 17:16:29 <btcdrak> Technocrat7: subject for #bitcoin
 95 2015-11-25 20:39:13 <jgarzik> 2015-11-25 20:38:40 tor: Disconnected from Tor control port 127.0.0.1:9051, trying to reconnect
 96 2015-11-25 20:39:13 <jgarzik> 2015-11-25 20:38:48 tor: Disconnected from Tor control port 127.0.0.1:9051, trying to reconnect
 97 2015-11-25 20:39:13 <jgarzik> 2015-11-25 20:38:59 tor: Disconnected from Tor control port 127.0.0.1:9051, trying to reconnect
 98 2015-11-25 20:39:21 <jgarzik> $ telnet localhost 9051
 99 2015-11-25 20:39:21 <jgarzik> telnet: Unable to connect to remote host: Connection refused
100 2015-11-25 20:39:21 <jgarzik> Trying 127.0.0.1...
101 2015-11-25 20:40:27 <gijensen> rip