Topic: The only answer against Miners Mafia is UASF - page 6. (Read 7672 times)

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.

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.

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.   

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?



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.


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.

AsicBoost is an exploit per definition.

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.

The rest of your post is worthless.

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.

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

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.

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.

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?

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

So?  You actually have nothing ...


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.  

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.

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.

Conspiracy theory much?

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.

Can they do that using the DNS seed?

In any case few people deny that LN is the answer to instant microtransactions. Even Roger Ver is happy to implement it in BU, as one thing he really hates is the inability to accept unconfirmed txes safely and has stated he will implement LN to address this kind of problem. We still need onchain capacity though of course, but not at the expense of decentralization. Listening node count is down from 60,000 at it's height to 6,000, I can only see that getting worse with a constantly increasing blocksizelimit.

if blockstream as a DNS seed maintainer set themselves up as just a 'spoke' 'routed hop' between hubs can make 1penny from 7million users a day each

they can repay their $70million VC DEBT in 3 years. especially seeing as how blockstream are VC partnered with coinbase and bitpay anyway
http://dcg.co/portfolio/#b
-bitpay
-blockstream
http://dcg.co/portfolio/#c
-coinbase

so DCG get the blockstream debt paid and it also helps DCG get repaid by coinbase and bitpay. all due to the corporate partnership

Ah. I didn't know that, I'd never heard of that implementation. Seems like eclipse is the go-to one right now.

??
rusty russell of blockstream employment
https://blockstream.com/team/rusty-russell/

is not making lightning network software??

https://github.com/ElementsProject/lightning/graphs/contributors

That is no proof of any kind. You've just made a more definitive statement which comes to clarify the previous one.

Let's start with some basics. How exactly does communist China operate? Once you follow that trail, you will possibly reach a fine amount of evidence.

There is no proof that either one of them have major Bitcoin holdings.

Source for the latter 3?