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

Or you might simply accept that we are working on different things because our priorities are simply different at the moment.
Feel free to read the missives, they communicate pretty clear on what we work and why we do that.
Like working together with Anoncoin on the i2pdaemon c implementation (https://sigterm.no/blog/30/), man power is important.


Yeah you did, and its yet to be seen what happens if the bbr scratchpad grows to a few hundred mbs and every miner on every pool has to download the scratchpad and that may result in a nice accidental ddos.



Read the missives, that code is currently beeing rewritten, thats one example of stuff we prefer to work on.


PS: It's pretty lame to diss us with features we don´t agree on technically.

I suppose rather than joining Monero, you'd rather be independent so you can continue to test out your ideas for superior design. Competition is good. But it is clear that you are focused on coding, not on marketing and product strategy.

You need someone in your community to step up, who is good at the latter job and can put sufficient effort into it. I edited my prior post about this point, e.g. it is difficult to rave about your PoW hash until it has been properly vetted and your marketing makes it clear this has been done.

At this point, you need to use your PoW hash (since it is your only potential extremely compelling feature improvement that isn't trivially copyable by Monero) to rally other developers and community to your aid so you can compete with the manpower Monero has applied to refining the Cryptonote code base (even if you are copying each other's commits, you still need manpower to evaluate and sieve them). So you could focus on proving your PoW is secure and or fixing it to resolve any analyzed weakness.

I guess if it will still be verified (once) - you will still meet the same problem - long PoW check... or did i miss something ?



With all respect to you smooth, I doubt that it's true.
Based on my knowlage of protocol, i can say that clients while downloading the blockchain automatically switch to some other nodes if it's do response faster. So even if you have few overloaded nodes than newcomers will switch to another nodes that have faster response. You can see this in src\currency_protocol\currency_protocol_handler.inl:
Close to this line:

But. Even it is true and you really faced that some nodes was overloaded - the hosted blockchain is still centralized and still bad solution. I would prefer to improve protocol to have spread bandwith over the nodes.
Just my opinion. As dev to dev.

 

What did I state above that is wrong?

You don't prune the blockchain, which is a potentially exponential savings. I was correct. You only discard a constant percentage amount of data. Amdal's law applied to data size applies.

The product and marketing strategy is a mess, because for example you misuse the term 'prune' from its accepted meaning for Bitcoin. Whose fault is the misunderstanding?

And the entropy of the PoW hash has not been cryptanalyzed? Yes or no?

Zoidberg I have seen your developer stereotype many times in my career. Prodigious coder. You think a few minor relevance or irrelevant (and perhaps even incorrect) optimizations makes a product strategy. This is why you can not be a product manager for commercial software project.

Edit: if the PoW hash is analyzed (and fixed if required) and can be relied upon, then the speed up is not a minor relevance. But I don't know yet if that analysis has been done? I don't have time to go reading all the threads on all the altcoins. Your marketing has to get this information out front and center.

Obviously english is not your primary language. Your community needs to aid you. This is the point the Monero proponents are making. You can't do it all alone.

I was readed the history and just curious, how people could make such conclusions without even understanding technology and what have done with that... ? This is sad to read this.

The only thing that was actually evaluated is the project name i guess.

I'd even prefer the name Zoid over Boolberry, but Sieve I like better for the moment.

Others:

Boolzoid
Boolseye

Unfortunately none of my ideas nor Boolberry sound like money, but maybe that is okay if the name is catchy and doesn't have negative connotations (e.g. blue balls).

I didn't elevate it to my comparison list summary yet, because I am not sure this new PoW hash is not trivially preimageable. I would like to see some analysis of that first. This PoW design is a radical departure from the way any hash has been done in the past, thus it needs to be treated with extra caution.

Zoidberg this is what I mean by unless your feature advantages are unequivocally compelling, then being the loner has the effect of being the "odd man out".

I favor being the loner when I think I can out innovate a group which is preoccupied on issues that I think I can eliminate. But you have not eliminated the issues they are working on? And they have more manpower to apply?

Two minor technical corrections:

1. The centralization aspect of this will likely be removed at some point, as done by bitcoin. The static blockchain will still be verified (once).

2. The primary reason for a static blockchain download is not PoW verification, it is to reduce load on the p2p. Relatively few p2p nodes are accessible for incoming connections, so the ones that are get hammered very hard by new nodes connecting and downloading the block chain. Periods of rapid adoption are the worst, because there are so many new users downloading the block chain. We encourage (and spend money to host) the static downloads to reduce the load on existing nodes. High load in turn leads to fewer people being willing to operate accessible nodes, which makes matters even worse on the ones who do.

Seriously I respect you, but you must cut the crap. You're project is not the most technically superior CN coin. The Monero team are so busy trying to get the ram and ledger size on disk sorted out and fix the bandwidth QOS that they haven't moved onto these areas you went for first.

One of the reasons people are not following some of your design considerations is that they are questionable in their actual utility. Time will tell.

This is one that's worth elevating into the "strengths of BBR" list.  I'm possibly overly-sensitive to it because I end up re-synchronizing both my XMR and BBR blockchains frequently due to excessive poking at things, but it really is true that I'm willing to start up the BBR daemon from a fresh build and let it sync over the network, whereas with XMR (or, heaven forbid, BCN), you're pretty dead in the water if you don't download the blockchain first from a (quasi-central) source.

Speaking specifically of XMR, this seems to arise because of:

(a)  1 minute block times leads to more cryptonight-style verification (CPU);
(b)  Early dust transactions from pools and people trying "big blockchain stuffing" attacks led to artificially large transactions and transaction volume in the early days (CPU and bandwidth);
(c)  CryptoNight is a comparatively expensive hash to evaluate (perhaps 20ms on a good CPU), and the daemon is, I believe, still single-threaded when it comes to handling the blockchain verification.  That means maybe 50 blocks/second, or roughly 30 seconds of single-core CPU time per day of the blockchain. (CPU)
(d)  Overall blockchain size from ring signatures, mixins, etc. (bandwidth)

Some of these, such as multithreading parts of the blockchain verification, can probably be fixed with "just engineering".  Others, such as the early transaction dust and DoS attacks, are hopefully a one-time artifact.

(c) and (d) are the most interesting in a longer-term sense, because (d) will increase with transaction size, and the total amount of time spent doing (c) grows linearly over time as the number of blocks in the chain grows.

The technically strong devs respect each other and will gravitate towards the winning technical solution. In theory every technically strong and extremely productive dev can be sufficiently rewarded with bounties, because the market is gargantuan if we solve the scaling problems and there is a lot to work on. I am sure most of us would love to work on changing the fundamental structure of the internet to turn back the corporate fascist takeover, e.g. facebook, google, yahoo. This we can fund from the coin that can scale.

Some silly name brainstorming off the top of my head:

Zoidberry
Mixberry
Moolaberry
Zeroberry
Nullberry
Moberry
Sieve <-- probably the best name I've thought of recently.


My concern is this data is not any where near even 2^128 in entropy.

You can reduce the number of computed random lookups using this block chain header entropy, but my intuitive guess is you can't safely eliminate all the computation which increases the apparent (i.e. easily knowable without cryptanalysis attack) entropy via confusion and diffusion[1]. So I think you need to reintroduce some computed lookups and only replace some of the computed lookups with the block header entropy. However, I haven't studied your PoW source code, so it might already apply confusion and diffusion to the block header input entropy.

[1] http://en.wikipedia.org/wiki/Confusion_and_diffusion
     http://www.theamazingking.com/crypto-block.php

Wait what? 2) you're claiming claymore is a Bytecoin Dev? What are you basing that on? Can I see some proof?

