Bitcoin Forum
December 15, 2017, 04:44:49 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Bitcoin scalability - unite transactions transaction.  (Read 368 times)
ivantosov
Newbie
*
Offline Offline

Activity: 20


View Profile
November 11, 2017, 05:32:25 PM
 #1

On my bitcoin address 1000 input transactions, 0.001 btc each, - 1 btc summary. The new out transaction lists them all, and it's size is 100 kilobytes. I have 10 of such addresses, and to send 10 btc on new address, I need to generate 1Mb transaction! So I have a very biiig fee ... 2 btc, or 25% (((
But bitcoin address size is 33 bytes! So why doesn't bitcoin provide special unite transactions, listing only 10 inputs addresses, without listing 10000 transactions? It would reduce transaction size tremendously, would allow to optimize states with very low, almost fixed fees, and would solve the problem of transactions with amount of coins less than current fee.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513313089
Hero Member
*
Offline Offline

Posts: 1513313089

View Profile Personal Message (Offline)

Ignore
1513313089
Reply with quote  #2

1513313089
Report to moderator
1513313089
Hero Member
*
Offline Offline

Posts: 1513313089

View Profile Personal Message (Offline)

Ignore
1513313089
Reply with quote  #2

1513313089
Report to moderator
ranochigo
Legendary
*
Offline Offline

Activity: 1288


View Profile WWW
November 11, 2017, 05:51:54 PM
 #2

The blockchain isn't a balance system. It keeps track of the transactions, not the balance. Nodes do not have to see the entire balance of the address to validate the transaction.

Bitcoin transaction works by using unspent outputs of addresses. Each nodes keeps a list of such outputs. When a transaction is spent, the transaction states the transaction unspent outputs that are used in it. Next, the node removes the outputs from their list and no one else can send another transaction sending it and have that node relaying it.

It's way easier to track the unspent output than to index each and every address for their balance.














 

 

█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
BitBlender 

 













 















 












 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
ivantosov
Newbie
*
Offline Offline

Activity: 20


View Profile
November 11, 2017, 06:02:03 PM
 #3

It does not require balance calculation for address/all addresses. It just requires finding all transactions of the address(es), listed in such transaction in specified block number. And I guess it should not be difficult to implement.?
achow101
Moderator
Legendary
*
Offline Offline

Activity: 1246


17kKQppUsngUiByDsce4JXoZEjjpvX9bpR


View Profile WWW
November 12, 2017, 02:04:52 AM
 #4

It does not require balance calculation for address/all addresses. It just requires finding all transactions of the address(es), listed in such transaction in specified block number.
... You are contradicting yourself. Balance calculation means "finding all transaction of the addresses". So for your idea to work, you would need to calculate the balance for a given address.

And I guess it should not be difficult to implement.?
That is incorrect. It would be both difficulty to implement, and completely unsafe. Making it safe would make this even harder to implement.

First of all, on the technical level, addresses don't exist. What exist are transaction outputs, and transaction outputs themselves don't have addresses, they have output scripts. An address only encodes what a wallet should use as an output script, but there are infinitely many output scripts that are not related to any address whatsoever.

Furthermore your idea is completely unsafe. What you propose is to use accounts and balances, but such systems are known to be unsafe in the context of a cryptocurrency. For example, suppose you want to pay me and you do so by constructing one of these special transactions. Now later, you receive money to the same addresses, and once the balances are high enough, I broadcast the special transaction again and send your money to myself.

ivantosov
Newbie
*
Offline Offline

Activity: 20


View Profile
November 12, 2017, 08:46:30 AM
 #5

... For example, suppose you want to pay me and you do so by constructing one of these special transactions. Now later, you receive money to the same addresses, and once the balances are high enough, I broadcast the special transaction again and send your money to myself.
Union transaction must contains the block number that must be used to determine all address transactions.
- if later I receive money, this new transaction will have a larger block number, and must not be used in the union transaction.
- if I spend money later (related to union transaction), there will be a "double spend" transaction. This situation is common for transactions. Only one transaction will be selected, so this is not a problem.
First of all, on the technical level, addresses don't exist. What exist are transaction outputs, and transaction outputs themselves don't have addresses, they have output scripts. ...
I mean a special transaction, a separate type. As message transaction, for example.

Balance calculation means "finding all transaction of the addresses". So for your idea to work, you would need to calculate the balance for a given address.
All transactions contain address. So it's need only + one index for array search.
Conventional transactions contain a list of input transaction numbers. They also have to be searched. For each transaction there will be a separate search. There аre always more transactions than addresses. Search by address should be faster.

In current situation, the network has lost a lot of coins in small transactions (~< 0,002 BTC), since the commission for their transfer (0.00913 BTC/KB) is larger than the number of coins in this transactions. This is a big problem. The network needs a unite transaction.
ranochigo
Legendary
*
Offline Offline

Activity: 1288


View Profile WWW
November 12, 2017, 01:23:16 PM
 #6

Union transaction must contains the block number that must be used to determine all address transactions.
- if later I receive money, this new transaction will have a larger block number, and must not be used in the union transaction.
- if I spend money later (related to union transaction), there will be a "double spend" transaction. This situation is common for transactions. Only one transaction will be selected, so this is not a problem.
It's confusing. The current blockchain system works by only allowing each inputs to only be spent once. How is your implementation going to help?
I mean a special transaction, a separate type. As message transaction, for example.
There isn't a message transaction. Unless you are referring to OP_Return which contributes to Blockchain bloat.
All transactions contain address. So it's need only + one index for array search.

Conventional transactions contain a list of input transaction numbers. They also have to be searched. For each transaction there will be a separate search. There аre always more transactions than addresses. Search by address should be faster.
Basically, for the "conventional" transaction, to validate a transaction, nodes basically have to see which UTXO is being spent and search it in their UTXO database which is relatively small. If we were to switch to a balance method, for each address, the node will have to search and validate each of the transactions and then calculate the total balance. Obviously, some attacker would spam invalid transactions for the node to waste resources to DDOS any nodes.














 

 

█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
BitBlender 

 













 















 












 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
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!