Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segregated witness support should result in significantly different fees #4

Open
dcousens opened this issue Nov 9, 2016 · 13 comments
Labels

Comments

@dcousens
Copy link
Contributor

dcousens commented Nov 9, 2016

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 dcousens self-assigned this Nov 9, 2016
@dcousens dcousens changed the title Segregated witness results in significantly different VSize calculation Segregated witness results in significantly different fees Nov 9, 2016
@dcousens dcousens changed the title Segregated witness results in significantly different fees Segregated witness should result in significantly different fees Nov 9, 2016
@dcousens dcousens changed the title Segregated witness should result in significantly different fees Segregated witness support should result in significantly different fees Nov 9, 2016
@dcousens
Copy link
Contributor Author

dcousens commented Jan 8, 2017

Options:

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

The latter is probably better...

@karelbilek
Copy link
Contributor

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

@karelbilek
Copy link
Contributor

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
Copy link
Contributor Author

dcousens commented Jun 29, 2017

.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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

dcousens commented Aug 15, 2017

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

@blmalone
Copy link

Is this issue being worked on? :)

@mahnunchik
Copy link

Any news?

@karelbilek
Copy link
Contributor

karelbilek commented Jul 13, 2023 via email

@mahnunchik
Copy link

What's happened?

@junderw
Copy link
Member

junderw commented 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
Copy link
Contributor

I made PR #82 regarding this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants