Banks have bought the Core Team

[leopard2]

The idea of unlimited blocks is nonsense. Should 32MB blocks really be required, the blockchain will be so bloated that no one except professional datacenters can handle it.

Not very Satoshi-ish. 

That's nevertheless exactly Satoshi's original vision, with 1 GB blocks and only full nodes in data centers.

https://bitcointalk.org/index.php?topic=1876752.msg18659688#msg18659688

One second, he refers to miners in that post not nodes in general

Trouble is if you have only data centers (for mining OR for relaying) then you have  a situation where courts only have to send out a bunch of subpoenas to shut down Bitcoin,

It is exactly the reason why Bittorrent has been so successful, it takes a lot more work to shut down Bittorrent than a single ftp site hosting warez or moviez

I wish we could ask Satoshi what he thinks about centralization today.....

[1715003856]

1715003856

[1715003856]

1715003856

[1715003856]

1715003856

[franky1]

Core wants to increase from 1MB to 4MB and that is more than enough for the time being....

The idea of unlimited blocks is nonsense. Should 32MB blocks really be required, the blockchain will be so bloated that no one except professional datacenters can handle it.

Not very Satoshi-ish.  

your reading too many reddit doomsday scripts.

think of it this way. in 2009-2011 pools were making upto  0.25mb blocks even with the 1mb limit.
think of it this way. in 2011-2013 pools were making upto  0.5mb blocks even with the 1mb limit.
think of it this way. in 2013-2014 pools were making upto  0.75mb blocks even with the 1mb limit.
think of it this way. in 2014-2017 pools were making upto  0.99mb blocks even with the 1mb limit.

imagine the consensus.h 1mb limit was made as consensus.h 8mb or 32mb
then instead of pools setting the policy. in 25% increments below that as 2mb 4mb 6mb ... instead of the old 0.25mb 0.5mb 0.75mb

take a minute and think about that..

now.. imagine this.. that policy.h was not just pool decided.. but node decided..

NODES had a 'policy.h' where the NODES set their preference of what NODES can handle
and this was displayed in their useragent.

so now you know blocks will for now not get above 8mbor 32mb(consensus.h) but pools will only make blocks to say 75% majority vote of policy pr ference of nodes.
EG
say 5% stuck at 1mb
say 10% stuck at 1.5mb
say 10% stuck at 2mb
say 15% stuck at 4mb
say 30% stuck at 6mb
say 30% stuck at 7mb

a pool would see that 75% are ok with anything below 4mb.. and 25% are ok with anything below 2mb

so a pool makes blocks upto 2mb and that triggers a message to suggest users below the 25% change their policy.h because its getting low and pools are going to push that.

again all safely below 8mb upper limit. because the nodes are in more control of the policy.h..

welcome to dynamics.


now imagine say a node had a speed test that would help users define the upper and lower limits of consensus and policy so that pools NEVER EVER go beyond what nodes are capable of.

and all of this was user definable and controlable within the node at run time..
no more requirement of pleading to devs for more spoonfuls of capacity.

[jonald_fyookball]

The idea of unlimited blocks is nonsense. Should 32MB blocks really be required, the blockchain will be so bloated that no one except professional datacenters can handle it.

Not very Satoshi-ish. 

That's nevertheless exactly Satoshi's original vision, with 1 GB blocks and only full nodes in data centers.

https://bitcointalk.org/index.php?topic=1876752.msg18659688#msg18659688

One second, he refers to miners in that post not nodes in general

Trouble is if you have only data centers (for mining OR for relaying) then you have  a situation where courts only have to send out a bunch of subpoenas to shut down Bitcoin,

It is exactly the reason why Bittorrent has been so successful, it takes a lot more work to shut down Bittorrent than a single ftp site hosting warez or moviez

I wish we could ask Satoshi what he thinks about centralization today.....

It might not be an issue though.

By the time we get to such HUGE volumes where 'data centers' are neccessary,
Bitcoin will be so mainstream that it will impossible to stop and many small businesses can run a node.
Plus storage/bandwidth costs will keep decreasing.

