The only answer against Miners Mafia is UASF

[quake313]

Blockstream, of which Maxwell is an officer of, stands to profit from Bitcoin becoming a settlement layer. Settlement layer solutions are literally Blockstream's only products.

Do you have any proof to back up that claim?

From what I understand, the only products blockstream currently has are blockchain tech for banks, such as "confidential assets" and the work they did on IBM and Intel's "hyperledger".

They did not develop any lightning implementation, nor did they state they planned to run a lightning hub, and it doesn't make much sense for them to run one as the best businesses to run LN hubs are companies like coinbase and bitpay who already have a large base of users and merchants and are already doing offchain payments.

Blockstream is officially testing Lighting on the testnet. They also consider themselves to be a "implementers" of Lighting protocol system(s).

The first product of Blockstream is licquid, which acts as a 2nd layer above Bitcoin. They have developed Strong Federations, which supplement Liquid.

Blockstream's sidechains also act as a 2nd layer.

I suspect that they will implement confidential assets into either LN or another 2nd layer solution. This is likely where the big money is as Banks spend a lot of money on back office work in settling trades, and have tried unsuccessfully in trying to streamline these processes with blockchain technology.

Further, LN (along with SW) will have so much technical debt, that consultants will likely be needed in order to properly setup LN nodes, and create LN compatible wallets, and the supply of qualified people who can advise companies on how to implement LN will be in short supply, however many of them will work for Blockstream, allowing them to sell their services at high rates -- they will essentially make Bitcoin and LN so complicated so that few people understand how it works.

Conspiracy theory much?

[1713547892]

1713547892

[1713547892]

1713547892

[wck]

Also just exactly how can SegWit block AsciBoost? 

The coinbase transaction in a SW block contains the hash of all the transactions in a block, forcing a miner employing ASICBOOST to spend more resources on calculations so that the advantage to employing ASICBOOST is removed.

Anyway Bitmain has stated they aren't using AsicBoost

But Greg said that he has proof that a miner has implemented ASICBOOST, and that this is why they are not signaling for SegWit.

Since Greg Maxwell is the posterchild for integrity, and has never tried to mislead anyone in his life, it is safe to take his word for it without any evidence. /s

and are holding out for 2MB blocks with SegWit.   Which actually sounds like a reasonable compromise at this point.   https://blog.bitmain.com/en/regarding-recent-allegations-smear-campaigns/

The problem with increasing the max block size at all is that doing so will create a precedent that the max block size will be increased once it needs to be increased (aka when blocks become full). However in order for LN and other settlement layers to be economically viable, tx fees need to be very expensive (prohibitively so), and if one option is to increase the max block size, then tx fees will never be prohibitively expensive. 

I take it that you have never written or even worked on any miner either hardware or software.   Hashing all the transactions in a block is child's play and has nothing to do with finding the block.   

As for the president that is also nonsense.   2 years ago when I was very active the Bitcoin network you would have had a point.   We are about a year past that now.   SegWit would work just as well with a 2 MB max block size as with a 1 MB block size.   There is a lot more politics than common sense being used here.

[AngryDwarf]

The effects of a UASF without miner majority might not be the utopia some people think it might be.

https://www.reddit.com/r/btc/comments/63pzmx/any_uasf_without_miner_majority_is_a_contentious/

UASF allows any resulting hard fork bilateral split to be blamed on the users for activating it without miner majority.

[wck]

That is like saying multiplication is an abuse of addition.   Avoiding needless work is a basic optimization technique.

False equivalency fallacy; as expected by the likes of you. An exploit is an exploit; that is an undeniable fact.

You are showing you are an intellectual giant! Optimization is not the same as an exploit.  

Also just exactly how can SegWit block AsciBoost?  

It does not block it entirely. It blocks the covert usage of it. Segwit changes the block header in a specific way, which prevents the covert usage of Asicboost. In fact, Asicboost as is implemented in current Bitmain devices is incompatible with a lot of potential upgrades (which change the block header).

So?  You actually have nothing ...

Since Greg Maxwell is the posterchild for integrity, and has never tried to mislead anyone in his life, it is safe to take his word for it without any evidence. /s

He's certainly more trustworthy than the likes of Ver, Jihan, Peter R and the other charlatans.

It would appear he is more trustworthy than Landa too ... at least he appears to be doing his own thinking.

You really are trying to make something out of nothing or you are just being a parrot.   Why don't you take some time and actually write a crypto miner and learn what you are talking about.   I've actually written two different miners.   The first one was for Proto Share mining and I used it for months.   The second one is for cryptonight and I'm currently using it.   Both of these were vastly more optimized than the ASICBOOST you are complaining about.  (Otherwise there really isn't any point to writing your own miner.)   Not doing more work than is necessary is just good optimization.  

If you really had a valid complaint that made sense, it would be focusing on the patent, not the technique.   That is where there is a possible valid argument.  

[Carlton Banks]

I suspect that they will implement confidential assets into either LN or another 2nd layer solution. This is likely where the big money is as Banks spend a lot of money on back office work in settling trades, and have tried unsuccessfully in trying to streamline these processes with blockchain technology.

Further, LN (along with SW) will have so much technical debt, that consultants will likely be needed in order to properly setup LN nodes, and create LN compatible wallets, and the supply of qualified people who can advise companies on how to implement LN will be in short supply, however many of them will work for Blockstream, allowing them to sell their services at high rates -- they will essentially make Bitcoin and LN so complicated so that few people understand how it works.

OK, how come the testnet Lightning software looks pretty easy to use already? I've seen nothing more than a couple of screenshots on this forum, and I could figure out how it worked just from that, without even using it.


So, remind us why highly qualified and expensive IT consultants will be needed to run Lightning nodes for businesses, when I can figure it out from a coupe of screenshots? On an early version of the software?

[wck]

I suspect that they will implement confidential assets into either LN or another 2nd layer solution. This is likely where the big money is as Banks spend a lot of money on back office work in settling trades, and have tried unsuccessfully in trying to streamline these processes with blockchain technology.

Further, LN (along with SW) will have so much technical debt, that consultants will likely be needed in order to properly setup LN nodes, and create LN compatible wallets, and the supply of qualified people who can advise companies on how to implement LN will be in short supply, however many of them will work for Blockstream, allowing them to sell their services at high rates -- they will essentially make Bitcoin and LN so complicated so that few people understand how it works.

OK, how come the testnet Lightning software looks pretty easy to use already? I've seen nothing more than a couple of screenshots on this forum, and I could figure out how it worked just from that, without even using it.


So, remind us why highly qualified and expensive IT consultants will be needed to run Lightning nodes for businesses, when I can figure it out from a coupe of screenshots? On an early version of the software?

The Lightning network is actually my primary concern, not SegWit itself.    Personally, I don't care if it is done with a soft fork or a hard fork, but increasing the block size limit only provides more options.   We aren't talking anything crazy like 1 GB, 2 MB isn't that large any more.   Forcing the Lightning network without any fallback isn't rational engineering.   It might be great politics though.

[Carlton Banks]

Forcing the Lightning network without any fallback isn't rational engineering.   It might be great politics though.

But where's the force though?

On-chain capacity can be improved with efficiency increases. The vaunted improvements to tx encoding would give us 20-30% more blockspace, so the 2.1 MB Segwit would become more like the equivalent of 2.5 MB, but still only actually using 2.1 MB. Schnorr signatures would give us a similar amount of extra space in the witness blocks.


So when the Bitcoin devs have solid proposals to:

• Increase on-chain capacity directly from 1MB to 2.1MB
• Increase transaction block efficiency to the equivalent of 2.6MB using the encoding we use now (which would be only 1.05 MB)
• Increase witness block efficiency to the equivalent of 3.75MB using the encoding we use now (which would be only 3 MB)

Now, what's wrong with compressing an aggregated additional 1.25MB of transactions into the 4MB Segwit permits? Getting 5.25MB worth of transactions, while still only using 4MB total?


And why would you say "that's forcing everyone off-chain". On-chain is important, but so is the blocksize. If we can improve the efficiency of on-chain and keep the blocksize the same, adding more blocksize becomes even more effective, the gain ratio is the same improvement every extra MB in blockszie that gets added.

And what's wrong with doing those efficiency improvements before the blocksize is hiked? We already know the arguments against hiking the blocksize right now, what are the arguments against improving the amount of space each transaction uses to achieve more on-chain capacity? I've never heard someone even try to make an argument against the idea.


And again, the Bitcion devs cannot be construed as "forcing people off chain" when you consider that space-efficiency improvements are available and realistic, or when you concede that the blocksize is getting upped by Segwit. This "forcing" description makes zero sense, the devs are just being cautious and diligent, that's all.

[wck]

Forcing the Lightning network without any fallback isn't rational engineering.   It might be great politics though.

But where's the force though?

On-chain capacity can be improved with efficiency increases. The vaunted improvements to tx encoding would give us 20-30% more blockspace, so the 2.1 MB Segwit would become more like the equivalent of 2.5 MB, but still only actually using 2.1 MB. Schnorr signatures would give us a similar amount of extra space in the witness blocks.


So when the Bitcoin devs have solid proposals to:

• Increase on-chain capacity directly from 1MB to 2.1MB
• Increase transaction block efficiency to the equivalent of 2.6MB using the encoding we use now (which would be only 1.05 MB)
• Increase witness block efficiency to the equivalent of 3.75MB using the encoding we use now (which would be only 3 MB)

Now, what's wrong with compressing an aggregated additional 1.25MB of transactions into the 4MB Segwit permits? Getting 5.25MB worth of transactions, while still only using 4MB total?


And why would you say "that's forcing everyone off-chain". On-chain is important, but so is the blocksize. If we can improve the efficiency of on-chain and keep the blocksize the same, adding more blocksize becomes even more effective, the gain ratio is the same improvement every extra MB in blockszie that gets added.

And what's wrong with doing those efficiency improvements before the blocksize is hiked? We already know the arguments against hiking the blocksize right now, what are the arguments against improving the amount of space each transaction uses to achieve more on-chain capacity? I've never heard someone even try to make an argument against the idea.


And again, the Bitcion devs cannot be construed as "forcing people off chain" when you consider that space-efficiency improvements are available and realistic, or when you concede that the blocksize is getting upped by Segwit. This "forcing" description makes zero sense, the devs are just being cautious and diligent, that's all.

Yet a another set of numbers being thrown around.   Seriously why isn't there any consistency when people talk about SegWit?

As for compression goes, it can possible be a boon.   It can also bite hard when it doesn't work correctly, I lost a disk full of data once because of that.   I'm not against it but it does hurt to have options.

Now I haven't studied the SegWit code, and apparently that is what one would have to do to fully understand it.   I did read various descriptions, even 2 different ones from Bitcoin core devs.   Granted they may have been talking about different versions of the code but it really sounds like no one is on the same page here.   To me as a software developer that is really scary.   At a minimum it throws up a flag warning that something pretty complex is going on.

As for what is wrong with changing the block size later, nothing technically.  There also wouldn't be any harm in comprising and hiking the block size limit up front.   The hard fork scare tactics are just that.   I'm not aware of any coin that has died because of a hard fork.    What is wrong is all the politics.   It creates an environment where no one can be trusted.

[chek2fire]

ASICBOOST is a serious problem and everyone even from big block camp must accept that bitcoin community something need to do
BU was not a movement to increase blocksize but to stall bitcoin from miners as he say and a former BU developer

https://medium.com/@heyrhett/why-im-leaving-bitcoin-unlimited-becbc5a149d9

[Lauda]

You are showing you are an intellectual giant! Optimization is not the same as an exploit.  

AsicBoost is an exploit per definition.

So?  You actually have nothing ...

I have just explained to you in a rather simplistic way, why covert Asicboost won't work with Segwit. Instead of actually learning something, you're shrugging it off as "nothing". Either you're very dumb, or you're on a nice payroll.

-snip-

The rest of your post is worthless.

I suspect that they will implement confidential assets into either LN or another 2nd layer solution. This is likely where the big money is as Banks spend a lot of money on back office work in settling trades, and have tried unsuccessfully in trying to streamline these processes with blockchain technology.

Further, LN (along with SW) will have so much technical debt, that consultants will likely be needed in order to properly setup LN nodes, and create LN compatible wallets, and the supply of qualified people who can advise companies on how to implement LN will be in short supply, however many of them will work for Blockstream, allowing them to sell their services at high rates -- they will essentially make Bitcoin and LN so complicated so that few people understand how it works.

OK, how come the testnet Lightning software looks pretty easy to use already? I've seen nothing more than a couple of screenshots on this forum, and I could figure out how it worked just from that, without even using it.

So, remind us why highly qualified and expensive IT consultants will be needed to run Lightning nodes for businesses, when I can figure it out from a coupe of screenshots? On an early version of the software?

This is made up fear mongering from BTU fanatics and shills. They keep making these strong statements, yet have no real evidence nor arguments to back them up. You've pretty much destroyed their statements with this response.

[Carlton Banks]

Yet a another set of numbers being thrown around.   Seriously why isn't there any consistency when people talk about SegWit?

Er, the numbers for Segwit I gave are no different to any other numbers provided by anyone else. 1MB tx block, 3MB witness/signature block.

Sure, the estimates for how much today's 1mB blocks trnnaltes to that have change (1.75 MB at first, now 2.1 MB). That's because they're estimates. Estimates based on how people are using the blockchain at a given moment in time (i.e. the balance between tx data and signature data). What do you want, for the whole of Bitcoin to keep using it excatly the same every day, so you can have an estimate that never changes, even though that estimate is  based on changes in use?

As for compression goes, it can possible be a boon.   It can also bite hard when it doesn't work correctly, I lost a disk full of data once because of that.

Not data compression, that's not what I mean. I used the "compression" expression to simplify the explanantion, but I guess I'll have to explain seeing as you've come to the wrong conclusion.

Data compression on computer disk or media files (mp3, DivX etc) just looks for patterns in data, and then keeps 1 copy of the pattern instead of every copy. Then a map of where the copies occur must be made to re-assemble the original data. If the map gets damaged, there goes your data, as there's no way to re-assemble without the map. That's what happened to your hard drive, the map got corrupted.

All I mean when I'm talking about compressing transactions is encoding the exact same information in less space, but without depending on a map charting the repetitions in the data. When the shrinking of the data doesn't need a map, the risk you're referring to is no longer an issue.

Now I haven't studied the SegWit code, and apparently that is what one would have to do to fully understand it.   I did read various descriptions, even 2 different ones from Bitcoin core devs.   Granted they may have been talking about different versions of the code but it really sounds like no one is on the same page here.   To me as a software developer that is really scary.

If you are able to read code, you should read it. There's no room for misunderstanding if you can just read what it does, the code doesn't have differences in interpretation like humans can have when describing something. As a software developer, you can easily put your misunderstanding to rest by just reading and thinking through the code.

And sure, Segwit adds some complexity. But not really that much more, if you can understand how Bitcoin already works, Segwit is easy to understand. It's often said (by detractors) that Segwit changes millions of LoC (lines of code), but that's a bit of a trick. Segwit adds alot of LoC: but not to existing Bitcoin code. Segwit is more testing code than it is any changes to the main codebase, and as a software developer, I'm sure you understand why more testing code is diligent.

[wck]

You are showing you are an intellectual giant! Optimization is not the same as an exploit.  

AsicBoost is an exploit per definition.

Really sweet, you don't like something so you define it as an exploit.   There isn't any exploit in doing work more efficiently.   There might be an issue with preventing others form doing the same, but that is a legal exploit.

An exploit would be creating fake coins, double spending, stealing from someone's wallet ... those types of things.   

[AngryDwarf]

As for compression goes, it can possible be a boon.   It can also bite hard when it doesn't work correctly, I lost a disk full of data once because of that.

Not data compression, that's not what I mean. I used the "compression" expression to simplify the explanantion, but I guess I'll have to explain seeing as you've come to the wrong conclusion.

Data compression on computer disk or media files (mp3, DivX etc) just looks for patterns in data, and then keeps 1 copy of the pattern instead of every copy. Then a map of where the copies occur must be made to re-assemble the original data. If the map gets damaged, there goes your data, as there's no way to re-assemble without the map. That's what happened to your hard drive, the map got corrupted.

All I mean when I'm talking about compressing transactions is encoding the exact same information in less space, but without depending on a map charting the repetitions in the data. When the shrinking of the data doesn't need a map, the risk you're referring to is no longer an issue.

There are two types of compression, lossy compression and non-lossy compression. Lossy compression is tended to be used on sound and video files, it reduces the size of the file, but it also reduces quality. In many cases people do not notice the loss of quality. Hard drive compression is non-lossy, that is you will get the same file back when it is uncompressed (e.g. zip file). If wck  lost data due to disk compression, then it is due to the file or hard drive getting corrupt.
There are some compression techniques that are intensive to compress, but unintensive to uncompress. This type of compression would be good in a crypto propagation system, since nodes could store and pass on the compressed data and validate it rather quickly. The downside is that the miner takes time to compress it (and runs the risk of being orphaned in a block creation race).
Then of course there is more efficient transaction encoding. This is not actually compression.

[wck]

And sure, Segwit adds some complexity. But not really that much more, if you can understand how Bitcoin already works, Segwit is easy to understand. It's often said (by detractors) that Segwit changes millions of LoC (lines of code), but that's a bit of a trick. Segwit adds alot of LoC: but not to existing Bitcoin code. Segwit is more testing code than it is any changes to the main codebase, and as a software developer, I'm sure you understand why more testing code is diligent.

Actually I was just starting to look at the code.  It isn't a minor change.   That doesn't mean it is bad.   Yes your use of the term compression was confusing.

I actually know a great deal about testing.   A lot of bugs I've worked on turned out to be bugs in the testing code.    It is extremely difficult to do good testing.

SegWit will actually be tested though by LTC.   It is also gaining in adoption probably because of LTC.   Still at only 30% of the blocks signalling SegWit, it has a long ways to go.  

Reading through the BIPs it is pretty clear that the Bitcoin core has become extremely political.   I'm actually happy I choose to work on other miners.  

However that wasn't by choice, I was simply too late to Bitcoin as I didn't start playing around with crypto-currencies until 2012.   Initially I was more into trading and trading bots.   That is why I wrote a PTS miner because I was selling the Proto shares to get BTC.  I didn't like the miners that existed and I wanted to do some AVX assembly.  By 2012 one couldn't profitably mine bitcoin on a computer but some altcoins were very profitable.   At one point I had worked myself up to 60 BTC, but then I got dumb and was scammed by a several cloud mining sites.  Still going after one of the scammers with a class action lawsuit.   One already refunded and a third is hiding in South America from what I can tell.   After that I put stopped playing with crypto-currency for over a year, but was pulled back by the lawsuit.   So I have a lot of general distrust this point for pretty much all the Bitcoin players.   Of coarse altcoins are filled with scammers too.   Actually I've been scammed 5 different times, 2 in bitcoin and 3 in altcoins.    I can't tell you how many scams I successfully avoided though.   So you have to excuse the lack of trust.

So getting back to UASF ... it just seems to be another way to try to force SegWit.   I don't see that it is necessary.   SegWit will stand or fall on its own.

[Lauda]

Really sweet, you don't like something so you define it as an exploit.   There isn't any exploit in doing work more efficiently.   There might be an issue with preventing others form doing the same, but that is a legal exploit.

An exploit (from the English verb to exploit, meaning "using something to one’s own advantage") is a piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic (usually computerized).

Which fits perfectly for AsicBoost. This is unintended behavior which is being exploited by Jihan for personal gain. Living in denial won't help your payroll.

[Carlton Banks]

Then of course there is more efficient transaction encoding. This is not actually compression.

Yes that's a helpful distinction to make. I am aware of these differences (lossy and lossless alike, you could argue that lossy should make use of a different expression to compression, as the actual concept of compression, i.e. with air or a liquid, involves no loss, these are imperfect metaphors and not really properly defined technical terms).

And because computer nomenclature frequently borrows physical concepts to use as metaphors, your assertion "this is not actually compression" isn't as absolute as you suggest. It actually is compression, just not in commonly accepted technical jargon, in the English language. For all you and I know (I don't speak foreign languages or know their computing jargon so well, do you?), the way that file compression and efficient data encoding is described in one language or another may well use the same word for encoding as is used for improved encoding efficiency. I used the expression "compression" just to make sure as many people as possible reading would understand.

[wck]

Really sweet, you don't like something so you define it as an exploit.   There isn't any exploit in doing work more efficiently.   There might be an issue with preventing others form doing the same, but that is a legal exploit.

An exploit (from the English verb to exploit, meaning "using something to one’s own advantage") is a piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic (usually computerized).

Which fits perfectly for AsicBoost. This is unintended behavior which is being exploited by Jihan for personal gain. Living in denial won't help your payroll.

While I'm going to exploit your by simply ignoring you.  That is definitely use this forum to my own advantage.  

[tournamentdan]

ASICBOOST is a serious problem and everyone even from big block camp must accept that bitcoin community something need to do
BU was not a movement to increase blocksize but to stall bitcoin from miners as he say and a former BU developer

https://medium.com/@heyrhett/why-im-leaving-bitcoin-unlimited-becbc5a149d9

Silly core sheep do not have any data showing asic boost has been used at any point.
Statistics show that bitmain pools are performing within 1% of other pools. And their empty blocks mined are in line with every other pool also.
Find a new imagined make believe reason.

[franky1]

ASICBOOST is a serious problem and everyone even from big block camp must accept that bitcoin community something need to do
BU was not a movement to increase blocksize but to stall bitcoin from miners as he say and a former BU developer

lol you do know the S9 and asic boost were created before segwit right..

so did they make a time machine?

[chek2fire]

ASICBOOST is a serious problem and everyone even from big block camp must accept that bitcoin community something need to do
BU was not a movement to increase blocksize but to stall bitcoin from miners as he say and a former BU developer

lol you do know the S9 and asic boost were created before segwit right..

so did they make a time machine?

in the end you will ask everyone to apologised to Jihan.... I see where this goes