<p>Advantages of UTXO/blockchain approach:</p>

<ol>
<li>You don't have to pay to addresses that refer to accounts. Transactions can pay to unique rules or conditions that can exist only as the rule to claim a particular transaction output.</li>
<li>Transactions are more independent in execution, not contending for access to the same account structures.</li>
<li>All you need to know about a transaction is that it succeeded. There's no "additional information" such as the previous balance and the new balance.</li>
</ol>

<p>Advantages of account/ledger approach:</p>

<ol>
<li>Accounts exist as primary structures and so can have properties, both persistent/configured and dynamic/reported.</li>
<li>Transactions are more independent in formation, not contending for access to the same transaction outputs.</li>
<li>There is no UTXO database to maintain and synchronize and attacks on the UTXO set do not work. (Though there are other ways you can defend against attacks of this type.) More sophisticated transactions can be supported without creating the risk of disagreement on the UTXO set.</li>
</ol>

<p>Bitcoin's design naturally fits the UTXO approach. Transaction results are simple, and there's no need for account parameters.</p>

<p>That approach would not have worked in Ripple for a variety of reasons:</p>

<ol>
<li><p>Because Ripple supports arbitrary assets, many of which can be worthless, there has to be a way for recipients to indicate which assets they'll accept as payment. This means something has to have that as a property, which requires an account.</p></li>
<li><p>Something has to issue those assets, which requires accounts to act as issuers.</p></li>
<li><p>Cross-currency payments can produce complex results, trying to map those deterministically onto UTXO operations is not a natural fit. Adjusting an account's balance is simpler than choosing UTXO's to consume and create at transaction processing time. Ripple's transactions could not have, for example, specified which UTXOs they'd consume because that isn't known at transaction formation time. (How do you know know who will offer the best rate when your transaction executes? If everyone competes with transactions hardcoded for the juiciest liquidity, the majority of transactions will fail.)</p></li>
<li><p>The more complex network state requires a more complex structure to ensure the network agrees on that state. Bitcoin's structure has no way to protect against UTXO divergence, which would be catastrophic, other than keeping transactions simple enough that a mistake of this type is unlikely. Ripple's more complex transactions need a powerful defense against divergence or small bugs in the code could cause catastrophic results.</p></li>
<li><p>Because Ripple transactions have more complex outputs, they tend to be larger. Ripple's approach makes it easier to discard transaction history because all you really need is the current status of all accounts and other persistent structures.</p></li>
</ol>

<p>You can pretty much meet any requirements with either approach. There are ways to work around each of these issues without changing the approach. But it's often easier to start with the design that most naturally fits your requirements, rather than shaving and jamming to get a round peg into a square hole.</p>

CC BY-SA 3.0
2016-06-16T07:57:06.997Z
2016-06-16T08:20:03.507Z
2016-06-16T08:20:03.507Z
David Schwartz
<p>In Bitcoin, the transaction inputs (UTXOs) are specified as a tuple (transaction index, vout) since there is no notion of an account in the bitcoin system and the address (pointed to by vout) alone would not be sufficient. Instead transactions are primary entities.</p>
<p>Ripple on the other hand makes an account a primary entity with transactions changing the account balance. This makes it possible to specify the (account) address alone as an input to a transaction.</p>
<p>These are design decisions. <strong>What are the pros and cons of the two models? What was the motivation behind them?</strong></p>

CC BY-SA 3.0
2016-06-16T10:17:00.893Z
Nit: `vout` is just the index of an output in the output list of a transaction. It's just an integer. The address is part of the output script that is contained in the UTXO. The tuple that you are referring to is the unique identifier of a UTXO, not the complete UTXO.
Murch
<transactions><address><ripple><utxo>
Specification of Transaction Inputs - Bitcoin vs Ripple
Ni9elF
# Specification of Transaction Inputs - Bitcoin vs Ripple

(Asked by: username_0 on 2016-06-16)

In Bitcoin, the transaction inputs (UTXOs) are specified as a tuple (transaction index, vout) since there is no notion of an account in the bitcoin system and the address (pointed to by vout) alone would not be sufficient. Instead transactions are primary entities.

Ripple on the other hand makes an account a primary entity with transactions changing the account balance. This makes it possible to specify the (account) address alone as an input to a transaction.

These are design decisions. **What are the pros and cons of the two models? What was the motivation behind them?**

**Tags:** transactions, address, ripple, utxo

> **Comments:**
> **username_1**: Nit: `vout` is just the index of an output in the output list of a transaction. It's just an integer. The address is part of the output script that is contained in the UTXO. The tuple that you are referring to is the unique identifier of a UTXO, not the complete UTXO.  

---

## 1 answers

### Answer by username_2 on 2016-06-16. Score: 3 | Accepted answer

Advantages of UTXO/blockchain approach:

1. You don't have to pay to addresses that refer to accounts. Transactions can pay to unique rules or conditions that can exist only as the rule to claim a particular transaction output.
2. Transactions are more independent in execution, not contending for access to the same account structures.
3. All you need to know about a transaction is that it succeeded. There's no "additional information" such as the previous balance and the new balance.

Advantages of account/ledger approach:

1. Accounts exist as primary structures and so can have properties, both persistent/configured and dynamic/reported.
2. Transactions are more independent in formation, not contending for access to the same transaction outputs.
3. There is no UTXO database to maintain and synchronize and attacks on the UTXO set do not work. (Though there are other ways you can defend against attacks of this type.) More sophisticated transactions can be supported without creating the risk of disagreement on the UTXO set.

Bitcoin's design naturally fits the UTXO approach. Transaction results are simple, and there's no need for account parameters.

That approach would not have worked in Ripple for a variety of reasons:

1. Because Ripple supports arbitrary assets, many of which can be worthless, there has to be a way for recipients to indicate which assets they'll accept as payment. This means something has to have that as a property, which requires an account.
2. Something has to issue those assets, which requires accounts to act as issuers.
3. Cross-currency payments can produce complex results, trying to map those deterministically onto UTXO operations is not a natural fit. Adjusting an account's balance is simpler than choosing UTXO's to consume and create at transaction processing time. Ripple's transactions could not have, for example, specified which UTXOs they'd consume because that isn't known at transaction formation time. (How do you know know who will offer the best rate when your transaction executes? If everyone competes with transactions hardcoded for the juiciest liquidity, the majority of transactions will fail.)
4. The more complex network state requires a more complex structure to ensure the network agrees on that state. Bitcoin's structure has no way to protect against UTXO divergence, which would be catastrophic, other than keeping transactions simple enough that a mistake of this type is unlikely. Ripple's more complex transactions need a powerful defense against divergence or small bugs in the code could cause catastrophic results.
5. Because Ripple transactions have more complex outputs, they tend to be larger. Ripple's approach makes it easier to discard transaction history because all you really need is the current status of all accounts and other persistent structures.

You can pretty much meet any requirements with either approach. There are ways to work around each of these issues without changing the approach. But it's often easier to start with the design that most naturally fits your requirements, rather than shaving and jamming to get a round peg into a square hole.


---

