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

[cbeast]

SegWit will allow 4-5 tps. That will help some banks participate, but not many. If banks can't even use Bitcoin, who will?

[ahpku]

check out the definition of the word Coup

OED good?
coup, n
1.1 A blow, stroke; the shock of a blow, engagement, or combat; = cope n.2 Obs.
2.2 A fall, upset, overturn. Sc.

You linked to Coup d'état which is more specific and not something I mentioned.

Nakamoto consensus remains and the immutable blockchain has remained resilient against multiple political coups.

Yeah, that's coup d'etat. Now you know.

[ChartBuddy]

Coin



Explanation

[BitUsher]

i was vaguely aware that lighting would require bigger blocks...

so we can have 133MB blocks years from now, but we have to wait a full year for 2MB.

because 2MB today would centralize bitcoin?

No, Core's plan is giving us an effective 2 MB (1.7MB-2MB average) in April + LN in 3-4 th quarter this year increasing that capacity. I suppose you meant to say 3.4MB to 4 MB would centralize Bitcoin?

Why do you keep making this mistake when I have corrected you multiple times?

SegWit will allow 4-5 tps. That will help some banks participate, but not many. If banks can't even use Bitcoin, who will?

I would like to see your math. My math reflects current 4-7TPS with segwit getting us to 6.8 - 14 TPS. Who the hell cares about the banks anyways? Bitcoin is for us , not the banks to use.

[adamstgBit]

SegWit will allow 4-5 tps. That will help some banks participate, but not many. If banks can't even use Bitcoin, who will?

no one unless they NEED to do a settlement TX, for everything else there's Lighting.

the idea is that bitcoin is the backbone, not a "commercial bank" but a "central bank."

[coins101]

...
the true reason to delay blockincress ( we all agree block size increase is INEVITABLE  ) is to get poeple use to using the second layer sooner rather than later.

Blockstream needs forks to get its $75m worth of protocols into Core:

> Recruit as many core devs as possible
> Cause crisis
> Keep crisis going for months / years while you prepare
> Agree to bend, if xyz gets accepted

Pretty clever negotiating tactics, when all you have at the start is a weak hand.

[Adrian-x]

If these proposals were merely framed in terms of technical increases to the blocksize without attempts at hardforks and changes in governance or consensus, they probably would have gone through by now... But they are not about technical increases.

If you had been flowing this since 2013 you'd have a feeling for it, gate keepers have been blocking all discussion and stalling for years. Gavin's proposal was shot down, Maxwell went on a big public rampage exclaiming Gavin is no longer a lead developer and we wont follow him anymore. Gavin then released the working code as XT. Maxwell resigned from assigning BIP numbers most likely after his hand was forced a little while later after BIP101 was added to Core.    

