Bitcoin Forum
November 03, 2024, 11:20:28 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 »  All
  Print  
Author Topic: blockstream - wants to tax you and become the new Bitcoin oligarchy  (Read 8946 times)
tvbcof
Legendary
*
Offline Offline

Activity: 4746
Merit: 1277


View Profile
August 24, 2015, 01:00:29 AM
 #161


sidechains sound like they could be a great innovation.  the issue that I see is they are being used to justify keeping the blocks small.  Why should we be forced to use sidechains?  Why can't we have sidechains AND bigger blocks?

I've never heard anyone ever say that Bitcoin should be off-limits to anyone who is willing to pay the going rate for transactions on a secure system.  That is, one which throws a huge amount of power into locking the transactions, and maintains multiple copies of the transaction on multiple systems scattered around the world and retained indefinitely.

The cost of such a solution is significant.  The costs could come down to a very low level by centralization and consolidation of the support infrastructure just as has been the case for other many other on-line services.  That is very undesirable from a security standpoint however.  To me it would destroy any value Bitcoin has at all.  Exponentially growing blocks as Gavin and Mike have tried to ram home are a sure-fire recipe for severe centralization eventually.  They pretty much bake it in.

Sidechains leverages the power of of the core solution with autonomous chains to take the load of less critical transactions.  It ties things together with immutable math rather state sponsored judicial systems which are increasingly capricious.  They are, to me, a pretty strong win.


sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
jonald_fyookball (OP)
Legendary
*
Offline Offline

Activity: 1302
Merit: 1008


Core dev leaves me neg feedback #abuse #political


View Profile
August 24, 2015, 01:02:55 AM
 #162

sidechains sound like they could be a great innovation.  the issue that I see is they are being used to justify keeping the blocks small.  Why should we be forced to use sidechains?  Why can't we have sidechains AND bigger blocks?

But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive.

The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with.

Then what? Emergency doubling? That won't cause another argument at all, will it? Come on.

This sounds like an all-or-nothing fallacy to me.  We don't have the 'perfect' solution so its better to do nothing?
I don't agree with that.  I would rather see 8mb now while solutions continue to be developed.


Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3080



View Profile
August 24, 2015, 01:06:36 AM
 #163

sidechains sound like they could be a great innovation.  the issue that I see is they are being used to justify keeping the blocks small.  Why should we be forced to use sidechains?  Why can't we have sidechains AND bigger blocks?

But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive.

The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with.

Then what? Emergency doubling? That won't cause another argument at all, will it? Come on.

This sounds like an all-or-nothing fallacy to me.  We don't the 'perfect' solution so its better to do nothing?
I don't agree with that.  I would rather see 8mb now while solutions continue to be developed.

You know perfectly well that I do not support doing nothing, and intimate as such in the very text you replied to.

You are attempting to submit to me a straw man argument. Done with you jonald, I will not entertain such open dishonesty

Vires in numeris
jonald_fyookball (OP)
Legendary
*
Offline Offline

Activity: 1302
Merit: 1008


Core dev leaves me neg feedback #abuse #political


View Profile
August 24, 2015, 01:11:47 AM
 #164

sidechains sound like they could be a great innovation.  the issue that I see is they are being used to justify keeping the blocks small.  Why should we be forced to use sidechains?  Why can't we have sidechains AND bigger blocks?

But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive.

The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with.

Then what? Emergency doubling? That won't cause another argument at all, will it? Come on.

This sounds like an all-or-nothing fallacy to me.  We don't the 'perfect' solution so its better to do nothing?
I don't agree with that.  I would rather see 8mb now while solutions continue to be developed.

You know perfectly well that I do not support doing nothing, and intimate as such in the very text you replied to.

You are attempting to submit to me a straw man argument. Done with you jonald, I will not entertain such open dishonesty

Please.

You were the one who just introduced a strawman: "what if there's an 8 fold increase, then we are back to square one".

You seem more interested in arguing the problems than offering solutions, so if you are done
in this thread, that is fine with me.  Good day.






becoin
Legendary
*
Offline Offline

