1 2015-11-13 00:58:52 <jtimon> sipa: "estimation unfortunately relies on knowing other's policies", not necessarily, we shouldn't make assumption's about the input requirements or sophistication of policies at all
  2 2015-11-13 01:00:43 <jtimon> there are concieable policies that don't rely on knowing other's policies (ie random policy, which will be included in bitcoin JT0.12)
  3 2015-11-13 01:01:06 <phantomcircuit> jtimon, you have to make some kind of guess about what the miners average policy is
  4 2015-11-13 01:02:25 <jtimon> phantomcircuit: ?
  5 2015-11-13 01:03:46 <phantomcircuit> jtimon, randomly selecting transactions as policy has some pretty comical negative side effects :P
  6 2015-11-13 01:04:11 <jtimon> I think of a policy interface that returns true or false with each call (with cute error strings in validationState when false, analogous to libconsensus)
  7 2015-11-13 01:04:37 <sipa> jtimon: sure, but that doesn't mean that you do a good fee estimation if miners adopt it
  8 2015-11-13 01:05:29 <sipa> jtimon: if everyone adopted their own policies of various kinds, of various complexity, and of varying competence... fee estimation would be pretty useful
  9 2015-11-13 01:05:46 <sipa> *useless
 10 2015-11-13 01:05:54 <jtimon> phantomcircuit: no denial, but I claim that the trivial implementation of a random policy is a good signal of a good encapsulation and potentially also interesting for testing
 11 2015-11-13 01:06:42 <sipa> jtimon: i think we're talking about different things
 12 2015-11-13 01:07:16 <sipa> jtimon: what encapsulation a miner uses for its policy interface implementation has nothing to do with how well others can estimate their parameters
 13 2015-11-13 01:07:40 <jtimon> sipa: of course I don't expect miners to adopt a random policy, at most use it as a template for their own policy that maybe extends default policy (but doesn't need to)
 14 2015-11-13 01:08:09 <sipa> jtimon: i'm just saying that the less you know about other's policies, the worse fee estimation will work
 15 2015-11-13 01:08:30 <sipa> jtimon: that's not a reason against having configurable policies... just an unfortunate side effect
 16 2015-11-13 01:08:45 <jtimon> the first random policy in bitcoin jt will be unfortunately limited to 3 functions
 17 2015-11-13 01:08:53 <jtimon> in policy/policy
 18 2015-11-13 01:11:08 <jtimon> I don't know anything about any policy, I just know about existing code in bitcoin core that could be put together and encapsulated (sound similar but it's not the same) in the policy dir
 19 2015-11-13 01:13:26 <sipa> jtimon: i don't really believe in good encapsulation for policy; what you can call policy is defined by the logic that calls it
 20 2015-11-13 01:13:33 <jtimon> I know it's currently trivial to do so from master (of course with very limited policy functionality) so jt0.12 will have it, but let's stop advertising my personal software fork
 21 2015-11-13 01:13:53 <sipa> yes, i know it's possible in the current code
 22 2015-11-13 01:14:01 <jtimon> then you don't believe encapsulation is generally good
 23 2015-11-13 01:14:11 <sipa> i'm sure it's also possible in the final 0.12 code, but perhaps in a completely different way
 24 2015-11-13 01:14:53 <jtimon> I'm not asking for this to be included in 0.12
 25 2015-11-13 01:15:36 <sipa> i guess maybe encapsulation isn't the word to use; but i don't think it can be a stable interface
 26 2015-11-13 01:15:53 <sipa> policy is just whatever is left to configure in a sane way after implementing the logic
 27 2015-11-13 01:16:14 <sipa> if that logic now allows replacement, fine, your policy may need means to configure what is replacable
 28 2015-11-13 01:16:33 <jtimon> it's just a branch, like petertodd did with full RBF for a while (btw, will he keep doing it after optin RBF?)
 29 2015-11-13 01:17:13 <sipa> whatever policy configuration you want, it will break
 30 2015-11-13 01:17:14 <jtimon> well, certainly it cannot be stable now
 31 2015-11-13 01:17:17 <sipa> ok,
 32 2015-11-13 01:17:35 <sipa> then i think it's a distraction to work on it
 33 2015-11-13 01:18:26 <jtimon> that's why I closed my only remaining policy-encapsulation PR at least until 0.12
 34 2015-11-13 01:22:26 <sipa> ok
 35 2015-11-13 01:23:10 <jtimon> but after 0.12 I'm going to try restore some of the policy encapsulation work I continued and improved from luke in my latest abandoned longest branch, maybe it will not have minrelayfee as policy option yet, but isdust and other globals can turn into DefaultPolicy attributes
 36 2015-11-13 03:07:13 <dcousens> Anyone here recommend any libraries to analyze the blockchain?
 37 2015-11-13 03:11:09 <dcousens> my fastest parsers still takes ~25s to parse the entire chain atm
 38 2015-11-13 03:11:23 <dcousens> mostly IO bound tho :/
 39 2015-11-13 03:25:29 <phantomcircuit> dcousens, 25 seconds to load 50+GB of data is pretttty good
 40 2015-11-13 03:26:18 <dcousens> phantomcircuit: I remember reading people were saying they had it under 10s? Was that just on a 2014 chain haha
 41 2015-11-13 03:26:29 <phantomcircuit> yes...
 42 2015-11-13 03:26:45 <dcousens> Well, I guess I'll leave my 25s alone then :S
 43 2015-11-13 06:09:13 <csoria> hello
 44 2015-11-13 06:15:36 <csoria> got one question about the script, someone can help me out?
 45 2015-11-13 07:48:46 <dcousens> hmph, 7minutes for a UTXO parse and dump, not the worst :D
 46 2015-11-13 10:38:22 <matsjj_> anyone got site for me where I can view the raw transaction in testnet?
 47 2015-11-13 10:38:27 <matsjj_> in hex
 48 2015-11-13 10:47:12 <flyingkiwi> matsjj_, https://testnet.manu.backend.hamburg/memorypool ?
 49 2015-11-13 10:49:33 <flyingkiwi> matsjj_, and I've found this endpoint: http://tbtc.blockr.io/api/v1/tx/raw/<txid>
 50 2015-11-13 10:49:50 <matsjj_> flyingkiwi: the last one looks perfect, thanks!
 51 2015-11-13 12:15:27 <venzen> good to hear
 52 2015-11-13 12:15:45 <venzen> please ignore ^, wrong window
 53 2015-11-13 12:27:59 <Yoghur114> @matsjj_ http://srv4.yogh.io/testnet/
 54 2015-11-13 13:23:38 <matsjj_> just tried making a transaction with OP_CSV on the testnet (currently OP_NOP2, 0xB2), but it's not getting mined (without just that, it is working fine) ... Shouldn't it work on testnet?
 55 2015-11-13 13:25:42 <matsjj_> It even was in a P2SH redeemscript
 56 2015-11-13 13:27:40 <sipa_> matsjj_: assuming testnet miners have bip112 merged
 57 2015-11-13 13:27:52 <sipa_> which isn't even merged in master
 58 2015-11-13 13:34:41 <matsjj_> sipa_, I'm not asking for a fully functional OP_CSV ;) I just thought that OP_NOP2 should be included (even in mainnet)
 59 2015-11-13 13:35:11 <sipa_> matsjj_: no, unused opcodes are one of the few things that are not accepted, even when isstandard checks are disabled
 60 2015-11-13 13:35:24 <sipa_> matsjj_: otherwise we'd have forking risks around the time a softfork that includes them activates
 61 2015-11-13 13:37:10 <matsjj_> sipa_, thank you for clarifying, makes indeed perfectly sense! Should probably be listed as 'Disabled' in the wiki then?
 62 2015-11-13 13:37:47 <sipa_> no, from the consensus rules' point of view they exist
 63 2015-11-13 13:38:05 <matsjj_> oh, so miners not including it is just a policy then
 64 2015-11-13 13:38:21 <sipa_> yes
 65 2015-11-13 13:38:40 <sipa_> if those opcodes were actually invalid to use, a softfork couldn't change their meaning anymore
 66 2015-11-13 13:38:49 <matsjj_> riiight, of course
 67 2015-11-13 13:39:03 <sipa_> it's a policy that's enabled even on testnet even, one of the few
 68 2015-11-13 13:39:35 <matsjj_> Hm. I guess anyone can mine these anyway, but why is it enabled there?
 69 2015-11-13 13:40:09 <sipa_> because they're not implemented using the IsStandard logic, but as a script validation flag that's passed down
 70 2015-11-13 13:40:17 <sipa_> no real reason why they would be
 71 2015-11-13 13:41:11 <matsjj_> Hm I see... would be handy for testing though
 72 2015-11-13 13:42:54 <matsjj_> Is it documented at least somewhere? ;)
 73 2015-11-13 16:23:11 <mr_burdell> I'm getting build errors with v0.11.2 tag: http://pastebin.com/4u9EXVKW
 74 2015-11-13 16:28:28 <wumpus> mr_burdell: clean your tree and re-run autogen.sh and configure
 75 2015-11-13 16:30:10 <mr_burdell> ah, ok... i guess there were left over files that git didn't handle
 76 2015-11-13 16:30:17 <mr_burdell> it's building now
 77 2015-11-13 16:30:20 <mr_burdell> thanks
 78 2015-11-13 17:05:29 <btcdrak> matsjj_: you can test CSV with sequencenumbers using by combined branch https://github.com/btcdrak/bitcoin/tree/sequenceandcsv
 79 2015-11-13 18:17:10 <nan`> hello. Why does bitcoin need merkle trees? Why could it no just hash all of the transactions for the block?
 80 2015-11-13 18:18:07 <sipa> nan`: it allows for very small proofs that a particular transaction is in a block
 81 2015-11-13 18:18:11 <wumpus> because merkle trees allow for compact proof that a transaction is in a block, by passing the hashes along the tree path
 82 2015-11-13 18:18:53 <nan`> hm. Thank you wumpus, sipa. I will look into that. Any refs for the proof?
 83 2015-11-13 18:19:07 <sipa> nan`: any light wallet client :)
 84 2015-11-13 18:19:15 <nan`> ok
 85 2015-11-13 18:19:16 <sipa> nan`: see BIP37
 86 2015-11-13 18:19:42 <sipa> though that's not the simplest form of the proof
 87 2015-11-13 18:20:21 <sipa> nor very understandably explained there
 88 2015-11-13 18:22:25 <nan`> did it always use merkle trees or were they thought of later
 89 2015-11-13 18:22:50 <nan`> their use thought of later, that is
 90 2015-11-13 18:23:00 <wumpus> https://bitcoin.org/en/developer-guide#term-merkle-tree
 91 2015-11-13 18:23:13 <wumpus> it was used in block headers since the beginning
 92 2015-11-13 18:32:59 <jtoomim> sipa what is the current status of libsec256k1? is it still used only for transaction signing?
 93 2015-11-13 18:33:36 <sipa> see #6954
 94 2015-11-13 18:33:40 <jtoomim> ok
 95 2015-11-13 18:35:58 <petertodd> jtimon: yes, I'll keep publishing a full-RBF w/o opt-in branch (and with preferential peering) until full-RBF w/o opt-in is the default in Bitcoin Core (or you don't need preferential peering to get your full-RBF txs to miners)
 96 2015-11-13 21:08:09 <midnightmagic> sigh. Still failing to match linux gitian sigs.
 97 2015-11-13 21:16:43 <midnightmagic> v0.10.3rc2 ..
 98 2015-11-13 21:52:26 <Kireji> 0.11.2 release, linux 64 bit from https://bitcoin.org/bin/bitcoin-core-0.11.2/bitcoin-0.11.2-linux64.tar.gz has a soft link in the root of the tar directory "bitcoin-0.11.2 -> ./bitcoin-0.11.2/"
 99 2015-11-13 21:52:47 <Kireji> I think that's a mistake
