Wall Observer BTC/USD - Bitcoin price movement tracking & discussion

[Hueristic]

Thanks, getting the gist of it.

Since shitting on ETH seems OK, have a personal story to tell; I was contracted to evaluate Etherum security in 2016 (or it might have been 2017) because the customer wanted to build a service on top of it. After installing the official client which is a clusterfuck of different languages (Go, Python, Java, C#, etc), the client started downloading updates directly from GitHub during runtime (which means any hacked commit could potentially compromise the client instantly), so that was bad, but it didn't end there, the client crashed a lot so testing became hard, shortly after testing some more I advised the customer to not use Etherum to build anything because it's simply not stable enough. The customer was stubborn and had some kind of FOMO about his business partners building frameworks on top of ETH already, so it ended that I just refused to continue but he was welcome to hire someone else to do it. Shortly after this the first Etherum rollback happened due to malicious transactions (can't remember the details, but was not surprised), so it was obviously not "distributed" in a true sense then, emperor of rollbacks (Vitalik) had final word. After this I never touched it again, maybe it has improved security wise, probably not.

Shit, I missed this.

Thanks for sharing, not only is shitting on Eth allowed it is a prerequisite to hat adoption and is wholeheartedly encouraged.

[Hueristic]

Why not a adjustable limit based on a previous median timeframe?

It depends on what purpose you want the limit for. If it's to protect from unusually high loads as the original limit was for then something along the lines you suggest would work (and I've shown support for similar schemes). If, for some reason I can't fathom, you think 1 million bytes per block is a magically correct number for all time then it's not even open for consideration (and you might also not see a problem with foot-binding).

I have no numbers to present. I am just spitballing and am trying to figure out the root of why this hasn't been fixed as it seems to be a pretty academic problem.

I would think that having an agreed upon median would allow the algo to stabilize itself depending on market forces.

This is the first time I have known that this was the issue and appreciate Marcus boiling it down so nicely.

Oh and obviously a limit is just to stop bloat and spam attacks but a dynamic exponential cost seems to be a effective method of mitigation afa that goes.

*I don't know what "foot-binding" is.

[marcus_of_augustus]

