- More scalable/faster than a blockchain (not enough utxos)
- Much better privacy security model than a blockchain
- Same or better theft security model than TTP but much worse than a blockchain
If it's so great, why hasn't it been done yet?
If it's so great, why hasn't it been done yet?
Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead.
Update: This now has a BIP and WIP implementation
The recipient generates a so-called silent payment address and makes it publicly known. The sender then takes a public key from one of their chosen inputs for the payment, and uses it to derive a shared secret that is then used to tweak the silent payment address. The recipient detects the payment by scanning every transaction in the blockchain.
Hi there,
I'm writing to propose a set of mempool policy changes to enable package validation (in preparation for package relay) in Bitcoin Core. These would not be consensus or P2P protocol changes. However, since mempool policy significantly affects transaction propagation, I believe this is relevant for the mailing list.
My proposal enables packages consisting of multiple parents and 1 child. If you develop software that relies on specific transaction relay assumptions and/or are interested in using package relay in the future, I'm very interested to hear your feedback on the utility or restrictiveness of these package policies for your use cases.
A draft implementation of this proposal can be found in [Bitcoin Core PR#22290][1].
25/5/2020
Imagine a future where a user Alice has bitcoins and wants to send them with maximal privacy, so she creates a special kind of transaction. For anyone looking at the blockchain her transaction appears completely normal with her coins seemingly going from address A to address B. But in reality her coins end up in address Z which is entirely unconnected to either A or B.
Now imagine another user, Carol, who isn't too bothered by privacy and sends her bitcoin using a regular wallet which exists today. But because Carol's transaction looks exactly the same as Alice's, anybody analyzing the blockchain must now deal with the possibility that Carol's transaction actually sent her coins to a totally unconnected address. So Carol's privacy is improved even though she didn't change her behaviour, and perhaps had never even heard of this software.
Moved to https://github.com/fjahr/debugging_bitcoin to allow for better collaboration.
This document is currently optimized for MacOS. If you would like to help me add Linux equivalent commands, please let me know.
This guide is designed to give beginners of C++ development and/or people new to the bitcoin core code base an overview of the tools available for debugging issues as well as giving hints where issues may trip you up.
This is a description of how I write tech articles for various blogs. Hopefully someone else will find this useful as well.
When I begin writing a new article, I create a new [GitHub Gist][gist] for the article files. The Gist contains a file for the article text and code examples related to the article.
A description of known problems in Satoshi Nakamoto's paper, "Bitcoin: A Peer-to-Peer Electronic Cash System", as well as notes on terminology changes and how Bitcoin's implementation differs from that described in the paper.
The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.
Locate the section for your github remote in the .git/config file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this: