Is it really necessary to have inputs in transactions?

[hidecoin2016]

Is it really necessary to have inputs in transactions?

I think that inputs in transactions are extra waste of space. We can just use blockchain state:

Now in Bitcoin

ADDR1 PRIVATE_KEY1 2 BTC TRANSACTIONS 1. 0.4 BTC, 2. 0.4 BTC, 3. 0.4 BTC, 4. 0.4 BTC, 5. 0.4 BTC
ADDR2 PRIVATE_KEY2 5 BTC TRANSACTIONS 1. 1 BTC, 2. 4 BTC

Sending to ADDR3 2 BTC from two addresses:

TRANSACTION
INS:
ADDR1 #1, #2, #3 (1.2 BTC) PRIVATE_KEY1
ADDR2 #1 (1 BTC) PRIVATE_KEY2

OUTS:
ADDR3 2 BTC
ADDR1 0.2 BTC (return)

How could it be

ADDR1 PRIVATE_KEY1 STATE 2 BTC
ADDR2 PRIVATE_KEY2 STATE 5 BTC

Sending to ADDR3 2 BTC from two addresses:

TRANSACTION
PAYMENTS:
ADDR1 1 BTC PRIVATE_KEY1
ADDR2 1 BTC PRIVATE_KEY2

OUTS:
ADDR3 2 BTC
ADDR1 0.2 BTC (return)

CHANGING STATE TO:
ADDR1 1 BTC
ADDR2 4 BTC

What do you think?

[1714077078]

1714077078

[1714077078]

1714077078

[1714077078]

1714077078

[1714077078]

1714077078

[LittleBitFunny]

Try moving this thread to Development and Technical Discussion if you want some decent answers.

[DannyHamilton]

Your solution is vulnerable to replay attacks.

Alice pays address 1Bob for his monthly paycheck
Bob uses the 1Bob coin to pays address 1Carol for dinner

Alice pays address 1Bob again his next paycheck
Mallory shows up and replays the transaction where 1Bob is paid to 1Carol

Bob is sad.

There are many other cases like this. If you address all of the one by one, you just end up with an inefficient and inflexible version of the UTXO model.

[hidecoin2016]

Your solution is vulnerable to replay attacks.

Alice pays address 1Bob for his monthly paycheck
Bob uses the 1Bob coin to pays address 1Carol for dinner

Alice pays address 1Bob again his next paycheck
Mallory shows up and replays the transaction where 1Bob is paid to 1Carol

Bob is sad.

There are many other cases like this. If you address all of the one by one, you just end up with an inefficient and inflexible version of the UTXO model.

You are not able to send the same coins two times because every node controls blockchain state.

[DannyHamilton]

Your solution is vulnerable to replay attacks.

Alice pays address 1Bob for his monthly paycheck
Bob uses the 1Bob coin to pays address 1Carol for dinner

Alice pays address 1Bob again his next paycheck
Mallory shows up and replays the transaction where 1Bob is paid to 1Carol

Bob is sad.

There are many other cases like this. If you address all of the one by one, you just end up with an inefficient and inflexible version of the UTXO model.

You are not able to send the same coins two times because every node controls blockchain state.

But your solution doesn't have inputs.  Therefore there is no indication in the transaction WHICH coins are being spent.  It just says to send some coins from an address to another address. It doesn't way anything about which ones:

Sending to ADDR3 2 BTC from two addresses:

TRANSACTION
PAYMENTS:
ADDR1 1 BTC PRIVATE_KEY1
ADDR2 1 BTC PRIVATE_KEY2

OUTS:
ADDR3 2 BTC
ADDR1 0.2 BTC (return)

CHANGING STATE TO:
ADDR1 1 BTC
ADDR2 4 BTC

What do you think?

You show "Payments" of:

• ADDR1 1 BTC
• ADDR2 1 BTC

Later, that same transaction can be sent again, and it will spend DIFFERENT coins taking 1 BTC from ADDR1 AGAIN, and 1 BTC from ADDR2 AGAIN.

[hatshepsut93]

Your solution is vulnerable to replay attacks.

Alice pays address 1Bob for his monthly paycheck
Bob uses the 1Bob coin to pays address 1Carol for dinner

Alice pays address 1Bob again his next paycheck
Mallory shows up and replays the transaction where 1Bob is paid to 1Carol

Bob is sad.

There are many other cases like this. If you address all of the one by one, you just end up with an inefficient and inflexible version of the UTXO model.

You are not able to send the same coins two times because every node controls blockchain state.

For example, you have an address with 2 Bitcoins, you broadcast transaction that sends 1 Bitcoin to Alice, but then Alice just broadcasts the same transaction again to steal your second coin. This transaction will be valid as long as the amount is lower or equal to the balance of an address. The reason why this is works is because in your model when addresses are like accounts, there is no way to distinguish different coins, so every address has to be used only once for sending. This would create a lot of problem for those who use static addresses, like services that have deposit addresses for their customers or people who accept donations.

[hidecoin2016]

Your solution is vulnerable to replay attacks.

Alice pays address 1Bob for his monthly paycheck
Bob uses the 1Bob coin to pays address 1Carol for dinner

Alice pays address 1Bob again his next paycheck
Mallory shows up and replays the transaction where 1Bob is paid to 1Carol

Bob is sad.

There are many other cases like this. If you address all of the one by one, you just end up with an inefficient and inflexible version of the UTXO model.

You are not able to send the same coins two times because every node controls blockchain state.

For example, you have an address with 2 Bitcoins, you broadcast transaction that sends 1 Bitcoin to Alice, but then Alice just broadcasts the same transaction again to steal your second coin. This transaction will be valid as long as the amount is lower or equal to the balance of an address. The reason why this is works is because in your model when addresses are like accounts, there is no way to distinguish different coins, so every address has to be used only once for sending. This would create a lot of problem for those who use static addresses, like services that have deposit addresses for their customers or people who accept donations.

We can prohibit identical transactions with the same hashes. We can make field NONCE and if I want to send 1 more BTC to Alice, I will change NONCE and sign new transaction. But Alice will be not able to repeat my transaction because she is not able to sign transaction with another NONCE.

[DannyHamilton]

We can prohibit identical transactions with the same hashes. We can make field NONCE and if I want to send 1 more BTC to Alice, I will change NONCE and sign new transaction. But Alice will be not able to repeat my transaction because she is not able to sign transaction with another NONCE.

So, instead of just storing the unspent transaction outputs (UTXO) to be used to determine if a transaction is valid, now every node needs to scan a complete list of every transaction in the blockchain every time it needs to validate a transaction?  That's not going to work.  Nodes receive hundreds of transactions per minute.  If the node has to rescan the entire history of transactions hundreds of times per minute to validate that transaction hashes haven't been used before it isn't going to be able to keep up.

You can keep adding more and more conditions and processes to handle all of the edge cases that you aren't thinking of.  You'll find I already quoted gmaxwell about this earlier in this thread. By the time you are all done...

- snip -

- snip -
There are many other cases like this. If you address all of the one by one, you just end up with an inefficient and inflexible version of the UTXO model.

[hidecoin2016]

every node needs to scan a complete list of every transaction in the blockchain every time it needs to validate a transaction?

Every node validates EVERY input of transaction, it means that 1 input = 1 transactions search. 100 inputs = 100 searches.
My model: no inputs -> 1 search.

[DannyHamilton]

every node needs to scan a complete list of every transaction in the blockchain every time it needs to validate a transaction?

Every node validates EVERY input of transaction, it means that 1 input = 1 transactions search. 100 inputs = 100 searches.

Correct, but it only needs to search through the UTXO. (The very limited list of unspent transaction outputs).

The node only needs to do a full blockchain scan once, when building the UTXO list during synchronization.  Then it's 100 very fast searches through a short list.

My model: no inputs -> 1 search.

That's 1 search through a list of every transaction in the entire blockchain every time it needs to validate a transaction, just to see if that transaction has ever existed before.

Additionally, it needs to maintain and scan a separate database of every address and the current balance of each address, just to see if there are enough bitcoins available.

Inputs solve both of those problems quickly and efficiently with a single fast search.

While you are thinking about that, how would your system handle the bitcoin scripting system that allows for multi-sig and other useful extensions?  Are you suggesting we just abandon that feature?