Difference between pages "Dev" and "Hardware"

From Obyte Wiki
(Difference between pages)
(updated name)
 
(added Byteduino text from tarmo888)
 
Line 1: Line 1:
This page is for [[Main_Page|Obyte]] developer use. It is not dumbed down at all for non-techies.
+
This is a page about using Obyte with hardware devices: BIoT, Byteduino etc
  
==New bot developers==
+
== BIoT (Byte IoT) ==
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).
+
=== IoT ===
 +
The Internet of things (IoT) is the network of devices such as vehicles, and home appliances that contain electronics, software, sensors, actuators, and connectivity which allows these things to connect, interact and exchange data.
  
To look into how bots are written, see the Github tutorials at https://github.com/byteball/byteballcore/wiki/Writing-chatbots-for-Byteball.
+
The IoT involves extending Internet connectivity beyond standard devices, such as desktops, laptops, smartphones and tablets, to any range of traditionally dumb or non-internet-enabled physical devices and everyday objects. Embedded with technology, these devices can communicate and interact over the Internet, and they can be remotely monitored and controlled.<ref>https://en.wikipedia.org/wiki/Internet_of_things</ref>
  
'''Getting your hands dirty'''<br />
+
=== BIoT ===
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
+
BIoT has been funded with an Obyte grant. It allows you to manage and monitor the process of payment (using Obyte micropayments in [[Dev#Payment_channels|payment channels]]) and communication between devices by using the BIoT client on your smartphone or, for example, the onboard computer of your electric car.<ref>https://hackernoon.com/welcome-to-biot-iot-solutions-on-byteball-platform-94c4d7640f03</ref>
  
'''Headless wallet'''<br />
+
==== Example of payment per use ====
A headless wallet is like a normal wallet, but without user interface, intended for software code interaction with the Obyte DAG.
+
'''Bosch-BIoT: Self-sustaining 3D Printer'''
 +
<youtube>https://www.youtube.com/watch?v=E_cem1cl3a4</youtube>
  
More about headless wallet:
+
The essence of this project is to create a remote 3D printing service. The user uploads a 3D model, then is shown the approximate time and cost of 3D model printing. The cost of printing is calculated by the time spent and the amount of material.<ref>https://hackernoon.com/bosch-biot-self-sustaining-3d-printing-service-f6c925b07355</ref>
*https://github.com/byteball/headless-byteball
 
*https://github.com/byteball/headless-byteball/wiki/Running-RPC-service
 
  
'''Sending payments'''<br />
+
The video shows payment in Bosch Coins, an [[asset]] on the Obyte platform.
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
 
  
'''TESTNET'''<br />
+
== Byteduino ==
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.
+
'''Arduino''' is an open-source hardware and software company, project and user community that designs and manufactures single-board microcontrollers and microcontroller kits for building digital devices and interactive objects that can sense and control both physically and digitally ... Arduino boards are available commercially in preassembled form or as do-it-yourself (DIY) kits.<ref>https://en.wikipedia.org/wiki/Arduino</ref>
  
== Obyte-to-TCP Proxy ==
+
'''Byteduino''' is a light implementation of Obyte for Arduino ESP8266 and ESP32 boards. It requires very little memory, working even on devices with 40 KB of memory.
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.
 
  
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] ).
+
This library is made to help hobbyists and professionals to implement Obyte platform into microcontrollers and build cool and original projects. Currently, this library can connect to a hub, send payments, post datafeeds, cosign transactions, and exchange messages with Obyte wallets through encrypted chat.
  
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.
+
=== Hardware co-signer ===
 +
This is an example project. See Steemit [https://steemit.com/utopian-io/@drsensor/byteduino-create-your-own-hardware-cosigner-for-byteball-1543200264366 article].
  
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.
+
== External links ==
 +
*[https://youtu.be/Rll5JQGNrU0 Video of BIoT system buying something]
 +
*[https://hackernoon.com/biot-real-examples-of-work-of-our-system-20ed741c74a1 Hackernoon article of BIoT examples]
 +
*[https://www.youtube.com/watch?v=JN0o7xjtPhc  BIoT payment-per-use breadboard video]
 +
*[https://biot.ws/ BIoT website]
  
 +
*[https://www.arduinolibraries.info/libraries/byteduino Byteduino in Arduino Library]
 +
*[https://github.com/Papabyte/Byteduino Byteduino Github repo]
  
== Obyte address validation in C++ ==
+
== References ==
<pre>
 
<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>
 
 
 
</pre>
 
 
 
Obyte github repo<ref>https://github.com/byteball/byteball</ref>
 
 
 
==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==
 
 
<references />
 
<references />
  
 
[[Category:Browse]]
 
[[Category:Browse]]

Latest revision as of 15:28, 2 March 2019

This is a page about using Obyte with hardware devices: BIoT, Byteduino etc

BIoT (Byte IoT)

IoT

The Internet of things (IoT) is the network of devices such as vehicles, and home appliances that contain electronics, software, sensors, actuators, and connectivity which allows these things to connect, interact and exchange data.

The IoT involves extending Internet connectivity beyond standard devices, such as desktops, laptops, smartphones and tablets, to any range of traditionally dumb or non-internet-enabled physical devices and everyday objects. Embedded with technology, these devices can communicate and interact over the Internet, and they can be remotely monitored and controlled.[1]

BIoT

BIoT has been funded with an Obyte grant. It allows you to manage and monitor the process of payment (using Obyte micropayments in payment channels) and communication between devices by using the BIoT client on your smartphone or, for example, the onboard computer of your electric car.[2]

Example of payment per use

Bosch-BIoT: Self-sustaining 3D Printer

The essence of this project is to create a remote 3D printing service. The user uploads a 3D model, then is shown the approximate time and cost of 3D model printing. The cost of printing is calculated by the time spent and the amount of material.[3]

The video shows payment in Bosch Coins, an asset on the Obyte platform.

Byteduino

Arduino is an open-source hardware and software company, project and user community that designs and manufactures single-board microcontrollers and microcontroller kits for building digital devices and interactive objects that can sense and control both physically and digitally ... Arduino boards are available commercially in preassembled form or as do-it-yourself (DIY) kits.[4]

Byteduino is a light implementation of Obyte for Arduino ESP8266 and ESP32 boards. It requires very little memory, working even on devices with 40 KB of memory.

This library is made to help hobbyists and professionals to implement Obyte platform into microcontrollers and build cool and original projects. Currently, this library can connect to a hub, send payments, post datafeeds, cosign transactions, and exchange messages with Obyte wallets through encrypted chat.

Hardware co-signer

This is an example project. See Steemit article.

External links

References