Obyte: Totally new consensus algorithm + private untraceable payments

[tonych]

Sorry if this has already been asked...

I'm trying to send 1 GB from my wallet to cryptox.pl, but it changes the quantity I'm sending from 1 to zero. Cryptox is seeing the transaction and confirming, but sees 0 as being sent.

Anyone else having this?

There was a bug, please upgrade to 1.2.0.

[jacaf01]

Version 1.2.0 is released https://github.com/byteball/byteball/releases.
It includes ability to partially recover from seed:



As was said before, the seed doesn't allow to recover blackbytes because they are not stored on the public database.
Recovery works only in full wallets because it scans the local copy of the database for addresses generated from the seed.

To restore your bytes (but not blackbytes) from seed, you will need to download the wallet, choose "Full wallet", wait that it syncs and then go to the Recovery menu in Settings.

Also, a number of small bugs fixed in this release.

Nice work, I saw the update on twitter. Byteball steady progress is great, very soon it will be in the top 10 marketcap, I just hope Poloniex would be rational and list Byteball on their exchange.

[pol5]

   my antivirus displays threats when unpacking and installing a new version of the client. it is a false positive?  I hope that this is just an error       https://supload.com/HkwYB7Mdx

[coinzcoinzcoinz]

New to Byteball; couple of questions that I couldnt figure out myself:

1) what is the difference between bytes and blackbites? Why are there 2 tokens?
2) On Coinmarketcap it says available supply: 100,000 GByte. Why is it called Gbyte there and not bytes?
3) The total supply on Coinmarketcap (100,000), is that the eventual total supply (all coins that will ever exist), or is it the current total supply (10% of the eventual coin supply -- the coins that were released in the first distribution round)?

Thanks!

1) Bytes is the main currency of the Byteball network, is the currency fees are paid in. Blackbytes are a defined asset which can be used for private untraceable exchange of said currency, blackbytes only paying the network fee in bytes.

2) Gbyte because its easier to say and spell out than whole 100 000 000 000, like we use MegaBytes, KiloBytes etc, standard SI notation.

3) Dunno the first post says something about 10^15 total supply, 10% of that is distributed.  

Thanks for the answers! Can someone clarify the current total supply (final total supply-90%) and the final supply (current total supply+90%)? 10^15 can't be right?! Thanks!

There are a total of 1000000 giga bytes. 100000 was distributed.

Wow so you are saying the true market cap is $100 million! Crazy! Byteball is awesome, but it is not worth so much at this stage! I'm staying away for now, but will be participating in the next round of free coins. Really cool project btw, beautiful UI/UX for the wallet as well. I wonder if this is truly the next evolution of decentralized distributed networks, it could be. Vitalik and Satoshi will feel pretty stupid if this stuff turns out to be superior to blockchains.

[escapefrom3dom]

   my antivirus displays threats when unpacking and installing a new version of the client. it is a false positive?  I hope that this is just an error       https://supload.com/HkwYB7Mdx

accordind to 2/56

http://i045.radikal.ru/1702/35/27349509e65d.jpg

it's ok.

[freezal]

Hi tonych,

Shower thought (almost certainly a stupid one as always happens when you don't exert deep thinking, as I haven't finished reading the white paper, and have no time right now to research feasibility):

Would it be possible to optionally (because it changes somewhat the privacy/anonymity model) save assets (including blackbytes) in the public DAG as a compressed and encrypted payload (not much differently of what is saved locally today) paying due commissions?
Maybe we could now use a different seed for each asset to generate private keys for them and some hash of these to encrypt assets payload after each transaction.
Wallets would scan the DAG trying to decrypt asset payloads to get balance and history (some optimizations may apply).
Somehow old saved payloads in the DAG could be pruned as assets carry their own history.

