Transaction inputs and outputs not needed?

[eugene111]

Hi, guys
Is bitcoin transaction inputs and outputs something which is absolutely needed? As to me it would be much simpler if we used just a transaction, which maintains the number of transferred money. So we have spent and unspent (spent is the one on which a reference from another transaction exists) transactions and instead of a new output we just create a new transaction. Maybe l miss something  in this concept?

[1714841291]

1714841291

[1714841291]

1714841291

[1714841291]

1714841291

[Xynerise]

Bitcoin has always used an UTXO system, so yes, outputs and inputs are absolutely needed.
If bitcoin is to change to an account-based system a la Ethereum, it would require a hardfork, so yeah, not happening.

[eugene111]

Bitcoin has always used an UTXO system, so yes, outputs and inputs are absolutely needed.
If bitcoin is to change to an account-based system a la Ethereum, it would require a hardfork, so yeah, not happening.

Yes I understand that changing UTXO in bitcoin is rather impossible.My question is more general.Is there something vital and critical in UTXO system for blockchain security and stability or UTXO it's rather some historical heritage with which bitcoin must live?

[Xynerise]

UTXO system Is more private as it discourages address reuse while account based systems like Ethereum inadvertently incentivize it.

Also, account-based systems like Ethereum require a nonce, which is a transaction counter, without which replay attacks would be trivial

Apparently UTXO-basee systems are potentially more scalable. [ibid]

[Thirdspace]

Is there something vital and critical in UTXO system for blockchain security and stability or UTXO it's rather some historical heritage with which bitcoin must live?

It's the basic of bitcoin architecture: UTXOs, transactions and blocks
It has something to do with bitcoin security and preventing double spend payments
with distinguishable coins as inputs, verifying inputs is easier (and robust) than account based inputs

[eugene111]

Is there something vital and critical in UTXO system for blockchain security and stability or UTXO it's rather some historical heritage with which bitcoin must live?

It's the basic of bitcoin architecture: UTXOs, transactions and blocks
It has something to do with bitcoin security and preventing double spend payments
with distinguishable coins as inputs, verifying inputs is easier (and robust) than account based inputs

But if imagine that we removed UTXOs and moved everything to transactions - so transaction contains transfered amount of bitcoin, locking script, unlocking script, and a reference to a previous transaction which money we want to spend. Verification will be the same as for UTXO. For a change we create a new transaction where locking script locks it  to ourselves. Are there any reasons why wouldnt it work?

[Betwrong]

Is there something vital and critical in UTXO system for blockchain security and stability or UTXO it's rather some historical heritage with which bitcoin must live?

It's the basic of bitcoin architecture: UTXOs, transactions and blocks
It has something to do with bitcoin security and preventing double spend payments
with distinguishable coins as inputs, verifying inputs is easier (and robust) than account based inputs

But if imagine that we removed UTXOs and moved everything to transactions - so transaction contains transfered amount of bitcoin, locking script, unlocking script, and a reference to a previous transaction which money we want to spend. Verification will be the same as for UTXO. For a change we create a new transaction where locking script locks it  to ourselves. Are there any reasons why wouldnt it work?

Maybe I'm missing something, but what would be the reason for the change you propose? As far as I understand this will not allow us to include more transactions in a block because the hash of a transaction will be of the same length regardless of whether or not the inputs and outputs were included.

Also it is not the hardest part - hashing all the transactions in the block with all the info they contain. Guessing a nonce is what billions times harder.

[eugene111]

Is there something vital and critical in UTXO system for blockchain security and stability or UTXO it's rather some historical heritage with which bitcoin must live?

It's the basic of bitcoin architecture: UTXOs, transactions and blocks
It has something to do with bitcoin security and preventing double spend payments
with distinguishable coins as inputs, verifying inputs is easier (and robust) than account based inputs

But if imagine that we removed UTXOs and moved everything to transactions - so transaction contains transfered amount of bitcoin, locking script, unlocking script, and a reference to a previous transaction which money we want to spend. Verification will be the same as for UTXO. For a change we create a new transaction where locking script locks it  to ourselves. Are there any reasons why wouldnt it work?

Maybe I'm missing something, but what would be the reason for the change you propose? As far as I understand this will not allow us to include more transactions in a block because the hash of a transaction will be of the same length regardless of whether or not the inputs and outputs were included.

Also it is not the hardest part - hashing all the transactions in the block with all the info they contain. Guessing a nonce is what billions times harder.

If we remove inputs and outputs then the things must be much simpler in implementation and support in my oppinion. But I want to understand whethrer it would break something fundamental in a blockchain functionality and stability. At first look there are not any issues if transactions don't use inputs and outputs. ... Isn't transaction hash has always the same size equals to
sha256 hash size?

[Ix]

