Repository navigation
Segregated witness support should result in significantly different fees #4
Description
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.
Activity
[-]Segregated witness results in significantly different VSize calculation[/-][+]Segregated witness results in significantly different fees[/+][-]Segregated witness results in significantly different fees[/-][+]Segregated witness should result in significantly different fees[/+][-]Segregated witness should result in significantly different fees[/-][+]Segregated witness support should result in significantly different fees[/+]dcousens commentedon Jan 8, 2017
Options:
.witnessfield for eachinput, or.prevOutScript/.prevOutTypefor eachinputThe latter is probably better...
karelbilek commentedon Jun 28, 2017
Hey, I will look at this soon, I am currently in need for coinselect to work on segwit :)
karelbilek commentedon Jun 28, 2017
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 commentedon Jun 29, 2017
.script.lengthis 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.lengthand an added reduction of bytelengthover thewitnessstack would be more than enough to do this.karelbilek commentedon Jun 29, 2017
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 commentedon Jun 30, 2017
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 commentedon Aug 15, 2017
Resolved partially by #22 (comment) - but - the virtual size calculation isn't accounted for yet?
.witnesswould need to be provided?blmalone commentedon Apr 12, 2019
Is this issue being worked on? :)
mahnunchik commentedon Jul 13, 2023
Any news?
karelbilek commentedon Jul 13, 2023
mahnunchik commentedon Jul 13, 2023
What's happened?
junderw commentedon Jul 13, 2023
I am here, but this repository is not a priority for me.
PRs and more importantly PR reviews are greatly appreciated and needed.
ChrisCho-H commentedon Aug 18, 2023
I made PR #82 regarding this issue.