Advertise with us (we do not endorse any site advertised)

Author Topic: BYTEBALL: Totally new consensus algorithm + private untraceable payments  (Read 15212 times)

0 Members and 1 Guest are viewing this topic.

This topic contains a post which is marked as Best Answer. Press here if you would like to see it.

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
For full technical description, read the white paper: https://byteball.org/Byteball.pdf


Testnet is already online.  Try it out by downloading the wallet:


iOS   Android   Mac   Windows   Linux
or build from source at github


Desktop wallets are full nodes (will take a while syncing with the network after the first start).  Mobile wallets are light clients.

After installing the wallet, visit https://byteball.org and click the clink to receive free bytes to play with.  The link will open your wallet:


The design

There are no blocks in Byteball, and no block size issue.  Instead, every new transaction references one or more earlier ones (parents) by including and signing their hashes.  The links among transactions form a DAG (directed acyclic graph):


By including its parents, each new transaction also indirectly includes and confirms all parents of the parents, parents of the parents of the parents, and so on.  As more transactions are added after your transaction, the number of confirmations you receive grows like snowball, that’s why the name Byteball (our snowflakes are bytes of data).

Consensus

There is no PoW, no PoS, and no mining.  Instead, we have the DAG, which already establishes partial order between transactions, plus we add the main chain within the DAG:


The main chain (MC) allows to define total order between transactions: the transaction which gets included (directly or indirectly) earlier on the MC, is deemed earlier in the total order.  When there is a double-spend, the version of the transaction that comes earlier in the total order is deemed valid, all others are deemed void.

The main chain is defined deterministically based on the positions of transactions in the graph.  Refer to the white paper for details, but as a general rule, the MC gravitates towards transactions authored by well known users, which we call witnesses.  The list of witnesses is defined by users themselves as they include the list in every transaction they post.  The MC then follows the path within the DAG such that:
1. the witness lists of the neighboring transactions on the chain are either identical or differ by only one mutation,
2. the chain goes through the most number of witness-authored transactions, compared with alternative chains.

The above is very brief and sketchy description with many important details omitted, refer to the white paper for a full technical story.

Fees and intrinsic value

The fees paid for storing one’s transactions (or any other data) in the Byteball database are equal to the size of the data being stored.  If your transaction size is 500 bytes, you pay exactly 500 bytes (the native currency of Byteball) in fees.  This means there is intrinsic value in bytes: it is the utility of permanently storing that size of data in a decentralized immutable database.  For data that represents financial transactions, the value is social rather than personal, because you absolutely need to store the full coin history in order to be able to prove the value and authenticity of the coin to each subsequent owner.

The fees are collected partially by those who are first to reference your transaction as parent and partially by witnesses.  The former incentivizes referencing the most recent transactions as parents, which results in the DAG growing in one direction only, like the trunk of a tree, and being as narrow as network latency permits.  If new transactions are rare enough, such that all nodes have enough time to sync before a new transaction appears, the DAG will look almost like a chain, with only occasional forks and quick merges.

Money supply

The total number of bytes is 1015, all bytes will be issued in the genesis transaction. Since the fees paid are returned into the circulation, the money supply will remain the same.

Deterministic finality

In Byteball, there is a protocol rule that a transaction must include the previous transaction (if any) sent from the same address, i.e. there must be partial order between subsequent transactions from the same address.  Breaking this rule is considered equivalent to double-spending, therefore at least one of such unordered transactions will become void.  If we assume that most witnesses follow this rule (that’s what they are elected for), they have to reference only sufficiently recent transactions as parents and can’t inherit from old enough parents.  Therefore, they can no longer influence the MC (which is attracted to witnesses) in the old enough part of the DAG, and that part of the MC becomes stable, hence the total order relative to this MC also becomes stable.  See the white paper for discussion of exact criteria of reaching stability, here it is important that the criteria are deterministic, and once a transaction appears on the stable part of the MC, it is final, and, unlike all other cryptocurrencies, no re-orgs are possible. 

This is extremely important for applications in financial industry and for wider adoption in general, as most people are used to expect certainty in matters of money and property ownership, and the concept of probabilistic finality is a difficult sell.

Assets and on-chain exchange

Bytes is the native currency of Byteball.  Users can issue any other tokens (assets), e.g. to represent debt.  The debt can be expressed e.g. in fiat currencies or in natural units (barrels, ounces, kWh, etc).  The issuers of the debt can reveal their real-world identities and/or be voluntarily attested (i.e. their real-word identities be verified by a well known third party such as CA).  This enables the use of the existing legal system to secure against fraud.

The issued assets can be used as means of payment, along with bytes.  Assets can be exchanged against bytes and other assets by both parties signing a single unit that executes both legs of the exchange, thus the two transactions either happen simultaneously or don't happen at all.  This kind of signing is called multilateral signing.  No centralized exchange is needed, hence no trust is necessary and no exchange fees (apart from the usual fees for the size of the data).

Private untraceable payments

Assets can be either public or private.  All transactions in public assets are visible to everyone on the public decentralized database, just like Bitcoin.  Bytes is a predefined public asset.

Payments in private assets are not published to the public database.  Instead, only the hash of the transaction is stored to the database, while the plaintext of the transaction is sent directly from the payer to the payee.  To protect against double-spends, a spend proof is also published to the Byteball database.  The spend proof is constructed as a hash of the output being spent, so that if the same output is spent twice, the spend proofs will be necessarily the same.

I’ve already described this design at https://bitcointalk.org/index.php?topic=1574508.0, see more details in the white paper.

Regulated assets

Regulated institutions can issue assets that are compatible with KYC/AML requirements. Every transfer of such asset is to be cosigned by the issuer, and if there is anything that contradicts the regulations, the issuer won't cosign.

This way, banks can issue fiat-pegged assets and stay fully compliant.  They can open demand deposit accounts and track them on Byteball as assets.  These assets are easily exchangeable against bytes and other assets (with bank’s approval).

Other features

