Skip to content

Conversation

sipa
Copy link
Member

@sipa sipa commented Mar 19, 2012

Wallet keys are 32 bytes, exactly two AES blocks. Using padded encryption makes attacking somewhat easier, as the attacker can check whether the padding is correct after decrypting using an attempted passphrase, rather than needing to do an EC multiplication to check whether the private and public keys match.

@sipa
Copy link
Member Author

sipa commented Mar 19, 2012

Note that this only fixes this issue for newly encrypted wallets. We do not rely on it for security however, so I do not think there is enough reason for reencrypting old keys.

@TheBlueMatt
Copy link
Contributor

ACK for 0.6.
Update: after incrementing min-version.

@gavinandresen
Copy link
Contributor

NACK for 0.6 : maybe pull early in 0.7 and thoroughly testing backwards/forwards compatibility, although if it creates yet another wallet.dat variation that is not backwards-compatible then I'm not sure the cost is worth the extra security benefit.

(cost is incompatibility with earlier releases and third-party wallet tools)

Wallet keys are 32 bytes, exactly two AES blocks. Using padded encryption
makes attacking somewhat easier, as the attacker can check whether the
padding is correct after decrypting using an attempted passphrase, rather
than needing to do an EC multiplication to check whether the private and
public keys match.
@Diapolo
Copy link

Diapolo commented Mar 19, 2012

I'm currently of no help coding wise, but I think an extra security benefit is not only nice to have, but a must. I agree it's a bad idea to include such a wallet-compatibility change at the end of the 0.6 development, but does wallet.dat variation really matter (i.e. is there a standard defined, when this is allowed and when not)?

Is there a safe way to, let's say, force all wallets to use the latest BC client encryption algo / functions, when first used with a new client version?

@TheBlueMatt
Copy link
Contributor

Oops, this needs to increment wallet's min_version. I don't see why there is any objection to making another wallet version that is non-backward-compatible: wallets in 0.6 are already not compatible with any previous versions, so this is just another change that makes them further incompatible. In fact, I would say its better to put this in 0.6 than in 0.7, so that 0.7 wallets arent incompatible (again) with 0.6 wallets.
Properly implemented 3rd-party wallet tools should still work fine, or could be made to work with very minimal changes.

@sipa
Copy link
Member Author

sipa commented Mar 19, 2012

(edited)

@TheBlueMatt: oh yes, indeed, it needs a min_version update

@luke-jr
Copy link
Member

luke-jr commented Apr 6, 2012

Is this sane now with the -walletupgrade thing?

@sipa
Copy link
Member Author

sipa commented Apr 6, 2012

I'll update this to be compatible with -upgradewallet.

@sipa
Copy link
Member Author

sipa commented Jun 12, 2012

Closing this as it is outdated. Will reopen when redone properly.

@sipa sipa closed this Jun 12, 2012
suprnurd pushed a commit to chaincoin-legacy/chaincoin that referenced this pull request Dec 5, 2017
13316a4 Return true from IsBlockValueValid when masternode data is not synced
  - This restores behavior very close to that in 12.0
  - Needed to prevent the forking problem currently being seen on
    testnet between online and offline nodes
  - This is expected to be a temporary fix while we develop a
    long-term solution for this problem

427086e Restore miner payments for superblocks

794b90d Added IsSynced field to JSON output of mnsync status RPC command
  - This is needed to allow fixing RPC tests so that they wait until
    the nodes are fully synced before performing tests

a9ddf6f Wait for nodes to sync masternode data during p2p-fullblocktest
ptschip pushed a commit to ptschip/bitcoin that referenced this pull request Feb 20, 2018
LogAcceptCategory and the enum used to define available logging
category is defined inside the Logging namespace. If used directly
outside of util.{h,cpp} reference to such namespace is needed.

This commit fix issue bitcoin#950
ptschip pushed a commit to ptschip/bitcoin that referenced this pull request Feb 25, 2018
LogAcceptCategory and the enum used to define available logging
category is defined inside the Logging namespace. If used directly
outside of util.{h,cpp} reference to such namespace is needed.

This commit fix issue bitcoin#950
ptschip added a commit to ptschip/bitcoin that referenced this pull request Mar 5, 2018
* Update the block availaibility for all nodes during IBD

One of the problems with IBD is that we end up downloading
blocks from the same peer. This is because after downloading
all the headers at startup the block availability is only
being updated for that peer. We need to assume that all connected
or newly connected peers have the blocks that we need but we
only do this during IBD or when IsInitialBlockDownload() is true.

