Segregated witness support should result in significantly different fees

[dcousens]

Perhaps base it off a .witness field in the inputs... with which case:

vsize of a transaction equals to 3 times of the size with original serialization, plus the size with new serialization, divide the result by 4 and round up to the next integer. For example, if a transaction is 200 bytes with new serialization, and becomes 99 bytes with marker, flag, and witness removed, the vsize is (99 * 3 + 200) / 4 = 125 with round up.

[dcousens]

Options:

• .witness field for each input, or
• .prevOutScript/.prevOutType for each input

The latter is probably better...

[karelbilek]

Hey, I will look at this soon, I am currently in need for coinselect to work on segwit :)

[karelbilek]

Which script types would like to support?

I could take the types from here (except for NONSTANDARD)

https://github.com/bitcoinjs/bitcoinjs-lib/blob/170328341bdcf2a22d6ee6df1df587ea4e83c8a9/src/templates/index.js#L11

[dcousens]

.script.length is used now for estimation [if provided] - without it, it assumes P2PKH.

If you're implementation can pre-sign all inputs, but with fake/blank signatures [for security], then script.length and an added reduction of byte length over the witness stack would be more than enough to do this.

[karelbilek]

Hm, but pre-signing all inputs with empty/fake privkeys will complicate things and needlessly slow down computation, when the inputs types usually have the same lengths anyway for the given type

[dcousens]

Hm, but pre-signing all inputs with empty/fake privkeys will complicate things and needlessly slow down computation

Not necessarily, it should be no different then the approach we'd be taking here (pattern match, speculate byte length impact via a fake script/witness.

[dcousens]

Resolved partially by #22 (comment) - but - the virtual size calculation isn't accounted for yet?
.witness would need to be provided?