But if imagine that we removed UTXOs and moved everything to transactions - so transaction contains transfered amount of bitcoin, locking script, unlocking script, and a reference to a previous transaction which money we want to spend. Verification will be the same as for UTXO. For a change we create a new transaction where locking script locks it  to ourselves. Are there any reasons why wouldnt it work?

UTXO stands for Unspent Transaction Output. You are describing what bitcoin already does. The output is the input of a new transaction where you prove you can unlock those coins and send them to new outputs. The inputs and outputs are the transaction.

[DannyHamilton]

If we remove inputs and outputs then the things must be much simpler in implementation and support in my oppinion. But I want to understand whethrer it would break something fundamental in a blockchain functionality and stability. At first look there are not any issues if transactions don't use inputs and outputs. ...

I can't think of a way to make it work.

Write up a white paper that covers all the use cases with the details of exactly what would be stored in the transaction and how it would work.  Either you'll come across a situation where you'll suddenly realize that it can't work, or you'll have a full explanation of exactly how it could be implemented.  If you miss any specific use cases, then they can be pointed out and you can update your whitepaper.

[Betwrong]

Okay, in order to become closer to understanding your point I will not argue on whether it is possible or not to remove inputs and outputs and to keep the blockchain working at the same time. Let's suppose it's possible, but please explain what are the reasons for this innovation?

~
If we remove inputs and outputs then the things must be much simpler in implementation and support in my oppinion.

Can you please elaborate this a bit more? What in your opinion will be much easier to do if we remove inputs and outputs?

But I want to understand whethrer it would break something fundamental in a blockchain functionality and stability.

Imo it will be impossible to prevent double spending because the inputs and outputs of a transaction give the network evidences that the amount of BTC on an address is equal or greater to what is transferred from there to another address.

At first look there are not any issues if transactions don't use inputs and outputs. ... Isn't transaction hash has always the same size equals to
sha256 hash size?

You are right about the size, but how can you resolve the issues regarding double spending?

[bob123]

If we remove inputs and outputs then the things must be much simpler in implementation and support in my oppinion.

What is going to be simplier in implementation?
Are you currently at a point where you don't know how to further code your project?
I don't see the reason why input/outputs aren't 'simple' in implementation. Might elaborate this?

And what do you mean with 'support' ?

Isn't transaction hash has always the same size equals to sha256 hash size?

The transaction hash is always the same size. The definition of a hash function is that it generates a 'randomly looking output' of a fixed length for any input.
The transaction itself can vary in size. This depends on the amount of inputs and outputs.

[eugene111]

If we remove inputs and outputs then the things must be much simpler in implementation and support in my oppinion.

What is going to be simplier in implementation?
Are you currently at a point where you don't know how to further code your project?
I don't see the reason why input/outputs aren't 'simple' in implementation. Might elaborate this?

And what do you mean with 'support' ?

Yes I'm developing a simple cryptocurrency for educational purposes. And I'm on a stage where I need to implement Inputs and Outputs, but I cannout understand which problem they help to solve. Transaction is just a collection of inputs and outputs. So I'm thinking what if only have a Transaction which contains and amount of money to transfer, reference to a previous transaction,  Lockcing script (for itself) and Unlocking (for a Transaction to spend)). (Acually in my case I will not have scripts just (planning to save sender and receiver Public keys and a signature - but is another question)).
So we have spent transactions (reference to which are set in next transactions) and unspend transactions (like UTXOs)

Then I don't need to code Inputs and Outpus and enable nodes to sync UTXOs - that will be much simpler. But I'm afraind that I miss something very critical with not using Inputs and Outputs. Actually it's not difficult to me to code Inputs and Output but I'l like to know why they are so important)

[ranochigo]

So I'm thinking what if only have a Transaction which contains and amount of money to transfer, reference to a previous transaction,  Lockcing script (for itself) and Unlocking (for a Transaction to spend)). (Acually in my case I will not have scripts just (planning to save sender and receiver Public keys and a signature - but is another question)).
So we have spent transactions (reference to which are set in next transactions) and unspend transactions (like UTXOs)

How different is it from the current implementation? Your previous transaction still needs a signature and a script to let the people know where the coins are being transferred to. Transactions are typically sent to various addresses and it is highly unlikely that the sum of Bitcoins transferred will be spent altogether.

Then I don't need to code Inputs and Outpus and enable nodes to sync UTXOs - that will be much simpler. But I'm afraind that I miss something very critical with not using Inputs and Outputs. Actually it's not difficult to me to code Inputs and Output but I'l like to know why they are so important)

If you were to remove inputs and outputs completely, nodes still has to synchronize all the transactions. I can imagine it being a whole lot more resource intensive. If the client does not extract the UTXO, then they would have to search through all the transactions for the Bitcoins that is being spent in the transaction. In addition, most of the transactions would have to be searched through since they can't be "marked" as spent completely.

