franky1 where are you? I believe we should stop the drama and start talking about Bitcoin Cash's vision and technical roadmap. The hard fork to 32mb maximum block size is too much in my opinion, but maybe increasing the data carrier size to 220 bytes might encourage a Counter Party Cash smart contract platform to be built on top.
I also like the return of the disabled OPcodes.
I hope your community throws Roger Ver out. If the project is great then that will speak for itself. You do not need Roger Ver.
the internet can handle 32mb
users nodes can handle 32mb (its not raspberry pi v1 days of 2009. nor is it basic ADSL of 2009 either) people are living in the fibre/5g era of duelcore multigigbyte ram with terrabyte hard drives
(just for laughs: 1995: floppy disk "no do not release digital camera's there is no way a piece of portable plastic can hold a 2mb image" we should remain with kodak film and get people to not print their own photo's but lock their photo's into a walmart photo printing service hub, where they decide which photos should be printed )
anyway
32mb every ~10mins is 200mb an hour.
netflix/livestream/youtube use more than that.
yep millions of people livestream(liveupload) their gameplay while also using bandwidth for the game play. so if your against 32mb.. go complain to
google that google+ videocalls wont work
vimeo that livestream wont work
apple that facetime wont work
amazon that twitch.tv wont work
microsoft that skype wont work
google that youtube uploads wont work
... oh wait they do work...... shocker
oh.. to add to that although a block may have a 32mb limit. that does not mean pools ar forced to make 32mb blocks.
take the old bitcoin legacy mainnet of 2009-2013
1mb block consensus rule - under0.25mb mining policy
then upto 2013: 1mb block consensus rule - 0.5mb mining policy
then upto 2015: 1mb block consensus rule - 0.75mb mining policy
meaning a consensus HARD 1mb limit was in place with also a stepped increment soft policy limit growing at 0.25mb evry couple years.
if you ar going to rebut about the validation time and that laughable rebuttable of linear quatratics..
a smart contract(ln channel for instance) is usually a 2in 2 out tx.. it does not need a tx to have the ability of 20,000 sigops
so the solution is to limit the signops per tx so that no one can even make a delay causing validation event by abusing max sigops
anyway
my community?
damn dude you really are stuck in the band camp wars.
i am not pidgeon holed in any band camp. nver have been. again just because i detest core does not mean i must belong to some other team.. take a few steps back and move away from the core cabin. and you will see a wider world. gt out of the echo chamber you are stuck in, its not healthy for you
..
as for utilising new OPcodes.. great. more functionality.. but only if that functionality does not open trojan horse back doors for abuse.
EG
one opcode proposal is to have a TX just sign an input thus allow
(il explain the utopia false pretense first)
the ability to alter how much a tx fee is needed without needing to re-sign a tx
(now for the reality)
alter the values of output without needing to re-sign. and thus if there were 2 outputs
in
bc1qLNfactory 0.2btc
out
bc1qFranky 0.1btc
bc1qwindfu 0.0995btc
(fee:0.0005)
could be altered to
in
bc1qLNfactory 0.2btc
out
bc1qFranky 0.199btc
bc1qwindfu 0.0005btc
(fee:0.0005)
https://bitcoin.org/en/glossary/sighash-nonemany users of smart contracts do not have technical scope to check if a tx is a sighash-none before signing. yep do not expect LN users to request a clartext rawtx version of the contract before signing. which means the system can be abused by counterparts that create such so that they can then alter the output and broadcast a tx where they get most value back to them.
this is why i detest LN because there is loop holes of moving value around after signing and without a blockchain auditing it while in channel. most users are stuck with autopilot and trusting theeir counterparty. even when the counterparty can compile their own LN node to produce such nasty tx types
my hate of the LN is also that it does not scale to a reliable system of random payments to random people for a billion people.
also the features of locking in funds, requiring co-signing and then having delayed maturity and revokes. and other bugs, trojans and backdoors just turns it into somthing worse than fiat2.0
