knowing blockstream have $90mill and only a couple dozen paid devs, and over 100 unpaid interns we can assume gmaxwell is atleast a millionaire in the fiat world

ok imagine this is a ~450bye tx
*********************************************

input
signature
output

each star represents 10bytes for easy display

if you done the same tx but using segwit p2wpkh keys, the transaction looks like this
*********************************************

one thing that will blow your mind. the blue and red stars(bytes) are still transmitted physically. but at code interpretation level they are not 'counted' as going towards what goes into the base block.

but because at code level an opcode is used to flag old nodes to ignore data after purple. making it look like an anyonecanspend

the other stars (blue, red) are only looked at by new nodes.
  old nodes see:*********************************************  grey is ignored
new nodes see:*********************************************

while unconfirmed
old nodes wont morally relay or add a segwit tx and instead drop it. however a malicious actor can tweak their code to relay/force it into a oldblock. (hence why wpkh wallet key generation is not released pre activation to avoid malicious attacks)

after feature activation,
because only purple stars are counted (yet more stars are actually transmitted). this trick can allow more transactions into the base block
because they have room for 100,000stars (1mb)

so where say 2222tx's was 100k(1mb) stars. if everyone used segwit keys. becomes ~50k stars(~50%), giving ~50k(~50%) spare room in the block for more transactions
but remember the blue and red is still real data but just not 'counted' by the baseblock

this allows ~5000tx's(depending on ins and out and how many people use segwit keys) into the baseblock but the reality is the actual data transmitted is 2mb even with the baseblock still limited to 1mb

P.S whats said above should be interpretted by the concept. i used rough numbers for demo purposes. dont get knitpicky about the numbers. just learn then concept of HOW the switch around is used and HOW things are 'counted' or 'ignored' by nodes.. and HOW it differs to actual data transmitted

then look at the extra bytes added later when extra features are added.. and have a nice day

you dont understand it

segwit takes out bytes from tx data (the signature is moved), this is a temporary one time 'gesture' and only increases tx count if people move funds and use segwit keys.

but later more bytes are added to tx data.

have you even looked at how many extra bytes are needed for:
CLTV
CSV
Confidential commitments

go find that out.

ill give you a hint confidential commitments are said to be (by blockstream devs themselves) around a kilobyte.
yep they want to bloat an average tx of 450bytes to be near 1.5kb for the same 2input 2output tx

like i said.
segwit temporarily makes an average 450tx 'look like' ~230bytes being counted in the base block with the rest in the 'witness area'(still totalling 450byte TRANSMITTED)