Activity: 3431
Merit: 1233



View Profile
August 24, 2015, 09:57:58 AM
 #165

But why support such a poor design for increasing the blocksize?
Because they have no time. In few months side chains will catapult bitcoin into completely different orbit that is unreachable to bitcoin enemies. They have to cripple bitcoin now. It is a question of now or never. This is why is all that hectic creation of XT nodes.
dachnik
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
August 24, 2015, 11:35:09 AM
Last edit: August 24, 2015, 11:56:18 AM by dachnik
 #166

A few more thoughts on the matter...

Firstly, the stable and tested core has been proven to increase its soft limit from 250Kb, to 500Kb, to then 750Kb in order to survive this long by being a useful transactional medium with a single ledger. Artificially capping it to 1Mb now cannot be claimed as a safe solution going forward, because we are entering an uncharted territory here. Again a proven and workable solution that we currently have and value is known to have been increasing the cap, not maintaining it.

Secondly, the market for fees will emerge naturally as the network can timestamp a limited amount of transactions not because of an artificial cap, but due to physical limitations related to block propagation times and network stability. Whether we need an explicit limit baked into the protocol or allow the network to find its own equilibrium (with a help of outside competition in altcoin space) is a question open to debate. A series of planned workshops should help find a common ground with regards to this.

Thirdly, the idea of every monetary transaction on a single ledger might sound Utopian with present day technology and limitations, however, it is not entirely out of question. I, personally, don't think that every coffee purchase will be on blockchain within next 5 to 10 years, but it doesn't mean that we have to artificially cap the blockchain beyond what current technology allows. What transactions are in and what out will be decided by the market.
Muhammed Zakir
Hero Member
*****
Offline Offline

Activity: 560
Merit: 509


I prefer Zakir over Muhammed when mentioning me!


View Profile WWW
August 24, 2015, 12:00:06 PM
 #167

sidechains sound like they could be a great innovation.  the issue that I see is they are being used to justify keeping the blocks small.  Why should we be forced to use sidechains?  Why can't we have sidechains AND bigger blocks?

But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive.

The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with.

Then what? Emergency doubling? That won't cause another argument at all, will it? Come on.

This sounds like an all-or-nothing fallacy to me.  We don't have the 'perfect' solution so its better to do nothing?
I don't agree with that.  I would rather see 8mb now while solutions continue to be developed.

Of course, its not better to do nothing. But is bad better than nothing? Is not it better to discuss more to find a better solution than to implement a bad one? 1 MB now is not a problem now except when blockchain is spammed by so-called "stress test". IMHO its better to wait a little than to implement BIP 101. No offence.

dachnik
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
August 24, 2015, 12:37:19 PM
Last edit: August 24, 2015, 01:08:42 PM by dachnik
 #168

sidechains sound like they could be a great innovation.  the issue that I see is they are being used to justify keeping the blocks small.  Why should we be forced to use sidechains?  Why can't we have sidechains AND bigger blocks?

But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive.

The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with.

Then what? Emergency doubling? That won't cause another argument at all, will it? Come on.

This sounds like an all-or-nothing fallacy to me.  We don't have the 'perfect' solution so its better to do nothing?
I don't agree with that.  I would rather see 8mb now while solutions continue to be developed.

Of course, its not better to do nothing. But is bad better than nothing? Is not it better to discuss more to find a better solution than to implement a bad one? 1 MB now is not a problem now except when blockchain is spammed by so-called "stress test". IMHO its better to wait a little than to implement BIP 101. No offence.

8Mb is what Bitcoin needs in order to have only twice the capacity of its closest PoW competitor. However a soft cap of 4Mb might be a good safety measure for the initial ramp up schedule. Whether doubling should occur every two or every four years and what an ultimate cap (if any) should be is all debatable.
Muhammed Zakir
Hero Member
*****
Offline Offline

Activity: 560
Merit: 509


I prefer Zakir over Muhammed when mentioning me!


View Profile WWW
August 24, 2015, 12:49:48 PM
 #169

