Bitcoin Forum
November 03, 2024, 07:52:52 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Why do we allow zero transaction blocks?  (Read 4450 times)
coinjedi (OP)
Full Member
***
Offline Offline

Activity: 184
Merit: 100



View Profile WWW
February 23, 2012, 03:01:50 PM
 #1

I was wondering how come a block with no transaction other than mining reward is a valid block. Is there a technical advantage?

Example:
http://blockexplorer.com/block/000000000000042f7c236a243e2d84bec12210dd2dd5abbeaaf55024898ac70f

Bets of Bitcoin
http://betsofbitco.in/
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 23, 2012, 03:10:51 PM
 #2

If you made a rule that blocks had to have transactions well people could just make a dummy transaction sending 1 satoshi to themselves.  

As the block subsidy declines and transaction fees become more important the "problem" will correct itself.  No need for the protocol to enforce it.
eleuthria
Legendary
*
Offline Offline

Activity: 1750
Merit: 1007



View Profile
February 23, 2012, 05:20:09 PM
 #3

While it may not be the case today, in the past it was not uncommon for there to be periods of no transactions on the network [look at the first 30k blocks].  If the network refused to process blocks without a transaction, people would be forced to just insert dummy transactions in order to keep the block rate moving in proportion to the hash power of the network.  Otherwise, the difficulty could plummet as a result of low network activity, rather than low hash power.

Even today it is the case that 0 transaction blocks can come about due to -extremely- close blocks on the network.  However, eliminating these short blocks will end up offsetting the average block rate.  A 0-5 second block on the network smooths out the average when we have the occasional 1-hour without a block period.

So it's really two reasons that I see:

1) If 0-tx blocks were stopped, people would just send append a 0-fee transaction to their own blocks, which just wastes space in the chain.
2) If 0-tx blocks were stopped, the network difficulty would be slanted towards a higher difficulty than necessary [even if its not a major impact].

RIP BTC Guild, April 2011 - June 2015
coinjedi (OP)
Full Member
***
Offline Offline

Activity: 184
Merit: 100



View Profile WWW
February 23, 2012, 05:23:50 PM
 #4

Thanks for the clarification.

Bets of Bitcoin
http://betsofbitco.in/
FreeMoney
Legendary
*
Offline Offline

Activity: 1246
Merit: 1016


Strength in numbers


View Profile WWW
February 24, 2012, 01:19:07 AM
 #5

In addition to the previous points every block empty or not makes it one block more work to rewrite a particular previous block making the tx in them a little bit more secure.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 24, 2012, 01:39:44 AM
 #6

In addition to the previous points every block empty or not makes it one block more work to rewrite a particular previous block making the tx in them a little bit more secure.

Very good point.  So anyone who's transactions were in the prior blocks benefits from increased depth in the blockchain.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 24, 2012, 03:27:02 AM
 #7

@DnT

What amount do you need to send to always avoid transaction fees or is there a minimum amount? How does that work?


It is based on time and amount (not just total amount but amounts of the prior output).

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

You need a priority of 57,600 or higher to avoid spam fees.

IIRC (and I may not be) the simple version is 1 coin 1 day.

IF you receive 1 BTC you need to wait 1 day to avoid a fee when transferring it.
If you receive 10 BTC you need to wait 2.4 hours to avoid a fee when transferring it.

The wallet always attempts to reduce the fee using older coins as necessary to minimize or eliminate any fee.
payb.tc
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
February 24, 2012, 04:05:59 AM
 #8

I’m going somewhere with this eventually.

So you can send one coin transactions repeatedly without a fee if the amount in the wallet is large enough because effectively the client will always look for the oldest coin to avoid fees. Correct?

EDIT: Repeatedly  

it also depends on how your wallet is constituted... if all those 'old' transactions are millions of 0.00000001 inputs, then you'll still get fees because of the data size (in bytes) of your transaction.


edit: also, even if you had a wallet with 1000 BTC which was just ONE really old transaction... as soon as you spend 1 btc from it, the remaining 999 btc will be sent as 'change' and will no longer be an old transaction, but a really new one.

payb.tc
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
February 24, 2012, 04:09:46 AM
 #9

I’m going somewhere with this eventually.

So you can send one coin transactions repeatedly without a fee if the amount in the wallet is large enough because effectively the client will always look for the oldest coin to avoid fees. Correct?

EDIT: Repeatedly 

it also depends on how your wallet is constituted... if all those 'old' transactions are millions of 0.00000001 inputs, then you'll still get fees because of the data size (in bytes) of your transaction.


Ok, then what is the minimum Tx amount? How is that determined?

you can spend 0.00000001 without a fee if you have an old incoming 0.00000001 that was sent to your wallet.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 24, 2012, 04:16:26 AM
 #10

I’m going somewhere with this eventually.

So you can send one coin transactions repeatedly without a fee if the amount in the wallet is large enough because effectively the client will always look for the oldest coin to avoid fees. Correct?

EDIT: Repeatedly 

No because once you send it, it is gone and the wallet where it is received it is now time 0.
payb.tc
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
February 24, 2012, 04:16:33 AM
 #11

I’m going somewhere with this eventually.

So you can send one coin transactions repeatedly without a fee if the amount in the wallet is large enough because effectively the client will always look for the oldest coin to avoid fees. Correct?

EDIT: Repeatedly  

it also depends on how your wallet is constituted... if all those 'old' transactions are millions of 0.00000001 inputs, then you'll still get fees because of the data size (in bytes) of your transaction.


Ok, then what is the minimum Tx amount? How is that determined?

you can spend 0.00000001 without a fee if you have an old incoming 0.00000001 that was sent to your wallet.


If I send one coin a day to the wallet for 60 days could I then send .1 60 times an hour without a fee?

best guess: yes (for ONE hour)

then you'd have the remaining 90% as 60 x 0.9 btc in new change addresses.

after the first hour (the first 60 x 0.1 transactions), all your wallet would contain would be new addresses with 0.9 in them.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 24, 2012, 04:18:07 AM
 #12

I’m going somewhere with this eventually.

So you can send one coin transactions repeatedly without a fee if the amount in the wallet is large enough because effectively the client will always look for the oldest coin to avoid fees. Correct?

EDIT: Repeatedly  

it also depends on how your wallet is constituted... if all those 'old' transactions are millions of 0.00000001 inputs, then you'll still get fees because of the data size (in bytes) of your transaction.


Ok, then what is the minimum Tx amount? How is that determined?

you can spend 0.00000001 without a fee if you have an old incoming 0.00000001 that was sent to your wallet.


If I send one coin a day to the wallet for 60 days could I then send .1 60 times an hour without a fee?
No because you can't send part of a coin.

If you have a 1 BTC input and want to send 0.1 you can't do that 10 times.

You have to send 1 BTC so you send 0.1 and get 0.9 back as change.  The change now has a time 0 and is too young to be sent without incurring a fee.
payb.tc
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
February 24, 2012, 04:22:29 AM
 #13

So, if someone had 20 computers and 40 clients, one running in a VM and one on the desktop. That machine with the proper script could be made to send coins to itself in a continuous loop or to one of the other 20 in a series. Yes?


sure, if they had RPC switched on i guess.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 24, 2012, 04:24:08 AM
 #14

So, if someone had 20 computers and 40 clients, one running in a VM and one on the desktop. That machine with the proper script could be made to send coins to itself in a continuous loop or to one of the other 20 in a series. Yes?


How many coins per transaction?

24 BTC?  You can send 24 BTC again in 6 confirmations without fee, since 6 confirmation is the minimum it could continue forever.  The point of the fees is to avoid cheaply spamming the network.  i.e. taking 1 BTC and sending a million 1 satoshi transactions and keep doing that every seconds until you generate TB worth of transactions.

The number of nodes is irrelivent.  It doesn't matter where you send coins.  Hell you can send them to another address in the same wallet.

Everytime you transfer a coin its time resets to 0.  If it is too young to be used in a new transaction you must pay a fee or wait.
eleuthria
Legendary
*
Offline Offline

Activity: 1750
Merit: 1007



View Profile
February 24, 2012, 04:24:30 AM
 #15

Just to add to the talk about fees (in the case of 0tx blocks):  Don't forget that you can send your coins anywhere without a fee when you're the one mining a block Smiley.  Or you could send .00000001 and tack on a 500 BTC fee, since you're the one mining that block [don't broadcast it, just include it in the block when you build it].

RIP BTC Guild, April 2011 - June 2015
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 24, 2012, 04:33:51 AM
 #16

So, if someone had 20 computers and 40 clients, one running in a VM and one on the desktop. That machine with the proper script could be made to send coins to itself in a continuous loop or to one of the other 20 in a series. Yes?


How many coins per transaction?

24 BTC?  You can send 24 BTC again in 6 confirmations without fee, since 6 confirmation is the minimum it could continue forever.  The point of the fees is to avoid cheaply spamming the network.  i.e. taking 1 BTC and sending a million 1 satoshi transactions and keep doing that every seconds until you generate TB worth of transactions.

The number of nodes is irrelivent.  It doesn't matter where you send coins.  Hell you can send them to another address in the same wallet.

Everytime you transfer a coin its time resets to 0.  If it is too young to be used in a new transaction you must pay a fee or wait.

So again, if someone had 20 computers and 40 clients, one running in a VM and one on the desktop. Each of the 40 wallets had 24BTC with the proper script could be made to send coins to itself in a continuous loop.
 
How long would it take for the associated bloat to affect the block chain?



I don't get the fascination of 20 computers.  I already explained you could send it from 1 address in a wallet to another address in the SAME wallet and it would generate the same amount of transactions, same amount of transaction data, and incur the same limits.

Using 20 computers and 40 wallets would just be stupid.  Lots of electricity to accomplish nothing.


As far as transferring 24 BTC continually. It would create negligible transaction volume.  You must wait 6 confirms before spending so you could perform 1 transaction per hour, or ~24 per day.  At 0.25 KB per day you would add a massive 6KB per day or 2MB per year.
payb.tc
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
February 24, 2012, 04:44:40 AM
 #17

You are helping me settle an argument with someone.

So, there is no amount small enough or large enough that (since you don’t like 20 we’ll say a few computers) you could send in a continuous stream of transactions increasing the size of block chain to a point that it would be difficult to hold it on a single hard drive (my position on the issue)? Correct?


that's ridiculous in 2012... even an 'old' hard drive is 80gb+
a 'not old' hard drive is 500gb+.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 24, 2012, 04:49:08 AM
 #18

You are helping me settle an argument with someone.

So, there is no amount small enough or large enough that (since you don’t like 20 we’ll say a few computers) you could send in a continuous stream of transactions increasing the size of block chain to a point that it would be difficult to hold it on a single hard drive (my position on the issue)? Correct?


Not without prohibitively massive cost.  That is the entire point of spam fee.  It prevents spam.   Well technically it doesn't prevent it.  If someone wanted to spend tens of millions of dollars acquiring bitcoins just to massively spam the the chain they could they would just lots tens of millions of dollars in wealth to transaction fees. Smiley  It would be a good day to be a miner.

Blockchain pruning could be used to clean up any "circular" spam.  To have a lasting effect you would need to send coins somewhere permanently (so it could be pruned out).  Thus costing you not just the spam fees but the principal.

TL/DR I wouldn't say impossible just prohibitively expensive.  You could also mine your own transactions "for free" but then you are limited to block size and how many blocks you can generate per day.  To generate a large number of blocks (full of spam) each day would require hundreds if not thousands of MH/s of hashing power (which isn't free). 
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 24, 2012, 04:56:41 AM
 #19

He did make one good point though. He said that Bitcoin couldn’t be used for any real business because you need to send too many continuous transactions per hour to make it useful to big business unless they had an infinite # of wallets on a shitload of computers or they would have to pay Tx fees like a Visa terminal only the fees would be slightly lower. 

The later contradicts the former.

Couldn't be used for business except the fees would be lower.  How would lower fees make it impossible to be used by business.

Also you keep getting hung up on # of wallets.  # of wallets would have no effect on fees.  Amazon could have 1 wallet or a quadrillion wallets running on a quadrillion computers.  It would have absolutely no effect on fees, spam, transaction volume, etc.
payb.tc
Hero Member
*****
Offline Offline

Activity: 812
Merit: 1000



View Profile
February 24, 2012, 05:02:55 AM
 #20

you keep getting hung up on # of wallets.  # of wallets would have no effect on fees.  Amazon could have 1 wallet or a quadrillion wallets running on a quadrillion computers.  It would have absolutely no effect on fees, spam, transaction volume, etc.

actually d&t i think it would have a negative effect.

imagine a wallet has 3 transactions:

3 btc: old
3 btc: old
4 btc: new


you could make 2 x 1btc spends from that without incurring fees.

but let's say you had them in 3 different wallets:

a = 3 btc: old
b = 3 btc: old
c = 4 btc: new

if you spend from the 'c' wallet, you'd have to pay a fee because it can't find any old transactions to spend from... even though you've got plenty of old transactions in your other wallets.

Pages: [1] 2 »  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!