As far as I can tell he's just a talented programmer that wants to make money. I don't agree with his tactics but no way does this qualify Monero as a premine. This FUD campaign is so lame. Try again.

At first - thank you for your interest to our poject.

I agree with you - it is not pruning transactions, and we newer claimed that we do it (This is strange that Monero devs was not explained this to you since they said that they closely examined all Boolberry features.   )
But there was still possible to reduce a bigger part of transaction's body - and i did that, since it was best that i could do with CryptoNote blockchain bloat.


Boolberry is not perfect, sure. Every coin have practical problems. But this is obviously that our project is technically stronger than any other CN coin, despite "significant team of devs with Monero". (nothing personal - i still like a few pretty nice persons from Monero )

We don't use the whole header's data since it obviously not all of it is pseudo-random. For adding to scratchpad i use only:
* prev block id
* coin-base transaction's onetime key
* coinbase transaction's outs keys (xored with prev_id)
* blocks merkle hash
So i took only that data that seems to be maximum close to random.
(take a look into get_block_scratchpad_addendum(const block& b, std::vector& res) in src\currency_core\currency_format_utils.cpp: line 868)

upd:
PoW is changed because oroginal CN PoW is extremely slow, even with optimizations. Now, with that slow hash Bytecoin, Monero and others have to provide a link for downloading blockchain file instead of loading this from network cloud, tha's actually a real centralization.
In Boolberry we have 5-times faster synchronization and don't need to centralized blockchain file preloading.

Zoidberg

I've heard this criticism. And raised the issue in a Monero thread.

Hello Zoidberg. I apologize I thought you were attempting to prune the blockchain of transaction records which are spent— which both I and at least fluffypony think is impossible.

Now I see the details of your solution, which is discarding the ring signature proofs bloat, but retaining all transaction history. This indeed will work fine.

However, this is not pruning the blockchain, rather is just a constant size reduction in the bloat, thus it still won't scale to Visa scale because even Bitcoin wouldn't scale to Visa scale without pruning transaction history (or implementing the mini blockchain which also discards transaction history more efficiently). To reach Visa scale without mining centralization, appears to require transaction history pruning (at current hard disk size, and for the UXTO also memory size or SSD is a factor).

There is confusion over what the term 'pruning' means in this context of the blockchain. You are discarding some of the data from each transaction record (specifically the ring signatures proof), but you are not pruning the transaction history (because it is impossible or impractical).

I will update my upthread summary of top anonymity coins to note your advantage. But note your advantage doesn't really solve the scaling problem of one-time ring signatures. Thus I can't insure the mention of Boolberry will be sticky (for long) as the summary is edited by the community.

When I said my enthusiam waned, I didn't mean to imply that you are not a capable programmer, because obviously you are. I meant that you are picking features to implement which don't really achieve the necessary level of functionality to unequivocally pull out in front of the rest of the coins. But I don't fault you for this, because most everyone else can't figure it out either. It is just that you are up against apparently a significant team of devs with Monero. I am not saying you couldn't pull a radical innovation out of your hat— anything is possible. Seriously consider renaming your coin. Perhaps rpietila still owns StealthCoin, which I gifted to him in early 2013 and can offer it to you to show his goodwill?

About your PoW hash, I am concerned there isn't enough entropy on the blockchain headers to prevent some trivial preimaging. I haven't had time to think deeply about it though, so no one should quote my concern as any thing more than an intuitive guess.

P.S. I never wrote that the ideal team size is 1 or 2 for all scenarios. Rather I said that for raw innovation, the ideal is 1 or 2 and for refinement via open source, the core team size should be larger (with hopefully a Benevolent Dictator to keep innovation from being stifled by consensus gridlock or chaos) and the community of eyeballs should be unbounded.

Shelby

This is a valid point.

What was the last invention that was as profoundly novel as Satoshi's invention of a scarce information good?

I don't know, they are very few and far between.