... whatever scheme you think you can up with imposing a new limit ( a dynamic limit is the same problem which you seem to have ignored since the dynamic limit also needs to have it's own limit) you'll need a hard fork for that .... and after the bigblockers contaminated all further possibilities of hard-forks with disingenuity, arguing in bad faith and various political machinations that split the development and mining community, I can confidently say bitcoin, as we know it, will never have another hard fork, i.e. any fork will be forked off by opportunists into new coins and the un-hardforked coin will always be known as bitcoin.

[Hueristic]

... whatever scheme you think you can up with imposing a new limit ( a dynamic limit is the same problem which you seem to have ignored since the dynamic limit also needs to have it's own limit) you'll need a hard fork for that .... and after the bigblockers contaminated all further possibilities of hard-forks with disingenuity and arguing in bad faith that split the development and mining community, I can confidently say bitcoin, as we know it, will never have another hard fork, i.e. any fork will be forked off by opportunists into new coins and the un-hardforked coin will always be known as bitcoin.

Well I didn't ignore it I said it could be set on a median which would depend on a timeframe.

IOW lets say we wanted to make the timeframe the last month so whats that like 4300 blocks and we take the average transaction size from those and that is the base number and then we decide on a bounding range to allow for upper limit before the fee kicks in. The range of the blocksize would stabalize with the market forces setting it. It could shrink as well if the transaction count goes down over the median timeframe. All the variable could be set by the devs as they have a much better understanding of the underlying structure. but this is a pretty academic approach that I'm not wondering why I've never seen it discussed. but to be fair I stayed out of all the block threads because it was just a fucking nightmare to follow and I didn't feel competent enough to have an opinion on the subject.

AFA never having another hard fork, I agree with you if something cannot be soft forked in then its DOA. And that is bitcoins biggest failure as far as I can see, there are far too many that put their own priorities before the networks. Its become like government where nothing can get done without all out war.

[DaRude]

I just don't see that.  Banks don't need small blocks to remain necessary.

FYI, small block force a side chain solution which is centralized and there in lies the problem.

I just don't understand why dynamic blocks are just not discussed, it smells of agenda.

... there is no discussion with dynamic blocks because think about for longer than 2 seconds, it goes like this:

"Hmmm, dynamic blocks what's that about?"
"Well the blocks can take any size up to a limit ...."
"Oh a dynamic block size with a limit, what size should we make that?" ... and there it ends, it's the same discussion.

Why not a adjustable limit based on a previous median timeframe?

Because on top of compromising decentralization for usability (the degree of compromise can and has been argued to death, and no there's no free lunch here) it introduces new attack vectors

[ChartBuddy]

Explanation

[Hueristic]

Why not a adjustable limit based on a previous median timeframe?

Because on top of compromising decentralization for usability (the degree of compromise can and has been argued to death, and no there's no free lunch here) it introduces new attack vectors

Could you link that explanation for me, I'm not aware of how compromising decentralization could happen in this instance?

I'm usually pretty good at identifying attack vectors but I don't see the one here.

[stelee68]

Do you guys know about the Binance CFO that quit and left Binance within 24 hours yesterday (10th June)?

I wonder does it have any effect on the market pricing, did it caused the btc dip despite the good news from El Salvador?

[ChartBuddy]

Explanation

[Richy_T]

I have no numbers to present. I am just spitballing and am trying to figure out the root of why this hasn't been fixed as it seems to be a pretty academic problem.

I would think that having an agreed upon median would allow the algo to stabilize itself depending on market forces.

This is the first time I have known that this was the issue and appreciate Marcus boiling it down so nicely.

Oh and obviously a limit is just to stop bloat and spam attacks but a dynamic exponential cost seems to be a effective method of mitigation afa that goes.

Yes. Note that when I wrote "you" I was using the rhetorical "you" and not referring to you specifically.

*I don't know what "foot-binding" is.

Binding feet when young to restrict the growth in older ages. Some cultures find this attractive but it deforms the feet and is quite grotesque.

[DaRude]

Why not a adjustable limit based on a previous median timeframe?

Because on top of compromising decentralization for usability (the degree of compromise can and has been argued to death, and no there's no free lunch here) it introduces new attack vectors

Could you link that explanation for me, I'm not aware of how compromising decentralization could happen in this instance?

I'm usually pretty good at identifying attack vectors but I don't see the one here.

Ugh this again, it's rather simple, but lets try a flow chart

Code:

-nodes matter to decentralization                                             -------------NO---> go to: Faketoshi and BSv
       |
      YES
       |
      \|/
-larger capacity leads to higher resource use                                        ------NO---> go to: math class 
       |
      YES
      \|/
-raising resource reqs eliminates minimum req nodes (Pis can't handle 100mb blocks)    ----NO---> go to: math class
       |
      YES
      \|/
-Less nodes, less decentralization   -NO-> go to: https://en.wikipedia.org/wiki/Decentralization
       |
      YES
      \|/
-Voilà

Some big blockers went full retard and argued for unlimited blocks, enter Faketoshi with his enterprise data center nodes
Other like Richy_T argues for cost/benefit compromise, for multiple reasons market decided against this thus here we are

[Richy_T]

... whatever scheme you think you can up with imposing a new limit ( a dynamic limit is the same problem which you seem to have ignored since the dynamic limit also needs to have it's own limit) you'll need a hard fork for that .... and after the bigblockers contaminated all further possibilities of hard-forks with disingenuity, arguing in bad faith and various political machinations that split the development and mining community, I can confidently say bitcoin, as we know it, will never have another hard fork, i.e. any fork will be forked off by opportunists into new coins and the un-hardforked coin will always be known as bitcoin.

The big blockers acted with good faith all along. You need to revisit your history. They tried arguing and had their voices silenced. They tried reaching agreements and had them reneged on. They had their developers excommunicated and slandered and their mods removed or demoted. They've been lied to and gaslighted endlessly by certain Core devs.

[JayJuanGee]

*I don't know what "foot-binding" is.

Binding feet when young to restrict the growth in older ages. Some cultures find this attractive but it deforms the feet and is quite grotesque.

Surely NOT a good example when talking about bitcoin development, and consensus kinds of decisions that are reached in bitcoin including open allowances for submitting of BIPs and getting discussion on any proposed changes.  The foot-binding example might well be helpful if you want to exaggerate in order to try to attract emotional attention to matters that should NOT be emotional.

... whatever scheme you think you can up with imposing a new limit ( a dynamic limit is the same problem which you seem to have ignored since the dynamic limit also needs to have it's own limit) you'll need a hard fork for that .... and after the bigblockers contaminated all further possibilities of hard-forks with disingenuity, arguing in bad faith and various political machinations that split the development and mining community, I can confidently say bitcoin, as we know it, will never have another hard fork, i.e. any fork will be forked off by opportunists into new coins and the un-hardforked coin will always be known as bitcoin.

The big blockers acted with good faith all along.

Bullshit.  Many of the BIGblockers gave no shits about the issues, they just wanted to try to make it easier to make changes to bitcoin..

You gotta be fucking naive as fuck Richy_T if you believe that BIGblockers were actually going through their bullshit in good faith.

You need to revisit your history.

Oh my... why review it?  My memory still works.

They tried arguing and had their voices silenced.

I don't think so.

They got at least a year, and they just got worse and worse and worse.

Remember in late 2015, Peter wuille came up with a compromise (which was segwit), and for about 6 months (while segwit was coded and tested), there was a lot of consensus that it was great, but then with the passage of time, the disingenuine BIG blocker fucktwats just started to make up other shit about various disagreements they had with it.. .

They tried reaching agreements and had them reneged on.

You can make up any shit that you want... but you just sound bitter and resentful and crying over spilt milk..   It's already spilt.

They had their developers excommunicated and slandered and their mods removed or demoted. They've been lied to and gaslighted endlessly by certain Core devs.

Poor widdle tingilies... Sounds like made-up and exaggerated bullshit to me. 

[philipma1957]

Why not a adjustable limit based on a previous median timeframe?

Because on top of compromising decentralization for usability (the degree of compromise can and has been argued to death, and no there's no free lunch here) it introduces new attack vectors

Could you link that explanation for me, I'm not aware of how compromising decentralization could happen in this instance?

I'm usually pretty good at identifying attack vectors but I don't see the one here.

Ugh this again, it's rather simple, but lets try a flow chart

Code:

-nodes matter to decentralization                                             -------------NO---> go to: Faketoshi and BSv
       |
      YES
       |
      \|/
-larger capacity leads to higher resource use                                        ------NO---> go to: math class 
       |
      YES
      \|/
-raising resource reqs eliminates minimum req nodes (Pis can't handle 100mb blocks)    ----NO---> go to: math class
       |
      YES
      \|/
-Less nodes, less decentralization   -NO-> go to: https://en.wikipedia.org/wiki/Decentralization
       |
      YES
      \|/
-Voilà

Some big blockers went full retard and argued for unlimited blocks, enter Faketoshi with his enterprise data center nodes
Other like Richy_T argues for cost/benefit compromise, for multiple reasons market decided against this thus here we are

pretty good break down.

in hardware a new apollo for sale mines a little bit and runs a full node soon to be lightening node.

it is small nice piece a gear and thousands have been sold.
i did a youtube
https://m.youtube.com/watch?v=iDtEkXawuN4&feature=youtu.be


the builders thread:
https://bitcointalk.org/index.php?topic=5314398.0


these cheap nodes that mine at a small profit can be in 10 thousand homes.

building a super node with 32mb blocks would mean using 8tb ssds in arrays

you would need more than 300mb internet speed.

I loaded a node/wallet on a thread ripper about 18 months ago

used a threadripper 3970 with 128gb ram

used 200mb internet and a 2tb nvme m.2 ssd

took 2 hours to synch it.

the time was 2 hours due to a 100mb switch I downloaded at a constant 80-90mb. it was about 300gb

but if we had a 32mb block thread it would be 16x the size
take 32 hours to download
and use 4.8tb

if it were a 96mb block
it takes 96 hours to download

and use 13.4tb

so that would mean at least two 8tb ssds in an array to give 16tb
maybe the 2000 usd threadripper the 3970 is good enough
maybe the 128gb ram is enough.

but I would need to have built a 9 k rig to do a node.

[Richy_T]

*I don't know what "foot-binding" is.

Binding feet when young to restrict the growth in older ages. Some cultures find this attractive but it deforms the feet and is quite grotesque.

Surely NOT a good example when talking about bitcoin development, and consensus kinds of decisions that are reached in bitcoin including open allowances for submitting of BIPs and getting discussion on any proposed changes.  The foot-binding example might well be helpful if you want to exaggerate in order to try to attract emotional attention to matters that should NOT be emotional.

No analogy bears too close a scrutiny.

Perhaps a better question would be "Assuming that we need a limit, what should that limit be". I would suggest that we should probably be at 16MB currently (which, note, does not mean that we will certainly have 16MB blocks) but I think we should be willing to consider expanding on that as we go.

Going from 1->2MB in 2015 would have allowed us to cautiously observe how such an expansion affected Bitcoin in a fairly controlled way. It would even have been possible to roll things back should it have affected things negatively (actually a soft fork). There's really nothing scary about 12MB/hr other than the n^2 issue with validating transactions with large number of inputs (and that had a work-around and has been solved since).

Marcus is wrong in saying that big blockers have locked Bitcoin in against forks. That was the outcome of Core refusing to take small steps or even entertain the discussion. It has also exposed a very strong centralization issue around Bitcoin's governance (though it's not clear that could have been avoided).

[Richy_T]

Remember in late 2015, Peter wuille came up with a compromise (which was segwit), and for about 6 months (while segwit was coded and tested), there was a lot of consensus that it was great, but then with the passage of time, the disingenuine BIG blocker fucktwats just started to make up other shit about various disagreements they had with it.. .

Segwit was presented as something that it wasn't. As people looked more and more into it, the problems became clear. It wasn't on-chain scaling. It increased the size per transaction, it moved certain parts of the transaction off-chain, it messed with the cost model of transactions, it required major changes to nodes and wallets and it didn't provide the increase in capacity promised. Even today, it only adds 30% to the paltry 1MB in actual use because lies and gaslighting. Yes, people weren't happy with this. Though I don't know why I'm having to go over this, you've got perfect memory of it all, right?

You can make up any shit that you want... but you just sound bitter and resentful and crying over spilt milk..   It's already spilt.

Just putting the record straight. But yes, doesn't make much difference now. "Big blockers" just wanted a bit of organic on-chain scaling while Bitcoin is in its growth phase. Though CSW is a tit who should be in jail.

[JayJuanGee]

*I don't know what "foot-binding" is.

Binding feet when young to restrict the growth in older ages. Some cultures find this attractive but it deforms the feet and is quite grotesque.

Surely NOT a good example when talking about bitcoin development, and consensus kinds of decisions that are reached in bitcoin including open allowances for submitting of BIPs and getting discussion on any proposed changes.  The foot-binding example might well be helpful if you want to exaggerate in order to try to attract emotional attention to matters that should NOT be emotional.

No analogy bears too close a scrutiny.

Perhaps a better question would be "Assuming that we need a limit, what should that limit be". I would suggest that we should probably be at 16MB currently (which, note, does not mean that we will certainly have 16MB blocks) but I think we should be willing to consider expanding on that as we go.

Going from 1->2MB in 2015 would have allowed us to cautiously observe how such an expansion affected Bitcoin in a fairly controlled way. It would even have been possible to roll things back should it have affected things negatively (actually a soft fork). There's really nothing scary about 12MB/hr other than the n^2 issue with validating transactions with large number of inputs (and that had a work-around and has been solved since).

Marcus is wrong in saying that big blockers have locked Bitcoin in against forks. That was the outcome of Core refusing to take small steps or even entertain the discussion. It has also exposed a very strong centralization issue around Bitcoin's governance (though it's not clear that could have been avoided).

Seems to me that your ongoing persistence on this topic strives to presume that something is actually broken in bitcoin, and that is not true.

If you want to make a proposal to change something that is already existing, then you have the burden to provide evidence to support your claims as to why such change is needed and preferable over the status quo and also to provide the logic and argument to persuade why a change is needed. 

If you cannot meet your burden of  proof (evidence) and burden of persuasion (logic) then the status quo continues.  Big blockers had the same problem in 2015/2016, and then even after a proposal was passed, coded and then tested, they changed their minds and said that they did not like it, but they did not present another proposal that was able to reach consensus... segwit reached consensus and those various block limit increase proposals did not get accepted then, and it seems even more doubtful that they will get accepted now because bitcoin seems to be working even better than it was working in 2015-2017 as far as I can see... -  unless you can provide evidence and logic to convince me otherwise, and actually who gives any shits what I think submit your BIP and go through the official channels so that your dumbass ideas that lack both evidence and logic can get discussed and agreed to.

In other words, why agree to a change that is not agreed to and you are not even going through the proper channels to try to get such a change considered... in other words, no one gives any fucks about your made up claims and  your whining about history in which you supposedly were not heard because that BIP system was there all along, and there was not evidence and logic to persuade.. and then the nonsense did get implemented on those other bullshit bcash chains, and wonder why no one is using those superior BIG block systems?  Surely not superior nor a better mouse trap because if it were true, after nearly 4 years for one of the bcash pieces of crap and nearly 3 years for the other bcash crap, you would think that those  BIG blocker versions of bitcoin would gain some traction besides just being scams?  Go figure why they have never amounted to shit, except means to deceive, confuse and mislead people (especially newbies) about bitcoin?

[ChartBuddy]

Explanation

[philipma1957]

but you can now buy a used small form factor like a dell for 200 bucks.

toss in 32gb ram.

a 2 tb ssd and probably go up to a 4 mb block. as long as you have at least 100mbs internet.

beyond that block size you need more power and faster internet.

but a pc with 128gb ram

 i7 core

4tb ssd and 200mbs internet

starts to become costly.

[Hueristic]

...

With what I was describing it could be set in the variables that 100mb blocks would be completely cost prohibited. Did you even read what I wrote? Maybe I should flow chart it for you so that you can grasp the variables that would make such a system live within a specific set of rules all of which are taken from a previous set of rules that already exist and therefore follow a similar trend without having the ability to change rapidly.


Nevermind after reading the responses its apparent this subject still can't be talked about without insults flying around.