- Spending conditions (AKA smart contracts) in an easy to understand declarative language https://bitcointalk.org/index.php?topic=1617816.0
- Multisig: a special case of spending conditions
- On-chain oracles can post data (such as timestamps, exchange rates, weather, various events) directly to the database, then that data can be referenced from spending conditions
- Private end-to-end encrypted messaging: used to convey private payment data, communicate in multisig scenarios, and chat with a merchant’s bot.

Initial distribution

There will be no ICO, no crowdsale.  I believe the success of a currency depends on the number of people who own it, in fact Peter R’s research suggests that historical marketcap of Bitcoin follows Metcalfe's law: https://bitcointalk.org/index.php?topic=572106.0, i.e. it is proportional to the square of the number of active users.  That’s why I want Byteball to be in the hands of as many people as possible:


- 98% of all bytes and blackbytes (the private untraceable currency) will be distributed among bitcoin holders who link their bitcoin and byteball addresses before the launch.  No investment required, you keep your bitcoins, plus receive the bytes and blackbytes.
- 1% I reserve for myself


To link your byteball and bitcoin addresses, you’ll need to make a small BTC payment to a one-time bitcoin address created specifically for you.  Next, you consolidate all your bitcoins on the one address you paid from that we know is controlled by you (if you have only one bitcoin address, you skip this step as all your bitcoins are already on a single address).  Then the number of bytes and blackbytes you receive on the launch date will be proportional to the BTC amount on your linked address in a specific bitcoin block (e.g. in block 437000 which is expected late October - early November).  The detailed instructions and the exact block number will be posted later when we get ready for launching the livenet.

Current status and plans

We’ll have a few test flights before we launch in October or November; now the first test flight is under way.  The launch date may be adjusted if we realize that there is more (or less) work to be done before the launch.

How you can help


- play with the wallets, install them on multiple devices, pair them for multisig.  If you find bugs, report them.
- run a relay on your cloud server to help the network. The relay doesn’t hold any private keys, so you don’t have to worry too much about security.  Get relay source code from https://github.com/byteball/byteball-relay
- run a hub to better decentralize the delivery of private payments (the hub also includes a relay).  Again, the security doesn’t matter much as all messages are end-to-end encrypted.  Hub address can be changed by users in their wallet settings.  Get hub source code from https://github.com/byteball/byteball-hub
- fix bugs, contribute improvements in our github repositories https://github.com/byteball.  In particular, we need faster syncing and faster UI.  Before now, I prioritized simplicity of algorithms over performance, now we need speed too.  A 10x improvement should come easy enough, the next 10x will be probably harder.  Discuss any major changes before actually implementing them.
- develop new tools/apps that you think will be useful for Byteball users
- spread the word about Byteball and remember that its value is proportional to the square of the number of active users


Translations: Chinese, German, Italian, Portuguese, Russian.
Twitter: https://twitter.com/ByteballOrg

-----------------------------

One last thing.  The remaining 1% will be given away to the first 100m users who install Byteball wallet, 100 Kbytes to each user.  This will start 6 months from now or later, after we get ready for that scale.
vindynegroup.com


Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #1 on: October 18, 2016, 08:51:54 PM »
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #2 on: November 10, 2016, 06:48:48 PM »
#Byteball version 0.6.0 released.  Important bugfixes https://github.com/byteball/byteball/releases
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #3 on: November 17, 2016, 01:42:44 AM »
Quote from dev of Byteball:

Quote
Finally, you can experience the pre-distribution linking of Byteball and Bitcoin addresses.

We are launching a new testnet, and you'll be able to get a portion of its distribution in proportion to your balance in Bitcoin testnet.

0.  Get your Bitcoin testnet wallet ready and funded.

1.  Download and install the wallet for the new Byteball testnet: https://github.com/byteball/byteball/releases
You will have two Byteball wallets - one for the old testnet that you already have, the other for the upcoming new testnet.

2.  Visit https://byteball.org and click the link to chat with the Transition Bot.  The link will open the new wallet and start a chat.  Follow the instructions of the Transition Bot to prove your Bitcoin balance.


You have two options to prove your Bitcoin balance:
a.  By making a micropayment.  The bot will see your address the payment came from, will know that it is your address, and will instruct you to move your Bitcoins to this address.  By making several micropayments, you can link several Bitcoin addresses to the same Byteball address.
b.  By signing a message (if your Bitcoin wallet supports this function).  You tell the bot your Bitcoin address and sign your Byteball address with the Bitcoin address.  After you prove one address (a typical Bitcoin wallet has dozens of them), you can either move all your coins to this single proven address or prove all other addresses in the same way -- by signing a message.

If you try to link the same Bitcoin address to multiple Byteball addresses, only the last linking counts.

If you prove by micropayment, remember to check that the Bitcoin address that the bot received the micropayment from, is indeed your address.  An attacker might see your payment on the blockchain and repeat the same micropayment from his address trying to trick you to move your funds to him.

3.  After linking, there is no use of the new wallet before the distribution, just keep it installed (backup if necessary).  It will receive the bytes on the distribution day.  If you make any Bitcoin payment, your coins will most likely be moved to a new change address.  Chat with the bot again, see the balance on your linked address(es) and move the coins back to the linked address(es) if necessary.

The linking phase will end in late November, after which we'll do the distribution for the new testnet.  Those who linked their Byteball and Bitcoin addresses will receive new test bytes in proportion to their Bitcoin testnet balances on the distribution day.

If all goes well, we'll do exactly same linking, but with real Bitcoin addresses, from early December to December 25 before the upcoming livenet launch and distribution.
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #4 on: November 17, 2016, 06:00:01 PM »
Current Status and Plans

Currently, the first testnet is online and fully operational.  You can use it to send and receive coins, create multisig wallets, and even buy pizza by talking with a chatbot https://bitcointalk.org/index.php?topic=1608859.msg16330266#msg16330266.

New testnet will be launched in late November based on distribution that is proportional to balances on linked Bitcoin testnet addresses.  To take part in the distribution, see https://bitcointalk.org/index.php?topic=1608859.msg16837694#msg16837694.