Let's say we went to 32mb (full) blocks tomorrow. 
That's 32x6x24= 4.6 gigs of storage a day.  ...or 1.68 TB a year.   
That's still quite manageable for a hobbyist.

[leopard2]

franky you forget that these numbers happened with mining fees as they are

with BU mining fees could be close to zero and there is no limitation, just assumptions of the BU team that there will be "market balance"

In theory blocks could become gigantic, no matter what they say  

HEY, if they are so sure about "market balance" then why not put a hard limit in, maby 8MB? Then watch and see what happens?

[leopard2]

Let's say we went to 32mb (full) blocks tomorrow. 
That's 32x6x24= 4.6 gigs of storage a day.  ...or 1.68 TB a year.   
That's still quite manageable for a hobbyist.

What the Fyook?

No one will transfer 150Gigs per month over his home internet line, and buy 2TB hard disks every year just to run fucking hobby bitcoin node on his PC

It was YOU who pointed me to extension blocks so do you not support them yourself? Are you indeed a BU shill...?

[melbourne33]

I do not understand. Segwit makes blocks larger and more efficient.

No one is forced to use LN (right?). You can do more onchain transactions with Segwit than you can today.
 

Core's goal has to be stall onchain scaling as much as possible.  Segwit offers only a modest increase in transaction capacity while
actually making transactions more complicated and likely taking more capacity... and years later than most have wanted it.

By artificially restricting on chain capacity, Blockstream hopes to price ordinary users off the main chain and force them to use their
LN solution.

It is better to simply increase the blocksize but Core has done everything possible to stop that.

Yes that's right, the problem is simple, and the solution is even easier, Bitcoin needs only to make bigger blocks with original consensus
algorithm.

The pathetic thing is you come up with this without a shred of evidence. Just prejudice.

Obviously BU has been bought by banks. See how easy it is? Anyone can say anything, but without evidence the claim is garbage.

Core is controlled by Blockstream which is funded by AXA, which is tied to Bilderberg.  

Even if you don't believe the conspiracy, it should be clear Blockstream seeks to profit from Bitcoin at the expense of the users.  This is why they are blocking on chain scaling.  

Bitcoin started to show clear signs of corporate banking contamination (bureaucracies) for a simple technical update.

Why people should believe an organization like Blockstream will have the "best" intentions for Bitcoin if Bitcoin as a decentralized product
represents a direct treath to the people behind the curtain of this organization?

Asicboost on the other hand, would hand over BTC to just one Chinese entity on the planet...much worse.

Chinese have over ~68% control of the ASICS, asic boost working or nonworking will not decrease that % at all.

Yes and even if that may happen, nothing stops another entity to build more asics and compete into the market.

What no one has said about Core Team is they are attacking other solutions as being centralized but the ones becoming centralized are
themselves, a straight centralized financial group is behind them for not saying a "company", Blockstream, they are no longer a Fundation.
They attack people wanting to follow original consensus algorithm but they want to implement new consensus that were not even wrote
in Bitcoin whitepaper, they want to radically modify how Bitcoin works, 'no one can modify Bitcoin but us' isn't that position
the most clear sign of centralization?.
Also, why centralize the power in just one region? it is healthy for the network to have "consensus" leaders all around the world, in North America,
Europe, Asia, among other regions. With hashrate anyone in the world can become part of it.


And.. for the record, Satoshi Nakamoto didn't dissapear for no reason, he dissapeared when other Core members started meetings with the
CIA at 2011, some of them decided to make some distance from Bitcoin when they got called from CIA but for Satoshi this was the trigger
to completely dissapear as any other post/message from him could bring new clues to people behind him.
Finally.. Whom current Core members repond to at this stage?

[jonald_fyookball]

Let's say we went to 32mb (full) blocks tomorrow.  
That's 32x6x24= 4.6 gigs of storage a day.  ...or 1.68 TB a year.  
That's still quite manageable for a hobbyist.

What the Fyook?

No one will transfer 150Gigs per month over his home internet line, and buy 2TB hard disks every year just to run fucking hobby bitcoin node on his PC

If they are mining, why wouldn't they?  People spend plenty of money on muscle cars, guns, guitars, and other hobbies.  If they are not mining, they only need the block headers.
Point is, enough people will do it so it is censorship resistant.  Not everyone needs to run a full node on their iphone.

It was YOU who pointed me to extension blocks so do you not support them yourself? Are you indeed a BU shill...?

I support many scaling proposals.  Extension blocks are fine ... they are still on chain scaling so that doesn't change the fact that a large capacity will require more storage.

[franky1]

franky you forget that these numbers happened with mining fees as they are

with BU mining fees could be close to zero and there is no limitation, just assumptions of the BU team that there will be "market balance"

In theory blocks could become gigantic, no matter what they say  

HEY, if they are so sure about "market balance" then why not put a hard limit in, maby 8MB? Then watch and see what happens?

mining tx fee's are not an issue today. and not gonna be an issue for decades.
pools do not care about the fee's  today. and not gonna be an issue for decades.

its core that have done the code changes to let the fees become absurd. not pools.

lastly.
yea jumping to say 8mb blocks over night may only get filled with maybe 3-4mb of tx data today where this could crash the tx fee's down to near zero cost to transact. good for users and not a problem for pools

but obviously pools wont go full wetard up to 8mb over night or 32mb overnight either. they would just like a bit of space to get rid of any mempool backlog.

hence the whole policy.h preferences that allow blocks to be more dynamic.

what results is that and equilibrium is found where by if a pool got to 1.5mb -2mb and started to see that the demand for capacity brings the fee prices right down, and a healthy level will be found.. symbiotically.

even a new priority fee mechanism could be brought in which rewards lean users that dont spend every block and penalises users that make bloated tx every block

here is one example - not perfect. but think about it
imagine that we decided its acceptable that people should have a way to get priority if they have a lean tx and signal that they only want to spend funds once a day. (reasonable expectation)
where if they want to spend more often costs rise, if they want bloated tx, costs rise..

which then allows those that just pay their rent once a month or buys groceries every couple days to be ok using onchain bitcoin.. and where the costs of trying to spam the network (every block) becomes expensive where by they would be better off using LN. (for things like faucet raiding/day trading every 1-10 minutes)

so lets think about a priority fee thats not about rich vs poor(like the old one was) but about reducing respend spam and bloat.

lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.(thats what CLTV does)

and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae with was more about the value of the tx


as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain ($0.01).
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more ($0.44)
if you want to be a spammer spending every block. you pay the price($1.44)
and if you want to be a total ass-hat and be both bloated and respending EVERY BLOCK you pay the ultimate price($63.72)

note this is not perfect. but think about it

[andron8383]

***
Segwit plans to launch an off-chain network AKA fractional reserve system.

A lighting network AKA paypal scheme.

A high fees for on chain txs AKA bank wires fees.
***

Bla bla ...
If BTC won't get LN then anyway ETH will have it and will benefit from it.
Do you people think that everything can be kept on main chain ?
I don't insist to keep 1MB forever but common rewards will be payed till 2140,
Segwit doesn't cost anything if not work you turn if off and move to another solution.
From hard fork you won't go back.


If miners are so annoyed by Core they should tax themselves to hire best devs in universe but those people won't work for free.
Why people think that best developers will work for free to pride their coin - you are really believe in that ?

If you use free soft them don't blame core hire better devs and prove that they are better not like BU devs that their client crashed few times in row.

Increasing blocksize is easier and most non effective approach to make changes.
1st is better to optimize that space what is segwit doing then start to increasing it.

[franky1]

If you use free soft them don't blame core hire better devs and prove that they are better not like BU devs that their client crashed few times in row.

what you dont realise is that the crash. was due to BU using cores 0.12. where there was a bug in cores 0.12 that was not patched until core 0.13

so while BU were fixing the bugs . someone at core realised that some of the BU nodes were running the unfixed 0.12 and as such had the bug.. thus called out to attack them.

however BU already patched the 0.12 so all people had to do was download the latest BU.
not wait 3-6 months.. just download the patched BU the same day the core team publicised how to attack OLD bu version that had OLDER core bugs.

