Topic: [PRE-ANN] +++ HUB: +++ - page 2. (Read 2412 times)

HUB:
+++          Token Creation Revisited          +++

The token creation is the crucial part and the one where most things can go wrong. Once a secure way to create tokens is established, the rest shouldn’t be too hard.

As mentioned before, there are two ways to store bitcoin: as a pool or in a wallet per token.

I think the logical approach would be to create an address per token. Having a pool has a lot of disadvantages over separate addresses.

However, there are some disadvantages that come along using single addresses as well. Probably the biggest one are small tokens. For one, cashing out a small token may cost more transaction fees than they are worth. At the same time, small tokens may be needed for paying accurately.
A possible solution may be to have pools for small tokens: since these pools are relatively small and the tokens themselves are small as well, attacking these pools doesn’t lead to much gains, while losing a few cents worth of bitcoin on the other hand isn’t a big loss. Additionally, these pools are relatively easy to monitor.

Once a user wants to cash out some small tokens, they can collect tokens that belong to the same pool, making the cash out a single transaction, minimizing transaction fees.

However, this may be a too complex process for regular users. At the same time, the concept of fixed value tokens, the imitation of cash money in a digital environment, in which everything should be scalable, itself looks like a weird, outdated concept.

In commercial circles, the custodians may decide to have an auto-change system in place, which would make the limited scalability almost invisible for regular users.

Token should come with some kind of expiration date. If we apply an approach in which a number of users hold the private keys, the danger of all of them getting offline or losing the keys gets bigger over time. Therefore, it would be prudent to have tokens just as long as needed, although it is very convenient to have tokens ready. There has to be a middle ground for this, or, a solution in which the custodians are not needed to access the funds. A smart contract may make this possible: once a token is created, the custodians write the corresponding private keys into a smart contract that is automatically triggered when the token is sent to the burn address.

make it a zcash fork

Zhub

HUB:
+++          Trust          +++

I think completely trustless systems are overrated. It may sound weird, writing this and at the same time working on blockchain technology, since trustlessness seems to be one of the holy grails of blockchain technology. I’m not saying that we don’t need preventive means in place, but if we look closer, we see that absolute trustlessness can’t be achieved. Why? Because in a transaction, there are, most of the time, two things that are exchanged. If I buy something using bitcoin, I get a product. While the bitcoin transaction may be trustless, the sending of the product isn’t and there is no way to ensure that it is, other than punishing misbehavior. Even if I use an escrow, both I and the seller have to trust the escrow. This is true for most transactions, and definitely true for all transactions that involve a physical product or service.

So, what I am working on is a system, that still needs trust, but distributes this trust over a number of users. Only if a critical mass of users decides to work together, or a single user somehow manages to impersonate enough users, the system can be broken.


HUB:
+++          Trust, Identity and Reputation Revisited          +++

The reputation system used will be somewhat similar to the friends system, Facebook uses: A user can earn trust from other users.

Let’s say, Brian, David, Anne and Emily are users. David can set a mark, that says “I trust Emily”.

Brian doesn't know Emily and had no dealings with her, but he knows David and has set a mark that says “I trust David”. Thus, Emily has some amount of reputation for him, albeit not as much as David has, whom he trusts directly.

Anne has no trust marks set for David, Emily or Brian, so to her none of them has any amount of trust.

This has two implications:

Users can't generate hundreds of accounts to boost their trust. Well, they can, but it will lead to nothing, since the amount of trust is not relevant for users they are not connected with. Even if users manage to gain trust from a single or a few other users, their reputation only raises a bit, since being interconnected outweighs trust marks by a big number of users with few connections.

This can lead to the formation of “trust bubbles”, isolated groups, which share none or only few connections. While this sounds like a problem, I doubt that it’s going to be a big problem, if it is a problem at all. I believe a likely scenario will be, that some users will be generally trusted by the community and that these users will act as “bridges”: A user can check if one of those users is part of a trust bubble. If there is one or more, they can decide to deem members of this bubble as trustworthy, by setting trust marks.

While the HUB: reputation system has no negative trust per se, trust can be withdrawn. An account without trust is useless, as is an account with trust from users that are not trusted themselves.

In case we need nodes (which may be needed to ensure, that external data is stored somewhere), we could have a system in place, which requires users to validate accounts. To do so, a user has to buy a validation code from at least three nodes. The user uses these codes to validate their account, which at the same time sets a base level of trust. Other users can see that the account has been validated and which nodes signed for it (nodes can be trusted or not, just like regular users).


HUB:
+++          Nodes          +++

I am not sure yet, whether nodes are needed in the first place. If they are, they have two main jobs: they are the ones ensuring that external data is stored somewhere and check whether this data is correct (it is sent to them by custodians) and they are the ones signing new accounts (see “Trust, Identity and Reputation Revisited”).
Additionally, they will be most likely be asked to escrow certain deals or serve as custodians for some circles. This may give node operators some kind of income.
Interestingly, the trust system set in place may render the use of nodes redundant: A user may safe things like trust settings on their own, so there is no need for a certain entity to safe this data. If a user removes trust settings by deleting them, other users may retaliate by removing their trust settings. This would force users to keep their trust settings and keep them accessible from time to time. Thus, by utilizing the trust system, users can be punished or rewarded for providing storage space for external data.
If a user wants to validate a new account, they may do so by buying initial trust settings from other users. I believe, that some users will stand out as exceptionally trustworthy anyway, so earning trust marks from them will almost be a requirement anyway. These users may charge others for it. This would mean that a dedicated node system is not needed.

Is there a danger of nodes (or users who effectively act as such) becoming too powerful?

I don’t think so. Nodes require reputation just as much as normal users do. You could say, that a node is just a regular user, who is more interconnected than other users. If a node operator would try to abuse their powers, users will withdraw their trust marks, stripping the node operator of their power.


HUB:
+++          Marketplace          +++

Since there already is a reputation system in place, it would be only logical to enhance the HUB: idea to include a marketplace. This won't be my main focus, but it would be very interesting and convenient to create one.

A token is created when it is needed. Think of it as an envelope: when you need a token, you put an amount of bitcoin into the envelope and use it instead.


Thanks

But really, there are still a lot of open questions:

- How are the tokens created exactly? Who holds the privkeys?
- How exactly are tokens transferred between two circles?
- How do you prevent spamming the network with a bunch of small tokens?

These are just out of the top of my head. And these are make or break questions: Without satisfying answers, this project won't fly.

no ico and no mining how do you distribution the coin  well,  very curious
 the idea looks good

It's already quite complete for me, and all of your thoughts seems to be rational and make sense.
I like to call it all in one. A lot of taste in one pack.

Good luck with your project, I think you have a good idea here and should solicit some of the better DEVs on this site.

Yeah, writing it on Ethereum was one of my thoughts. However, there are some reasons, why I didn't follow this route further:

Ethereum has assets, which are not that different from what I am thinking about. The HUB: tokens have some properties, that Ethereum assets don't have and this would be a way to realize sidechains on Ethereum, without the need to change Ethereums code. So, there may be actually enough advantages to think about this a little more.

However, there is another reason, why I think bitcoin is a better base for this: bitcoin is mainly a value exchange and storage tool, while Ethereum isn’t. Bitcoins worth is not primarily defined by its usability besides its "usability" of being a value tool. This is more a feeling that I have than anything else, but I think it would be good to have some base that is meant to be that, as opposed to a blockchain, that is mainly intended to be a platform.

If it works, the HUB: protocol can be used with just about any cryptocurrency, using bitcoin is just the most… well, logical. People could create implementations for Monero, Zcash or whatever, though.

Using HUB: to enable these cryptocurrencies to utilize smart contracts is one of the main use cases I'm thinking of


At this point, the honest answer is "no". There are a couple of reasons:
My programming skills are just enough to write a "hello world!" program, so I am not able to write the needed code myself. Neither do I have the funds to pay a programmer.

Since HUB: has no native coins, there is no way to sell something as an ICO and even if there was, I'm getting a little tired of ICOs. I think they are holding back development, actually, because it divides the community. Everybody is working on their own little project, instead of trying to work on a few big projects. I’m not that much better, I guess

I can't really bait anyone with 100x returns or any other kind of direct returns, really. You could argue, that, if this idea takes off, it may further mass adoption of bitcoin, which would ultimately benefit those involved, but I understand that working on a project that can multiply your money looks far more interesting.

I am not yet sure how viable the idea actually is. I think the use cases are there:

- Enabling pretty much any cryptocurrency to have smart contracts
- Fastening transfer times of bitcoin etc.
- delegating transactions to sidechains could remedy maximum transaction problems
- ideally, transactions won't require a fee (not sure about that, yet)
- …I have more, but it's buried in my brain somewhere

But I don't know how to create a sufficient level of security, yet. All ideas I've come up with until now require at least some level of trust (although at least, we are not talking about trust in a single person) or sanctioning of malicious behavior (which implies that malicious behaviour is possible). I’m not totally sure how much of a problem that actually is (philosophically, I have a problem with accepting that we have to create systems that are completely trustless, even if it's the internet). So, there is still a chance, that this thing would just pop like a soap bubble.

Anyway, It's nice to see some people posting here. That's encouraging

This is a real project?

This could be written on Etherium. Sounds like smart contracts.

Half route name idea... Crescent

HUB:
+++          Internal and External Data          +++

HUB: consists of two main parts: the circles, which hold the tokens and a reputation and identity system. The HUB: Network as a whole does not know what happens inside every single circle. There is no main chain, where all transactions are documented. The network doesn’t need to know anyway, because those who are affected by what happens inside a circle are part of it.
However, there is data that is relevant for the HUB: Network. One obviously is the identity and reputation system, others are things like the size of a circle (both in tokens and in bitcoin value), the identifiers of the tokens it is holding and probably other stuff as well.

While it is relatively trivial to keep a circle running without the use of rewards for those who do so (since the ones keeping a circle alive normally have a vested interest to do so), it is not so easy to incentivize users to maintain external data. It needs to be processed and stored just as much as internal data (i.e. data concerning a single circle), but since there is neither mining nor transaction fees in the network itself, there is no monetary way to do so, unless you would implement a donation-based pool to fund operations.

I’m not yet sure how to solve this problem. Maybe the first question that needs answering is who exactly is responsible for maintaining external data; whether there is a special instance, like nodes, or whether it should be the custodians.
What is speaking in favour of the nodes solution, is the fact that there needs to be some means of storage anyway. It is rather pointless to create a system which is supposed to be streamlined and slim, when every circle would need to hold all external data. The external data needs to be stored somewhere and giving chunks of it to different circles (which have, after all undetermined lifetimes) in the hope of somehow preserving the external data as a whole in this way seems foolish. Thus, there have to be instances which serve as storage for this kind of data.

A possible payment system would be to tax using circles at the moment of token creation. Part of the bitcoin invested would go to nodes or maybe custodians. However, this creates new problems, particularly, whether people are willing to pay the extra money to use the service (we shouldn't forget, that  due to bitcoins transaction fees, there are already additional costs, albeit relatively small).

HUB:
+++          Introduction          +++

Hey guys,

with all the people creating altcoins, I thought, I’d do the same

…no, not really.

This is not going to be a cryptocurrency on its own, so I may be actually wrong in this section. Still, I think this is the place where the most people who may be interested in what I am aiming at are looking, so I hope, this doesn’t get removed


HUB:
+++          Disclaimers          +++

• There won’t be an ICO.
  
• There won’t be any mining either.
  
• There won’t be any giveaways, airdrops, or any other way to get free coins.
  
• There won’t be any bounties.
  
• At this point, all I write is theoretical.
  

Ok, let’s get into the real stuff:


HUB:
+++          Elevator Pitch          +++

HUB: aims to become a go-to blockchain solution for almost every case in which a blockchain is useful by replacing Altcoins with bitcoin backed tokens which can be exchanged back to Bitcoin, effectively tethering their price to bitcoin and removing the need to purchase alternative cryptocurrencies.

HUB: has no single main blockchain, but is a network of blockchains, that are called :CIRCLES (or, just circle. :CIRCLE just looks cooler ). Every circle has its own properties, which can differ greatly. A very probable use case will be to modify the code of an existing Altcoin, which would make it possible to use their properties without being subjected to heavy value swings due to pump and dump schemes or the market as a whole.

To provide interchangeability, HUB:TOKENS are tethered to a certain bitcoin value. There will be tokens of different fixed sizes, like 0.001 BTC, 0.01 BTC, 0.05 BTC and so on, just like bills and coins in paper money. This is needed to make trading of tokens easier. Since a token can’t be split, a token with a random bitcoin value is not as easily tradable as a token with a fixed value.


HUB:
+++          :CIRCLES         +++

The custom blockchains used in the HUB: network are called :CIRCLES. I’m not using the term “blockchain”, because most circles are not supposed to run indefinitely; they are in fact supposed to have a rather short lifetime. Due to the nature of this idea, there will be very different styles of circles, though. Some may actually be used for a very long time, others may have the lifespan of a few hours. The same goes for members of a circle; some may contain thousands of members, others may contain as little as two members. Since a circle may contain an agreement between parties that may be considered as a contract, for circles that are abandoned (i.e. they don’t hold any tokens anymore) an archiving system will be set in place, which enables former members to save a copy of the circle and creates a hash and writes this hash into the bitcoin blockchain, as a proof of existence.

While there will be a HUB: native validation system to keep a circle alive, it is very possible, that at some point, circles will pop up, that have their own validation systems, like modified Proof of Work, Proof of Stake or similar.


HUB:
+++          :TOKENS           +++

As stated above, the “fuel” of the HUB: Network are tokens. Every token represents a fixed amount of bitcoin and can't be split into smaller parts. To make payment easier, there will be tokens of different sizes, similar to cash money.

Other than in the most cryptocurrencies, tokens will have unique identifiers. This is important for two reasons:

Users need to have the ability to check whether a specific token is backed with the right amount of bitcoin.

The HUB: Network as a whole doesn't necessarily know how many tokens are held within all circles combined. Thus, to make keeping track of transactions and especially of cash outs easier, a token is assigned an identifier.

The main issue is where to store the bitcoin the token represents. There are two (and a half) routes to go:

Ideally, a token would have a dedicated bitcoin address associated with it, which holds the right amount of bitcoin. This system could work similar to physical bitcoin containers: a trusted entity creates an address and provides the private key only under certain circumstances. To make stealing harder, a solution could be to do so by creating a 5-out-of-7 multi-signature address, of which the token creator holds four keys, while the other three are held by users, who provide this as a service. The advantage of using the 5-out-of-7 solution is redundancy on the one hand, since only one otherkey holder is needed, on the other hand, even if all key holders would cooperate, they wouldn't be able to steal the bitcoin without at least one key of the token holder. A remaining attack vector would be, that a token holder impersonates one of the other key holders and can still access the funds. I hope, that this can be mitigated by a working reputation system, though.

Another approach would be to collect all bitcoin a circle holds in a single address, which is controlled by the custodians (see below) controlling this circle. If a token is cashed out, a request is sent to those custodians, to send the associated amount of bitcoin to a provided address. If a token is sent to another circle, the associated amount of bitcoin is sent to the circle address.

To cash out a token, it has to be sent to a special address, which is agreed upon, either per circle, or for the HUB: Network as a whole. This address works as a kind of “black hole”: every token sent to it, disappears. To send a token to this address, the user must provide a bitcoin address.

Now, to the half route: I call it the “half route”, because I haven’t really figured it out, yet. The main  idea is, though, that a multisig address is created (let’s say a 5-out-of-7), in which six of the seven keys are generated (the seventh is held as a proof of ownership”) in a “black box”, i.e. a kind of smart contract, that watches for for the token to be sent to a very specific address (the “black hole”). Only then, the contract triggers and generates a transaction to the stated bitcoin address. What makes this idea just a half idea is one major problem: I still have to find a system in which private keys can be created without anyone watching it, and of course, this has to happen in a way, that it is provable that nobody watched their creation.


HUB:
+++          :CUSTODIANS         +++

Circles need to be secured, as any other blockchain does. You could probably use the bitcoin blockchain for it, but it is rather slow and it would be nice to have faster transaction times. In fact, one advantage of HUB: would be to have a system in which you can effectively send bitcoins faster than you could normally do, by sending bitcoin-backed tokens.
The approach I’ve come up with, is a system using so-called “custodians”. The main idea is this:
custodians are actors within a circle that maintain the circles chain by verifying transactions, those inside of the circle, as well as those leaving the circle. At the moment of creation, it is determined who serves as custodian. Just as the number of users, this number can vary greatly. In a very small one-purpose chain between two parties, there may be two or three custodians (the two parties plus an escrow), there may be hundreds of custodians, there also may be only a single but trusted custodian maintaining a circle with hundreds or even thousands of actors (a use case may be a supermarket maintaining a circle to make instant payment possible, while still having a transparent system).
The power of a custodian is not determined by their size of stake in a circle, every custodian has the same amount of power. At the same time, there won’t be any payment for being a custodian, no transaction fees or anything. In smaller circles, probably all members are custodians and have a vested interest in the integrity of the circle. An obvious problem will be, that a single user can impersonate a group of custodians to overrule a smaller group of custodians. To prevent this, every custodian has a “Veto” function: a single custodian or a group can declare any transaction invalid, but what will happen, is, that a new circle is created with them as custodians and all their funds being transferred to this circle, so effectively, they are thrown out of the other circle. This approach obviously saves only their own funds, so in a system in which there are members that are not custodians, it still needs to be figured out how to handle this. A possible approach would be to let members follow the custodian they trust (about “trust”, see below) the most in case of a dispute.


HUB:
+++          Trust, Identity and Reputation          +++

The HUB: Network won’t be a completely trustless system. It is not supposed to. It is not an anonymous system either. If all goes well, it can be pseudonymous, at least for the majority of its users. Still, to effectively use HUB:, a user will need to create some kind of identity.

Within the HUB: Network, there will be a reputation system. Due to the nature of blockchain, there is no way of effectively blacklisting users, so there will be a combination of white-listing and reputation earned by other users. Trust will be displayed in a network style: The more users, that a user personally trusts, be it by knowing them personally, or by having positive interactions with them in the past, are trusting an unknown user, the more trusted this user is.

So far, this is it. I hope you are intrigued. I would love to get some people interested in further discussing this project.