< gmaxwell> Trolling for ACKs. https://github.com/bitcoin/bitcoin/pull/10945 (people may want to start benchmarking pre-0.15 and this changes performance)
< gmaxwell> BlueMatt: ^
< sipa> gmaxwell: extrapolated txcount with the data currently in chainparams is only 0.5% off of the real number
< sipa> so updating it may be unnecessary
< gmaxwell> we don't really handle pre vs post assume valid right in terms of estimation though...
< kanzure> regtest mode sendrawtransaction telling me "insufficient fee". 543 byte transaction is paying 16560 sat fee. 2 inputs, 7 outputs. why is this happening?
< kanzure> debug=1 is not revealing anything about this.
< gmaxwell> what are the values of the outputs?
< kanzure> 6 of them are p2pkh 0.08333333 BTC to same address, one is to same address but 0.4998344 BTC.
< kanzure> also nSequence=0 on all the inputs
< gmaxwell> the error messages from sendraw are not always accurate because it's actually very complicated to get that right.
< gmaxwell> is it possible that you're spending an excessively long chain of unconfirmed inputs or something like that?
< kanzure> quick way to test would be to mine a dozen blocks and try again?
< gmaxwell> yes.
< gmaxwell> kanzure: there is a limit on the size of a graph of unconfirmed txn. (it's pretty genrous but in a test it's also not hard to hit)
< kanzure> whoops shouldn't have generated those blocks. (it's hooked up to an application that decided to spend the inputs aonther way.)
< kanzure> so.. my setup is not designed to produce chains of unconfirmed transactions. according to getrawtransaction, the inputs had >20 confirmations at the time i was getting "insufficient fee".
< gmaxwell> are you absolutely sure the fee is what you think it was?
< kanzure> parent tx was 3558 bytes. ~100 outputs.
< kanzure> yea i checked with getrawtransaction and checked the 2 inputs.
< kanzure> and then i summed the output nValues
< kanzure> oh well, i'll try again and this time turn off the other application.
< gmaxwell> kanzure: oh if your other output had already spent the coin you might be "insufficient fee for replacement"!
< kanzure> oh that's clever. yes it could be possible that my system is unintentionally generating a replacement. i could unset nSequence if that would help the error message situation.
< gmaxwell> I would bet that you're making a replacement unintentionally, setting nseq max on all txn would make that more clear.
< kanzure> testing. will get back.
< kanzure> pretty sure that was it, thank you. even worse is that i had a parameter/flag for toggling whether that specific transaction should conflict with previous attempts (as a sort of way of not exhausting my ability to plan, it wasn't intended to be a replacement: but with nSequence=0 that's how it was probably getting interpreted).
< gmaxwell> there isn't really a 1:1 mapping between "human network rules" and "actual network rules" many rules are implied by others, so it's kind of a crapshoot when something is rejected to map that to the most meaningful reason.
< kanzure> yes for this to give me the correct error message it would have to know about the previous transaction and be able to report about it or something.. which is different from just attempting a replacement as it does now.
< gmaxwell> well like it could tell you it was a double spend but that would be super confusing if you were actually attempting a replacement.
< kanzure> yep, to be fair i'm pretty sure my exact situation is technically a replacement and/or double spend, even though this was a bug on my end.
< bitcoin-git> [bitcoin] jl2012 opened pull request #10953: [Refactor] Combine scriptPubKey and amount as CTxOut in CScriptCheck (master...combine_script_amount) https://github.com/bitcoin/bitcoin/pull/10953
< Yoghurt114> hello, has anything changed in the getrawtransaction result format recently?
< Yoghurt114> I can't make sense of the following: https://pastebin.com/VjwD8Qhz (random segwit testnet tx)
< luke-jr> Yoghurt114: Segwit transactions don't use the old tx format..
< gmaxwell> Yoghurt114: thats segwit.
< gmaxwell> Yoghurt114: the 0 vin count is the flag that the tx is using segwit.
< luke-jr> although it's strange that it seems to have a scriptSig for the sole input?
< gmaxwell> the real vin count follows after it.
< gmaxwell> luke-jr: p2sh embedded segwit, I'd assume.
< luke-jr> ah
< luke-jr> Yoghurt114: also there's witness data before the lockitme
< gmaxwell> Yoghurt114: it would be beyond totally awesome if you got your colorcoding tools working with segwit.
< gmaxwell> Yoghurt114: I wasted a couple hours this morning trying to find a reddit post SOMEONE made that colorcoded a hexdump of a block to show the witness data inside it, to disprove some fud that was saying with segwit signatures weren't in blocks.
< gmaxwell> someone actually suggested it was you and pointed me to your site, which might have resulted in other people nagging you to update your stuff for segwit. :)
< Yoghurt114> that is indeed what's happened ;)
< Yoghurt114> so the 00 00 01 01 following the version, what does it mean?
< Yoghurt114> also I can't explain the last part of the raw tx, what used to be a 4 byte locktime is now 0120000000000000000000000000000000000000000000000000000000000000000000000000
< Yoghurt114> which I'm guessing is 01 (1 thing) 20 (32 bytes) 0000000000000000000000000000000000000000000000000000000000000000 (hash) and then the locktime 00000000 - but what is the thing, and what does the hash point to?
< luke-jr> Yoghurt114: before vin count is 00 01
< luke-jr> before locktime is, for each input, a vector of witness data
< luke-jr> each of which is number-of-witness-elements, and for each, the size and data itself
< Yoghurt114> is the 01 following the 00 the segwit program version?
< intcat> is the new segwit transaction serialization format written up anywhere?
< gmaxwell> intcat: sure, in the specs, that one is in BIP 144 https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
< gmaxwell> intcat: come on, you think we'd really change the consensus protocol in any way without writing an extensive specification?
< luke-jr> Yoghurt114: no, the sequence at the start merely serves to distinguish segwit from non-segwit
< intcat> course not, just had some trouble finding it - didnt expect it under "peer services" ;)
< Yoghurt114> "The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP." well - the thing crashed, so I guess the spec is well-defined ;)
< gmaxwell> intcat: serialization itself is a property of the p2p protocol, in theory at least you could have a mix of peers using something entirely different between each other, all in consensus with the network. What matters for consensus is the hashing.
< intcat> is the txin[] the same format as before?
< gmaxwell> intcat: yes.
< jl2012> intcat, gmaxwell: the serialization is indeed consensus because of hashing and weight counting
< bitcoin-git> [bitcoin] practicalswift opened pull request #10956: Fix typos (master...typos-201708) https://github.com/bitcoin/bitcoin/pull/10956
< Yoghurt114> gmaxwell: https://i.imgur.com/8hO4yoH.png it'll look something like this
< Emcy> has there ever been a known example of an SPV client being scammed/partitioned off deliberately
< Emcy> or otherwise attacked using the trust concessions that SPV clients have to mkae
< Emcy> shit wrong place ignore
< bitcoin-git> [bitcoin] practicalswift opened pull request #10957: Do not return a BIP9Stats object with uninitialized values (master...bip9status) https://github.com/bitcoin/bitcoin/pull/10957