profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/sipa/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Pieter Wuille sipa @chaincodelabs @Bitcoin developer at @chaincodelabs. Formerly @Blockstream.

bbuenz/BulletProofLib 138

Library for generating non-interactive zero knowledge proofs without trusted setup (Bulletproofs)

sipa/bips 137

Bitcoin Improvement Proposals

sipa/bech32 132

Code snippets and analysis of the Bech32 format

sipa/bitcoin 67

Bitcoin integration/staging tree

sipa/bitcoin-stats 48

bitcoin.sipa.be scripts

sipa/bitcoin-net-simul 17

Bitcoin network simulator

sipa/ezbase32 9

Simple base32 format with strong error detection

sipa/asmap 6

Compact encoding of approximate prefix->AS table

push eventsipa/bitcoin

Pieter Wuille

commit sha f278e37678aef1ef33dd9ec7554ea9a6a123bc28

Fix bug in fractional max_access randomization

view details

push time in 7 hours

pull request commentbitcoin/bitcoin

p2p, rpc, test: address rate-limiting follow-ups

Concept ACK

jonatack

comment created time in 8 hours

push eventsipa/bitcoin

Pieter Wuille

commit sha 5a9ebbcb0824a3c0de06d9976ed4a5fc82a21780

Search until 99.9999% within 90%+-0.01%, or range 0.25

view details

push time in 8 hours

push eventsipa/bitcoin

Pieter Wuille

commit sha a226059841ef469891d6de41ab63a5aa5f1558b3

Switch to Boost beta function

view details

push time in 9 hours

push eventsipa/bitcoin

Pieter Wuille

commit sha 500a8c518c4fd9fac874904fa8d521c946b9288d

Fractional max_access

view details

push time in a day

push eventsipa/bitcoin

Pieter Wuille

commit sha 7e0a3765373c833aa27ff6fa1293866a23224aa9

Fractional max_access

view details

push time in a day

issue commentbitcoin/bitcoin

Coin database inconsistencies found

Sure, this is a bug, and should be fixed. I'm just pointing out what it is related to.

bg002h

comment created time in 2 days

issue commentbitcoin/bitcoin

Coin database inconsistencies found

These are the two BIP30 exceptions, where coinbases were overwritten.

bg002h

comment created time in 2 days

pull request commentbitcoin/bitcoin

[0.21] Rate limit the processing of rumoured addresses

Hmm, now a fuzzer job times out?

sipa

comment created time in 3 days

issue commentbitcoin/bitcoin

Schnorr sig implementation diverges from the BIP340 standard

Yeah, I think so.

antonio-fr

comment created time in 3 days

issue commentbitcoin/bitcoin

Schnorr sig implementation diverges from the BIP340 standard

@achow101 The concern is a memory/CPU error during signing, because those can leak private key information. If a correctly-created signature accidentally gets corrupted there is no issue.

antonio-fr

comment created time in 3 days

issue commentbitcoin/bitcoin

Schnorr sig implementation diverges from the BIP340 standard

Hmm, but isn't it possible that a potentially corrupted signature ends up in PSBT?

antonio-fr

comment created time in 3 days

push eventsipa/bitcoin

Pieter Wuille

commit sha 33332768c7842a665679f4bcccc4504c542f09e6

Avoid Appveyor compilation failure

view details

push time in 4 days

pull request commentbitcoin/bitcoin

[0.21] Rate limit the processing of rumoured addresses

@sipsorcery @fanquake Any idea what is causing the appveyor failure here?

sipa

comment created time in 4 days

push eventsipa/bitcoin

Hennadii Stepanov

commit sha 681f728a35b800d6f1cc359171b6b40de9ddb9a4

ci: Build with --enable-werror by default, and document exceptions Github-Pull: #20182 Rebased-From: 2f6fe4e4e9e9e35e713c0a20cf891b023592110a

view details

MarcoFalke

commit sha 55e941f5df18ce6d9b1ee8759f1419c5d1f03a8f

test: Fix intermittent feature_taproot issue Github-Pull: #20535 Rebased-From: fa275e1539941b49fe206ff0bf110e3362bec6bb

view details

Pieter Wuille

commit sha 1fc214f7fdc57fa10757867a8a1e865eabe3ce47

Rate limit the processing of incoming addr messages While limitations on the influence of attackers on addrman already exist (affected buckets are restricted to a subset based on incoming IP / network group), there is no reason to permit them to let them feed us addresses at more than a multiple of the normal network rate. This commit introduces a "token bucket" rate limiter for the processing of addresses in incoming ADDR and ADDRV2 messages. Every connection gets an associated token bucket. Processing an address in an ADDR or ADDRV2 message from non-whitelisted peers consumes a token from the bucket. If the bucket is empty, the address is ignored (it is not forwarded or processed). The token counter increases at a rate of 0.1 tokens per second, and will accrue up to a maximum of 1000 tokens (the maximum we accept in a single ADDR or ADDRV2). When a GETADDR is sent to a peer, it immediately gets 1000 additional tokens, as we actively desire many addresses from such peers (this may temporarily cause the token count to exceed 1000). The rate limit of 0.1 addr/s was chosen based on observation of honest nodes on the network. Activity in general from most nodes is either 0, or up to a maximum around 0.025 addr/s for recent Bitcoin Core nodes. A few (self-identified, through subver) crawler nodes occasionally exceed 0.1 addr/s. Github-Pull: #22387 Rebased-From: 0d64b8f709b4655d8702f810d4876cd8d96ded82

view details

Pieter Wuille

commit sha 5cf36bbdee1426312c1284333f191ea5fd6f1245

Randomize the order of addr processing Github-Pull: #22387 Rebased-From: 5648138f5949013331c017c740646e2f4013bc24

view details

Pieter Wuille

commit sha d21ebf622440d63a3087509e9af7fa986463c961

Functional tests for addr rate limiting Github-Pull: #22387 Rebased-From: b4ece8a1cda69cc268d39d21bba59c51fa2fb9ed

view details

Pieter Wuille

commit sha 4e6661fe5c60f555246abec7e16287d951feb317

Add logging and addr rate limiting statistics Includes logging improvements by Vasil Dimov and John Newbery. Github-Pull: #22387 Rebased-From: f424d601e1b6870e20bc60f5ccba36d2e210377b

view details

push time in 4 days

Pull request review commentbitcoin/bitcoin

[0.21] Rate limit the processing of rumoured addresses

 struct CNodeState {     //! Whether this peer relays txs via wtxid     bool m_wtxid_relay{false}; +    /** Number of addr messages that can be processed from this peer. Start at 1 to+     *  permit self-announcement. */+    double m_addr_token_bucket{1.0};+    /** When m_addr_token_bucket was last updated */+    std::chrono::microseconds m_addr_token_timestamp{GetTime<std::chrono::microseconds>()};+    /** Total number of addresses that were dropped due to rate limiting. */+    std::atomic<uint64_t> m_addr_rate_limited{0};+    /** Total number of addresses that were processed (excludes rate limited ones). */+    std::atomic<uint64_t> m_addr_processed{0};

Agree, I may address this if I retouch.

sipa

comment created time in 5 days

PullRequestReviewEvent

push eventsipa/bitcoin

Hennadii Stepanov

commit sha f220368220abb11040fa944a853cda3d4f1fe84d

qt: Do not use QClipboard::Selection on Windows and macOS. Windows and macOS do not support the global mouse selection. Github-Pull: bitcoin-core/gui#277 Rebased-From: 7f3a5980c1d54988a707b961fd2ef647cebb4c5b

view details

Hennadii Stepanov

commit sha 6ca54ce2ae0808513172c4945e38165e766e1381

qt: Do not extend recent transaction width to address/label string Github-Pull: bitcoin-core/gui#365 Rebased-From: 9ea1da6fc91e17bdaa722001b97aadf576f07f65

view details

Hennadii Stepanov

commit sha e3f1da4bf3db120cc691a844d612fbc522f11fb9

qt: Draw "eye" sign at the beginning of watch-only addresses Github-Pull: bitcoin-core/gui#365 Rebased-From: cd46c11577a05f3dc9eac94f27a6985f6ba0509e

view details

fanquake

commit sha 997e528a34185c68665d10cef43da883934ea03a

Merge bitcoin/bitcoin#22427: [0.21] gui: Backports for 0.21.2 e3f1da4bf3db120cc691a844d612fbc522f11fb9 qt: Draw "eye" sign at the beginning of watch-only addresses (Hennadii Stepanov) 6ca54ce2ae0808513172c4945e38165e766e1381 qt: Do not extend recent transaction width to address/label string (Hennadii Stepanov) f220368220abb11040fa944a853cda3d4f1fe84d qt: Do not use QClipboard::Selection on Windows and macOS. (Hennadii Stepanov) Pull request description: Backports https://github.com/bitcoin-core/gui/pull/277, https://github.com/bitcoin-core/gui/pull/365. ACKs for top commit: fanquake: ACK e3f1da4bf3db120cc691a844d612fbc522f11fb9 jarolrod: ACK e3f1da4bf3db120cc691a844d612fbc522f11fb9 Tree-SHA512: 43cc2ac48f4e5014bfdbe86cc904bb36d2be9fcd257f0fc0800c384bd727bb98466723e450a8909b06708784ad91184be599c49cf60de2e4377202774cb878f6

view details

Hennadii Stepanov

commit sha 89426c43fb75fabd72e6e16433dab7f8ee9c860c

ci: Fix macOS brew install command Details: https://github.com/Homebrew/discussions/discussions/691 Github-Pull: #21663 Rebased-From: b7381552cd4f965c45f1560d9cfc2fb09dbfcc1d

view details

Pieter Wuille

commit sha 4534aae4f7e4bf28eb446f3d944ee9709157fad8

Rate limit the processing of incoming addr messages While limitations on the influence of attackers on addrman already exist (affected buckets are restricted to a subset based on incoming IP / network group), there is no reason to permit them to let them feed us addresses at more than a multiple of the normal network rate. This commit introduces a "token bucket" rate limiter for the processing of addresses in incoming ADDR and ADDRV2 messages. Every connection gets an associated token bucket. Processing an address in an ADDR or ADDRV2 message from non-whitelisted peers consumes a token from the bucket. If the bucket is empty, the address is ignored (it is not forwarded or processed). The token counter increases at a rate of 0.1 tokens per second, and will accrue up to a maximum of 1000 tokens (the maximum we accept in a single ADDR or ADDRV2). When a GETADDR is sent to a peer, it immediately gets 1000 additional tokens, as we actively desire many addresses from such peers (this may temporarily cause the token count to exceed 1000). The rate limit of 0.1 addr/s was chosen based on observation of honest nodes on the network. Activity in general from most nodes is either 0, or up to a maximum around 0.025 addr/s for recent Bitcoin Core nodes. A few (self-identified, through subver) crawler nodes occasionally exceed 0.1 addr/s. Github-Pull: #22387 Rebased-From: 0d64b8f709b4655d8702f810d4876cd8d96ded82

view details

Pieter Wuille

commit sha 6dec444ca2c0b80688a0f6ba9cd43e4539891749

Randomize the order of addr processing Github-Pull: #22387 Rebased-From: 5648138f5949013331c017c740646e2f4013bc24

view details

Pieter Wuille

commit sha b65129e8e38d464c0a5c2cb9ccf8a1c9ca2fd2e9

Functional tests for addr rate limiting Github-Pull: #22387 Rebased-From: b4ece8a1cda69cc268d39d21bba59c51fa2fb9ed

view details

Pieter Wuille

commit sha 651216e70b0cd1aaa1318db07e1d89d9cbb65cf3

Add logging and addr rate limiting statistics Includes logging improvements by Vasil Dimov and John Newbery. Github-Pull: #22387 Rebased-From: f424d601e1b6870e20bc60f5ccba36d2e210377b

view details

push time in 5 days

PR opened bitcoin/bitcoin

Add references for the generator/constant used in Bech32(m)

I often find myself recreating this, or looking up references for this construction. So instead, this seems like as good a place as any to place a summary.

+32 -2

0 comment

1 changed file

pr created time in 5 days

create barnchsipa/bitcoin

branch : 202107_bech32_doc

created branch time in 5 days

push eventsipa/bitcoin

Pieter Wuille

commit sha f53cbc53235a89f05f228deecbbbed9b8ae5b540

Functional tests for addr rate limiting Github-Pull: #22384 Rebased-From: b4ece8a1cda69cc268d39d21bba59c51fa2fb9ed

view details

Pieter Wuille

commit sha 55fcbde5a9fc35b187a8cb31004e5ce94bdbbedd

Add logging and addr rate limiting statistics Includes logging improvements by Vasil Dimov and John Newbery. Github-Pull: #22387 Rebased-From: f424d601e1b6870e20bc60f5ccba36d2e210377b

view details

push time in 5 days

push eventsipa/bitcoin

Pieter Wuille

commit sha b9f420246c03de177858e575bfd8862e351420d4

Functional tests for addr rate limiting Github-Pull: #22384 Rebased-From: b4ece8a1cda69cc268d39d21bba59c51fa2fb9ed

view details

Pieter Wuille

commit sha a4ae2a624432675a84bf24ea02f89141d8e16a79

Add logging and addr rate limiting statistics Includes logging improvements by Vasil Dimov and John Newbery. Github-Pull: #22387 Rebased-From: f424d601e1b6870e20bc60f5ccba36d2e210377b

view details

push time in 5 days

PR opened bitcoin/bitcoin

[0.21] Rate limit the processing of rumoured addresses

Backport of #22387.

The rate at which IP addresses are rumoured (through ADDR and ADDRV2 messages) on the network seems to vary from 0 for some non-participating nodes, to 0.005-0.025 addr/s for recent Bitcoin Core nodes. However, the current codebase will happily accept and process an effectively unbounded rate from attackers. There are measures to limit the influence attackers can have on the addrman database (bucket restrictions based on source IPs), but still - there is no need to permit them to feed us addresses at a rate that's orders of magnitude larger than what is common on the network today, especially as it will cause us to spam our peers too.

This PR implements a token bucket based rate limiter, allowing an average of 0.1 addr/s per connection, with bursts up to 1000 addresses at once. Whitelisted peers as well as responses to GETADDR requests are exempt from the limit. New connections start with 1 token, so as to not interfere with the common practice of peers' self-announcement.

Due to the lack of the Peer struct in 0.21, the relevant fields have been added to CNodeState instead, necessitating additional locks, and slightly different structure to avoid too much cs_main grabbing. The last test-improving commit has also been dropped, as the code has changed too much. Most of the behavior is still tested however, just not the part that compares with RPC statistics.

+153 -1

0 comment

7 changed files

pr created time in 6 days

create barnchsipa/bitcoin

branch : 202107_rate_limit_addr_0.21

created branch time in 6 days

pull request commentbitcoin-core/secp256k1

Replace ecmult_context with a generated static array.

utACK 8e9f75a5888a8ec549fe9026053051c3db7a1282

roconnor-blockstream

comment created time in 6 days

pull request commentbitcoin/bitcoin

cli -addrinfo: drop torv2; torv3 becomes onion per GetNetworkName()

@jonatack Ah, being consistent with existing RPCs is a good reason.

jonatack

comment created time in 8 days

pull request commentbitcoin/bitcoin

cli -addrinfo: drop torv2; torv3 becomes onion per GetNetworkName()

Do you think "onion" is clearer than "tor"?

jonatack

comment created time in 8 days

push eventsipa/bitcoin

Pieter Wuille

commit sha db16eda7e08232aee1e2733130ea3fe6e5060d85

Fixup more coders

view details

push time in 8 days

create barnchsipa/bitcoin

branch : HEAD

created branch time in 8 days

push eventsipa/bitcoin

Pieter Wuille

commit sha 7f0063178e039fb5ec0bcaabc0dd56c4db01806e

Change format

view details

push time in 8 days