Topic: 1MB block size forever is just silly - page 4. (Read 4292 times)

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.

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?

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

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.

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...

@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.)


 

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.


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


lol nice joke.

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.

 

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

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

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

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.

They just wanted more profits so thats why they declined to the increase of 8 megabytes blockzise. Probably btc core has internal links with segwit, LN and offchain versions. I just dont understand why they wanted to make bitcoins more complicated, if it is possible to just increased the blocksize to  8 mb without resorting to other measures then its the best choice.

LTC fixed the spam issue in 2015.
There is nothing stopping BTC from using the same type of fix.

https://cointelegraph.com/news/litecoin-shows-there-is-a-simple-fix-for-spam-attacks-on-bitcoin



 

8MB will "work" until someone wants to enforce a change again and pays for the "stress test".

If BTC core released an update to an 8MB blocksize , all of the Chinese Miners would update, and the rest would have to follow or get left behind.

Unlimited is higher than 8MB, and some of the Chinese miners don't want to go higher than 8mb, because they are concerned the Chinese internet infrastructure can't handle more than 8mb.

8MB could last for a few years before needing to worry about it again.
(When your house is on fire, you don't order a sprinkler system, you get as much water as possible and put out the damn fire.)
(BTC house has been burning for a few months now.)

 

Your concern is good, Satoshi never thought bitcoin can be so huge on users and market cap, therefore he designed only for 1MB. 1MB is too small since nowadays there are more and more unconfirmed transactions, 2MB or bigger block is imminent to be updated, personally I support SegWit, hope it will be updated asap.

As I already wrote, I see this as the best solution. Those 3-4 miners fork into a new coin. The rest continues with the current Bitcoin system. Win-Win - everybody gets what he wants!

not all Chinese support unlim

The Chinese are ~68% of the miners dum dum.
Hard fork could happen tomorrow with no problems.

 

Only minority of miners agreed with blocksize increase. majority stick to segwit