Bitcoin Forum
December 05, 2016, 12:39:50 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Add option to add a fee to dead transactions  (Read 2219 times)
TierNolan
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 26, 2011, 11:43:46 PM
 #21

Ahh.  The reason is probably because reusing keys is a bad idea, in general.  Many cryptosystems have are weak when an attacker is able to collect many cyphertexts all using the same key.  I don't know how much of a problem it is when using ECDSA, but all the textbooks since WWII have said not to do it unnecessarily.

Good to know Smiley

Quote
The client could reduce this problem by keeping track of the addresses getting change, and chaining them into the following spend on the changeless side.

In this X+Y==A+(B-F) example, B is the change.  The next transaction the client does would be B+Z==C+D, or C+(D-F).  Then the next would be D+W, and so on.

Ideally, there would be some kind of incentive to reduce the total number of active transactions.  The recommended fee could be lower for transactions that combined lots of low value coins into high value coins.

Minimum fees based on the size of the transaction already mean that tiny coins have less value than larger coins.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480898390
Hero Member
*
Offline Offline

Posts: 1480898390

View Profile Personal Message (Offline)

Ignore
1480898390
Reply with quote  #2

1480898390
Report to moderator
1480898390
Hero Member
*
Offline Offline

Posts: 1480898390

View Profile Personal Message (Offline)

Ignore
1480898390
Reply with quote  #2

1480898390
Report to moderator
1480898390
Hero Member
*
Offline Offline

Posts: 1480898390

View Profile Personal Message (Offline)

Ignore
1480898390
Reply with quote  #2

1480898390
Report to moderator
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 27, 2011, 12:17:49 AM
 #22

Ideally, there would be some kind of incentive to reduce the total number of active transactions.  The recommended fee could be lower for transactions that combined lots of low value coins into high value coins.

Minimum fees based on the size of the transaction already mean that tiny coins have less value than larger coins.

Right now the default client enforces some limits on transaction fees, mostly to stop transaction spam.  Over time, those will go away, and each network node and miner will be able to set their own rules for accepting and relaying transactions, which means that there will be a market of sorts for fees.

But, when there are a lot of transactions to process, the miners will evaluate them in the terms that make sense to them.  That mostly means that they will want a high ratio of fee to work.  Each input to a transaction involves a certain amount of work, so there is no possible way to provide incentives to miners for consolidation transactions.

So, while consolidation may be useful to other parts of the network, it will not be prioritized by the group capable of making it actually happen.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
June 27, 2011, 06:20:24 AM
 #23

Why isn't a dependent transaction which pays a fee all that is needed? This requires no dropping of existing transactions.

1. A+B -> C + D
2. D+E -> F + (G - Fee)

In this case the Fee pays for both transaction 1 and transaction 2.
The only problem seems to be if you make a transaction with zero change and then want to add an additional fee. But that is up to the choice of the sender anyway.
TierNolan
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 27, 2011, 09:04:54 AM
 #24

Why isn't a dependent transaction which pays a fee all that is needed? This requires no dropping of existing transactions.

1. A+B -> C + D
2. D+E -> F + (G - Fee)

In this case the Fee pays for both transaction 1 and transaction 2.

A zero fee transaction won't propagate and neither will one that collides with another transaction.  If you have a rule that higher transaction fee transactions that have all the same inputs and outputs replace the older transaction, then it doesn't matter if the node has seen the earlier transaction or not, it will propagate.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
TierNolan
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 27, 2011, 09:47:18 PM
 #25

Ahh.  The reason is probably because reusing keys is a bad idea, in general.  Many cryptosystems have are weak when an attacker is able to collect many cyphertexts all using the same key.  I don't know how much of a problem it is when using ECDSA, but all the textbooks since WWII have said not to do it unnecessarily.

Good to know Smiley


Does this mean that you shouldn't ask people to send money to an address once you have sent money from the address?

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: « 1 [2]  All
  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!