sidechains sound like they could be a great innovation.  the issue that I see is they are being used to justify keeping the blocks small.  Why should we be forced to use sidechains?  Why can't we have sidechains AND bigger blocks?

But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive.

The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with.

Then what? Emergency doubling? That won't cause another argument at all, will it? Come on.

This sounds like an all-or-nothing fallacy to me.  We don't have the 'perfect' solution so its better to do nothing?
I don't agree with that.  I would rather see 8mb now while solutions continue to be developed.

Of course, its not better to do nothing. But is bad better than nothing? Is not it better to discuss more to find a better solution than to implement a bad one? 1 MB now is not a problem now except when blockchain is spammed by so-called "stress test". IMHO its better to wait a little than to implement BIP 101. No offence.

8Mb is what Bitcoin needs in order to have twice the capacity of its closest PoW competitor. However a soft cap of 4Mb might be a good safety measure for the initial ramp up schedule. Whether doubling should occur every two or every four years and what an ultimate cap (if any) should be is all debatable.

Yes. We need to have bigger block size to handle a high number of transaction but we can't just increase to 8 MB because of that. Its always better to increase block size gradually. Now, there is no need for 8 MB and doubling every X years does not make sense. We need dynamic block size, of course, but a better one.

Quickseller
Copper Member
Legendary
*
Offline Offline

Activity: 2996
Merit: 2371


View Profile
August 24, 2015, 12:53:59 PM
 #170

sidechains sound like they could be a great innovation.  the issue that I see is they are being used to justify keeping the blocks small.  Why should we be forced to use sidechains?  Why can't we have sidechains AND bigger blocks?

But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive.

The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with.

Then what? Emergency doubling? That won't cause another argument at all, will it? Come on.

This sounds like an all-or-nothing fallacy to me.  We don't have the 'perfect' solution so its better to do nothing?
I don't agree with that.  I would rather see 8mb now while solutions continue to be developed.

Of course, its not better to do nothing. But is bad better than nothing? Is not it better to discuss more to find a better solution than to implement a bad one? 1 MB now is not a problem now except when blockchain is spammed by so-called "stress test". IMHO its better to wait a little than to implement BIP 101. No offence.
The only reason that BIP101 is bad is that there is the possibility that it will be attempted to be implemented without consensus. There is no real reason why the network would not be able to support 8MB blocks on a technical basis and Moores law would imply that technology will advance quickly enough so that the network will continue to be able to support the increasingly large max block size and if it doesn't then then Bitcoin can be formed again.

