1MB block size forever is just silly

[LoyceV]

Satoshi never thought bitcoin can be so huge on users and market cap, therefore he designed only for 1MB.

Before you make up stuff, please read what satoshi himself says about this:

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

We have 4 times more blocks by now, and it's still not implemented.

[franky1]

this is about the "spam" cries. and a way to solve it using CODE. not fee's


though there are spam attacks. we need to truly stop using a umbrella term, in regards to calling lots of different types of transactions "spam".
for me i consider BLOATED transactions that spend funds EVERY block an obvious spam attack.
yet others treat simply spending less than 0.1btc a spam attack.(facepalm)

in a world outside of america/europe. 0.01btc for instance can be a weeks wage and 0.001btc can be multiple hours of labour.
for the unbanked developing countries we should not be considering something spam, purely on the basis of how much is spent, but on bloated transactions and transactions that are spent too frequently outside what appears normal spending behaviour.


bitcoins 'priority' calculation are no longer appropriate, many pools dont even use it anymore.
the calculation of:
(value *age) / size. does not help anyone. because someone with 1000btc can respend multiple times an hour fee free. but someone with only 0.Xbtc has to wait weeks or pay a premium. victimising the poorer nations effectively
thus it only makes it a calculation beneficial for the rich.
the 'priority' calculation needs to change to be more about bloat and age. and not about value.


eg knowing that the blocksize limits how much data is allowed. a new calculation needs to have considerations of making there be a points system for blocksize vs tx size. more so then making the value the consideration changer
 so that the leaner the tx size is, the more points are rewarded. which when blocksizes increases. would make the leaner transactions earn more points for staying lean.

EG
(blocksize/tx size)*age

txsize      blocksize   age         result   
226         1000000   1            4425      10min
226         1000000   6            26549     1 hour
226         1000000   46          203540    7h 40min
450         1000000   1            2222      10min
450         1000000   6            13333     1 hour
450         1000000   90          200000    15h
100,000   1000000   1            10          10min
100,000   1000000   6            60          1 hour
100,000   1000000   144         1440      16h 40min
100,000   1000000   20160      201600   5months

imagining where the priority target was 200,000
this means if super lean you can spend funds every 7 hours with priority. but being bloated (100k blocks) you have to wait months.
this then makes bloated transactions PAY MORE to make up for the missing points.


it also means that rich spammer cannot bypass it by just moving a larger reserve for free.
ofcourse my example can include extra variables. such as if people voluntarily put in a CLTV maturity of X blocks to show they wont respend for atleast X blocks (because CLTV prevents it) they can gain extra points too

EG
((blocksize/tx size)*age)*CLTV confirms.
=((1000000/226)*6)*6      159292
=((1000000/226)*6)*7      185840
=((1000000/226)*6)*8      212389

which is an example of someone who naturally may want to spend every couple hours. where their funds are only an hour old.
226         1000000   6            26549     1 hour
dont have to wait >6 more hours
226         1000000   46          203540    7h 40min
they can just voluntarily tell the network they are happy to lock themselves into a 1hour 20minute maturity after the respend.
=((1000000/226)*6)*8      212389
to get priority.

meaning if you volunteer that you are not going to respend those funds for 8+ confirms. you get priority. which mitigates the respend every block true spam. because this calculation averages a 2-3 hour respend acceptable natural human timescale.

it also helps by giving users an option to say it needs to be accepted sooner.(a true "hey guys i really need this to go through, but accept the punishment for this need) making the wait PRIOR to confirm less, by making the waiting time AFTER confirm, more. thus a way to show the network who actually NEEDS priority the most

though a bloat spammer can just put a mega long CLTV on a bloated tx to gain priority for their first tx, they atleast once confirmed the funds wont be respent fast due to the CLTV maturity needing to be met
(no matter what the priority is of the second attempt, CLTV prevents respends until mature)

it makes it so that if you want to spend sooner (imagine its not maturity locked first) the sooner you want to spend the longer you have to wait to respend AFTER confirm. thus solving the wait for confirm 'trust' people getting paid dilemma
EG
if matured funds are only aged 3 blocks instead of 6. you have to volunteer not being able to re-spend then for 16 blocks instead of 8
=((1000000/226)*3)*14   185840
=((1000000/226)*3)*15   199115
=((1000000/226)*3)*16   212389

so that the faster you want to spend(after maturity) the longer you cant respend the second time. thus effectively stopping a spammer spending every block because they end up waiting atleast 2 hours before conditions are met


though my calculation is not perfect for every instance of utility. i think that usual / natural spending behaviour of only buying things once every couple hours is normal.. and mitigating the spend every 10 minute intentional spam.
for those wanting to bypass this because they GENUINELY need to spend every 10 minutes.. (not intention spam, but a niche need)
such as the small niche of day traders/faucet raiders/gamblers
they can use the niche market commercial LN service VOLUNTARILY to get their many spends an hour.

thus having an equal balance of people that only spend lets say once a week that dont need LN can happily spend onchain. but those that do need many spends an hour can use LN... natural balance is restored

im sure someone can be inspired by my idea of changing the priority calculation. by adding in or using variables in a different format to achieve something better then my example calculation formula.. and way way better than the current priority formulae

[kiklo]

have you even seen the recent spam attacks sizes?
there was time before when they did all 0.0001BTC with small fee attacks. right now they are doing random sizes with random amounts and high fees virtually undetectable by code. but they have been found.

So in other words, they are now sending the amounts and paying fees as high as everyone else.

BTC community is really pathetic , just increase the blocksize or increase the fees.
However increasing the fees makes the alts more attractive.
Sorry ass Dev Team, BTC has there, this problem has only been getting worse while they do nothing except trying to sell LN as a replacement.

 

[BTCLovingDude]

have you even seen the recent spam attacks sizes?
there was time before when they did all 0.0001BTC with small fee attacks. right now they are doing random sizes with random amounts and high fees virtually undetectable by code. but they have been found.

So in other words, they are now sending the amounts and paying fees as high as everyone else.

yes and even more fees as they plan on getting confirmation and then spend again so they need faster transactions so they include higher fees.

BTC community is really pathetic , just increase the blocksize or increase the fees.

it is not the community, it is a group of assholes probably getting paid to do it. and it is possibly because of block size debate.
i am more interested to know which side is responsible

However increasing the fees makes the alts more attractive.
Sorry ass Dev Team, BTC has there, this problem has only been getting worse while they do nothing except trying to sell LN as a replacement.

lol nice joke.

[kiklo]

@Franky1

In some versions of PoS, we use coin age.

It sounds like what you want to add to the BTC transaction priority calculations is Transaction Age.

Older a Transaction gets the higher its priority to be entered into a PoW Block.
That would help if they implemented it.

or

they could just go back to a first come first served transaction policy, and charge everyone a flat fee based on the amount.
(But That's not going to happen.)


 

[pedrog]

Bitcoin price continues to increase and that is what matters, the system is stable although not very reliable because one can never know when a transaction will be confirmed, if more transactions are important people can use some other coin like litecoin.

As far as investment goes, bitcoin is perfect as it is...

[spazzdla]

Bitcoin price continues to increase and that is what matters, the system is stable although not very reliable because one can never know when a transaction will be confirmed, if more transactions are important people can use some other coin like litecoin.

As far as investment goes, bitcoin is perfect as it is...

The security of the blockchain is king, without it the price will go to zero.

Which leads into the hesitation to change things it would seem. Logical but.. I stand by my title.. I offer no great solution just something like a linear increase in size so mores law dominates any linear increase but that isn't much of a suggestion.. All I know is 1MB in 2040 will just be overly silly.

[franky1]

The security of the blockchain is king, without it the price will go to zero.

Which leads into the hesitation to change things it would seem. Logical but.. I stand by my title.. I offer no great solution just something like a linear increase in size so mores law dominates any linear increase but that isn't much of a suggestion.. All I know is 1MB in 2040 will just be overly silly.

with a GOOD dynamic block code. the NODES.. emphasis NODES flag what they can cope with. and then when a confident majority of nodes can cope with more bytes. the pools would then ease themselves into it and weigh up the orphan risk as they test the water by making small steps BELOW the new acceptable limit ensuring little to no orphan risk for their attempts

[eternalgloom]

Sorry if this question has been answered before, I haven't read anything about it.

Do we actually have any idea who's behind these spam attacks and what their purpose is? Is it just to put pressure for bigger blocks?

[BillyBobZorton]

I don't really know where else to go from that..   1MB will seem like 1KB soon enough.  What do..

 

No one said that they want 1 MB forever except a very small amount of people. Everyone in Core devs except one dev wants to raise the blocksize after segwit gets activated. Activate segwit in order to safely raise the blocksize. No segwit? no blocksize increase, blame miners and not Core devs.

[franky1]

No one said that they want 1 MB forever except a very small amount of people. Everyone in Core devs except one dev wants to raise the blocksize after segwit gets activated. Activate segwit in order to safely raise the blocksize. No segwit? no blocksize increase, blame miners and not Core devs.

blame core..

pools wont move forward until there is good node validatability.
core decided to avoid getting nodes to update and show validatability.

core shot themselves in the foot thinking they could bypass security.

[isoneguy]

No one said that they want 1 MB forever except a very small amount of people. Everyone in Core devs except one dev wants to raise the blocksize after segwit gets activated. Activate segwit in order to safely raise the blocksize. No segwit? no blocksize increase, blame miners and not Core devs.

blame core..

pools wont move forward until there is good node validatability.
core decided to avoid getting nodes to update and show validatability.

core shot themselves in the foot thinking they could bypass security.

who wants to keep blocksize at 1mb? I was under the impression bitcoin was meant to scale.

Arguably segwit might not be the best implementation, but it is still a solution maybe...?

[spazzdla]

I don't really know where else to go from that..   1MB will seem like 1KB soon enough.  What do..

 

No one said that they want 1 MB forever except a very small amount of people. Everyone in Core devs except one dev wants to raise the blocksize after segwit gets activated. Activate segwit in order to safely raise the blocksize. No segwit? no blocksize increase, blame miners and not Core devs.

I am not blaming anyone.  I just would like to try to get a attempt to do something about it going.

I like something like an increase of 50% every year.. keep it under moores law not equal to.  I dunno..

THEMOS.. lead the charge!!!

[franky1]

THEMOS.. lead the charge!!!

this forums webmaster? (i think u misspelled) who begged for donations years ago to update this forum... but years later its the same thing.
if he cant update a webforum. dont desire him to supervise anything, no matter how close of a buddy he is to the blockstream crew

[pedrog]

Bitcoin price continues to increase and that is what matters, the system is stable although not very reliable because one can never know when a transaction will be confirmed, if more transactions are important people can use some other coin like litecoin.

As far as investment goes, bitcoin is perfect as it is...

The security of the blockchain is king, without it the price will go to zero.

Which leads into the hesitation to change things it would seem. Logical but.. I stand by my title.. I offer no great solution just something like a linear increase in size so mores law dominates any linear increase but that isn't much of a suggestion.. All I know is 1MB in 2040 will just be overly silly.

It is already overly silly, but price's up so everything is fine. 

[aarturka]

pools wont move forward until there is good node validatability.

How many pools want Unlimited? only 20 % including those, who earlier supports bitcoin xt and classic. Approximately 25% support segwit and the majority just wait to test segwit on lightcoin first

[pawel7777]

pools wont move forward until there is good node validatability.

How many pools want Unlimited? only 20 % including those, who earlier supports bitcoin xt and classic. Approximately 25% support segwit and the majority just wait to test segwit on lightcoin first

BU and Segwit go head to head, BU support briefly surpassed SW few days ago.
Supporting block increase =/= supporting BU

As far as I recall, Antpool's stance was that they will support SW but only after 2mb hardfork, not sure whether they still stick to it. I reckon F2pool could have similar stance, but I'm just guessing as I'm out of the loop with current affairs.

Can you provide any quote from any major pool confirming they wait with the decision after the Litecoin 'testing'?

...
It is already overly silly, but price's up so everything is fine. 

I love that logic:

BTC price drops: "Price means nothing! that's just speculation"
BTC price goes up: "See, that's a clear sign that Bitcoin is doing fine!"

[Carlton Banks]

who wants to keep blocksize at 1mb? I was under the impression bitcoin was meant to scale.

What makes you, or the OP, think that blocksize is the only way to scale up?



If the target is everyone (billions of people) using Bitcoin, using the blocksize to grow is not possible. Blocksize is not a scaling solution, it uses resources at the same scale whether it's 1 MB or 100 MB.

[DooMAD]

If the target is everyone (billions of people) using Bitcoin, using the blocksize to grow is not possible. Blocksize is not a scaling solution, it uses resources at the same scale whether it's 1 MB or 100 MB.

Blocksize is not a scaling solution on its own, but should still be part of the solution.  We need everything and the kitchen sink.  SegWit, Blocksize, Lightning, Atomic cross-chain transactions, sidechains/treechains, etc.  People generally understand that the blocksize is one of the more costly elements of the formula, but we still have to find a balance.  Scaling 100% off-chain runs in stark contrast to the underlying principles of an open and permissionless system.  Users won't stand for it and won't allow it to happen.

[franky1]

there goes CB yet again throwing down the

not verbatim: 'bitcoin mainnet should not scale onchain because billions of users by midnight.'
its much like saying in the 1900's cars should not be built because billion cars by midnight..

firstly. rational thought.
bitcoin wont have billions of users overnight. infact bitcoin wont have billions of users over decades.

a rational thing to think of is about 5% of the world adopting bitcoin naturally OVER DECADES
meaning it can scale.

if people think bitcoin is going to be the 'one world currency' and no other currency is going to exist then say goodbye to freedom of choice and say hello to bitcoin just becoming as corrupt as the IMF

instead think of it as just rationally taking a good healthy spot as one of the top 5 "nations"(communities)
think of it as being an open choice to have as a secondary currency to their own national currency.

then realise it wont happen overnight.