1 2016-12-08 03:24:46 <TommyBoy> I've been running bitcoin core for a few months (0.12.0 without down time) and it seems to put a pretty insane transaction fee
  2 2016-12-08 03:24:48 <TommyBoy> Here's the transaction: https://blockchain.info/tx/5a7622902e1e1bdea20e4728a6e2dc210e15636ca5fbe81ab489881531f6882a
  3 2016-12-08 03:24:54 <TommyBoy> That's about 10x what estimatefee says it should use
  4 2016-12-08 03:25:07 <TommyBoy> estimatefee says it should only use 0.00091372 per kb
  5 2016-12-08 03:25:18 <TommyBoy> The transaction is 0.372 kb, so it should use: 0.00033990384 in fees, but it's using 0.00235315
  6 2016-12-08 03:26:45 <achow101> TommyBoy: IIRC estimatefee has been improved in newer versions. You should upgrade to 0.13.1
  7 2016-12-08 03:27:00 <TommyBoy> The problem isn't that estimatefee is wrong, the problem is it's not even using that
  8 2016-12-08 03:27:14 <TommyBoy> It used almost x10 what estimatefee suggested
  9 2016-12-08 03:27:48 <achow101> txid of transaction in question?
 10 2016-12-08 03:27:55 <TommyBoy> Although, I'll update to 0.13.1 now. But it's quite concerning regardless
 11 2016-12-08 03:28:05 <TommyBoy> I linked to it above
 12 2016-12-08 03:28:24 <TommyBoy> 5a7622902e1e1bdea20e4728a6e2dc210e15636ca5fbe81ab489881531f6882a
 13 2016-12-08 03:28:43 <achow101> are you sure that when you sent it was using the dynamic fees?
 14 2016-12-08 03:28:52 <TommyBoy> Yeah
 15 2016-12-08 03:30:12 <TommyBoy> I just made another send, without resetting bitcoin. "5213fcfe8e331cce51c6dd6742723c3267fabe5c788723f000f0c6543ace1cae"
 16 2016-12-08 03:30:15 <TommyBoy> That one is correct fee
 17 2016-12-08 03:30:38 <achow101> that's really weird
 18 2016-12-08 03:31:13 <TommyBoy> I just checked my last 5 transactions (all made within the last hour) and they all have normal fee rates
 19 2016-12-08 03:31:22 <TommyBoy> The only one that doesn't is 5a7622902e1e1bdea20e4728a6e2dc210e15636ca5fbe81ab489881531f6882a
 20 2016-12-08 03:31:32 <TommyBoy> Where that fee rate is 10x what it should be
 21 2016-12-08 03:32:27 <achow101> perhaps you hit some super strange edge case, or you accidentally clicked something that set the fee rate to be different.
 22 2016-12-08 03:32:36 <TommyBoy> No, I used the command line interface
 23 2016-12-08 03:32:46 <TommyBoy> I don't even have the gui installed
 24 2016-12-08 03:32:54 <achow101> which command did you use?
 25 2016-12-08 03:33:42 <TommyBoy> let me grab it from my bash history exactly
 26 2016-12-08 03:34:11 <TommyBoy> bitcoin-cli sendtoaddress 1DeMTAhAoNH2eu4wn9G7vepmXPS8VqUSpj 50
 27 2016-12-08 03:35:39 <achow101> can you post your debug.log somewhere and link to it? there may be some clues in there as to what may have happened
 28 2016-12-08 03:36:58 <TommyBoy> https://gist.github.com/anonymous/5bdbbc6410832cc865303e5b8e21c38d
 29 2016-12-08 03:38:25 <achow101> is that it? There should defintely be more, particularly stuff involving the high fee tx
 30 2016-12-08 03:39:01 <TommyBoy> That's complete
 31 2016-12-08 03:39:30 <TommyBoy> I didn't skip any messages in that timeframe
 32 2016-12-08 03:40:07 <achow101> huh. it should be longer, but if it isn't, oh well. unfortunately I have no idea what happened, so I can't really help you
 33 2016-12-08 03:40:41 <TommyBoy> well i might kill it now, and upgrade to 0.13.1
 34 2016-12-08 03:40:47 <TommyBoy> unless there's something you want me to do before i do that
 35 2016-12-08 03:41:25 <achow101> nah, there isn't anything to do before upgrading
 36 2016-12-08 03:43:01 <TommyBoy> Ok, well running 0.13.1 now
 37 2016-12-08 09:44:29 <BTCgame> Hello guys
 38 2016-12-08 09:48:33 <BTCgame> Is there anyone who using blockchain API? I added ability to check final balance from address, but not sure how to check is the transaction was confirmed or no
 39 2016-12-08 20:39:49 <bsm117532> Given that Bloom filters don't provide any practical privacy benefit, is there any reason I can't set nHashFuncs=1 to search for a specific transaction using BIP37?
 40 2016-12-08 21:12:27 <belcher> bsm117532 you can also send the txid, outpoint or scriptPubKey directly to the other node and not even bother with a filter
 41 2016-12-08 21:12:54 <belcher> iv been working on something similar lately and just did that
 42 2016-12-08 21:13:29 <belcher> filteradd is the p2p command
 43 2016-12-08 21:18:25 <adiabat> bsm117532: the bloom filter provides a *little* privacy
 44 2016-12-08 21:19:42 <adiabat> slightly more obscure than just directly sending the address or txid.  Though yeah in practice it doesn't help much
 45 2016-12-08 21:23:33 <bsm117532> I'm more concerned about taking load off the servers... belcher that's a good idea...
 46 2016-12-08 21:24:11 <bsm117532> I'm also thinking, slightly longer term, about an update to BIP37 that will solve some of its problems...
 47 2016-12-08 21:25:19 <adiabat> The whole bloom filter thing really needs to be fixed...
 48 2016-12-08 21:25:30 <adiabat> there was some discussion of how to do that earlier this year
 49 2016-12-08 21:25:35 <bsm117532> belcher but a getdata will only return the txn, not a Merkle proof for it.
 50 2016-12-08 21:25:52 <adiabat> basically have the fullnode create a filter for the whole block, then return that
 51 2016-12-08 21:26:11 <adiabat> and the lite node can match that filter with their set of addresses / utxos
 52 2016-12-08 21:26:20 <adiabat> and if there's a match, download the whole block
 53 2016-12-08 21:26:28 <bsm117532> adiabat: yeah.  Also use Cuckoo filters...
 54 2016-12-08 21:27:01 <adiabat> yeah... the nicest thing about that is you could soft-fork in some kind of commitment to that filter, hash in the coinbase op_return or something
 55 2016-12-08 21:27:15 <adiabat> then fullnodes can't lie about not seeing transactions
 56 2016-12-08 21:27:29 <bsm117532> Hmmm.  It's about time I started keeping a list of BIP37 improvement ideas...
 57 2016-12-08 21:29:33 <bsm117532> Is there any reason to check the filter against *every* data element in scripts?
 58 2016-12-08 21:30:16 <adiabat> output scripts?
 59 2016-12-08 21:31:01 <adiabat> Not really, if you somehow get a p2sh that uses the same hash as p2pkh you can figure that out once you've downloaded it.  But that should ~never happen
 60 2016-12-08 21:31:23 <adiabat> so efficiency-wise it's fine to only add the 20 byte hash to the filter
 61 2016-12-08 21:31:33 <bsm117532> BIP37 checks every element of the scriptPubKey
 62 2016-12-08 21:32:22 <adiabat> yeah, it does seem kind of odd.  Maybe have it only check elements larger than 8 bytes or something
 63 2016-12-08 21:33:31 <adiabat> from the lite node side, adding only the 20 byte hashes to the filter construction works fine; that's what my software does
 64 2016-12-08 21:34:32 <bsm117532> What's your software?
 65 2016-12-08 21:52:19 <bsm117532> I invite you all to add to/comment on this: https://docs.google.com/document/d/1ByouxU_Jwqv360L3VVZwgJN4L7kK8DpdClCFwDRQyr0/edit#
 66 2016-12-08 21:52:26 <bsm117532> (BIP37 Improvement Ideas)
 67 2016-12-08 21:52:34 <bsm117532> ping chjj roasbeef
 68 2016-12-08 21:53:21 <arubi> bsm117532, why not a gist instead of the google doc?  might attract more editors
 69 2016-12-08 21:53:41 <sipa> bsm117532: utxo commitments don't help, unless they are address-based filters (which have ven higher overhead)
 70 2016-12-08 21:53:48 <sipa> what you need are filter commitments
 71 2016-12-08 21:54:12 <sipa> each block commits to a number of bloom/cuckoo/... filters of various sizes and partitions
 72 2016-12-08 21:55:12 <bsm117532> sipa: Two different use cases: "Is an output still unspent" vs. "Did an output send me funds".  UTXO set commitments provide the former, block commitments to a block filter provide the latter.
 73 2016-12-08 21:56:01 <bsm117532> arubi: I've enabled anonymous commenting on the google doc.  I'm not so sure about gists with multiple editors...
 74 2016-12-08 21:56:15 <bsm117532> Just open the google doc in an incognito window if you like.
 75 2016-12-08 21:58:05 <arubi> gists should act like git repos on github afaik.  I'll go over it on goog docs, no worries
 76 2016-12-08 21:58:29 <arubi> (not that I have anything to add, just curious as always :) )
 77 2016-12-08 21:59:46 <bsm117532> Google docs essentially auto-merge.  I wouldn't want to have 40 forks of my doc on gist and have to figure out how to merge them...  Anyway this is just brainstorming.
 78 2016-12-08 22:01:08 <chjj> bsm117532: i'm not sure about cuckoo filters. cuckoo filters are huge when serialized. probably not as bandwidth efficient. that's the basic idea though. we were leaning towards some kind of committed filter for each block that includes outpoints and address hashes.
 79 2016-12-08 22:02:06 <chjj> bsm117532: segwit blocks would be no problem if the spv client can request the full block, since they could then verify the witness commitment hash.
 80 2016-12-08 22:02:33 <bsm117532> chjj: At fixed false positive rate (which is all anyone cares about) both cuckoo and bloom filters are log(n) in the number of elements, up to a constant factor.  But the extra parameter in bloom filters makes this non-obvious.
 81 2016-12-08 22:05:24 <chjj> bsm117532: i see. i'm probably not in a position to argue on that, since i've only briefly played around with cuckoo filters. they definitely struck me as larger when i was testing.
 82 2016-12-08 22:05:58 <bsm117532> I was investigating the two like a year ago.  I'll dig through my notes...
 83 2016-12-08 22:08:14 <sipa> bsm117532: bip37 does not in any way answer the question whether an output is still unspent
 84 2016-12-08 22:08:21 <sipa> sure, a utxo commitment would help for that
 85 2016-12-08 22:08:36 <sipa> but it's completrly orthogonal to the question of replacing bip37
 86 2016-12-08 22:08:58 <bsm117532> I know. ;-)  It's a question I want light clients to be able to answer, and affects the question of what new things should we commit to in the block header?
 87 2016-12-08 22:09:35 <sipa> heh, there are many things we could commit to if the functionality we want to provide is unlimited
 88 2016-12-08 22:12:13 <sipa> if we'd commit to FIBRE FEC blocks you could create a trustless fibre network (where you can relay packets without being able to verify them)
 89 2016-12-08 22:12:18 <chjj> i think this is a good idea even without the committed filters. putting the load on the spv client rather than the full node is a better design. i see bip37 as a dos vector for full nodes atm.
 90 2016-12-08 22:12:37 <sipa> if we'd commit to spent positions of inouts, we could create double spending fraud proofs
 91 2016-12-08 22:12:41 <chjj> parsing the whole block, creating the merkle branch, testing each pushdata, etc. is nuts.
 92 2016-12-08 22:13:07 <sipa> if we'd commit to a merkle sumtree of amounts, you could have fraud proofs for fees and amounts
 93 2016-12-08 22:13:26 <bsm117532> I knew I could depend on you for da brainstorm sipa ;-)
 94 2016-12-08 22:13:36 <sipa> i didn't come up with any of this
 95 2016-12-08 22:14:10 <sipa> the input positions idea is by rusty
 96 2016-12-08 22:14:16 <sipa> the sumtree by gmaxwell
 97 2016-12-08 22:14:23 <sipa> the fec thing by BlueMatt
 98 2016-12-08 22:15:14 <sipa> filter commitmemts by someone on the ML
 99 2016-12-08 22:16:13 <bsm117532> I'll do some googling and add them to my list.  I'm interested in anything which can improve light client security.
100 2016-12-08 22:16:18 <sipa> roasbeef: hey, i'm next door
101 2016-12-08 22:19:27 <bsm117532> chjj: I agree...I'm also interested in ways to distribute such commitments, even if they are not a consensus rule, and not even necessarily communicated on-chain.
102 2016-12-08 22:19:46 <chjj> sipa: you're at DG? give roasbeef a hard time for me, for missing our hacking session.
103 2016-12-08 22:20:25 <sipa> chjj: no, at the burger place next to it
104 2016-12-08 22:20:53 <chjj> sipa: ah
105 2016-12-08 22:22:09 <chjj> bsm117532: yeah, doesn't necessarily have to be in the header. though, it would be nice. :)
106 2016-12-08 22:24:27 <sipa> bsm117532: well utxo commitments have the downsides of forcing us to forever stick to a (normative) utxo model
107 2016-12-08 22:24:49 <sipa> and fec commitments force us to stick to a particular fec algorithm forever
108 2016-12-08 22:25:43 <sipa> gmaxwell recently had the idea of having commitments with as rule 1) if it is present, it must be valid 2) they're only required to be present for a limited amount of time (say, 2 years)
109 2016-12-08 22:27:24 <bsm117532> I like that.  Though it requires code to be kept essentially forever to evaluate old-style commitments.
110 2016-12-08 22:27:36 <abpa> what does a "proof of proof of work" mean exactly?
111 2016-12-08 22:30:45 <bsm117532> abpa: I give you a list of the block headers for the [smallest hash value H, smallest hash value less than 2*H with larger height than the previous element,  smallest hash value less than 4*H with larger height than the previous element, ..., most recent block header]
112 2016-12-08 22:31:09 <abpa> is it referencing this paper: http://fc16.ifca.ai/bitcoin/papers/KLS16.pdf ?
113 2016-12-08 22:31:12 <bsm117532> this list is logarithmic in height
114 2016-12-08 22:31:28 <bsm117532> Yes.  plus some refinements by amiller
115 2016-12-08 22:31:48 <bsm117532> Don't know if he published his paper yet...