SegWit is usefull and Bitcoin Core should start cooperate with Bitcoin Classic to get both activated, SegWit and BIP109. Without this, both activations will be much more difficult  Cooperate with a high school science project? Interesting suggestion. A combination of both would be too much and BIP109 is really useless with its added limitations (a 2 MB block size limit without those is better). Did it increase by tenfold in 5 years? Not even close. Satoshi did not have the adequate data here.
There is a lot of processing power being untapped right now. This is typically found in GPUs though: The max radeon single card (not a 2x) of 2008 was, the 4870 doing 1.2 TFLOP (single) / 0.24 TFLOP (double) / 115gb/s ram The max radeon single card (not a 2x) of 2015 was R9 Fury 9 doing: 8.6 TFLOP (single) / 0.53 TFLOP (double) / 512 gb/s ram Two things: 1) I didn't ask for GPUs; 2) Still not tenfold. You didn't logic it correctlly. the block size limit was used to protect against "poison" blocks. The block size limit is in the way of natural growth.
There's nothing natural about it. A different solution to "poison" blocks exists now so block size limit is redundant. Segwit has nothing to do with any of this
It isn't a solution. It is a workaround that prevents certain types of transactions. You are a great example. You studied, you did your math, you weighed in all sides. Even more, you really tried to side with Bitcoin Core and understand them as much as possible. In the end you made your choice. This is a great example of Bitcoin freedom of choice. .
1) He certainly didn't "study" enough and is unaware of a lot of things (e.g. Segwit benefits). 2) The math is high school level and provides inadequate data. 3) It is freedom of choice as long as one sides with Classic, right? Nonsense. Wake me up when the project gets real developers. Seems switching people over was easier than I thought. |
|
|
|
Your wrong, follow the thread url. The hard sigop limit is the way to fight such attacks. All times are for worst case blocks than can be used for attacks and the same computer to make the comparsion fair.
I don't have time to follow that thread. So this is the worst case scenario? If we assume that this is true, then then Segwit seems pretty good. Added capacity without an increase in the amount of hashed data and no additional limitations. Did I understand this correctly? |
|
|
|
The worst case block validation costs that I know of for a 2.2 GHz CPU for the status quo, SegWit SF, and the Classic 2 MB HF (BIP109) are as follows (estimated):
1 MB (status quo): 2 minutes 30 seconds (19.1 GB hashed)
1 MB + SegWit: 2 minutes 30 seconds (19.1 GB hashed)
2 MB Classic HF: 10 seconds (1.3 GB hashed)
Two things: 1) These are apparently estimations; so this is inadequate data. Blocks differ in size, and types of transactions in them. 2) The comparison makes little sense as they've added a hard limit in Classic. When I play this out in my mind I see this;
1) eventually SegWit gets out the door and is adopted but if it doesn't reduce verification times then what was the point?
Segwit: 1) More transaction capacity 2) Fixes TX mallaeability 3) New mechanism for adding OPcodes 4) More flexible security model (fraud proofs) 5) Potential bandwidth decrease for SPV nodes.
Linear scaling of sighash operationsA major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly. Segwit resolves this by changing the calculation of the transaction hash for signatures so that each byte of a transaction only needs to be hashed at most twice. This provides the same functionality more efficiently, so that large transactions can still be generated without running into problems due to signature hashing, even if they are generated maliciously or much larger blocks (and therefore larger transactions) are supported.
Who benefits?
Removing the quadratic scaling of hashed data for verifying signatures makes increasing the block size safer. Doing that without also limiting transaction sizes allows Bitcoin to continue to support payments that go to or come from large groups, such as payments of mining rewards or crowdfunding services.
The modified hash only applies to signature operations initiated from witness data, so signature operations from the base block will continue to require lower limits.
Whatever; I've removed Core 0.12 and am now running Classic 0.12. I am unsettled.
I thought better of you at times. I guess I was wrong. |
|
|
|
i count Lauda + 5 sock puppets
we'll be fine...
Certainly. Please stop with this foolishness. I do not vote in such polls (I have rarely done so in the past). |
|
|
|
|
Realno gledano, što se tiće večine članova daleko bi bolje prošli kad bi sate provedene na forumu proveli radeći za neku satnicu i time kupujuči Bitcoin. Fauceti su gubitak vremena. Jedino pomoću čega možeš doći do nekih para (ako nemaš nekih posebnih vještina) su signature kampanje (i to tek kad budes legendary and above).
|
|
|
|
Less than 10% - 7 (24.1%)
Bitcoin wouldn't be where it is if it wasn't for them. This is the thank you that one gets for doing work for everyone.  I gave them a pretty poor rating. Sorry to their supporters, but the block size and scalability issue has been around for more than 3 quarters. It should have been solved last year already.
Such "issues" can't be solved quickly. A 2 MB block size limit does not improve scalability. Equal oportunity sock puppeting?
Looks like it. This is why polls on this forum are very unreliable. |
|
|
|
Fixing TX Malleability is beneficial to everyone. This *other benefits* - they include giving the ability to introduce consensus changes without hard forking. This is because we are told that a contentious hard fork is a terrible thing. How does anyone know this for sure!?
So being able to run multiple soft forks at once is a bad thing for you? Include the ability to introduce consensus changes without a HF? Source please. Why does segregated witness change the tx fee calculation?
I don't really have an answer to this question. This might do: My guess: To incentivize users to upgrade into segwit.
That is the carrot, and the raising fees of regular txs, the stick.
The same sigop and hash limits could, in theory, be used at any block size limit.
Replacing 1 limit with another is anything, but a nice way of solving problems. |
|
|
|
You and I think very much alike. Lauda, can you point us at a really big but totally legit/non-abusive transaction?
I don't think that there are many transactions that are so large in nature (both 'abusive' and non). This is the one that I'm aware of. However, you'd also have to define what you mean by "big". Do you mean something quite unusually big (e.g. 100kB) or something that fills up the entire block? I'd have to a lot more analysis to try and find one (depending on the type). Segwit isn't a solution designed to fix the block size limit. Its a solution to another problem that right now is undefined, that is being sold as a solution to a problem that is being actively curated by those who refuse to remove a prior temporary hack.
TX malleability (e.g.) is 'undefined'? Segwit provides additional transaction capacity while carrying other benefits. How exactly is this bad? What problem is it that requires signatures to be segregated into another data structure and not counted towards the fees. Nobody can give a straight answer to that very simple question. Why is witness data priced differently?
The question would have to be correct for one to be able to answer it. In this case, I have no idea what you are trying to ask. |
|
|
|
Tip was Chelsea-PSG Halftime DRAW. 2.17 odd, again awesome win.
Yeah. It was the riskier pair of the two if you ask me. Let's see how NBA will go. |
|
|
|
If/when a transaction comes in with zillions of inputs then everyone verifying it will be subjected to a long computation.
Example of such transaction a can be seen here (from last year). |
|
|
|
LN whitepaper is based on assumptions?
No. This was a part explaining how many users could theoretically use Bitcoin at a 1 MB block size limit under certain circumstances (I quoted as I mistakenly read it and spread false information (corrected it everywhere already, I hope). Please read the white-paper before making assumptions.
and libsecp256k1 offers 5x validation speeds.
Okay, I've asked around on IRC and got this: in order to sign or verify the tx, each input has to construct a special version of the tx and hash it. so if there are n inputs there are nxn hashes to be done. hence quadratic scaling.
the TLDR I believe is: ecdsa operations are the most computationally expensive part of verifying transactions, for normal, small size transactions, but they scale linearly with the size (number of inputs).whereas if a transaction in current bitcoin has tons of inputs, the bottleneck moves over to the hashing/preparing data to to be signed, because that time depends on the *square* of the number of inputs.
so usually it's ultra small, but it blows up for large N inputs.
Why doesn't libsecp256k1 have an effect on this? because libsecp256k1 is an ECC library so it's only the "ecdsa" part in the above.
Hopefully this helps, albeit I doubt that many are going to understand it. It certainly isn't easy. |
|
|
|
30 million users?
My god, I have made a HUGE mistake (as I've said this in a few places). I've just re-read the wallpaper and my statement is completely wrong: If we presume that a decentralized payment network exists and one person will make 3 blockchain transactions per year on average, Bitcoin will be able to support over 35 million users with 1MB blocks in ideal circumstances (assuming 2000 transactions per MB).
I must apologize. If anyone sees this mistake anywhere please notify me and I'll delete it. I assume hardware is always getting better because HELLO! and libsecp256k1 offers 5x validation speeds.
Libsec256k1 does not have an effect on the validation problem (Gavin confirmed this somewhere on Reddit but I can't find it). with the 1MB blocks currently all full, i seriously doubt thats true.
what happens when a payment channel with 10,000TX needs to be settled on the blockchain?
My statement is wrong (read above). However, the answer to your question is: It needs 1 transaction on-chain (to close the channel). |
|
|
|
I have find this as a strange activity, to search something to delete in a closed 2 weeks long thread.
This is one of some other PM about deleted messages from the same place.
A few months ago I had one or multiple posts that were ~2 years old (IIRC) deleted. It can happen. Unless the moderator who did it replies or contacts you directly then you might never know. You can message the global moderators (there are 3) directly to find out. However, since it is just a single post and the thread is locked I think that it does not matter. Might not be worth yours and their time. |
|
|
|
The thread was loved by many users, and got many thousands of views, it's so hard to call garbage. This is more about envy of so sucessful thread.
The number of posts and views does tell one nothing about the quality of the thread. This thread is full of random nonsense, ergo has no value, ergo garbage (definitely not successful). I'm worried if such removal may lead to ban.
I don't see a specific reason for which this image would be removed from that thread. I also do not think that these is a reason for which this removal could lead to your ban. |
|
|
|
everything you hear about why we shouldn't increase blocksize is a bullshit excuse to delay the inevitable.
Nope. There are true and valid concerns in regards to it. You can't just play around with numbers as you wish. the lighting network will require bigger blocks too....
According to the wallpaper it will be able to accommodate 30 million users at a 1 MB block size limit.we simply have to do this, the only thing to discuss now is when, thats all.
When, how much and test. Not as simple as you think. core says 1 year because they want the fee market to grow, and get poeple to come to there their second layer solution sooner rather than later.
There is no such thing as "their" second layer solution. You could develop LN yourself, if you had the necessary skills.
Update: Removed completely false statement. |
|
|
|
You've got no right to tell me what to do, as I have no right to tell you your business. So why do you spend 24 hours a day, 365 days a year, telling the Bitcoin dev team what to do Franky? It seems you only like governance when the governors get the "right" answer.
Because this Project is not your property. Stop trying to impose your will on other people's property, and you'll actually end up with some friends (non-sock puppets of that guy working in the cubicle across form you, that is)
I am also financially prepared to fund 5000 nodes with ease.
As long as you don't join in on the Sybil attack on Amazon it is fine. However, deploying 5000 nodes at a single house has a similar effect (the decentralization does help with the networks reliability and safety). In a brighter news. Bitcoin Core is lossing majority on nodes count everyday.
I missed your first post (this one) about nodes. The number of nodes is a very unreliable metric. I'm not sure what you think you would accomplish even if you had the majority of nodes. Sabotage , propaganda and infiltration has been a weapon of choice of the leftists since the Bolsheviks.
The real question is why are people letting themselves be manipulated? I could just as easily DDoS the next service that shows strong support for Core and blame it all on Classic supporters to portray them as evil. |
|
|
|
Please, explain, why there is such activity of moderators, if whole thread is just deleted/closed?
Moderators usually act independently which you should know if you read the rules of this forum. We can't know who did this without more information (how about link to the thread?). The real question is why does this matter to you? That whole thread is garbage. |
|
|
|
|
Show Posts
