Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upBytespersigop #9
Merged
Conversation
rubensayshi
force-pushed the
bytespersigop
branch
4 times, most recently
from
938febd
to
6f7680b
counterpartylib/lib/transaction.py
Outdated
| desired_input_count = 1 | ||
|
|
||
| if encoding == 'multisig' and data_output and util.enabled('bytespersigop'): | ||
| desired_input_count = len(data_output) * 2 |
This comment has been minimized.
This comment has been minimized.
robby-dermody
May 31, 2016
given that data_output = (data_array, data_value), do you mean desired_input_count = len(data_output[0]) * 2 ??
This comment has been minimized.
This comment has been minimized.
counterpartylib/lib/transaction.py
Outdated
| # in bitcoin core v0.12.1 a -bytespersigop was added that messes with bare multisig transactions, | ||
| # as a safeguard we fall back to pubkeyhash encoding when unsure | ||
| # when len(inputs) > len(data_outputs) there's more bytes:sigops ratio and we can safely continue | ||
| if encoding == 'multisig' and inputs and data_output and len(inputs) < len(data_output) * 2 and util.enabled('bytespersigop'): |
This comment has been minimized.
This comment has been minimized.
| "minimum_version_major": 9, | ||
| "minimum_version_minor": 54, | ||
| "minimum_version_revision": 0, | ||
| "block_index": 413083 |
This comment has been minimized.
This comment has been minimized.
robby-dermody
May 31, 2016
make this 500k so that we can safely merge into develop and commit with the next release, as this problem has an impact but not a huge one
rubensayshi
force-pushed the
bytespersigop
branch
4 times, most recently
from
7aa0927
to
ee2d1dc
…cast text messages. the old way had an issue when the string was exactly the switch point (52), because it turned into a 53 long string (+1 from length byte) and that resulted in length byte becoming part of the result. now always use a varint to specify the length.
rubensayshi
force-pushed the
bytespersigop
branch
3 times, most recently
from
40de8b7
to
cd455e2
…ctly-52chars-varstring Problem with broadcast text exactly 52 chars! (PROTOCOL CHANGE)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
rubensayshi commentedMay 23, 2016
•
edited
In Bitcoin Core v0.12.1 a PR was merged to add
-bytespersigopwhich limits the ratio of sigops:bytes.This DOS protection uses a shortcut way of counting sigops which counts OP_CHECKMULTISIG as 20 sigops (the max allowed) and results in CP TXs that use multisig encoding not being relayed and mined by v0.12.1 nodes (when > 80 bytes it no longer fits in opreturn).
this is an edge case, there's been 250 CP TXs with > 80 bytes in the history of CP;
I'm talking to core devs to get this fixed in core, hopefully for the next release, but before v0.12.1 is widely adopted we need a fix for this that we keep in place until v0.12.1 is phased out.
This PR consists of 2 fallbacks to deal with this problem: