Bitcoin Forum
May 02, 2024, 01:11:49 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Is a reduced reward time possible?  (Read 3037 times)
pootie
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
January 21, 2016, 05:41:27 AM
 #21

It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.

In the case of a Finney attack, the quicker that the average block is mined, the less time the attacker has to execute the double payment and then broadcast his mined block (http://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack). It would cost the attacker half as much time, but he would be racing against other miners who would be solving twice as fast. I imagine there are other security issues associated with faster reward time but I don't see how it makes Finney attacks more likely.

The reduced time does not affect how long (time wise) it would take for a transaction to be considered safe. If blocks can be solved with less hash power, then the orphan rate increases and thus lower confirmation numbers become less safe. It would still take 10-20 minutes for a transaction to be considered safe, just that instead of having 1 or 2 confirmations, it becomes having a lot more confirmations

Is this necessarily true? I think it depends on whether the confirmation accuracy scales at the same rate as the number of stale blocks. From what I understand, lower reward time --> more stale blocks --> more stale transactions percolating through the network --> less confidence in confirmations --> need for greater # of confirmations. 1) Is that right? 2) If so, I can't imagine each piece scales proportionally, which is what it seems like you're proposing above (in asserting that safe transaction time wouldn't change).
1714612309
Hero Member
*
Offline Offline

Posts: 1714612309

View Profile Personal Message (Offline)

Ignore
1714612309
Reply with quote  #2

1714612309
Report to moderator
1714612309
Hero Member
*
Offline Offline

Posts: 1714612309

View Profile Personal Message (Offline)

Ignore
1714612309
Reply with quote  #2

1714612309
Report to moderator
1714612309
Hero Member
*
Offline Offline

Posts: 1714612309

View Profile Personal Message (Offline)

Ignore
1714612309
Reply with quote  #2

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

Posts: 1714612309

View Profile Personal Message (Offline)

Ignore
1714612309
Reply with quote  #2

1714612309
Report to moderator
saturn643
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
January 21, 2016, 08:58:17 PM
 #22

It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.

In the case of a Finney attack, the quicker that the average block is mined, the less time the attacker has to execute the double payment and then broadcast his mined block (http://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack). It would cost the attacker half as much time, but he would be racing against other miners who would be solving twice as fast. I imagine there are other security issues associated with faster reward time but I don't see how it makes Finney attacks more likely.

The reduced time does not affect how long (time wise) it would take for a transaction to be considered safe. If blocks can be solved with less hash power, then the orphan rate increases and thus lower confirmation numbers become less safe. It would still take 10-20 minutes for a transaction to be considered safe, just that instead of having 1 or 2 confirmations, it becomes having a lot more confirmations

Is this necessarily true? I think it depends on whether the confirmation accuracy scales at the same rate as the number of stale blocks. From what I understand, lower reward time --> more stale blocks --> more stale transactions percolating through the network --> less confidence in confirmations --> need for greater # of confirmations. 1) Is that right? 2) If so, I can't imagine each piece scales proportionally, which is what it seems like you're proposing above (in asserting that safe transaction time wouldn't change).

That is what I understand from what I have read on this topic. The reduced block time makes it more susceptible to attacks due to a reduced difficulty and that the safe transaction time is still the same. I'm not sure about the exact details of this and I am not an expert on this, you should do your own research.
Bungeebones (OP)
Full Member
***
Offline Offline

Activity: 178
Merit: 100



View Profile
January 22, 2016, 09:34:23 PM
 #23

Some reasons against it:
It decreases the security of the network proportional to how much the time was decreased. E.g. decreasing the block time by half also decreases the security by half because then it would only cost an attacker half as much in order to pull off an attack like a finney attack.

Maybe it is just rumor but I heard that the Bitcoin network is already the world's largest computer network by an incredibly large margin. Is that just a lot of bunk? Because if what seems to be an excessive amount of capacity is not on the table after months of debate about blocksize to the point of nausea then why? How much capacity is just the right amount of security?

I've heard (don't know if it is reliable) that the Bitcoin network has the computing power of the top 500 supercomputers combined. Is that true or a bunch of horsecrap? if not true, let's get an accurate number. If true then it would seem talk about loss of security is not accurate.
saturn643
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
January 23, 2016, 01:37:53 AM
 #24

Maybe it is just rumor but I heard that the Bitcoin network is already the world's largest computer network by an incredibly large margin. Is that just a lot of bunk? Because if what seems to be an excessive amount of capacity is not on the table after months of debate about blocksize to the point of nausea then why? How much capacity is just the right amount of security?
Actually the internet is the worlds largest computer network. What is "an excessive amount of capacity"? Capacity for what? Block size is not the Bitcoin network but rather the blockchain itself, which is different from the network. The network has immense capacity, just like the internet. Loads of data passes through the network, but the blockchain, that is a different matter, which is separate from the network.

I've heard (don't know if it is reliable) that the Bitcoin network has the computing power of the top 500 supercomputers combined. Is that true or a bunch of horsecrap? if not true, let's get an accurate number. If true then it would seem talk about loss of security is not accurate.
It is not comparable. Supercomputers are almost like general application computers. They can do a lot of stuff, they are application specific like most mining hardware is. Sure the hash power is probably capable of producing SHA256d hashes faster than any supercomputer, but when it comes to doing other stuff, especially for benchmarks, the network can do squat. It is not a fair comparison, in fact, it is essentially a comparison of apples to oranges, they are two different things.

As for a loss of security, while the loss of security at this time may be small, we shouldn't do anything which can result in any loss of security. However small the loss is, if we can avoid it, we should.
pawel7777
Legendary
*
Offline Offline

Activity: 2436
Merit: 1559



View Profile WWW
January 25, 2016, 12:15:29 PM
 #25


Vitalik Buterin's (non-serious) proposal on soft-forking block time to 2 mins (increasing tx/sec capacity by x5):

https://www.reddit.com/r/btc/comments/428tjl/softforking_the_block_time_to_2_min_my_primarily/?ref=share&ref_source=link

Quote
So given that large portions of the bitcoin community seem to be strongly attached to this notion that hard forks are an unforgivable evil, to the point that schemes containing hundreds of lines of code are deemed to be a preferred alternative, I thought that I'd offer an alternative strategy to increasing the bitcoin blockchain's throughput with nothing more than a soft fork - one which is somewhat involved and counterintuitive, but for which the code changes are actually quite a bit smaller than some of the alternatives; particularly, "upper layers" of the protocol stack should need no changes at all.

...

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
mamadmankan
Member
**
Offline Offline

Activity: 73
Merit: 10


View Profile
January 25, 2016, 02:17:12 PM
 #26

How many altcoin forked their blockchain to get the faster block times? Forking is different and harder to do than having the block time originally since it requires a certain activation threshold and other conditions before the variables can change.
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!