An Open Letter to Bitcoin Miners – Jonald Fyookball

[HostFat]

Dear Bitcoin Miner,
My name is Jonald, and I am a Bitcoin investor.
I bought my first Bitcoins in 2013 and have been active on the Bitcointalk forum since March, 2014. I’m also a small business owner that actually uses Bitcoin for remittance payments, and I hold a degree in Computer Science.
Since Bitcoin investors and miners need each other to succeed, I wanted to take a minute to reach out to you, and send a sincere message from a “real Bitcoiner”.
 
I’ll cut right to the chase:
I’m concerned. I believe we urgently need to find a scaling solution, and I believe the best solution is to increase the blocksize.
At least, hear me out.

 ...

https://medium.com/@jonaldfyookball/an-open-letter-to-bitcoin-miners-c260467e1f0

[-ck]

He posts regularly here and starts far too many posts already about his anti-core sentiment. Why does he deserve another thread on his behalf now?

The solution's there already. Segwit will be deployed, it's just a matter of time. No, I'm not dreaming; I know the mining world better than most...

[HostFat]

@-ck
It seems that many were sure that segwit had to be activated already, it seems not.

https://coin.dance/blocks

[franky1]

-ck's response.. close eyes, put fingers in ears and just scream go with segwit.
(facepalm)

1. segwit is not as 'compatible' as promised
2. segwits activation event itself, is not about solving quadratics/malleability scaling or anything else. its about setting up the tier network
3. moving funds to segwit keys after activation has a POTENTIAL to affect quadratics/malleability scaling or anything else.
4. but malicious people will stick with native keypairs and continue to do quadratics/spamming to prevent good utility
5. segwit does not stop/disarm/solve native keypairs. thus not 'fix' issues.
6. segwit just disarms innocent people who volunteer to move funds across while letting the network continue doing the same as usual.
7. the 'expected' potential scaling boost of segwit is the same potential scaling of 7tx's on chain of 2009-2017. which still has no guarantee of actual achievability

[mindrust]

-ck's response.. close eyes, put fingers in ears and just scream go with segwit.
(facepalm)

1. segwit is not as 'compatible' as promised
2. segwits activation event itself, is not about solving quadratics/malleability scaling or anything else. its about setting up the tier network
3. moving funds to segwit keys after activation has a POTENTIAL to affect quadratics/malleability scaling or anything else.
4. but malicious people will stick with native keypairs and continue to do quadratics/spamming to prevent good utility
5. segwit does not stop/disarm/solve native keypairs. thus 'fix' issues.
6. segwit just disarms innocent people who volunteer to move funds across while letting the network continue doing the same as usual.
7. the 'expected' potential scaling boost of segwit is the same potential scaling of 7tx's on chain of 2009-2017. which still has no guarantee of actual achievability

Segwit is perfectly fine.

You guys are the ones who block bitcoin's development. Bigger blocks also don't solve anything. If 1mb blocks get spammed and filled, 8mb blocks will also share the same fate in the future. What then, 16mb blocks? I don't see BU as a development at all.

Jihan either will accept Segwit or he will lose his job as a business owner, one way or another he will come around and you paid shills... You are pathetic.

[Lauda]

-ck's response.. close eyes, put fingers in ears and just scream go with segwit.
(facepalm)

Jonald's response:

I am not a contributor to any Bitcoin projects, but I am quite familiar with the scaling topic because I’ve been following it for some time now, and I am knowledgeable enough to clearly understand the technical details.

As others have explained, there is no security provided to the network by non-mining ‘full nodes’.

Are you telling me you support the latter?

[davis196]

He posts regularly here and starts far too many posts already about his anti-core sentiment. Why does he deserve another thread on his behalf now?

The solution's there already. Segwit will be deployed, it's just a matter of time. No, I'm not dreaming; I know the mining world better than most...

How much time.We are waiting for Segwit for a long time and still nothing.
I`m not a BU supporter but all those confirmation time/transaction fees issues block the bitcoin growth.
I don`t see a point in making a thread about quoting some other thread.

[spartacusrex]

This is quoted from a link in Johnny's post.. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013930.html

