Payjoin intro article #67
Conversation
thebrandonlucas
added
the
documentation
There was a problem hiding this comment.
This article covers "common input heuristic," payjoin structure, opportunistic consolidation, scaling, and payment URIs.
I'd like to rework it to focus primarily on the cost savings associated with payjoin with the following examples
- Naive transaction
- Consolidation
- Exchange cut-through
- Lightning channel opening cut-through
I am coming up with these examples now. These examples can explain scaling and cost savings at once.
I'd also like to put move as much language from passive to active voice as possible. It's just easier to read (e.g. "It is assumed", "privacy best practices can be seamlessly integrated," ...).
Thereafter I'd like to share the privacy details. I like how you write "Satoshi declared it the last unsolved privacy problem" so simply, and this should be the basis of that information. From there, the hows like Bitcoin URIs can follow. I'd like to point this front matter to software leadership who has the ability to promote the idea and actually use it. Focusing on prioritizing how Payjoin solves their problems, like fees, might be more convincing than a general overview for a general audience.
| sidebar_position: 1 | ||
| --- | ||
|
|
||
| # Introduction |
There was a problem hiding this comment.
Titles should grab attention. Even "What is Payjoin?" Would be better for search here, and we might even be able to do better.
I think it's important to recognize that this is a piece of Content Marketing and should be written as such.
There was a problem hiding this comment.
Agreed 🤝 will change this
|
|
||
|  | ||
|
|
||
| This assumption is called the [common-input-ownership heuristic](https://en.bitcoin.it/wiki/Common-input-ownership_heuristic), and even Satoshi declared it the last unsolved privacy problem in the [whitepaper](https://bitcoin.org/bitcoin.pdf). But it wasn't unsolved, just undiscovered. Because the common-input-ownership heuristic is not required, a transaction can be constructed with any number of participants spending to anyone, including to themselves. One such combination is a [CoinJoin](https://en.bitcoin.it/wiki/CoinJoin), whose primary purpose is for the participants to collaboratively construct transactions to themselves to gain privacy. But it comes at the cost of paying high fees and requires high user interaction. |
There was a problem hiding this comment.
Satoshi's problem seems to be the hook of the whole piece and I think we're in agreement that solving it is stated purpose of this project. Putting the quote in the body makes a lot of sense to me.
[L]inking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.
There was a problem hiding this comment.
Do you think we should put it here despite our reworking this to be more about cost savings/scaling than privacy? Should we save inputting this paragraph for the privacy section?
|
|
||
|  | ||
|
|
||
| This assumption is called the [common-input-ownership heuristic](https://en.bitcoin.it/wiki/Common-input-ownership_heuristic), and even Satoshi declared it the last unsolved privacy problem in the [whitepaper](https://bitcoin.org/bitcoin.pdf). But it wasn't unsolved, just undiscovered. Because the common-input-ownership heuristic is not required, a transaction can be constructed with any number of participants spending to anyone, including to themselves. One such combination is a [CoinJoin](https://en.bitcoin.it/wiki/CoinJoin), whose primary purpose is for the participants to collaboratively construct transactions to themselves to gain privacy. But it comes at the cost of paying high fees and requires high user interaction. |
There was a problem hiding this comment.
CoinJoin is convenient when getting to the technical heart of Payjoin compared to existing tech. Depending on the target audience. I'd consider building up from a typical transaction instead, show how Common Input Heuristic is a threat, and show how payjoin breaks that.
Alternatively, since savings & scaling is the unique selling point of payjoin compared to other CIH busters, it might be interesting to explore building up the article from that perspective instead, starting with typical transactions and consolidation separately and showing a fee savings as a solid number for an example off the bat.
There was a problem hiding this comment.
"Privacy without sacrificing savings" somewhere would be a good distinction. This gives me the idea that we should also have a "features" table where payjoin has most of the green check marks ("non-interactive" ✅ , no extra costs ✅ , etc.)
There was a problem hiding this comment.
Why do some of the images have double lines and other do not? Each of the 4 images has at least once instance of this discrepancy.
There was a problem hiding this comment.
Do you mean double lines like these? If so, this is just the semi-random "sketched" look that excalidraw.com, which was used to make these diagrams and is a very commonly used/popular open source tool for these sorts of things. I would be surprised if this caused confusion generally and think it's probably not a big deal, but perhaps there's configurations in excalidraw to mitigate this.
|
|
||
| # Introduction | ||
|
|
||
| Payjoin is a protocol for creating collaborative transactions between a sender (Alice) and a receiver (Bob). It is simple, requires no changes to bitcoin, can operate without any manual interaction from the user, and has a variety of benefits and use cases, including: |
There was a problem hiding this comment.
The first sentence has to be a hook. Parentheticals are important caption information for the image, but don't add to a compelling reason to keep reading. The list of reasons why is good but perhaps should be summarized and then ordered as they will follow in the article to prepare a reader for what is to come.
There was a problem hiding this comment.
I agree, I fronted "Alice" and "Bob" here so that the user would have context for the rest of the article, but they feel distracting here. Also totally agree with having brief summaries on the list of reasons
| - **Scaling** | ||
| - **Flexibility & Extensibility** | ||
|
|
||
| In a typical on-chain bitcoin transaction, all of the [UTXOs](https://unchained.com/blog/what-is-a-utxo-bitcoin/) would belong to Alice. After all, one might ask, what sense does it make for Bob to send bitcoin to himself? It is _assumed_ that the spender in a transaction is the one who owns every UTXO: |
There was a problem hiding this comment.
A link is good, but any abbreviation / acronym should be stated in full followed by the abbreviation in parens to use further down the article. e.g. "Unspent Transaction Outputs (UTXOs)." A brief explanation of how bitcoin uses UTXOs seems necessary to proceed with technical details.
What purpose does the double "After all, one might ask" serve? Would fewer words do?
Why is assumed italicized?
There was a problem hiding this comment.
any abbreviation / acronym should be stated in full followed by the abbreviation in parens to use further down the article.
Yes! Good catch.
A brief explanation of how bitcoin uses UTXOs seems necessary to proceed with technical details.
Can do.
What purpose does the double "After all, one might ask" serve? Would fewer words do?
It was intended to emphasize that it's unnatural to think of UTXOs belonging to more than one owner and contrasts that with the previous sentence as being the natural thing to do. Just saying "What sense does it make..." feels to not get enough of the point across to me that the reader would also naturally think Bob wouldn't send the bitcoin to himself just like a chain analysis company. I agree that "one might ask" is over the top though, perhaps we can reduce to:
"After all, what sense does it make..."
Why is assumed italicized?
Because I have an overzealous love of em_PHA_sis. Will remove 😄
|
|
||
|  | ||
|
|
||
| This assumption is called the [common-input-ownership heuristic](https://en.bitcoin.it/wiki/Common-input-ownership_heuristic), and even Satoshi declared it the last unsolved privacy problem in the [whitepaper](https://bitcoin.org/bitcoin.pdf). But it wasn't unsolved, just undiscovered. Because the common-input-ownership heuristic is not required, a transaction can be constructed with any number of participants spending to anyone, including to themselves. One such combination is a [CoinJoin](https://en.bitcoin.it/wiki/CoinJoin), whose primary purpose is for the participants to collaboratively construct transactions to themselves to gain privacy. But it comes at the cost of paying high fees and requires high user interaction. |
There was a problem hiding this comment.
"[Common-input-ownership heuristic] wasn't unsolved, just undiscovered" ? What does this mean? Doesn't Satoshi declare it to be a problem right off the bat?
I like "batched" or "batch" transaction more than "collaborative." It's a simpler word that gets the point across more concretely and has less magic aura over it.
There was a problem hiding this comment.
But it wasn't unsolved, just undiscovered.
I remember thinking this was cool when I wrote it, but have no idea what it means now. Whoops. Will remove.
I like "batched" or "batch" transaction more than "collaborative."
Agreed 🤝
|
|
||
| ### Cost & Time Savings | ||
|
|
||
| Payjoin can save money and time by batching transactions when fees are low. Most wallets default to [address reuse](https://en.bitcoin.it/wiki/Address_reuse) (as they should!). This however results in more UTXOs when spending a transaction. Since the scarce resource in Bitcoin is block space, the [fee](https://unchained.com/blog/bitcoin-transaction-fees/) paid (in satoshis) in a transaction is measured relative to the number of bytes in the transaction, i.e. satoshis per byte or [satoshis per virtual byte](https://bitcoin.stackexchange.com/questions/89385/is-there-a-difference-between-bytes-and-virtual-bytes-vbytes). So if you have many small UTXOs, you're likely to have to combine some to make larger payments, which results in higher fees. Therefore, you should periodically [consolidate UTXOs](https://unchained.com/blog/too-many-bitcoin-utxos/) by sending them to a new address you own when fees are low. |
There was a problem hiding this comment.
why should most wallets default to address reuse? And why does that result in more UTXOs (and more than what?)
passive voice "the fee ... is measured" could be active
There was a problem hiding this comment.
why should most wallets default to address reuse? And why does that result in more UTXOs (and more than what?)
Jeez, I meant the exact opposite of what I actually wrote here. My mistake for not catching this obvious mistake on reread. What I meant was:
Most wallets default to generating new addresses for every payment to avoid address reuse (as they should!)
Will fix
|
|
||
| Payjoin can save money and time by batching transactions when fees are low. Most wallets default to [address reuse](https://en.bitcoin.it/wiki/Address_reuse) (as they should!). This however results in more UTXOs when spending a transaction. Since the scarce resource in Bitcoin is block space, the [fee](https://unchained.com/blog/bitcoin-transaction-fees/) paid (in satoshis) in a transaction is measured relative to the number of bytes in the transaction, i.e. satoshis per byte or [satoshis per virtual byte](https://bitcoin.stackexchange.com/questions/89385/is-there-a-difference-between-bytes-and-virtual-bytes-vbytes). So if you have many small UTXOs, you're likely to have to combine some to make larger payments, which results in higher fees. Therefore, you should periodically [consolidate UTXOs](https://unchained.com/blog/too-many-bitcoin-utxos/) by sending them to a new address you own when fees are low. | ||
|
|
||
| Payjoin performs a consolidation on _every_ payment. While wallets today make this a manual, interactive experience, this can easily be the default for wallets that integrate Payjoin. Bitcoin users wouldn't have to worry about taking this extra step as it can be automated for them. |
There was a problem hiding this comment.
Does payjoin consolidate on every payment? Does that exclude cut-through?
There was a problem hiding this comment.
Oh, it definitely doesn't necessarily, this was just my mental model when writing this for some reason. Good catch.
|
|
||
| ### Flexibility & Extensibility | ||
|
|
||
| Because Payjoin utilizes [BIP 21](https://bitcoinqr.dev/) payment URIs, parameters related and unrelated to Payjoin can be used and understood by wallets. The use of BIP 21 allows wallets that don't support Payjoin to fallback to regular transactions, allows for the configuration of the many [Payjoin-specific parameters](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#bip21-Payjoin-parameters), as well as parameters outside the Payjoin protocol or ones yet-to-be created. |
There was a problem hiding this comment.
passive
"parameters related and unrelated to Payjoin can be used and understood by wallets"
active
"Wallets can use and understand parameters related and unrelated to payjoin"
concise
"Wallets can select a payment method they support from a list"
|
@DanGould Thanks for this amazing & thorough review. Wish I'd caught all this while writing it and these are all great suggestions. Before implementing these changes, would it be best to simply rewrite the article, removing the technical details here to a different article and just showing them scaling/savings examples off the bat, then moving into high level "how it works" in a separate article right after? How do you see what you wrote here fitting in? |
|
I'm inclined to combine some elements you have here, like the sketches with the savings-first article in #69. I'd like to split out what's here on privacy and expand upon that because I think that's the strongest kernel of this piece. Not sure if scaling / extensibility / flexibility belong here in an article or as part of an expanded FAQ or something else. Let's plan to discuss in person or by phone when you get settled. |
|
What's the status of this since #69 was added? |
After rereading, I believe this should be rewritten in light of the new articles added. I think the diagrams and explanations are still very valuable and very much think we should have an "intro" page, but our marketing focus has changed since this was written. I'll take another look at this, propose a new content-structure to you, then do a rewrite. |
Adds an overview article that will live at payjoin.org/docs/intro explaining the high-level benefits along with a basic explanation of how it works. Also includes diagrams for visual illustration as well.
Would love edits/review.
