Bitcoin Forum
December 18, 2017, 02:33:07 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Is it really necessary to have inputs in transactions?  (Read 297 times)
hidecoin2016
Sr. Member
****
Offline Offline

Activity: 288


View Profile WWW
September 17, 2017, 04:49:37 PM
 #1

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? Smiley

Как заработать на росте стоимости газа Ethereum, если ты не майнер? >> Buy MINT while it's cheap! Mineable Ethereum Token MINT
Donations for Hidecoin Development BTC 1Mi3fhQug3PGfJYv7SNPs6CrQsczJzCMH8 DOGE A2V6dxVBhW797fEubRrSp9paMBF2br7dXd ETH 0x2488d18fe46d8cb00BC9d6F784422cD46A03723D
1513564387
Hero Member
*
Offline Offline

Posts: 1513564387

View Profile Personal Message (Offline)

Ignore
1513564387
Reply with quote  #2

1513564387
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513564387
Hero Member
*
Offline Offline

Posts: 1513564387

View Profile Personal Message (Offline)

Ignore
1513564387
Reply with quote  #2

1513564387
Report to moderator
1513564387
Hero Member
*
Offline Offline

Posts: 1513564387

View Profile Personal Message (Offline)

Ignore
1513564387
Reply with quote  #2

1513564387
Report to moderator
LittleBitFunny
Full Member
***
Offline Offline

Activity: 210


View Profile
September 17, 2017, 05:27:20 PM
 #2

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

Activity: 2002



View Profile
September 17, 2017, 08:25:48 PM
 #3

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
Sr. Member
****
Offline Offline

Activity: 288


View Profile WWW
September 17, 2017, 08:29:43 PM
 #4

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.

Как заработать на росте стоимости газа Ethereum, если ты не майнер? >> Buy MINT while it's cheap! Mineable Ethereum Token MINT
Donations for Hidecoin Development BTC 1Mi3fhQug3PGfJYv7SNPs6CrQsczJzCMH8 DOGE A2V6dxVBhW797fEubRrSp9paMBF2br7dXd ETH 0x2488d18fe46d8cb00BC9d6F784422cD46A03723D
DannyHamilton
Legendary
*
Offline Offline

Activity: 2002



View Profile
September 17, 2017, 08:43:10 PM
 #5

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? Smiley

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
Hero Member
*****
Online Online

Activity: 630


Vires in numeris


View Profile
September 17, 2017, 08:54:34 PM
 #6

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
Sr. Member
****
Offline Offline

Activity: 288


View Profile WWW
September 18, 2017, 05:02:39 AM
 #7

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.

Как заработать на росте стоимости газа Ethereum, если ты не майнер? >> Buy MINT while it's cheap! Mineable Ethereum Token MINT
Donations for Hidecoin Development BTC 1Mi3fhQug3PGfJYv7SNPs6CrQsczJzCMH8 DOGE A2V6dxVBhW797fEubRrSp9paMBF2br7dXd ETH 0x2488d18fe46d8cb00BC9d6F784422cD46A03723D
DannyHamilton
Legendary
*
Offline Offline

Activity: 2002



View Profile
September 18, 2017, 01:43:37 PM
 #8

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
Sr. Member
****
Offline Offline

Activity: 288


View Profile WWW
September 18, 2017, 04:11:37 PM
 #9

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.

Как заработать на росте стоимости газа Ethereum, если ты не майнер? >> Buy MINT while it's cheap! Mineable Ethereum Token MINT
Donations for Hidecoin Development BTC 1Mi3fhQug3PGfJYv7SNPs6CrQsczJzCMH8 DOGE A2V6dxVBhW797fEubRrSp9paMBF2br7dXd ETH 0x2488d18fe46d8cb00BC9d6F784422cD46A03723D
DannyHamilton
Legendary
*
Offline Offline

Activity: 2002



View Profile
September 18, 2017, 08:04:59 PM
 #10

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?





Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!