Eclipse attacks occur when a node is not connected to any honest peers on the network, and instead its peer connections are controlled by an adversary. Once denied connectivity to the honest network, a victim can be attacked in numerous ways, such as with double-spends or funds loss on layer 2 systems (such as the Lightning Network). Mining nodes attacked in this way can be forced to waste hashpower or be commandeered in selfish mining attacks, or generally aid in causing forks on the network.
This document attempts to describe the mechanisms implemented in Bitcoin Core to mitigate eclipse attacks followed by open questions and areas of further research.
A restart-based eclipse attack occurs when the adversary is able to sufficiently saturate the victim's address manager with attacker IPs (a.k.a. addrman flooding), and then the victim restarts. If the attack succeeds, the victim will lose its current outgoing connections due to the restart and be more lik
- MuSig
- MuSig-DN
- Elligator Squared for BN
- Countersign
- https://github.com/bitcoin-core/secp256k1
- patent expired, enabling libsecp256k1 to enable a 27% optimization
- Version 2 Peer-to-Peer Message Transport Protocol
- Taproot In The Generic Group Model
- Formalizing adaptor signatures
- Design for witness asymmetric channel construction (lightning)
This is not an exhaustive list. This is mostly from looking at PRs or IRC meetings. Any mistakes are my own.
- [MERGED] 0.19: Add txids with non-standard inputs to reject filter #19681
- [MERGED] 0.20: Add txids with non-standard inputs to reject filter #19680
- 0.20: Backport wtxid relay #19606
- bitcoin/bitcoin#19569 (comment) (to be opened by jnewbery) with #19610
- [MERGED] Transaction overhaul (#19184 - sipa) (Review by sdaftuar, ajtowns, ariard)
Q: In this video, John Newbery talks about verification vs computation, and he bring it up as a big reason why he thinks bitcoin can scale but is skeptical about ethereum. I think I get the general idea of what he’s saying but I might be missing something.
Is there a qualitative difference between verification and computation? And is it the fact that ethereum is capable of performing arbitrary computation that makes the whole thing difficult to scale, or is it that specifically smart contracts that require arbitrary computation won’t be able to scale (as in those contracts would be very expensive to run).
A: There is a big difference between verification and computation.
For instance:
- given the prime number 11,121,415,581,673,924,441, compute its prime factorisation.
- given the prime number 11,121,415,581,673,924,441, verify that 3,226,079,203 and 3,447,347,347 are its factors.
bitcoin/bitcoin#16401 - package relay
bitcoin/bitcoin#16702 - asmap to improve bucketing
bitcoin/bitcoin#16974 - Walk pindexBestHeader back to ChainActive().Tip() if it is invalid
bitcoin/bitcoin#16856 - Do not allow descendants of BLOCK_FAILED_VALID blocks to be BLOCK_FAILED_VALID
bitcoin/bitcoin#16939 - p2p: Delay querying DNS seeds if addrman is populated
Error:
>>> [do_build] Command failed: git apply /Users/jonas/bitcoin-dir/bitcoin-maintainer-tools/patches/stripbuildinfo.patch
>>> [do_build] Could not apply patch to strip build info. Probably it needs to be updated
Checkout the patchset from the last patch:
git checkout 'master@{aug 1}'
src :
- https://joost.vunderink.net/blog/2011/12/02/irssi-tricks-navigating-around/
- https://www.linode.com/docs/applications/messaging/using-irssi-for-internet-relay-chat
Let’s start by what you can do while typing. These keystrokes change only what happens on the input line (the line where you type stuff).
arrow left/right: move one character left or right.
Fungibility/Privacy: | |
Scalability: | |
Trustlessness/Decentralization: |
1) How can Gossip protocol be exploited to leak privacy? | |
2) How do BOLT 11 strings potentially leak privacy? | |
3) What is the minimal amount of info watchtowers need to know to work? | |
4) How can we minimize what is broadcasted to the base layer and how can the base layer leak our privacy? |