SCF Advanced Search


Members
  • Total Members: 13091
  • Latest: Nora
Stats
  • Total Posts: 31877
  • Total Topics: 9595
  • Online Today: 1373
  • Online Ever: 51419
  • (01. January 2010., 10:27:49)











Author Topic: Byteball - Round 9 - full moon of September 6, 2017 at 07:02 UTC  (Read 7219 times)

0 Members and 7 Guests are viewing this topic.

vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + untraceable payments
« Reply #10 on: 02. January 2017., 19:02:34 »
OP has been updated. Round 2 distribution coming in Feb, stay tuned!
vindynegroup.com

Samker's Computer Forum - SCforum.info

Re: BYTEBALL: Totally new consensus algorithm + untraceable payments
« Reply #10 on: 02. January 2017., 19:02:34 »
Sponsored Links:




vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + untraceable payments
« Reply #11 on: 10. January 2017., 00:20:01 »
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

vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + untraceable payments
« Reply #12 on: 16. January 2017., 23:05:32 »
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

vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + untraceable payments
« Reply #13 on: 22. January 2017., 20:13:21 »
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

vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + untraceable payments
« Reply #14 on: 28. January 2017., 00:32:13 »
From the original post by Byteball dev tonych here: https://bitcointalk.org/index.php?topic=1608859.msg17566450#msg17566450


We'll have our 2nd distribution round under the Full Moon, on 11th of February at 0:33 UTC.
We will probably follow the Full Moon calendar for future rounds too.

Bitcoin snapshot will be taken in the first block after the date.
Snapshot of Byteball database will be taken on exactly this date and will include only final transactions.

The transition bot is already working (find the link at https://byteball.org), chat with it to link your Bitcoin address and check the currently linked addresses and their balances.  If you participated in the 1st round, your linked addresses stay the same, you don't need to link again.

The distribution rules:

BTC to bytes: 1 BTC of proven balance gives you 62.5 MB (0.0625 GB)
BTC to blackbytes: 1 BTC of proven balance gives you 2.1111 * 62.5 million blackbytes (money supply of blackbytes is 2.1111 times more than that of bytes)
Bytes to bytes: 1 byte on any Byteball address gives you 0.1 new bytes
Bytes to blackbytes: 1 byte on linked Byteball address gives you 0.21111 blackbytes

If you already hold bytes, please move them to one of the linked BB addresses (chat with the bot to learn what your linked addresses are) before the distribution date to receive your share of blackbytes.  This is a technicall necessity that follows from how blackbytes work: we need to send the private payloads to your device and we know only the device address of the linked BB address, not of any other BB address.  If you don't care about blackbbytes for some reason, you don't need to do anything.  If you didn't touch your bytes after the 1st round (i.e. didn't send or receive a single transaction), you also don't need to do anything since all your bytes are still on the linked address.

Blackbytes that remain undistributed because some people didn't move their bytes to the linked address, will be transferred to a development fund which will be used to pay for future promotion and development.

In this round and at the current market prices, bytes give you a much larger share in the distribution than Bitcoins.  For example, holding 1 GB gives you the same as holding 1.6 BTC:
1 GB -> 0.1 GB
1.6 BTC -> 1.6 * 0.0625 = 0.1 GB
This is one of the nice things about being an early adopter.

Chat with the bot to check the current status or link new Bitcoin addresses and don't forget to move your Bitcoins and Bytes to the linked addresses before the February Full Moon.
vindynegroup.com

vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group
Re: BYTEBALL: Totally new consensus algorithm + untraceable payments
« Reply #15 on: 04. February 2017., 19:46:36 »
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: How will this change going forward regarding the witnesses?  I mean in the selecting of the 12, how long do you plan to carry the whole network?

So if I understand correctly the witnesses are the ones who receive the payload commissions for each transaction. 
Where can we find the info on how much commission are being generated for each transaction?

What about the headers commissions where can we find this for each transaction?


A: You can see all fees in the explorer https://explorer.byteball.org


Quote
A: 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.

