Bitcoin Forum
August 14, 2018, 09:49:19 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: 1 2 [All]
  Print  
Author Topic: What is the incentive to collect transactions?  (Read 11406 times)
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 3108
Merit: 3373


View Profile
June 05, 2010, 04:26:09 PM
 #1

Adding transactions to the block you're working on will slow down your generation rate. What prevents the majority of generating nodes from ignoring broadcasted transactions and making the network unreliable?

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
1534283359
Hero Member
*
Offline Offline

Posts: 1534283359

View Profile Personal Message (Offline)

Ignore
1534283359
Reply with quote  #2

1534283359
Report to moderator
1534283359
Hero Member
*
Offline Offline

Posts: 1534283359

View Profile Personal Message (Offline)

Ignore
1534283359
Reply with quote  #2

1534283359
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1534283359
Hero Member
*
Offline Offline

Posts: 1534283359

View Profile Personal Message (Offline)

Ignore
1534283359
Reply with quote  #2

1534283359
Report to moderator
1534283359
Hero Member
*
Offline Offline

Posts: 1534283359

View Profile Personal Message (Offline)

Ignore
1534283359
Reply with quote  #2

1534283359
Report to moderator
1534283359
Hero Member
*
Offline Offline

Posts: 1534283359

View Profile Personal Message (Offline)

Ignore
1534283359
Reply with quote  #2

1534283359
Report to moderator
lachesis
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile
June 05, 2010, 06:59:19 PM
 #2

I don't know if there are any technological safeguards to prevent this, but there is a social one: if you drop transactions, others might drop yours.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
sirius
Bitcoiner
Sr. Member
****
Offline Offline

Activity: 429
Merit: 251



View Profile
June 05, 2010, 07:22:38 PM
 #3

Bitcoin supports transaction fees paid to the node that records a transaction into the block chain. If too many nodes start dropping transactions, you can pay a fee when you want to increase the likeliness of your transaction being recorded in the next block.

Identifi - Decentralized address book with trust ratings
I'm not a forum admin - please contact theymos instead.
laszlo
Full Member
***
Offline Offline

Activity: 199
Merit: 274


View Profile
June 05, 2010, 07:42:17 PM
 #4

So would it be smarter to only process transactions which profit you?  That way if you want to send money you need to include a courier fee or nobody will confirm it.  That seems reasonable to me, where you can add a fee yourself to each transaction, and people can configure a threshold of how much of a fee they expect before accepting a transaction.

BC: 157fRrqAKrDyGHr1Bx3yDxeMv8Rh45aUet
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 3108
Merit: 3373


View Profile
June 05, 2010, 07:55:40 PM
 #5

That's a clever (and very free-market) solution. How does BitCoin currently deal with transactions that aren't published in a block for a long time? Is there any risk of them being lost?

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
QuantumMechanic
Member
**
Offline Offline

Activity: 110
Merit: 14


View Profile
June 05, 2010, 08:02:09 PM
 #6

Are there any estimates on the average transaction fee once users' incentive to support the network via bitcoin generation is mostly dried up?  How does this scale with the number of users, the size of network, and the total transaction rate?
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 1361


View Profile
June 15, 2010, 11:41:29 PM
 #7

Adding transactions to the block you're working on will slow down your generation rate
The premise is false.  Adding more transactions to the block you're working on does NOT slow down your generation rate.  When generate is scanning hashes, it only hashes the header of the block, which is constant size.  The header contains a hash of the transactions (the Merkle root) and is only updated occasionally.

If necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about.  A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in.  I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.
Stickboy
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
July 13, 2010, 05:38:55 AM
 #8

I'm new here so forgive me if I say something stupid.

Under normal circumstances there might be no advantage not to include all transactions but what about pure malicious motivations?  If this is an avenue for disrupting the currency I certainly would think twice about "keeping my money there", so to speak.
jib
Member
**
Offline Offline

Activity: 92
Merit: 10


View Profile
July 13, 2010, 05:46:31 AM
 #9

It doesn't matter if a transaction's not included; it'll get included in a later block. As long as the attackers have much less CPU power than the rest of the network, they won't be a problem.
Come-from-Beyond
Legendary
*
Online Online

Activity: 2030
Merit: 1007

Newbie


View Profile
October 05, 2012, 07:10:38 PM
 #10

Adding transactions to the block you're working on will slow down your generation rate
The premise is false.  Adding more transactions to the block you're working on does NOT slow down your generation rate.  When generate is scanning hashes, it only hashes the header of the block, which is constant size.  The header contains a hash of the transactions (the Merkle root) and is only updated occasionally.

If necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about.  A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in.  I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.

What if the state developed and sold a lot of ASICs that don't include any transaction? If these ASICs are better than anyone's else, then most of miners will use such malicious devices. The state can afford to hire the best scientists and the best engineers to create such ASICs. It can even sell these devices much cheaper than, say, Butterfly Labs. Was the mentioned functionality (rejecting blocks with not enough transaction) implemented?
maaku
Legendary
*
expert
Offline Offline

Activity: 905
Merit: 1001


View Profile
October 05, 2012, 07:46:27 PM
 #11

You, sir, are a powerful necromancer.

Can you raise Satoshi from the dead too?

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Come-from-Beyond
Legendary
*
Online Online

Activity: 2030
Merit: 1007

Newbie


View Profile
October 05, 2012, 09:02:43 PM
 #12

No, it wasn't, thankfully. It is the miners choice to add or not add transactions to a block.

You worry about a state attacking Bitcoin, yet want to force miners, via the protocol, to add transactions? /facepalm

Eventually, transactions fees will be the main method by which miners are compensated for their work. There is no reason to change anything. Let the market take care of it. If miners don't add ANY transactions, they won't receive any transaction fees, and their competition will earn more than them and outpace them in the hardware arms race.

I'm talking about next few years.

If u were a miner what would u choose:
1. Find 1 block every 24 hours with some fees.
2. Find 1 block every 16 hours with no fees.

Huh
Come-from-Beyond
Legendary
*
Online Online

Activity: 2030
Merit: 1007

Newbie


View Profile
October 05, 2012, 09:09:16 PM
 #13

You, sir, are a powerful necromancer.

Can you raise Satoshi from the dead too?

I was led here via https://en.bitcoin.it/wiki/Weaknesses (search for "Satoshi has communicated that he will write code to stop this kind of thing if it becomes a problem" text). So I'm not a necrophiliac. Smiley
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1554
Merit: 1001


View Profile
October 05, 2012, 09:09:35 PM
 #14

I'm talking about next few years.

If u were a miner what would u choose:
1. Find 1 block every 24 hours with some fees.
2. Find 1 block every 16 hours with no fees.

And if everybody's bitcoin transactions take forever to confirm, users will abandon the network, and bitcoins will have no value.

Miners have an incentive to encourage users to use bitcoins, over and above simple fee income.

The more users, the more value conferred by the block reward + fee total.

No users, block reward + fee is worthless.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Come-from-Beyond
Legendary
*
Online Online

Activity: 2030
Merit: 1007

Newbie


View Profile
October 05, 2012, 09:10:39 PM
 #15

If in some make-believe I was forced to choose between the two, I would choose option 1, I'm not stupid enough to think that Bitcoin can have value if it can not function properly.

Most miners will choose option 2 coz of greed.
Come-from-Beyond
Legendary
*
Online Online

Activity: 2030
Merit: 1007

Newbie


View Profile
October 05, 2012, 09:13:33 PM
 #16

Miners have an incentive to encourage users to use bitcoins, over and above simple fee income.

I disagree. I know some miners who own mining farms. They mine coz it's easy way to earn money, they don't care what will happen to Bitcoin in the future.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1554
Merit: 1001


View Profile
October 05, 2012, 09:18:07 PM
 #17

Miners have an incentive to encourage users to use bitcoins, over and above simple fee income.

I disagree. I know some miners who own mining farms. They mine coz it's easy way to earn money, they don't care what will happen to Bitcoin in the future.

The existence of an incentive does not presuppose all will follow that.

Thankfully, most do, otherwise value would collapse.


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

Activity: 1302
Merit: 1001



View Profile
October 05, 2012, 10:09:18 PM
 #18

I'm talking about next few years.

If u were a miner what would u choose:
1. Find 1 block every 24 hours with some fees.
2. Find 1 block every 16 hours with no fees.

Why on earth would anyone make this choice?  Are you confused about how mining works?  Here's a hint to get you started: including transactions does not hurt your hash rate.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Come-from-Beyond
Legendary
*
Online Online

Activity: 2030
Merit: 1007

Newbie


View Profile
October 05, 2012, 10:12:53 PM
 #19

I'm talking about next few years.

If u were a miner what would u choose:
1. Find 1 block every 24 hours with some fees.
2. Find 1 block every 16 hours with no fees.

Why on earth would anyone make this choice?  Are you confused about how mining works?  Here's a hint to get you started: including transactions does not hurt your hash rate.

Heh. It's the 1st time I see a person who can write but can't read.

What if the state developed and sold a lot of ASICs that don't include any transaction? If these ASICs are better than anyone's else, then most of miners will use such malicious devices. The state can afford to hire the best scientists and the best engineers to create such ASICs. It can even sell these devices much cheaper than, say, Butterfly Labs. Was the mentioned functionality (rejecting blocks with not enough transaction) implemented?

Should I rewrite it MORE slowly?  Grin
Inaba
Legendary
*
Offline Offline

Activity: 1260
Merit: 1000



View Profile WWW
October 05, 2012, 10:17:09 PM
 #20

Holy shit I was so confused when reading this... I didn't look at the date to start with and was like total WTF.



But to answer your question: What is the incentive to do so?  To destroy bitcoin?  There are easier, quicker, cheaper ways to do that... The threat of a state or powerful actor going through the trouble and expense to wreck bitcoin in that manner is pretty remote, because it's exceptionally inefficient once the ASICs are in the wild and network hashing power is measured in hundreds of TH, not just 10 or 20.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2534
Merit: 1006



View Profile
October 05, 2012, 10:24:11 PM
 #21

Adding transactions to the block you're working on will slow down your generation rate
The premise is false.  Adding more transactions to the block you're working on does NOT slow down your generation rate.  When generate is scanning hashes, it only hashes the header of the block, which is constant size.  The header contains a hash of the transactions (the Merkle root) and is only updated occasionally.

If necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about.  A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in.  I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.

What if the state developed and sold a lot of ASICs that don't include any transaction? If these ASICs are better than anyone's else, then most of miners will use such malicious devices. The state can afford to hire the best scientists and the best engineers to create such ASICs. It can even sell these devices much cheaper than, say, Butterfly Labs. Was the mentioned functionality (rejecting blocks with not enough transaction) implemented?

The ASIC itself doesn't concern itself with block construction, that's done by mining software on host machine. The ASIC only does the dirty hashing work.

As said by Satoshi and also Gavin and others more recently (when that botnet or whatever it was appearead early 2012 mining non-tx block) there are effective ways to deal with such an attack.

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

Activity: 1302
Merit: 1001



View Profile
October 05, 2012, 11:02:18 PM
 #22

I'm talking about next few years.

If u were a miner what would u choose:
1. Find 1 block every 24 hours with some fees.
2. Find 1 block every 16 hours with no fees.

Why on earth would anyone make this choice?  Are you confused about how mining works?  Here's a hint to get you started: including transactions does not hurt your hash rate.

Heh. It's the 1st time I see a person who can write but can't read.

What if the state developed and sold a lot of ASICs that don't include any transaction? If these ASICs are better than anyone's else, then most of miners will use such malicious devices. The state can afford to hire the best scientists and the best engineers to create such ASICs. It can even sell these devices much cheaper than, say, Butterfly Labs. Was the mentioned functionality (rejecting blocks with not enough transaction) implemented?

Should I rewrite it MORE slowly?  Grin

How about you write it on this planet instead?

In your hypothetical universe where the chip has the telepathic ability to refuse to hash blocks that include transactions, pigs will fly out of unicorn asses.

In this universe, where the ability to get paid for a block is exactly the same thing, as far as the chip is concerned, as being able to include transactions, no one can force this choice on you.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Come-from-Beyond
Legendary
*
Online Online

Activity: 2030
Merit: 1007

Newbie


View Profile
October 06, 2012, 05:53:13 AM
 #23

There are easier, quicker, cheaper ways to do that...

We'll get rid of all weaknesses one by one. I'm analyzing this one right now.


The ASIC itself doesn't concern itself with block construction, that's done by mining software on host machine. The ASIC only does the dirty hashing work.

It seems to be possible to move "block construction" logic into the chip.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2534
Merit: 1006



View Profile
October 06, 2012, 12:14:46 PM
 #24

It seems to be possible to move "block construction" logic into the chip.

It's possible to move anything into the chip... however it doesn't make sense because "block construction" is complex and not time-critical.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
Come-from-Beyond
Legendary
*
Online Online

Activity: 2030
Merit: 1007

Newbie


View Profile
October 06, 2012, 12:18:08 PM
 #25

It seems to be possible to move "block construction" logic into the chip.

It's possible to move anything into the chip... however it doesn't make sense because "block construction" is complex and not time-critical.

For the state that wants to shutdown Bitcoin it does make sense.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2534
Merit: 1006



View Profile
October 06, 2012, 01:00:54 PM
 #26

It seems to be possible to move "block construction" logic into the chip.

It's possible to move anything into the chip... however it doesn't make sense because "block construction" is complex and not time-critical.

For the state that wants to shutdown Bitcoin it does make sense.

Why would they sell the chips, though, instead of simply running them themselves? In that case they might as well use ASIC only for hashing (as would be sensible as argued) because they control the software and can do 0-tx-block-construction on CPU.

Also: please recall my argument that there are possible countermeasures against this which could be employed once the attack commences. This makes the attack impractical (it will fail) and therefore noone will attempt it. Even without actually implementing the countermeasures beforehand, merely the possibility of implementing them on demand is sufficient to avoid this attack.

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

Activity: 1764
Merit: 1002



View Profile
March 05, 2013, 10:42:45 PM
 #27


Also: please recall my argument that there are possible countermeasures against this which could be employed once the attack commences. This makes the attack impractical (it will fail) and therefore noone will attempt it. Even without actually implementing the countermeasures beforehand, merely the possibility of implementing them on demand is sufficient to avoid this attack.


can u elaborate on what countermeasures can be taken?  what happened to the Mystery Miner?
molecular
Donator
Legendary
*
Offline Offline

Activity: 2534
Merit: 1006



View Profile
March 06, 2013, 10:35:05 PM
 #28


Also: please recall my argument that there are possible countermeasures against this which could be employed once the attack commences. This makes the attack impractical (it will fail) and therefore noone will attempt it. Even without actually implementing the countermeasures beforehand, merely the possibility of implementing them on demand is sufficient to avoid this attack.


can u elaborate on what countermeasures can be taken?  what happened to the Mystery Miner?

Wow, this was a while ago... I cant even remember the thread in which the countermeasures (I guess we're talking about a "0-tx-block" attack) have been discussed.

One idea (the one that stuck in my memory until now) was to reject blocks that contain substantially less transactions than are currently in the set of transaction awaiting a block from the point of view of each node/miner. This would avoid falsely rejecting blocks in cases where a block is found shortly after another one and so there are no (or a low number of) transactions or in cases where there are no or not many transaction for other reasons.

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

Activity: 1512
Merit: 1000



View Profile WWW
March 06, 2013, 11:23:44 PM
 #29

This undead thread is fundamentally flawed in any and all assumptions that are being made as a basis of argument.

1:

Adding transactions to the block you're working on will slow down your generation rate. What prevents the majority of generating nodes from ignoring broadcasted transactions and making the network unreliable?

Theymos made an incorrect assumption, hash rate is in no way affected by the inclusion or non-inclusion of transactions, there is no advantage to not including transactions. There may have been a very small bit of CPU used in the CPU solo mining days when creating a new merkle tree when a new transaction was received, but these days where multiple pools have over 4TH, the number of included transactions in no way impacts the hashing that miners are doing - they don't even know how many transactions are in the block data that is being hashed.

Secondly, even if 50% of the blocks included no transactions, Bitcoin would keep on working. There was already a "mystery miner" that was using a botnet that didn't include transactions, and his 10% of the hashrate was merely a curiosity.

If a bad actor has more than 50% of the hashrate required to deny transaction inclusion on more than half the blocks mined, there is a much bigger problem, as they already have enough hashrate to do a 51% attack and can cause more problems by rewriting block history, double spending and erasing blocks. Bitcoin relies on a majority of mining being good, there is little defense against a majority hashrate attack.

Finally there is no motivation for this. If a pool operator was doing something against the interests of Bitcoin, it would be known and miners would leave. Not including transactions would be passing up considerable earnings.



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!