Pro:
- Massive improvement in usability, no need to back-up local assets after each transaction (simplicity is beauty).
Cons:
- Privacy model changes (thus to use it optionally) as now assets history only remains private as long as no one discover a way to decrypt the payload which is now publicly available.
- Increased storage requisites for the DAG (but it'd be optional and has costs)

[Sonny91BE]

Guys is it possible that the wallet is not working correctly ? I wnt to sell on cryptox, I go to send amount of Gbyte and type in the icon on top right corner to scan a QR code provided for deposit by cryptox .. It doesn't respond nor work for me... Anyone know what the issue is

[chikator]

hi i have a question if sended amount is bigger than 0.00069 btc, my btc will be counted? or only direct amount ?

[escapefrom3dom]

hi i have a question if sended amount is bigger than 0.00069 btc, my btc will be counted? or only direct amount ?

sended to what?..

[chikator]

hi i have a question if sended amount is bigger than 0.00069 btc, my btc will be counted? or only direct amount ?

sended to what?..

sended to adress that i created in chat bot

[SHAWN-MIDWAYS]

Guys is it possible that the wallet is not working correctly ? I wnt to sell on cryptox, I go to send amount of Gbyte and type in the icon on top right corner to scan a QR code provided for deposit by cryptox .. It doesn't respond nor work for me... Anyone know what the issue is

Have you tried upgrading your wallet to the latest  version 1.2.0 as the latter might have developed a bug and this update just might have the fix, GL hope it works correctly for you.

[spud21]

hi i have a question if sended amount is bigger than 0.00069 btc, my btc will be counted? or only direct amount ?

sended to what?..

sended to adress that i created in chat bot

Send the exact amount the bot asks for. If you send too much the bot might think it's coming from an exchange address.

[SatoNatomato]

Hi tonych,

Shower thought (almost certainly a stupid one as always happens when you don't exert deep thinking, as I haven't finished reading the white paper, and have no time right now to research feasibility):

Would it be possible to optionally (because it changes somewhat the privacy/anonymity model) save assets (including blackbytes) in the public DAG as a compressed and encrypted payload (not much differently of what is saved locally today) paying due commissions?
Maybe we could now use a different seed for each asset to generate private keys for them and some hash of these to encrypt assets payload after each transaction.
Wallets would scan the DAG trying to decrypt asset payloads to get balance and history (some optimizations may apply).
Somehow old saved payloads in the DAG could be pruned as assets carry their own history.

Pro:
- Massive improvement in usability, no need to back-up local assets after each transaction (simplicity is beauty).
Cons:
- Privacy model changes (thus to use it optionally) as now assets history only remains private as long as no one discover a way to decrypt the payload which is now publicly available.
- Increased storage requisites for the DAG (but it'd be optional and has costs)

There is nothing stopping you from tar/zipping up, encrypting and storing your own blackbytes as data anywhere public, even on Byteball. But thats just reckless in my opinion, aside from increased costs.

There is really no benefit to storing the whole thing in Byteball, if you actually are so certain of your encryption and passwords not getting compromised store it elsewhere were costs are lower. Compared to say storing the data in ipfs and instead paying lower fee by storing the hash to the ipfs data in Byteball. Well actually there is something to explore here.

Like this, tar compress the blackbytes data, encrypt with AES passphrase, the sha256sum of the blackbytes.data.tar.bz2.enc is published to ipfs (you are seeding it now). The sha256sum+salt of your passhprase (or just bcrypt or whatever that thing is called) is published as ipns name pointing to the sha256sum of encrypted data. Now you can look up your blackbytes encrypted data if you know the passphrase and lookup in ipns what the hash to the encrypted data is. This ipns name is what you store in Byteball if you really want.

IPNS, because if you want to update your data, when sending/receiving blackbytes, you publish that, and repoint ipns to the latest blackbytes-encrypted data which you now also seed.

In this way you offload everything to ipfs/ipns and really you dont need to keep any new hashes in Byteball. If you want to help seed/share others encrypted data, and others to help you, well, thats easy if you want to just publish hashes and begin sharing things you dont know what it is, and if you want economical share only other people who also share/constribute, thats more tricky.

I wouldnt do this though.

[tonych]

Hi tonych,

Shower thought (almost certainly a stupid one as always happens when you don't exert deep thinking, as I haven't finished reading the white paper, and have no time right now to research feasibility):

Would it be possible to optionally (because it changes somewhat the privacy/anonymity model) save assets (including blackbytes) in the public DAG as a compressed and encrypted payload (not much differently of what is saved locally today) paying due commissions?
Maybe we could now use a different seed for each asset to generate private keys for them and some hash of these to encrypt assets payload after each transaction.
Wallets would scan the DAG trying to decrypt asset payloads to get balance and history (some optimizations may apply).
Somehow old saved payloads in the DAG could be pruned as assets carry their own history.

Pro:
- Massive improvement in usability, no need to back-up local assets after each transaction (simplicity is beauty).
Cons:
- Privacy model changes (thus to use it optionally) as now assets history only remains private as long as no one discover a way to decrypt the payload which is now publicly available.
- Increased storage requisites for the DAG (but it'd be optional and has costs)

If it were possible, users would have to store huge numbers of decryption keys because every payload has to be encrypted with its own key.  They would convey a subset of these keys (instead of he payloads) to the new owner when making a payment.  The keys are smaller in size than the original payloads but still have to be stored privately and backed up, so the backup problem is not solved.

The best solution of the backup problem is imho multisig.

[vlom]

why does the OS X app try to connect to google?

plus.google.com TCP-Port 443 (https)

[kaicrypzen]

Guys is it possible that the wallet is not working correctly ? I wnt to sell on cryptox, I go to send amount of Gbyte and type in the icon on top right corner to scan a QR code provided for deposit by cryptox .. It doesn't respond nor work for me... Anyone know what the issue is

Can you please describe your issue with more details? Is it your first time on cryptox? There used to be a bug (maybe it's still there) that for displaying the correct QR code, you had to log out and log back in, maybe that's what you are facing ...

[freezal]

Hi tonych,

Shower thought (almost certainly a stupid one as always happens when you don't exert deep thinking, as I haven't finished reading the white paper, and have no time right now to research feasibility):

Would it be possible to optionally (because it changes somewhat the privacy/anonymity model) save assets (including blackbytes) in the public DAG as a compressed and encrypted payload (not much differently of what is saved locally today) paying due commissions?
Maybe we could now use a different seed for each asset to generate private keys for them and some hash of these to encrypt assets payload after each transaction.
Wallets would scan the DAG trying to decrypt asset payloads to get balance and history (some optimizations may apply).
Somehow old saved payloads in the DAG could be pruned as assets carry their own history.

Pro:
- Massive improvement in usability, no need to back-up local assets after each transaction (simplicity is beauty).
Cons:
- Privacy model changes (thus to use it optionally) as now assets history only remains private as long as no one discover a way to decrypt the payload which is now publicly available.
- Increased storage requisites for the DAG (but it'd be optional and has costs)

There is nothing stopping you from tar/zipping up, encrypting and storing your own blackbytes as data anywhere public, even on Byteball. But thats just reckless in my opinion, aside from increased costs.

There is really no benefit to storing the whole thing in Byteball, if you actually are so certain of your encryption and passwords not getting compromised store it elsewhere were costs are lower. Compared to say storing the data in ipfs and instead paying lower fee by storing the hash to the ipfs data in Byteball. Well actually there is something to explore here.

Like this, tar compress the blackbytes data, encrypt with AES passphrase, the sha256sum of the blackbytes.data.tar.bz2.enc is published to ipfs (you are seeding it now). The sha256sum+salt of your passhprase (or just bcrypt or whatever that thing is called) is published as ipns name pointing to the sha256sum of encrypted data. Now you can look up your blackbytes encrypted data if you know the passphrase and lookup in ipns what the hash to the encrypted data is. This ipns name is what you store in Byteball if you really want.

IPNS, because if you want to update your data, when sending/receiving blackbytes, you publish that, and repoint ipns to the latest blackbytes-encrypted data which you now also seed.

In this way you offload everything to ipfs/ipns and really you dont need to keep any new hashes in Byteball. If you want to help seed/share others encrypted data, and others to help you, well, thats easy if you want to just publish hashes and begin sharing things you dont know what it is, and if you want economical share only other people who also share/constribute, thats more tricky.

I wouldnt do this though.

Thank you for your reply.
I think I could understand your suggestions and they are interesting and have their own merits, but the point of my post was to have all this integrated into Byteball.
The goal was to make possible and automated that a mechanism like the one tonych offered today to recover all bytes balances and transactions of any wallet by just typing the seed would also work for assets (blackbytes included).
The idea was to use a generated random seed (not a human password or passphrase) not only to generate keys for assets but, via extra hashes of those keys, to generate a random encryption key for each transaction in order to break traceability of saved payloads.

[Karartma1]

Solved a bug when sending blackbytes with new wallet update (1.2.0) on Android: if anybody experienced the same just update and send it again.
Can't wait for the 11th

[Sonny91BE]

Guys is it possible that the wallet is not working correctly ? I wnt to sell on cryptox, I go to send amount of Gbyte and type in the icon on top right corner to scan a QR code provided for deposit by cryptox .. It doesn't respond nor work for me... Anyone know what the issue is

Can you please describe your issue with more details? Is it your first time on cryptox? There used to be a bug (maybe it's still there) that for displaying the correct QR code, you had to log out and log back in, maybe that's what you are facing ...

This has been the issue. Please report for fellow new users in upcoming events. I had to relog to make it work after activating my stuff !

thanks

[HomoHenning]

why there is no real exchange right now? is this coin a scam?