[bob123]

So we have spent transactions (reference to which are set in next transactions) and unspend transactions (like UTXOs)

How exactly do you implement 'transactions'?
For me, this sounds like spent transaction outputs and unspent transaction outputs (UTXO's). Yet you have only changed the name.
Besides changing the word, what is the technical difference between UTXO and your 'unspent transactions' ?

We'd happily contribute. A more detailed explaination would be appreciated.

[eugene111]

So I'm thinking what if only have a Transaction which contains and amount of money to transfer, reference to a previous transaction,  Lockcing script (for itself) and Unlocking (for a Transaction to spend)). (Acually in my case I will not have scripts just (planning to save sender and receiver Public keys and a signature - but is another question)).
So we have spent transactions (reference to which are set in next transactions) and unspend transactions (like UTXOs)

How different is it from the current implementation? Your previous transaction still needs a signature and a script to let the people know where the coins are being transferred to. Transactions are typically sent to various addresses and it is highly unlikely that the sum of Bitcoins transferred will be spent altogether.

The prevoius transaction will have a signature (And all transactions does). And the verification will consist of two parts:  1. Tx signature (prof that the TX content did not changed and Sender is the one who made a transaction). 2. That the a Sender can spend the transaction (Just by tracking field Sender Public Key: if (Receiver Pub Key == on one of my wallet's generated Pub keys)). In first draft Pub Key will be an address). I know pretty primitive)

Then I don't need to code Inputs and Outpus and enable nodes to sync UTXOs - that will be much simpler. But I'm afraind that I miss something very critical with not using Inputs and Outputs. Actually it's not difficult to me to code Inputs and Output but I'l like to know why they are so important)

If you were to remove inputs and outputs completely, nodes still has to synchronize all the transactions. I can imagine it being a whole lot more resource intensive. If the client does not extract the UTXO, then they would have to search through all the transactions for the Bitcoins that is being spent in the transaction. In addition, most of the transactions would have to be searched through since they can't be "marked" as spent completely.

I will also have and "Unspend TX pool" like for UTXOs and Tx will be pushed and pulled from/into it by the same algorithm like UTXOs (I don't know yet on which stage the TX should be removed from The "Unspend TX pool" - maybe when the XT is added to a block and block is mined)
But while I'm writing this I'm realising that If I were to download the unspend transactions to a wallet software - it will be considerably more data to download in comparison to UTXO.

[Ix]

reference to a previous transaction,

That is your input, plus the unlocking script that proves you can spend it.

Lockcing script (for itself) and Unlocking (for a Transaction to spend)).

This is a little confused but this is basically your output. The receiver creates a locking script, hashes it, and gives that to you as the address to send to.

Then I don't need to code Inputs and Outpus and enable nodes to sync UTXOs - that will be much simpler.

I think maybe what you're trying to do is have a flat database where you do not need to download all of the old transactions to prove newer ones? This is a complex topic that has been discussed in this subforum before, but I don't remember any good keywords to search for. It can sort of be done, but there are technical caveats.

If you are going to try coding your own block chain though, you should probably do some more reading about bitcoin until you grasp everything that is going on.

[eugene111]

So we have spent transactions (reference to which are set in next transactions) and unspend transactions (like UTXOs)

How exactly do you implement 'transactions'?
For me, this sounds like spent transaction outputs and unspent transaction outputs (UTXO's). Yet you have only changed the name.
Besides changing the word, what is the technical difference between UTXO and your 'unspent transactions' ?

We'd happily contribute. A more detailed explaination would be appreciated.

The Tx will contain:
1. the amount of money to transfer
2. The Sender Pub Key (Actually an address)
3. The Signature(signed by the Sender Priv Key)
4. The receiver Pub Key
Yes exacly transactions without Inputs and Outputs may be though as Transactions with always only one Input and only One output. They don't bring anything new in this case. But again as I wrote in the prevoius answer I'm starting to think remove Inputs/Outputs then the wallet software needs to download Unspend transactions which is a lot of data.  In this respect UTXO's make sense (But If a wallet verifies a previous TX (a tx which Output I'm going to spend) then it anyway should be downloaded - but I'm not sure )

[eugene111]

If you are going to try coding your own block chain though, you should probably do some more reading about bitcoin until you grasp everything that is going on.

Yes that true

[eugene111]

Hi, guys
I finally decided to to go with UTXO's model because:
It becomes really messy when it comes to using money from multiple Unspent transactions into a new transaction. Then you need to keep the list of "parent transactions" into the new one. There are more user cases when Inputs/Outputs model solves it better.

And one more question - when I use a standalone wallet software - does it downloads the transactions locally or it downloads only UTXO's?
And if only UTXO's then how the parent transaction's signature is verified locally? Because without having the whole TX locally we cannot hash it an verify a signature