hypothesis: BU motivations (NO PROOF)

[franky1]

That does not compute. I have just read that the 1MB maxblocksize was added as an anti spam measure. We all know that the flooding of the mempool is because some group is spamming the network, so if we hard fork to an 32MB maxblocksize and some other group is not happy and decide to spam the network that will lead to more blockchain bloat.

someone making 1mb of spam today will make 1mb of spam filling the baseblock after segwit activation with native keys.
so that no segwit tx's can fit txdata in the baseblock, thus not hang their sigs outside the baseblock.. thus not even use any of the 3mb extra weight but still have the 'blocks are full' issue.


someone making 1mb of spam today will make 1mb of segwit txdata spam filling the baseblock after segwit activation using segwit tx's. so that it has 2mb of txdata+sig spam and still no moral / normal user transactions able to get in

inshort: segwit does not stop spam because segwit is reliant on the baseblock.

[Wind_FURY]

That does not compute. I have just read that the 1MB maxblocksize was added as an anti spam measure. We all know that the flooding of the mempool is because some group is spamming the network, so if we hard fork to an 32MB maxblocksize and some other group is not happy and decide to spam the network that will lead to more blockchain bloat.

someone making 1mb of spam today will make 1mb of spam filling the baseblock after segwit activation with native keys.
so that no segwit tx's can fit txdata in the baseblock, thus not hang their sigs outside the baseblock.. thus not even use any of the 3mb extra weight but still have the 'blocks are full' issue.


someone making 1mb of spam today will make 1mb of segwit txdata spam filling the baseblock after segwit activation using segwit tx's. so that it has 2mb of txdata+sig spam and still no moral / normal user transactions able to get in

inshort: segwit does not stop spam because segwit is reliant on the baseblock.

Yes I agree the spamming will not stop as long as there are certain groups who are unhappy with the way things are now. I am sure there will be another group who will be unhappy if we hard fork to bigger blocks and have a new set of developers who may not be popular.

If that is a possible scenario then I ask this question from jonald_fyookball's ball comment.

At this point, I'd be happy as a peach if everyone just got behind a hardfork to 32mb or 8mb.

Will that lead to more blockchain bloat or not? There is also the mining centralization issue that comes with bigger blocks.

[jonald_fyookball]

That does not compute. I have just read that the 1MB maxblocksize was added as an anti spam measure. We all know that the flooding of the mempool is because some group is spamming the network, so if we hard fork to an 32MB maxblocksize and some other group is not happy and decide to spam the network that will lead to more blockchain bloat.

It would become pretty expensive to bloat a blockchain that had 32mb blocks.  Let's say a transaction is 0.5 kb, that's 2048 x 32 = 65,536 transactions per block.   At a nickel a transaction, that would be $3276.80.  That's just for one block.  That's $19,660.80 an hour, and $471,859.20 a day.  

[Wind_FURY]

That does not compute. I have just read that the 1MB maxblocksize was added as an anti spam measure. We all know that the flooding of the mempool is because some group is spamming the network, so if we hard fork to an 32MB maxblocksize and some other group is not happy and decide to spam the network that will lead to more blockchain bloat.

It would become pretty expensive to bloat a blockchain that had 32mb blocks.  Let's say a transaction is 0.5 kb, that's 2048 x 32 = 65,536 transactions per block.   At a nickel a transaction, that would be $3276.80.  That's just for one block.  That's $19,660.80 an hour, and $471,859.20 a day.  

But it is still hypothetically possible. Why not maintain the small maxblocksize as an anti spam measure and create an offchain transaction layer built on top that anyone is free to use.

I want to ask you, if Blockstream was not involved in any of this, are you open to a smaller maxblocksize and an offchain transaction layer for Bitcoin? Honestly.

[franky1]

Will that lead to more blockchain bloat or not? There is also the mining centralization issue that comes with bigger blocks.

miner centralisation?? nope

you do know that an ASIC has no hard drive.
ASICS do not store the blockchain and do not care about the data of a block or how big a block is.

an asic is just handed a hash and told how many0000 at the start of the solution is needed for a solved hash

1byte of data
65c74c15a686187bb6bbf9958f494fc6b80068034a659a9ad44991b08c58f2d2

or 1000byte
e6631d63c97fb6d9239bd7d1d0a8878e3ea383722635051f94efc5b2790fc441

or a gigabyte
442aaa99d16cf451b853451fbb0515ed696985f236924adf682b34e9531472b1

the hash a asic is given is the same length

the POOL/nodes however that do validate tx data need to ensure they do it in a timely manner.