Q: Interesting, will it work if one of the devices is offline?

A: Yes.


Quote
Q: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.


A: 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.


Quote
Q: Was there a peer review of "private untraceable payments"* claim?

---
* - taken from the title

A: I proposed similar idea in bitcoin-dev mailing list and it was discussed there.  One of the responses is from Peter Todd https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/012956.html, see others too.

Also there was a technical discussion at https://bitcointalk.org/index.php?topic=1574508 and https://bitcointalk.org/index.php?topic=1298588.0


Quote
Q: I am really interested in seeing some Byteball smart contracts in action. Specifically I would like to know if it is possible to implement a Double Deposit Escrow contract using Blackbytes?
A: 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.


Quote
Q: 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?
A: Yes, you can (if the outputs you are going to spend are already in your copy of the DAG).


Quote
Q: 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...


A: 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.


Quote
Q: @tonych, do you support the claim of SatoNatomato the Expert: "Id say the blackbytes + Tor support makes Byteball more secure and anonymous than even Monero or Zcash." ?

A: 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.


Quote
Q: 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?


A: So far, no exchange has told me that they have any issues with the undistributed coins.


Quote
Q: why does the OS X app try to connect to google?

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


A: What makes you think so?
There are no references to any sites (except the default hub) in the source code.


Quote
Q: 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!


A: Impossible by design.  Too much information to fit on piece of paper.


Quote
Q: 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.org

why do they think its an exchange?


A: 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.


Quote
Q: 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.


A: 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.
vindynegroup.com

vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group



Less than 1 day  left before the 2nd round of Byteball distribution. Link your $BTC address HERE before Feb 11 at 0:33 UTC to participate while there's still time left!
vindynegroup.com

vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group
CLICK HERE FOR DETAILS

Byteball Second Distribution Round Scheduled for Feb. 11 at 0:33 UTC
Just 2 hours left to link up! Don't miss out! Time is running out!




CLICK HERE FOR DETAILS
vindynegroup.com

vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group
Round two distribution stats from the Byteball dev, tonych in original post here: https://bitcointalk.org/index.php?topic=1608859.msg17820043#msg17820043

Quote
The second round is now complete, bytes and blackbytes distributed.

Here are the exact numbers:

17,610.194028342 GB distributed (1.76% of total supply, +17.6% to the previous available supply).
New available supply: 117,610.194028342 GB.

86,658.346197160 GB were on linked addresses at snapshot time and eligible for receiving blackbytes.
37,176.880613233 new GBB (gigablackbytes) in circulation, out of which:
34,360.309831321 GBB distributed,
2,816.570781912 GBB go into the development fund.

Thank you everyone who participated, special thanks to those who supported our new community members and made their experience as smooth as possible, thank you the Transition Bot.

The next round is scheduled for the full moon of March (12 March 14:54 UTC), the conditions are exactly the same as in the 2nd round.

Meanwhile, we continue developing the Byteball ecosystem to bring the power of crypto to regular users.
vindynegroup.com

vindyne8

  • SCF CryptoGroupie
  • *
  • Posts: 785
  • KARMA: 13
  • Gender: Male
    • Vindyne Group
From the original post by Byteball dev tonych here

Version 1.4.0 released - Get it here (click me)

It includes:
* Full backup and restore.  The backup file is compressed, encrypted, and compatible with all platforms
* Improved speed of sync
* Multiple bugfixes



Please upgrade.  Android version is already in Google Play.

If you plan to move your wallet to another device using backup/restore, please close the wallet and don't use it on the first device after creating the backup.  Overlapped use of the same keys on multiple devices can lead to multiple issues such as non-delivered blackbytes and lost chat messages.  If what you want is access to the same money from multiple devices, use multisig instead.
vindynegroup.com

 

With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Name: Email:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image
Type the letters shown in the picture:
Second Anti-Bot trap, type or simply copy-paste below (only the red letters):www.scforum.info:

Enter your email address to receive daily email with 'SCforum.info - Samker's Computer Forum' newest content:

Terms of Use | Privacy Policy | Advertising