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

Implement Segregated Witness #8

Closed
wants to merge 81 commits into from

Conversation

jameshilliard
Copy link

This is mainly for tracking SegWit progress and testing, it can be tested on segnet.

luke-jr and others added 30 commits December 1, 2015 20:57
Bump version from 0.11.99 to 0.12.0 so that we don't forget to do this
when rc1 is released.
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
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
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
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
- [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
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
…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.
@jtoomim
Copy link

jtoomim commented Jan 16, 2016

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.

@ghost
Copy link

ghost commented Jan 16, 2016

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.

@Aquentus
Copy link

Nack for reasons given by jtoomim, but also because it should be implemented as a hardfork rather than as a messy, complicated, soft fork.

@opetruzel
Copy link

@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.

@jameshilliard
Copy link
Author

@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.
'''

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...

@orangeman
Copy link

+1 Deploy as hard fork!

Why are hard forks more safe?

@jtoomim
Copy link

jtoomim commented Jan 17, 2016

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.

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

Successfully merging this pull request may close these issues.

None yet