I meant to say that when you receive the asset you receive all its past historic data, like today I think. You'd receive the whole thing unencrypted from the sender.
Then you'd encrypt it with a seed generated new key of yours and save everything back as a payload in the public DAG (forget about compression as this data probably shouldn't compress well anyway, addresses, signatures, etc.).
When it comes time to send these tokens to someone, your wallet would have retrieved it from the DAG, unencrypt it with you key (calculated from your seed), maybe save it in your local database (which now function as a local cache) as it does today, generate the new transaction and send it to the counterpart using the same mechanism as it does today. Then the process would repeat all over again by the new receiver.
Note that after each transaction reaches finality state, the payload of the previous transaction could somehow be pruned as not needed. As today any owner of a token could only access previous history of it and wouldn"t be allowed to see future transactions.
I see what you mean, the data to be stored would be huge (megabytes) in this case. The pruning part is not trivial too, because 3rd-party nodes don't know what data is already not needed. |
|
|
|
Will there be a way to backup private assets via a seed in the future?
I love paper wallets and it's a shame I can't make one for Blackbytes!
Impossible by design. Too much information to fit on piece of paper. How much data are we talking about? If you can store the right amount of data on a blockchain/DAG, you can store an encrypted backup there. Then, all you'd need would be a) the passphrase/seed to decrypt the data b) some means to find the relevant data on the blockchain/DAG. You wouldn't need a dedicated function for it, you could do it on your own. You could store it on some other blockchain as well, if you'd want to. Obviously, you'd have to pay for the transaction when storing data, so this would probably be only suitable for long term holding. It's megabytes, and you'll have to re-encrypt and store the data again every time it changes. I'm afraid it would be too expensive to store your personal data in Byteball. Byteball was designed to store data of social value: data that matters for all members of the ecosystem who transfer money-like assets to each other and need the database to track their origins and verify their validity. When you are not using these features and only using plain storage, you are overpaying. |
|
|
|
Sent my transaction from my bitgo wallet and received this message from Transaction bot I received 0.0015 BTC from 3QcomrVZo8T7XARRVYziJg3B8BqkzcZs2D but this transaction looks like it was sent from an exchange, which is not allowed. Please send BTC only from a wallet that you own private keys for. If you think it was a mistake, please contact tonych@byteball.orgwhy do they think its an exchange? I already replied you by email: See here https://blockchain.info/address/3QcomrVZo8T7XARRVYziJg3B8BqkzcZs2D, there are too many outputs that’s why we detect it as an exchange (transactions sent from regular wallet usually have 2 outputs). Please use a wallet where you control the private keys. |
|
|
|
Will there be a way to backup private assets via a seed in the future?
I love paper wallets and it's a shame I can't make one for Blackbytes!
Impossible by design. Too much information to fit on piece of paper. |
|
|
|
why does the OS X app try to connect to google?
plus.google.com TCP-Port 443 (https)
What makes you think so? There are no references to any sites (except the default hub) in the source code. |
|
|
|
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. The idea was to generate those encryption keys from the random generated seed. When you need a random address for bytes you calculate/generate it from the seed. Encryption keys could be generated from a seed too (one seed for each asset class maybe for security reasons, i.e. one for blackbytes, other for asset X and etc.). If they are generated from a seed, only the seed need to be saved (one time operation). If you already generate private keys from a seed for each non spended asset (I don't really know), you could generate encryption keys from those pks by calculating some hash from them, not needing an extra seed only for the encryption keys. I assume you are not suggesting system-wide seed which would then be known by everybody  If the seeds are per user, the problem remains. A user can encrypt his own transactions but he has to also store and forward (when sending balckbytes) the coin histories which include previous transactions created by other users. Then he has to know the keys that these previous owners used to encrypt their private payloads, and the number of these keys is as large as the number of previous owners of each coin. The best solution of the backup problem is imho multisig.
Yes, this works but maybe not for all scenarios. For high values and strict security models of some institutions (for instance, cold wallets) it's hard to imagine that your back-up depend on many devices on-line syncing between them. If the other idea works (which is unlikely cause it must have any number of flaws), only the seeds would need to be backed-up. I see your point. I'm suggesting multisig for hot wallets as used by regular users, it allows to avoid the pain of having to backup after each transaction. When you use cold wallets, I assume that convenience is not your primary concern and the transactions are rare, in this case having to backup after each transaction is not such a big issue compared with other steps you have to do to unlock the cold wallet. Note that you can split the backup into two parts: the seed, which is small and can be stored on paper wallet, and the private payloads stored in the sqlite database. Even if the private payloads are stolen, they cannot be used without the seed, hence your privacy might be affected but the security is not compromised. |
|
|
|
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. |
|
|
|
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. |
|
|
|
We recently updated our transaction explorer https://explorer.byteball.org. Now it shows detailed information about transactions in blackbytes:  This is all we know about them. |
|
|
|
Great job tonych. Is this update mandatory?
It is not mandatory but highly recommended. |
|
|
|
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. |
|
|
|
I am really interested in seeing some Byteball smart contracts in action.
"This language is already used in Byteball, you can view the source code and create tools that make use of the language."
A guide for this would be really useful!
Specifically I would like to know if it is possible to implement a Double Deposit Escrow contract
using Blackbytes?
There's really TONS of potential here and I'm really surprised this thread hasn't gotten much love.
Smart contracts are already in action on the trustless exchange on testnet https://byteball.org/testnet.html. It is possible to implement a better contract than Double Deposit Escrow, see the fedex example above. It's not "better" than double deposit escrow! Thats crazy talk. The fedex example doesn't work because fedex doesn't know the CONTENTS of the box. Double deposit escrow is meant to stop deception forever. This means only the two parties involved know about the truth of the deal. A tracking number system can be gamed by filling boxes with incorrect items or making them empty. It can harm buyer on purchases and seller on returns (depending on who the platform favors). Double deposit is superior to all escrow systems and it always will be due to its purity. There is no middleman in DDE, thats the point. It forces both parties to put a deposit and only they can sign off on it. Oracles are no different from judges and juries. Biased third parties that have no knowledge of the truth beyond superficial guesses. WITH THAT SAID, Byteball is doing something new and amazing. They are enhancing the p2sh multisig accounts by making them much more legible. Instead of n of m keys they can give different keys weight which eliminates the need for redundant keys. So its basically better multisig. Byteball can do double deposit escrow pretty easily with this in a couple transactions using a Halo protocol. If they have locktimes they can even do it in one elegant transactions (not sure what codebase supports but would highly recommend locktimes) Correct, this fedex example is not ideal because the contents of the box are not guaranteed. However, a similar contract can be applied to other transactions where the contents of the "box" are known in advance and not gameable. For example, a cryptocurrency exchange transaction wherein transaction output serves the same role as tracking number. DDE, while also possible with Byteball, is not ideal either: it is more complex because requires two coordinated steps, it is more capital intensive because it requires deposits, and it fails to admit that the two parties might have different perceived value of money, hence the party that needs money more and faster is more willing to unlock the deposits ASAP, therefore more vulnerable. Legibility of smart contracts is of utmost importance indeed. It empowers the users to actually use the smart contracts and move money in ways that were not available to them before crypto, reduce the requirement of trust (and therefore regulation) without making the developer of the contract a new trust anchor. |
|
|
|
Is Cryptox being extremely slow for anyone else today? Under DDoS?
It would be so nice to get on another exchange. First for liquidity, some people will not touch tiny, obscure exchanges and secondly price checker apps dont include obscure exchanges either so its not possible to set up any alerts on ByteBalls price. Is there anything stopping BB from getting on Bittrex? I believe their requirements are very easy to meet. I think only 20% max of premine can be held by the dev to get listed. Tonych may be able to make them one of the multisig holders that control the rest ..so they perhaps would list it then This needs to be done then. Bigger exchanges likely have similar requirements. If byteball is just listed on one small, obscure exchange for another year or however long it takes to distribute the rest potential growth will really be obstructed. Tonych any plans to address this limitation? So far, no exchange has told me that they have any issues with the undistributed coins. |
|
|
|
Id say the blackbytes + Tor support makes Byteball more secure and anonymous than even Monero or Zcash.
I hope noone will really believe the quoted words, or they may find themselves in serious troubles... Now you are just trolling and spreading fear with only these three dots ... to back it up, because your own shit coin iota is worthless. @tonych, do you support the claim of SatoNatomato the Expert? I think the privacy features of all 3 coins are more or less the same for most practical purposes. What differs, and what matters most for regular users, is usability. |
|
|
|
I think I won't wait for SatoNatomato's response, it will likely contain only nonsense. I'll explain my concern right away:
Byteball uses witnesses. There are 2 ways to choose the witnesses:
1. They are picked by every user for himself
2. They are elected via global voting
If it's #1 then it becomes possible that some users are almost isolated from each other because they have only few common witnesses. #2 leads to a more serious problem which arises if a user is faced with more than 2 options (just google why it's a serious problem, there should be many links with mathematical proofs on impossibility of coming to a satisfying consensus). The problem of picking an option has already striked twice in the cryptoindustry. First it was Ripple/Stellar consensus flaw drama when Stellar admitted to have a flawed consensus while Ripple decided to make appearance they were fine (heh, they had enough money not to care about community opinion). The second time which I remember it was Factom drama, now I can't find the links, but in few words: they "sold" a flawed voting mechanism which was unfixable because they allowed more than 2 options.
So my concern is that cryptocoin developers don't take voting seriosly. I noticed this several years ago in Bitshares. Back then I was thinking that voting is easy, only after working with two professors (on two separate tasks) who were specializing in voting I got that it's all actually not that simple...
Voting is not easy indeed, and there is no voting in Byteball consensus. Instead, there is a requirement that witness lists of neighboring (and not just neighboring - see the white paper for details) units on the DAG are compatible. Compatible means that they differ by no more than one mutation. This is similar to biology where the genes of a parent and child are very similar but not the same, and the genes of any member of the same species are also similar but not identical. |
|
|
|
If you installed the full wallet can you send a transaction before its synced?
With Bitcoin and most altcoin wallets you can send a transaction before they are fully synced provided the wallet shows it contains your coins. Is byteball the same?
Yes, you can (if the outputs you are going to spend are already in your copy of the DAG). |
|
|
|
I am really interested in seeing some Byteball smart contracts in action.
"This language is already used in Byteball, you can view the source code and create tools that make use of the language."
A guide for this would be really useful!
Specifically I would like to know if it is possible to implement a Double Deposit Escrow contract
using Blackbytes?
There's really TONS of potential here and I'm really surprised this thread hasn't gotten much love.
Smart contracts are already in action on the trustless exchange on testnet https://byteball.org/testnet.html. It is possible to implement a better contract than Double Deposit Escrow, see the fedex example above. |
|
|
|
Any idea why this is happening?! Worked before (connected my BTC adress)... using 1.1.1
Please right click and select both "Inspect" and "Inspect background page". Send me what you see in the Console. Uncaught Error: More than one instance of bitcore-lib found. Please make sure to require bitcore-lib and check that submodules do not also include their own bitcore-lib dependency. Secp256k1 bindings are not compiled. Pure JS implementation will be used. Please make sure that the program is started from "C:\Program Files", not "c:\Program Files" (with capital C). If it is not, edit the paths on the start icon. There is one oddity in how node.js works on Windows. |
|
|
|
It's for this reason that it is necessary to save completely the directory of the byteballs, not just seed
Yeah, but you must save it after each transaction lol. It's very hard and here can be some other problems. Like an empty balance You must not, if you are using multisig: ... private assets, such as blackbytes, are stored only in the wallet (exactly because they are private) and get updated every time you send or receive a private asset.
To secure against loss of the wallet, I recommend that you use multisig. For example, 1-of-2 multisig with one wallet on the phone, the other on a desktop computer. This way, the private assets will be automatically copied to the two devices. Interesting, will it work if one of the devices is offline? Yes. |
|
|
|
|
Show Posts
. 
