Bitcoin Forum
June 29, 2022, 06:16:14 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Alternate cryptocurrencies / Bounties (Altcoins) / [Referral][Contest][Sig][DeFi] Bonded Stablecoins Referral Program $3,000 weekly on: November 17, 2020, 01:09:40 AM

Bonded Stablecoins Referral Program + Contest

Bonded Stablecoins Referral Program pays up to 10% of the referral's balance every week.  The referral is also rewarded (up to 5%).

Participate in the referral program by having your referral link in your Bitcointalk signature and in other content you create.  Win prizes for the best content.

About Bonded Stablecoins

Bonded stablecoins is a novel type of stablecoins that are issued on two-dimensional bonding curves.  They can be pegged to any asset such as USD, BTC, stocks, etc, or to an asset plus interest -- these coins grow as they accrue interest, they are called stable+ coins.

There is no overcollateralization when issuing the coins and no risk of liquidations.

They run on Obyte network, which is a DAG, not a blockchain, hence there is no risk of front-running and miner manipulation.

It is the first major DeFi product on a DAG.

Obyte network is live since 2016, it is one of the first DAG chains, and the first to support dapps.

IUSD: a USD-pegged stable+ coin, 16% interest

IUSD is the most popular stable+ coin.  It is pegged to USD + 16% per year, i.e. its target price in USD programmatically grows at 16% per year, and it allows to earn 16% interest.  The price was exactly 1 USD on September 22, 2020 when it was launched, and its target price will be 1.16 USD one year later on September 22, 2021.  Now it is worth 1.0232 USD.

OUSD is a companion token pegged to USD, it is a stablecoin.  We get it by stripping interest off IUSD.

GRD is another companion token, it is a governance token and its price grows as more IUSD are issued.  Currently, it is worth about $50,000 and the supply is very small.

IBIT: a BTC-pegged stable+ coin, 11% interest

There are similar BTC-pegged tokens:
- IBIT is a stable+ coin that earns 11% interest in BTC;
- OBIT is a stablecoin pegged to BTC;
- GRB is the corresponding governance token.

There are similar tokens pegged to other assets.

Find more details at Bonded Stablecoins website

Referral program

You are rewarded for getting new users into bonded stablecoins. Your referrals are rewarded too, so they get a better deal by clicking your referral link.

- referrer gets up to 10% of the referral's balance every week;
- the referral gets up to 5% of their balance every week.

The total weekly payout is capped by $3,000. So, if the sum of all referrer 10% and referral 5% rewards exceeds $3,000, all rewards are scaled down so that the total is $3,000.

The rewards are paid in IUSD.

Get your referral link from
All details:


To participate in the referral program on Bitcointalk, please use one of these signatures:

Full Member