100 2015-11-13 22:40:26 <jtoomim> who is running the BIP65/v4 block tests on testnet? I'd like to coordinate our tests with them to avoid stepping on their toes.
101 2015-11-13 22:48:14 <Luke-Jr> jtoomim: in what sense? stepping on toes seems like a useful test :P
102 2015-11-13 22:50:23 <Luke-Jr> Kireji: I don't see it
103 2015-11-13 22:50:30 <jtoomim> luke-jr: in the sense that it might result in escalating hashrate
104 2015-11-13 22:50:37 <morcos> jtoomim: i was doing some mining on testnet today with master, but don't feel comfortable leaving my GreenIsMyPepper paper-clip special plugged in over the weekend, so its all you now
105 2015-11-13 22:51:01 <jtoomim> ok
106 2015-11-13 22:51:06 <Luke-Jr> jtoomim: aren't you testing BIP101 anyway? once you get a >1MB block, nothing you do can mess up the main chain
107 2015-11-13 22:51:09 <morcos> i probably wasn't the only one though
108 2015-11-13 22:51:11 <jtoomim> last time i checked, difficulty was kinda high (400k ish)
109 2015-11-13 22:51:17 <jtoomim> should we timewarp and get it down a bit?
110 2015-11-13 22:52:02 <jtoomim> luke-jr yes, but i don't leave it forked all the time
111 2015-11-13 22:52:14 <jtoomim> i want to test borderline hashrate scenarios if i get a chance
112 2015-11-13 22:52:43 <jtoomim> and i also want to bring the v3/v4 chains back up to overtake BIP101 every now and then so we can fork again
113 2015-11-13 22:52:52 <jtoomim> maybe i'm addicted to forks. i should try spoons sometime.
114 2015-11-13 22:53:02 <Luke-Jr> sounds like the escalating hashrate does just that?
115 2015-11-13 22:53:18 <jtoomim> but escalating hashrate costs other people money
116 2015-11-13 22:53:26 <jtoomim> i see no reason to cost money
117 2015-11-13 22:53:48 <jtoomim> chaos is great and all, but chaos on testnet can be free
118 2015-11-13 22:54:16 <Luke-Jr> :p
119 2015-11-13 22:54:42 <Luke-Jr> when it comes to mining, the money they're costed, is money someone else is making ;)
120 2015-11-13 22:55:00 <Luke-Jr> (ok, maybe not if they're using obsolete hardware)
121 2015-11-13 22:55:14 <jtoomim> i'm a bit of a newbie with timewarping, though. i just realized it could be done a few days ago (is there any documentation of it?) and i'm not sure i understand everything correctly
122 2015-11-13 22:55:31 <jtoomim> so you go forward 20 minutes, go forward 20 minutes again, then go back and forward 20 minutes indefinitely, right?
123 2015-11-13 22:55:51 <jtoomim> and the difficulty is recalculated based on the work done, which will be low with diff 1 blocks?
124 2015-11-13 23:12:47 <jtoomim> oh, it looks like we just forked
125 2015-11-13 23:13:05 <jtoomim> http://ml.toom.im/
126 2015-11-13 23:13:05 <jtoomim> i wasn't paying enough attention
127 2015-11-13 23:30:55 <jtoomim> and our blocks got orphaned, as we don't have enough hashrate
128 2015-11-13 23:31:15 <jtoomim> i guess this is the borderline hashrate scenario already