* Increase the block download window to 1024

This helps to keep IBD moving forward when we have a peer
that may be serving us blocks more slowly.  And now that
blockvailability is being updated correctly we are getting blocks
from all connected peers so the chance of having a slow peer
is now much higher.

* Reset the single peer request mode age to 24 hours

One week isn't needed anymore because the new DAA is working
well and we're not falling behind in terms of blocks mined
per day.

* Remove the check for node ping in the request manager

This feature is causing occasional hangups during IBD and
is not really effective in selecting peers especially during
IBD. Since it is not used when the chain is sync'd then there
is no need for this feature to remain which only adds another
level of complexity to IBD. KISS can be applied here for a better
IBD experience.

* Only update xthin stats when IsChainNearlySyncd()

There is no need to lock vNodes and check all peers for
thinblocks in flight unless we are IsChainNearlySyncd() because
we would not have asked for any xthins if !IsChainNearlySyncd().

This is an expensive operation and which makes a performance hit
during IBD.

* Disconnect non NETWORK nodes during initial sync

We only want to have nodes we can download the full
blockchain from, connected to us while we do our initial sync.

* Increase the default max outbound connections to 16

Having a few more outbound connections can help especially
during the process of IBD.

* During IBD, batch the block reqeusts if possible.

By batching the blocks together we save a little bandwidth
and time in requesting blocks.

This method can then be applied to batching transactions which
should make a very good improvement during periods where transaction
rates are high.

* Replace missing cs_main lock

* fix formatting

* Fix locking order issue with cs_objectDownloader and cs_vNodes

cs_objectDownloader must be locked first to prevent a possible
deaklock.

* Fix formatting

* Use Logging namespace to access LogAcceptCategory

LogAcceptCategory and the enum used to define available logging
category is defined inside the Logging namespace. If used directly
outside of util.{h,cpp} reference to such namespace is needed.

This commit fix issue bitcoin#950

* Don't favor XTHIN nodes when sending messages

This has a negative effect on IBD

* Use more descriptive variable names for nodes we are disconnecting

ptemp1 and ptemp2 are getting hard to follow. We'll say what they are:

pNonXthinNode and pNonNodeNetwork

* Take the cs_objDownloader lock earlier when requesting multiple objects

This prevents anyone else from asking for these same objects before
we've notified the request manager of their existence. This could happen
for in stance during IBD where we look for the next blocks to download
but before we've notified the request manager of them all we then
go back and possibly request them again.

Also keeping the lock here allows the request manager to prepare
a better batch request of blocks and thereby keep a better order
of block requests.

* Call MarkBlocksAsInFlight() before asking for blocks

This ensures you don't receive any blocks back before you mark the block
in flight as could happen on regtest.

* Add/release node refs when making batch requests

We need to track the node refs correctly so we don't get disconnected
before we're done our work.

* Don't ask for the same blocks twice when doing IBD

If we've already asked for a block, we don't have to ask for it
again in FindNextBlocksToDownload(), instead we can rely o the request
manager handle potential re-requests.

* Calculate MaxBlocksInTransitPerPeer, but on an individual node basis

Before we were using the overall resonse times regardless of
which peer they came from. This made the selection of how many
blocks to donwload at one time not responsive to faster or
slower nodes.  By tracking response times on a per node basis
we can deprioritize slower downloaders and get more blocks
from the faster nodes.

In HEADERS net processing, remove MAX_BLOCKS_IN_TRANSIT_PER_PEER

  This has been replaced with pnode->nMaxBlocksInTransitPerPeer

use atomic store, load, fetch_add

* Fixes bitcoin#941: Rotate vNodes by one peer every 60 seconds when sending messages

We do this only during IBD and this has the effect of distributing
the load more evenly between the peers. Previously, because we are
using PV, the very first peer to connect would always be favored and
we would end up downloading a disproportionate amount of blocks from
that peer during IBD.  However, we still will download more from
some peers based on their download response time performance.

* Small net optimization when sending messages

Just copy the entire vector rather than bothering to allocate
memory and then push_back for each entry as we iteration through
vNodes.

Make sure to LOCK vNodes then add the ref

* Fix getchaintips.py spurious failures

The hang results from a  PV bug which is caused by a condition where
threads that are waiting for validation are forced to quit during chain
tip rollback.  We don't in fact have to force any threads to quit since
any validation threads on the current chain will fail automatically
once we disconnect the tip.  And then the waiting block validation
thread for the new chain can still continue without being inadvertanly
forced to quit.

