rpietila Altcoin Observer

[tacotime]

4)  You left off a discussion of transaction identification by prefix.  Comments?  As a mechanism to keep the blockchain smaller, this seems like one of the most technically relevant ways in which BBR departs from XMR, given that the blockchain size is one of the big deals with the entire cryptonote family.

I was going over the features I readily disagree with. I'm not sure about the tx prefixing stuff, because I still don't entirely understand what it solves. It seems that he's making it so that you can't mixin outputs from before checkpoints as inputs, which means you're relying on centralized checkpointing dictated by him to establish what inputs are to be used.

But, as you said, if this becomes useful, we can always implement it in Monero without a lot of hassle (the tx_prefix hashing is from the original ByteCoin code and used in signature generation).

crypto_zoidberg knows the network code very well and is good at patching things relating to it, and the alerts system is a good idea and should be integrated into ByteCoin/Monero/etc.

[AlexGR]

Just to be sure, I own a few MROs myself as a hedge to DRK (although I sold most of them in 0.007-8 with the intention to buy back lower and make a better cost avg), my question-post was to a guy popping up in the DRK thread and pumping Monero / shitting on DRK for like two pages...

I might answer a few counter-points later, as I don't have time right now. However yesterday's events were unsettling. If MRO can't take transactions by 200-300 geeks who use it right now, how can it scale to Bitcoin's levels of 2014 (500-1000 tx per block)?

I knew CN has scaling issues, but this went beyond my expectation. I don't know whether the adaptive block size is at fault or something (I read the thread - but that's the extent of my knowledge regarding the root cause of the issues), but it was not "looking good" to have the chain "stuck".

I always wondered how the market valued bitcoin-based scamcoins with "anon" features (=vaporware) with a 3 day or 1 week lifespan, higher than MRO which had obvious value, but the lack of trust in the bytecoin codebase compared to the trust displayed to the bitcoin codebase may explain this difference. And, maybe, yesterday's events show that this lack of trust towards BCN / CN-codebase is not entirely wrong. Although I believe there is a genuine need for different codebases to hedge Bitcoin with.

Usability can be fixed (adding a GUI is nothing serious), but scaling needs to be worked ASAP. A few people sending coins simultaneously and having the chain stuck = "DOA" material.

[digicoin]

There is a consensus that BBR devs are more familar with CryptoNote source code than XMR devs. I hope that 2 teams can work together  

[tacotime]

I knew CN has scaling issues, but this went beyond my expectation. I don't know whether the adaptive block size is at fault or something (I read the thread - but that's the extent of my knowledge regarding the root cause of the issues), but it was not "looking good" to have the chain "stuck".

The chain was never actually stuck, there's just a limit to how many tx may be included in a block at a time. Many users didn't understand this and panicked and kept trying to resubmit their tx to the network, only to find that the tx were already in the mempool waiting to be included in a block. Adaptive block sizing expanded the chain within an hour, and then the tx all went through.

It seems there was a misconception with that userbase that because block timing is fast, that their tx should be as fast, however, this is not the case from the code or the original documentation.

[AlexGR]

I knew CN has scaling issues, but this went beyond my expectation. I don't know whether the adaptive block size is at fault or something (I read the thread - but that's the extent of my knowledge regarding the root cause of the issues), but it was not "looking good" to have the chain "stuck".

The chain was never actually stuck, there's just a limit to how many tx may be included in a block at a time. Many users didn't understand this and panicked and kept trying to resubmit their tx to the network, only to find that the tx were already in the mempool waiting to be included in a block. Adaptive block sizing expanded the chain within an hour, and then the tx all went through.

It seems there was a misconception with that userbase that because block timing is fast, that their tx should be as fast, however, this is not the case from the code or the original documentation.

Yes I understand that "stuck" is a figure of speech to depict "crawling speeds", but people were complaining about txs that took hours.

We need to do a stress test on the network with 100-500-1000-10000 txs per hour to see if it scales and record the networks ability to process them. After the findings are recorded, an assessment must be done and a course of action must be decided on what to fix (or not fix).

Doing a comparative test to other networks (like BCN and BBR) for similar amounts of transactions is also useful for comparison purposes.

[tacotime]

Yes I understand that "stuck" is a figure of speech to depict "crawling speeds", but people were complaining about txs that took hours.

We need to do a stress test on the network with 100-500-1000-10000 txs per hour to see if it scales and record the networks ability to process them. After the findings are recorded, an assessment must be done and a course of action should be decided on whether it needs fixing or not.

Doing a comparative test to other networks (like BCN and BBR) for similar amounts of transactions is also desired for comparison purposes.

The adaptive blocksizing works fine scaling to any blocksize up to the static limit of 5MB, propagation issues however will make the network difficult to use at these sizes. Because of the fast block timing, it's undesirable to instantaneously generate huge blocks, and adaptive block sizing assists in ensuring this does not happen.

This is the same issue as seen with Bitcoin; there is no fundamental scaling issue CryptoNote coins have that Bitcoin-derived coins do not. This is exacerbated to some extent by larger tx sizes with CN coins, but a lot of this slowdown was simply due to pool related dust on the network bloating tx size, an issue that has been resolved.

[statdude]

Using wolf's hash rate and current parameters, I get marginal cost of 0.00653, which corresponds more closely to current market clearing at 0.007

What's the latest factoring in open source GPU miner?
https://bitcointalk.org/index.php?topic=656841.20

[AlexGR]

Yes I understand that "stuck" is a figure of speech to depict "crawling speeds", but people were complaining about txs that took hours.

We need to do a stress test on the network with 100-500-1000-10000 txs per hour to see if it scales and record the networks ability to process them. After the findings are recorded, an assessment must be done and a course of action should be decided on whether it needs fixing or not.

Doing a comparative test to other networks (like BCN and BBR) for similar amounts of transactions is also desired for comparison purposes.

The adaptive blocksizing works fine scaling to any blocksize up to the static limit of 5MB, propagation issues however will make the network difficult to use at these sizes. Because of the fast block timing, it's undesirable to instantaneously generate huge blocks, and adaptive block sizing assists in ensuring this does not happen.

This is the same issue as seen with Bitcoin; there is not fundamental scaling issue CryptoNote coins have that Bitcoin-derived coins do not. This is exacerbated to some extent by larger tx sizes with CN coins, but a lot of this slowdown was simply due to pool related dust on the network bloating tx size, an issue that has been resolved.

Please consider doing a scaling analysis / simulated scaling run and publish results (no sugar coating) + proposed courses of action to rectify things that may need improvement... If you leave it to third parties to conduct such scaling review, the market is at the mercy of third-parties or FUDers to do it. When they do it, they can have enormous power to tank the market by issuing a report that "CN coins are dead" with proof of a curve hitting a wall that renders the coins DOA.

You need to be pro-active about these things. "Yes we are aware of the problem through our own investigation and we are working on it" etc etc.

[nioc]

I knew CN has scaling issues, but this went beyond my expectation. I don't know whether the adaptive block size is at fault or something (I read the thread - but that's the extent of my knowledge regarding the root cause of the issues), but it was not "looking good" to have the chain "stuck".

The chain was never actually stuck, there's just a limit to how many tx may be included in a block at a time. Many users didn't understand this and panicked and kept trying to resubmit their tx to the network, only to find that the tx were already in the mempool waiting to be included in a block. Adaptive block sizing expanded the chain within an hour, and then the tx all went through.

It seems there was a misconception with that userbase that because block timing is fast, that their tx should be as fast, however, this is not the case from the code or the original documentation.

Yes I understand that "stuck" is a figure of speech to depict "crawling speeds", but people were complaining about txs that took hours.

We need to do a stress test on the network with 100-500-1000-10000 txs per hour to see if it scales and record the networks ability to process them. After the findings are recorded, an assessment must be done and a course of action must be decided on what to fix (or not fix).

Doing a comparative test to other networks (like BCN and BBR) for similar amounts of transactions is also useful for comparison purposes.

I was one of those people but it turns out it was a problem with the exchange I was sending from not Monero.  I posted this in the main Monero thread when I found out what the issue was.

[crypto_zoidberg]

Hello.
At first - thank you to interest to BBR project.

I think it is generally helpful for the particulars of these differences to be well-known.  Can you provide a reference?  Or even just high-entropy keywords?

