Bitcoin Forum

As noted in this wiki page (http://www.bitcoin.org/wiki/doku.php?id=transaction_fee) and in this satoshi post (http://bitcointalk.org/index.php?topic=795.msg8960#msg8960), the -paytxfee switch may be employed give your sent transactions "priority."

Prioritized transactions appear to be defined as increasing the likelihood that a transaction will be included in a block, even if that block is very large (byte-wise or tx-wise).

Considering that 99.9% of blocks are outside the range that will incur tx fees, it can be said that tx fees are largely useless today.  But it makes me curious...

Are there any other areas of the bitcoin client or network that could somehow prioritize transactions based on tx fees?  Examples:

• if you have a list of transactions to send out to the network, send prioritized ones to more connected nodes
• restart mining work immediately if priority tx arrives, but continue working on existing block for a while, if free tx arrives

And with my businessman's cap on, I would think it prudent practice for any bitcoin business to use -paytxfee=0.02 by default, just to be safe, guaranteeing priority on the existing network and existing clients, in cases of extreme network load.

Other comments about how to use tx fees welcome...  I strongly believe that a healthy tx fee structure is important to the long term health of the bitcoin P2P network.

As far as I can tell, transactions are not prioritized according to fee size. Paytxfee just ensures that you will meet the fee requirements (and it isn't guaranteed to do that). This does seem to be contrary to what Satoshi and sirius-m have implied, but I can't find any prioritization in the code.

The fees are a function of total transaction volume.
Right now the volume is pretty tiny so all fees are zero.
Later when the volume is high only some of the current transactions will be included in each
block so you either pay a fee to make sure your transaction is desirable to be in each block
or wait until the trading volume drops.

-Wayne

It ramps up the fee requirement as the block fills up:

<50KB  free
50KB   0.01
250KB  0.02
333KB  0.03
375KB  0.04
etc.

It's a typical pricing mechanism.  After the first 50KB sells out, the price is raised to 0.01.  After 250KB is sold, it goes up to 0.02.  At some price, you can pretty much always get in if you're willing to outbid the other customers.

Just including the minimum 0.01 goes a long way.

That's cost per kilobyte, though, and a kilobyte can only hold ~9 TxIns, so 0.01 is not guaranteed to meet the requirement.

True, the switch should be something more dynamic that pays per KB.  It's harder to think of how to explain it.

No one's going to figure out -paytxfee without reading the forums anyway, so we might as well just use -expectedBlockSize and rely on forum members to explain reasonable values if it actually becomes necessary.

So, in a Snowcrash future with Bitcoin as a major currency, generation of a block with 250K transactions would net the generating client a profit of 2K+ bitcoin, plus the regular award?  Or is this total block size?  Am I looking at this right?  If there is ever a future that this transaction fee structure would be triggered by the transaction volume in a 10 minute span, then the Bitcoin economy would have to rival one of the top ten economies (defined by national borders) and that fee would be a fortune.

Is that fee structure ridgid, or can it be backed down as the value of bitcoin increases?  I can conceive of a future wherein a ridgid fee of even .01 bitcoin could become a burden upon further growth.  If the value of a bitcoin were to break parity with the Euro, such a fee structure could start to strangle the micropayments end of the economy.  Granted, a sustained transaction rate of 300K every hour would still be a huge economy before such transaction fees came into play, making Paypal look like a small player.

Does anybody have estimates of total, worldwide USD or EUR transactions in an average 10-minute timespan?

A quick Google search returned these PayPal statistics (http://www.eventbrite.com/paypal-why), in case they're of interest to anyone:

• Over 2 million transactions per day (that's about 14000 per 10 minutes)
• 150 million accounts in 190 countries
• Over $150 million in payments per day

Of course, any system that works well for micropayments could end up handling many more transactions but a much lower dollar equivalent.

It's total block size. 250K = ~1150 transactions. See:
http://www.bitcoin.org/wiki/doku.php?id=transaction_fee

I did a quick Google search on the topic, and discovered an old Visa press release that stated that during the peak hour for the year of 2005 (Dec 23rd) Visa processed an average of 6,363 transactions per second, or just shy of 3.82 million transactions within a ten minute span.  The same press release made the claim that Visa processed more transactions within a coffee break than all of the world's public stock exchanges have ever done on their best day. combined.  I'm afraid I can't link it however, you will have to search for it yourself.  "How many transactions?" should work.

I could not find any numbers for Paypal, however.

That's a lot. Bitcoin won't allow blocks over 1MB, so assuming a (rather small) average transaction size of 216 bytes, Bitcoin can only handle 4,629 transactions per 10 minutes.

That hard limit is going to have to be bumped up if/when Bitcoin takes off.  463 transactions per minute wouldn't be anywhere near viable for a worldwide online currency.  We, at least, need to be able to handle the number of average transactions per minute that paypal claims they currently average.

+1

Scaling to high transaction rate has always been my main concern about viability of bitcoin.  I'm much more concerned about scalability than government shutdown, for example.

Maybe we can scale the block limit, like we scale the difficulty?

Compute average block size over past two weeks, and don't accept blocks over AVG_SIZE*100 ?

That would force large block sizes on people who can't handle them. MAX_BLOCK_SIZE can be carefully increased if it's ever actually limiting. 0.3.13 won't even create blocks over 500kB, so it's not a problem right now.

Well, at a minimum, bitcoin should be able to match Paypal's average volume over a 10-minute span.

Otherwise, I don't see how we can convince others that bitcoin is a long term viable [micro]currency, if technical limitations keep bitcoin below 500 transactions/minute.

Are there any low-tech ways to boost maximum number of transactions, such as zlib compression of blocks?

Where does the 1Mb limit come from? Is it a technical limit, or simply hardcoded to save bandwidth?

It's just an arbitrary limit, probably to limit the effects of DoS attacks. You won't accept blocks over 1 decimal megabyte.

Is there a technical limit beyond this artificial one?  Would it just be the bandwidth available to the weakest (in terms of bandwidth) nodes, or are there any inherent limitations of the p2p network itself?

I doubt there is a technical limit, I can't see any reason there should be such a limit (besides, as already mentioned, protecting from DoS attacks).

That means that if the limited block size becomes a problem, it can be scaled up at such a time. Which also means we probably don't need to worry about it at the moment.

If there are any technical limits (from data types or whatever), they can be eliminated in the same way that MAX_BLOCK_SIZE can be increased.

Storage is the main issue, I think: an attacker could create huge blocks that every full network node has to store forever. With just 1 BTC you can create a block of 15+ GB by splitting it into 100,000,000 "nanocoins".

In the future most people will run Bitcoin in a "simple" mode that doesn't require downloading full blocks or transactions. At that point MAX_BLOCK_SIZE can be increased a lot.

How about this idea! The algorithm is updated to deny any blocks that have transactions in them that are less than 1/10th of the average (or median) transaction fee from say the last 300 blocks. That does mean that the currency isn't effectively divisible... but it isn't anyway! In that your transactions will never get processed if you send them with less than the lowest fees (as the fees start to rise). It would then become quite costly (in bitcoins) to launch such an attack.

If you like this idea, send some bitcoin happiness to
1Gc3BAjW4jD1GCCphdqCSNsWHFHGyu8k4f

I just joined the craze last week! :-)

Daniel G
Apologies if this idea has already been mentioned...

Satoshi's response to the block size debate.


Also:

Um, why Elwar?

The 'fancy Visa' heresy is older than I thought!

Talk about failing to grok the ethos (https://twitter.com/adam3us/status/693405143862239232) (early and often).

So Garzik is a limousine libertarian.  No wonder he's so eager to help Olivier Janssens engage in pointless/dangerous vanity forks based on retail payment rail business requirements.

There are a lot of people who do not want Bitcoin to be another PayPal or a VISA competitor. I disagree with them, because I think the cheaper micro transactions

capability of Bitcoin is one of it's strongest advantages. We should concentrate on tapping the potential of the strong points, without sacrificing the security. I think the

hesitation to increase the block size, come from the risk it pose for the security. We should find a good balance between performance and security, before we go forward

with a fork. 

The fantasy of making BTC into yet another PayPal or VISA competitor is never going to happen on Layer One.

Bitfury Valery permanently demolished that nonsense in this domination post.

https://medium.com/@BitFuryGroup/keep-calm-and-bitcoin-on-4f29d581276