> If the obsession with every personal computer being able to run a
> full node continues then bitcoin will be consigned to the dustbin
> of history,

The cause of the block size debate is the failure to understand the
Bitcoin security model. This failure is perfectly exemplified by the
above statement. If a typical personal computer cannot run a node
there is no security.

.. This FUNDAMENTAL issue is what 'Jhonny & the BU Supporters' do not understand ..

( You could always start a Band as that sounds like a cool name ! )

[thejaytiesto]

He posts regularly here and starts far too many posts already about his anti-core sentiment. Why does he deserve another thread on his behalf now?

The solution's there already. Segwit will be deployed, it's just a matter of time. No, I'm not dreaming; I know the mining world better than most...

How do you expect segwit to be enabled? and most importantly, when?

While segwit is the best solution to scale right now, and it's perfectly fine and there will be no doomsday as demonstrated in litecoin, I just don't see it happening. At least not for the time being, and it's not like we have a lot of time left. Litecoin is going to start gaining traction as the payment's coin thanks to segwit and lightning network developments.

[HostFat]

@spartacusrex
What is a "typical personal computer"? Why do you see it as "every personal computer" ?

Bitcoin doesn't need that a node must be run on every personal computer, it just need to run on as many personal computers that it will cost too much to attack all of them.
Then all the other can be SPV clients.

This will enable both decentralisation and access to the onchain tx to the larger number of population.

[aarturka]

He is not a 'real bitcoiner' he's altcoiner, like roger vermin and others that backing BU and want to destroy bitcoin

[franky1]

-ck's response.. close eyes, put fingers in ears and just scream go with segwit.
(facepalm)

Jonald's response:

I am not a contributor to any Bitcoin projects, but I am quite familiar with the scaling topic because I’ve been following it for some time now, and I am knowledgeable enough to clearly understand the technical details.

As others have explained, there is no security provided to the network by non-mining ‘full nodes’.

Are you telling me you support the latter?

no, i think jonald is FLAWED to the Nth degree in his understanding of what nodes do. i have face palmed him many times. and corrected him also.

but someone personal beliefs of why they should or should not run a full node is not as big a deal as the empty promises/guarantee's/expectations of segwit which is more of a network wide issue

people should learn about what would truly benefit/hinder the bitcoin ecosystem and what would actually occur due to certain changes, proposals

here is a copy of a PM i sent to jonald as soon as i read this topic

The most ludicrous is the “all users should be running full nodes” idea.

As others have explained, there is no security provided to the network by non-mining ‘full nodes’. Only mining nodes secure and extend Bitcon’s distributed ledger.

The white paper explains why most users do not need to run full nodes:

    It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he’s convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it’s timestamped in. He can’t check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it… …Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.

The idea that a lot of non-mining full nodes will make the network more decentralized (because they can make sure the miners are behaving) is erroneous, because an SPV client can already query the network’s nodes. Generally, there would only be a problem if a majority mining of nodes were colluding dishonestly, in which case Bitcoin would be already broken.

(facepalm)

your taking quotes of (not verbatim) 'some people just want to balance check their own funds which is ludicrous to get those people to run a full node..'
but erroneously trying to twist it into sounding like NO ONE should run a full node and just let pools have full control.
(facepalm)

EG
"As others have explained, there is no security provided to the network by non-mining ‘full nodes’. Only mining nodes secure and extend Bitcon’s distributed ledger."
(facepalm)

your literally saying that relying on pools to be the sole holders of the full data is good
your literally saying that relying on pools to be the sole verifiers of the full data is good
(like a fiat bank) just so that users can balance check...
but that would be making bitcoin insecure and centralised.
(facepalm)

1. pools collate the data, yes. but it needs independent verifiers to accept it in that format as valid. merchants and people that care about security do this and should continue to do this. they do and should continue to reject/orphan blocks that cause issues and make pools follow the rules or find themselves unable to spend rewards.

2. yes some people that dont care and only want to check their balance can just run SPV/lite clients. but that does not mean we should only let pools be the only verifiers of the data.

lets reword your words. maybe that would help you understand:

