Author

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

legendary
Activity: 1722
Merit: 1004
June 25, 2014, 01:11:02 AM

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.

hero member
Activity: 976
Merit: 646
June 24, 2014, 09:41:17 PM
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
hero member
Activity: 976
Merit: 646
June 24, 2014, 08:28:53 PM
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 Wink

It's not. Smiley

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.
hero member
Activity: 976
Merit: 646
June 24, 2014, 07:59:02 PM
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
legendary
Activity: 1176
Merit: 1015
June 24, 2014, 07:58:28 PM
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 Wink

It's not. Smiley

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.
legendary
Activity: 1176
Merit: 1015
June 24, 2014, 07:50:46 PM
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. Smiley
legendary
Activity: 1484
Merit: 1005
June 24, 2014, 06:39:54 PM
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 220 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.

Quote
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.

Quote
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.
hero member
Activity: 976
Merit: 646
June 24, 2014, 06:20:56 PM
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 220 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.
legendary
Activity: 1624
Merit: 1008
June 24, 2014, 05:26:18 PM
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.
legendary
Activity: 1708
Merit: 1049
June 24, 2014, 05:01:44 PM
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.
legendary
Activity: 1498
Merit: 1000
June 24, 2014, 05:01:14 PM
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
legendary
Activity: 1484
Merit: 1005
June 24, 2014, 04:54:59 PM
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.
legendary
Activity: 1708
Merit: 1049
June 24, 2014, 04:49:18 PM
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.
legendary
Activity: 1484
Merit: 1005
June 24, 2014, 04:45:58 PM
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.
legendary
Activity: 1106
Merit: 1000
June 24, 2014, 04:39:07 PM
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  Smiley
legendary
Activity: 1708
Merit: 1049
June 24, 2014, 04:38:21 PM
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.
legendary
Activity: 1484
Merit: 1005
June 24, 2014, 04:09:25 PM
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.
legendary
Activity: 1484
Merit: 1005
June 24, 2014, 04:05:52 PM
Quote
Consider the instance in which a user uploads their alias, and someone sends them a small output, maybe 0.1 BBR.

Now, the person watches the blockchain for when this output is spent. If the user with the alias spends it in a tx with mixin=0, the user can now identify that the money has been spent, can assume any associated inputs belong to the spender, and can see where outputs are intended to go.

I couldn't help but notice that you have an XMR address in your signature.

It amounts to the same thing.  Public disclosure and reuse of an address coupled with mixin=0 respending allows (limited) tracing of spends in all of the cryptonote family.

The only real difference is that the address disclosed in the blockchain is completely public.  I believe that's the intent of the aliases, no?

But this is a fairly unimportant distinction in the grand scheme of things.  XMR could easily add aliases if they prove successful, BBR could probably rip them out, ... these don't strike me as a fundamental thing to bring to the debate.

Correct. I don't believe in sticking this information into the blockchain in arbitrary data appended to tx though, because I think it's bloat and creates races to spam the chain much like races to purchase domain names.
dga
hero member
Activity: 737
Merit: 511
June 24, 2014, 04:01:09 PM

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

Further, Boolberry's feature attaches identifier information to outputs which may be further used in analysis to identify spenders.

This is a nice feature in BBR. You don't need to use it at all. Alias name is just as anonymous as CryptoNote address. It can not be used to identify the sender if sender doesn't want to. Similarly, who knows Satoshi is?

Consider the instance in which a user uploads their alias, and someone sends them a small output, maybe 0.1 BBR.

Now, the person watches the blockchain for when this output is spent. If the user with the alias spends it in a tx with mixin=0, the user can now identify that the money has been spent, can assume any associated inputs belong to the spender, and can see where outputs are intended to go.

I couldn't help but notice that you have an XMR address in your signature.

It amounts to the same thing.  Public disclosure and reuse of an address coupled with mixin=0 respending allows (limited) tracing of spends in all of the cryptonote family.

The only real difference is that the address disclosed in the blockchain is completely public.  I believe that's the intent of the aliases, no?

But this is a fairly unimportant distinction in the grand scheme of things.  XMR could easily add aliases if they prove successful, BBR could probably rip them out, ... these don't strike me as a fundamental thing to bring to the debate.

legendary
Activity: 1484
Merit: 1005
June 24, 2014, 03:50:12 PM

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

Further, Boolberry's feature attaches identifier information to outputs which may be further used in analysis to identify spenders.

This is a nice feature in BBR. You don't need to use it at all. Alias name is just as anonymous as CryptoNote address. It can not be used to identify the sender if sender doesn't want to. Similarly, who knows Satoshi is?

Consider the instance in which a user uploads their alias, and someone sends them a small output, maybe 0.1 BBR.

Now, the person watches the blockchain for when this output is spent. If the user with the alias spends it in a tx with mixin=0, the user can now identify that the money has been spent, can assume any associated inputs belong to the spender, and can see where outputs are intended to go.
Jump to: