Topic: BitBay OFFICIAL BITBAY Thread Smart Contracts Decentralized Markets Rolling Peg - page 53. (Read 541982 times)

Hi all. We've now heard back from OEX.com that our new listing date will be the 14th February. They will announce it in their channels nearer the date, but I wanted to let you all know that it's been confirmed by them.

I'll post more info as soon as we have it.

Thanks,
Shorn.

The OEX delay is just another bump in the road.
We're in a bear market.

This low price really sucks bad.
ALL of crypto's really low prices suck bad right now. lol

Bay is still the most undervalued coin on the planet in my opinion.
Everything is working and ready to populate.

Here is another good example of why Bay is a really great potential store of value:
https://bitbay.market/blog/how-does-cryptocurrency-mining-work

We have had notification from OEX that their listing queue currently has a backlog which means we are waiting to hear about the new date for listing BAY.

As soon as I have an update I'll post it here, hopefully it will only be a short delay.

Thanks,
Shorn.

Excellent response! And there is more information on our website and forums as well.

With the Dynamic Peg, BAY is not pegged to any currency or asset at all. It's one coin, that has multiple levels of liquidity (spending power) within it.

It can best be described through an analogy.

Imagine there is a group of thirsty people, and in front of them is a water vending machine. This vending machine can quickly turn liquid water into ice, and vice versa.

7 times a day, this group casts a vote to express their level of thirst. Based on the consensus of each voting session, the machine releases (or freezes) a specific amount (1-3%) of water, leaving an amount closer to what everyone wants to drink.

If demand falls and water freezes, then there is less liquid to drink. This puts upward price pressure on of liquid water.
If demand increases and water unfreezes, there is more liquid to drink. This puts downward price pressure on liquid water.

So the price of liquid water becomes stable, in relation to the amount needed by the group. People's level of thirst is always changing, and the price can change right along with it.

--

BitBay's Dynamic Peg is this water vending machine, but for money... and the group of people voting are all the stakers of BitBay's blockchain.

It moves towards a liquid price that everyone agrees on, and the rest is frozen for later. The frozen BAY can then be traded on a secondary market, based on a future speculative value.

Because it is democratic, there is no need to peg it to an asset or fix it to a price. The total supply is controlled by the users themselves, and not a central entity. History has shown how price fixing and hard currency pegs always fail under extreme market pressure. Because it's not pegged, there is no need for auditing reserves (like tether, gemeni, circle, etc.), or trying to keep a hard price ($1) when the market chooses otherwise... like most other stablecoins.

Instead the dynamic peg allows the price to move and adapt with market swings, within refined limits. It reduces (but doesn't eliminate) volatility to the point where people can use BAY as both a store of value, and a medium of exchange. This allows the users of BitBay's marketplace to have a stable form of value when using BAY as a deposit for its P2P contracts.

ps: if a user doesn't want to vote, they can opt to have an algorithm vote for them  

Can anyone ELI5 me on Dynamic PEG? I don't understand what it is and on which currency BAY will be pegged to...or if there is another coin running on BitBay which the pegged one

OEX is a big one. Congrats!
...And they only have 14 Markets? Bittrex (a great exchange) has 305.
I think that makes Bay kinda special!

A lot of hard work has gone into this project.
...it's only a matter of time before BitBay hits critical mass - it's not "if", but "when"?

Yes. It will be triggered once we have the exchanges on board. So first we release/test demo exchange(so we have an example they will understand), wait for exchanges to implement, fork.

Can someone explain the Hard Fork that is coming up?

Does this happen because of the Peg implementation?

The BitBay 2019 development roadmap is live now, with a brand new layout we think you'll find easier to follow. The Dynamic Peg and web markets are still our main focus but there’s also a lot more coming… check it out now

https://bitbay.market/roadmap

Shorn | Project Manager

I just sent you a pm to get you on slack

Well there is a Slack and Telegram. I'm usually on Slack. You can visit our site at bitbay.market and request an invite there or here.

I'm currently in 12-step rehab for recovering nerds.

Is there a better venue for this discussion such as Slack or Telegram?

Yes exactly POW prevents DDOS but the problem is it needs to be easy enough for consumer grade computers and hard enough for strong computers.
So it doesn't really stop an attack it just makes it a bit more cumbersome.

One solution I've had for years (although you can argue it does sacrifice a little bit of anonymity) is to require a user to tie up funds for X time.
This solution is simple and because you can charge X coins per kilobyte. Since the funds are only tied up for a few blocks it's a good way to say
"sending a message will cost you a couple dollars but you get it back in a few minutes". You are right in thinking a whale can attack this as they
don't lose money, they just tie it up. But perhaps you can keep increasing cost or lock time for related addresses. They can get around that too
by having a lot of addresses. I would say for now there is no perfect solution but it's a solution that allows for Bitmessage to be faster because POW
can take up to 10 minutes on slow computers sometimes.

The only issue with it is it creates a mild barrier to entry (user would need funds or have to fall back on POW) so I haven't really bothered to code it. Also other nodes in Bitmessage won't acknowledge the messages and for user security I prefer to be part of the larger network with more nodes.

I guess as long as POW serves as a deterrent (most people won't attack a network unless there is profit involved) then it's good to protect Bitmessage for now until we see someone even attempt it. And besides, Halo has backup messaging options so a prepared user won't be too affected.

I still also really like using Bitmessage to make accounts anonymous by having someone else broadcast (getting rid of the IP address issue altogether). It's still unclear if having control of a lot of nodes can help someone guess who is sending a message.

I guess Bitmessage POW is in place to prevent sybil attacks or not?
How would that other method "proof of time locked funds" work?
How would that prevent a whale to attack the network?

Ahh that interview. That's nice to hear you read it, that was a fun one. What I mean by self-regulating is fully decentralized. Basically the code I wrote was meant to be P2P and not modular. So to convert all of the code to JS even with a tool wouldn't work for web. Basically the Bitmessage network, the business logic and other things would prevent that from working. Bitmessage isn't very phone friendly. The team of coders has so far done a partial refactor of Halo code, they converted my Python peg logic to c++ and launched testnet, they started to code a demo of the markets with double deposit escrow. We do work on a tight budget with the bear market and all though so it's unclear if we will get the web/phone market where I envisioned it by spring or summer.

The model they set up is server based and that can not be used as a working product, only a demo. The downloadable software is already fully functional. The method I want and proposed for web is like this:

Markets go direct to IP routed from main site, peers form a master/slave group
Peers run "servers" voluntarily like docker nodes and receive signed/encrypted data from front end
Thus, the server cannot delete info before it's header expiry (no data is permanent but much is persistent)
If server breaks rules(deleting singed/encrypted data or making it illegible), the other peers replace by consensus with electing new master in list
Thus ALL web logic is client side. Clients may even check txid values on sites like chainz and our own nodes to ensure it's all correct

The current model is not that, it's just where all data goes to servers that don't process any client stuff but do centralize the market data.

The BitBay/Halo software is fully decentralized from the contracts, double deposit, bitmessage, no servers, etc. So the goal is to get the web markets to do
that. Peers must host data, that's the only proper way to shift liability away from third parties and secure users.

I don't think they use chrome extensions, just standard crypto JS libraries.

The system I want to build for WebHalo will be compatible with Desktop app because nodes will read Bitmessage for main markets and post on web (relay)
and then to communicate back both Halo and Web will know they must deal with the Web logic. Bitmessage then would only be for posting to desktop only.

Bitmessage has shown itself to be very secure. Although I've not audited all the code, the main concepts are solid. Peers encrypt and only decrypt what they
hold a key for. Channels are shared keys. Messages bounce from group to group hiding sender. Even if a sender could be correlated assuming a person
had many, many nodes it's still hard to say they are involved in enough groups to know that node is the original sender.

More importantly, encrypted messages which are channels gives plausible deniability that you can just say you aren't able to read the traffic even if you
forward it. It's very strong. Unlike TOR when it accesses unencrypted pages which means entry and exit nodes are more volatile, Bitmessage is encrypted end to end meaning no clearnet traffic is found by ISP. It's not perfect, but I think it's the best we have out there. Plus there is NO SERVERS! This is so superior to hosting an onion site in my opinion which in theory might eventually be uncovered by an ISP.

Lack of servers is the end goal to serving censorship resistant, peer to peer data. I feel Bitmessage is headed in the right direction despite the bulky POW which
can be replaced anyways with other methods such as proof you time locked funds.

We have a lot of help boxes in the code, there is some sparse documentation which is somewhat old it would be nice for someone with the technical expertise
to document all the software and code but I'm pretty much focused on looking forward for now.

I take it you are a coder or something?

Thank you for getting back so fast, I know how busy you are. My motivation for the post was your interview with Leah Zitter when she asked, "What do you want BitBay to accomplish this coming year?" You replied, "and best case scenario get some coders to work on a web based version of Halo. But the web version may not happen if the project doesn't become self-regulating. I want to focus on realistic short term goals."

This led me to believe you were dealing with limited coding resources. I was thinking there might be a fast, simple way to get the web version out. I just took a look on BitBay's site and saw you already have a full-stack JS coder (Slava) as well as several other coders, so it seems you have the bandwidth to do a complete re-write. Good on you.

The packages you mentioned (Linux and Mac) are stand-alone desktop apps. I was focusing on the web version. I was thinking WebHalo was going to be server-hosted site with the server handling all storage and socket I/O. That's why I used the terms client and server.

Now it appears you will be using a (Chrome at first?) extension to be the UI for the desktop apps. Right? The extension has full r/w access to all system storage and socket I/O. So the WebHalo extension will be able to create UDP/TCP sockets with arbitrary addresses. In fact, it will share fully equivalent functionality with the desktop apps without connecting to any host. Right?

The BitHalo is in Py2. If you were strapped for resources, you could use Transcrypt to transpile the Py to JS. Transcrypt requires Py3 as input. But then you would still have to handle the PyQt calls in some manner. But none of this is necessary since you have already coded it from scratch.

What did you mean when you said "self-regulating"? Kind of like an open source project that requires minimum input by the main author?

Bitmessage has not had a full-blown security audit. Do you view that as a concern? Do you think Loki is worth looking into?

I'm trying to get up to speed technically, but as in many other projects extensive documentation is the last step.

Disclaimer: All too often "piece of cake" transpiles to "kiss of death".

BitHalo has no server. Neither does Bitbay. The software is decentralized P2P run on top of Bitmessage. The contracts are double deposit escrow so nothing is
hosted and it's not possible to defraud the counter-party. The code is Python 2.7 and I didn't upgrade to Python 3 but that would be possible to do. It wasn't
necessary. It does work on Linux and Mac. There is something with Linux that seems to be an update or something that doesn't work with Pyelliptic so maybe that package should be updated with the newer version of Bitmessage.

Much obliged.