non-mining full nodes make the network more decentralized (because they can make sure the miners are behaving) because there would be a problem if a majority of pools were colluding dishonestly, in which case Bitcoin would be broken.
..
in short to explain what non mining nodes do:
if a pool offers a new block that does not contain the last accepted block hash (previous hash). and/or does not meet the standards of the node rules(funky tx's, creating funds from nowhere, fraud, etc), then that pool get their block orphaned. once pools realise their blocks are getting orphaned, thus cant spend their rewards with merchants/people. the pools would fall inline and only make acceptable blocks.

removing that power from merchants/people is BAD.
nodes play an important role. and should continue.

you should have stuck with the argument of not everyone needs to be their own bank,.. but not push it into being a plea to centralise pools into being more authoritarian by suggesting merchants and those that do care, should just let pools do all the work.

.. but it seems lately you have jumped over to the other side wanting centralisation by only accepting the one dimensional twisted scripts as gospel.

[franky1]

-ck's response.. close eyes, put fingers in ears and just scream go with segwit.
(facepalm)

1. segwit is not as 'compatible' as promised
2. segwits activation event itself, is not about solving quadratics/malleability scaling or anything else. its about setting up the tier network
3. moving funds to segwit keys after activation has a POTENTIAL to affect quadratics/malleability scaling or anything else.
4. but malicious people will stick with native keypairs and continue to do quadratics/spamming to prevent good utility
5. segwit does not stop/disarm/solve native keypairs. thus 'fix' issues.
6. segwit just disarms innocent people who volunteer to move funds across while letting the network continue doing the same as usual.
7. the 'expected' potential scaling boost of segwit is the same potential scaling of 7tx's on chain of 2009-2017. which still has no guarantee of actual achievability

Segwit is perfectly fine.

You guys are the ones who block bitcoin's development. Bigger blocks also don't solve anything. If 1mb blocks get spammed and filled, 8mb blocks will also share the same fate in the future. What then, 16mb blocks? I don't see BU as a development at all.

Jihan either will accept Segwit or he will lose his job as a business owner, one way or another he will come around and you paid shills... You are pathetic.

lol
1. you using the buzzwords/script words "jihan" "paid shill" is foolish.
2. segwit does nothing to stop native tx's filling the baseblock which prevents segwit tx's sitting in the baseblock to put their feet up in the weight area.

a real proposal is to not allow ANYONE have 20% of the block area for a single tx.
a real proposal is to bring back a NEW and DIFFERENT priority formulae that reward infrequent/lean tx users with low fees. and punish frequent bloated users with high fee's. thus not forcing everyone into LN. but making it super expensive for the spammers (spending every block with loaded tx's). into wasting their funds faster or using LN if their frequent/loaded tx's are genuine.

EG reduce the 'large tx' to below 10% of block
EG reduce the sigops to below 20% of block
EG new priority formulae

here is one example - not perfect. but think about it
imagine that we decided its acceptable that people should have a way to get priority if they have a lean tx and signal that they only want to spend funds once a day. (reasonable expectation)
where if they want to spend more often costs rise, if they want bloated tx, costs rise..

which then allows those that just pay their rent once a month or buys groceries every couple days to be ok using onchain bitcoin.. and where the costs of trying to spam the network (every block) becomes expensive where by they would be better off using LN. (for things like faucet raiding/day trading every 1-10 minutes)

so lets think about a priority fee thats not about rich vs poor(like the old one was) but about reducing respend spam and bloat.

lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.(thats what CLTV does)

and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae with was more about the value of the tx


as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain ($0.01).
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more ($0.44)
if you want to be a spammer spending every block. you pay the price($1.44)
and if you want to be a total ass-hat and be both bloated and respending EVERY BLOCK you pay the ultimate price($63.72)

note this is not perfect. but think about it

[franky1]

@spartacusrex
What is a "typical personal computer"? Why do you see it as "every personal computer" ?

Bitcoin doesn't need that a node must be run on every personal computer, it just need to run on as many personal computers that it will cost too much to attack all of them.
Then all the other can be SPV clients.

This will enable both decentralisation and access to the onchain tx to the larger number of population.

the main 'minimum spec' people are trying to keep bitcoin to is the Raspberry Pi spec..

but since 2009. things have moved on.
libsecp256k1 is 5x better than 2009
internet speed averages are no longer basic ADSL/3G.. we are now in the fibre/4-5G era.
hard drives are cheaper than 2009
(list of effiencies is larger than just above)

meaning 2009's 1mb safe.. is now 8mb safe. even core know and accept this. but still want 4mb at most as extra 'safety'
so going up to a 4mb dynamic* single merkle block**, with the extra features people want. and yes the opt-in voluntary segwit/rbf feature and voluntary LN can all go together happily

but segwits 'soft' approach is cludgy, has no guarantee's and doesnt solve old issues.. and is just kicking the can down the road of hope..

*dynamic=network grows when network can accept it (network consensus growth not dev spoonfed growth)
** full network upgrade where everyone is on the same peer layer.. not the 2merkle tier network of full/stripped/filtered/prunned cludgy blocks for different layers of nodes

[Paashaas]

After all these years Segwit is still the best possible update Bitcoin can have.

I can understand if someone doesn't like it i mean not all people voted for Trump but in the end they need to respect market decision and move on.

BU had there shot but blew it big time. It doesn't matter how 'great' there updates are, BU code is bad. The remaining BU supporters seems to having a hard time to understand how important a well working code is.
( I dont believe Jonald got a degree in Computer Science  )

[franky1]

After all these years Segwit is still the best possible update Bitcoin can have.

I can understand if someone doesn't like it i mean not all people voted for Trump but in the end they need to respect market decision and move on.

BU had there shot but blew it big time. It doesn't matter how 'great' there updates are, BU code is bad. The remaining BU supporters seems to having a hard time to understand how important a well working code is.
( I dont believe Jonald got a degree in Computer Science   )

many people never read trumps books, manifesto's or plans.
many people never read segwits code, documentation or plans.

those that have end up seeing why people facepalm when they see supporters of both.
do you know the difference between what segwit activation does vs what the keypairs do
do you know the difference between what segwit activation does not do vs what the keypairs do not do

do you know what gestures/features/promises will actually get to be seen.

or are you just settling for the idea that because blockstream worked on it since 2014, that its too late to just ask them to try something different/better. due to the mindset of 'they put so much work into it, we should just accept it'

P.S even in 2017 the actual keypairs that segwit will utilise are still not etched in stone. so its not really actually been fully tested since 2014.. its been worked on since 2014.. which is totally different. they are still tinkering with it even now

[freebutcaged]

If I pay 50BTC as a fee intentionally or accidentally a miner will receive it as newly generated coins?
Then what happens to it's records deep in blockchain?

Because those 50 coins no longer exist as in the form they were before I spent them as miner fee and their data is just filling block size while it can be used for other or new data if we could somehow discard them to make room or do something like defragment and consolidate the blockchain.

Many believe if normal users run full nodes it helps the network but why would normal users want to do that?

Only big users, businesses and those paranoid should and are running full nodes aside from miners of course.

Even if normal users start running them they can't change or effect any thing because a miner can out number them if the miner wants his data to be validated it will only makes it harder for them as the numbers of full nodes by individuals increases even then not every normal user knows how to or wants to black list or ban a specific set of nodes/IPs if they start to misbehave.

What would be the result if a miner broadcasts a block of 2MB right now and all other miners accept it but only %50 of nodes accept it as well and just get rejected by other %50 of non-mining nodes?

What is plan B of Core devs?

Can all the Core miners start rejecting every block generated with BU clients?

How much does it cost to run a full node if we were to buy everything in bulk, lets say if you were to deploy 5000 full nodes.

[franky1]

Many believe if normal users run full nodes it helps the network but why would normal users want to do that?

Only big users, businesses and those paranoid should and are running full nodes aside from miners of course.

its nt about getting all 5million+ users to be full nodes.. but certainly not about trying to pretend that nodes are meaningless to hope people turn off nodes to then give pools majority node count to make it easy for pools..

but yes merchants and those that do care about security and protection of the network should run a full node.
there is always has been and should always be a symbiotic relationship. to ensure no one has overall control.

