Difference between Transactions and Payments

[johnsBeharry]

How to name things especially when there can be conflicts with common knowledge.

1. Transactions in bitcoin represent a technical thing, a smart contract.
2. Transactions to someone outside bitcoin usually refer to a list of payments.
3. Transactions in bitcoin can contain multiple payments (see batched payments).
4. Lightning network uses transactions for channel creations (multi-sig, funding) as well as destructions.
5. Lightning Network, developers refer to the movement of funds on lightning as payments.

Proposal for the Bitcoin Design Guide

• Transaction refers to the smart contract.
• Payment refers to the movement of funds to fullfill a purpose.

Rationale

• Payment is common between bitcoin lightning and on-chain
• Payment also captures user intent, in the guide we can have payment user flows for donations, or paying merchants.
• Lightning should be seen as bitcoin not separate network.

Method

Examples of how this would be applied in the guide.

• Lightning Payments are instant
• Payment Channels are created by locking up bitcoin using an on-chain transaction
• A company can save fees if they create a single transaction to batch salary payments to its employees at the end of the month.
• A wallet which supports both lightning and on-chain should list the individual payments of a batched transaction along with any lightning payments they have received. Otherwise the user would need to lookup the individual transaction then open it to see the list payments.
• Payment Requests allow a payer's wallet to know how to route a payment to you. They are often shared as text or a QR Code image for both Lightning Payments and on-chain.
• You can send a payment request on Lightning with an on-chain address encoded. This would allow the payer, or their wallet to choose which method they would like to use to make the payment.

Edit: Also it would add clarity to #62 (comment) since the flow of creating a transaction (smart contract context) is not as linear, though making a payment is closer to what is suggested.

Seeking ACKs/NACKs

[pavlenex]

Very complex topic. I am not sure if we'd be able to simplify things this much, however to understand this better, could you provide a bit more examples.

Personally I can't either ack or nack this for now, because I don't think it'll be easy to make changes like this, especially for the on-chain where people have been using terminology for 10+ years, and to switch it just because LN refers to things differently... I can't agree that a transaction should be used in smart-contract context only. From what I was able to understand, this would mean that payments can only happen on the layer two?

One more question, when you say

Lightning Network does not have transactions, developers refereed to the movement of funds as payments.

Are you referring to a particular implementation, I'm not sure I've seen this one being standardized like that.

I like the Examples, but would appreciate some concrete ones. For example, providing a sentence that puts these words in context.

[johnsBeharry]

Personally I can't either ack or nack this for now, because I don't think it'll be easy to make changes like this, especially for the on-chain where people have been using terminology for 10+ years, and to switch it just because LN refers to things differently

1. The scope for this reference is the content of this guide addressing how we communicate these concepts to designers
2. We already take similar considerations in private key management Multi Sig -> Shared multi-key, Seedless -> Automatic cloud backup
3. This is not an attempt to introduce anything new just to standardise how we communicate to readers internally

From what I was able to understand, this would mean that payments can only happen on the layer two?

Not at all. Payments happen inside of on-chain transactions. Technically they are outputs. As stated "Transactions in bitcoin can contain multiple payments" referring to on-chain transactions.

Are you referring to a particular implementation, I'm not sure I've seen this one being standardized like that.

Language is certainly difficult to standardise. I don't think it's stated specifically in any implementation or spec. It's something we can and should agree on for the guide though.

Anyway here are some references I selected to demonstrate how payments and transactions are used else where. I'm sure you can find others to dispute the proposal. The beauty of language.

Instant Payments. Lightning-fast blockchain payments without worrying about block confirmation times. Security is enforced by blockchain smart-contracts without creating a on-blockchain transaction for individual payments. Payment speed measured in milliseconds to seconds.

https://lightning.network/

The Lightning Network is a "layer 2" payment protocol that operates on top of a blockchain-based cryptocurrency (like bitcoin). It is intended to enable fast transactions among participating nodes and has been proposed as a solution to the bitcoin scalability problem.

https://en.wikipedia.org/wiki/Lightning_Network

The Lightning Network scales blockchains and enables trustless instant payments by keeping most transactions off-chain and leveraging the security of the underlying blockchain as an arbitration layer.

https://docs.lightning.engineering/conceptual-overview/overview-overview/lightning-network

high-frequency spenders can use the scaling technique of payment batching to reduce transaction sizes and fees by about 75% in practical situations. As of February 2019, payment batching is used by multiple popular Bitcoin services (mainly exchanges), is available as a built-in feature of many wallets (including Bitcoin Core), and should be easy to implement in custom wallets and payment-sending solutions. On the downside, use of the technique can lead to temporary unexpected behavior for the receivers of payments, a possible inability to fee bump, and may result in a reduction of privacy

https://bitcoinops.org/en/scaling/payment-batching/

It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in.

Bitcoin Whitepaper

[pavlenex]

Thanks for clarifying, I'm not trying to dispute the proposal, just want to better understand the context in which you're suggesting this is used, as I didn't quite get it from the op. You've certainly tapped into this problem way more in-depth than I have 😃

I'll have to think about this more, as distinction is still muddy to me. But those examples LGTM.

[GBKS]

Good to clarify this in the context of the guide. I think we have to differentiate between four terminologies:

1. Technical terms for things (hard to change, baked into the tech, maybe made sense at the time and not today, etc)
2. Ecosystem terms (all the random things people call stuff, we can clarify in the glossary via a.k.a.)
3. Guide terms (probably a mix of 1 and 2) that should be internally coherent and follow todays best practices, embodied in the glossary
4. User terms (what makes sense to end users in the context of their use cases)

Since we're focusing on user-centered design, I'd generally prefer more user-focused terminology (4) over tech lingo (1).

[Bosch-0]

Agree with @GBKS. I like to lean towards just referring to layer 1 and 2 both as payments - just sounds more plain English and it is good to not distinguish Bitcoin and LN too much. Muun has great UI around molding these two networks.

I noticed that the terminology is jumped back a forth a bit in the Payments section which I find confusing btw @johnsBeharry. Are you eventually going to settle for one? e.g. the 'Transaction Privacy' page first sentence refers to Bitcoin Payments - is this using the proposed terminology in OP? Maybe it should be called Payments privacy.

[Bosch-0]

We should define Transactions vs. Payments in https://bitcoin.design/guide/payments/transactions/.

[Bosch-0]

Lightning should be seen as bitcoin not separate network.

I think we can communicate that they both use bitcoin but are also separate networks with different trade-offs. Not distinguishing is confusing. Saying they are the same would make people think they could send from on-chain -> Lightning invoice for example which isn't possible.

My 2c on defining things is this:

• Transaction: Refers to the smart contract, or to put it more simply what variables are involved in a value transfer (amount, UTXOs used etc).
• Transfer: Refers to on-chain value transfers. A transfer could also refer to moving between on-chain and LN
• Payments: Refers to LN value transfers which are most likely your regular day-to-day spends.

Below is a comment I made here regarding defining 'Transfers' and 'Payments.'

I agree, LN and payments are synonymous to me whilst on-chain is for savings and transfers type value movements. A money transfer doesn't usually encompass standard payments you make to buy goods and services, hence we should refer to an on-chain sends as transfers and lightning sends as payments. A lot of grey areas here but that's how traditional finance defines these things so people wouldn't have too hard a time grasping the distinction imo. It's better to distinguish these networks by their use cases, calling them both payments when they serve different purposes is way too general and confusing.