but then LN has their features. which increase the base block txdata ABOVE ~230 (thus reducing possible tx's in the base block again)

and other blockstream features add on, will add about a kilobyte.. (once confidential payments and other features is added)

go research

lol
actually its the blockstream crew that want to increase the units of measure.. as part of their LN strategy of millisatoshi's.
look beyond what has been spoonfed to you and research

but back to the blocksize..
blockstream want to halt tx counts. at 1mb.. but bloat the DATA TRANSMITTED beyond 1mb.
they as a fake gesture suggest their new 'weight' buzzword as part of segwit allows 2.1x transactions. but as fast as people switch to segwit keypairs blockstream are bloating up transactions with CLTV bytes of data and CSV bytes of data and confidential commitment kilobytes of data.

so a one time hope of 2500tx/block->4500tx/block.. soon goes back down to 2500tx/block once they add the features.. but the DATA TRANSMITTED goes up to 4mb/block

EG 2500tx:1mb      to    4500tx:2.1mb   <-blockstream (2017)
EG 4500tx:2.1mb   to    2500tx:4mb   <-blockstream (2019)

EG 2500tx:1mb    to      5000tx:2mb   <-community desire (2017)
EG 5000tx:2mb    to     10000tx:4mb   <-community desire (2019)

think rationally..
natural scaled and copable growth has been halted using fears of "gigabyte blocks by midnight" fake scare doomsday propaganda.

the simple fact is. if a node cant cope with a larger size they wont set their dynamic setting above what they can cope with. and if the majority of nodes cant cope it wont change. and pools that try to force it will just get their attempt orphaned.

learn consensus, it will help you.

even core have publicly said 8mb is safe but they prefer 4mb.. to be ultra safe.. so no actual reason to hold the base block at 1mb

getting to 2mb or 4mb or 8mb is not going to be an overnight thing. its going to be a risk averting curve that naturally progresses over time.

stop reading the fake doomsdays of 1gb blocks by midnight. as an excuse to stop rational smaller growth over natural and rational time.

they are scaring you with wild numbers, because they dont want you knowing that rational and natural numbers can work. they want to halt natural and rational growth to force you into commercialised LN Hubs so they can repay their $90m debt from investors.
they care less about bitcoin and only care about their investment contract,

just look beyond the doomsday rhetoric told to you by the guys devoted to blockstream and look for the truth behind their propaganda
.. but i guess like all the other blockstream sheep. you wont research it. you will just "trust" them on face value.

here is the blockstream rhetoric simplified.
"dont think about the blue line or choose the blue line because we want to scare you with a fake red line to push people into a new network that has commercialised hubs"

you have cabin fever. your reading prepared scripts from a group of people that want centralisation and commercial services to own bitcoin.

not quite.

when the consensus is reached to go to say 2mb block buffer (acceptable limit of nodes)
pools will then say the maximum they will ever make is 2mb.. but
here is the kicker
pools will dip thir toe in the water by making a block that is just a tad bit more than 1mb. say 1.001mb just to see the orphan risks and also to see if any bugs pop up.. such as the 500kb bug Sipa introduced in 2013..

if the orphan rate is not noticeable and no drama is caused, the pools will test a little more.

this is the safe rational and natural path to do.

but dont worry about bottlenecking. they wont take 8 years to get to the 2mb 'full' limit. the progress to 2mb will be sooner.

eg if they stepped up by an extra 10kb per block. they could get to 2mb 'full' in just 3 days, safely evaluating the orphan bug risks
or if actual transaction demand per block was only 1.2mb to get everyone in.. it can have blocks have the 2mb limit but blocks only with 1.2mb due to demand only needing 1.2mb and slowly grow as demand grows.

its not a straight near vertical line like the op thinks.. its a curve

ill keep this short



the red line is the OP's view of the future.

the blue area is the reality of past present and future

if there was a thing that required people to burn coins.. exchanges would instantly stop trading before the message circled around to everyone.
so instantly this stops 3letter agencies profiting.

the exchanges wont accept bitcoin deposits. much like the 2013 db drama sipa created with his bug.. exchanges just halted trading.


next part...why 'burn coins??.. seems like a fools errand

afterall how would you 'burn' coins.
if any public key could be bruteforced because all privkeys were available to a 3letter agency. then any 'bticoin eater' public key you sent them to could be bruteforced and funds taken out.

ultimately there is nothing you can do as revenge

at best. to mitigate yourself as a possible victim. you would not have your stash on a single key. that way it wont show up as you being on the richlist for you to be targetted so soon/if at all.

i just see no point in burning coins by sending them to a bitcoin eater address if the agency has a privkey for all known addresses containing funds

i was talking more about someone spending real funds repeatedly onchain(confirmed). every block.

what your describing is a malicious party trying to DDos your node with random data.

so your saying bitcoins problem is that users are not using an altcoin...
much like: a cars problem is that people are not using a train..

see the logic problem of your statement.

if we want to strengthen bitcoin we dont suggest people should use some a different network thats not permissionless nor immutable, and where this other network allows coins to be refunded(csv) even after settlement confirmation simply because they have not matured(cltv) for the weeks maturity

but those 'pushing' are in the same camp, they are his colleagues. infact he is Sipa's boss.. which was the other point rawdog was highlighting afterwards that gmaxwell can still control things.
afterall adam back is also pulling the strings even while pretending he does not pull or push..

commits and merges are 2 different things. but Rawdog said revoke maxwells commit access.. not merge access.. commit.
you replied that he already lost his commit access.. again not merge.. commit.

i replied to show he does still have commit access.. not merge.. commit.

so dont twist it like it was always about merge... when it clearly said commit by rawdog, YOU, twice.. and me.

yea he doesnt have merge status. thats something else.. dont divert the point.
but now you know he has commit access and always had it.. rawdogs point about taking maxwells commit access still has relevance again.

in the last year the only month he did not 'commit' was march.. he must of taken a vacation that month

in 2009-2013 people used sourceforge and then github to openly submit proposals.

this has then been sidelined in 2013+ requiring submitting a proposal to a mailing list to have it vetted first.
then a new layer was added where it needed to be discussed in IRC or the forum before being worthy of catching peoples eye on the mailing list.

its no longer open communication but a one way street with regular checkpoints and guards

malleability fix..
LN does not need it. its a dual signing process. if the TX is malleated. it doesnt get signed. if someone wants to malleate a second tx. they cant as they need the other persons signature for the second tx too, because the data has changed.

and double spending is still an issue because blockstream introduced RBF and CPFP to cause double spends.
also you cannot even confidently trust a confirm tx of funds belong to you if the tx has a CLTV+CSV in it. you have to wait for maturity before declaring 100% immutable

linear scaling..
easy fix dont let a tx have 20,000-80,000 sigops.
if you think linear helps LN work better. you are wrong. an LN is only a 2in 2out 2 signature tx.  thus its sigops is not going to cause seconds/minutes of processing. it remains milliseconds.

again solution to linear is reduce the tx sigops limit.. which also reduces the spam of people trying to make 1mb tx's
funnily blockstream want to allow large transactions. although there is no reason for it

as for
it can actually. please wash away the "1gb blocks by tonight" nonsense you have read somewhere
the mindset of 'Bitcoin will not scale to a world finance system onchain' rhetoric is not original, nor factual..

and go with your other mindset about 10-20year's natural growth you mentioned last year.
bitcoin wont be and rationally shouldnt be the 'one world currency' or the worlds only financial system.. as that would get corrupted.. especially if blockstream becomes the IMF. removing diversity and open choice

instead take a rational 5% populous.. meaning bitcoin ranked in the top 5 'nations' of the world.
then you will see over a couple decades it is easy and manageable.

as for why i checked your post history. its more about understanding am i talking to an empty troll thats just spamming devotion of blockstream in hopes of some recognition and commission from them.. or someone that actually knows a thing or two

reasons bitcoin is not ready for mainstream

1. public keys are worse then remembering a car number plate or someones email address, even QR codes are not 100% the solution
2. decimal values, which needs you to look on another service/site to find your local currencies 'rate'
3. tx fee is more than an hours labour in a dozen developing countries (the same countries that could need bitcoin much.. but are priced out of using)
4. the code is not preventing spam and is left for 'economics' to sort.
5. the 'economics' of avoiding spam actually hurts genuine ethical users more than spammers.
6. the solution to spam is to get everyone locked into permissioned contracts, which funnily spammers will avoid as their intention is not contracted payments, but to spam.

until bitcoin is as straight forward to just buy something by simply swiping an NFC chip. thus not needing an old granny to have a brain bleed trying to fumble around.. .. bitcoin is not ready

until devs stop pretending we are all on dialup 56k internet, and actually stop halting mainnet progress.. bitcoin is not ready

blockstream are helping the banks and governments make a new system. its called hyperledger.

its not going to be a open platform for users to be free from bankers control. its going to be more control given to bankers and government.
yes medical records, bank records, tax record, driving licence, child support, passports will all be relationally linked to each other

bitcoin is being held back due to it.

https://www.hyperledger.org/about/members - general members - blockstream
blockstream are using bitcoin as the sandbox/testbed for hyperledger. slowly centralizing bitcoin and holding it back while then expanding hyperledger so that bitcoin cant compete

here is where your letting your friend shoot you in the foot.

you have a 30MBit/s upload. (3.75mbyte/s = 2.25gbyte/10minutes)
even you know bitcoin can run on a raspberry pi

and even now there is a raspberry Pi3. and bitcoin has had some efficiency gains since you done your tests last year(5x due to libsecp256k1)

so running on a Raspberry Pi3 is about 20x faster today compared to the tests you done last year.

but instead of that rational thought. you let people tell you 2mb is bad and dynamic blocks are bad and baseblock needs to halt at 1mb.

knowing you can send 2.2gb of data every 10 minutes. you want to ignore that 2.2gbyte figure your able to cope with (37.5mb with 60 connections)
and proclaim 2mb with safe incremental growth based on community node agreement is bad.

simply because someone said so. but your own numbers say the opposite than your friends are telling you.
you then want to proclaim that closing off doors to diversity of 71different implementations should be an option and only connect to one 'brand'

do you even hear yourself advocating for centralization, for no reason.

here is a kicker.. core want 4mb weight. while keeping the 1mb base not for 'data restriction' but for transaction utility restriction
so if you ever argue that non core are 'bigblockers' look at cores 4mb weight. look at non cores 2mb request.

2 or 4 which is 'bigblocker'. simply maths, simple observation. 2 or 4 which is bigger.

---

oh and please dont throw out the standard script reply your friends shout. "1gb blocks by midnight doomsday"

we both know the rational consensus of 2016-2017 is 2mb and then natural node consensus accepting growth there after