-
Notifications
You must be signed in to change notification settings - Fork 70
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
Implement Segregated Witness #8
Conversation
Bump version from 0.11.99 to 0.12.0 so that we don't forget to do this when rc1 is released.
Rebased-From: b440409 Github-Pull: bitcoin#7152
Mempool requests use a fair amount of bandwidth when the mempool is large, disconnecting peers using them follows the same logic as disconnecting peers fetching historical blocks. Rebased-From: 6aadc75 Github-Pull: bitcoin#7166
Github-Pull: bitcoin#7174 Rebased-From: 96918a2
Remove necessity to call create_callback_map (as well as the function itself) from the Python P2P test framework. Invoke the appropriate methods directly. - Easy to forget to call it and wonder why it doesn't work - Simplifies the code - This makes it easier to handle new messages in subclasses Github-Pull: bitcoin#7171 Rebased-From: 2f601d2
This is a combination of 3 commits. - Coinselection prunes extraneous inputs from ApproximateBestSubset A further pass over the available inputs has been added to ApproximateBestSubset after a candidate set has been found. It will prune any extraneous inputs in the selected subset, in order to decrease the number of input and the resulting change. - Moved set reduction to the end of ApproximateBestSubset to reduce performance impact - Added a test for the pruning of extraneous inputs after ApproximateBestSet Github-Pull: bitcoin#4906 Rebased-From: 5c03483 af9510e fc0f52d
Ever since we bitcoin#5913 have been sending invalid reject messages for transactions and blocks. test: Add basic test for `reject` code Extend P2P test framework to make it possible to expect reject codes for transactions and blocks. Github-Pull: bitcoin#7179 Rebased-From: 9fc6ed6 2041190
- Avoids string typos (by making the compiler check) - Makes it easier to grep for handling/generation of a certain message type - Refer directly to documentation by following the symbol in IDE - Move list of valid message types to protocol.cpp: protocol.cpp is a more appropriate place for this, and having the array there makes it easier to keep things consistent. Github-Pull: bitcoin#7181 Rebased-From: 9bbe71b
Rebased-From: daf6466 Github-Pull: bitcoin#7206
CWalletTx::GetAmounts could not find output address for null data transactions, thus issuing an error in debug.log. This change checks to see if the transaction is OP_RETURN before issuing error. resolves bitcoin#6142 Github-Pull: bitcoin#7200 Rebased-From: b6915b8 c611acc d812daf
We used to have a trickle node, a node which was chosen in each iteration of the send loop that was privileged and allowed to send out queued up non-time critical messages. Since the removal of the fixed sleeps in the network code, this resulted in fast and attackable treatment of such broadcasts. This pull request changes the 3 remaining trickle use cases by random delays: * Local address broadcast (while also removing the the wiping of the seen filter) * Address relay * Inv relay (for transactions; blocks are always relayed immediately) The code is based on older commits by Patrick Strateman. Github-Pull: bitcoin#7125 Rebased-From: 5400ef6
Github-Pull: bitcoin#7216 Rebased-From: e18378e
In rpc-tests.py, don't override BITCOIND and BITCOINCLI if they're already set. Makes it possible to run the tests with either another tree or the GUI. Github-Pull: bitcoin#7209 Rebased-From: 83cdcbd
Bring dependencies up to date with master: [depends] Boost 1.59.0 [depends] miniupnpc 1.9.20151026 [depends] native ccache 3.2.4 [depends] zeromq 4.0.7 [depends] Latest config.guess & config.sub [depends] Fix miniupnpc compilation on osx Github-Pull: bitcoin#6980 Rebased-From: 9e940fa 17ad964 26f8ea5 10d3c77 23a3c47 e0769e1
…action 1) Fix mempool limiting for PrioritiseTransaction Redo the feerate index to be based on mining score, rather than fee. Update mempool_packages.py to test prioritisetransaction's effect on package scores. 2) Update replace-by-fee logic to use fee deltas 3) Use fee deltas for determining mempool acceptance 4) Remove GetMinRelayFee One test in AcceptToMemoryPool was to compare a transaction's fee agains the value returned by GetMinRelayFee. This value was zero for all small transactions. For larger transactions (between DEFAULT_BLOCK_PRIORITY_SIZE and MAX_STANDARD_TX_SIZE), this function was preventing low fee transactions from ever being accepted. With this function removed, we will now allow transactions in that range with fees (including modifications via PrioritiseTransaction) below the minRelayTxFee, provided that they have sufficient priority. Github-Pull: bitcoin#7062 Rebased-From: eb30666 9ef2a25 27fae34 901b01d
Github-Pull: bitcoin#7226 Rebased-From: 9b41a5f
- [Tests] Add mempool_limit.py test - [Tests] Refactor some shared functions Github-Pull: bitcoin#7153 Rebased-From: 110ff11 7632cf6
This is unnecessary during the current tests (any test for Tor interaction can explicitly enable it) and interferes with the proxy test. Github-Pull: bitcoin#7170 Rebased-From: 4c40ec0
Github-Pull: bitcoin#7276 Rebased-From: 7ef8f3c
fa8c8d7 torcontrol debug: Change to a blanket message that covers both cases (MarcoFalke)
The manpages are outdated and are very rarely updated when changes to the code happen. Github-Pull: bitcoin#7274 Rebased-From: fae7a36 fa6ce44
Github-Pull: bitcoin#7251 Rebased-From: fa09562
Github-Pull: bitcoin#7250 Rebased-From: fa0a974
…ecifier (usually when it only has one possible value) Github-Pull: bitcoin#7253 Rebased-From: 0d59589
Include translations that omit raw number from the singular case.
Github-Pull: bitcoin#7217 Rebased-From: 5246180
Github-Pull: bitcoin#7193 Rebased-From: fafd093
Includes standardness logic and v0 20-byte logic by Johnson Lau.
Includes simplifications by Eric Lombrozo.
Includes support for pushkeyhash wit v0 by Alex Morcos.
Isn't this project being developed upstream? I do not expect development on it to be faster here than upstream, and I think that discussing this PR here would fracture the conversation. We can pull it from upstream (Core) once it's merged into their master branch, the same as we do all other Core commits that we don't explicitly reject. Note: This is likely to be another trolling attempt. Keep politics in the appropriate forums. Github is for code. |
I guess the thing that would be worth doing on the Bitcoin Classic side is to refactor SegWit as a hard fork rather than a soft fork. But that can wait until 2MB is deployed and Pieter has finished coding it for Core. |
Nack for reasons given by jtoomim, but also because it should be implemented as a hardfork rather than as a messy, complicated, soft fork. |
@jameshilliard Has any work on a HF implementation been done, as well? Or, is the soft fork version the only effort thus far? Genuinely curious. |
@opetruzel There has been work done on both variants although the plan was to do it as a soft fork since it can be deployed safety faster than a hard fork. |
class RejectResult(object): | ||
''' | ||
Outcome that expects rejection of a transaction or block. | ||
''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What could possibly go wrong here?
I can't see any risks merging as is.
FULL ACK from my side 👍
Bitcoin really needs more transaction throughput to grow!
We need to get a release ready before its too late...
+1 Deploy as hard fork! Why are hard forks more safe? |
This branch has merge conflicts. It also does not seem to be the right forum, as @jameshilliard did not write any of the code in this PR, and is submitting incomplete code, and is doing so in a way that violates principles for a good work flow. This code can be pulled in from our upstream, Core master, once it is committed there. At an absolute minimum, please make sure your code merges properly, compiles, and passes unit tests before opening a pull request. I am closing this. |
This is mainly for tracking SegWit progress and testing, it can be tested on segnet.