P.S.. if core was independent then they would help other implementations. but by devs being dependant to core shows they are not independent..

[Pab]

How much banks did pay,before War2 somebody sold Eifla Tower in Paris

[dinofelis]

One second, he refers to miners in that post not nodes in general

Read this line in that post:

Only people trying to create new coins would need to run
network nodes.

[The One]

I do not understand. Segwit makes blocks larger and more efficient.

No one is forced to use LN (right?). You can do more onchain transactions with Segwit than you can today.
 

Core's goal has to be stall onchain scaling as much as possible.  Segwit offers only a modest increase in transaction capacity while
actually making transactions more complicated and likely taking more capacity... and years later than most have wanted it.

By artificially restricting on chain capacity, Blockstream hopes to price ordinary users off the main chain and force them to use their
LN solution.

It is better to simply increase the blocksize but Core has done everything possible to stop that.

Core wants to increase from 1MB to 4MB and that is more than enough for the time being....

The idea of unlimited blocks is nonsense. Should 32MB blocks really be required, the blockchain will be so bloated that no one except professional datacenters can handle it.

Not very Satoshi-ish. 

Eh???

[The One]

BTW the non-rollback-ability / non backwards compatibility is what pisses me off about Segwit but it is the lesser evil between Segwit and BU

sure extension blocks might work but they have as much support as Ron Paul 

There are other big block solutions available that don't use Bitcoin Unneeded levels of complexity with its acceptance depth mechanism.
It could be argued Emergent Consensus has been proved to work in an informal manner. Miners upped the block sizes they mined in a consensus move until they hit the 1MB limit. All it requires is for the block limit to be removed and miners to advertise the block size they are willing to accept, and then miners will produce bigger blocks when there is a consensus minimum acceptance size advertised. It is just formalising what used to happen before the 1MB limit was hit.

Bitcoin is suppose to be decentralised. Giving Miners the to power to choose blocksize is centralisation. Any centralisation must be done outside Bitcoin - developers etc - thus any proposal is then decided by all the users. (or % of users).

[jonald_fyookball]

  Giving Miners the to power to choose blocksize is centralisation.

This is your opinion.   Miners are the ones choosing and ordering transactions, and blocksize is clearly in that realm.

I can easily make the argument that giving developers this power is far more centralizing.

[The One]

  Giving Miners the to power to choose blocksize is centralisation.

This is your opinion.   Miners are the ones choosing and ordering transactions, and blocksize is clearly in that realm.

I can easily make the argument that giving developers this power is far more centralizing.

Nope. Fact.

Shouldn't be happening.

[franky1]

 Giving Miners the to power to choose blocksize is centralisation.

This is your opinion.   Miners are the ones choosing and ordering transactions, and blocksize is clearly in that realm.

I can easily make the argument that giving developers this power is far more centralizing.

Nope. Fact.

Shouldn't be happening.

pools can put transactions in, in any order they please.

you would never know the order.
it could be first seen first entered.
it could be more mature (older first)
it could be highest fee first.

all that really matters is if they have time to add tx's (ovr 1min since last block solved) then there should be tx's in a block

[jonald_fyookball]

  Giving Miners the to power to choose blocksize is centralisation.

This is your opinion.   Miners are the ones choosing and ordering transactions, and blocksize is clearly in that realm.

I can easily make the argument that giving developers this power is far more centralizing.

Nope. Fact.

Shouldn't be happening.

Okkkaaaayyyy.... care to explain why it "shouldn't be"?  Because that's how its worked since day 1.

[The One]

 Giving Miners the to power to choose blocksize is centralisation.

This is your opinion.   Miners are the ones choosing and ordering transactions, and blocksize is clearly in that realm.

I can easily make the argument that giving developers this power is far more centralizing.

Nope. Fact.

Shouldn't be happening.

pools can put transactions in, in any order they please.

you would never know the order.
it could be first seen first entered.
it could be more mature (older first)
it could be highest fee first.

all that really matters is if they have time to add tx's (ovr 1min since last block solved) then there should be tx's in a block

Should be.

[jonald_fyookball]

I'm not sure you understand that proof of work is a timestamping mechanism.