Bitcoin Forum
November 11, 2024, 01:06:40 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Why does everyone keep calling them fees? They're not fees, they're BIDS!  (Read 3095 times)
AliceWonder
Full Member
***
Offline Offline

Activity: 168
Merit: 100



View Profile
June 28, 2013, 03:00:37 PM
 #41

What I would like is for the receiver to be able to "bid".

e.g. Acme Corp is willing to pay 1 mBTC for every transaction regardless of what the sender buyer pays.

But I imagine that would require some changes to the protocol. Maybe if the payment address starts with a 1 there is no fee taken from the receiver, if the payment address starts with a, say, z - then then the minor is automatically allowed to take 0.5% of the transaction. Hell - just put z1 at the beginninging instead of 1. Or something.

Businesses that want higher odds of fast confirmation can use it as the payment address, potentially saving money in customer service queries.

QuarkCoin - what I believe bitcoin was intended to be. On reddit: http://www.reddit.com/r/QuarkCoin/
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
June 28, 2013, 03:08:49 PM
 #42

When one pays a so-called "fee" for a transaction, it's not really a fee at all. It's a bid! It's simply bidding for space in the next available block.

So-called miners are the entities auctioning block-space to the highest bidders.

I've been wondering why there has been so much confusion surrounding the whole "increasing the block-space" thing, and I think it at least partly boils down to a highly misleading nickname. They're not fees, they're bids!

The way I understand it, every time a new block is discovered, an auction occurs and individual kilobytes of that block are auctioned off to the highest bidders. However, at the moment there's a problem because it seems like such a crappy opaque process with very little market transparency. This needs to be improved. Before requesting any transaction, I want to know the "going rate" and the estimated delivery time depending on how much i BID.

Agree? Disagree? Please discuss. Smiley
Technically: I agree.
Otherwise: I disagree, because if you look at the satoshi client as a whole, much of the terminology is based on how the real world used to think about money:
Wallet instead of keychain
Address instead of publickey(hash)
and therefor also fee instead of "bids that the miners accept to get your transactions into the magical blockchain-voodoo stuff *techbabble continues*".

I think that its easier to get people to use bitcoin, because the terminology is similar to what people are used to when they talk about cash. maybe its a bit off to call it fees, but it greatly eases the _basic_ understanding of whats its doing.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
June 28, 2013, 03:11:08 PM
 #43

What I would like is for the receiver to be able to "bid".

e.g. Acme Corp is willing to pay 1 mBTC for every transaction regardless of what the sender buyer pays.

But I imagine that would require some changes to the protocol. Maybe if the payment address starts with a 1 there is no fee taken from the receiver, if the payment address starts with a, say, z - then then the minor is automatically allowed to take 0.5% of the transaction. Hell - just put z1 at the beginninging instead of 1. Or something.

Businesses that want higher odds of fast confirmation can use it as the payment address, potentially saving money in customer service queries.

No changes to protocol are necessary.  There are two options that can be done but would require some client/node changes (much easier than extending the protocol)

Option 1: Respend
One can (by protocol) spend 0-confirm transactions the client prevents this by that can be easily changed (we modified our bitcoind for this exact purpose).  The larger issue is that currently miners can't "see" the downstream transaction.  They should and when they can it will allow you to get confirmations by simply creating a new tx with a fee (this potentially could be done automatically via a sweep process).  This sweep process could even be designed to periodically only grab the "slow pays".  The node logs incoming txs and every hour looks for tx older than x minutes with no confirmations.  Those tx are bundled up into one sweep.

Example:
customer A sends 1 BTC (w/ no fee) to payment address X (A->X).  Your system detects this and creates a tx spending the entire output to X in a new tx (X -> Y) which includes a fee.  Mining pool has rejected tx A->X for insufficient fees but detects your paying tx (X->Y) meets criteria for inclusion in a block.  The mining node adds BOTH txs (A->X AND X->Y) into the next block.  The node has to add the A->X because the block will be invalid if X->Y is only included as a block can't include tx with unconfirmed inputs however there is no rule against both tx being in the same block.


Option 2: Off-blockchain fee payments (contracts)
A pool (or collection of pools) could make an agreement with a merchant to include all txs to their addresses (merchant could either provide a list or a deterministic public key seed) either on a per tx basis or potentially a monthly contract (i.e. up to 1,000 tx for Y BTC).    The mining node software would simply look for this "premium" txs and always include them first.
nimda
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


0xFB0D8D1534241423


View Profile
June 28, 2013, 03:18:52 PM
 #44

I was looking through satoshi's posts, and even he said something like "same inputs, same outputs, larger fee."

Unfortunately that doesn't work, because the fee is sum(inputs) - sum(outputs). The only way I can see it working is "same inputs (and one more), same outputs (and one more), larger fee," but that still doesn't seem as optimal as adding the "Respend" scenario to the default miner code.
legitnick
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500



View Profile WWW
June 28, 2013, 05:27:50 PM
 #45

When one pays a so-called "fee" for a transaction, it's not really a fee at all. It's a bid! It's simply bidding for space in the next available block.

So-called miners are the entities auctioning block-space to the highest bidders.

I've been wondering why there has been so much confusion surrounding the whole "increasing the block-space" thing, and I think it at least partly boils down to a highly misleading nickname. They're not fees, they're bids!

The way I understand it, every time a new block is discovered, an auction occurs and individual kilobytes of that block are auctioned off to the highest bidders. However, at the moment there's a problem because it seems like such a crappy opaque process with very little market transparency. This needs to be improved. Before requesting any transaction, I want to know the "going rate" and the estimated delivery time depending on how much i BID.

Agree? Disagree? Please discuss. Smiley

I do agree with what your saying, however the term Fee's fits the wording for the one transfering the coins better.

For the person transferring coins its not really a BID, its more of a set price you have to pay to send the coins.

5 BITCOIN RAFFLE GIVEAWAY
"I dont lift" - Lord Furrycoat
Pages: « 1 2 [3]  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!