Bitcoin Forum
April 25, 2024, 01:41:27 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: CreateTransaction: suggest/enforce fee for big low-priority transactions  (Read 7864 times)
Steve
Hero Member
*****
Offline Offline

Activity: 868
Merit: 1007



View Profile WWW
March 02, 2011, 01:52:02 AM
 #61

Quote
I actually like this formula. Thinking about it in these terms, its basically similar to what I was trying to articulate, except with valuein added. Though, if you are going to use the fee, why not drop valuein? From a miner's point of view, why should a transaction moving 100 btc with a .01 btc fee be preferred to one moving 10 btc with a .02 btc fee? (assuming txsize is equal).

My thoughts exactly...the value of a transaction has no bearing on the cost to process it...so valuein has should have no bearing on priority.  I think the winning formula is to base priority on a combination of age, fee, size, and time since the last transaction involving one of the accounts in the transaction (to deal with the spam issue).  That last one should be carefully tweaked to better deal with the recent delay issues experienced with slush's pool.  This priority would govern the forwarding behavior of the clients.  In addition, clients should factor this priority calculation into the decision on whether or not to accept blocks.  Blocks that seem to be grossly out of alignment with these priority assessments should be treated with great suspicion.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
1714052487
Hero Member
*
Offline Offline

Posts: 1714052487

View Profile Personal Message (Offline)

Ignore
1714052487
Reply with quote  #2

1714052487
Report to moderator
1714052487
Hero Member
*
Offline Offline

Posts: 1714052487

View Profile Personal Message (Offline)

Ignore
1714052487
Reply with quote  #2

1714052487
Report to moderator
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Cryptoman
Hero Member
*****
Offline Offline

Activity: 726
Merit: 500



View Profile
March 02, 2011, 05:48:06 AM
 #62

Someone just unclogged the drain:

http://blockexplorer.com/b/111264

How did all of those 0.0001 fees get into the transactions?

"A small body of determined spirits fired by an unquenchable faith in their mission can alter the course of history." --Gandhi
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1596
Merit: 1091


View Profile
March 02, 2011, 06:06:00 AM
 #63

My thoughts exactly...the value of a transaction has no bearing on the cost to process it...so valuein has should have no bearing on priority.  I think the winning formula is to base priority on a combination of age, fee, size, and time since the last transaction involving one of the accounts in the transaction (to deal with the spam issue).  That last one should be carefully tweaked to better deal with the recent delay issues experienced with slush's pool.  This priority would govern the forwarding behavior of the clients.  In addition, clients should factor this priority calculation into the decision on whether or not to accept blocks.  Blocks that seem to be grossly out of alignment with these priority assessments should be treated with great suspicion.

The value of a transaction does have bearing.

People are far less likely to spam using 10000 BTC transactions.  Faster confirmations for bigger sums encourages use of bitcoin for larger amounts, which is always a good thing for the economy.  And as ArtForz pointed out, it encourages sending larger amounts per tx, which implies less block chain size for the same volume of currency flow.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
March 02, 2011, 10:46:23 AM
 #64

How did all of those 0.0001 fees get into the transactions?
The Bitcoin faucet started paying this fee, to avoid the transactions being stuck. This has unclogged the blockage for other transactions too, by freeing up "free transaction" space.
ribuck
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
March 02, 2011, 10:49:09 AM
 #65

...it encourages sending larger amounts per tx, which implies less block chain size for the same volume of currency flow.

If sending a 10 BTC transaction has higher utility to me than sending a 10000 BTC transaction, why should the system care?

The only rational basis for fees is for the fee to reflect cost of processing (e.g. size in block chain, or number of inputs).
carp
Member
**
Offline Offline

Activity: 82
Merit: 10


View Profile
March 02, 2011, 01:09:21 PM
 #66

My thoughts exactly...the value of a transaction has no bearing on the cost to process it...so valuein has should have no bearing on priority.  I think the winning formula is to base priority on a combination of age, fee, size, and time since the last transaction involving one of the accounts in the transaction (to deal with the spam issue).  That last one should be carefully tweaked to better deal with the recent delay issues experienced with slush's pool.  This priority would govern the forwarding behavior of the clients.  In addition, clients should factor this priority calculation into the decision on whether or not to accept blocks.  Blocks that seem to be grossly out of alignment with these priority assessments should be treated with great suspicion.

The value of a transaction does have bearing.

People are far less likely to spam using 10000 BTC transactions.  Faster confirmations for bigger sums encourages use of bitcoin for larger amounts, which is always a good thing for the economy.  And as ArtForz pointed out, it encourages sending larger amounts per tx, which implies less block chain size for the same volume of currency flow.


Less likely, but, I wouldn't completely discount the possibility.

The fee has the same effect though. If adding a fee gets faster processing, and you want faster processing, then you pay the fee right? Well, if you want to jump the queue with smaller values, thats fine but that means the fee will be a larger percentage of your total value.

That said, I doubt either of these effects is going to have much bearing on anyone's behavior in terms of what they send. If I make a transaction, it is either to consolidate btc into another wallet, or, its to pay someone for something. Either way, the amount I send is not going to be influenced here.... but the fee might be.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
March 02, 2011, 01:28:53 PM
 #67

Can we make it easier to create multi-output txn for peole like slush to distribute to large lists?

I'm quoting from #bitcoin-dev:

Quote
ArtForz> hmmm... doesnt look like adding a rpc interface to send to multiple outputs simultaneously would be too hard
ArtForz> looks like the cleanest way woudl be to extend CreateTransaction so it takes a vector of (scriptPubKey, nValue) pairs
sipa> i was thinking exactly the same

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



View Profile
March 02, 2011, 01:38:51 PM
 #68

My thoughts exactly...the value of a transaction has no bearing on the cost to process it...so valuein has should have no bearing on priority.  I think the winning formula is to base priority on a combination of age, fee, size, and time since the last transaction involving one of the accounts in the transaction (to deal with the spam issue).  That last one should be carefully tweaked to better deal with the recent delay issues experienced with slush's pool.  This priority would govern the forwarding behavior of the clients.  In addition, clients should factor this priority calculation into the decision on whether or not to accept blocks.  Blocks that seem to be grossly out of alignment with these priority assessments should be treated with great suspicion.

The value of a transaction does have bearing.

People are far less likely to spam using 10000 BTC transactions.  Faster confirmations for bigger sums encourages use of bitcoin for larger amounts, which is always a good thing for the economy.  And as ArtForz pointed out, it encourages sending larger amounts per tx, which implies less block chain size for the same volume of currency flow.


Less likely, but, I wouldn't completely discount the possibility.

The fee has the same effect though. If adding a fee gets faster processing, and you want faster processing, then you pay the fee right? Well, if you want to jump the queue with smaller values, thats fine but that means the fee will be a larger percentage of your total value.


I think I agree with carp on this point. After all, the amount in a spam transaction is not lost to the spammer, he can just self-send it. The fee however is lost to him.

I'm still not convinced we should remove amount from priority calculation, although I can't seem to find a good reason against it.

After all, we're not trying to maximize volume, are we? The goal is "merely" to have transaction processing that is effective and cost-efficient enough for users.


PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!