★ ★ ██████████████████████████████[█████████████████████
██████████████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████████
███████████████████████████████████████████████████████████████████
████████████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████████
███████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████
████████████████████████████████████████████████████████████
███████████████████████████████████████████████████████████████████
★ ★ 
dachnik
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
August 24, 2015, 01:24:30 PM
 #171

sidechains sound like they could be a great innovation.  the issue that I see is they are being used to justify keeping the blocks small.  Why should we be forced to use sidechains?  Why can't we have sidechains AND bigger blocks?

But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive.

The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with.

Then what? Emergency doubling? That won't cause another argument at all, will it? Come on.

This sounds like an all-or-nothing fallacy to me.  We don't have the 'perfect' solution so its better to do nothing?
I don't agree with that.  I would rather see 8mb now while solutions continue to be developed.

Of course, its not better to do nothing. But is bad better than nothing? Is not it better to discuss more to find a better solution than to implement a bad one? 1 MB now is not a problem now except when blockchain is spammed by so-called "stress test". IMHO its better to wait a little than to implement BIP 101. No offence.

8Mb is what Bitcoin needs in order to have twice the capacity of its closest PoW competitor. However a soft cap of 4Mb might be a good safety measure for the initial ramp up schedule. Whether doubling should occur every two or every four years and what an ultimate cap (if any) should be is all debatable.

Yes. We need to have bigger block size to handle a high number of transaction but we can't just increase to 8 MB because of that. Its always better to increase block size gradually. Now, there is no need for 8 MB and doubling every X years does not make sense. We need dynamic block size, of course, but a better one.

There wasn't a need for 1Mb limit 4 years ago either, we could have done away with 256Kb or 512Kb just fine. In fact, up until recently the hard 1Mb cap wasn't effective at all as it never was approached. But smaller soft limits were all hit and raised. That's how Bitcoin survived.

As this time we are discussing rising the hard limit (via hard fork) we need to future proof it a little bit. In this light, 8Mb seems reasonable as a new hard limit for the next 4 years, in conjunction with smaller soft limits that miners can agree to maintain internally to prevent network spamming and abuse. They can, for example, agree to not build on top of anything larger than 4Mb initially, however full nodes will still accept and propagate blocks all the way up to 8Mb. This way the infrastructure will be ready for soft expansion in the future.

Whether to expand beyond 8Mb, when and how is questionable and depends on many factors. Maybe a series of hard-forks down the road will be a more appropriate and responsible solution than trying to predict the technology, but anything less than 8Mb for the upcoming years might start hurting Bitcoin and deflect its user base towards other solutions. We, as a community, definitely don't want that.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3080



View Profile
August 24, 2015, 01:45:32 PM
Last edit: August 24, 2015, 01:59:50 PM by Carlton Banks
 #172

Moores law would imply that technology will advance quickly enough so that the network will continue to be able to support the increasingly large max block size and if it doesn't then then Bitcoin can be formed again.

Intel conceded that Moore's law as applied to silicon lithography ran out of legs, the story came out a few weeks ago. Their next "tock" in their world renowned "tick-tock" development strategy has been re-scheduled to become a "tick" for the first time in history.

Exponential growth is not the same thing as infinite growth. Because exponential trends necessarily end when they hit the apex.

Vires in numeris
hdbuck
Legendary
*
Offline Offline

Activity: 1260
Merit: 1002



View Profile
August 24, 2015, 01:58:16 PM
 #173

Moores law would imply that technology will advance quickly enough so that the network will continue to be able to support the increasingly large max block size and if it doesn't then then Bitcoin can be formed again.

Intel conceded that Moore's law as applied to silicon lithography ran out of legs, the story came out a few weeks ago. Their next "tock" in their world renowned "tick-tock" develooment strategy has been re-scheduled to become a "tick" for the first time in history.

Exponential growth is not the same thing as infinite growth. Because exponential trends necessarily end when they hit the apex.

lol these people are so far away from reality, talking about things they will never grasp, it is dramatically staggering.

hopefully bitcoin will absorb this nonsense and rise from the xt ashes.
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2965


Terminated.


View Profile WWW
August 24, 2015, 02:03:29 PM
 #174

The only reason that BIP101 is bad is that there is the possibility that it will be attempted to be implemented without consensus. There is no real reason why the network would not be able to support 8MB blocks on a technical basis and Moores law would imply that technology will advance quickly enough so that the network will continue to be able to support the increasingly large max block size and if it doesn't then then Bitcoin can be formed again.
Moore's law? It looks like you aren't up to date with that one.
Quote
Intel confirmed in 2015 that the pace of advancement has slowed, starting at the 22 nm node around 2012 and continuing at 14 nm. Brian Krzanich, CEO of Intel, announced that “our cadence today is closer to two and a half years than two.
It is going to get worse from here, until the transition to something entirely new. The growth factor in BIP 101 is not sustainable and people should be aware of this. That's one of the main problems.

Intel conceded that Moore's law as applied to silicon lithography ran out of legs, the story came out a few weeks ago. Their next "tock" in their world renowned "tick-tock" development strategy has been re-scheduled to become a "tick" for the first time in history.

Exponential growth is not the same thing as infinite growth. Because exponential trends necessarily end when they hit the apex.
This explains it as well. My quote was from Wikipedia, as I failed at finding the article that I have recently read.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
Muhammed Zakir
Hero Member
*****
Offline Offline

Activity: 560
Merit: 509


I prefer Zakir over Muhammed when mentioning me!


View Profile WWW
August 24, 2015, 02:10:37 PM
 #175

The only reason that BIP101 is bad is that there is the possibility that it will be attempted to be implemented without consensus. There is no real reason why the network would not be able to support 8MB blocks on a technical basis and Moores law would imply that technology will advance quickly enough so that the network will continue to be able to support the increasingly large max block size and if it doesn't then then Bitcoin can be formed again.

BIP 101: Doubles maximum block size every two years.

IMHO, its not a good idea. CMIIW.

There wasn't a need for 1Mb limit 4 years ago either, we could have done away with 256Kb or 512Kb just fine. In fact, up until recently the hard 1Mb cap wasn't effective at all as it never was approached. But smaller soft limits were all hit and raised. That's how Bitcoin survived.

As this time we are discussing rising the hard limit (via hard fork) we need to future proof it a little bit. In this light, 8Mb seems reasonable as a new hard limit for the next 4 years, in conjunction with smaller soft limits that miners can agree to maintain internally to prevent network spamming and abuse. They can, for example, agree to not build on top of anything larger than 4Mb initially, however full nodes will still accept and propagate blocks all the way up to 8Mb. This way the infrastructure will be ready for soft expansion in the future.

Whether to expand beyond 8Mb, when and how is questionable and depends on many factors. Maybe a series of hard-forks down the road will be a more appropriate and responsible solution than trying to predict the technology, but anything less than 8Mb for the upcoming years might start hurting Bitcoin and deflect its user base towards other solutions. We, as a community, definitely don't want that.

I know, maximum block size as 8 MB does not necessarily mean all blocks after that will be 8 MB. IMHO, its better for a gradual increase than a jump. However, I might support 8 MB but I am still opposed to BIP 101.

jonald_fyookball (OP)
Legendary
*
Offline Offline

Activity: 1302
Merit: 1008


Core dev leaves me neg feedback #abuse #political


View Profile
August 24, 2015, 02:12:04 PM
 #176

According to Gavin, storage space won't be the bottleneck in the future , but rather bandwidth.
"The (pruned) ledger only takes up 1 gig and will be further optimized."

Muhammed Zakir
Hero Member
*****
Offline Offline

Activity: 560
Merit: 509


I prefer Zakir over Muhammed when mentioning me!


View Profile WWW
August 24, 2015, 02:13:51 PM
 #177

According to Gavin, storage space won't be the bottleneck in the future , but rather bandwidth.
"The (pruned) ledger only takes up 1 gig and will be further optimized."

It is still a problem.

jonald_fyookball (OP)
Legendary
*
Offline Offline

Activity: 1302
Merit: 1008


Core dev leaves me neg feedback #abuse #political


View Profile
August 24, 2015, 02:23:55 PM
 #178

According to Gavin, storage space won't be the bottleneck in the future , but rather bandwidth.
"The (pruned) ledger only takes up 1 gig and will be further optimized."

It is still a problem.

What's a problem?  Storage space required to run a node? 

mavericklm
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500


View Profile
August 24, 2015, 02:25:44 PM
 #179

what? the miners don't have bills?

we don't fully use the 1mb and out of gavin(CIA)'s ass we jump to 8mb?

wtf!!!
hdbuck
Legendary
*
Offline Offline

Activity: 1260
Merit: 1002



View Profile
August 24, 2015, 02:26:30 PM
 #180

According to Gavin, storage space won't be the bottleneck in the future , but rather bandwidth.
"The (pruned) ledger only takes up 1 gig and will be further optimized."

It is still a problem.

What's a problem?  Storage space required to run a node?  



problem: when you dont qualify, you stfu..

The CEO of Intel suggested 'Moore's Law' is finally coming to an end
http://uk.businessinsider.com/intel-ceo-brian-krzanich-suggests-moores-law-is-over-2015-7?r=US&IR=T

Intel scientists find wall for Moore's Law
http://www.cnet.com/news/intel-scientists-find-wall-for-moores-law/


edit: bonus: The impending end of Moore's Law is not Intel's biggest problem: http://www.itworld.com/article/2949368/hardware/the-impending-end-of-moores-law-is-not-intels-biggest-problem.html
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 »  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!