Since early December you'll be able to link your livenet bitcoin and byteball addresses.  Livenet launches on December 25, snapshot will be taken from the first block of this day, and the distribution will be proportional to BTC balances on the linked Bitcoin addresses in this block.  10% of bytes and blackbytes will be distributed on this date, the remaining 88% will be distributed in subsequent rounds, see https://bitcointalk.org/index.php?topic=1608859.msg16569906#msg16569906.
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #5 on: November 24, 2016, 11:25:15 PM »
A few Q & A from the past week:





Join #Byteball on slack to keep up on current events!
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #6 on: December 02, 2016, 08:20:12 PM »
Byteball version 0.7.0t released: huge performance improvements and new testnet.
Get it here: https://github.com/byteball/byteball/releases
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #7 on: December 07, 2016, 03:24:54 AM »
From the Byteball dev:

Starting now, you can link your Byteball and Bitcoin addresses for the upcoming distribution.

1. Download and install the wallet for Byteball live network:
Desktop: https://github.com/byteball/byteball/releases
Android: https://play.google.com/store/apps/details?id=org.byteball.wallet
* You will have two Byteball wallets - one for the testnet that you already have, the other for the upcoming live network.

2. Visit https://byteball.org and click the link to chat with the Transition Bot.  The link will open the new wallet and start a chat. Follow the instructions of the Transition Bot to prove your Bitcoin balance.


You have two options to prove your Bitcoin balance:
a. By making a micropayment. The bot will see your address the payment came from, will know that it is your address, and will instruct you to move your Bitcoins to this address. By making several micropayments, you can link several Bitcoin addresses to the same Byteball address.
b. By signing a message (if your Bitcoin wallet supports this function). You tell the bot your Bitcoin address and sign your Byteball address with the Bitcoin address. After you prove one address (a typical Bitcoin wallet has dozens of them), you can either move all your coins to this single proven address or prove all other addresses in the same way -- by signing a message.

If you try to link the same Bitcoin address to multiple Byteball addresses, only the last linking counts.  This rule might be adjusted if we see attempts to link exchange-owned addresses.

If you prove by micropayment, remember to check that the Bitcoin address that the bot received the micropayment from, is indeed your address. An attacker might see your payment on the blockchain and repeat the same micropayment from his address trying to trick you to move your funds to him.

3. After linking, there is no use of the new wallet before the distribution, just keep it installed (backup if necessary).  It will receive the bytes on the distribution day.  If you make any Bitcoin payment, your coins will most likely be moved to a new change address.  Chat with the bot again, see the balance on your linked address(es) and move the coins back to the linked address(es) if necessary.

The linking phase will end on December 24 at 23:59:59 UTC, after which we'll do the distribution in proportion to Bitcoin balances in the first block timestamped after December 25 00:00:00 UTC (Christmas block).  I'll announce the exact block number several hours after this block is mined (the waiting time is to exclude the slightest chance of reorg). The bytes and blackbytes will be sent out in the afternoon of December 25.

During this distribution we'll distribute 10% of the total supply of bytes and blackbytes. The remaining 88% will be distributed during subsequent distribution rounds, exact dates to be announced later. The planned distribution percentages (subject to change):

2nd round: 20%
3rd round: 30%
4th round: 38%


The rounds will be spaced 1 to 2 months.

In each subsequent distribution round, we'll take a new snapshot. The distribution rules in the 2nd and further rounds will be slightly different from the 1st. You'll show both your BTC balances (as in the 1st round) and your balance in bytes (which you received in earlier rounds or bought from other users). You have a sort of basket that consists of a mixture of BTC and bytes. To determine the weight of the basket, every 62.5 MB are counted as 1 BTC. For example, if you have 125 MB and 3 BTC, the weight is 2+3=5 BTC. The distribution of new bytes in the 2nd and subsequent phases will be proportional to the weight of your basket.

My 1% doesn't participate in the 2nd and further rounds.

The ratio 62.5 MB per 1 BTC is chosen so that the total money supply of bytes (1015) and the total number of BTC in circulation (16,000,000) are equivalent.

Earlier adopters have the opportunity to participate in greater number of distribution rounds and receive new bytes in each round by using the same BTC balance and bytes received in previous rounds. You are effectively doubling your stake in each additional round you take part in.

Please retweet https://twitter.com/ByteballOrg/status/806290785486467073
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #8 on: December 11, 2016, 06:23:07 PM »
Some distributions stats: http://transition.byteball.org/

Quote
Total balance linked: 11046.67590134 BTC

Current transition rate: 0.11046676 BTC/gigabyte
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #9 on: December 18, 2016, 04:05:59 PM »
Questions from the community, and answers from the dev, from the main BCT thread.

Question:
Quote
Hi tonych,
After this 25th snapshot, byteball and blackbytes will be distributed as per the rules you announced.
Byteball will be send to linked byteball addresses that reside on "byteball public DAG", I can understand this is completely asynchronous process..
What I cannot understand is about blackbytes distribution:
1) Is it an automatic or interactive process (need human intervention)?
2) Will byteball client with the linked keys on peoples computers need to be left running to receive these coins?
Thanks again.
Answer:
Quote
1) It is automatic.
2) Not necessary, you'll see both bytes and blackbytes as soon as you start the wallet after the coins are sent out.
- tonych


Question:
Quote
Tonych, is the model sort of proof of service? Those that relay the activity and transactions get rewarded some bytes? I read the whitepaper but still am looking for some sort of understanding of this.
Answer:
Quote
It is not a proof-of.
The collected fees are split between regular users who are first to extend the DAG and witnesses who help define the order of transactions.
-tonych

Question:
Quote
Why it is not instant? say if there are 1000 tx per second in the network, my transaction once done will be covered within a second by 50 other transactions, isn't that after 1 second my transaction will have 50 confirmations? If we put 10 confirmations as confirmed, isn't my tx is confirmed after less than 1 sec?
Answer:
Quote
Perhaps you got used to hear about N confirmations in Bitcoin.  There is no such thing here, your transaction is either final or not.  And getting covered advances it to being final.  Getting covered by witnesses matters most (the structure of the DAG after your transaction also matters for finality).  Witnesses earn fees from transactions they cover, and the more transactions per second there are in the network, the more frequently witnesses will post with positive ROI (they pay fees like everybody else).