Even if normal users start running them they can't change or effect any thing because a miner can out number them if the miner wants his data to be validated it will only makes it harder for them as the numbers of full nodes by individuals increases even then not every normal user knows how to or wants to black list or ban a specific set of nodes/IPs if they start to misbehave.

there are MANY mechanisms in a node that protect the network.. bitcoin is nothing like the banking system.. nodes are not just duplicate copies of a database.
the consensus/orphan mechanism, to name just one feature... does not need users to do anything manually apart from run the node. the node knows the rules and will throw out any block that doesnt meet the rules. and then the whole network consensus syncing/relay mechanism sorts out the weak from the strong, leaving behind the weak..

What would be the result if a miner broadcasts a block of 2MB right now and all other miners accept it but only %50 of nodes accept it as well and just get rejected by other %50 of non-mining nodes?

well to take one example from history (BU's 1.000250 block mistake)
non mining nodes response

2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)
drama over in 3 seconds.

.. then if the 50% of pools accepted it when the pool makes a new block where by the previous hash was
^000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5

the non mining nodes would reject that next block too..
the non mining nodes would only accept a block where all the previous hashes of blocks followed the rules.

in short over 50% of pools end up making/wasting time making blocks ontop of a block that merchants and users wont see/accept. and those pools wont get to spend their rewards with those merchants/users in 16 hours time..

pools know this!! and for years have been following this knowledge..
which is why when they see its rejected they dont build ontop. instead they go back and find a blockheight that was accepted by the majority and only build ontop of that block. to ensure they are building on the most acceptable chain that will allow them to spend their rewards

this is why NODE+pool consensus events should happen.. and where core went wrong thinking only pools should have the vote
and where core fanboys went wrong thinking the non-core proposals would actually act just on mining flags. when the reality is that things will only happen if there was a combined node and pool consensus

What is plan B of Core devs?

cores plan B is if the community say no, dont back track and listen to the community and make something different.. but continue on and press even harder my making it mandatory, with another year delay
UASF quote: mandatory by late 2018

Can all the Core miners start rejecting every block generated with BU clients?
How much does it cost to run a full node if we were to buy everything in bulk, lets say if you were to deploy 5000 full nodes.

cost is about under $100 for a raspberry pi and a microsd..
what you are talking about is a sybil attack.. also traditionally called a invasion / corporate take over..

[Paashaas]

After all these years Segwit is still the best possible update Bitcoin can have.

I can understand if someone doesn't like it i mean not all people voted for Trump but in the end they need to respect market decision and move on.

BU had there shot but blew it big time. It doesn't matter how 'great' there updates are, BU code is bad. The remaining BU supporters seems to having a hard time to understand how important a well working code is.
( I dont believe Jonald got a degree in Computer Science   )

many people never read trumps books, manifesto's or plans.
many people never read segwits code, documentation or plans.

those that have end up seeing why people facepalm when they see supporters of both.
do you know the difference between what segwit activation does vs what the keypairs do
do you know the difference between what segwit activation does not do vs what the keypairs do not do

do you know what gestures/features/promises will actually get to be seen.

or are you just settling for the idea that because blockstream worked on it since 2014, that its too late to just ask them to try something different/better. due to the mindset of 'they put so much work into it, we should just accept it'

P.S even in 2017 the actual keypairs that segwit will utilise are still not etched in stone. so its not really actually been fully tested since 2014.. its been worked on since 2014.. which is totally different. they are still tinkering with it even now

Well, if that is a critical issue i advice you to make contact with Core/LightCoin dev's about youre concern. They're testing it atm, this will be the moment for it to how to fix it. We'll be gratefull.

[Kprawn]

Why is  Jonald Fyookball's opinion suddenly so important? We all have opinions on the matter and to be honest some of these issues will never be

resolved between these sides. At this moment, any scaling will be better than no scaling at all.... we are kicking the can down the road, thinking

that network spamming will change people's mind. The only thing this has accomplished, is to push people away from Bitcoin. I do not make my

decision based on the developers, but rather the quality of the code being produced by those developers. { NOT the person, but the code }