Other Core supported were quick to point out that as total lines of code Maxwell had in fact contributed more to bitcoin than Gavin. However it was recently uncovered that Maxwell had in fact misattribute others contributions to the code by adding his e-mail address to all unclaimed contributions, something he has not corrected to this day. (he could have used any email address he chose but he didn't he chose to use his personal one)

None the less that's a rather cheep shot as adding lines of code is akin to measuring the contribution to building an airplane by measuring the adding of weight.

I think Adam Back the CEO of Blockstream knows full well what a coup is when he sees the centralized control of Core slipping away from his hands.

Bitcoin is better served by many implementation not one centralized one, its not hostile, what is hostile is the censoring of discussion.  

[BitUsher]

If these proposals were merely framed in terms of technical increases to the blocksize without attempts at hardforks and changes in governance or consensus, they probably would have gone through by now... But they are not about technical increases.

If you had been flowing this since 2013 you'd have a feeling for it, gate keepers have been blocking all discussion and stalling for years. Gavin's proposal was shot down, Maxwell went on a big public rampage exclaiming Gavin is no longer a lead developer and we wont follow him anymore. Gavin then released the working code as XT. Maxwell resigned from assigning BIP numbers most likely after his hand was forced a little while later after BIP101 was added to Core.    

There is indeed a small minority of very vocal supporters of contentious hardforks XT/BU/Classic ...
It is great that a majority of the miners, developers , and users support core's plan of a settlement network.  Processing every tx on the chain is futile and won't get us anywhere.

[Adrian-x]

SegWit will allow 4-5 tps. That will help some banks participate, but not many. If banks can't even use Bitcoin, who will?

Be your own bank. we get an extra 4-5tps written to the blockchain but the Witness data that get trimmed puts a 4X increase on the bandwidth needed by the network.

[ahpku]

... Processing every tx on the chain is futile and won't get us anywhere.

Other than the fact that no one is suggesting to have every transaction on-chain, would that be as futile as your solar/micro hydro solo mining farm?
Or ...not quite?

[BitUsher]

SegWit will allow 4-5 tps. That will help some banks participate, but not many. If banks can't even use Bitcoin, who will?

Be your own bank. we get an extra 4-5tps written to the blockchain but the Witness data that get trimmed puts a 4X increase on the bandwidth needed by the network.

Even though it makes my cause look favorable , I have to correct you . Segwit gets us 1.7-2MB realistically, not 4x.

6.8 - 14 TPS

Other than the fact that no one is suggesting to have every transaction on-chain, would that be as stupid as your solar/micro hydro solo mining farm?
Or ...not quite?

Actually quite a few Classic supporters are suggesting everything onchain, and there are no plans for payment channels in Classics roadmap-
https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md

[adamstgBit]

i was vaguely aware that lighting would require bigger blocks...

so we can have 133MB blocks years from now, but we have to wait a full year for 2MB.

because 2MB today would centralize bitcoin?

No, Core's plan is giving us an effective 2 MB (1.7MB-2MB average) in April + LN in 3-4 th quarter this year increasing that capacity. I suppose you meant to say 3.4MB to 4 MB would centralize Bitcoin?

Why do you keep making this mistake when I have corrected you multiple times?

its miscommunication

segwit is not a blocksize increase, it doesn't add more load to the network, in the same way a real blocksize increase ( and subsequent rise in TX vol) does.

when i say 2MB i mean 2MB

when you say 2MB you mean 1MB + segwit

it's all very confusing

[adamstgBit]

if we segwit then we will blocksize incress and HARD targeting 4MB effective block space.

wait that came out all wrong.

then next block increase is critical!!

[Adrian-x]

SegWit will allow 4-5 tps. That will help some banks participate, but not many. If banks can't even use Bitcoin, who will?

Be your own bank. we get an extra 4-5tps written to the blockchain but the Witness data that get trimmed puts a 4X increase on the bandwidth needed by the network.

Even though it makes my cause look favorable , I have to correct you . Segwit gets us 1.7-2MB realistically, not 4x.

6.8 - 14 TPS

I'm not looking at the 1.7-2MB in block size but the extra Multi sig data that is transmitted prior to being written to a block. That extra data is putting more strain on the infrastructure for fewer transactions, and its giving a discount to those transactions what use LN and carry more data. it's a new economic policy favoring the off chain solutions at the expense of mining rewards needed to secure the network.  I'm all fore it, but cost it on the broadcast tx size not the trimmed text size that's written to a block.  

[JayJuanGee]

If these proposals were merely framed in terms of technical increases to the blocksize without attempts at hardforks and changes in governance or consensus, they probably would have gone through by now... But they are not about technical increases.

If you had been flowing this since 2013 you'd have a feeling for it, gate keepers have been blocking all discussion and stalling for years. Gavin's proposal was shot down, Maxwell went on a big public rampage exclaiming Gavin is no longer a lead developer and we wont follow him anymore. Gavin then released the working code as XT. Maxwell resigned from assigning BIP numbers most likely after his hand was forced a little while later after BIP101 was added to Core.    

Other Core supported were quick to point out that as total lines of code Maxwell had in fact contributed more to bitcoin than Gavin. However it was recently uncovered that Maxwell had in fact misattribute others contributions to the code by adding his e-mail address to all unclaimed contributions, something he has not corrected to this day. (he could have used any email address he chose but he didn't he chose to use his personal one)

None the less that's a rather cheep shot as adding lines of code is akin to measuring the contribution to building an airplane by measuring the adding of weight.

I think Adam Back the CEO of Blockstream knows full well what a coup is when he sees the centralized control of Core slipping away from his hands.

Bitcoin is better served by many implementation not one centralized one, its not hostile, what is hostile is the censoring of discussion.  

Fair enough when you describe political jockeying going on from both sides; however, I still believe that any technical solutions should be couched separately from  governance solutions, and likely in most circumstances soft forking is going to be better than hard forks, except to the extent that the hardfork is not contentious, then in those circumstances a hardfork would be acceptable. 

Otherwise, to me it seems that no one person is really in charge of bitcoin or should be considered as being in charge of bitcoin, so if agreements cannot be achieved regarding some proposed change(s) in overwhelming ways, then the status quo would continue to carry on until such overwhelming consensus based agreements could be achieved.

[marcus_of_augustus]

In the beginning there was only darkness, then Satoshi said to Nakamoto "do we have consensus?" and then there was light.

Love this LOL'ed, I had a side bet (a like clockwork prediction) with "my other shillls"  that you'd come here and insult me.  

I'm actually pretty simple to get along with ... play fair, don't try to lie, cheat, steal, distort the facts and you're all good. Step out of line and you're fair game for the full suite of insults, trolling and wrath that the internet makes available.

I really used to like your contributions and it was with a heavy heart when I watched you fall in with a bad crowd. 

[adamstgBit]

if we segwit then we will blocksize incress and HARD targeting 4MB effective block space.

wait that came out all wrong.

then next block increase is critical!!

this is typically a Coreish pattern, it's likely we will not segwit and break into a fork to form a new higher low fee targeting 4cents.

if 4cents hodls, we will segwit tomorrow.

[BitUsher]

its miscommunication

segwit is not a blocksize increase, it doesn't add more load to the network, in the same way a real blocksize increase ( and subsequent rise in TX vol) does.

when i say 2MB i mean 2MB

when you say 4MB you mean 2MB + segwit

it's all very confusing

No , it clearly is an example of misunderstanding segwit. There are two merkle trees that will exist with the signatures split off on their own. Both merkle trees exist in the same block. There aren't two blocks that miners will start mining but single blocks containing 2 merkle trees at a rate of 1 every 10 minutes on average. The blocks will indeed be an effective 1.7-2MB immediately for all users who use segwit enabled wallets.

Segwit will add more data to the blockchain just like increasing the blocksize.

But lets but aside the technical details or semantics for a second. The real question is are you asking if an effective 1.7-2MB Blocksize(done by raising maxBlockSize variable or Segwit) will centralize bitcoin? Or are you asking if an effective 3.7-4MB (done by raising maxBlockSize variable or Segwit) will centralize bitcoin more?

The answer to those two questions is yes. The evidence is clear that even with a 1MB blocksize limit node count has precipitately dropped over the years , especially after blocksize averages exceeded 0.5MB. This trend has only temporarily reversed itself by classic supporters spinning up cloud nodes which constitutes a sybil attack because most of them are non economic nodes not being used by active wallets. I am fine making a small sacrifice and increasing to 2Mb despite this because we need to balance other concerns like adoption perception and giving more time for some wallet providers who have taken over a year thus far to role out changes like dynamic fee market adjustments (slow bastards)... blockchain.info ... seriously WTF!

[adamstgBit]

its miscommunication

segwit is not a blocksize increase, it doesn't add more load to the network, in the same way a real blocksize increase ( and subsequent rise in TX vol) does.

when i say 2MB i mean 2MB

when you say 4MB you mean 2MB + segwit

it's all very confusing

No , it clearly is an example of misunderstanding segwit. There are two merkle trees that will exist with the signatures split off on their own. Both merkle trees exist in the same block. There aren't two blocks that miners will start mining but single blocks containing 2 merkle trees at a rate of 1 every 10 minutes on average. The blocks will indeed be an effective 1.7-2MB immediately for all users who use segwit enabled wallets.

Segwit will add more data to the blockchain just like increasing the blocksize.

But lets but aside the technical details or semantics for a second. The real question is are you asking if an effective 1.7-2MB Blocksize(done by raising maxBlockSize variable or Segwit) will centralize mining bitcoin? Or are you asking if an effective 3.7-4MB (done by raising maxBlockSize variable or Segwit) will centralize bitcoin more.

The answer to those two questions is yes to both. The evidence is clear that even with a 1MB blocksize limit node count has precipitately dropped over the years , especially after blocksize averages exceeded 0.5MB. This trend has only temporarily reversed itself by classic supporters spinning up cloud nodes which constitutes a sybil attack because most of them are non economic nodes not being used by active wallets. I am fine making a small sacrifice and increasing to 2Mb despite this because we need to balance other concerns like adoption perception and giving more time for some wallet providers who have taken over a year thus far to role out changes like dynamic fee market adjustments (slow bastards)...

i can't be bothered to read & understand this technical mumbo jumbo.

in your view is what you are saying bullish or bearish?

[iCEBREAKER]

high fee hurt bitcoin IMAGE.

Agreed that high fees hurt bitcoins image

Since I read Satoshi's whitepaper in 2011, it's been clear that Bitcoin needs high (aggregate) fees to wean it off block subsidies and ensure its independence.

Can we please not worry about the image perceived by those who don't grok the logos (much less the ethos)?

Higher (aggregate) fees = Bitcoin starting to work the way it's supposed to.

Low fees = Fear/uncertainty/doubt Bitcoin will become self-securing and self-sustaining before its baby bottle runs dry.