You will never get sub-second confirmation times because of network latency.
-tonych

Question:
Quote
OK so if I got it correctly, then if the transaction are covered by more than half witnesses' transactions it will be final thus confirmed? Are witnesses always emit transactions? What if none of the witness are doing tx? my tx will never get confirmed?
Answer:
Quote
It'll do as a very rough approximation, see the white paper for the exact criteria of finality.
Witnesses are expected to always emit transactions, that's one of the factors that determines the choice of witnesses.
-tonych

Question:
Quote
This is interesting question. Suppose, each of 12 witnesses run a script which submit transactions at crazy rate, but nobody else is using the network at this time. What happens then? Do witnesses end up loosing money?
Answer:
Quote
Witnesses do post transactions automatically but do it in a bit more reasonable way https://github.com/byteball/byteball-witness/blob/master/start.js
-tonych

Question:
Quote
is there any way planned to increase marketing apart from the sig campaign ?

I think this project will only succeed if we have a lot of users.
Answer:
Quote
Any suggestions are welcome.
We have sig campaign, twitter campaign, and a recent press release which resulted in a few publications.
-tonych

Question:
Quote
Quick Question; can we link multiple BTC addresses to our one Byteball address by sending the micro transaction from each BTC address, and do we have to run the Transition Bot each time?
Answer:
Quote
You can (if you can control which address the payment is sent from, this is an advanced feature).  You just send the same micro-amount to the same address.
-tonych

Reply:
Quote
Incidentally, I finished developing our trustless exchange bot a day ago, just when you started this discussion.  How did you know?
It will exchange only internal assets, not a replacement for poloniex etc.
-tonych
Question:
Quote
Please provide some more details? how to use it? what internal assets you meant? Is it blackbyte? I don't see any other internal assets...
Answer:
Quote
I'll release it in a few days, need to make a few changes to the wallet too.
This version of the exchange will work with public assets only, blackbytes are private.
tonych
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #10 on: December 23, 2016, 04:48:14 PM »
Less than 2 days  remain to link your BTC address for Byteball distribution!
Don't miss out, visit https://byteball.org/ and https://bitcointalk.org/index.php?topic=1608859.0 for more information!

Recent updates from the dev: tonych are quoted below


Quote
Two news for today: version 0.8.0t is released and trustless exchange is launched.

Both are for testnet.
Download the new version from https://github.com/byteball/byteball/releases, Android should auto-update, and the link to the exchange is at https://byteball.org.  Only the new version will work with the exchange.

The exchange allows to exchange public assets issued on Byteball platform, including bytes.  Blackbytes are not covered as they are a private asset.

The exchange is not built-in (as in Nxt, Ripple, and Bitshares), it is an application built on smart contracts.  It is the first application on our network that uses smart contracts.  By keeping the exchange out of the core, we achieve that we don't have to add complexity to the core, as well as greater flexibility in how the exchange can work.

The exchange is centralized and trustless.  Centralized means that there can be many centralized exchanges competing with each other and trying to deliver better product.  Centralized also means that it is run as a business and can be properly managed and marketed.  Trustlessness means that the exchange operator can't steal customer's money, nor can he lose it if the exchange is hacked or mismanaged.  This is achieved by very simple smart contracts that every user can see and verify, and he doesn't need to be a developer to understand them:

To create an order to exchange asset A to asset B, a customer sends his asset A to an address that can be spent:
- by the customer himself after a timeout, or
- by the exchange operator if the same transaction simultaneously sends asset B to the customer (in the specified amount)

The first clause allows the customer to cancel the order and take his money back.  The 2nd clause doesn't give the operator arbitrary control over asset A: the operator can use asset A only if he simultaneously pays asset B to the customer.  This is the key difference from conventional trustful exchanges -- the operator is bound by the contract.

The operator then matches this order with a reverse order from another customer and signs for both sides of the deal simultaneously.

This is what a typical dialog with exchange operator looks like (yes, it is a chatbot, you've already got used to):



Before paying, the customer is presented with a user readable description of the contract:

HXY5... is the asset we are buying (chips).
W272... is the exchange address (actually, it doesn't matter who owns this address as long as the asset is sent to us).

Before the order is executed, the customer can see everything about this smart contract address in his wallet -- its balance and history, and can spend from this address (after the timeout specified in the contract).  The address is presented as a subwallet, it is easy to navigate to and from.

For those who have experience with conventional exchanges, there are a few differences that may seem odd.  Due to how the smart contracts work, there is no partial matching of orders.  To overcome this, orders are split into a small number of standard sized orders.  The standard lot sizes are powers of 2, which allows to match equal-sized orders, as well as some common combinations thereof, such as one large order against two half-sized orders (e.g. 32=16+16).  (Instead of powers of 2, we could also use Fibonacci numbers as standard lot sizes because each size would be equal to the sum of two smaller sizes, e.g. 13=8+5).  That's why when you create an order you usually pay to several addresses.  These sub-orders can match at different time and you'll receive your assets in several standard-sized portions.  Also, placing an order is not instant, you have to wait that the transaction that funds it becomes final.  Obviously, there is no margin trading, and there are no charts in chat.  So, if you are a day trader, it is not for you.  If you need to occasionally buy or sell assets, I think this tool is quite good for you.

Try it for yourself, the new UI is available after upgrading to 0.8.0t, and the link to start a chat with the exchange bot is at https://byteball.org.  Remember, this will work with testnet wallet only.

Please retweet https://twitter.com/ByteballOrg/status/811007135148572672



Quote
Transaction explorer is online https://explorer.byteball.org

It is the coolest transaction explorer in crypto, isn't it?
vindynegroup.com

Marked as best answer by John Ogden on January 03, 2017, 03:04:42 AM

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #11 on: January 02, 2017, 07:04:36 PM »
For full technical description, read the white paper: https://byteball.org/Byteball.pdf

Exchanges: https://cryptox.pl and #book channel on our slack http://slack.byteball.org
Auctions: #auctionroom channel on slack http://slack.byteball.org

Download the wallet:


iOS   Android   Mac   Windows   Linux
or build from source at github


Desktop wallets can be full nodes (will take a while syncing with the network after the first start) or light nodes.  Mobile wallets are always light clients.

If you want to experience the wallet without paying a penny, visit https://byteball.org/testnet.html to install testnet wallet and click the clink to receive free bytes to play with.  The link will open your wallet:


The design
There are no blocks in Byteball, and no block size issue.  Instead, every new transaction references one or more earlier ones (parents) by including and signing their hashes.  The links among transactions form a DAG (directed acyclic graph):



By including its parents, each new transaction also indirectly includes and confirms all parents of the parents, parents of the parents of the parents, and so on.  As more transactions are added after your transaction, the number of confirmations you receive grows like snowball, that’s why the name Byteball (our snowflakes are bytes of data).

Consensus
There is no PoW, no PoS, and no mining.  Instead, we have the DAG, which already establishes partial order between transactions, plus we add the main chain within the DAG:



The main chain (MC) allows to define total order between transactions: the transaction which gets included (directly or indirectly) earlier on the MC, is deemed earlier in the total order.  When there is a double-spend, the version of the transaction that comes earlier in the total order is deemed valid, all others are deemed void.

The main chain is defined deterministically based on the positions of transactions in the graph.  Refer to the white paper for details, but as a general rule, the MC gravitates towards transactions authored by well known users, which we call witnesses.  The list of witnesses is defined by users themselves as they include the list in every transaction they post.  The MC then follows the path within the DAG such that:
1. the witness lists of the neighboring transactions on the chain are either identical or differ by only one mutation,
2. the chain goes through the most number of witness-authored transactions, compared with alternative chains.

The above is very brief and sketchy description with many important details omitted, refer to the white paper for a full technical story.

Fees and intrinsic value
The fees paid for storing one’s transactions (or any other data) in the Byteball database are equal to the size of the data being stored.  If the size of your transaction data is 500 bytes, you pay exactly 500 bytes (the native currency of Byteball) in fees.  This means there is intrinsic value in bytes: it is the utility of permanently storing that size of data in a decentralized immutable database.  For data that represents financial transactions, the value is social rather than personal, because you absolutely need to store the full coin history in order to be able to prove the value and authenticity of the coin to each subsequent owner.

The fees are collected partially by those who are first to reference your transaction as parent and partially by witnesses.  The former incentivizes referencing the most recent transactions as parents, which results in the DAG growing in one direction only, like the trunk of a tree, and being as narrow as network latency permits.  If new transactions are rare enough, such that all nodes have enough time to sync before a new transaction appears, the DAG will look almost like a chain, with only occasional forks and quick merges.

Money supply
The total number of bytes is 10 to the 15th power, all bytes will be issued in the genesis transaction. Since the fees paid are returned into the circulation, the money supply will remain the same.

Deterministic finality
In Byteball, there is a protocol rule that a transaction must include the previous transaction (if any) sent from the same address, i.e. there must be partial order between subsequent transactions from the same address.  Breaking this rule is considered equivalent to double-spending, therefore at least one of such unordered transactions will become void.  If we assume that most witnesses follow this rule (that’s what they are elected for), they have to reference only sufficiently recent transactions as parents and can’t inherit from old enough parents.  Therefore, they can no longer influence the MC (which is attracted to witnesses) in the old enough part of the DAG, and that part of the MC becomes stable, hence the total order relative to this MC also becomes stable.  See the white paper for discussion of exact criteria of reaching stability, here it is important that the criteria are deterministic, and once a transaction appears on the stable part of the MC, it is final, and, unlike all other cryptocurrencies, no re-orgs are possible. 

This is extremely important for applications in financial industry and for wider adoption in general, as most people are used to expect certainty in matters of money and property ownership, and the concept of probabilistic finality is a difficult sell.

Assets and on-chain exchange
Bytes is the native currency of Byteball.  Users can issue any other tokens (assets), e.g. to represent debt.  The debt can be expressed e.g. in fiat currencies or in natural units (barrels, ounces, kWh, etc).  The issuers of the debt can reveal their real-world identities and/or be voluntarily attested (i.e. their real-word identities be verified by a well known third party such as CA).  This enables the use of the existing legal system to secure against fraud.

The issued assets can be used as means of payment, along with bytes.  Assets can be exchanged against bytes and other assets by both parties signing a single unit that executes both legs of the exchange, thus the two transactions either happen simultaneously or don't happen at all.  This kind of signing is called multilateral signing.  No centralized exchange is needed, hence no trust is necessary and no exchange fees (apart from the usual fees for the size of the data).

Private untraceable payments
Assets can be either public or private.  All transactions in public assets are visible to everyone on the public decentralized database, just like Bitcoin.  Bytes is a predefined public asset.

Payments in private assets are not published to the public database.  Instead, only the hash of the transaction is stored to the database, while the plaintext of the transaction is sent directly from the payer to the payee.  To protect against double-spends, a spend proof is also published to the Byteball database.  The spend proof is constructed as a hash of the output being spent, so that if the same output is spent twice, the spend proofs will be necessarily the same.

I’ve already described this design at https://bitcointalk.org/index.php?topic=1574508.0, see more details in the white paper.

Regulated assets
Regulated institutions can issue assets that are compatible with KYC/AML requirements. Every transfer of such asset is to be cosigned by the issuer, and if there is anything that contradicts the regulations, the issuer won't cosign.

This way, banks can issue fiat-pegged assets and stay fully compliant.  They can open demand deposit accounts and track them on Byteball as assets.  These assets are easily exchangeable against bytes and other assets (with bank’s approval).

Other features
- Spending conditions (AKA smart contracts) in an easy to understand declarative language https://bitcointalk.org/index.php?topic=1617816.0
- Multisig: a special case of spending conditions
- On-chain oracles can post data (such as timestamps, exchange rates, weather, various events) directly to the database, then that data can be referenced from spending conditions
- Private end-to-end encrypted messaging: used to convey private payment data, communicate in multisig scenarios, and chat with a merchant’s bot.

Initial distribution
There will be no ICO, no crowdsale.  I believe the success of a currency depends on the number of people who own it, in fact Peter R’s research suggests that historical marketcap of Bitcoin follows Metcalfe's law: https://bitcointalk.org/index.php?topic=572106.0, i.e. it is proportional to the square of the number of active users.  That’s why I want Byteball to be in the hands of as many people as possible:


- 98% of all bytes and blackbytes (the private untraceable currency) will be distributed among bitcoin holders who link their bitcoin and byteball addresses before any of the distribution rounds.  No investment required, you keep your bitcoins, plus receive the bytes and blackbytes.  See below how to receive the coins.
- 1% I reserve for myself


Current status
The network was launched on December 25, 2016, and 10% of bytes and blackbytes distributed to those who linked their Bitcoin and Byteball addresses.  The total balance linked was over 70,000 BTC.

Participation in Byteball distribution
If you missed the 1st round of distribution, you can still participate in the further rounds.  If you were in the 1st round, you can multiply your holdings.  In the second round, which is expected in mid-February, you receive:
- 62.5 MB for every 1 BTC of proven balance
- 0.1 new bytes for every 1 byte (received in the 1st round)

To participate, link your Byteball and Bitcoin addresses before the second round:

1.  Download and install the wallet by following the above links.
2.  Visit https://byteball.org and click the link to chat with the Transition Bot.  The link will open the new wallet and start a chat.  Follow the instructions of the Transition Bot to prove your Bitcoin balance.


You have two options to prove your Bitcoin balance:
a.  By making a micropayment.  The bot will see your address the payment came from, will know that it is your address, and will instruct you to move your Bitcoins to this address.  By making several micropayments, you can link several Bitcoin addresses to the same Byteball address.
b.  By signing a message (if your Bitcoin wallet supports this function).  You tell the bot your Bitcoin address and sign your Byteball address with the Bitcoin address.  After you prove one address (a typical Bitcoin wallet has dozens of them), you can either move all your coins to this single proven address or prove all other addresses in the same way -- by signing a message. 

If you try to link the same Bitcoin address to multiple Byteball addresses, both links are ignored.  If you did this by mistake, link another Bitcoin address.

If you prove by micropayment, remember to check that the Bitcoin address that the bot received the micropayment from, is indeed your address.  An attacker might see your payment on the blockchain and repeat the same micropayment from his address trying to trick you to move your funds to him.

3.  If you make any Bitcoin payment, your coins will most likely be moved to a new change address.  Chat with the bot again, see the balance on your linked address(es) and move the coins back to the linked address(es) if necessary.

The linking phase will end in mid February (exact date to be announced later), after which we'll do the distribution in proportion to BTC and bytes balances on the distribution date.

In the second round, we'll distribute as much as is linked and calculated by the above rules, the exact % is not known in advance. 

The 3rd and subsequent rounds (yet to be announced) will follow similar rules, but the relative weight of bytes vs. BTC in the 3rd and further rounds will change and will gradually increase to 1 BTC=62.5 MB.  It will be selected to maximize the value of bytes and keep the speed of distribution in sync with the growth of user base and the actual use of the network.  The ratio 62.5 MB per 1 BTC is chosen so that the total money supply of bytes (1015) and the total number of BTC in circulation (16,000,000) are equivalent.

We'll have as many rounds as is necessary until all bytes are distributed, the rounds will be spaced 1 to 2 months.

My 1% doesn't participate in the 2nd and further rounds.

Earlier adopters have the opportunity to participate in greater number of distribution rounds and receive new bytes in each round by using the same BTC balance and bytes received in the previous rounds.  You are effectively multiplying your stake in each additional round you take part in.

Track the progress of linking at http://transition.byteball.org.

How you can help
- play with the wallets, install them on multiple devices, pair them for multisig.  If you find bugs, report them.
- run a relay on your cloud server to help the network. The relay doesn’t hold any private keys, so you don’t have to worry too much about security.  Get relay source code from https://github.com/byteball/byteball-relay
- run a hub to better decentralize the delivery of private payments (the hub also includes a relay).  Again, the security doesn’t matter much as all messages are end-to-end encrypted.  Hub address can be changed by users in their wallet settings.  Get hub source code from https://github.com/byteball/byteball-hub
- fix bugs, contribute improvements in our github repositories https://github.com/byteball.  In particular, we need faster syncing and faster UI.  Before now, I prioritized simplicity of algorithms over performance, now we need speed too.  A 10x improvement should come easy enough, the next 10x will be probably harder.  Discuss any major changes before actually implementing them.
- develop new tools/apps that you think will be useful for Byteball users
- spread the word about Byteball and remember that its value is proportional to the square of the number of active users


Translations: Chinese, French, German, Hindi, Indonesian, Italian, Japanese, Korean, Portuguese, Russian, Spanish, Turkish.
Twitter: https://twitter.com/ByteballOrg
Slack: http://slack.byteball.org
Telegram: https://telegram.me/byteball
QQ: 326176030

-----------------------------

One last thing.  The remaining 1% will be given away to the first 100m users who install Byteball wallet, 100 Kbytes to each user.  This will start 6 months from now or later, after we get ready for that scale.
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #12 on: January 10, 2017, 12:27:00 AM »
Some more  Q & A from the main post on BCT forums here: https://bitcointalk.org/index.php?topic=1608859.0
Q = question from a poster.
A = answer from dev - tonych

Quote
Q: Does Byteball have this same problem with extended public keys and private keys? Is it safe to reveal your extended public key provided you don't reveal any of your private keys?
A: We use BIP44 for HD wallets, and it is the same as in Bitcoin, and the same safety measures apply.

Quote
Q: I wondered about this too :) To make a private transaction you need to first pair your device with your counterparty. Doesn't it reveal your ip?
A: The IP is visible to the hub only, not to the counterparty.

Quote
Q: Is the witness list included in transaction and cannot be tampered with?
A: Everything in the transaction, including witness list, is hashed and signed, hence cannot be tampered with.

Quote
Q: Hmm this is interesting. But what about the parents? If the invalid tx gets some parents for the 1st time, he is suppose to get some fees. Will he actually gets it? If so then I can devise an attack by creating massive invalid double spending tx and the only purpose is to grab all the fees related to first time parents.
A: Recipients of fees are selected among valid transactions only.

Quote
Q: That is quite an observation, if that is the case then what is stopping users attacking the network with double spend inputs that have been edited for the same time input, wouldn't both then be accepted at the same time since the timestamps are identical so it wouldn't know which one comes first.
A: There are no timestamps in Byteball protocol.  AFAIK it is the only cryptocurrency that doesn't use clock time at all.  Ordering of transactions is based on Main Chain within the DAG.

Quote
Q: Also, another issue, Ive sewn transactions posted by my wallet containing a witness list, I assume this witness list will evwntually wnd uo in a witness list unit and be untamperable, but is it possible to make a modifyed wallet to send a witness list which is 12witnessws of my own choosing, my witnesses would see the transactio n right, modify the witness list to be 11 real ones plus my own and tske the transaction fee. The other witnesses wouldnt know anything, id just take all/many fees.
A: Witness list unit is a reference to another unit that already lists your witnesses explicitly.  It is just another way to say who your witnesses are when the same witness list is reused.  It saves space, costs only the size of the unit hash (44 bytes) instead of 12 witness addresses (12 * 32 = 384 bytes).

Quote
Q: Here is a question about the second distribution phase: what if I change my Byteball address? Do I lose my 0.1 new byte per 1 byte received in the first round?
A: If you didn't remove your wallet, you still have the old BB address (but your receiving BB address constantly changes, same as in Bitcoin wallets).  If you have a new wallet, you'll have to link again.  I'll announce all the details when we start the linking phase for the 2nd round.

Quote
Q: Let's assume for the sake of argument that 16*106 bitcoins are linked for the second round, so this means that 1015 bytes should be distributed which wouldn't be possible, or am I missing something? Thx.
A: In this unlikely case, we'll distribute the remaining 88% proportionally.

Quote
Q: If the majority of coins remains at your disposal for so long time, how do you think it will affect the adoption by exchanges or other businesses? You may be the most honest person in the world, and will keep all your promises (and I personally believe you will), but how you can prove that to others, so they believe you will not just dump your undistributed coins?
A: Having to keep so many undistributed coins doesn't make me feel comfortable either.  I have to find a balance between distributing fast and distributing wide, which takes more time to allow more people to pull in.  I might move the undistributed funds to a multisig address, I would expect my cosigners to:
- have a long term interest in the success of Byteball at best, or be neutral at least
- be non-anonymous
- have a good reputation in the crypto community
- be trusted not to collude with me or with each other

Quote
Q: No, there no applications on main net yet. There are few example bots on test net. I hope, some applications on main net are coming soon. Tonych is not very active on this thread since after  distribution, I guess he is cocking something to surprise us.
A: Demos of some applications are running on testnet https://byteball.org/testnet.html (need to install a separate wallet), all source code is in our github repos.  Still more to come.
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #13 on: January 16, 2017, 11:06:46 PM »
From original post by dev tonych here: https://bitcointalk.org/index.php?topic=1608859.msg17474758#msg17474758


Two news for today.

TOR support

Now all server based Byteball nodes can connect through TOR.  TOR support in GUI wallets will be added in one of the future releases.  TOR is supported in:

- merchant https://github.com/byteball/byteball-merchant
- headless wallet https://github.com/byteball/headless-byteball

Since Byteball merchants operate in chat interface (unlike web sites), they already don't have to accept incoming connections, therefore don't have to have a publicly known IP address, and TOR support means that they also can hide their IP addresses when making outgoing connections.  This allows them to be completely hidden.  At the same time, customers don't have to use TOR to chat with the merchant bot.

Being able to completely hide one's IP address is even more important for server based wallets that may store large amounts of funds online and be a lucrative target for attackers.  With the IP address hidden, the attackers simply do not know what server to attack, or it is much harder to learn.  So, for headless wallets, TOR allows to achieve better security, not just anonymity.  This is used in the new product which is the subject of our second news today.

Exchange bot that allows to exchange BTC to Bytes and vice versa

The exchange is as easy to use as ShapeShift.  No registration required.  To buy Bytes, you start the chat, send Bitcoins, and a few minutes later you receive the Bytes.  Same for selling Bytes.  You can also create a pending order and hope to get a better deal.



The bot is running on testnet now, see the link at https://byteball.org/testnet.html (you'll need a separate wallet for testnet).

The exchange is trustful, it holds customers' funds, even if it is for a short time.  To minimize risks, the exchange runs through TOR, which makes its IP address unknown to the attackers.  Since it operates in chat and doesn't have to accept incoming connections, you can run the exchange bot even in your bedroom, with the added advantage of being behind NAT.

As another measure to minimize its liabilities and the associated risks, the exchange bot discourages pending orders that are too far from the market price by allowing withdrawals only in the opposite currency and by allowing to modify the order's price only when it accelerates its execution.

Full source code and install instructions are at https://github.com/byteball/btc-exchange.

Please test the exchange on testnet by clicking its link at https://byteball.org/testnet.html, any feedback is appreciated.
vindynegroup.com

Offline John OgdenTopic starter

  • Legendary Member
  • *****
  • Joined: Apr 2014
  • Location: United States
  • Posts: 1748
  • Country: 00
  • Thanked: 2 times
  • Karma: +0/-0
    • View Profile
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
« Reply #14 on: January 22, 2017, 08:15:57 PM »
Some more Q & A from the main post on BCT forums here: https://bitcointalk.org/index.php?topic=1608859.0
Q = question from a poster.
A = answer from dev - tonych

Quote
Q: Wonderful news, does the trading bot works for blackbytes too? I am interested in trading some blackbytes for white bytes...
A: It works for bytes only.
We'll have a bytes-to-blackbytes P2P exchange on the network.

Quote
Q: Ok, thanks. But I meant the transactions made by others (not from/to my wallet) Smiley
Is there any way to see the timestamps on them?

A: There are no timestamps in Byteball protocol, they are just not needed.  That's why there are no reliable timestamps. The ones you see in History tab are the times and dates when your wallet first learnt about the transaction (or, if you are on light wallet, when the light vendor first learnt about the tx).

Quote
Q: Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.

A: If the user waits that the transaction is final, he cannot be defrauded.
In your example, you isolate the merchant from the real network and feed him with a fake branch.  The merchant will accept your units and add them to his version of the DAG, but since there are no witness-authored units on your branch, it will not move the stability point forward and your double-spent payment will stay unconfirmed for as long as your attack continues.  Number of nodes is totally irrelevant, it is the presence of witnesses what makes a branch real.

Quote
Q: Currently, that page is frozen with the balances and linked addresses used for the first round, so for now it is not getting updated. I think it might be the time to unfreeze it and/or maybe keep that state in a separate page: transition.byteball.org/firstround.html for instance, and update the main page with the current links.
A: Thanks for the suggestion, now the transition page updates again, and the balances used in the 1st round are moved to transition.byteball.org/firstround.html.

Quote
Q: This is what I actually supposed. Thanks for confirming that, tonich!
But don't you think such timestamps could be useful for some of the applications of Byteball? I understand they are not needed by protocol, but it could be useful to add them as an comment or "additional info", so it could be easier to trace transactions or analyze the chain. Simple example - I was trying to see when an amount was transferred to some address (some minutes ago or few days ago), and I found no way of using that! This is great for making things more obscure, but I suppose that is not something we want to achieve with Byteball...?

A: Applications are supposed to use timestamps posted by oracles they trust.  There is already one timestamping oracle, its address is I2ADHGP4HL6J37NQAD73J7E5SKFIXJOT and this is one of its recent timestamps https://explorer.byteball.org/#vcwDbSwjOH4h0wdW5M51N92+ivdm8zgBArrdeSHDz5k=.  A similar timestamping oracle on testnet is already referenced from smart contracts of our trustless exchange.

However, choosing which timestamping oracle to trust is entirely up the application, there is no single "official" timestamp.  The best we could do to address the issue you describe above, is showing when a transaction was received by the explorer node.  It's only that - when the tx was received.  If we restart the explorer from scratch, all past transactions will be received within 1-2 hours after it is restarted and these timestamps won't be very useful.

Quote
Q: Right, but how is reputation and marketing in the real world determined algorithmically? If it's just number of votes, couldn't large ICO holders easily make the most txs and thus vote themselves as most reputable, especially when the coin is relatively small like now?
A: This is where the system is anchored to the real world.  If someone feels that witness X should be replaced with witness Y for whatever reason, he can start a campaign and try to convince others to do the replacement (in the current version of the wallet, this can be done only manually in wallet settings).  While some people have already switched to the new witness list and some are still on the old one, all users are able to add their transactions to the DAG because a difference of 1 witness is allowed.  After the change has diffused throughout the network, a new change can be campaigned for and realized.

Obviously, no "votes" from anonymous users can be relied upon in a system with no barriers to entry.  ICO holders don't get any more power automatically just from holding larger bags.

Quote
Q: Can you explain more technically how the change of witness is diffused througout the network?
A: This part is the least technical, just more users accept the new witness list.
Q: Which votes count, anybody making transactions? 1 vote per transaction?
A: As I said, there are no votes.
Q: Btw, does the amount of witnesses, 12, impose limits on transactions/second in any way, or latency for finality?
A: Yes it does.  If we had 1 witness (which would be roughly equivalent to checkpointing that is used in some cryptocurrencies), transactions would confirm faster.  If more than 12, then slower.  See the chapter about finality in the whitepaper, we reach finality when we see the majority of witnesses on certain positions on the DAG.

Quote
Q: Good job. Is there a market for blackbyte / byte or blackbyte / BTC? If not, can users create any two pairs they want, or you have to create them?
A: Only bytes vs BTC so far.
We'll have trustless P2P exchange for trading bytes vs blackbytes.

Quote
Q: ... All the above sounds simple. It's this bit that's causing me a little confusion.


For the bytes you hold on mid-February (to be announced) you receive 0.1 new byte for each 1 byte of your balance, even if your bytes are not on linked Byteball addresses.

You also receive 0.21111 blackbytes for each 1 byte of your balance on the linked Byteball address, which currently is:
YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY  0 GB.

Move your bytes to the linked address in order to maximize the amount of blackbytes you receive.

I signed a message and successfully linked my BTC address to my byteball address.
I have a load of bytes and dark bytes sitting in that wallet also.
Now, why is it telling me I have to move my bytes to YYYYYYYYYYYYYYYYYYYYYYYYYY  ?

Do I need to move resend my own bytes to myself at this YYYYYYYYYYYYYYYYYYYYYYYY  address?

Many thanks in advance.

A: Yes, you need to move bytes to yourself, to your linked address.
To distribute blackbytes, it's not enough to know your BB address, we also need to know your device address in order to send the private payloads.  Since we know this only for your linked BB address (but not for all your other BB addresses), you have to move bytes to the linked address.

Quote
Q: Price is exploding. Lisk please dump now, I want to buy more but cheaper! Max be our friend :-)
A: I'm in contact with Lisk and ICONOMI and they are not going to sell any time soon.
vindynegroup.com


 

[ANN][CLOAK 2.0 ] Private, Secure, Untraceable & Decentralized Digitalcurrency

Started by asn

Replies: 4
Views: 2011
Last post May 31, 2017, 09:18:15 PM
by asn
[ANN] Global Denomination (GDN) - X11 Algorithm 22/04/14 - 28 Hours until Launch

Started by GlobalDenomination

Replies: 0
Views: 2283
Last post April 21, 2014, 08:31:54 AM
by GlobalDenomination
Paypex the solution for online digital payments!

Started by Michael Richard

Replies: 1
Views: 797
Last post November 07, 2017, 04:39:47 PM
by VINCHAIN
Zennies: The easiest And Safest Way To Send And Receive Digital Payments

Started by Michael Richard

Replies: 0
Views: 697
Last post November 28, 2017, 10:49:09 PM
by Michael Richard
Dropil: Smart Investment Trading Algorithm?

Started by neumal

Replies: 0
Views: 442
Last post January 31, 2018, 08:46:22 AM
by neumal

your ads here