* Do not to use an incorrect or invalid state

Use the node id from the iterator rather than looking up state
by the node we think we just passed in. Just in case they don't match
for some reason.

Also DbgAssert if the state is NULL and return false if we assert.

* Small edit to logprint

Add category BLK to logprint

remove printf

* During IBD only request blocks from peers that have block availability

Request from peers that are NODE_NETWORK and have demonstrated that
they have the blocks that we need.

Also move ProcessBlockAvailablity and UpdateBlockAvailabilty to
RequestManager.cpp

* Move FindNextBlocksToDownload() to the requestManager.cpp

Also change all NULL's to nullptr.

* Move MarkBlockAsInFlight() and MarkBlockAsReceived() to requestManager.cpp

This ia a Move only.  Alhtough there are edits in order to
bring these into the requestManager class structure there
are no logic changes.

C++ nullptr replaces NULL's

* Update block availablity during the process of downloading headers

During initial sync we have to download a set of all headers but
we also need to update the block availabiity for each connected
peer so that when the request manager starts downloading blocks
it can have the correct list of peers that have available blocks
to download from, rather than just assuming every peer has all
blocks.

* EXIT cs_objDownloader earlier.

We don't have to repeatedly take and release the locks.
Just do it once for all items in the entire batch request.

* Only ask for headers to updateblockavailability if chain work is behind

When doing the initial request for headers and we're in the process
of also updating the block availability for each connected peer we
only need to ask for a header if any peer is actually behind in
terms of chain work. This prevents first of all requesting
headers we don't need but also any possible attack where we're being
fed an invalid group of headers which then causes us to request
large number of additional headers.
ptschip added a commit to ptschip/bitcoin that referenced this pull request Mar 7, 2018
* Update the block availaibility for all nodes during IBD

One of the problems with IBD is that we end up downloading
blocks from the same peer. This is because after downloading
all the headers at startup the block availability is only
being updated for that peer. We need to assume that all connected
or newly connected peers have the blocks that we need but we
only do this during IBD or when IsInitialBlockDownload() is true.

* Increase the block download window to 1024

This helps to keep IBD moving forward when we have a peer
that may be serving us blocks more slowly.  And now that
blockvailability is being updated correctly we are getting blocks
from all connected peers so the chance of having a slow peer
is now much higher.

* Reset the single peer request mode age to 24 hours

One week isn't needed anymore because the new DAA is working
well and we're not falling behind in terms of blocks mined
per day.

* Remove the check for node ping in the request manager

This feature is causing occasional hangups during IBD and
is not really effective in selecting peers especially during
IBD. Since it is not used when the chain is sync'd then there
is no need for this feature to remain which only adds another
level of complexity to IBD. KISS can be applied here for a better
IBD experience.

* Only update xthin stats when IsChainNearlySyncd()

There is no need to lock vNodes and check all peers for
thinblocks in flight unless we are IsChainNearlySyncd() because
we would not have asked for any xthins if !IsChainNearlySyncd().

This is an expensive operation and which makes a performance hit
during IBD.

* Disconnect non NETWORK nodes during initial sync

We only want to have nodes we can download the full
blockchain from, connected to us while we do our initial sync.

* Increase the default max outbound connections to 16

Having a few more outbound connections can help especially
during the process of IBD.

* During IBD, batch the block reqeusts if possible.

By batching the blocks together we save a little bandwidth
and time in requesting blocks.

This method can then be applied to batching transactions which
should make a very good improvement during periods where transaction
rates are high.

* Replace missing cs_main lock

* fix formatting

* Fix locking order issue with cs_objectDownloader and cs_vNodes

cs_objectDownloader must be locked first to prevent a possible
deaklock.

* Fix formatting

* Use Logging namespace to access LogAcceptCategory

LogAcceptCategory and the enum used to define available logging
category is defined inside the Logging namespace. If used directly
outside of util.{h,cpp} reference to such namespace is needed.

This commit fix issue bitcoin#950

* Don't favor XTHIN nodes when sending messages

This has a negative effect on IBD

* Use more descriptive variable names for nodes we are disconnecting

ptemp1 and ptemp2 are getting hard to follow. We'll say what they are:

pNonXthinNode and pNonNodeNetwork

* Take the cs_objDownloader lock earlier when requesting multiple objects

This prevents anyone else from asking for these same objects before
we've notified the request manager of their existence. This could happen
for in stance during IBD where we look for the next blocks to download
but before we've notified the request manager of them all we then
go back and possibly request them again.

Also keeping the lock here allows the request manager to prepare
a better batch request of blocks and thereby keep a better order
of block requests.

* Call MarkBlocksAsInFlight() before asking for blocks

This ensures you don't receive any blocks back before you mark the block
in flight as could happen on regtest.

* Add/release node refs when making batch requests

We need to track the node refs correctly so we don't get disconnected
before we're done our work.

* Don't ask for the same blocks twice when doing IBD

If we've already asked for a block, we don't have to ask for it
again in FindNextBlocksToDownload(), instead we can rely o the request
manager handle potential re-requests.

* Calculate MaxBlocksInTransitPerPeer, but on an individual node basis

Before we were using the overall resonse times regardless of
which peer they came from. This made the selection of how many
blocks to donwload at one time not responsive to faster or
slower nodes.  By tracking response times on a per node basis
we can deprioritize slower downloaders and get more blocks
from the faster nodes.

In HEADERS net processing, remove MAX_BLOCKS_IN_TRANSIT_PER_PEER

  This has been replaced with pnode->nMaxBlocksInTransitPerPeer

use atomic store, load, fetch_add

* Fixes bitcoin#941: Rotate vNodes by one peer every 60 seconds when sending messages

We do this only during IBD and this has the effect of distributing
the load more evenly between the peers. Previously, because we are
using PV, the very first peer to connect would always be favored and
we would end up downloading a disproportionate amount of blocks from
that peer during IBD.  However, we still will download more from
some peers based on their download response time performance.

* Small net optimization when sending messages

Just copy the entire vector rather than bothering to allocate
memory and then push_back for each entry as we iteration through
vNodes.

Make sure to LOCK vNodes then add the ref

* Fix getchaintips.py spurious failures

The hang results from a  PV bug which is caused by a condition where
threads that are waiting for validation are forced to quit during chain
tip rollback.  We don't in fact have to force any threads to quit since
any validation threads on the current chain will fail automatically
once we disconnect the tip.  And then the waiting block validation
thread for the new chain can still continue without being inadvertanly
forced to quit.

* Do not to use an incorrect or invalid state

Use the node id from the iterator rather than looking up state
by the node we think we just passed in. Just in case they don't match
for some reason.

Also DbgAssert if the state is NULL and return false if we assert.

* Small edit to logprint

Add category BLK to logprint

remove printf

* During IBD only request blocks from peers that have block availability

Request from peers that are NODE_NETWORK and have demonstrated that
they have the blocks that we need.

Also move ProcessBlockAvailablity and UpdateBlockAvailabilty to
RequestManager.cpp

* Move FindNextBlocksToDownload() to the requestManager.cpp

Also change all NULL's to nullptr.

* Move MarkBlockAsInFlight() and MarkBlockAsReceived() to requestManager.cpp

This ia a Move only.  Alhtough there are edits in order to
bring these into the requestManager class structure there
are no logic changes.

C++ nullptr replaces NULL's

* Update block availablity during the process of downloading headers

During initial sync we have to download a set of all headers but
we also need to update the block availabiity for each connected
peer so that when the request manager starts downloading blocks
it can have the correct list of peers that have available blocks
to download from, rather than just assuming every peer has all
blocks.

* EXIT cs_objDownloader earlier.

We don't have to repeatedly take and release the locks.
Just do it once for all items in the entire batch request.

* Only ask for headers to updateblockavailability if chain work is behind

When doing the initial request for headers and we're in the process
of also updating the block availability for each connected peer we
only need to ask for a header if any peer is actually behind in
terms of chain work. This prevents first of all requesting
headers we don't need but also any possible attack where we're being
fed an invalid group of headers which then causes us to request
large number of additional headers.
lateminer pushed a commit to lateminer/bitcoin that referenced this pull request Oct 30, 2019
…mmands

983d97a [Refactor] Combine parameter checking of budget commands (Cave Spectre)

Pull request description:

  ### **Release notes**
  - [Refactor] Move common budget parameter checking code into a function

  ### **Details**
  The code in both `preparebudget` and `submitbudget` used the same parameter checking.  This pulls that parameter checking and loading into a common routine used by both; for ease of improvements and adjustments to the parameter checking... so the risk of not adjusting them consistently in both routines is removed.

  ### **Note**
  The early discussion below is based on a combined PR that addressed this, plus bitcoin#950 and a PR to be named later.  The decision was made to split and focus; so the discussions can be independent of each other and refactor as needed.