1) Using the block header hashes as the scratchpad was intended to keep individual miners full nodes, but this was naive and pools simply send the (tiny) headers out to the miners themselves. There is lots of discussion about how to prevent pool centralization in Bitcoin lately, and Boolberry's solution has been criticized as being "the worst of both worlds" (requires lots of extra data to hash, but doesn't prevent pooled/centralized mining at all).

This is simply not true.
The main reason of using this approach was to solve hash speed problem and to keep memory hard, it was discussed in our pre launch pow discussion thread.

Since cn_slow_hash created 2MB scratchpad, it's have to cover all this data, that's why they use 2²⁰ iterations, and side-effect from this pretty slow work (about 500ms on normal laptop, twice faster on normal pc with suitable cpu cache). It may slow down synchronisation process at downloading blockchain (that is not a big problem) and theoretically it may be possible to attack network - connect and send a random block to make peer calculate slow_hash for useless fake block.

So, putting all together, we want to have:
1. Wide CPU instruction set
2. Memory-oriented algo
3. Small work time.

Realizing it, we've  tried to take a step to the side.

Idea of using blockchain data as scratchpad resulted in this hash function:
.......

2) Aliases attach additional, permanent identity pieces to your addresses and should probably be avoided in my opinion.

Aliases is a feature for people who want to make their addresses public. Like your xmr address in your account signature, that is actually also "permanent identity piece".

3) The mandatory mixin=n for txouts doesn't solve fundamental issues with privacy relating to ring signatures. Monero has the same issues, but this will be discussed in an upcoming softfork proposal I'm coming up with thanks to some guidance from gmaxwell. Right now, because Monero is mostly used speculatively, it's not really an issue and is probably a boon to trading over the chain. Further, Boolberry's feature attaches identifier information to outputs which may be further used in analysis to identify spenders.

As i understand from gmaxwell reply to me, he is also concerned about this security problem in monero/bcn.
This BBR feature at least provide a solution to solve this issue, unlike other cn projects including monero.
There are no identifer information in outs, taco, don't lie.
This is a policy attribute that can't provide more information about out than already exists in blockchain, but it will keep out untracebility property in safe(that can't be granted in monero).

This attributes also provide an ability to have public addresses that want to share their balance, public fund for example. Sending money to such fund with mixin attribute = 0 grant that this outs woun't be mixed and spending could be easily seen.

Sorry for bad english.
Zoidberg


PS: this is funny that you blame my project, but take my commits less that in few in hours.

[tacotime]

Hello.
At first - thank you to interest to BBR project.

This is simply not true.
The main reason of using this approach was to solve hash speed problem and to keep memory hard, it was discussed in our pre launch pow discussion thread.

Since cn_slow_hash created 2MB scratchpad, it's have to cover all this data, that's why they use 2²⁰ iterations, and side-effect from this pretty slow work (about 500ms on normal laptop, twice faster on normal pc with suitable cpu cache). It may slow down synchronisation process at downloading blockchain (that is not a big problem) and theoretically it may be possible to attack network - connect and send a random block to make peer calculate slow_hash for useless fake block.

So, putting all together, we want to have:
1. Wide CPU instruction set
2. Memory-oriented algo
3. Small work time.

Realizing it, we've  tried to take a step to the side.

Idea of using blockchain data as scratchpad resulted in this hash function:
.......

That's my mistake, then. There's numerous discussions about it in this thread. Botnet resistance is only mentioned in passing. As far as memory hardness, whether or not this will ever be an issue on modern GPUs (whose onboard DRAM increases exponentially with Moore's law) given linear increases in memory for wild keccak with increasing chain size remains to be seen.

As i understand from gmaxwell reply to me, he is also concerned about this security problem in monero/bcn.
This BBR feature at least provide a solution to solve this issue, unlike other cn projects including monero.
There are no identifer information in outs, taco, don't lie.
This is a policy attribute that can't provide more information about out than already exists in blockchain, but it will keep out untracebility property in safe(that can't be granted in monero).

This attributes also provide an ability to have public addresses that want to share their balance, public fund for example. Sending money to such fund with mixin attribute = 0 grant that this outs woun't be mixed and spending could be easily seen.

Sorry for bad english.
Zoidberg

gmaxwell brought up this point. You can distinguish users based on what mixin count they demand, which, like amounts, can be used for identification. Similar issues exist for payment IDs, which I refuse to use.

Monero is actively solving this issue, and we will have a proposal and fix out in the near future.

PS: this is funny that you blame my project, but take my commits less that in few in hours.

We have different design intentions, and disagree about what features should and should not be implemented. I have complimented your bugfixes on the network/core before, but I can't agree with everything you engineer, as probably you will not agree with everything I engineer.

[drawingthesun]

I'm still only in monero and bitcoin. I have 100% confidence in tacotime and am very happy with the current state of the project. Many core issues need fixing before a GUI is incorporated into the main development branch.

My earlier comment was being a little sarcastic. Like Hal Finney said with Bitcoin, if a clone was to overtake Bitcoin with no real merit it would erode all confidence in using crypto as a store of value.

Bytecoin had to be replaced, its release was immoral and deceptive. Monero then became the first fair launch of a CryptoNote coin.

Now I will not support a coin to overtake monero unless its feature set was such that is was better and unable to be incorporated back into the monero core.

Nothing in any of the clones is better. When I'm talking about better, I'm talking about the jump from bitcoin to monero. I will support the next coin that has a similar jump. At the moment there aren't even any serious conceptual models for such a giant leap.

I will also state my opinions on the bloat of the blockchain again. If we can get the final chain within a 5-10:1 ratio with bitcoin, then that is fine. A larger chain is worth the functionality of an anonymous chain. Something darkcoin can never offer us.  The block size issues, the memory and bandwidth requirements are all being worked on. I have absolute confidence in the monero team.

By the way. If the next big thing comes like monero. I'll end up holding 3 coins instead of 2.

[drawingthesun]

Looks like BBR is taking over. What does rpietila think about this?

I still don't know enough of the coin, so I'll stick with XMR. The little I know does not warrant a switch.

ADD: Boolberry is so stupid a name that it must be changed before I'll consider

It's not.

I see no chance of a boolberry takeover. If boolberry did takeover I would probably sell back into bitcoin because it would mean any cryptonote coin can be destroyed by a features for feature sake coin. Which is what boolberry and litecoin are. The proof of work. The alias. The tx modifications. It's just an attempt to differentiate for the sake of marketing.

It's litecoin all over again.

[crypto_zoidberg]

I'm going to disagree with #2 - I think the issue with aliases is that they haven't been yet pushed hard enough.  For example, there should be an alias rebinding mechanism (perhaps using a tx fee and a signature from the originally bound key).  

We already have rebinding mechanism, it was initially designed and implemented, to rebind alias you need to prove that you own aliased address by signing rebind message using  current aliased address private spending key. My fail that it is not documented well and not represented in command line options yet, since i thought it is not important at this moment.

Zoidberg

[crypto_zoidberg]

Looks like BBR is taking over. What does rpietila think about this?

I still don't know enough of the coin, so I'll stick with XMR. The little I know does not warrant a switch.

ADD: Boolberry is so stupid a name that it must be changed before I'll consider

It's not.

I see no chance of a boolberry takeover. If boolberry did takeover I would probably sell back into bitcoin because it would mean any cryptonote coin can be destroyed by a features for feature sake coin. Which is what boolberry and litecoin are. The proof of work. The alias. The tx modifications. It's just an attempt to differentiate for the sake of marketing.

It's litecoin all over again.

Probably this is my fault that people don't understand features of BBR since it is not well explained, i guess current explanation sounds like jargon and not clear.
But if you take a look in deep - it is improvement of technology, that i've made after wide research of cryptonote technology.

[crypto_zoidberg]

4)  You left off a discussion of transaction identification by prefix.  Comments?  As a mechanism to keep the blockchain smaller, this seems like one of the most technically relevant ways in which BBR departs from XMR, given that the blockchain size is one of the big deals with the entire cryptonote family.

I was going over the features I readily disagree with. I'm not sure about the tx prefixing stuff, because I still don't entirely understand what it solves. It seems that he's making it so that you can't mixin outputs from before checkpoints as inputs, which means you're relying on centralized checkpointing dictated by him to establish what inputs are to be used.

But, as you said, if this becomes useful, we can always implement it in Monero without a lot of hassle (the tx_prefix hashing is from the original ByteCoin code and used in signature generation).

crypto_zoidberg knows the network code very well and is good at patching things relating to it, and the alerts system is a good idea and should be integrated into ByteCoin/Monero/etc.

1. You still can mix and use outs as you wish. Ring signature doesn't affect this. Ring signature is actually the feature that let transaction to get included into blockchain. Since transaction is included into blockchain that mean that ring signature check is passed by every network machine. So, after thousands on confirmations ring signamtures seems not really necessary.
One of the way to use this feature is to cutoff ring signatures that is under checkpoints. Not the best solution, may be we gonna find something more nice.

2. You need to hardfork to support this, since transactions included in block by their id (in merkle tree).



Zoidberg

[Melbustus]

I'm still only in monero and bitcoin.
...
Like Hal Finney said with Bitcoin, if a clone was to overtake Bitcoin with no real merit it would erode all confidence in using crypto as a store of value.

Yes! I argue this on twitter almost every day. People who self-describe as crypto-currency supporters but who also push alt after alt are just serving to discredit the entire idea and add fuel to the criticisms levied by guys like Peter Schiff. It's infuriating.

Bytecoin had to be replaced, its release was immoral and deceptive. Monero then became the first fair launch of a CryptoNote coin.

Yup!

Now I will not support a coin to overtake monero unless its feature set was such that is was better and unable to be incorporated back into the monero core.

Nothing in any of the clones is better. When I'm talking about better, I'm talking about the jump from bitcoin to monero. I will support the next coin that has a similar jump. At the moment there aren't even any serious conceptual models for such a giant leap.
...

+1, totally agree. Refreshing to see someone with identical analysis. The first alt idea that I ever saw much merit in was Zerocoin, and it looks like CryptoNote has functionally beat it to the punch. It's the first actually meaningful feature-enhancement to bitcoin that likely will never be implemented natively within bitcoin. Thus, like you, I find myself interested in Monero as the first actually meaningful non-theoretical alt.

I see no chance of a boolberry takeover. If boolberry did takeover I would probably sell back into bitcoin because it would mean any cryptonote coin can be destroyed by a features for feature sake coin. Which is what boolberry and litecoin are. The proof of work. The alias. The tx modifications. It's just an attempt to differentiate for the sake of marketing.

It's litecoin all over again.

Again, well said. I've *hated* litecoin since it came out for exactly these reasons. LTC supporters have never understood the economic ramifications of what they're doing or why litecoin should or shouldn't have value. Thankfully I think LTC's days in the sun are more clearly numbered than ever, and a rational coin ecosystem is getting closer. The #2 coin *should* have meaningful functional differentiation from bitcoin.

[cAPSLOCK]

Again, well said. I've *hated* litecoin since it came out for exactly these reasons. LTC supporters have never understood the economic ramifications of what they're doing or why litecoin should or shouldn't have value. Thankfully I think LTC's days in the sun are more clearly numbered than ever, and a rational coin ecosystem is getting closer. The #2 coin *should* have meaningful functional differentiation from bitcoin.

One of the beautiful things about Cryptonote is the feature it offers is one Bitcoin should never offer, and the two ledgers will have distinct and complimentary uses.  The are not competitors per say but compliments.  Litecoin was touted as "silver to Bitcoin's gold"  A relationship which makes sense if you are talking about the metals, but not when you are talking about digital money.  Cryptonote is "night to Bitcoin's day".  And this is a relationship which is not only possible in cryptocurrency, but arguably imperative.

Now the race is on for which CN coin is the leader. 

Most of my money is on XMR. but to be honest I am glad there is competition, and I hope the devs can pull this thing off.

[devphp]

Now the race is on for which CN coin is the leader. 

Most of my money is on XMR. but to be honest I am glad there is competition, and I hope the devs can pull this thing off.

From my perspective, Fantomcoin has very good chances for survival as it can be merge-mined with all other CN coins without wasting additional power, hence potentially it will have the largest and most diversified mining network of them all.

[lebing]

Excellent posts guys about the comparison with Litecoin. Basically echoing my own thoughts. I am eerily reminded of the last time I felt so sure about investing in something...

On that note, if someone was an early buyer of Monero and wants to offload a large amount of coins without moving the price, pls pm me.