for instance v0.12 had a txsigop limit of 4000ops.. and a blocksigop limit of 20,000ops
a malicious person can make 5 transactions of 4000ops to use up the blocks limits.

lets say it takes 0.01sec to process 4000ops
that becomes 0.05sec to do the whole block.

now imagine. instead of having
1mb block with 4,000txsopl and 20,000bsopl
we had
2mb block with 8,000txsopl and 40,000bsopl
using native keys quadratics would take 1min 40 seconds for the 5 tx's

where as if we had
2mb block with 4000txsopl and 40,000bsopl
using native keys even with quadratics would take 0.10 seconds for 10tx's
thus alleviating the quadratics scare because your not allowing a single transaction to multiply up the sigops. but allowing more transactions per block.

the real silly thing is,
core have actually put in
1mb base 4mb weight block with 16,000txsopl and 80,000bsopl
which is incredibly stupid and allows native key sigop spammers to do alot within the baseblock

if basing the block sigop limit on the weight. they should be doing
1mb base 4mb weight block with 4,000txsopl and 80,000bsopl
which would allow 20 bloated maxed out tx's instead of 5. but the timing would only be 0.2sec...
not hours and only five maxed out spam tx's that core 0.14+ allows

but now im just ranting.

[jonald_fyookball]

That does not compute. I have just read that the 1MB maxblocksize was added as an anti spam measure. We all know that the flooding of the mempool is because some group is spamming the network, so if we hard fork to an 32MB maxblocksize and some other group is not happy and decide to spam the network that will lead to more blockchain bloat.

It would become pretty expensive to bloat a blockchain that had 32mb blocks.  Let's say a transaction is 0.5 kb, that's 2048 x 32 = 65,536 transactions per block.   At a nickel a transaction, that would be $3276.80.  That's just for one block.  That's $19,660.80 an hour, and $471,859.20 a day.  

But it is still hypothetically possible. Why not maintain the small maxblocksize as an anti spam measure

Because the context is completely different and we are talking about
2 completely different kinds of 'anti-spam measures'.  

When Satoshi put in the 1mb limit, the avergae block was 1kb,
or 1000 times smaller than the limit, and fees were 0.  
Thus, the spam filter was not operating by making it
expensive for spammers.  Instead, it simply limited
bloat.  

Today, it is more effective to make it economically
expensive, and the way to do that is with bigger
blocks, not smaller ones.

The 'hypothetically possible' that you mention
is a) 'hypothetically possible' at any scale
given enough money and b) 32x cheaper
at 1mb than 32mb.

and create an offchain transaction layer built on top that anyone is free to use.

I'm not against offchain networks per se.  I think its a very cool idea.

I want to ask you, if Blockstream was not involved in any of this, are you open to a smaller maxblocksize and an offchain transaction layer for Bitcoin? Honestly.

If there is to be a maximum blocksize, it should be for a very good reason,
and unless someone convinces me otherwise, it should always be well
beyond that of market demand.   So, if there was no blockstream
but core devs refused to raise it (lets say because of their economic
beliefs) i'd be screaming just as loudly.  It just so happens that
their involvement with blockstream provides a logical explanation
for why they wouldn't take sensible steps to allow growth.

[franky1]

But it is still hypothetically possible. Why not maintain the small maxblocksize as an anti spam measure and create an offchain transaction layer built on top that anyone is free to use.

I want to ask you, if Blockstream was not involved in any of this, are you open to a smaller maxblocksize and an offchain transaction layer for Bitcoin? Honestly.

there is no reason not to use LN.. emphasis as a VOLUNTARY side service for those that need it.
but LN does have some limitations and issues which make it useful for only a niche of people. not everyone.

also the 1mb base still limits how many channels can be active. and needing more base block size will be needed to cover the more channels being open while also allowing people to replenish funds of channels to spend more. (which does require onchain space to restart new channels or add fresh funds to a channel)

some have done the maths.
to have enough channels open to cover say 7billion people with a 1year lock requires 133-200mb blocks
for a more reasonable 2week lock. that would be 5.2gb blocks. so thinking w can survive on 1mb blocks and (i laugh) 'be like visa' is impossible

[ImHash]

Banks/SWIFT have nothing to do with the use case of ASIC machines and they process their transactions entirely in a different way. BU will not fork bitcoin because then no exchanging company/merchants will recognize their generated coins as bitcoin and their coin's price will drop below $200 in matter of one week and drop to zero after a month.
If segwit activated and spammers still able to spam with old keys then every one should switch to segwit and then everyone could ban/ignore those spams and a spammer needs to have hash power in order to mine blocks filled with spam transactions, a miner if stays honest and friendly to the network could profit more.
Miners also need to find the successful and honest pools to point their hash power only towards them and nodes must ban/ignore/blacklist those nodes which are broadcasting spam attacks.

Anyways right now the whole system are following and enforcing Core rules unless running BU right now could give people advantage over Core miners I see no reason to run other versions such as BU/classic/XBTC/8MB.

[Kakmakr]

Why would they go through all the trouble to buy hash power, if they can bribe a couple of government employees to change policies and get Bitcoin banned or regulated? They can even bribe them to stop 3rd party initiatives like the ETF for that matter.

Just look at how effective they were to slow down Bitcoin in New York with the BitLicense. ^grrrrrrrr^

If you have the government in your pocket, you do not need the miners and you do not need Bitcoin. They have not done this aggressively yet, because they know this will turn into a shit show if they do, so they are doing this slowly by doing small things. < Deny ETF / Strict regulations on exchanges / BitLicense >

[franky1]

If segwit activated and spammers still able to spam with old keys then every one should switch to segwit and then everyone could ban/ignore those spams

getting everyone 46million output to move to segwit keys. would in itself cause a mass 'spam event'
....think about it.

secondly then rejecting old transactions is just killing off the hoarders that are not actively spending.
thats like nuking someones old safety deposit box purely in the hopes it will reduce the queue at the banks cashier desk because savers who hardly ever/ dont move funds are then lost.

wake up
far far far easier to not give spammers too many opportunities.. rather than open new attack vectors and then build walls affecting innocent people.

EG
core v0.12
a spammer could fill a block with just 5 bloated tx's of 4000tx sigops. (20k block sigops)
core v0.14
a spammer could fill a block with just 5 bloated tx's of 16000tx sigops.(80k block sigops) meaning...
..yep core 0.14 makes a block have alot longer native quadratic validation time attack.

however. instead of locking out old UTXO's completely as a fix ImHash said..

keep the 4000tx sigops but grow the (80k block sigops) meaning now requires 20 bloated tx's to fill a block instead of 5 and the time is better and manageable,

yep
20 x 4000=80000 is better by many factors of multiplication, rather than
5 x 16000=80000

[Jerean]

Conspiracy theory. BU existence because core is failed to scale the blocksize.

[Bergmann_Christoph]

I would like to share an hypothesis.

With enough asics a group of miners could offer/sell an alternative to SWIFT for banks?

The group could settle a secret agreement with some banks to raise a few billion US$ for their hash capacity (they would have to leave bitcoin).

That's a nice business idea for mining facilities like BitMain. But why do you think they need to destroy Bitcoin for that? They could just create new asics with new algorithm for the bank coin in parallel. Would be the far easier and more profitable.

And why do you need to spin such theories to explain the simple fact that miners want more onchain scaling?

[Wind_FURY]

jonald_fyookball, franky1, you have gone too technical and lost me. My pea brain can only handle enough information at a time. I will need to step back and reread your posts later.

I request for someone with more technical knowledge for a rebuttal while I try to read their posts. I am learning as I go.

[jonald_fyookball]

jonald_fyookball, franky1, you have gone too technical and lost me. My pea brain can only handle enough information at a time. I will need to step back and reread your posts later.

I request for someone with more technical knowledge for a rebuttal while I try to read their posts. I am learning as I go.

try to look at from a simple supply and demand persective.

Supply = blocksize space
demand = transaction

by making the supply smaller, prices (fees) will go up.   

So if someone wants to manipulate the market (spam attack) and make prices go up, obviously its going to easier with a smaller market (smaller blocksize, smaller supply)
than with a bigger one..

I hope that isn't too technical.

[franky1]

jonald_fyookball, franky1, you have gone too technical and lost me. My pea brain can only handle enough information at a time. I will need to step back and reread your posts later.

I request for someone with more technical knowledge for a rebuttal while I try to read their posts. I am learning as I go.

usually i try to keep things laymens.
non technical version

imagine it like a plane that originally only allows 2500 seats. and people are waiting at the airport to buy their seat

issues.
1 guy can buy a party ticket to buy up all the seats for only 5 obese people to sit in..
leaving 2495 passengers angry and frustrated

solutions

a. allow plans to grow in seating capacity, but limit the party ticket. EG a 5,000 seat plane has a party ticket to allow 20people to reserve the whole plane instead of 5 (or go one step further make it so party ticket people need 40+ to fill the plane instead of 5)
b. make the cargo-hold area into new seating and offer a discount for adults if the let their kids sit in the cargo hold
c. invent a teleporter on teleport island to avoid passengers needing the plane each month. but once a month they need to travel by plane to or from teleport island just to be able to use the teleporter inbetween times.

a=dynamics
b=segwit
c=LN

issues
b. though there are 2500seats that could possibly allow more first class empty seats for more people because some adults volunteer to put their kids into cargo freeing up the main seats. the plane operator has done nothing to stop the party ticket guy from buying up all the seats for only 5 people

c. although some people may love teleport island. some people may only need the plane once a month so why buy a return ticket via teleport island to get to destination. rather than just a single ticket to destination. also plane operator hasnt stopped the partyticket reserving the plane for just 5 people.

thats the situation we are at...


now to your question
1. are you open to a smaller maxblocksize and an offchain transaction layer for Bitcoin? Honestly.
answer: LN (teleport island) does have a niche for gamblers that want to get to Lasvegas many times a day instantly in their coffee break. but LN is not for everyone. and forcing people into LN/teleport island especially without fixing bloat/partyticket, isnt solving the issue of queues at the airport.
answer: also if it starts costing too much just to get to teleport island by plane. people will hate travlling distances and never use the airport to even then use the teleport island.(AKA never use bitcoin to never use LN)

2. planes with (ur 32mb scenario) 80000 seats too big to be reliable around the sky and can crash with all the weight.
answer: no one is building plane to be that big overnight. it would be natural growth over time that move when safety allowances are met. nodes wont flag preference for such big planes unless they could cope. (think slow progressive growth over time. not 32mb by midnight)
answer: if the plane allowed a party ticket of 5 extremely obese guys fill the plane then the unbalance weight could cause more damage. so restrictions of bloat to allow say only parties of 2 onboard (40,000 tickets) is safer and manageable. rather than 5 tickets of insane obesity.

[Hydrogen]

I would like to share an hypothesis.

With enough asics a group of miners could offer/sell an alternative to SWIFT for banks?

The group could settle a secret agreement with some banks to raise a few billion US$ for their hash capacity (they would have to leave bitcoin).
They would need something like 40% to 50% of bitcoin hash rate to avoid attacks (Bitcoin unlimited is in almost 40%?).
They would have to keep building asics to keep hash capacity in bitcoin level. Or build even more.
Them we would live in a world with 2 major coins. Both only vulnerable to each other hash capacity.
The miner (banks backed) would have lot of budget to keep pumping asics until bitcoin is forced to change POW or other mitigation strategy.
The group would guarantee its future in asics manufacturing and operations and would ´t care if bitcoin fails. Quick $ with low risk. As it would have a signed contract with major banks to back them.
Actually this group of miners would gain with bitcoin suffering.
Banks could have a chance to have its own SWIFT and damage bitcoin considerably, gaining more time for their fiat party, with very low costs for them(comparing to acquisitions we are seeing today and the SWIFT value)

Interesting theory OP.

I wonder if this could be evidence of banks/states supporting bu.

http://www.investopedia.com/terms/h/hard-fork.asp

There could be some agenda in play where people with money and influence are spreading pro bitcoin unlimited propaganda.

If there is a hard fork, will decreasing the number of miners and nodes also lead to slower transactions?

The concept of a hard fork could be flawed if such is the case.

[Wind_FURY]

jonald_fyookball, franky1, you have gone too technical and lost me. My pea brain can only handle enough information at a time. I will need to step back and reread your posts later.

I request for someone with more technical knowledge for a rebuttal while I try to read their posts. I am learning as I go.

try to look at from a simple supply and demand persective.

Supply = blocksize space
demand = transaction

by making the supply smaller, prices (fees) will go up.  

So if someone wants to manipulate the market (spam attack) and make prices go up, obviously its going to easier with a smaller market (smaller blocksize, smaller supply)
than with a bigger one..

I hope that isn't too technical.

Thank you.

But if we have a layer on top of the blockchain for offchain transactions, we would be given an option as an out to avoid doing the transaction on the blockchain and do it off the chain. That is a shallow reason but still very useful.

Do you think spamming the blockchain will be discouraged by having bigger blocks?

Franky1, I will reply to your post later if I can find the brain cells.

[jonald_fyookball]

of course , because it will be more expensive as we discussed earlier.

[Wind_FURY]

of course , because it will be more expensive as we discussed earlier.

Right. Let me divert the topic a little. Who do you think is spamming the network and for whose best interest is he acting? All we see are cries of "Oh someone is spamming and flooding the mempool" but there is no mention of who or what group is doing this.

In theory it could be someone who has a commitment to Bitcoin Unlimited but I do not want to go there and be biased. That is why I am asking you.

[LesPristy]

The thing is, anyone with 51% of the hashpower can attack the network and kill it -- they don't BU or anything else, or anyone's consensus or permission.

BTC could be taken down with zero hashpower.