ACKs for top commit:
  Fuzzbawls:
    ACK 983d97a
  random-zebra:
    ACK PIVX-Project@983d97a

Tree-SHA512: a88eb41e06d1936db77f1cd9c4f04360b446c48d27652d57dfd6e4b119140d56e24b24e00e0ac48890cc78d4130f8f688a711f74899f9c9301d1aba22dff5315
lateminer pushed a commit to lateminer/bitcoin that referenced this pull request Oct 30, 2019
009bd63 [RPC] require valid URL scheme on budget commands (Cave Spectre)

Pull request description:

  ### **Release Notes**
  [RPC] Require valid URL schemes (URLs starting with "http" or "https") on preparebudget and submitbudget.

  ### **Details**
  The budget proposal system did not have any checks on the URL aside of string length.  This allowed for the scheme to be left off the URL; which on some browsers, resulted in the link to fail when clicked:

  ![image](https://user-images.githubusercontent.com/36988814/61176879-69c97a80-a596-11e9-9307-cbeeb210e133.png)
  ```
  gio: file:///home/CaveSpectre/forum.pivx.org/index.php%3Fthreads/bizdev-proposal-john-m.285:
  Error when getting information for file “/home/CaveSpectre/forum.pivx.org/index.php?
  threads/bizdev-proposal-john-m.285”: No such file or directory
  ```

  The included PR changes the `submitbudget` and `preparebudget` rpc commands to prevent inadvertent omissions of the URL scheme (http:// or https://).

  Qt changes to fixup the existing & historical budget URLs will be submitted as a separate PR after the merging of bitcoin#954 .

  ![image](https://user-images.githubusercontent.com/36988814/61176955-017b9880-a598-11e9-8df0-f4afe1ccdf7d.png)

  _(This PR originally included the Qt changes, and as a result some of the below discussion relates to that, before the decision was made to back out the Qt changes until a later date)_

ACKs for top commit:
  Fuzzbawls:
    ACK 009bd63
  random-zebra:
    utACK 009bd63 and merging...

Tree-SHA512: c08538af442ce1177cae8684bc71e7a6148a3cdb462c1e442e21e2bd5aa91b0ee8417a1692073d9db2a356f86785ab85b2c2cbcf6c681c24c2cd4921094c8ff3
sipa added a commit to sipa/bitcoin that referenced this pull request Jul 14, 2021
be8d9c2 Merge bitcoin-core/secp256k1#965: gen_context: Don't use any ASM
aeece44 gen_context: Don't use any ASM
7688a4f Merge bitcoin-core/secp256k1#963: "Schnorrsig API overhaul" fixups
90e8344 ci: Add C++ test
f698caa Use unsigned char consistently for byte arrays
b5b8e7b Don't declare constants twice
769528f Don't use string literals for char arrays without NUL termination
2cc3cfa Fix -Wmissing-braces warning in clang
0440945 Merge bitcoin#844: schnorrsig API overhaul
ec3aaa5 Merge bitcoin#960: tests_exhaustive: check the result of secp256k1_ecdsa_sign
a1ee83c tests_exhaustive: check the result of secp256k1_ecdsa_sign
253f90c Merge bitcoin-core/secp256k1#951: configure: replace AC_PATH_PROG to AC_CHECK_PROG
446d28d Merge bitcoin-core/secp256k1#944: Various improvements related to CFLAGS
0302138 ci: Make compiler warning into errors on CI
b924e1e build: Ensure that configure's compile checks default to -O2
7939cd5 build: List *CPPFLAGS before *CFLAGS like on the compiler command line
595e8a3 build: Enable -Wcast-align=strict warning
0725626 build: Use own variable SECP_CFLAGS instead of touching user CFLAGS
4866178 Merge bitcoin-core/secp256k1#955: Add random field multiply/square tests
75ce488 Merge bitcoin-core/secp256k1#959: tests: really test the non-var scalar inverse
41ed139 tests: really test the non-var scalar inverse
5f6ceaf schnorrsig: allow setting MSGLEN != 32 in benchmark
fdd06b7 schnorrsig: add tests for sign_custom and varlen msg verification
d8d806a schnorrsig: add extra parameter struct for sign_custom
a0c3fc1 schnorrsig: allow signing and verification of variable length msgs
5a8e499 Add secp256k1_tagged_sha256 as defined in BIP-340
b6c0b72 schnorrsig: remove noncefp args from sign; add sign_custom function
bdf19f1 Add random field multiply/square tests
8ae56e3 Merge bitcoin#879: Avoid passing out-of-bound pointers to 0-size memcpy
a4642fa configure: replace AC_PATH_PROG to AC_CHECK_PROG
1758a92 Merge bitcoin#950: ci: Add ppc64le build
c58c4ea ci: Add ppc64le build
7973576 Merge bitcoin#662: Add ecmult_gen, ecmult_const and ecmult to benchmark
8f879c2 Fix array size in bench_ecmult
2fe1b50 Add ecmult_gen, ecmult_const and ecmult to benchmark
593e6ba Clean up ecmult_bench to make space for more benchmarks
50f3367 Merge bitcoin#947: ci: Run PRs on merge result even for i686
a35fdd3 ci: Run PRs on merge result even for i686
442cee5 schnorrsig: add algolen argument to nonce_function_hardened
df3bfa1 schnorrsig: clarify result of calling nonce_function_bip340 without data
99e8614 README: mention schnorrsig module
3dc8c07 Merge bitcoin#846: ci: Run ASan/LSan and reorganize sanitizer and Valgrind jobs
02dcea1 ci: Make test iterations configurable and tweak for sanitizer builds
489ff5c tests: Treat empty SECP2561_TEST_ITERS as if it was unset
fcfcb97 ci: Simplify to use generic wrapper for QEMU, Valgrind, etc
de4157f ci: Run ASan/LSan and reorganize sanitizer and Valgrind jobs
399722a Merge bitcoin#941: Clean up git tree
09b3bb8 Clean up git tree
bf0ac46 Merge bitcoin#930: Add ARM32/ARM64 CI
202a030 Merge bitcoin#850: add `secp256k1_ec_pubkey_cmp` method
1e78c18 Merge bitcoin-core/secp256k1#940: contrib: Explain explicit header guards
6939487 Merge bitcoin#926: secp256k1.h: clarify that by default arguments must be != NULL
6eceec6 add `secp256k1_xonly_pubkey_cmp` method
0d9561a add `secp256k1_ec_pubkey_cmp` method
22a9ea1 contrib: Explain explicit header guards
6c52ae8 Merge bitcoin#937: Have ge_set_gej_var, gej_double_var and ge_set_all_gej_var initialize all fields of their outputs.
185a6af Merge bitcoin#925: changed include statements without prefix 'include/'
14c9739 tests: Improve secp256k1_ge_set_all_gej_var for some infinity inputs
4a19668 tests: Test secp256k1_ge_set_all_gej_var for all infinity inputs
3c90bdd change local lib headers to be relative for those pointing at "include/" dir
45b6468 Have secp256k1_ge_set_all_gej_var initialize all fields. Previous behaviour would not initialize r->y values in the case where infinity is passed in. Furthermore, the previous behaviour wouldn't initialize anything in the case where all inputs were infinity.
31c0f6d Have secp256k1_gej_double_var initialize all fields. Previous behaviour would not initialize r->x and r->y values in the case where infinity is passed in.
dd6c3de Have secp256k1_ge_set_gej_var initialize all fields. Previous behaviour would not initialize r->x and r->y values in the case where infinity is passed in.
d0bd269 Merge bitcoin-core/secp256k1#936: Fix gen_context/ASM build on ARM
8bbad7a Add asm build to ARM32 CI
7d65ed5 Add ARM32/ARM64 CI
c848352 Makefile.am: Don't pass a variable twice
2161f31 Makefile.am: Honor config when building gen_context
99f47c2 gen_context: Don't use external ASM because it complicates the build
98e0358 Merge bitcoin#933: Avoids a missing brace warning in schnorrsig/tests_impl.h on old compilers
99e2d5b Avoids a missing brace warning in schnorrsig/tests_impl.h on old compilers.
34388af Merge bitcoin#922: Add mingw32-w64/wine CI build
7012a18 Merge bitcoin#928: Define SECP256K1_BUILD in secp256k1.c directly.
ed5a199 tests: fopen /dev/urandom in binary mode
ae9e648 Define SECP256K1_BUILD in secp256k1.c directly.
4dc37bf Add mingw32-w64/wine CI build
0881633 secp256k1.h: clarify that by default arguments must be != NULL
9570f67 Avoid passing out-of-bound pointers to 0-size memcpy

git-subtree-dir: src/secp256k1
git-subtree-split: be8d9c2
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants