Bitcoin Forum

Here is a re-post from http://qubic.boards.net/

What Qubic is
Qubic is a medium of exchange in the Information Age. It is money that can be created, controlled and used by anyone.

Why Qubic was invented
Inspired by Bitcoin and its forks, the author of Qubic began to think of a currency that would have advantages of Bitcoin but would not have its disadvantages. After a while he came to a concept that was named "Qubic".

Where name "Qubic" came from
An idea of quorum-based coins is the core of the concept. These coins are created and controlled by arbitrary nodes on the Internet without any central authority. Name "Qubic" came from acronym "QBC" which stands for "Quorum-Based Coin". The coins are called "qubics" to distinguish them among other types of coins.

What qubics are
Qubics are binary data stored in computers. These data contain information about value of qubics, their public and private keys. A private key is known only to a qubic's owner and is used to prove ownership.

How qubics are created
Qubics are created ("minted") by nodes ("providers") that run special software. Every provider does work necessary for normal existence of the Qubic network. Periodically every provider receives new qubics as a reward for its support of the network and this reward is proportional to quality of provided service.

What service is provided
Providers mint new qubics. They let qubics to be split, combined and refreshed, providers also prevent double-spending of qubics. Splitting is used to split a qubic to ones with lesser values to get specific amount. Combining is used to combine qubics to make them easier to store. Refreshing is used to change private keys, it is also used to stress-test the network to keep it healthy.

How qubics are transferred
To transfer qubics during a trade between parties it is necessary to transfer private keys. After the keys are accepted by the seller the qubics are destroyed and new ones with the same values are created. Private keys of the new qubics are known only to the new owner. Transfer of keys occurs outside the Qubic network (via e-mail or special software), so it is impossible to track transactions made with qubics. Destroying of qubics and creation of new ones is a common occurrence and noone can prove that this happened due to a trade.

What features Qubic has
- Value of a qubic varies from 0.000000001 (10^-9) to 999999999.999999999 (almost 10⁹), it is 9 decimal places before and after the point.
- Supply of qubics is theoretically unlimited. Every provider decides how many qubics it lets to be rewarded to the other providers. In the future the system can come to a state when total value of minted qubics becomes less than total value of qubics lost during the same period of time. (Some loss of qubics is expected due to lost keys and other causes.)
- No fees are supposed to be charged for transactions as they occur outside the Qubic network. Providers obtain qubics by providing the service.
- Transactions can not be tracked.
- Noone needs to reveal theirs real identities to be able to use Qubic.
- There are no "accounts" in Qubic, only "coins" which can be lost but can not be nullified.

Implementation of the concept
The author is working on an implementation of the concept. Constructive suggestions and help in testing are very welcome.

---

Quick comparison with Bitcoin:

- No fees
- Transactions can't be scrutinized
- Network-bound proof-of-work instead of CPU-bound one is used
- New coins are produced at the rate determined by quorum of miners, not by developers (good ole Greek democracy)
- Coins "look" like real coins (not a ground-breaking feature but a neat one)
- No need to download gigs of data from "a blockchain", every miner is allowed to handle only fraction of the Qubic network
- Transfer of money in Qubic is supposed to be much faster than in Bitcoin
- Qubic is more eco-friendly as it doesn't require a lot of electricity to be spent
- (I'll add more if anything comes to mind)

From what I gather this is somewhat based off of the Chaumian-style digital cash.

1. How does the system prevent sybil attacks (http://en.wikipedia.org/wiki/Sybil_attack) without proof of work?
2. How is consensus reached on how many and what coins exist?
3. What the hell does "Coins "look" like real coins" mean?
4. How long do you expect it to take consensus to be reached to prevent double spending?

Any provider can consider any other provider to be trusted with some weight. 1000x, for example, means that an attacker has to create at least 1000 faked providers visible to the attacked provider to make a successfull Sybil attack (not all providers are visible to the others, so practically it is necessary to have more than 1000 faked ones). All data received from such a trusted provider should be carefully logged and audited (to prevent qubics to be minted out of thin air), but it is necessary only in the beginning. When more providers join the Qubic network, Sybil attack will become less dangerous. So after a while it can be possible to get rid of all trusted providers. As every provider itself marks other providers trusted and choses appropriate weights and noone else knows this information, Sybil attack doesn't seem to be an issue. Anyway I'm concerned about it and plan to simulate such kind of attack during pre-launch tests.

Everytime when a new transaction appears (SPLIT, COMBINE, REFRESH) providers distribute it each to other. When a provider receives a new transaction it increases the rating of the provider the transaction was received from. Periodically every provider asks the others if they wish to mint new qubics and receives public keys of these qubics. There are 19 keys for qubics with values of 0.000000001, 0.000000009, 0.00000009, 0.0000009, ..., 0.9, 9, 90, ..., 900000000 are published by every asked provider. Every provider makes decision what total value of qubics it lets to be minted by every other provider and this is based on the rating.

Let's imagine that provider A lets 100 QBC to be minted by provider Z. Provider B lets 10 QBC by Z and provider C - 10 QBC by Z as well. A stores qubics with keys corresponding to values 90, 9, 0.9, 0.09, ... (total = 100 QBC). B and C store keys corresponding to values 9, 0.9, 0.09, ... (total = 10 QBC) both. Now if Z try to do anything with qubics with values higher than 90 QBC it will be rejected by everyone. Transactions with 90 QBC will be accepted only by 1 of 3 providers (no quorum) so it means that the qubic [90 QBC] wasn't minted. Transactions with 9 QBC and less will be accepted by the quorum of providers.

There could be a situation when every provider refuses to accept qubics minted by the others. In this case the Qubic network will start to lose its providers (no point to work for free) and credibility of the rest of the world. So the price of 1 QBC will go down which will lower profits of remaining providers. Similar scenario is expected even in case when values of minted qubics are higher than zero but still too low. On the other hand it's undesirable for the network to mint a lot of qubics, coz in this case due to inflation the price of 1 QBC will go down as well. I suppose that the whole system will find a point of dynamic balance, just like the market does.

The same with already existing qubics. It's necessary to ask some providers if this particular qubic exists. If u asked 100 providers and more than 50 said "yes", than u should consider it's legit qubic. If u r not satisfied with numbers than just ask 1000 providers and keep asking as long as u wish.

Bitcoin has accounts and their balances. Qubic doesn't have accounts. Qubics are very similar to real coins as there are no connections between a purse (a wallet in Bitcoin) and a qubic.

Something within 60 seconds. Need to make experiments though as this depends on an implementation.

You've got a lot of work ahead of you if you think this can be used as a way to bring consensus. In a decentralized system, there has to be a way for everyone to eventually come to an agreement on what has happened.


No one else knows this information including people who want to transact on the network. Determining who to trust will be impossible and sybil attacks will be easy.

Minting algo can be adjusted. Or completely changed. And then we'll see if it works.

It's not necessary to choose whom to trust when there are thousands providers and Sybil attack can't be implemented easily. At early stage with a few providers only small amount of qubics can be minted and it's easy to audit every qubic. Real qubics can be minted starting from the point when the network will have enough providers to overcome attackers.

You claim a sybil attack can't be mounted easily, but the only defense you seem to have is that honest people will have more. One botnet could have thousands or hundreds of thousands of IP addresses. Once IPv6 is the norm, governments and ISPs will have easy access to billions of IP addresses. The trust system might work among providers that know and trust each other, but this does nothing for people trying to use the network. They will be inundated with all kinds of providers and have no clue as to which ones are trustworthy. Not to mention since each provider will likely have a different idea about who is trustworthy, trust can't be used to weigh votes on how many coins are created. So someone with tens of thousands of IPs can just say "I want 9999999" tens of thousands of times (good lord the data consumption) and destroy any value to the currency.

you gotta solve this too: http://en.wikipedia.org/wiki/Byzantine_generals

You might be interested in this: https://github.com/FellowTraveler/Open-Transactions/wiki

Is there more to the 'network-bound proof-of-work' other than ip addresses?

I assume if you call it 'proof-of-work' there must be more than unique ip addresses? Number of transactions received?

Can't say for sure if you have at least mitigated sybil attack with just the sketch you provided but Etlase has some good points here.

Also the inflation model seems to be wide open.

It's enough to defend. Sybil attack is like 51% attack in Bitcoin world. Do we have a lot of problems with anyone 51%-attacking Bitcoin?

No need. Bitcoin ignore such an issue and works perfectly (I'm talking about bitcoin clients that retransmit transactions, who makes them doing this correctly?). If at some step this becomes a problem, than Paxos will be added to implementations.

Thx. I've seen this long time ago. It's quite different.

Faster u send transactions - more qubics will be rewarded to u.

Etlase indeed has good points regarding Sybil attack. This kind of attack can't be completely avoided without a central authority, but Bitcoin has similar issue (51% attack) and still works fine. If we grow in numbers the attack won't bother us.

Regarding inflation model... It depends on quorum of providers.

No, we don't have a lot of problems with anyone 51% attacking bitcoin because it costs a lot of money. IP addresses do not.


:sigh: Bitcoin does not ignore byzantine fault tolerance. It's part of that whole distributed-consensus block chain thingy you might have heard of.
"If u asked 100 providers and more than 50 said "yes", than u should consider it's legit qubic. If u r not satisfied with numbers than just ask 1000 providers and keep asking as long as u wish." - This reeks of byzantine failure. I am not familiar with Paxos, but by a brief overview it looks like it is made for a centralized service with distributed fault tolerance, not a distributed network protocol.

Maintaining a lot of providers doing a lot of work during long period of time is expensive too. U can't just launch 100500 providers and say "I have 1000000000 QBC".

If number of "good" providers is higher than number of "evil" ones then I see no problem. When a qubic is destroyed "good" providers erase its data and won't say "it still exists". If u ask 100 providers then 51+ will say "it doesn't exist". Every provider keeps records about existing qubics itself. We (users of Qubic) need to ask providers only to get recent info to avoid double-spending.
Perhaps I can't get ur question, could u paraphrase it?

How many bots does a botnet tend to have? Maybe only a few hundred thousand for a not particularly huge/notable botnet?

So botnets should be easily able to "51% attack" you until you have a few million "good" nodes, presumably?

Maybe you are yourself in control of one of the several million bots botnets, thus expect to easily defeat a few smaller (few hundred thousand nodes) botnets yourself to secure this coin? (Why else would you design a system explicitly ensuring botnets a massive advantage over normal folk?)

-MarkM-

We should distinguish a concept and its implementation. Depending on an implementation number of bots required to overtake legit providers could vary from 1 to 1000000000.

Perhaps u will laugh but I design this system to make the world better. U shouldn't trust me of coz. I'll publish source code, so anyone can audit it. Or make his own implementation.

Thx. I was waiting for a reply like urs. To just to make statement that I understand that there are a lot of bitcoiners and litecoiners who are against any possible competitor of their lovely Coin. So I'll ignore all replies which r non-constructive ones.

OK so what implementation details will you be including in order to ensure that being out-numbered by botnet nodes will not be a problem?

-MarkM-

Weighted trust built on history. Longer a provider stays (and send correct responses) on the network - more weight it has. Every provider has its own IP address which identifies it. Most of zombie computers popup and disappear on the Internet, so they r unable to earn noticeable weight.

No, no.  We welcome competitors.  If not for the corpses of the dead alternate coin systems covering the field, how would we have any way to tell how great bitcoin is?

:) Good point of view. But some hoarders r still not happy with new coins appearing around.

Meh.  If inflation was a desirable property, one of the many, many attempts to create inflateacoin would have taken off.  None have.  Not exactly QED, but highly suggestive.

Qubic can deflate too. Depends on the quorum.

I don't really care of inflation/deflation, I wish to create money without disadvantages of Bitcoin, some extra advantages would be good bonus also.

1. Why "Quorum" is a loaded word:
     (Anonymous Global Quorum) The most important quality of Bitcoin is that it gets global consensus while being anonymous in the sense that it does not try to identify individuals among "the miners." Any public system that uses identifiers (e.g., an IP address, or self-reported public keys) is vulnerable to a sybil attack. Bitcoin's central innovation is using a proof-of-work competition to coordinate consensus without needing to distinguish between the participants.

      (Global Quorum with Identifiers) Ben Laurie described a quorum system where a network of globally 'trusted' providers performs a consensus voting protocol. http://www.links.org/files/decentralised-currencies.pdf The "Greek democracy" scheme also works this way, just with a large number of identities. The mapping of identifiers to nodes has to be decided ahead of time, which usually implies a central administration (e.g., to assign IP addresses, voter IDs, or to certify public keys). This is the "traditional" way to do distributed consensus, but it's at least partially centralized, which is dissatisfying.

     Now I think you're getting confusing - is the "quorum" considered 51% of the entire network, or just among the 100 providers that a single individual asks? If Alice in the US talks to 100 providers, and Bob in China talks to a different 100, will they get different answers than the other 800/1000? How does a single provider among all the providers receive rewards? I get the idea that you are no longer talking about "global" consensus at all. If that's true, then this might resemble Ripple http://ripple-project.org/paymentrouting.pdf which is a p2p currency system about local currencies (for example each individual issues their own notes). On the other hand, there's no expectation that your credits are valuable to a random other person on the other side network though (who has no reason to trust the issuer). It's not "money" though because it's not universal. I'm interested because you said that the rate of new coins is set by some mechanism other than developer-fiat. If it's set by a quorum, then is it by a global quorum, or some local kind (i.e., you ask 100 providers what the rate of new coins is?)

    I think you're being very vague about how the quorum is defined, what its boundaries are, and how individuals observe its responses. If you try to make a clear statement of the assumptions and objectives for the technical components of your system, then we can probably get to the bottom of how it works.

2. "Network-bound proof-of-work instead of CPU-bound one is used"
    I'm interested in this, can you give more details about the network-bound proof-of-work scheme?

I've seen a lot of similar papers on the Internet and have not met any mathematically strong proof that such a system can't work. There is a way to find the solution by proving its in practice. I can fail, but I can succeed.

It's where Statistics works. U don't need to ask all providers coz even part of them will have almost the same percentage. Everyone decides themselves how many providers they wish to ask. And I'm talking about global consensus. A single provider receives reward as described here - https://bitcointalk.org/index.php?topic=112676.msg1219095#msg1219095. The rate of new qubics is set by the Qubic network, the same as prices set by the market.

I don't know how it will exactly work. I have no ready answer. That's why I asked for help. I'm developing an implementation of the concept and I'm planning to change algorithms of the implementation until I get a working system.

There is no real proof-of-work. I used a term that is understandable by this community. I could say "Qubic is mined by network cards". "Weighted trust" idea looks like network-bound proof-of-work but I'm not sure it's correct to call it so.

It's nice to see someone trying something really different from Bitcoin. I think the idea of getting votes from peers has some merit. It'll be interesting to see how well it works.

I've published my implementation of Qubic with its source code. Not a complete one, right now i'm testing how providers find each other on the Internet. More info on http://qubic.boards.net/index.cgi?board=technicalbase&action=display&thread=2. If u could help to test that would be great.

U can monitor activity of my own provider here - https://78.47.168.188/provider?123.

ok i downloaded the zip files... unpacked them all,

then went to change the 10* and replaced them with "https://myprovider.com/provider"

Is this wrong?? should i put my own website?? or what do i put here??

I then ran CMD and invoked the command      "java -jar start.jar"

Output I get is then:

2012-09-27 16:16:44.542:INFO:oejs.Server:jetty-8.1.7.v20120910
2012-09-27 16:16:44.589:INFO:oejdp.ScanningAppProvider:Deployment monitor C:\Doc
uments and Settings\ME\My Documents\Downloads\qubic\jetty\webapps at in
terval 0
2012-09-27 16:16:44.589:INFO:oejd.DeploymentManager:Deployable added: C:\Documen
ts and Settings\ME\My Documents\Downloads\qubic\jetty\webapps\root
2012-09-27 16:16:44.792:INFO:oejw.StandardDescriptorProcessor:NO JSP Support for
 /, did not find org.apache.jasper.servlet.JspServlet
2012-09-27 16:16:44.839:INFO:oejsh.ContextHandler:started o.e.j.w.WebAppContext{
/,file:/C:/Documents%20and%20Settings/ME/My%20Documents/Downloads/qubic
/jetty/webapps/root/},C:\Documents and Settings\ME\My Documents\Downloa
ds\qubic\jetty\webapps\root
2012-09-27 16:16:44.839:INFO:oejsh.ContextHandler:started o.e.j.w.WebAppContext{
/,file:/C:/Documents%20and%20Settings/ME/My%20Documents/Downloads/qubic
/jetty/webapps/root/},C:\Documents and Settings\ME\My Documents\Downloa
ds\qubic\jetty\webapps\root
2012-09-27 16:16:46.135:INFO:oejus.SslContextFactory:Enabled Protocols [SSLv2Hel
lo, SSLv3, TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1
.2]
2012-09-27 16:16:46.276:INFO:oejs.AbstractConnector:Started SslSelectChannelConn
ector@0.0.0.0:443


I take it i am being stupid on the URI of my provider... but was wanting to help u test so give me a shout and point me in the right direction and I should be able to have this running for u on a stand alone server i have spare :)

As its a jetty app will people be able to put it into their I2P "eepsite" so it runs over I2P? This saves them all the problems of having a known IP address, opening a port in their router and so on, plus of course provides anonymity...

-MarkM-

Thank u for ur attempt to help.

To know what to place instead of "myprovider.com" u need to know IP address that allows to connect to ur computer from the outside. Go to http://www.whatismyip.com/ and watch ur IP. Let's assume it's "111.222.333.444". Replace the asterisks with "https://111.222.333.444/provider". That's it.

Yes. It should work via I2P "eepsite". Never tryed this technology but according to its description everything should be ok.

Mathematically, IPv6 has 2^128 address space. Standard size of subnet is 2^64. You can register /56 net for free from Freenet6: http://www.gogo6.com/freenet6/tunnelbroker

It has 2^(128-56) = 2^72 addresses.

If you want to base security on IP addresses, it seriously is not going to work. A serious attacker can impersonate practically unlimited number of nodes.

You have a reputation system based on time? Attacker can impersonate, say, 10^6 nodes for, like, a month. And then he will pwn you. It won't cost him much, a couple hundred bucks, maybe.

Ben Laurie's design is based on explicit trust: providers are organizations, officially registered by government, and they'll check each other's existence and trustworthiness. Sybil attacks are practically impossible in this way.

Fully decentralized alternative to that is Ripple-like designs. They are based on explicit trust (i.e. among people who know each other), but global trust is not required since you route payments among trusted individuals.

So there are designs which are theoretically sound.

Yours, however, seem to be based on idea that IP addresses are scarce and costly. Which simply isn't true.

I do not want to base security on IP addresses. I want to base it on a reputation system. And this reputation can't be easily earned during staying online for, like, a month. All these 10^6 nodes have to process and transmit a lot of traffic. This does cost much, very much. Not only traffic, but CPU power as well, coz u can't just set up 1 computer and use 10^6 aliases.

So how will you identify each site? A keypair, like the way I2P sites and Freenet stuff and Tor services etc are identified?

Also seems like you are pretty close to being back to proof of work, since your only defence it seems is to throw more CPU power and IP addresses (or identities) and bandwidth into it than any attacker.

That being so, it seems like a very complicated way of blowing just as much energy/expense as bitcoin much less elegantly and very likely much more prone to errors problems bugs etc simply due to all the extraneous complexity.

(How much more cost-effective is bandwidth than CPU? Is a big datacentre more cost-effective than a distributed botnet? Etc etc etc...)

-MarkM-

Perhaps I have missed something... What traffic?

Each provider is identified by its URI. Right now only "https://" scheme is supported.

Yes, I'm very close to network-bound proof-of-work as bandwidth is intensively used. CPU is used also but not those enormous GHash/s as in Bitcoin, Qubic needs only to check a nonce, not to find it.

Big datacentre is much more cost-effective than a botnet which, likely, unable to earn much reputation or reward.

Okay, so something like https://provider.knotwork.i2p could be a URI for a provider I run in I2P.

Then only others who run I2P and have set up some kind of system at their end to make .i2p addresses work would be able to connect to my node.

Will others hear of mine through those and credit me accordingly?

(https is kind of redundant over i2p but whatever...)

-MarkM-

To earn reputation u have to respond with actual data (what qubics r valid, what transactions r processed). Qubic has a built-in mechanism that doesn't let the network to sleep when there are no transactions from users of the system. Every second every provider has to receive, process and transmit data at 99+% rate of available resources.

No. If I2P doesn't allow to access inner nodes from outside then this technology can't be used to "mint" qubics. I thought I2P was something like Port Mapping and allowed to connect to computers behind firewall.

Replying to 1000 queries per second won't be a problem even for a cheapo box. So I'll emulate 1000 nodes for some time to get reputation and then will attack you.

As markm said, you just have a weird form of proof-of-work which requires CPU power, network bandwidth and IP addresses. But it doesn't make it stronger, it makes it harder to analyze.

With Bitcoin proof-of-work, miners are incentivized to do hashing as fast as possible, so you get no unexpected hacks.

With your proof-of-work an attacker might find some cheaper way to process queries, get some cheap bandwidth and IP addresses. (For example, he might be an ISP himself.) Other nodes do not have an incentive to do things in an optimal way, so you don't know how much attack costs.

Attack on bitcoin is estimate to cost millions of dollars. Attack on qubics might cost thousands of bucks. Or perhaps it would be essentially free for organizations who have access to resources. (Providers always have some spare capacity which isn't used for anything else.)

Right. 1000 queries per second won't be a problem. For legit providers also. Calculate what fraction of reputation will u earn in the network of 1000 nodes that process 1'000'000 queries per second. Can ur node process 1 million queries per second? Yes? Then legit nodes can do it too, so u have to overcome 1'000'000'000 queries per second. Qubic is designed a way that doesn't allow to have 1 provider doing work of 1000 legit providers, u need 1000 computers for that. Is it cheap? Multiply this on weeks u have to remain online, coz if u went offline for long period of time then u'll lose all ur reputation. Btw, that's why u can't use botnets for Sybil attack.
I followed the path of the Great Satoshi. U must have 51% of all resources to hack Qubic. The only noticed difference in defenses of Bitcoin and Qubic is CPU-bound VS network-bound proof-of-work.

I wouldn't say it's weird. We used to use CPU-bound proof-of-work, so network-bound one is just not so familiar.

It's impossible to receive and transmit data at faster rate than allowed by a channel throughput.

ISP can attempt an attack. If they have spare bandwidth. Just like any computer center/cluster can attempt to attack Bitcoin. ISPs have to cooperate each with other, coz in Qubic nodes r supposed to be distributed randomly around the globe.

Attack on Qubic might cost just a couple of bucks. Or billions. It depends on an implementation.

I posted more info related to defense against sybil attack.

http://qubic.boards.net/index.cgi?action=display&board=theconcept&thread=3

Very important info about freedom-centric nature of Qubic that could be interesting for true libertarians - http://qubic.boards.net/index.cgi?action=display&board=theconcept&thread=4.

"Bringing ancient traditions back" - Brief description why Qubic doesn't require a person to be a tech savvy one to influence on the whole system - http://qubic.boards.net/index.cgi?action=display&board=theconcept&thread=5.

should probably repost your conspiracy theory thread on your forum since it got deleted here.

I'm kinda surprised whoever did that did it, it only fuels the fire imo

Why not take an approach where every kind of resource is rewarded in it's own way?

There are:
Computing Power (CPUs, FPGAs, GPUs)
Storage Capacity (Harddisks, SSDs, DRAM)
Memory Bandwidth (SRAM, DRAM, SSDs)
Network Capacity (Upload/Download Capacity)
Routing Resources (IPs, Infrastructure)

Currently only Computing Power is rewarded by Bitcoin, although it needs all of those tescources to function. Litecoin for example rewards Memory Bandwidth a litte bit more.
I propse to extend this to every resource which contributes to a functioning network.

Aye. I'll do it and send the link to different bitcoin bloggers.

Qubic rewards Network but it's just a side-effect of the sybil attack defense.

Not just "not so familiar", it has completely different properties.

Your hashing power depends only on what you do. I.e. you need to buy certain hashing device, then pay  for electricity. Costs are well understood, and you get stable hash rate if your hardware works.

But network bandwidth's nature is very different: it, by definition, depends on your interactions with whole network.


It isn't enough to buy channel to some peer, as peer might not want to relay your traffic at full channel bandwidth.

Costs depend greatly on who you are:

• For tier 1 networks bandwidth is usually free, they don't pay for peering. So for them it is about costs of creating channels, after that traffic is essentially free
• Smaller networks might need to pay for peering, but they can get some free traffic on traffic exchanges and whatnot.
• Commercial users often pay a lot for bandwidth they use. Unless they can find some wholesale deal. Wholesale bandwidth is much cheaper than regular price you can get from ISP, but you have to commit to some minimum. This is how things like imgur.com and sendbigfiles.com are possible. Just one shitty image on imgur can easily generate 100 GB traffic, but apparently they have fat pipes...
• Residential user often pay a tiny sum for considerable bandwidth, but it depends on where you live. Essentially, ISPs think that even if you have 50 Mbit/s connection, you'll be using a tiny fraction of it on average. Some ISPs throttle heavy users...

So traffic price might change 1000-fold depending on who you are, where you are and how you're going to use it.

Thus it IS possible to simulate 1000 nodes for costs of just 1 node if you have some sweet deal.


Not really the same: attacking Bitcoin has opportunity/electricity costs. While spare bandwidth is essentially free.


Have you ever heard about packet spoofing? Your ISP can pretend to be around the globe.  :)
You cannot really check where packets come from geographically.


As I said, fundamental cost structure is different.

I think it would be cool to see a protocol where PoW will be augmented with some network-level checks. Essentially, we could isolate asshole miners who block legit transactions, or perform double-spends. I have designed a basic sketch of such implementation, BTW...

But using only "proof-of-bandwidth" seems to be a recipe for disaster: it waste resources just like Bitcoin, but does not provide same security.

Good points. I work hard to complete the code and test my idea in practice, so then we'll see how my "proof-of-bandwidth" works.

"Solution of the biggest disadvantage of Bitcoin" - http://qubic.boards.net/index.cgi?action=display&board=socialissues&thread=6

a very interesting read. Im very excited to see how you plan on ingratiating all of these ideas into a currency.

In short, "print moar moneyz".

-MarkM-

I've published a new version of the provider prototype. Now it's possible to test how qubics r minted.

Everyone is welcome to join, u must have 443 port opened on ur computer. Also http://aws.amazon.com/free/ can be used as free hosting.

PS: http://qubic.boards.net/index.cgi?board=technicalbase&action=display&thread=2

Hello, Stranger(s) from Mountain View (http://en.wikipedia.org/wiki/Mountain_View,_California), I noticed that u were visiting Qubic Forum (http://qubic.boards.net) a lot of times using different IPs. I'm curious if u r a search bot or a real person...

maybe it's just a coincidence that google is based in mountain view

Googlebot?

Seems so. ISP = "Google Inc."

But why 10 bots at once?..

For those who asked about the Sybil attack (from http://qubic.boards.net/index.cgi?board=theconcept&action=display&thread=7):

This seems to be a form of ripple ?

What's about double-spending?

Suppose there is a sudden loss of connectivity between Moscow and Petersburg, but my friend has a full copy of my wallet in Moscow while I'm in Petersburg.

We both can spend same qubic, can't we?

Well, I hope your software can detect that network is split and delay confirmation of payment.

However, this is where Sybil attack comes to play: without anti-Sybil measures, Moscow providers could impersonate Petersburg providers to make it seem like network isn't split.

No. Similar but still different.



Moscow providers can't pretend they are Petersburg ones, coz all traffic between providers is encrypted with a secret key. Each pair of providers has its own key. Moscow providers can spoof IP addresses but they can't guess the key.

Let's imagine that you spend 10 QBC to buy a car and your friend spends the same 10 QBC to buy a house. Both sellers get signed transactions and publish them into the different parts of the Qubic network. The transactions look like "destroy 10 QBC and create 10 QBC with other public key". After a minute both sellers begin to ask arbitrary providers if 10 QBC with new public key exists and count weighted voices. The seller in Moscow tries to ask providers in both cities, the same the seller in Petersburg. If the network is split close to 50/50 but sellers set the quorum as 75% then none of them will ship the purchased item because no reply == "the qubic doesn't exist". Let's assume that Moscow has 80% of all providers. In this case only one of the sellers will ship the item. And after the network is merged, info that old 10 QBC is destroyed will be propagated among Petersburg providers so they invalidate the transaction with double-spent qubics.

I'm considering a scenario where split is 50/50, but 25 more providers appear in Moscow so that quorum is reached.

If I understand correctly, anti-Sybil measures such as weighting fix this situation: it isn't possible to create more providers in a short period of time.

Thus weighting is what protects the network from double-spend attacks. Am I right?

Even better:

+25 providers means only (50+25)/(50+50+25)=60%, we must add 100 providers more to get (50+100)/(50+50+100)=75%. Paranoic sellers can set the quorum to 90%. Too high quorum value makes them vulnerable to the sabotage attack, so very high values shouldn't be used though.

The list of providers is updated with arbitrary delay (depends on a provider settings, something like 12-36 hours, can be set to any period), so only a few legit providers will see new 100 providers as soon as they appear. The others will see them in 6-18 hours.

You are right. The weighting works similar to proof-of-work in Bitcoin, it protects the system.

Just want to say well done on having something new with the network based proof. It's great to see a new innovation. I'll buy into this when it's ready just to support it I think.

I read about this before but it wasn't clear in the main descriptions. I think it would have had more attention if that was so.

Small topic that could be interesting (http://qubic.boards.net/index.cgi?action=display&board=theconcept&thread=9&page=1):

Fighting the scam

Internet is full of scammers because anonymity lets to evade punishment with no or little effort. Qubic does its best to support anonymity, but it provides users with a tool that protects them against scammers.

Every transaction is processed in a 2-step manner:
1. Every owner of input qubics signs the transaction.
2. After a while they commit it.

A transaction can't be rolled back, this means that input qubics of an uncommited transaction are lost forever. How does this protect against scammers?

Imagine that Alice wants to buy an electronic book from Bob for 10 QBC.

She signs a transaction:
10 QBC [owned by Alice] => 10 QBC [owned by Bob]

Then Bob sends the book to Alice via e-mail.

And finally Alice commits the transaction.

If Bob didn't send the book, Alice wouldn't commit the transaction, so Bob wouldn't get the money.

What if Alice didn't commit the transaction? She already got the book, why bother with the rest?

Let's change our transaction:
15 QBC [Alice] => 10 QBC [Bob] + 5 QBC [Alice]

In this transaction Alice paid 15 QBC but got 5 QBC back. If she didn't commit the transaction, she wouldn't get part of the money back. In this situation 5 QBC is a pledge.

What about a case when Bob is just a kid who likes to mock at people?

OK, our transaction should be:
15 QBC [Alice] + 25 QBC [Bob] => 35 QBC [Bob] + 5 QBC [Alice]

Now both Alice and Bob have to sign and commit the transaction. If one of them doesn't do it they will lose the money - 15 QBC of Alice and 25 QBC of Bob.

Let's change the scenario. Alice wants to buy a usual book made of paper. Bob sends it to Alice via good old postal service. Unfortunately, someone in Good Ole Postal Service (GOPS) loses the book. After a week of waiting Alice is angry so she decides to never commit the transaction. Of course, she loses 15 QBC, but Bob loses more, let it be a lesson for him! And only GOPS, which deserves punishment, loses nothing...

...But such a transaction would fix the issue:
15 QBC [Alice] + 25 QBC [Bob] + 20 QBC [GOPS] => 35 QBC [Bob] + 5 QBC [Alice] + 20 QBC [GOPS]

In this case GOPS would do its best to deliver the book.

In examples above all numbers can be adjusted. If Bob has a good reputation he could pay 10 QBC instead of 25 QBC. If he has no reputation yet GOPS could lower their pledge from 20 QBC to 5 QBC (because they don't know for sure if Bob can print the book in time).

This is just an example of a simple scenario. It's possible to create more sophisticated schemes using 2-step transactions.

We all know how inflation graph of Bitcoin looks. Follow this link - http://qubic.boards.net/thread/11/qubic-supply-growth - and u'll see the same thing for Qubic.

For those who are too lazy :):

http://qubic.boards.net/attachment/download/1

I don't know when Litecoin ASICs will come to the market, but owners of GPU farms could earn coins even after that - http://qubic.boards.net/thread/12/workers.

So, it's a sort of built-in escrow? Neat!

I know that users of Bitcointalk are very resourceful when it's necessary to find weak points of a system. There is a list of attacks that could be attempted against Qubic, I hope u help me to devise more attacks:



Isolation attack

Severity: Medium.
Description: An attacker blocks traffic of all providers except controlled ones trying to make the quorum to be statistically incorrect.
Counteraction: Setting a threshold for percentage of non-responded requests to suspend payment acceptance.


Sabotage attack

Severity: Low.
Description: An attacker sends incorrect information about validity of qubics trying to disrupt normal functioning of the system.
Counteraction: Setting the quorum to values below 90% makes the attacker to have at least 10% of the total weight to reach the goal.


Sybil attack

Severity: High.
Description: An attacker creates a lot of providers trying to get the majority of the network to be able to create qubics out of thin air.
Counteraction: Weighting (with proof-of-work) lets to assign weights to each provider, so it's necessary to have a lot of computing power to get a big share of the total weight.


Tunnelling attack

Severity: Medium.
Description: An attacker creates a lot of providers trying to validate non-existent qubics, so it becomes statistically feasible that one of the legitimate providers will consider such qubics as valid ones and will spread incorrect information to other nodes.
Counteraction: Constant validation of all valid qubics.


Read more: http://qubic.boards.net/thread/15/attacks-on-qubic

How to donate and tip

With Bitcoin it's easy to start accepting donations, publish your BTC-address and check the balance time to time. With Qubic you can't publish a QBC-address because there is no such a thing, only one-time qubics. But you can publish your e-mail and check it or setup software to do it automatically. Such a way have an advantage over Bitcoin's approach. If Alice sends bitcoins to Bob, but he loses access to his BTC-address, then noone will be able to get the money. Though, if Alice sends qubics to Bob's e-mail and he loses access to it, she still will be able to check if the qubics are spent and redeem them if not.

Tipping works similar way. Imagine that Alice goes to a restaurant where Bob works as a waiter. If she likes the service she could generate a qubic using a mobile phone. This qubic should use a private key derived from a set of symbols. Alice will just write something like on the bill, so Bob will calculate to get the private key. Later she can check if Bob was smart enough to redeem the qubic and if not then redeem it by herself. She could even use her phone number as a key if Bob is a handsome man :).

Read more: http://qubic.boards.net/thread/16/donate-tip

this projects surely needs more velocity :(

Really? Well, I still need to solve some technical issues, so Qubic will be able to handle thousands of transactions per second.
Programming is not a problem, if I had all pieces of the puzzle I would write the code within a month.

In http://qubic.boards.net/thread/17/technical-details I posted some technical details about qubics, so it should become clear what the differences between Bitcoin and Qubic addresses are.

One solution to the Sybil problem would be to only allow a certain amount of "providers" in the network. Say, not more than 10,000 (exact number to be determined, you could start with less)

Then, have some sort of proof of work system through which interested parties generate a "provider node" token *. Make it extremely difficult, exponentially, so that it is very hard to become a provider. Make provider nodes expire after say 1 month, but allow existing owners to renew their nodes once they have them.

Allow banning of nodes, effectively making them lose their provider node if they become untrustworthy, and return the node to the pool, giving someone else a chance to run a trusty provider node.

* As an example, you could start with a fork of bitcoin, allow people to mine coins which they can use to buy provider node tokens. Say the first provider node costs 100 qucoins, the second 200, the third costs 400, etc.

How did u know?! It's already implemented that a provider has to do a lot of calculations to join the network.

Below u'll find a description how Qubic handles and distributes data of the ledger. Unlike Bitcoin, Qubic doesn't use a blockchain, so it doesn't need to store all transaction nor to prune some data:


Consistency of the ledger

All interactions between Qubic providers are non-deterministic. When a provider shares information about a transaction it sends the data to randomly chosen peers. This can lead to a situation when some providers don't see some transactions and hence don't destroy/create qubics. Unreliability of UDP, which is used to transfer data, makes the situation even worse, because some providers don't receive data, although transactions were sent to them. Obviously, the Qubic network must have a way to reach consistency at some point, otherwise differences between copies of the ledger will accumulate, leading to a collapse of the whole system.

Consistency is kept on a periodic basis. This synchronization process is a part of the bootstrapping process, because in the worst case scenario a provider has to download all data just like it's a brand new provider.

Once a day (at 00:00:00 UTC) every provider makes a copy of the ledger and calculates its root hash. This hash lets to compare all existing qubics using a 256-bit number, if there is a difference even in a small piece of two copies of the ledger then these hashes will be different. Every provider asks the others for the root hash and compares its hash to the hash of the quorum, and if there are any differences it requests data necessary to build identical ledger. If a provider is bootstrapped then it downloads entire set of qubics.

It should be noted that the ledger can contain billions of qubics, so the synchronization process can take a lot of time. During this time the provider keeps processing new transactions, working with the original ledger which is changed in real-time.

The synchronization relaxes requirements to Qubic providers. It's not necessary to have a high uptime percentage, a provider can be shut down for a maintenance without serious consequences.

Read more: http://qubic.boards.net/thread/18/consistency-ledger

If two providers have conflicting ledgers, which version wins?

If there are only 2 providers in the system then Qubic doesn't work. If more than 2 then it's necessary to ask other providers to make a decision.

Thank you for your quick answer!

How are the providers determined? Is it simple majority rule to resolve disputes?

If one transaction lands at one provider just before the midnight-synchronization starts, but then many other providers soon after midnight, if the one that landed before midnight a shoe-in to win, on timestamp alone?

Weighted majority rule. The weight is determined by available computing power, similar to Bitcoin.



Every transaction has a timestamp, providers take it into account instead of their local time.

OK, let's say a transaction 'A' arrives at one provider just before midnight, with a 1-minute-before-midnight timestamp. The synchronization process starts. Just after midnight, a conflicting transaction 'B' arrives at many providers, with a 2-minutes-before-midnight timestamp.

Is the more important factor B's earliest timestamp, the fact that only A was at any provider before the day's sync began, the relative computational power of the providers, or other arbitrary lags in the synchronization?

Also, how do providers demonstrate their relative computational power?

There is a "dead" period from 23:59:00 to 00:01:00, any transaction with a timestamp within this period is ignored. When a provider receives a transaction it checks that difference between the timestamp and local time is less than 30 seconds. These tricks let to avoid the described problem.



Once a day (it's adjustable) every provider sends a cryptographic puzzle to the others. The puzzle contains two 256-bit numbers (first_number and second_number). Upon receipt a provider calculates

personal_puzzle1 = Keccak256(first_number, public_key_of_the_provider)
Then it tries to find a 64-bit nonce1 such as

personal_puzzle2 = Keccak256(nonce1, personal_puzzle1)

personal_puzzle2 <= second_number
When nonce1 is found the provider starts searching for nonce2

personal_puzzle3 = Keccak256(nonce2, personal_puzzle2)

personal_puzzle3 <= second_number
and so on.

Nonce1, nonce2, ..., nonceN must be sent back to the original provider within a specific timeframe. More nonces sent -> more work done -> higher weight of the provider is -> more qubics it earns.

Read more: http://qubic.boards.net/thread/12/workers

I can see that helping narrow the windows for problems, but it doesn't really answer what wins in disputes and how things resolve under network stress and malicious attacks.

Say the providers with transaction B are cut off for a few minutes around and after midnight, so they join the synchronization a little late. But they still have a 'valid' earlier timestamp. Did A get an advantage, becoming more likely to 'win', with its small head start?


Interesting, thank you, but I don't see an explanation how these peer-to-peer challenges result in a consensus determination of how many new qubics each provider receives. Is that in another thread/page?

With thousands nodes it doesn't matter if some of them have incorrect data. If u care about double-spending transactions, both transactions will be cancelled (http://qubic.boards.net/thread/14/double-spending).



Each provider decides how much QBC the other providers should get (https://bitcointalk.org/index.php?topic=112676.msg1219095#msg1219095).

I predict that will be problematic, for at least two reasons:

(1) In a large distributed system with many transient failure modes, there can be non-malicious errors that inadvertently create double-spends. Destroying the associated value is quite a harsh penalty.

(2) When arbitrarily many followup transactions depend on a double-spent value, and then some time later the double-spend becomes evident (requiring cancellation): (a) unwinding all followup transactions is hard and disruptive; (b) future compromise of private keys would seem able to retroactively cancel true, honest transactions the holder thought had already completed before the compromise.


Very interesting. Is this based on any other consensus-finding system with any history or study behind it? Preference-aggregation/voting systems are hard.

Does this assume every provider generally knows about (and can judge the minting offers/actions of) every other?

My hunch is that the large uncertainty of supply, and potential for disagreements to leave providers confused or seeking network partitions, could prevent the necessary critical mass of stakeholders and community norms from emerging.

Maybe, we'll test this extensively.



Yes, it's based on Satoshi's assumption which is the base of Bitcoin security.



No. It's enough to know only about a small fraction of other providers.



Will see.

That seems a rather large leap. Satoshi relied on statically fixing some things, and single-threading others (one block wins), to avoid confidence-sapping complexity. You're suggesting a mesh of nodes with only local knowledge can, by a (totally novel?) negotiation protocol, converge on some global minting schedule that all respect.

That might be possible, in theory or in practice - it's an interesting idea. But Bitcoin doesn't provide supporting evidence, unless I'm missing something. Some sort of game-theory analysis, or simulation, or evolved precedents in working systems, would be more convincing.

What would be most helpful in understanding Qubic would be if, like Bitcoin, the essential design decisions were documented in one reference doc. Also great would be some example narrative-transcripts/protocol-time-sequences of regular processes.

Right now not all technical issues resolved. That's why there is no one reference doc yet.

Very interesting! Hope to see it running soon :)

what is the recent situation ?

I'm still thinking about different aspects of Qubic.

wait to see...

Hello CfB,
the web http://qubic.boards.net/ is always downtime recently.
What is wrong with it?

It's up for me.

http://qubic.boards.net/  has been deleted?

Yes. It contained too much outdated info.

And where is some information about Qubic?

So where can find info of Qubic?

I'm going to create a decentralized forum.

Using the NXT blockchain?

DISCLAIMER: In advance apologies if I've got this totally wrong :)

Is the Network PoW similar I wonder in concept the the utility/network/importance participation proofs being proposed in some of the NEM forums.

If you are trying to achieve true decentralisation, how do you take into account that the internet is not decentralised, in fact it is becoming more and more centralised in terms of bandwidth and cpu with cloud based hosting centres...

If you are in a major city in a western country then you can participate well in a network based system, with more bandwidth, faster response times etc...

if you are in a rural area or a less well connected country then your participation will be lower...

This will lead to people in the US for example easily/quickly gaining better reputations than people in africa or eastern europe...

Or perhaps there would be regionalisation so a node in eastern europe would see more network local nodes with which it naturally does more transactions as having more of a reputation then a node in the US which it talks to seldom...
Or is the reputation for a node levelled and set network wide?

Or are you just trying to achieve a logical decentralisation and the whole network could exist on VPS in one data centre?

No idea yet.

Yes. Network PoW is similar to Proof-of-importance of NEM.
Qubic is medium agnostic. Proof of concept version will run on top of UDP. After that I'm going to develop a truly decentralized medium based on WiFi Direct.

Is your decentralized medium like the Skycoin's Meshnet - https://bitcointalk.org/index.php?topic=380441.0 ?

I don't know how Skycoin Meshnet works.

Based on Nxt BC will be very innovative.

how is the Qubic ???

How is Qubic going?, We are eager to see the news on it.

I keep working on Qubic. I found a good solution to the last obstacle, but it requires technical base for the implementation. The solution will be based on Jinn (ternary processor), before Jinn is designed and prototyped I need to create an emulator to prove the concept. Keep an eye on my twitter (@comefrombeyond) for the announcement of Jiniri.

I lock this thread coz I don't use BitcoinTalk anymore.