Difference between pages "Wallet" and "Dev"

From Obyte Wiki
(Difference between pages)
obytewiki_>Admin
(Marked this version for translation)
 
(updated name)
 
Line 1: Line 1:
<languages/>
+
This page is for [[Main_Page|Obyte]] developer use. It is not dumbed down at all for non-techies.
<translate>
 
<!--T:1-->
 
[[File:wallet-dad.jpg|thumb|upright=0.67]]Details of the main (top left) menu and the cogwheel (halfway down on the right) menu; smart wallets
 
  
==Byteball wallets== <!--T:2-->
+
==New bot developers==
 +
If you know next to nothing about Obyte, then download/install a regular '''light''' client like a normal person would, and get familiar with some existing [[chatbot|bots]] in the Bot Store (Chat > Bot Store). The '''full''' client may take a few days to sync up. Same thing goes for the headless wallet (see below) - you can start developing faster if you run the bot also in light mode (by setting conf.bLight value to true).
  
<!--T:3-->
+
To look into how bots are written, see the Github tutorials at https://github.com/byteball/byteballcore/wiki/Writing-chatbots-for-Byteball.
To start, download and install a wallet from those listed at byteball.org or Github: releases<ref>https://github.com/byteball/byteball/releases</ref> (includes win32, but not for XP).  
 
  
<!--T:4-->
+
'''Getting your hands dirty'''<br />
The installation now comes with a default single-address wallet, called "Small Expenses Wallet". You can create additional main wallets. A main wallet can also have smart wallets inside it, created by conditional-payment [[Special:MyLanguage/smart contract|smart contract]]s.
+
What might help most to understand how bots work is to try to get an existing bot working on your machine, such as https://github.com/byteball/email-attestation. If you are able to get that bot running, you can try get any other bot running that can be found on Obyte Github account https://github.com/byteball and after that you are probably ready to start developing your own bot by following the Developer Guides Wiki: https://github.com/byteball/byteballcore/wiki/Byteball-Developer-Guides
  
===Multiple devices=== <!--T:5-->
+
'''Headless wallet'''<br />
 +
A headless wallet is like a normal wallet, but without user interface, intended for software code interaction with the Obyte DAG.
  
<!--T:6-->
+
More about headless wallet:
If you want a connected Byteball wallet on your pc and another one on your Android smartphone, choose the multi-device option [[Special:MyLanguage/wallet#add-wallet|as shown below]]. Don't try to build the second one from the seed of the first: it will probably not function as expected, especially regarding blackbytes.
+
*https://github.com/byteball/headless-byteball
 +
*https://github.com/byteball/headless-byteball/wiki/Running-RPC-service
  
====Convenience vs security==== <!--T:7-->
+
'''Sending payments'''<br />
 +
Look how existing bots send payments:
 +
*https://github.com/byteball/byteball-faucet
 +
*https://github.com/byteball/email-attestation/blob/master/modules/reward.js
 +
*https://github.com/byteball/real-name-attestation/blob/master/modules/reward.js
  
<!--T:8-->
+
'''TESTNET'''<br />
A 1of3 set-up is very convenient, and if one device fails (it happens) it's not a problem when you forgot to back it up. However, it is easier for a thief to get hold of your coins. Encrypting the wallets makes them more secure.  
+
There are commands in `testnetify.sh` file, which need to be run after `npm install` to edit some values in byteballcore library. It will make the bot to communicate with testnet hub, but important thing is to remember that you need to delete your bots existing databases when you already ran the bot on default MAINNET DAG: https://explorer.obyte.org/. Also, TESTNET wallet at https://byteball.org/testnet.html is also not up-to-date with all the features (single-address wallets & private profile requests) that default MAINNET wallet (https://obyte.org/#download) has, so it might be more complicated to develop some features with that wallet app, but the good thing is that you can ask bytes from faucet and write into TESTNET DAG at https://testnetexplorer.byteball.org without worrying that you mess something up.
  
<!--T:9-->
+
== Obyte-to-TCP Proxy ==
A 3of3 set-up is dangerous, because if one device fails -- and the back-up fails too -- you have lost your coins. So try to strike a balance between convenience and security. Different people have different circumstances. Someone living in a college dormitory has a different situation to someone working from their secure home.
+
With the help of this special [[chatbot]] it is possible to develop the actual bot in any programming language. Obyte-to-TCP Proxy ([https://github.com/heathmont/bb2tcp bb2tcp]) listens on the Obyte network like a regular chatbot, except that for each paired device it establishes a new TCP connection to a predefined server. Thus, it acts as a proxy between a custom TCP server and the paired Obyte client device.
  
===Independent or connected?=== <!--T:10-->
+
This software makes it no longer necessary for the Obyte chatbots to be developed in Node.js. Thus, the developer is free to choose whichever programming language they prefer for the bot. What is more, ''bb2tcp'' can be configured to send notifications to a custom server upon any pairing attempts. The latter can be used to implement two-factor or passwordless authentication (for example, see [http://sndd.io Slice&Dice Dungeon] ).
  
<!--T:11-->
+
To implement passwordless authentication with the help of Obyte, the application should present the user with a customly generated QR code. The payload of that QR code should contain a pairing link such as ''obyte:A/SCXz5tNuJDLuCO8PXpsfUoL7dCMBGnvSST7z0YPXjd@byteball.org/bb#'''bki433fsb''''' where the end part (in bold) is randomly generated by the server. When the user scans the given QR code with their Obyte device a pairing attempt with the code ''bki433fsb'' is made and the ''bb2tcp'' chatbot notifies the application by sending the device address and the provided pairing code to the application server. The application server then knows which Obyte device is attempting to authorize themselves so the respective user session's privileges could be elevated immediately without any input from the user.
'''Independent:''' Useful for experimenting, seeing what happens when you interact with another Byteball user in chat. Use (plain) default Small Expenses Wallet on each device.
 
  
<!--T:12-->
+
The ''bb2tcp'' chatbot is developed and maintained by ''@hyena'' from the [https://obyte.slack.com Obyte's official Slack]. All questions and ideas for enhancements are welcome.
'''Connected:''' Useful for security. Will show the same balance and history across all devices.
 
  
===Pairing=== <!--T:13-->
 
  
<!--T:14-->
+
== Obyte address validation in C++ ==
Pairing is between devices, independent of whatever wallets are on those devices. So if you have a 1of2 wallet shared by your pc and your smartphone, and you pair the pc and chat with a friend, the chat will not appear on your smartphone, although the funds will.
+
<pre>
 +
<syntaxhighlight lang="cpp">
 +
#include <stdio.h>
 +
#include <string.h>
 +
#include <openssl/sha.h>
 +
#include <type_traits>
  
===Light/easy or full/hard wallet?=== <!--T:15-->
+
bool is_byteball_addr(const char *addr) {
 +
    static const unsigned char offsets[] = {
 +
          1,  5,  6,  11,  20,  22,  28,  33,
 +
        36,  41,  49,  58,  65,  74,  77,  79,
 +
        82,  90,  94, 100, 102, 108, 112, 115,
 +
        118, 126, 129, 131, 138, 147, 152, 154
 +
    };
 +
    const size_t offsets_sz = std::extent<decltype(offsets)>::value;
 +
    bool bits[32*5];
 +
    unsigned char data[16];
 +
    unsigned char checksum[4];
  
<!--T:16-->
+
    { // Base32 validation and decoding.
Always select the light option unless you REALLY need the full version. If you have funds sent to an address in a full wallet you will be unable to spend them until it finishes synchronizing, and this can take a very long time. The bottleneck seems to be the read/write speed to the hard drive, with an SSD being preferred by far.<ref>https://bitcointalk.org/index.php?topic=1608859.msg19676106#msg19676106</ref>
+
        auto b32 = [](char c) -> unsigned char {
 +
            return ( (c >= 65 && c <= 90) ? (unsigned char) (    c - 65) :
 +
                    (c >= 50 && c <= 55) ? (unsigned char) (26 + c - 50) : 255 );
 +
        };
  
===Single-address wallet=== <!--T:17-->
+
        auto isb32 = [](char c) -> bool {
 +
            return ( (c >= 65 && c <= 90) || (c >= 50 && c <= 55) );
 +
        };
  
<!--T:18-->
+
        size_t i = 0;
A single-address wallet (version 1.11.0 on) you create will not generate the usual new [[Special:MyLanguage/change address|change address]] when needed. Change will always go to the one-and-only address the wallet contains.
+
        char *c = (char *) &(*addr);
 +
        while (isb32(*c) && i < 32) {
 +
            unsigned char value = b32(*c++);
 +
            for (size_t j=0; j<5; ++j) {
 +
                bool bit = (value % 2);
 +
                value /= 2;
 +
                bits[5*i + (4-j)] = bit;
 +
            }
 +
            ++i;
 +
        }
 +
        if (i != 32 || *c) return false;
 +
    }
  
<!--T:19-->
+
    { // Separation of the checksum from the clean data.
You can use single-address wallets to run a manual oracle right from your wallet, without having to run a node on a server.  This allows you to run a [[Special:MyLanguage/Trading prediction markets|prediction market]] for a future event, enable users to make contracts (bets) referencing your address as an [[Special:MyLanguage/Oracle#Personal_oracles|oracle]], and when the outcome of the event is known you post its result from your wallet.
+
        auto bits2bytes = [](bool *b, unsigned char *B, size_t sz) -> void {
 +
            for (size_t i=0; i<sz; ++i) {
 +
                unsigned char byte = 0;
 +
                for (size_t j=0; j<8; ++j) {
 +
                    bool bit = b[i*8 + j];
 +
                    byte ^= (unsigned char) ( (-bit ^ byte) & (1 << (7-j)) );
 +
                }
 +
                B[i] = byte;
 +
            }
 +
        };
  
<!--T:20-->
+
        bool data_bits[128];
In this version you can also manually attest other users and post arbitrary data into the Byteball DAG.
+
        bool checksum_bits[32];
 +
        size_t start = 0;
 +
        size_t data_bit_i = 0;
 +
        size_t checksum_bit_i = 0;
 +
        for (size_t i=0; i<offsets_sz; ++i) {
 +
            for (size_t j=start; j<offsets[i]; ++j) {
 +
                data_bits[data_bit_i++] = bits[j];
 +
            }
 +
            checksum_bits[checksum_bit_i++] = bits[offsets[i]];
 +
            start = offsets[i]+1;
 +
        }
 +
        memcpy(data_bits+123, bits+155, 5); // Add last fragment.
  
====Attestation==== <!--T:21-->
+
        bits2bytes(data_bits, data, 16);
 +
        bits2bytes(checksum_bits, checksum, 4);
 +
    }
  
<!--T:22-->
+
    { // Validate the checksum (requires the openssl/sha.h header).
To facilitate [[Special:MyLanguage/Identity verification|Identity verification]], starting with version 2.1, the default ("Small expenses") wallet of new users is created as single-address (nothing changes for old users). Users can still easily add another wallet and make it multi-address for better privacy. The second wallet is not linked to the user’s verified identity and can be used anonymously.<ref>https://medium.com/byteball/distribution-to-verified-users-and-referrals-ed00b9b2a30e</ref>
+
        SHA256_CTX context;
 +
        unsigned char md[SHA256_DIGEST_LENGTH];
  
==Multiple screens== <!--T:23-->
+
        SHA256_Init(&context);
 +
        SHA256_Update(&context, (unsigned char*) data, 16);
 +
        SHA256_Final(md, &context);
  
<!--T:24-->
+
        if (md[ 5] == checksum[0]
The default wallet is named "Small Expenses Wallet", and has two screens: one for bytes, one for blackbytes. Every [[Special:MyLanguage/Asset|new asset]] you receive (CK1's, [[Special:MyLanguage/Tingos|Tingos]] etc) will create an additional screen just for that asset. If you add a wallet to the default set-up -- maybe "Savings" -- it will start out with two screens again.
+
        &&  md[13] == checksum[1]
 +
        &&  md[21] == checksum[2]
 +
        &&  md[29] == checksum[3]) return true;
 +
    }
  
==Update== <!--T:25-->
+
    return false;
 +
}
  
<!--T:26-->
+
int main( int argc, char * argv [] ) {
When doing a routine update, first do a full back-up using the Byteball menu option (see below) just in case, then simply download the latest version and install it over the top of the existing version. So when you get a prompt saying "you already have [this], do you want to replace it?" click yes. 
+
    int i;
  
==Main menu options== <!--T:27-->
+
    for (i = 1; i < argc; ++i ) {
 +
        bool valid = is_byteball_addr(argv[i]);
 +
        printf( "%s is %s\n", argv[i], valid ? "VALID." : "INVALID!");
 +
    }
  
===Add wallet=== <!--T:28-->
+
    return 0;
 +
}
  
<!--T:29-->
+
</syntaxhighlight>
Choose between PLAIN WALLET and MULTI-DEVICE WALLET, and give it a name. If multi-device (m of n) wallet, choose the total number of co-signers (n), and the required number of signatures (m). For each co-signer (not you), you need to select from the list of paired devices in your library. If the device is not there yet, share a pairing code with it and then select it.
 
  
<!--T:30-->
+
</pre>
A multi-device wallet is duplicated across each of the paired devices, showing the same transactions, addresses, balances etc.
 
  
====Signatures==== <!--T:31-->
+
Obyte github repo<ref>https://github.com/byteball/byteball</ref>
  
<!--T:32-->
+
==Consensus==
*A 1-of-2 set-up means two devices and either one is sufficient to send a transaction.  
 
*A 2-of-2 set-up means two devices and both signatures are needed to send a transaction.  
 
*A 2-of-4 set-up means four devices and two signatures are needed to send a transaction.
 
  
===Paired devices=== <!--T:33-->
+
A Slack #tech conversation 28/29 March 2018.
  
====Contacts==== <!--T:34-->
+
:'''angrytree''' [10:25 PM]: posted in #general, want to see if anyone from [Obyte] can clarify - question about double spending - if a user violates the rule that requires all his txns to have partial order, what's to stop him? do we just go back to the non serial case? for example, if i introduced a pair of conflicting double spending txns, would one be accepted eventually as stated in 4.2? or would both be discarded? if it's the former case, what's the point of introducing the partial order requirement then? looks like witness is used to help with resolving double spending anyway. looks to me, the arbitrary rule of requiring partial order of one's own txns could make [Obyte] prone to censorship attack
  
<!--T:35-->
+
::'''Punqtured''' [10:44 PM]: @angrytree Is what you're trying to learn, whether the platform will be prone to censorship from witnesses? If so, you're right. The witnesses should therefore be entities with "real world value" at stake. If they misbehave, they will not only be rejected as witnesses, but also lose reputation and credibility in the real world. Think of companies that can't accept to be linked to dubious behavior. That's probably the best explanation I can give about the witnesses. The network relies on witnesses and therefore, in theory, they could collude and censor the platform. It would require the majority of witnesses to collude, for it to be effective, though. When witnesses gets decentralized (this is an issue as of yet) it would be unlikely that 6 different companies with 6 different interests would agree to have their name and reputation spoiled by colluding. The witnesses are covered in the presentation from slide 28
This shows a list of all your paired devices, both the user-chosen name (''myputer'' etc) and the permanent device number (0VC...ARM etc). Some you will be able to remove, some you won't. However, if you enter the chat window for that device, there's an Edit button at the top right. One of the options is ''rename'', so at least you can rename "AnnoyingDevice" to "zzAnnoyingDevice" and it will move to the end of your alphabetical list and be out of the way.
 
  
====Bot store==== <!--T:36-->
+
:'''angrytree''' [10:58 PM]: thanks @Punqtured for the explanation :slightly_smiling_face: but what i'm trying to learn right now is mostly the scenario without witnesses, as a clean thought experiment for other DAG consensus algos as well. If I'm required to have partial order of all my own txns, and I want to get my txns "confirmed" as fast as possible, then I'm prone not to include other people's txns as that takes time. If everyone does that, then it poses a risk of censorship. That's what I see the downside in requiring partial order of one's own txns, so I want get to the bottom of why it's needed in the first place :slightly_smiling_face:
  
<!--T:37-->
+
::'''Punqtured''' [11:01 PM]: Why would referencing your own txns be faster than referencing any others'? (edited)
Currently shows about 20 bots. See wiki article [[Special:MyLanguage/Chatbot|Chatbot]] for details.
 
  
===Settings = Global preferences=== <!--T:38-->
+
:'''angrytree''' [11:13 PM]: borrowing bitcoin's example, may not be applicable to [Obyte] - the txns verification takes time + i don't want my competitors to know the most up to date information. Here in [Obyte], seems like only witnesses earn bytes from verifying txns anyway? So I don't see an incentive for normal users to help each other, other than altruism. but what i'm really interested about is just the dag consensus part - partial ordering and double spending
  
<!--T:39-->
+
:::'''HHugh''' [11:22 PM]: From what I understand the fee is split into to categories: header fee and payload fee. Payload fee (about 40% for simple transfers) is equal to the size in bytes of the message; header fee (about 60%) is the balance of the data size. The witnesses collect the payload fee and the header fee goes to whichever user who posts the next child transaction. So a financial incentive exists (however small) to link to childless parent units. Check out pg 17 #13 of the whitepaper for details.
'''Device name:''' Change it if you wish. If you chat to someone, they will see this name
 
  
<!--T:40-->
+
:'''angrytree''' [11:26 PM]: yeah that's right, thx! ^^ would still love to get some clarification with regard to the partial ordering requirement
'''Hub:''' Default is <code>byteball.org/bb</code>. You can change it
 
  
<!--T:41-->
+
:::'''HHugh''' [11:31 PM]: That's beyond me... sorry. Sounds like you're considering forking options?
'''TOR:''' This option is desktop/laptop only. For Android, use the Orbot app
 
  
<!--T:42-->
+
:'''angrytree''' [11:33 PM]: yeah looking at the extreme version of this is hashgraph/nano, where everyone has his own chain, but they have their own problems too
'''Language:''' Select from 18 or so
 
  
<!--T:43-->
+
'''tonych''' [12:18 AM]: @angrytree at least one of the two conflicting transactions will be censored. Not by witnesses, by everybody who follows the protocol.
'''Unit for bytes:''' Select from kB, MB or GB. For safety, use the unit matching your usual expenditures. Otherwise you might intend to send 100kB (0.1 MB) and you send 0.001 GB (1 MB) instead because all the leading zeroes are confusing
 
  
<!--T:44-->
+
:'''angrytree''' [12:30 AM]: @tonych censored? what's the rule?
'''Unit for blackbytes:''' Select from kBB, MBB or GBB
 
  
<!--T:45-->
+
'''tonych''' [12:51 AM]: the rule that txns from the same address must be in partial order
'''Enable push notifications:''' (Android) toggle on or off
 
  
<!--T:124-->
+
:'''angrytree''' [12:52 AM]: no i mean what's the rule for which txn to censor if I have a pair of conflicting double-spending txn?
'''TRUSTED NODES'''
 
  
<!--T:46-->
+
'''tonych''' [12:53 AM]: the one that is later on the main chain
'''Witnesses:''' Easiest to select "Auto-update the witness list from the hub". See wiki [[Special:MyLanguage/Witness|Witness]] article for harder options
 
  
<!--T:125-->
+
:'''angrytree''' [12:55 AM]: hmm you sure? what if they forking off the same parent? even with different parents, how does the clients reach consensus on that? there could be many edge cases. eg. if the attacker send one txn to one set of users; then the other to another set of users
'''Email attestor''' <code>H5EZTQE7ABFH27AUDTQFMZIALANK6RBG</code> is the default. You can change this, but don't unless you know what you are doing.
 
  
<!--T:47-->
+
'''tonych''' [1:04 AM]: there is an unambiguous way to compare transactions. If their MCIs are equal, we compare the hashes.
'''DEVICE ADDRESS:''' <code>0VCPO8MYDRN2E3N5JDRHRSTVEVZSZYARM</code> for example. This doesn't change, and will be visible to anyone you pair with for chat
 
  
<!--T:48-->
+
::::'''Milan Horvath''' [5:32 AM]: I think it would be great to hire an "auditor" company/team to review the white paper for all these questions to have an independent opinion about the consensus mechanism, and about the double spending prevention!
SPENDING RESTRICTIONS<br />
 
'''Request password:''' Lets you set up a password that will encrypt your wallet. Don't forget it! There is no password recovery option
 
  
<!--T:49-->
+
:'''angrytree''' [6:01 AM]: @tonych what about if the attacker shuffles the order of the two conflicting txns, and send to two different sets of users? wouldn't one group censors one, then the other censors the other? how would this be mediated?
'''Backup wallet seed:''' The seed alone will back up your bytes but not your blackbytes. This is important!
 
  
<!--T:50-->
+
'''tonych''' [12:23 PM]: this is a good question and this a basic requirement for every working consensus algo that it should be protected from partitioning.  The answer is that both sets of users must accept both txs.  The order of transactions (hence voiding of the tx that appears to be later) is decided only after they become final, i.e. when reordering of these transactions becomes impossible.
'''Recovery from seed:''' Recovery is available in single-sig (i.e., not multi-sig) light wallets from version 1.10.1. 
 
  
<!--T:51-->
+
:'''angrytree''' [7:40 PM]: when user X broadcasts a txn to group A, and not to group B, will the group A relay this txn to group B (other than just referencing the hash of it as a parent)? i guess since it's asynchronous system, if X broadcasts a conflicting set of double spends, there's no guarantee they will all be "final" at the same round right?
'''Full backup:''' Lets you set a password (don't forget it!) and export a full backup file. You should do a full backup every time you do a blackbytes teansaction. Many people have lost funds because they didn't do a backup.
 
  
<!--T:52-->
+
'''tonych''' [12:31 AM]: @angrytree all transactions are relayed to peers, including the doublespends. Of course, we cannot rely on it. what is a "round"?
'''Restore from full backup:''' Note this will permanently delete all your existing wallets and replace them with whatever is in your backup file. If you created this backup on another device, you should have stopped using the original device wallet immediately after creating the backup. Never clone wallets. If you must access your funds from several devices, use multisig.
 
  
<!--T:53-->
+
:'''angrytree''' [12:33 AM]: thanks! thought that's something normal to do, but don't recall reading in wp. what i meant by "round" was each time the stability point advances - in the context of my last question, there's no guarantee both the double spends get in before the stability point advances right? so some clients may see txn A before the stability point, and that one becomes final, and then the txn B arrives after the stability point. For some other clients, they may have a different view depending on how the conflicting txns are propagated, and get the txn B before the stability point, and txn A after. how does the system deal with this case? also if the double spends order is decided *after* becoming final - that means all the parties will have to do verification again after they are "confirmed"? normally finality == txn sent/received
'''About Byteball:''' Version number, commit hash (developer thing), terms of use, translators credits, session log
 
  
==Cogwheel preferences== <!--T:54-->
+
'''tonych''' [1:12 AM]: this case is just impossible.  Finality means that the transactions cannot be reordered and all nodes agree about the order of transactions before the stability point.  What you describe just contradicts finality. no need to do verification again.  When reaching finality, the doublespends are just marked as such
  
<!--T:55-->
+
:'''angrytree''' [2:52 AM]: so basically is the safety guarantee that all honest nodes in the network have a consistent view of the MCI of all txns up to the stability point? I don't remember reading about how partition is dealt with in detail. also is this the right repo for consensus? - https://github.com/byteball/byteballcore
'''Wallet alias:''' change local name
 
  
<!--T:56-->
+
:'''angrytree''' [3:23 AM]: btw, thanks for your time in the discussion :slightly_smiling_face: really interested in learning about these new consensus algos
'''Color:''' 12 to choose from
 
  
<!--T:57-->
+
'''tonych''' [10:16 AM]: yes, up to the stability point (or the earlier of the stability points of different nodes) all nodes have a consistent view of the ledger. yes this repo
'''Advanced:''' (under next heading)
 
  
===Wallet information=== <!--T:58-->
+
==Payment channels==
 +
Slack post by tonych [2018-04-01 4:22 PM]: Here is how payment channels can be implemented in BB: https://docs.google.com/document/d/19s4LYDfbWDREzVzUwxPuoKANeIGOgPGKV2zI9jTsPSg/edit#
  
<!--T:59-->
+
==References==
'''Wallet name (at creation):''' whatever name you gave it first
+
<references />
  
<!--T:60-->
+
[[Category:Browse]]
'''Wallet ID:''' note this does not change, and is different to all the wallet addresses. If this is a shared multi-sig wallet, the ID will be the same on each of the paired devices
 
 
 
<!--T:61-->
 
'''Wallet configuration (m-n):''' multiple-signature configuration, like 1 of 1, 1 of 2, 2 of 2,  2 of 3 etc
 
 
 
<!--T:62-->
 
'''Derivation strategy:''' BIP44: standard method of deriving new keys for addresses<ref> [https://en.bitcoin.it/wiki/BIP_0044 Improvement Proposal 44]</ref>
 
 
 
<!--T:63-->
 
'''Account (BIP44):''' BIP44 allows the creation of more than one account. If you create a second multi-sig account with a paired device it will show as #2
 
 
 
<!--T:64-->
 
'''CO-SIGNERS'''
 
 
 
<!--T:65-->
 
Shows the co-signers (if any) for this wallet configuration, and which wallet is currently in use. Note the original wallet names are used, not what they may have been changed to
 
 
 
<!--T:66-->
 
'''EXTENDED PUBLIC KEYS:'''
 
 
 
<!--T:67-->
 
*'''Me''' xpub... (this wallet's xpub)  
 
 
 
<!--T:68-->
 
*(Other wallet's name, if multi-sig) xpub... (that wallet's xpub)
 
 
 
<!--T:69-->
 
'''ALL WALLET ADDRESSES:''' (examples shown)
 
 
 
<!--T:70-->
 
65C...AW6<br />
 
m/44'/0'/1'/0/0 · April 19th 2017, 3:00 pm
 
 
 
<!--T:71-->
 
7SV...MMM<br />
 
m/44'/0'/1'/0/1 · April 22nd 2017, 5:47 pm
 
 
 
<!--T:72-->
 
MR3...APD<br />
 
m/44'/0'/1'/1/0 · April 26th 2017, 1:34 pm
 
 
 
<!--T:73-->
 
The m/44'/0'/1'/... designation is part of the BIP44 protocol. Here, the 1' means the second wallet -- the first (small expenses) wallet is designated 0'. The final 0/0 (0/1, 0/2 etc) means the 1st (2nd, 3rd etc) visibly-generated receive addresses; and the final 1/0 (1/1, 1/2 etc) means the 1st (2nd, 3rd etc) automatically-generated [[Special:MyLanguage/change address|change address]]es.
 
 
 
<!--T:74-->
 
'''BALANCE BY ADDRESS:''' (examples shown)
 
 
 
<!--T:75-->
 
7SV...MMM<br />
 
0.04 GBB
 
 
 
<!--T:76-->
 
O3J...YL5<br />
 
0.024402 MB
 
 
 
<!--T:77-->
 
RAZ...LIM<br />
 
0.05966 MB<br />
 
55 Zwib by Jore Bohne (new [[Special:MyLanguage/asset|asset]], registered)<br />
 
576 of 3kc7H8A2oiWr8mv7AcWJeLCA0Cp8c3BLK04kYQ+5pfU= (new asset, unregistered)<br />
 
0.085248 GBB
 
 
 
<!--T:78-->
 
UQX...EC6<br />
 
0.117889 MB
 
 
 
===Sweep paper wallet=== <!--T:79-->
 
 
 
<!--T:80-->
 
*This gives an option to scan QR code of paper wallet private key  
 
*If anyone sees a Byteball paper wallet generator, please tell me (Slackjore)
 
 
 
===Delete wallet=== <!--T:81-->
 
 
 
<!--T:82-->
 
What it says, big red button on the next screen
 
 
 
==Smart wallets== <!--T:83-->
 
 
 
<!--T:84-->
 
When you transact using a smart contract, the funds may go into a smart wallet. One or both parties will be able to unlock this and spend the funds.
 
 
 
===Confirmed funds=== <!--T:85-->
 
 
 
<!--T:86-->
 
You need transactions to confirm before  
 
*A smart wallet first becomes visible  
 
*You can spend funds from it
 
 
 
===Transaction fees are paid in bytes=== <!--T:87-->
 
 
 
<!--T:88-->
 
If you are in a new smart wallet and trying to send blackbytes, or some [[Special:MyLanguage/asset|new asset]] (like [[Special:MyLanguage/Zangos|Zangos]]), it won't have any regular bytes in it to cover the transaction fee. So open the Receive tab, copy the address, paste it into your regular wallet and send some bytes, maybe 0.1 MB. You can easily recover any unspent bytes from this.
 
 
 
====Zero out the smart wallet==== <!--T:89-->
 
 
 
<!--T:90-->
 
Lots of little smart wallets can get confusing. So send all funds, in all currencies, to your regular wallet(s). Send the (white)bytes last, or you won't be able to pay the transaction fees.
 
 
 
<!--T:91-->
 
When all balances in a wallet are zero, it will disappear (hooray!).
 
 
 
<!--T:92-->
 
If you cannot spend the funds, maybe they are locked because the other party needs to spend them. Or some other condition has not been satisfied.
 
 
 
==Backup== <!--T:93-->
 
 
 
<!--T:94-->
 
Full backup is WAY more important than a seed. Full backup keeps your blackbytes, and even better, it means a simple and quick full restore, whereas a restore from seed may require a full node.
 
 
 
==Convert== <!--T:95-->
 
 
 
<!--T:96-->
 
There's no simple way to change from a full wallet to a light one. Usually the need becomes apparent when one has sent GBytes from an exchange to a full wallet and the funds don't show in the wallet because it hasn't sync'd up to the date/time of the transaction. 
 
 
 
<!--T:97-->
 
In this case, follow these steps to get access to your bytes (not blackbytes):
 
 
 
<!--T:98-->
 
#On a separate device, download and install a light wallet
 
#Find someone you trust that has a fully-sync'd full wallet that has zero funds in it. Send that person your seed. They will then restore your wallet on their computer
 
#That person then sends your funds to your new light wallet
 
#Continue to use the light wallet
 
 
 
<!--T:99-->
 
To get access to your blackbytes, either  
 
 
 
<!--T:100-->
 
*Wait until the full wallet syncs, then send the blackbytes to the light wallet (after pairing); or
 
*Send that nice person you trusted with your seed the "User data" data directory (see below), and he can then send you the blackbytes (after pairing).
 
 
 
<!--T:101-->
 
User data directory in Windows, for example, is found at C:\Users\Alice\AppData\Local\byteball\User Data
 
 
 
==Reinstall wallet== <!--T:102-->
 
 
 
<!--T:103-->
 
To start from scratch, you have to rename or delete the Byteball user data folder before reinstalling. '''Be aware that deleting the user data folder results in any existing coins getting lost.''' After you've renamed or deleted this folder, you can do a re-install and choose the wallet type (light/full) again.
 
 
 
===Rename or delete this folder before reinstall=== <!--T:104-->
 
 
 
<!--T:105-->
 
*Windows: %LOCALAPPDATA%\byteball
 
*MacOS: ~/Library/Application Support/byteball
 
*Linux: ~/.config/byteball
 
 
 
===Changing operating systems=== <!--T:106-->
 
 
 
<!--T:107-->
 
It is apparently possible to make a full backup on Windows, and then restore it on Linux. Everything reportedly gets copied including the device address.
 
 
 
==Wallet and explorer differ== <!--T:108-->
 
 
 
<!--T:109-->
 
Does explorer.byteball.org show some new bytes have arrived, but they don't show in your wallet? 
 
 
 
<!--T:110-->
 
'''Wallet not connected properly?''' Your internet connection needs to allow communications to get to and from the wallet: an easy check is do the chatbots work? If the chatbots don't work, maybe showing a Socket Closed [[Special:MyLanguage/error|error]], this lack of proper connection must get fixed.  
 
 
 
<!--T:111-->
 
*Firewall problem?  
 
*Tor turned on by mistake? ('''Check''' this at Settings > TOR, don't just assume it isn't turned on)
 
*Something else wrong?
 
 
 
<!--T:112-->
 
'''Wallet not sync'd?''' If have a full wallet it needs to sync up to the date of a transaction to show it. Then, transfer your coins to a light wallet and when you're sure the coins are in the light wallet dump the full wallet.
 
 
 
<!--T:113-->
 
'''Weird wallet?''' If you have done something weird like "copied"/cloned a wallet from one device to another, or are running more than one instance on a single computer, then you may or may not be able to access these coins. 
 
 
 
<!--T:114-->
 
'''Latest version?''' You '''are''' running the latest version, right?
 
 
 
==Sync problems== <!--T:115-->
 
 
 
===Android=== <!--T:116-->
 
 
 
<!--T:117-->
 
If your phone is taking too long to sync, even with a light wallet, it could be due to blackbytes, and because when the screen fades out it often stops syncing. Activate Developer Mode on Android to get under Settings a new option to keep the screen awake/on when plugged in, and this allows you to sync overnight.
 
 
 
===Full wallet may be better=== <!--T:118-->
 
 
 
<!--T:119-->
 
If you want to do many blackbyte transactions, a light wallet is less efficient than a full wallet to sync blackbytes. So in this case you are better off with a full wallet and thus must have an SSD drive on your laptop/desktop.
 
 
 
==External links== <!--T:120-->
 
 
 
<!--T:121-->
 
*Bitcoin Improvement Proposal 44<ref>https://en.bitcoin.it/wiki/BIP_0044</ref>
 
 
 
==References== <!--T:122-->
 
 
 
<!--T:123-->
 
<references />
 
[[Category:Features]]
 
</translate>
 

Revision as of 17:31, 20 January 2019

This page is for Obyte developer use. It is not dumbed down at all for non-techies.

New bot developers

If you know next to nothing about Obyte, then download/install a regular light client like a normal person would, and get familiar with some existing bots in the Bot Store (Chat > Bot Store). The full client may take a few days to sync up. Same thing goes for the headless wallet (see below) - you can start developing faster if you run the bot also in light mode (by setting conf.bLight value to true).

To look into how bots are written, see the Github tutorials at https://github.com/byteball/byteballcore/wiki/Writing-chatbots-for-Byteball.

Getting your hands dirty
What might help most to understand how bots work is to try to get an existing bot working on your machine, such as https://github.com/byteball/email-attestation. If you are able to get that bot running, you can try get any other bot running that can be found on Obyte Github account https://github.com/byteball and after that you are probably ready to start developing your own bot by following the Developer Guides Wiki: https://github.com/byteball/byteballcore/wiki/Byteball-Developer-Guides

Headless wallet
A headless wallet is like a normal wallet, but without user interface, intended for software code interaction with the Obyte DAG.

More about headless wallet:

Sending payments
Look how existing bots send payments:

TESTNET
There are commands in `testnetify.sh` file, which need to be run after `npm install` to edit some values in byteballcore library. It will make the bot to communicate with testnet hub, but important thing is to remember that you need to delete your bots existing databases when you already ran the bot on default MAINNET DAG: https://explorer.obyte.org/. Also, TESTNET wallet at https://byteball.org/testnet.html is also not up-to-date with all the features (single-address wallets & private profile requests) that default MAINNET wallet (https://obyte.org/#download) has, so it might be more complicated to develop some features with that wallet app, but the good thing is that you can ask bytes from faucet and write into TESTNET DAG at https://testnetexplorer.byteball.org without worrying that you mess something up.

Obyte-to-TCP Proxy

With the help of this special chatbot it is possible to develop the actual bot in any programming language. Obyte-to-TCP Proxy (bb2tcp) listens on the Obyte network like a regular chatbot, except that for each paired device it establishes a new TCP connection to a predefined server. Thus, it acts as a proxy between a custom TCP server and the paired Obyte client device.

This software makes it no longer necessary for the Obyte chatbots to be developed in Node.js. Thus, the developer is free to choose whichever programming language they prefer for the bot. What is more, bb2tcp can be configured to send notifications to a custom server upon any pairing attempts. The latter can be used to implement two-factor or passwordless authentication (for example, see Slice&Dice Dungeon ).

To implement passwordless authentication with the help of Obyte, the application should present the user with a customly generated QR code. The payload of that QR code should contain a pairing link such as obyte:A/SCXz5tNuJDLuCO8PXpsfUoL7dCMBGnvSST7z0YPXjd@byteball.org/bb#bki433fsb where the end part (in bold) is randomly generated by the server. When the user scans the given QR code with their Obyte device a pairing attempt with the code bki433fsb is made and the bb2tcp chatbot notifies the application by sending the device address and the provided pairing code to the application server. The application server then knows which Obyte device is attempting to authorize themselves so the respective user session's privileges could be elevated immediately without any input from the user.

The bb2tcp chatbot is developed and maintained by @hyena from the Obyte's official Slack. All questions and ideas for enhancements are welcome.


Obyte address validation in C++

<syntaxhighlight lang="cpp">
#include <stdio.h>
#include <string.h>
#include <openssl/sha.h>
#include <type_traits>

bool is_byteball_addr(const char *addr) {
    static const unsigned char offsets[] = {
          1,   5,   6,  11,  20,  22,  28,  33,
         36,  41,  49,  58,  65,  74,  77,  79,
         82,  90,  94, 100, 102, 108, 112, 115,
        118, 126, 129, 131, 138, 147, 152, 154
    };
    const size_t offsets_sz = std::extent<decltype(offsets)>::value;
    bool bits[32*5];
    unsigned char data[16];
    unsigned char checksum[4];

    { // Base32 validation and decoding.
        auto b32 = [](char c) -> unsigned char {
            return ( (c >= 65 && c <= 90) ? (unsigned char) (     c - 65) :
                     (c >= 50 && c <= 55) ? (unsigned char) (26 + c - 50) : 255 );
        };

        auto isb32 = [](char c) -> bool {
            return ( (c >= 65 && c <= 90) || (c >= 50 && c <= 55) );
        };

        size_t i = 0;
        char *c = (char *) &(*addr);
        while (isb32(*c) && i < 32) {
            unsigned char value = b32(*c++);
            for (size_t j=0; j<5; ++j) {
                bool bit = (value % 2);
                value /= 2;
                bits[5*i + (4-j)] = bit;
            }
            ++i;
        }
        if (i != 32 || *c) return false;
    }

    { // Separation of the checksum from the clean data.
        auto bits2bytes = [](bool *b, unsigned char *B, size_t sz) -> void {
            for (size_t i=0; i<sz; ++i) {
                unsigned char byte = 0;
                for (size_t j=0; j<8; ++j) {
                    bool bit = b[i*8 + j];
                    byte ^= (unsigned char) ( (-bit ^ byte) & (1 << (7-j)) );
                }
                B[i] = byte;
            }
        };

        bool data_bits[128];
        bool checksum_bits[32];
        size_t start = 0;
        size_t data_bit_i = 0;
        size_t checksum_bit_i = 0;
        for (size_t i=0; i<offsets_sz; ++i) {
            for (size_t j=start; j<offsets[i]; ++j) {
                data_bits[data_bit_i++] = bits[j];
            }
            checksum_bits[checksum_bit_i++] = bits[offsets[i]];
            start = offsets[i]+1;
        }
        memcpy(data_bits+123, bits+155, 5); // Add last fragment.

        bits2bytes(data_bits, data, 16);
        bits2bytes(checksum_bits, checksum, 4);
    }

    { // Validate the checksum (requires the openssl/sha.h header).
        SHA256_CTX context;
        unsigned char md[SHA256_DIGEST_LENGTH];

        SHA256_Init(&context);
        SHA256_Update(&context, (unsigned char*) data, 16);
        SHA256_Final(md, &context);

        if (md[ 5] == checksum[0]
        &&  md[13] == checksum[1]
        &&  md[21] == checksum[2]
        &&  md[29] == checksum[3]) return true;
    }

    return false;
}

int main( int argc, char * argv [] ) {
    int i;

    for (i = 1; i < argc; ++i ) {
        bool valid = is_byteball_addr(argv[i]);
        printf( "%s is %s\n", argv[i], valid ? "VALID." : "INVALID!");
    }

    return 0;
}

</syntaxhighlight>

Obyte github repo[1]

Consensus

A Slack #tech conversation 28/29 March 2018.

angrytree [10:25 PM]: posted in #general, want to see if anyone from [Obyte] can clarify - question about double spending - if a user violates the rule that requires all his txns to have partial order, what's to stop him? do we just go back to the non serial case? for example, if i introduced a pair of conflicting double spending txns, would one be accepted eventually as stated in 4.2? or would both be discarded? if it's the former case, what's the point of introducing the partial order requirement then? looks like witness is used to help with resolving double spending anyway. looks to me, the arbitrary rule of requiring partial order of one's own txns could make [Obyte] prone to censorship attack
Punqtured [10:44 PM]: @angrytree Is what you're trying to learn, whether the platform will be prone to censorship from witnesses? If so, you're right. The witnesses should therefore be entities with "real world value" at stake. If they misbehave, they will not only be rejected as witnesses, but also lose reputation and credibility in the real world. Think of companies that can't accept to be linked to dubious behavior. That's probably the best explanation I can give about the witnesses. The network relies on witnesses and therefore, in theory, they could collude and censor the platform. It would require the majority of witnesses to collude, for it to be effective, though. When witnesses gets decentralized (this is an issue as of yet) it would be unlikely that 6 different companies with 6 different interests would agree to have their name and reputation spoiled by colluding. The witnesses are covered in the presentation from slide 28
angrytree [10:58 PM]: thanks @Punqtured for the explanation :slightly_smiling_face: but what i'm trying to learn right now is mostly the scenario without witnesses, as a clean thought experiment for other DAG consensus algos as well. If I'm required to have partial order of all my own txns, and I want to get my txns "confirmed" as fast as possible, then I'm prone not to include other people's txns as that takes time. If everyone does that, then it poses a risk of censorship. That's what I see the downside in requiring partial order of one's own txns, so I want get to the bottom of why it's needed in the first place :slightly_smiling_face:
Punqtured [11:01 PM]: Why would referencing your own txns be faster than referencing any others'? (edited)
angrytree [11:13 PM]: borrowing bitcoin's example, may not be applicable to [Obyte] - the txns verification takes time + i don't want my competitors to know the most up to date information. Here in [Obyte], seems like only witnesses earn bytes from verifying txns anyway? So I don't see an incentive for normal users to help each other, other than altruism. but what i'm really interested about is just the dag consensus part - partial ordering and double spending
HHugh [11:22 PM]: From what I understand the fee is split into to categories: header fee and payload fee. Payload fee (about 40% for simple transfers) is equal to the size in bytes of the message; header fee (about 60%) is the balance of the data size. The witnesses collect the payload fee and the header fee goes to whichever user who posts the next child transaction. So a financial incentive exists (however small) to link to childless parent units. Check out pg 17 #13 of the whitepaper for details.
angrytree [11:26 PM]: yeah that's right, thx! ^^ would still love to get some clarification with regard to the partial ordering requirement
HHugh [11:31 PM]: That's beyond me... sorry. Sounds like you're considering forking options?
angrytree [11:33 PM]: yeah looking at the extreme version of this is hashgraph/nano, where everyone has his own chain, but they have their own problems too

tonych [12:18 AM]: @angrytree at least one of the two conflicting transactions will be censored. Not by witnesses, by everybody who follows the protocol.

angrytree [12:30 AM]: @tonych censored? what's the rule?

tonych [12:51 AM]: the rule that txns from the same address must be in partial order

angrytree [12:52 AM]: no i mean what's the rule for which txn to censor if I have a pair of conflicting double-spending txn?

tonych [12:53 AM]: the one that is later on the main chain

angrytree [12:55 AM]: hmm you sure? what if they forking off the same parent? even with different parents, how does the clients reach consensus on that? there could be many edge cases. eg. if the attacker send one txn to one set of users; then the other to another set of users

tonych [1:04 AM]: there is an unambiguous way to compare transactions. If their MCIs are equal, we compare the hashes.

Milan Horvath [5:32 AM]: I think it would be great to hire an "auditor" company/team to review the white paper for all these questions to have an independent opinion about the consensus mechanism, and about the double spending prevention!
angrytree [6:01 AM]: @tonych what about if the attacker shuffles the order of the two conflicting txns, and send to two different sets of users? wouldn't one group censors one, then the other censors the other? how would this be mediated?

tonych [12:23 PM]: this is a good question and this a basic requirement for every working consensus algo that it should be protected from partitioning. The answer is that both sets of users must accept both txs. The order of transactions (hence voiding of the tx that appears to be later) is decided only after they become final, i.e. when reordering of these transactions becomes impossible.

angrytree [7:40 PM]: when user X broadcasts a txn to group A, and not to group B, will the group A relay this txn to group B (other than just referencing the hash of it as a parent)? i guess since it's asynchronous system, if X broadcasts a conflicting set of double spends, there's no guarantee they will all be "final" at the same round right?

tonych [12:31 AM]: @angrytree all transactions are relayed to peers, including the doublespends. Of course, we cannot rely on it. what is a "round"?

angrytree [12:33 AM]: thanks! thought that's something normal to do, but don't recall reading in wp. what i meant by "round" was each time the stability point advances - in the context of my last question, there's no guarantee both the double spends get in before the stability point advances right? so some clients may see txn A before the stability point, and that one becomes final, and then the txn B arrives after the stability point. For some other clients, they may have a different view depending on how the conflicting txns are propagated, and get the txn B before the stability point, and txn A after. how does the system deal with this case? also if the double spends order is decided *after* becoming final - that means all the parties will have to do verification again after they are "confirmed"? normally finality == txn sent/received

tonych [1:12 AM]: this case is just impossible. Finality means that the transactions cannot be reordered and all nodes agree about the order of transactions before the stability point. What you describe just contradicts finality. no need to do verification again. When reaching finality, the doublespends are just marked as such

angrytree [2:52 AM]: so basically is the safety guarantee that all honest nodes in the network have a consistent view of the MCI of all txns up to the stability point? I don't remember reading about how partition is dealt with in detail. also is this the right repo for consensus? - https://github.com/byteball/byteballcore
angrytree [3:23 AM]: btw, thanks for your time in the discussion :slightly_smiling_face: really interested in learning about these new consensus algos

tonych [10:16 AM]: yes, up to the stability point (or the earlier of the stability points of different nodes) all nodes have a consistent view of the ledger. yes this repo

Payment channels

Slack post by tonych [2018-04-01 4:22 PM]: Here is how payment channels can be implemented in BB: https://docs.google.com/document/d/19s4LYDfbWDREzVzUwxPuoKANeIGOgPGKV2zI9jTsPSg/edit#

References