[center][url=][color=#333][font=arial black][b][font=Century gothic][u]O[/u][/font]  Bonded Stablecoins[/b][/font][/color]     [i][font=Arial black][color=#90a7fd]│[color=#0037ff]█   [color=#333]Earn [color=#0037ff]16%[/color] interest in USD, [color=#0037ff]11%[/color] in BTC[/color]   █[/color]│[/color][/font][/i]
[font=calibri][color=#555]Use my link to get additional referral rewards (up to 5% of your balance every week)[/color][/font][/url]
[color=#90a7fd][font=arial black][i]││ │  │   │    │     │[/i][/font]     [url=][font=arial black][b][color=#333][color=#0037ff]The first DeFi[/color] on a DAG[/color][/b][/font][/url] [color=#b4cff0]│[/color] [url=][b][font=Verdana][color=#456c91]◯byte[/color][/font][/b][/url]     [font=arial black][i]│     │    │   │  │ ││[/i][/font][/color]

Sr Member

████▀         ▀████
████             ████
▐███               ███▌
▐███               ███▌
███▄             ▄███
▀███▄           ▄███▀
▀████▄▄     ▄▄████▀
[url=][font=arial][size=12pt][b][color=#333]Bonded Stablecoins[/size][/font][/td]
[td][size=20pt][font=arial black][i][color=#90a7fd]│[color=#0037ff]█[/font][/size][/td]
[td][center][url=][font=Impact][size=15pt][i][color=#333]Earn [color=#0037ff]16%[/color] interest in USD, [color=#0037ff]11%[/color] in BTC[/size][/font]
[size=7pt][font=Arial][color=#555]Use my link to get additional referral rewards (up to 5% of your balance every week)[/font][/size][/td][td][/td]
[td][size=20pt][font=arial black][i][color=#0037ff]█[color=#90a7fd]│[/font][/size][/td][td][/td]
[td][url=][b][font=arial][size=11pt][color=#333][color=#0037ff]The first[/color] DeFi
on a DAG[/size][/font][/td]
[td][url=][size=2pt][tt][color=#456c91]      ▄▄█████████▄▄
   ▄███▀▀       ▀▀███▄
  ██▀               ▀██
 ██▀                 ▀██
██▀                   ▀██
██                     ██
██                     ██
██▄                   ▄██
 ██▄                 ▄██ ▄
  ██▄               ▄██  █▄▄▄  ▄   ▄ █▄▄▄  ▄▄▄
   ▀███▄▄       ▄▄███▀   █   █ █   █ █    █▄▄▄█
      ▀▀█████████▀▀      ▀▄▄▄▀ ▀▄▄▄█ ▀▄▄▀ ▀▄▄▄▄

Hero - Legendary Member

████▀         ▀████
████             ████
▐███               ███▌
▐███               ███▌
███▄             ▄███
▀███▄           ▄███▀
▀████▄▄     ▄▄████▀
[url=][font=arial][size=12pt][b][color=#333]Bonded Stablecoins[/size][/font][/td]
[td][size=20pt][font=arial black][i][color=#90a7fd]│[color=#4b70fa][color=#0037ff]█[/font][/size][/td][td][/td][td][/td]
[td][center][url=][font=Impact][size=15pt][glow=#d1e6fe,1][color=transparent]........[i][color=#333]Earn [color=#0037ff]16%[/color] interest in USD, [color=#0037ff]11%[/color] in BTC[/color].........[/size][/font]
[size=7pt][font=Arial][color=#555]Use my link to get additional referral rewards (up to 5% of your balance every week)[/font][/size][/td][td][/td]
[td][size=20pt][font=arial black][i][color=#0037ff]█[color=#4b70fa][color=#90a7fd]│[/font][/size][/td][td][/td]
[td][url=][b][font=arial][size=11pt][color=#333][glow=#0037ff,1][color=#0037ff].[color=#fff]The first[/color].[/color][/glow] DeFi
on a DAG[/size][/font][/td]
[td][url=][size=2pt][tt][color=#456c91]      ▄▄█████████▄▄
   ▄███▀▀       ▀▀███▄
  ██▀               ▀██
 ██▀                 ▀██
██▀                   ▀██
██                     ██
██                     ██
██▄                   ▄██
 ██▄                 ▄██ ▄
  ██▄               ▄██  █▄▄▄  ▄   ▄ █▄▄▄  ▄▄▄
   ▀███▄▄       ▄▄███▀   █   █ █   █ █    █▄▄▄█
      ▀▀█████████▀▀      ▀▄▄▄▀ ▀▄▄▄█ ▀▄▄▀ ▀▄▄▄▄

AVATAR (optional)

Please edit the signature code and replace USERADDRESS with your Obyte address.
Find your full referral link at and after setting up the signature please verify that the link matches.

The signature codes above are for Full Member and higher ranks. Lower-ranked users can use a text link in their signature, e.g. "Bonded stablecoins: earn 16% interest in USD" (use your own link you get from

There is no requirement of being of certain rank or frequent posting, you make money when someone clicks your link, buys coins, and holds them.

Getting referrals from other media

In addition to (or instead of) your Bitcointalk signature, you can post your referral link in other media where you can get referrals:
- blogs;
- tweets;
- posts;
- newsletters;
- videos;
- public profiles;
- etc.

The best content will be rewarded with prizes:


Whenever you create content promoting Bonded Stablecoins, please post a link to this content in this thread in order to be considered for the contest.

The prizes are:
- 500 IUSD for the best video;
- 500 IUSD for the the best article or forum post (own blog, bitcointalk, reddit, medium, steem, hive, etc);
- 100 IUSD for the best tweet.

The contest is active for 1 month, submissions end on Dec 17 at 23:59:59 UTC, winners to be announced on Dec 20. Rules are subject to change at our discretion.

After the contest ends, we might decide to have another round.

Please help the jury (Obyte team) decide about the best entries: if you liked someone's post or video, please reply to this thread and say why you think it's good.

Suggestions about other prize categories are welcome.

Wearing the signature is not required to participate in the contest but would help promote your referral link.

The content should be in English to be eligible for the contest. Other languages might be accepted, please contact us in advance.

Obyte should be mentioned in your posts/videos.

Use your referral link in the content, so you can make money even if you don't win any prize.

Obyte core team members are welcome to create content but won't be taken into consideration for the prizes.

Summing up

Steps to acquire referral rewards from your Bitcointalk signature

- get your referral link from (you might need to install Obyte wallet if you don't have one yet);
- set up your signature using the codes above and replacing USERADDRESS with your actual address;
- after your next post, mouse over the links in your signature and check that the links to have your referral code, this is to make sure that your referrals are correctly assigned to you.

Steps to participate in the contest

- go to and learn more about Bonded Stablecoins;
- buy a small amount of any tokens, e.g. IUSD, for a trial (you might need to install Obyte wallet if you don't have one yet, and buy some GBYTEs first);
- get your referral link from;
- write an article, a post, or record a video, and include your referral link;
- post a link to the article/post/video in this thread.

Main thread:
2  Alternate cryptocurrencies / Altcoin Discussion / Declarative smart contracts in Byteball on: September 15, 2016, 03:00:01 PM
When you entrust your money to a smart contract, you want to be absolutely sure that the contract operates as you expect (remember TheDAO?).  One way to achieve this is by having a smart contract language that is designed to express what the contract expects, rather than how it accomplishes its goals.  This is exactly what declarative languages do.

The purpose of this post is to introduce the declarative smart contract language I chose for Byteball, the cryptocurrency I recently launched.  The language is designed to be as easy to understand as possible, so that even non-developer can immediately see what a contract means by just looking at its code.  The language values clarity over power and it is not as powerful as Ethereum's Solidity.  It is not turing-complete, and you cannot write even 'Hello world' program in this language.  But it is able to solve many practical business tasks.

Money in Byteball are stored on addresses.  Address is just a hash (plus checksum) of an address definition, and the address definition is an expression in the Byteball smart contract language that evaluates to either true or false.

Here is an example of the simplest address definition that defines an address controlled by a single private key:


The pubkey above is base64-encoded public key.  The expression evaluates to true if the signature provided with the transaction is valid and produced by the private key that corresponds to the above public key.  The address (checksummed hash in base32) corresponding to this definition is A2WWHN7755YZVMXCBLMFWRSLKSZJN3FU.

All expressions in this language evaluate to a boolean value, and multiple boolean subexpressions can be combined using boolean operators.  For example, this is a definition that requires two signatures:

["and", [
  ["sig", {pubkey: "one pubkey in base64"}],
  ["sig", {pubkey: "another pubkey in base64"}]

To spend funds from the address equal to the hash of the above definition, one would need to provide two signatures.

As you noticed, we use JSON to construct the language expressions.  This is an unusual choice but allows to use existing well-debugged, well-supported, and well-optimized JSON parsers rather than invent our own.

"Or" condition can be used to require signatures by any one of the listed public keys:

["or", [
  ["sig", {pubkey: "laptop pubkey"}],
  ["sig", {pubkey: "smartphone pubkey"}],
  ["sig", {pubkey: "tablet pubkey"}]

The above is useful when you want to control the same address from any of the 3 devices: your laptop, your phone, and your tablet.

The conditions can be nested:

["and", [
  ["or", [
    ["sig", {pubkey: "laptop pubkey"}],
    ["sig", {pubkey: "tablet pubkey"}]
  ["sig", {pubkey: "smartphone pubkey"}]

A definition can require a minimum number of conditions to be true out of a larger set, for example, a 2-of-3 signature:

["r of set", {
  required: 2,
  set: [
    ["sig", {pubkey: "laptop pubkey"}],
    ["sig", {pubkey: "smartphone pubkey"}],
    ["sig", {pubkey: "tablet pubkey"}]

("r" stands for "required") which features both the security of two mandatory signatures and the reliability, so that in case one of the keys is lost, the address is still usable and can be used to change its definition and replace the lost 3rd key with a new one.

Also, different conditions can be given different weights, of which a minimum is required:

["weighted and", {
  required: 50,
  set: [
    {weight: 40, value: ["sig", {pubkey: "CEO pubkey"}] },
    {weight: 20, value: ["sig", {pubkey: "COO pubkey"}] },
    {weight: 20, value: ["sig", {pubkey: "CFO pubkey"}] },
    {weight: 20, value: ["sig", {pubkey: "CTO pubkey"}] }

A definition can contain reference to another address:

["and", [
  ["address", "ADDRESS 1 IN BASE32"],
  ["address", "ADDRESS 2 IN BASE32"]

which delegates signing to another address and is useful for building shared control addresses (addresses controlled by several users).  This syntax gives the users the flexibility to change definitions of their own component addresses whenever they like, without bothering the other user.

A subdefinition may require that the transaction be cosigned by another address:

["cosigned by", "ANOTHER ADDRESS IN BASE32"]

One very useful condition can be used to make queries about data previously stored in Byteball:

["in data feed", [
  ["ADDRESS1", "ADDRESS2", …],
  "data feed name",
  "expected value"

This condition evaluates to true if there is at least one previous message stored in Byteball database that has "data feed name" equal to "expected value".  The data feed must be posted to Byteball decentralized database by one of the oracles whose addresses are "ADDRESS1", "ADDRESS2", ...  Since oracles post to the common database, we call them on-chain oracles.

On-chain oracles are a very powerful thing indeed.  For example, this address definition represents a binary option:

["or", [
  ["and", [
    ["address", "ADDRESS 1"],
    ["in data feed", [["EXCHANGE ADDRESS"], "EURUSD", ">", "1.1500"]]
  ["and", [
    ["address", "ADDRESS 2"],
    ["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">", "2016-10-01 00:00:00"]]

It relies on two oracles, one is posting EUR/USD exchange rate, the other is posting the current time.  Initially, the two parties fund the address defined by this definition by sending their respective stakes to the address.  Then if the EUR/USD exchange rate published by the exchange address ever exceeds 1.1500, the first party can sweep the funds.  If this doesn’t happen before Oct 1, 2016 and the timestamping oracle posts any later date, the second party can sweep all the funds stored on this address.

Another example would be a customer who buys goods from a merchant but he doesn’t quite trust that merchant and wants his money back in case the goods are not delivered.  The customer pays to a shared address defined by:

["or", [
  ["and", [
    ["address", "MERCHANT ADDRESS"],
    ["in data feed", [["FEDEX ADDRESS"], "tracking", "=", "123456"]]
  ["and", [
    ["address", "BUYER ADDRESS"],
    ["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">", "2016-10-01 00:00:00"]]

The definition depends on the FedEx oracle that posts tracking numbers of all successfully delivered shipments.  If the shipment is delivered, the merchant will be able to unlock the money using the first condition.  If it is not delivered before the specified date, the customer can take his money back.  This example is somewhat crazy because it requires FedEx to post each and every shipment.  See the white paper for a more practical way to achieve the same result.

A definition can also include queries about the transaction itself, which can be used for example to code limit orders on a decentralized exchange.  Assume that a user wants to buy 1,200 units of some asset for which he is willing to pay no more than 1,000 bytes (the native currency of Byteball).  Also, he is not willing to stay online all the time while he is waiting for a seller.  He would rather just post an order at an exchange and let it execute when a matching seller comes along.  He can create a limit order by sending 1,000 bytes to an address defined by this definition:

["or", [
  ["address", "USER ADDRESS"],
  ["and", [
    ["address", "EXCHANGE ADDRESS"],
    ["has", {
      what: "output",
      asset: "ID of alternative asset",
      amount_at_least: 1200,
      address: "USER ADDRESS"

The first or-alternative lets the user take back his bytes whenever he likes, thus cancelling the order.  The second alternative delegates the exchange the right to spend the funds, provided that another output on the same transaction pays at least 1,200 units of the other asset to the user’s address.  The exchange would publicly list the order, a seller would find it, compose a transaction that exchanges assets, and sign it together with the exchange.  Note that the exchange does not receive arbitrary control over the user's funds, it can spend them only if it simultaneously pays the alternative asset to the user, while the user retains full control over his funds and can withdraw them from the contract when he likes.

You can combine the above and a few other boolean constructs (see the white paper) to encode many of the clauses you are likely to see in real-life legal contracts.  And the language is clear, straightforward, and it directly expresses the intent of the contract parties.

This language is already used in Byteball, you can view the source code and create tools that make use of the language.

3  Alternate cryptocurrencies / Announcements (Altcoins) / Obyte: Totally new consensus algorithm + private untraceable payments on: September 05, 2016, 04:00:28 PM
For full technical description, read the white paper:

Former name: Byteball.

Exchanges: Bittrex, Cryptox, Bit-Z, Stealthex, and trading bot (find it in the Bot Store in the wallet)
If you are trading large blocks and don't want to move the price, trade P2P via smart contract (without human escrow)
Prediction markets (sports betting, binary options): find a peer on our discord
Insurance: find a peer on our discord

Download the wallet:

iOS   Android   Mac   Windows   Linux
or build from source at github

Desktop wallets can be full nodes (will take a while syncing with the network after the first start) or light nodes.  Mobile wallets are always light clients.

If you want to experience the wallet without paying a penny, visit to install testnet wallet and click the link to receive free bytes to play with.  The link will open your wallet:

The design

There are no blocks in Obyte, and no block size issue.  Instead, every new transaction references one or more earlier ones (parents) by including and signing their hashes.  The links among transactions form a DAG (directed acyclic graph):

By including its parents, each new transaction also indirectly includes and confirms all parents of the parents, parents of the parents of the parents, and so on.  As more transactions are added after your transaction, the number of confirmations you receive grows like snowball, that’s why the original name of the platform Byteball (our snowflakes are bytes of data).


There is no PoW, no PoS, and no mining.  Instead, we have the DAG, which already establishes partial order between transactions, plus we add the main chain within the DAG:

The main chain (MC) allows to define total order between transactions: the transaction which gets included (directly or indirectly) earlier on the MC, is deemed earlier in the total order.  When there is a double-spend, the version of the transaction that comes earlier in the total order is deemed valid, all others are deemed void.

The main chain is defined deterministically based on the positions of transactions in the graph.  Refer to the white paper for details, but as a general rule, the MC gravitates towards transactions authored by well known users, which we call witnesses.  The list of witnesses is defined by users themselves as they include the list in every transaction they post.  The MC then follows the path within the DAG such that:
1. the witness lists of the neighboring transactions on the chain are either identical or differ by only one mutation,
2. the chain goes through the most number of witness-authored transactions, compared with alternative chains.

The above is very brief and sketchy description with many important details omitted, refer to the white paper for a full technical story.

Fees and intrinsic value

The fees paid for storing one’s transactions (or any other data) in the Obyte database are equal to the size of the data being stored.  If the size of your transaction data is 500 bytes, you pay exactly 500 bytes (the native currency of Obyte) in fees.  This means there is intrinsic value in bytes: it is the utility of permanently storing that size of data in a decentralized immutable database.  For data that represents financial transactions, the value is social rather than personal, because you absolutely need to store the full coin history in order to be able to prove the value and authenticity of the coin to each subsequent owner.

The fees are collected partially by those who are first to reference your transaction as parent and partially by witnesses.  The former incentivizes referencing the most recent transactions as parents, which results in the DAG growing in one direction only, like the trunk of a tree, and being as narrow as network latency permits.  If new transactions are rare enough, such that all nodes have enough time to sync before a new transaction appears, the DAG will look almost like a chain, with only occasional forks and quick merges.

Money supply

The total number of bytes is 1015, all bytes were issued in the genesis transaction. Since the fees paid are returned into the circulation, the money supply will remain the same.

Exchanges list the currency as gigabytes (GB, GBYTE), 1 gigabyte is 1 billion bytes.  The total money supply in gigabytes is 1,000,000.

Deterministic finality

In Obyte, there is a protocol rule that a transaction must include the previous transaction (if any) sent from the same address, i.e. there must be partial order between subsequent transactions from the same address.  Breaking this rule is considered equivalent to double-spending, therefore at least one of such unordered transactions will become void.  If we assume that most witnesses follow this rule (that’s what they are elected for), they have to reference only sufficiently recent transactions as parents and can’t inherit from old enough parents.  Therefore, they can no longer influence the MC (which is attracted to witnesses) in the old enough part of the DAG, and that part of the MC becomes stable, hence the total order relative to this MC also becomes stable.  See the white paper for discussion of exact criteria of reaching stability, here it is important that the criteria are deterministic, and once a transaction appears on the stable part of the MC, it is final, and, unlike all other cryptocurrencies, no re-orgs are possible.  

This is extremely important for applications in financial industry and for wider adoption in general, as most people are used to expect certainty in matters of money and property ownership, and the concept of probabilistic finality is a difficult sell.

Assets and on-chain exchange

Bytes is the native currency of Obyte.  Users can issue any other tokens (assets), e.g. to represent debt.  The debt can be expressed e.g. in fiat currencies or in natural units (barrels, ounces, kWh, etc).  The issuers of the debt can reveal their real-world identities and/or be voluntarily attested (i.e. their real-word identities be verified by a well known third party such as CA).  This enables the use of the existing legal system to secure against fraud.

The issued assets can be used as means of payment, along with bytes.  Assets can be exchanged against bytes and other assets by both parties signing a single unit that executes both legs of the exchange, thus the two transactions either happen simultaneously or don't happen at all.  This kind of signing is called multilateral signing.  No centralized exchange is needed, hence no trust is necessary and no exchange fees (apart from the usual fees for the size of the data).

Private untraceable payments

Assets can be either public or private.  All transactions in public assets are visible to everyone on the public decentralized database, just like Bitcoin.  Bytes is a predefined public asset.

Payments in private assets are not published to the public database.  Instead, only the hash of the transaction is stored to the database, while the plaintext of the transaction is sent directly from the payer to the payee.  To protect against double-spends, a spend proof is also published to the Obyte database.  The spend proof is constructed as a hash of the output being spent, so that if the same output is spent twice, the spend proofs will be necessarily the same.

I’ve already described this design at, see more details in the white paper.

Regulated assets

Regulated institutions can issue assets that are compatible with KYC/AML requirements. Every transfer of such asset is to be cosigned by the issuer, and if there is anything that contradicts the regulations, the issuer won't cosign.

This way, banks can issue fiat-pegged assets and stay fully compliant.  They can open demand deposit accounts and track them on Obyte as assets.  These assets are easily exchangeable against bytes and other assets (with bank’s approval).

Other features

- Spending conditions (AKA smart contracts) in an easy to understand declarative language
- Multisig: a special case of spending conditions
- On-chain oracles can post data (such as timestamps, exchange rates, weather, various events) directly to the database, then that data can be referenced from spending conditions
- Private end-to-end encrypted messaging: used to convey private payment data, communicate in multisig scenarios, and chat with a merchant’s bot.
- Attestation of real name, which is important for applications that require real-world identity, e.g. ICOs that require KYC.

Initial distribution

There will be no ICO, no crowdsale.  I believe the success of a currency depends on the number of people who own it, in fact Peter R’s research suggests that historical marketcap of Bitcoin follows Metcalfe's law:, i.e. it is proportional to the square of the number of active users.  That’s why I want Bytes to be in the hands of as many people as possible:

  • 98% of all bytes and blackbytes (the private untraceable currency) are to be distributed for free.
  • 1% I reserve for myself

Free distribution

We currently use 4 methods of free distribution, see

How you can help

  • play with the wallets, install them on multiple devices, pair them for multisig.  If you find bugs, report them.
  • run a relay on your cloud server to help the network. The relay doesn’t hold any private keys, so you don’t have to worry too much about security.  Get relay source code from
  • run a hub to better decentralize the delivery of private payments (the hub also includes a relay).  Again, the security doesn’t matter much as all messages are end-to-end encrypted.  Hub address can be changed by users in their wallet settings.  Get hub source code from  Alternative hubs already running:,,,,  Hubs and full wallets on the world map:
  • fix bugs, contribute improvements in our github repositories  In particular, we need faster syncing and faster UI.  Before now, I prioritized simplicity of algorithms over performance, now we need speed too.  A 10x improvement should come easy enough, the next 10x will be probably harder.  Discuss any major changes before actually implementing them.
  • develop new tools/apps that you think will be useful for Obyte users
  • spread the word about Obyte and remember that its value is proportional to the square of the number of active users

Community fund

We have a community fund for financing bounties and other useful work, its reports are published at  More information about the fund:  Donation addresses: KREOV5Y57FRWQKDHJ7BD3SFQBEVVPAG3 (for bytes) and 39zeGpu4nG6BqB9ARxd9xM9XThX9JCmx8t (for BTC).

Translations: Chinese, French, German, Hindi, Indonesian, Italian, Japanese, Korean, Portuguese, Russian, Spanish, Turkish.
QQ: 706668147
WeChat: byteball_china (or "DAG雪球")


One last thing.  The remaining 1% will be given away to the first 100m users who install Obyte wallet, 100 Kbytes to each user.  This will start 6 months from now or later, after we get ready for that scale.

4  Alternate cryptocurrencies / Altcoin Discussion / Hiding entire content of on-chain transactions on: August 03, 2016, 07:28:14 PM
I want to share one idea about making bitcoin transactions private, i.e. not published to the blockchain.  I use this design in an altcoin I’m currently working on, but it is equally applicable to Bitcoin.

Bitcoin is an unusual currency in that it necessarily makes all transactions public in its blockchain. This, in turn, necessitates unusual usage patterns (such as having to keep multiple addresses, avoid address reuse, and avoid joining outputs from different transactions), which make bitcoin look even more “foreign” to an ordinary user.

There are multiple known ways to improve privacy, to name just a few (the list is far from comprehensive):
- coinjoin allows to obfuscate transactions by mixing inputs and outputs of multiple unrelated  transactions.  Someone has to arrange the mixing, and users have to take special steps to actually make use of the service.
- ring signatures allow to obfuscate the real signer of a transaction.  The amounts and the receivers of funds are left visible.
- confidential transactions allow to hide the amounts of inputs and outputs but leaves the “who” and “whom” still visible on the blockchain.  The cost of CTs is a significantly increased size of the transaction that has to be stored on the common blockchain, therefore the cost is beared by everyone.

The central idea of the proposed design is to hide the entire inputs and outputs, and publish only the hash of inputs and outputs in the blockchain.  The hash can be published as OP_RETURN.  The plaintext of inputs and outputs is sent directly to the payee via a private message, and never goes into the blockchain.  The payee then calculates the hash and looks it up in the blockchain to verify that the hash was indeed published by the payer.

Since the plaintext of the transaction is not published to the public blockchain, all validation work has to be done only by the user who receives the payment.

To protect against double-spends, the payer also has to publish another hash, which is the hash of the output being spent. We’ll call this hash spend proof.  Since the spend proof depends solely on the output being spent, any attempt to spend the same output again will produce exactly the same spend proof, and the payee will be able to see that and will reject the payment.  If there are several outputs consumed by the same transaction, the payer has to publish several spend proofs.

To prove that the outputs being spent are valid, the payer also has to send the plaintexts of the earlier transaction(s) that produced them, then the plaintexts of even earlier transactions that produced the outputs spent in those transactions, and so on, up until the issue (similar to coinbase) transactions that created the initial private coins.  Each new owner of the coin will have to store its entire history, and when he spends the coin, he forwards the entire history to the next owner and extends it with his own transaction.

If we apply the existing bitcoin design that allows multiple inputs and multiple outputs per transaction, the history of ownership transfers would grow exponentially.  Indeed, if we take any regular bitcoin output and try to track its history back to coinbase, our history will branch every time we see a transaction that has more than one input (which is not uncommon).  After such a transaction (remember, we are traveling back in time), we’ll have to track two or more histories, for each respective input.  Those histories will branch again, and the total number of history entries grows exponentially.  For example, if every transaction had exactly two inputs, the size of history would grow as 2N where N is the number of steps back in history.

To avoid such rapid growth of ownership history (which is not only inconvenient to move, but also exposes too much private information about previous owners of all the contributing coins), we will require each private transaction to have exactly one input (i.e. to consume exactly one previous output).  This means that when we track a coin’s history back in time, it will no longer branch.  It will grow linearly with the number of transfers of ownership.  If a user wants to combine several inputs, he will have to send them as separate private transactions (technically, several OP_RETURNs, which can be included in a single regular bitcoin transaction).

Thus, we are now forbidding any coin merges but still allowing coin splits.  To avoid ultimate splitting into the dust, we will also require that all private coins be issued in one of a small number of denominations.  Only integer number of “banknotes” can be transferred, the input and output amounts must therefore be divisible by the denomination.  For example, an input of amount 700, denomination 100, can be split into outputs 400 and 300, but not into 450 and 250.  To send a payment, the payer has to pick the unspent outputs of the highest denomination first, then the second highest, and so on, like we already do when we pay in cash.

With fixed denominations and one input per transaction, coin histories still grow, but only linearly, which should not be a concern in regard to scalability given that all relevant computing resources still grow exponentially.  The histories need to be stored only by the current owner of the coin, not every bitcoin node.  This is a fairer allocation of costs.  Regarding privacy, coin histories do expose private transactions (or rather parts thereof, since a typical payment will likely consist of several transactions due to one-input-per-transaction rule) of past coin owners to the future ones, and that exposure grows linearly with time, but it is still much much better than having every transaction immediately on the public blockchain.  Also, the value of this information for potential adversaries arguably decreases with time.

There is one technical nuance that I omitted above to avoid distraction.  Unlike regular bitcoin transactions, every output in a private payment must also include a blinding factor, which is just a random string.  When the output is spent, the corresponding spend proof will therefore depend on this blinding factor (remember that spend proof is just a hash of the output).  Without a blinding factor, it would be feasible to pre-image the spend proof and reveal the output being spent as the search space of all possible outputs is rather small.

To issue the new private coin, one can burn regular BTC by sending it to one of several unspendable bitcoin addresses, one address per denomination.  Burning BTC would entitle one to an equal amount of the new private coin, let’s call it black bitcoin, or BBC.  

Then BBC would be transferred from user to user by:
1. creating a private transaction, which consists of one input and several outputs;
2. storing the hash of the transaction and the spend proof of the consumed output into the blockchain in an OP_RETURN (the sender pays the corresponding fees in regular BTC)
3. sending the transaction, together with the history leading to its input, directly to the payee over a private communication channel.  The first entry of the history must be a bitcoin transaction that burned BTC to issue an equal amount of BCC.

To verify the payment, the payee:
1. makes sure that the amount of the input matches the sum of outputs, and all are divisible by the denomination
2. calculates the hash of the private transaction
3. looks up an OP_RETURN that includes this hash and is signed by the payee.  If there is more than one, the one that comes in the earlier block prevails.
4. calculates the spend proof and makes sure that it is included in the same OP_RETURN
5. makes sure the same spend proof is not included anywhere in the same or earlier blocks (that is, the coin was not spent before).  Only transactions by the same author are searched.
6. repeats the same steps for every entry in the history, except the first entry, which should be a valid burning transaction.

To facilitate exchange of private transaction data, the bitcoin network protocol can be extended with a new message type.  Unfortunately, it lacks encryption, hence private payments are really private only when bitcoin is used over tor.

There are a few limitations that ought to be mentioned:
1. After user A sends a private payment to user B, user A will know what the spend proof is going to be when B decides to spend the coin.  Therefore, A will know when the coin was spent by B, but nothing more.  Neither the new owner of the coin, nor its future movements will be known to A.
2. Over time, larger outputs will likely be split into many smaller outputs, whose amounts are not much greater than their denominations.  You’ll have to combine more inputs to send the same amount.  When you want to send a very large amount that is much greater than the highest available denomination, you’ll have to send a lot of private transactions, your bitcoin transaction with so many OP_RETURNs will stand out, and their number will roughly indicate the total amount.  This kind of privacy leakage, however it applies to a small number of users, is easy to avoid by using multiple addresses and storing a relatively small amount on each address.
3. Exchanges and large merchants will likely accumulate large coin histories.  Although fragmented, far from complete, and likely outdated, it is still something to bear in mind.

I’ll be glad to hear any thoughts on this design.
5  Bitcoin / Development & Technical Discussion / BIP32 with string indexes on: May 20, 2016, 12:00:17 PM
I'm developing an authentication scheme using bitcoin cryptography, and for best privacy I want to derive a unique key pair for each domain.  It would be nice to have derivation paths like


However BIP32 spec allows only integer indexes in the derivation path.  I could map domain names to 32-bit integers (e.g. take sha256 of domain name and then use only the first 32 bits) but then it would be too easy to find collisions.  Another option I thought of is taking sha256 hash, splitting it into eight 32-bit integers, and then building a long derivation path like m/44'/0'/0'/0/int1/int2/int3/int4/int5/int6/int7/int8.  I don't like it either because such a long path would require too many group operations.

How about using a string as derivation index?  In BIP32, a 32-bit serialization of the integer index ser32(i) is used as input to HMAC, and as far as I can see there is nothing in the spec that depends on the index being exactly 32 bits.  That makes me think that the derivation functions will still work if we feed into them all the bits of a string instead.  For example, non-hardened derivation would look like this (in BIP32 notation):

I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar)) || "")

The keys are still recoverable because they will be regenerated on demand when user tries to access the domain.

Are there any problems with this derivation?
6  Bitcoin / Development & Technical Discussion / One-time signatures to prevent double spends on: July 21, 2015, 12:25:56 AM
It is well known that unconfirmed transactions are not safe because of the risk of double spend. Below is a proposal how to mitigate (not totally eliminate) this risk.

Imagine if the owner of the coin were not able to use his private key more than once, then he wouldn't be able to create another conflicting spend. We cannot take this ability away from him, however we can try to create a strong incentive (like all of Bitcoin which is built upon incentives) not to sign a conflicting transaction.

The good news is it is possible.

Bitcoin's ECDSA private keys can be used to sign any number of transactions. If you use the same address to receive coins and pay from this address for multiple purchases, you are already legitimately using the same private key to sign multiple transactions.

There is another class of signature schemes called "one-time signatures", which sounds like exactly what we need. Lamport signature is the most well known example. By nature of Lamport signature, every time you sign something you reveal a part of your private key, and security level of your second signature is half of security of the first signature. You see that despite the name, Lamport and similar signature schemes are not strictly one-time: if you take a Lamport private key with 128-bit security, your second signature will have security level 64 bit which is still moderately secure. Such slow degradation of security is not suitable for our purpose.

My idea is to modify the plain old ECDSA signature scheme and make it one-time. Here is how we can do it.

Standard ECDSA signature depends on a number k which should be kept private and never reused. ECDSA prescribes that this number should be generated anew for each new signature (randomly or deterministically per RFC 6979). If the same k is used to sign two distinct messages, the private key will be revealed. It is this nice property of ECDSA that I'm going to make use of: require that every signer commits to k at the same time that he generates his private key (and bitcoin address). That is, make k part of private key in the new signature scheme, and the commitment -- part of public key.

Below is full description of one-time ECDSA signature scheme.

Key generation:
Generate standard ECDSA private key as usual.
Generate random k.

oneTimePrivateKey = (standardPrivateKey, k)

Standard public key is x-coordinate of curve point standardPrivateKey x G, where G is generator, x is point multiplication.
Also calculate r as x-coordinate of curve point k x G (it is exactly the r from standard signature (r, s) ).

oneTimePublicKey = ( standardPublicKey, (k x G).x ) = ( standardPublicKey, r )

oneTimeAddress = base58( hash_and_checksum( oneTimePublicKey ) )

Standard ECDSA signature is (r, s). r is already known from the public key. Calculate s as usual. Since r is already known from the public key, we can drop it from the signature and keep only s.

Reconstruct the standard public key and signature by moving r from public key to the signature and apply standard ECDSA verification procedure.

The end result is, if the user tries to sign a second unconfirmed transaction with one-time private key described above, he will have to reuse k, hence disclose his private key. After his private key is disclosed, anyone can take his coins, the miners are, of course, in the best position to do that (they will not honor transactions that send the spilled coins to any address but theirs).

If the first signature is already deep in the blockchain, the second signature is harmless (unless the user had other unspent outputs on the same address).

This one-time signature scheme is most useful for securing unconfirmed transactions as any potential attacker has to consider the risk that the system strikes back and he loses his coins. Then all potential attackers without access to mining resources are probably out of the game.

Obviously, it is not compatible with address reuse. Also, wallet software has to be redesigned to treat creating a second signature on the same key as silly as posting the private key to facebook. If not forbidden in software, users can be tricked to think their transaction didn't come through for some reason, need to send it again ... private key exposed, coins lost.

Since making address reuse impossible in Bitcoin would require major modifications, and also because PoW already solves double spend problem fairly well, I don't see one-time signatures coming to Bitcoin any time soon. However, they may be a good fit for altcoins and sidechains, especially those that already have stealth addresses.

PoS currencies can use one time signatures to address nothing-at-stake issue and make double-voting too risky (double voting is essentially the same as double spending). To sign more than one block, one can derive consecutive private keys in BIP32 style from a master private key and block number.

I made ECDSA signatures one-timed by having signers commit to k. The same trick can be applied to other signature schemes that involve k, e.g. DSA, Schnorr.

This idea is not quite new, I searched and found a few publications where it was also mentioned:;jsessionid=057011325AE4FA29DFE5401D31C9AD04?doi=

7  Bitcoin / Development & Technical Discussion / Pruning OP_RETURNs with illegal content on: February 09, 2015, 11:52:34 PM
Just researching another possible threat.
What if an individual who is angry at Bitcoin for whatever reason tries to insert some illegal content into blockchain?
There are a lot of content types that are illegal in one or many jurisdictions, for example Charlie Hebdo cartoons in Pakistan, suicide instructions in Russia, Sony PS3 signing key in the US, etc. This person would inject illegal content into OP_RETURN outputs, maybe spreading large content over several 40 bytes OP_RETURN outputs, and this content would be stored forever. He would inject it in the most open and self evident form possible, no encryption, no steganography, no fancy encoding. The content would be stored and distributed by full node operators. Their activity might not be automatically illegal while they store and distribute this content **unknowingly**. In the pre-blockchain world, it is common practice that if you run a web site that unknowingly stores and distributes some copyright infringing or otherwise illegal content and you receive a take down notice, you comply and you are ok after that. But you can't remove anything from blockchain without destroying its integrity. So a full node operator can only comply by ceasing operations, and if he doesn't comply after receiving a take down notice, he would **knowingly** store and distribute illegal content which places him in bad terms with the law.

This thread discusses pruning the offending transactions, which is not a simple thing as it would require changes to verification procedures. I understand it was never really necessary and never implemented. Even if it were implemented, it would create a mess if some nodes pruned a transaction while others did not. Also, the inputs of fully pruned transactions could be double spent.

As Bitcoin grows and becomes a business for many, the risks of illegal content become more important.
Any other ideas how to mitigate these risks (if they even exist)?
8  Bitcoin / Development & Technical Discussion / How are UTXOs stored? on: January 25, 2015, 04:12:36 PM
As far as I understand, when bitcoin client starts it parses the whole blockchain back from genesis block to build UTXO database. Later when it verifies a new transaction it uses the UTXO database and doesn't read the actual blocks where the outputs come from. Correct?

How does it store the UTXO database? In memory or on disk? If on disk, are there any integrity checks to protect from a hacker silently breaking into the node machine and modifying the UTXOs to whatever he wants?
9  Bitcoin / Bitcoin Discussion / Sending change to a different address, does it help much? on: January 23, 2015, 03:05:45 PM
To protect your privacy, it is commonly recommended to send change to a new freshly generated address. It is argued that this makes it impossible to distinguish the payment from the change which makes it harder to group the transactions that belong to you.

Correct me if I'm wrong, I'm afraid it doesn't help in many cases. The reason is simple: payment value is usually smaller than the change.

When I spend money from my debit card, the payment amount is usually much smaller than the remaining balance. That's because I don't want to refill my card as often as I spend. The same spending habits applied to Bitcoin make transactions traceable.

If you have 10 BTC (say, you received it from an exchange) and want to pay 1 BTC, your transaction will have two outputs:
1 BTC - the payment,
9 BTC - the change to another your address.
Without any other knowledge, just by looking at the output values, it is usually safe to say that 1 BTC is the payment and 9 BTC is the change, and the address where the 9 BTC landed is again your address. Any other coins received to this address will be tracked to you. The subsequent transaction that spends the 9 BTC will be tracked to you.

Any thoughts how this situation is really often and how to protect one's privacy?
10  Bitcoin / Development & Technical Discussion / Fake block timestamps can cause a temporary fork? on: January 17, 2015, 05:50:31 PM
Every block includes a timestamp as set by the miner who mined the block. There is a rule that other nodes reject the block if its timestamp is more than 2 hours in the future. It is a hard limit: if the timestamp is 2:00:01 in the future relative to node time, the node rejects it; if it's only 1:59:59 in the future, the node accepts it.

What happens if a miner finds a block and sets its timestamp exactly 2 hours in the future relative to some accurate time source? Since the clocks of all other nodes are never perfectly synchronized and distributed somewhere around the true time, I would expect that approximately half of the nodes (whose clock is slightly ahead of the true time) accept the block, while the other half will reject and forget it. Half of the miners will accept the block and start building a new block on top of it (with half of the original hash power), the other half will continue working on the previous block. We've got a blockchain fork caused by misbehavior of just one node. One of the two forks will eventually win but, before that, transaction confirmations might be delayed. Did I get anything wrong?

I think when designing a distributed consensus system, such as Bitcoin, one should be cautious about making a decision based on node time. Node time is different at different nodes and this a source of disagreement that potentially destroys consensus. Hopefully just temporarily.

Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!