Topic: More Bitshares Greed - page 2. (Read 12249 times)

The title got be kidding.

Uhhhhm, If I run a Ripple node whether I process 1,000,000 transactions or 1, the fees paid to me will be exactly 0.  Yes, people making a transaction have to spend a fee, but those fees are all burnt and do not go back to the nodes.  So yes, there is at least one way to make a blockchain run without someone being paid directly to validate blocks on a per transaction or per block rate.  As CfB mentioned hashcash is another.  I also know a dev that has been working on a third model where no fees are paid, but instead people running nodes will get special privileges in the system that others won't.  One who isn't just thinking about money all the time just need open their mind to find lots of possibilities.  Here is an example.  Lets say I am running an anon coin.  I can make a rule that only a node that has been active on the network for the last 24 hours can actually send anon transactions, all other nodes on the network less than 24 hours can of course still send and receive, but can't send anonymously. Here is another example, lets say I run a network and anybody that has been running a node for 24 hours will get 10 tokens.  Each transaction costs exactly 1 token.  All tokens are non-transferable.  So now to use the blockchain a person needs to run their node every once in a while for 24 hours and then they get 10 free transactions. I call that proof-of-participation. It is fairly easy to design a system that isn't just focused on money.  

You should adjust numbers a little. I would change 80 to 67, in this case cost of double-spending will be equal to cost of network disruption. Humans can see the flags and open Twitter or BitsharesTalk to get more info, DACs don't have these means of communication. If DACs stop functioning when less than 80 delegates are working then 22 rogue delegates can easily break business processes controlled by DACs.

Yes, our documentation is always lagging behind the wavefront of progress.  If it ever catches up that means we've stopped progressing, I guess.  

Fact is, when all delegates are participating they each have uniformly less than 1%.

The only way to get more than that is to have delegates start dropping out.

If we go below 90 delegates, the yellow "caution flag" comes out on all wallets warning users to trade with caution.
If we go below 80 delegates, the red flag comes on warning users to stop trading.

This also alerts the remaining delegates (many of whom are developers) that there is a problem that may need to be worked out by the various fall-back consensus mechanisms that we have been talking about.

I'll have to give the rating grinding concept a little more thought. 
Thanks for helping out in the what-if department.

I interpreted 2% vote limit as a way to force stakeholders to vote for at least 50 delegates. If it means that none of the delegates is allowed to generate more than 2% of blocks then the attack above will lead to exclusion of 33% of legit delegates and 33% of rogue delegates from block generation process (because they can't sign another chain if they already signed the attacker's one). And this leads to worse consequences. The attackers may get more than 33% of slots in the next top 66 delegates that will replace current leaders (assuming that it's easier to be in top 200 than in top 100).


Edit:

Such "rating grinding" attack (when rogue delegates commit suicide and force some honest delegates to be excluded too) is a neat feature for attackers. In this case no need to have 33 delegates, N attackers can be fired together with N+M honest delegates (the same way as 51% attack can be conducted with less than 51% of hashing power). Repeating this process the attackers may slowly increase percentage of occupied slots... Note that I don't know BitShares internals very well, if someone explained the process of firing of delegates it would help to assess how feasible "rating grinding" is.

Come-from-Beyond, I think some of that may be outdated, describing an older version of DPOS. Specifically,


I could be somehow mistaken, but this does not seem to be the case.

I was bored and decided to get the answer by myself. I based my analysis on information from http://bitshares.org/documentation/group__dpos.html and came to a conclusion that our case is this:

We can lower requirement on the number of honest delegates from 67 to 51 if we add an extra assumption that blocks reach all the delegates within 10 sec (it's equal to block gap in BitShares). Another way is to change how we choose the best chain, instead of plain "longest chain is the best" some kind of weighing is required, but I don't have a good suggestion yet.

This is how I "attacked" the system:
1. Rogue nodes colluded and didn't extend blockchain if the last block belonged to a delegate outside of their group.
2. I assumed that every honest delegate had 50% chance to get a block from a rogue delegate and the same chance to get a block from a honest one.
3. Latency varied from 0 to infinity.

PS: Using something else instead of "longest chain is the best" is a better approach than adding assumptions on latency. In this case the system will be less vulnerable to an eclipse attack.

Your words reminded me that I was going to read "Animal Farm" by Orwell...

Bloat is a legitimate short term criticism of XMR; however bloat is inherent in ring signature technologies. So basically it would occur in any Cryptonote. The argument is that bloat will become irrelevant because of advances in technology will make the cost of data storage, data transmission, memory etc., even more trivial than today. For example for an extra 15 CAD a month I get unlimited upload and download data on my Internet connection. This would have been unheard of as recently as 2008 when Bitcoin was created. A good analogy is credit cards. When American Express and Diner's club introduced credit cards in the 1950's the data processing technology of the time, tabulating machines and punch cards, could handle only a minuscule percentage of the credit card transaction volume of today. It was only in the 1970's with the advent of the mainframe computer that credit cards became viable as a mass consumer product. As for Monero over other cryptonotes it has the largest market cap and none of the controversy surrounding Bytecoin. Comparing Monero to Bytecoin is like comparing Litecoin to Tenebrix.

I like Namecoin because it provides a viable decentralized alternative to the ICANN DNS secured by the Bitcoin proof of work via merged mining. It is also used by the OpenAlias project, https://openalias.org/, started by the XMR developers.

I like Monero's anonymity but dislike the amount of Bloat created, I mentioned Cryptonote over Monero due to liking the underlying idea of the tech over the specific Coin. Why NameCoin? I haven't heard anything on NameCoin in forever.

The more I look at proof of stake the more I see banks and wall street under a different name. Something tells me the regulators will eventually reach the same conclusion. So I will stick to proof of work coins. If one wants to diversify into proof of stake one can always buy shares in a bank. I like XBT, XMR and NMC right now.

Arguing about which is better, NXt, Bitshares or Nubits/Nushares?

I like all of them! and I also like BlackCoin, HoboNickels, PeerCoin, ShadowCoin, PandaCoin, CryptoNote, and even DogeCoin!

Some are more profitable in the long-run than others, a Coin can have good tech or do good things but still be a bad investment. Only way to really tell if something is going to work long-term is to run with it in a live environment, no theory can match actual market conditions.

That's an excellent example of an ad-hoc design that doesn't really have an elegant closed form solution.
When you fire the gun there was an annoying tendency to pitch up.
So some clever engineer figured out a little ad-hoc cross-feed to deflect the elevator channel to compensate.

This would be comparable to us tweaking the market rules to require speculators to cover their shorts within 30 days in order to aid liquidity for sellers of bitUSD in a young market.

There are dozens of such examples that can only be tested in live action.  Just like you never really know how that artificial heart is gonna work till you try in on a real person - or what's going to really happen when you fire the Apollo's third stage engine for trans-lunar injection.

Agreed!  We're all just having fun here.

Crypto is a rapidly advancing field and there are many paths to success.  I would never want to discourage someone from trying to make an advancement that benefits everyone.  (I remember Copernicus and Galileo had a little trouble with that nonsense about the earth revolving around the sun.)

As I've said before - Our challenge is who can put together a reliable system that customers like and that provides a profitable return for investors.  There is room for many such systems.   Other's seek systems that meet other philosophical objectives.

So we all don't even have the same objectives - how can we expect us to agree on a single solution?

In school we argued over whether electrical engineers or mechanical engineers were the Highest Life Form.

 

I'd like to have 'Gun Compensation' built into NXT, actually.



Stan,  if you get a moment.......

On the question of 'better' tech.....this is something that only time and exposure to the real world can truly decide.
No matter how tightly engineered, mistakes and exploits are always going to be present in any new code.


 

Why do you think you have to chose one or the other? Sorry, I changed my mind  I'm not that interested in the answer.

Every step of the design and development and testing process has been an open book and subject to intense scrutiny at bitsharestalk.org.  We take the aerospace industry approach not the ivory tower approach.

Warnings about the developmental nature of the product are present in the software agreement everyone approves when they first load the software.  Similar warnings are permanently pinned to the top of the General Discussion thread at bitsharestalk.org.

I would rather fly in an aircraft designed by engineer than a theoretician, but that's just me. 

Since this is way of topic, I changed the title to better reflect my sentiment and the preceding posts.

Unless you want run the risk of some seriously p!ssed people later on, it may be wise to inform your investors that this is the approach you take in crypto.

Then they can't say that you didn't warn them.

Indeed, modeling is a key component.

Here is a picture of a very small portion of the F-16C flight control system.  I spent a lot of time modeling it myself.


I can assure you that every gain, filter, and look-up table function was derived empirically by adapting earlier working designs, modeling them with experimentally determined wind tunnel data, observing the results, tweaking the design to remove undesirable artifacts, dropping in ad-hoc feedback loops and gain schedules, and iterating with tens of thousands of hours of simulations until everything was tuned up just right for first flight.

Over the next several years of flight testing, more and more experimental results were collected as the flight envelope was gradually expanded.  More and more ad-hoc experimentally derived changes and upgrades were introduced to tune the system.

In the history of manned flight I have never seen a Flight Readiness Review Board say, "Sorry son, you ain't a flyin' that thing until you get me a scholarly paper with an elegant closed form mathematical proof that fits on a single sheet of paper and has reached consensus on at least three different internet forums."