If Eric was serious about this he would have targeted this post at chinese miners who are stalling on activating segwit (which is a 2x blocksize increase and the foundation for instant & nearly free txs via the Lightning Network).
Segwit is not a 2x block size increase. That is marketing spin that Blockstream started spreading to try and fool people into supporting their agenda w/o having to compromise and raise the block size. Segwit does _not_ increase the block size in the sense that people are discussing and in some cases it might even make the transaction throughput much worse than the current system.
The whole reason people want bigger blocks is for higher transaction throughput on-chain. Segwit doesn't deliver that.
You can play semantical games but segwit gives about 2x onchain capacity. And the only thing holding it up is a group of chinese miners/pools. Anyone truly wanting more onchain capacity should be engaging those miners/pools.
Of course that's not really what people bitching about tx fees want.
That's my point exactly people calling segwit a block size increase are playing semantic games. Miners and devs met a year ago and agreed on a path forward of segwit+hardfork blocksize increase to 2MB. Now they are trying to get people to activate segwit w/o a 2mb increase. It's not a mystery why this is happening and it isn't just Chinese miners that oppose it.
The comment you linked to refers to blocks that were specifically made to be big using non-standard scripts that are larger than usual.
For the current mix of transactions happening on the bitcoin network, SegWit will give us an effective block size of 2.1MB (or 2.1x transactions compared to today), and a bit more over time as people start using more advanced scripts.
According to the video below SegWit creates 4x effective transaction space in the same 1MB block. I assume that is a theoretical ceiling unlikely to be achievable in reality?
No, it creates 4x effective transaction space in blocks that can now be as large as 4MB. It does not compress data more efficiently or makes transactions smaller in any way, it is a block size increase in every sense of the word.
The only ones who see this as 1MB block are old nodes that didn't upgrade to a segwit-compatible client. But for nodes that do upgrade, the block is simply larger.
But you're right in that 4MB is the maximum theoretical ceiling. That 2.1MB number I mentioned is what we get according to kind of transactions that we have on the network today. It'll go a bit higher as bitcoin users start using more advanced scripts, but not by much.
Erm, targeted at? You mean he would have, what, written it in Chinese?
Note he said most businesses are looking for Segwit activation + a hard fork blocksize increase (ours included). The "Chinese miners" have expressed that desire as well. Segwit is stalling because it's not what the market is asking for.
SegWit is supported by over 100 businesses and projects, and pretty much by ~everyone in the technical bitcoin community. It definitely is what the market is asking for.
The market also includes miners. Do they appear excited to activate Segwit? As I understand it, they're waiting for a HF blocksize proposal to go with it.
Many of the businesses in that list that preparing for Segwit, but would still prefer that scenario as well (including many of those with the largest user bases).
Lastly, I'm in the technical bitcoin community. I agree most of us are in support of Segwit- just the show of hands at Satoshi Roundtable this year made that clear- but many of us would also like to see a block size increase, and the dev / miner impasse ended.
Segwit requires 95% of miners to activate. Currently about 75% of hash power is controlled by a group of chinese miners/pools. This is about the % of hashing power that is missing for Segwit to activate.
Aware of how Segwit activation works, thanks. I'm speaking to the miners' motivations. They've been asking for a simple blocksize increase for quite some time. See the HK agreement if you don't get the politics.
Yes that's the issue here, the miners are playing politics by trying to flex their power. But no one is willing to play petty games. There's an obvious win for everyone sitting on the table ready to go. Political games will be ignored.
The part you're missing is that Bitcoin is totally fine if it never changed from how it is today. Anonymity will come via Tumblebit. Lightning network can already work even without segwit.
Segwit never getting activated may even be a good thing. It will show everyone that Bitcoin has crystalized and can never be changed via petty human emotion. This was always Bitcoin's true selling point and we may be about to demonstrate it.
Not at all. Like many in the space, I've had to consider and come to terms with the fact that this might be the best version of Bitcoin we have, forever.
But that's not politics being ignored- this is still a group of humans who couldn't come to an agreement after much politicking. That's politics being exhausted.
I do share your optimism that we have a system that can survive gridlock. It just won't fulfill much of its early promise.
> for instant & nearly free txs via the Lightning Network
It's amazing we're putting all our hopes on a technology best labeled as vaporware. You make it out like it's readily available but the fundamental problem of decentralized routing hasn't been solved and it may even be unsolvable.
The simple fact is that blockstream is pushing segwit precisely for it being a necessity for lightning network, not because it's a good thing for bitcoin.
The correct solution would have been a blocksize increase long ago but the same people supporting segwit has been actively blocking all attempts at a blocksize increase previously. Why the sudden change? As another comment said, "Follow the money, it's not baffling at all."
This political argument that it's all just a plot by Blockstream is what is causing the division where the technical benefits of segwit are clear to anybody who knows what they are talking about.
As soon as it became about people and BS conspiracies instead of technical rational solutions it was only going to end up in slagging match.
You're dodging my technical argument well yourself. Segwit implemented as a soft fork isn't clearly full of benefits. But it seems you're just appealing to authority.
I didn't write the and test code myself so you can label that as appealing to authority all you like but I have looked into it and understand the benefits of moving the witness to a subtree of the merkle root so that it can be dropped when it is no longer needed as well as the other changes that are included in the update that allow further soft fork changes enough to see the benefits. I don't just accept someone saying it is good or bad.
Can you explain why such an obvious refactor that is backward and forward compatible isn't a clear benefit?
No it isn't sufficient and won't instantly increase the transaction throughput but the the arguments against it that I've heard are weak and almost all political and could also be argued as appeal to a different authority.
There are two visions of what people see as scaling and are pushing for, on-chain and off-chain. Segwit helps both so being against it can only be politically motivated.
I'm not against segwit but I and many other have problems with segwit as a soft-fork. The push for a soft-fork segwit seems to be politically motivated.
> Can you explain why such an obvious refactor that is backward and forward compatible isn't a clear benefit?
If seen as a blocksize increase it isn't backwards compatible as old transactions will not get the benefit. It is also not transparent as all wallets needs to be updated to support the new transaction format. No such extra effort is needed for a blocksize increase.
The Lightning Network is not bitcoin. The people who are fighting against block size increase are the same people pushing segwit. While there is nothing inherently wrong with segwit and the Lightning Network, they are ignoring the most important improvement to Bitcoin itself, which would be a pure block size increase.
The block size increase with segwit is marginal and a side effect. It's a complicated feature that is meant for purposes other than block size increase. Don't obfuscate the issue. I'm talking about a simple tweaking of a parameter to increase block size.
It's not marginal. According to the mix of current transactions on the bitcoin network, SegWit gives us an effective block size of 2.1MB. Over 2 times more transactions compared to today, which is more than what Bitcoin Classic was pushing for until not too long ago.
> I'm talking about a simple tweaking of a parameter to increase block size.
A "simple" block-size increase requires an hard-fork, which is anything but simple. Hardforks requires a network-wide coordinated upgrade where everyone updates on the same time, at the risk of a currency split and old nodes being open to attacks if not everyone upgrades in time. Hardforks are highly risky and very very slow to deploy safely.
I recently presented some slides on this topic, the relevant part starts here:
Shares are valued by people based on three things. Future direct cash you receive from the company based on the shares you hold (e.g. dividends/distributions and share buybacks). Voting power (i.e. control) in the company based on the shares you hold. And finally the ability to sell the shares you hold on the open market in the future (i.e. price speculation). Issuing more shares (usually) directly affects (i.e. dilutes) #1 and #2. But #3 is not directly affected in any way.
I'm Ripple Labs' Head of Tech Ops and I have to say I think it's amazing. Additionally, there's a program Ripple Labs are running which grants XRP for computing power donated to World Community Grid. So if you want to spend computing power you can, while doing some good. https://www.computingforgood.org/
I believe the weakest link in OTR is its Diffie-Helman key exchange. If you break that you get the symmetric key and can decrypt everything passively. OTR has been using a 1536 bit modulus for its Diffie-Helman exchange since 2004 [1] (The weakest one from RFC 3526 [2]). Seems they are still using the same one today.
In 2004 this was probably a fine choice, especially considering the tradeoff between CPU processing (usability) and security. But considering the NSA scandal, specifically them recording all encrypted communications forever, and Bruce Schneier increasing his key lengths [3], and the ability for CPUs to process higher keylengths without any noticeable slowdown, I don't feel confident it is strong enough today.
Other than this gripe OTR is amazing and everyone should be using it.
Edit: xnyhps's post [4] concludes that only a single "cracking" of the 1536 bit group would need to occur to then decrypt any past or future OTR conversation "instantly".
OTR uses DH in a ratcheting protocol that requires attackers to continuously break new DH exchanges; it's not like TLS, where one exchange at the beginning of the session gives you the whole session.
Also, while a 1536 bit modulus isn't the best you can do in 2014 (we should all be using curves now instead of doing DLP crypto), it's probably not within reach of attackers right now. Effort doesn't scale linearly from those 1024 bit factoring problems.
> OTR uses DH in a ratcheting protocol that requires attackers to continuously break new DH exchanges; it's not like TLS, where one exchange at the beginning of the session gives you the whole session.
Please correct me if I'm wrong, but as far as I know the required effort to break multiple DH exchanges doesn't scale linearly in the number of exchanges. A single successful index-calculus attack on the used group will make breaking additional key exchanges much easier.
You're not wrong. The current state of the art puts the precomputation step at complexity L_n(1/3, 1.923)§, and additional individual discrete logs at L_n(1/3, 1.232). So individual logarithms are still subexponential and nothing to scoff at, but they do become easier, yes.
Ignoring constant factors, for a 1536-bit prime this would mean cost ~2^102 for the initial precomputation, and ~2^66 for each individual log.
§ L_n(a, c) is the usual exp(c(1 + o(1)) (log n)^a (loglog n)^(1-a)).
> The current state of the art puts the precomputation step at complexity L_n(1/3, 1.923)§, and additional individual discrete logs at L_n(1/3, 1.232).
Could you cite that? Not skeptical, just interested.
Razvan Barbulescu's PhD thesis [1]. Note that the best asymptotic complexities are a little different: the 'best' is really L_n(1/3, 1.902), but that variant is hopeless in practice (it would require truly gigantic inputs for it to pay off). Similarly, there is a "discrete logarithm factory" method, based on Coppersmith's factorization factory, but that also has very large initial costs that make it not very attractive in practice.
Yes I get that, I think there is a new DH for almost every message, much better than TLS. The problem is we have no idea what the NSAs abilities are in terms of actual cryptanalysis/cracking, but we do know that they have an immense desire for it.
RFC 3526 puts the low end of the 1536 bit group's strength at 90 bits. If some unknown weakness was found that lowers that significantly that doesn't leave things very safe.
Can somebody weigh in on the feasiblity of cracking Diffie Helman? In Cryptography Engineering, Schneir et al say "there is no known formula" for computing x & y -- but this is a different kind of problem than ciphers, and a suitably advanced mathematical formula could potentially be discovered. It seems to me that the NSA are probably pretty advanced when it comes to prime number mathematics, and it's highly likely that they have teams of cryptographers chasing exactly such a formula.
I would rather see an actual, functional product take off (even without miners). The resistance to Ripple just enables an endless series of me-too fundraisers.
The ethereum proposal is the most technical yet. Hopefully it sets a new minimum bar in the market for crowd-funded vaporware (I'm highly skeptical of them all).
I've never heard of ripple before the GP's post, any particular reason why you consider it a scam? After all, many people consider bitcoin to be a scam as well...
The coin is issued by a central entity who has kept 50% of it. This makes people suspicious. Bitcoin has no central issuing entity, thus no one person to 'get rich quick' in some scam type operation.
Yeah, the early adopters got rich. I think that's fair because they invested in something that was really uncertain at that point. You could even argue that if you buy bitcoins now you're still an early adopter.
Bitcoin itself is less of a pyramid scheme than gold. This is because even when the price stops to rise (or even when it collapses) you can use it to easily transfer value across the world.
Shame downvoters. Proof-of-stake is bitcoin minus the constantly exponential energy increasing requirement for profitable mining operations.
Ripple has the same advantage, but without the benefit that (ongoing) minting of the coin is actually decentralized. In fact you can't see for sure that there is or isn't ongoing minting with Ripple.
Not a shame: At least so far as has been envisioned proof-of-stake doesn't appear to actually work. The fundamental problem with proof of stake is that there is nothing at stake: Its in your rational best interest to mine all possible subchains that you can mine in, and not only in the single unique chain you believe to be most likely to survive, as is the case for PoW.
PPCoin's security is not provided by proof of stake but by cryptographically signed lockins broadcast to the network by its creator... so you have to trust this anonymous party to behave honestly. It sort of defeats the purpose of having a cryptocurrency.
Ripple is even worse in that regard— an opaque ledger implemented via a closed source system.
The source is open, you can build your own chain separate from PPC with the same (or incompatible algorithms), and there is plenty at stake; you might not think your chain will ever be long enough to win, but maybe your transactions need to be private and then there's that at stake.
It is impossible for me to imagine mining all possible subchains that you can mine in; maybe it's because there is no pool I know who supports merged mining in more than just BTC and NameCoin, but I thought there was a technical reason why it wasn't possible (or especially why it was possible specifically for this pair).
You can mine TerraCoin and PPCoin today when you don't need those hashes for BTC, but you can't mine all three at once.
So, how do you propose to mine all possible subchains that you can mine in for the PPC Proof of Stake coin? When the difficulty drops on one chain, it would be to your benefit to mine just that one chain, if you think it will be accepted as the longest chain. Unless you have BTGuild on your side, you don't have much hope of making the longest chain, unless you found a chain that they just forgot.
When I read the CDF graph, I got the impression there is a sweet spot for payouts on chains that behave according to CDF (and because of the nature of "averages" most of us don't have it yet and never will.)
You sound like a person who knows, so I hope you'll tell me more, since I'm interested in Proof-of-Work as it applies to PPCoin. I like the PPCoin website and if that's any indicator, I think that some people will pick PPCoin over Bitcoin without any technical expertise even if it only "seems fairer".
Altruism and defaults are powerful things. In fact, they're the only thing enforcing rules about "nonstandard transactions", without which the blockchain would have been DDoSed all the way to a terabyte by now.
And the checkpointing system is a backup measure used to maintain stability because PPCoin is still small; it is not intended to be the primary mechanism holding it up. If you want to see an altcoin without checkpoints, look at any of the ones that got killed by a 51% attack.
All the supported curves in TLS are most likely influenced by the US government (NIST, ANSI, and SECG). So we don't really have an option to use curves with a non-US provenance.
The NIST curves weren't influenced by the US government so much as they were defined by one NSA cryptographer, Jerry Solinas. On the other hand, the rationale behind their generation is pretty straightforward.
No, the DHE/ECDHE (ephemeral key exchanges) don't protect against MITM, it protects against passive dragnet decryption. But the RSA/ECDSA/DSS part (certificate signing) does. All TLS ciphersuites include certificate signing to protect against MITM, but not all include ephemeral key exchange.
