Author

Topic: rpietila Altcoin Observer - page 133. (Read 387493 times)

hero member
Activity: 826
Merit: 500
July 27, 2014, 05:00:22 PM
The other killer flaw of Monero is non-zero transaction fees. A coin with zero-transaction fees can surpass it quickly.
So when mining is finished who is going to pay the miners?
Nothing in this world come for free you should know that. This was the stupidest statement I have ever read from you.
Perpetual debasement. If you had bothered to read some of his discussions, you'd know that. You'd make a good posterchild for Dunning-Kruger.
sr. member
Activity: 469
Merit: 250
English Motherfucker do you speak it ?
July 27, 2014, 04:57:01 PM
The other killer flaw of Monero is non-zero transaction fees. A coin with zero-transaction fees can surpass it quickly.
So when mining is finished who is going to pay the miners?
Nothing in this world come for free you should know that. This was the stupidest statement I have ever read from you.
donator
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
July 27, 2014, 04:50:02 PM
I don't think pruning is possible, at least not in the way you could with Bitcoin. There are other things we're looking at, but in my opinion pruning is a non-starter for solving this.

Is there any place I can go to learn about the ideas presented thus far?

This is open source correct?

Just discussions on IRC in #monero-dev (we will move to a more archivable format soon) - once something is ready to be formalised it will be proposed and put up for commentary.
hero member
Activity: 518
Merit: 521
July 27, 2014, 04:47:19 PM
TacoTime, there are cases when it is better to keep my mouth shut. This is one of them.
legendary
Activity: 1484
Merit: 1005
July 27, 2014, 04:40:21 PM
Quote
Centralization is the near-term enemy. Bitcoin is already there. Monero has not innovated at all on decentralization of mining.

There hasn't really been any decent alternatives.

For any proof-of-resource chain, it will tend towards centralization. That centralization can be concentrations of stake or coinage, or signing delegates, or hard drive space, or bandwidth, or whatever.

A censorship free, decentralized, provably temporally stable messaging system for which we can transmit and then store transactions simply doesn't exist. I have a lot of doubts about whether or not there will be a solution to that. I think it will be proven impossible before it will be proven possible.
hero member
Activity: 518
Merit: 521
July 27, 2014, 04:38:28 PM
tl;dr:  People are blowing a lot of smoke to try to achieve their own aims and pretending to be a lot more certain about it than they really are.  It's an important question.  But you probably don't need to panic about it in the short term.

I sort of agree with your post.

I do note nothing gets done to fix these killer flaws, e.g. centralization of mining.

We always push it out into the future when it is too late already, e.g. Bitcoin.

Okay so now we know what the parameters are. So I will go back to work on solving the fundamental problems and Monero can continue moving forward as a stop-gap measure.

Agreed?

(so I can go silent now I hope)
legendary
Activity: 826
Merit: 1002
amarha
July 27, 2014, 04:36:59 PM
The other killer flaw of Monero is non-zero transaction fees. A coin with zero-transaction fees can surpass it quickly.

The other killer flaw of Monero is it inherits Bitcoin's centralization of mining.

I edited my prior post to make that point.

I'm surprised at how many people in the Bitcoin community are fine with the way transaction fees are headed to be honest. I was really surprised too when I downloaded NXT to see that the fee was 1 whole NXT per transaction for a currency just a few months old. I guess they depend on that fee to support the network or something?
dga
hero member
Activity: 737
Merit: 511
July 27, 2014, 04:35:01 PM
- Splitting into fixed size chunks:  2-3x
- Ring signatures with a sane minimum for guaranteeing anonymity:  3x
- Block time:  Negligible in the limit as the number of transactions increases
- Bigger individual signatures and addresses:  2x

Mostly agree, but one comment. Ring signatures do not make up the entire block chain, so using a mix factor of three (approximately 3x signature size) does not mean 3x in terms of blockchain size factors. Perhaps you are already assuming a mix factor of 5 or something, and the 3x number includes this.


Right.  "with a sane minimum" -- something akin to BBR's minimum-mixin flag, to address the long-term mix de-anonymization problem.  A solution to that will boost the blockchain size, though by how much nobody knows yet.  The last time I heard from Zoidberg on this, he was thinking of something like minimum-mixin 5, but don't quote me on that, that's memory. Smiley
legendary
Activity: 826
Merit: 1002
amarha
July 27, 2014, 04:33:58 PM
Thank you AnonyMint, dga, and smooth for your answers. All very interesting perspectives.

hero member
Activity: 518
Merit: 521
July 27, 2014, 04:32:00 PM
The other killer flaw of Monero is non-zero transaction fees. A coin with zero-transaction fees can surpass it quickly.

The other killer flaw of Monero is it inherits Bitcoin's centralization of mining.

I edited my prior post to make that point.
legendary
Activity: 2968
Merit: 1198
July 27, 2014, 04:20:50 PM
- Splitting into fixed size chunks:  2-3x
- Ring signatures with a sane minimum for guaranteeing anonymity:  3x
- Block time:  Negligible in the limit as the number of transactions increases
- Bigger individual signatures and addresses:  2x

Mostly agree, but one comment. Ring signatures do not make up the entire block chain, so using a mix factor of three (approximately 3x signature size) does not mean 3x in terms of blockchain size factors. Perhaps you are already assuming a mix factor of 5 or something, and the 3x number includes this.


hero member
Activity: 518
Merit: 521
July 27, 2014, 04:20:00 PM
Also ask if adding the randomized delay would be compatible with use of I2P as a foundational network layer for general network functions? Answer: No
Not sure I understand, this delay is useful when sending coins because couple of additional seconds is worth the wait. We don't need other general network functions - or do we?

I2P is a general network layer. It is not just Monero that is being run on it. Adding a protocol change to I2P impacts all the network services that run on it. I suppose it might be possible to allow services to opt-in higher latency, so that is implicit in the question I asked of them. But it might not be possible for various reasons, one being resource usage reciprocity on relay nodes (or who provides the bandwidth for free and why are they not the NSA's Sybil attack?).

To get to Visa scale with Bitcoin brings us to 80 Terabytes.

Monero claims 5 - 6x bloat (and I disputed that, it might be higher). So heading towards a Petabyte just to reach Visa scale.

But..
Do we expect and require Visa scale and micro transactions? Bitcoin is fine for that. Remember you yorself claimed we are running out of time because of coming global sovereign debt collapse and currently there is nothing better on the horizon that would stand up to your criticism Wink for now let's just stick with what we have and concentrate on the main goal - it doesn't include micro transactions on Visa scale.

If something comes along that can scale faster because supports ZERO transaction fees, prevents pools from being large, mass mining, micro transactions and Ethereum style contracts, then Monero could be surpassed.

Also I don't believe Monero is anonymous to the NSA and authorities with high reliability given the weaknesses in I2P and Tor.

Also just like Bitcoin, Monero appears headed towards centralization thus it won't take long for NSA to have power to send national security gag order to the few pools that will dominate it, and thus defeat the anonymity either by correlating entry and exit node timing or simply changing the protocol to ban transactions they can't correlate.

Centralization is the near-term enemy. Bitcoin is already there. Monero has not innovated at all on decentralization of mining.

Note I did not argue that Monero is useless in all possible scenarios one can contemplate.
legendary
Activity: 2968
Merit: 1198
July 27, 2014, 04:14:50 PM
So we have people on one hand saying 1TB or some more, and then on the other end you're saying 100PB(?!). Whose estimate is closer to reality?

If it actually is in the 1-2TB range I think that's pretty manageable to be honest. Most people want to use thin clients anyway.

It depends. If you think this is going to replace Visa (or perhaps larger, by including micropayments that are currently handled "off-chain" with Visa) in its present form that then that is probably in the PB range. If you are thinking about Bitcoin today and in the foreseeable future then that is not PB.

Anonymint to his credit wants to "think big" and focus on the former. I think that's entirely reasonable, but I also think it is fairly useless for him to be doing so on this forum, because there is little indication that Bitcoin-derivied technologies are going to do that and certainly he is going to get very little useful collaboration here because few if any in the Bitcoin space are currently making any serious effort to implement it.

The rest of us are (or at least the Monero team is) focused on incremental improvements on what already exists and adding value in the near future. So adding some level of privacy to Bitcoin which currently has essentially none, improving scaling even if that doesn't mean scaling to PB, fixing bugs, improving usability and performance, etc. It is entirely possible that all this work will be made entirely obsolete someday by what Anonymint envisions, but it won't be soon.






dga
hero member
Activity: 737
Merit: 511
July 27, 2014, 04:13:08 PM
I don't get this obsession with bloat. No one in their right mind is going to download the full Bitcoin blockchain so they can spend $10 buying bread at their local shop. So why the hell are people complaining about Monero blockhain bloat? The vast majority of people are not going to be using the full client running a full node. That's just crazy to expect that. Even Bitcoin development is going in this general direction, by getting rid of the QT client and moving to a Core client because in the future, the Core program will be running the full node and third parties will develop the wallet program.


100 Petabytes scaling and thus can't scale without centralization of mining. See upthread details.

So we have people on one hand saying 1TB or some more, and then on the other end you're saying 100PB(?!). Whose estimate is closer to reality?

If it actually is in the 1-2TB range I think that's pretty manageable to be honest. Most people want to use thin clients anyway.

To the previous poster:

(a)  Some people are looking for any hammer they can to bash on the CryptoNote coins in general, and XMR specifically.  This is the most obvious, because it does represent the most apparent tradeoff made thus far:  The cryptonote blockchain is larger than the bitcoin blockchain.

(b)  It's actually interesting, for the above reasons, if your goal is for BTC or XMR or BBR or whatever to "take over the world" (i.e., replace cash) and scale to handle thousands of transactions per second.
  (b.1)  The block time is 60 seconds, so there is 10x more overhead from "blocks" (as opposed to transactions).  An "empty" XMR blockchain is O(10x) larger than an "empty" BTC blockchain.  An empty BBR blockchain is 5x larger than an empty BTC blockchain.  I use the "order of" notation O(x) to note that this is not a precise answer, but it's the right order of magnitude.

  (b.2)  To facilitate anonymity, transactions in CryptoNote are split into fixed-size chunks, so that the precise size of the inputs and outputs is not a clear distinguisher of the transaction.  Thus, one "payment" (as the user sees it) involves more inputs and outputs than might be typically used in Bitcoin.  Kind of.  None of the analyses that people have posted are very careful on this front, because the increase in transaction size depends on how well your client software can match up your existing set of coin inputs (which were also sent as fixed-size chunks!) to the outs it needs to generate.  This may be anywhere from 1x to 10x.

  (b.3)  When using mixins, the ring signature scheme adds an extra signature for every mixin used.  Thus, again speaking vaguely, a CryptoNote transaction is a few times larger than a BitCoin transaction, other factors being equal.

(c)  People are guessing and seem to be biasing their answers in favor of the direction they like. Smiley  I don't think people have a good answer to how much (b.2) above actually adds to things -- my personal hunch is that it's maybe a factor of two or three, but that's a guess.  Some people are pointing out stridently that the "empty blockchain" is actually only X much bigger than bitcoin, and that's true, but it's also a bogus measure, because we shouldn't care about the size of a blockchain that's being used primarily for mining coins and sending them to an exchange.  

The people picking huge constants and multiplying them all together are being similarly deceptive, because they're ignoring that some overheads (such as the block header, etc.) are fixed and shouldn't be included in the multiplication.

If you pick and choose this, you can construct almost any answer you like.

Here's my guess:

- Splitting into fixed size chunks:  2-3x
- Ring signatures with a sane minimum for guaranteeing anonymity:  3x
- Block time:  Negligible in the limit as the number of transactions increases
- Bigger individual signatures and addresses:  2x

Overall:  Roughly 10x the size of bitcoin.  Perhaps 10x, perhaps 30x.  With bitcoin at nearly 20GB, the XMR equivalent would be somewhere in the 200-600 GB range.

This is a concern.  Once the blockchain is too big to fit on a single commodity hard SSD, for example, the *time and knowledge* needed to participate as a full node in the system increases substantially -- RAID arrays, building your own hardware, etc.  The time to download the blockchain may also be a concern for the time to bring a new node into the ecosystem.

This is also an overblown concern for the moment, given the newness of all of these coins, the experiments underway at ring signature pruning (BBR), the increasing understanding of pool management to mitigate dust transactions (XMR), and the fact that we have *no idea* what kind of fees people would be willing to pay in order to have their transactions remain anonymous, or whether and what technical solutions will work well to help keep the size down.  There's also a complex long-term interplay with Moore's law and the volume of transactions.

tl;dr:  People are blowing a lot of smoke to try to achieve their own aims and pretending to be a lot more certain about it than they really are.  It's an important question.  But you probably don't need to panic about it in the short term.
full member
Activity: 211
Merit: 100
July 27, 2014, 04:08:05 PM
Also ask if adding the randomized delay would be compatible with use of I2P as a foundational network layer for general network functions? Answer: No
Not sure I understand, this delay is useful when sending coins because couple of additional seconds is worth the wait. We don't need other general network functions - or do we?

To get to Visa scale with Bitcoin brings us to 80 Terabytes.

Monero claims 5 - 6x bloat (and I disputed that, it might be higher). So heading towards a Petabyte just to reach Visa scale.

But..
Do we expect and require Visa scale and micro transactions? Bitcoin is fine for that. Remember you yorself claimed we are running out of time because of coming global sovereign debt collapse and currently there is nothing better on the horizon that would stand up to your criticism Wink for now let's just stick with what we have and concentrate on the main goal - it doesn't include micro transactions on Visa scale.
hero member
Activity: 518
Merit: 521
July 27, 2014, 04:07:28 PM
I don't think pruning is possible, at least not in the way you could with Bitcoin. There are other things we're looking at, but in my opinion pruning is a non-starter for solving this.

Is there any place I can go to learn about the ideas presented thus far?

This is open source correct?
donator
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
July 27, 2014, 03:50:22 PM
Incorrect on 'linearly'. Bitcoin can theoretically be pruned.

Yeah, I was just being snarky:-P

Monero can't theoretically be (prove me wrong).

And I agree that BoolBerry's pruning probably has a flaw that leads to some divergent scenario such as gridlock. I would need to look closer to be sure, and I don't have time. But I remember thinking about the possibilities in some detail months ago when I learned of Cryptonote and I always thought of divergent scenarios to every pruning strategy.

I don't think pruning is possible, at least not in the way you could with Bitcoin. There are other things we're looking at, but in my opinion pruning is a non-starter for solving this.
hero member
Activity: 518
Merit: 521
July 27, 2014, 03:48:35 PM
Question:

So we have people on one hand saying 1TB or some more, and then on the other end you're saying 100PB(?!). Whose estimate is closer to reality?

If it actually is in the 1-2TB range I think that's pretty manageable to be honest. Most people want to use thin clients anyway.

Reply:

Bitcoin is at 60,000 tx per day and I think Visa + Mastercard is 6,000 per sec. So multiply the 10GB for Bitcoin blockchain by 8000 (= 80 Terabytes) just to get to current commerce. And Visa + MC don't do micro transactions. With micro transactions we would be in the Petabyte range.

So even if your bloat is only a constant factor less than an order-of-magnitude, the real problem is one-time ring signatures defeat the mini blockchain design (because you can't know which address has which balance with ring signatures).

Edit: I think there is some effort underway looking into how to prune the Bitcoin blockchain, but afaics this won't be possible with ring signatures because you don't know which inputs were spent. There are some heuristics that could be applied, but it looked very messy when I thought about it a bit. One of the mixed inputs not spent can cascade and prevent the pruning of all those mixed with.

If that is true, then the units might not be rare but blockchain space might indeed be very scarce (and then must be somewhat expensive). It is a useful perspective.

At 8 billion people and 1024 account balances each, and say 128 bytes per account storage, that is 1 Petabyte. That is the best the mini blockchain could do. One-time ring signatures would make it entirely intractable (100s or more of Petabytes) unless you increase the cost until the 8 billion are restricted.

Let's assume a 10 year goal of 1 billion x 8 account balances each, so 1 Terabyte which is one hard drive. And hard drive space doubles every 18 months, so in 17 years we can store 1 Petabyte on one hard drive. So the mini blockchain can scale.

So there is no scarcity, except for badchosen design (priorities).

P.S. we do have to discourage dust balances though.

To get to Visa scale with Bitcoin brings us to 80 Terabytes without pruning.

Monero claims 5 - 6x bloat (and I disputed that, it could be higher see below...). So heading towards a Petabyte just to reach Visa+MC scale.

And we are expecting micro transactions and crypto-economies (Ethereum, CounterParty, Bitshares, etc) so the volume of transactions could increase orders-of-magnitude over Visa+MC scale.

Wait a minute, 6MB/day with 3% of Bitcoin transactions, and Bitcoins blockchain grows at 34 MB/day, that's not 5x the growth of blockchain compared to bitcoin, it's 5.82x, closer to 6x for the same number of transactions. You want to tell me that 6x bigger blockchain is not a design flaw...

As I wrote upthread, I don't think that 5 or 6x calculation is accurate. Because someone told me that Monero currently has a limitation wherein you can't mix too many inputs (incorrect?), so you need to mix multiple times to achieve the same level of mixing you would with one transaction without the limit. Thus many of the transactions are multiple mixes for the same transaction, thus the real bloat is orders-of-magnitude higher than Bitcoin.

But remember from upthread discussion between smooth and myself, that the level of that multiplier is less relevant. I explained (argued) that the real problem is one-time ring signatures make the blockchain unprunable.
legendary
Activity: 1442
Merit: 1000
Antifragile
July 27, 2014, 03:48:17 PM
I'm really interested here in Open Source Hardware. Guys - anyone have any more information here?
With the NSA revelations, I really don't trust any of the hardware manufacturers (but who does?)

IAS

Not really, you still have to trust someone to build that hardware.

There's a running joke when discussing "secure" systems, that if you want it to be "truly" secure you have to design and build the hardware yourself, and then write the OS yourself. And it has to have no exploitable bugs. In other words, good luck with that;)

When you take usability into account (presumably you don't want to jump through tons of hoops for every message you send and every penny you spend), the best you can do is exercise a moderate amount of caution, and use older, known cryptography on older, known hardware.

Thanks for the information.

(Anyone) - Any suggestion on a small and cheap netbook or the like, to be used as an offline machine?
I will be using a USB stick with the wallet generator on that and just print off it.

Thx in advance,
EMS
hero member
Activity: 518
Merit: 521
July 27, 2014, 03:46:40 PM
Nothing will be truly anonymous until there is an IP solution (not I2P, which is offers only illusory protection) and open source hardware. Bloat is an issue, no matter how much you try to divert attention away. It exposes your coin to centralization and makes it easier to attack the network.

There is no indication that I2P offers "illusory" protection. There are theoretical attacks that remain to be proven, and there are demonstrable attacks that are quickly patched. It is not perfect, but again, it is an added layer of obfuscation that will make it exceedingly hard for an advanced and resourceful attacker to even determine whether you are running Monero or not.

Well, there is this timing analysis attack for example and instead of labeling it theoretical, you could perhaps forward the previously asked question to the i2p team that is supposed to work on the i2p monero integration: is it possible to add some sort of random delay or something that would make this attack not possible?

Also ask how they can prevent Sybil attacks on the relay nodes? Answer: they can't

Also ask if adding the randomized delay would be compatible with use of I2P as a foundational network layer for general network functions? Answer: No
Jump to: