Articles Tagged with

TumbleBit

Breeze with Privacy Protocol Mainnet Release


The Breeze Wallet with Breeze Privacy Protocol public Mainnet release is now available and represents a key step in our product development roadmap. The Breeze Wallet showcases our technology with a strong emphasis on privacy and security on the blockchain network. This primarily serves organizations that want to obfuscate business to business transactions securely on the blockchain.
This version of the Breeze Wallet includes the Breeze Privacy Protocol feature as well as a user-friendly interface.  It also features the Masternode Client Discovery protocol where the blockchain is used to discover, validate, and connect to a Stratis Masternode, which provides the privacy protocol service. This discovery process is undertaken in a decentralized and trustless manner that is resistant to network disruption.
This is a Mainnet release and is now open to the public. Enhancements made to both the Breeze Wallet user interface and the Masternode Client Discovery Protocol have been incorporated into this release.
For more information about how the Breeze Masternode registration protocols works, please visit this technical blog post:
/2017/10/30/masternode_registration_protocol/
Download the Breeze Wallet with Breeze Privacy Protocol for Mainnet from the link below. The wallet will then automatically discover and connect to an available Mainnet Stratis Masternode.
Download
https://github.com/BreezeHub/BreezeProject/releases/latest
User Guides
Download for Breeze Wallet User Guide
/wp-content/uploads/2018/09/Breeze-Wallet-with-Privacy-Protocol-User-Guide-v1.1.pdf
Download for Stratis MasterNode User Guide
/wp-content/uploads/2018/08/Stratis-Masternode-Installation-Guide-for-Windows-v1.2.pdf

Stratis Masternode Registration Protocol


Stratis masternodes solve the problem of providing useful services to a blockchain network while keeping the list of services decentralised and tamper-proof. In the initial masternode implementation the service being provided is the Breeze Privacy Protocol, but it is anticipated that many more services can be added in future.
In order for this goal to be accomplished, each masternode must register (advertise) its existence via the Stratis blockchain. This is what is referred to as the Masternode Registration Protocol. A masternode registration simply consists of a specially formatted Stratis transaction. This transaction contains all the pertinent information needed by a client to connect to and validate the masternode.
A registration transaction, once submitted to the network, remains valid indefinitely until invalidated by one of the consensus rules governing such registrations. These are:

  • The masternode server’s funding address is not funded within the initial window period.
  • The collateral funds are insufficient at the conclusion of the window period (see section Collateral Verification for additional information regarding the collateral and the balance tracking).
  • The collateral funds get moved, wholly or in part, to another address, thereby decreasing the balance below the required threshold.
  • A subsequent registration is made at a greater block height than the original (e.g. to update the masternode’s public parameters).
  • (Currently not enforced) A registration expires every N blocks, requiring the operator to periodically refresh it.


It is the responsibility of the Breeze client software to scan the Stratis blockchain for the most current masternode registrations prior to initiating contact with any server. They do this by observing each incoming block, looking for transactions that match the bitstream format. When a registration is found, it is stored in the node’s local store.
The block height that the registration is received at determines the window period for the masternode funding transaction. The masternode operator has to move the required collateral into the funding address before this window elapses. If this is not done the registration will be regarded as expired and purged from the local storage of all nodes on the network.
Once a sufficient number of valid masternode registrations have been downloaded, the client can select one at random and try to connect to it to utilise its services (e.g. the Breeze Privacy Protocol). Optionally the masternode selection can be performed once the entire blockchain is downloaded, as this is more fair to masternodes that register later in the chain.
The process described above has already been implemented into the Stratis software offering.
Bitstream format for masternode registration transaction
The registration transaction consists of a single transaction broadcast on the Stratis network (either testnet for testing or mainnet for ‘live’ masternodes). This transaction can have any number of funding inputs, as normal.
It has precisely one nulldata (data storage) output marking the entire transaction as a masternode registration. There can be an optional change return output, which if present must be at the end of the entire output list. The remainder of the transaction outputs are of near-dust value. Each output encodes 64 bytes of data into a public key script. The contents and format of the encoded data is described below.
The presumption is that the transaction outputs are not reordered by the broadcasting masternode, as this would result in potential data corruption.

OP_RETURN transaction output
Field Size Description
1 26 bytes Literal ASCII string: BREEZE_REGISTRATION_MARKER

 

Encoded public key transaction outputs
Field Size Description
1 1 byte Protocol version byte (if >200, it is a test registration to be ignored by mainnet wallets)
2 2 bytes Length of registration header
3 34 bytes Server ID of masternode (base58 representation of the collateral address, right padded with spaces if it is less than 34 characters long)
4 4 bytes IPv4 address of masternode, one byte per octet. Use 00000000 for an empty address. This field is not used for the Breeze Privacy Protocol; it is a placeholder for future functionality
5 16 bytes IPv6 address of masternode, one byte per octet. Use 00000000 00000000 00000000 00000000 for an empty address. This field is not used for the Breeze Privacy Protocol; it is a placeholder for future functionality
6 16 bytes Masternode server URI, currently this is an ASCII onion address hostname without any prefix or suffix. An empty address is signified by 00000000 00000000 00000000 00000000, but leaving this empty is not valid for the current Breeze Privacy Protocol implementation
7 2 bytes TCP port of masternode, may be ignored by client implementation
8 2 bytes RSA signature length in bytes
9 n bytes RSA signature proving ownership of the Breeze Privacy Protocol server’s private key
10 2 bytes ECDSA signature length in bytes
11 n bytes ECDSA signature made with the private key of the address used as the server ID. This same address is where the collateral will need to be located
12 40 bytes Hash of the Breeze Privacy Protocol server’s configuration file. This may be moved into the header in the next version of the protocol
The protocol format can be extended in future to accommodate new functionality. New fields should attempt as far as possible to retain backward compatibility with the existing fields

On connection with the Breeze Privacy Protocol server by a client, the public key of the server will be verified by the client to ensure that the server is authentic and in possession of the registered keys. The Privacy Protocol is then followed as normal.
Collateral Verification
For the Breeze Privacy Protocol to function well, the creation of numerous or insufficiently powerful masternode servers must be disincentivised. Therefore, consensus rules that govern the validity of a masternode need to be established and enforced by participating client nodes.
A Stratis masternode requires 250 000 Stratis coins (STRAT) to be regarded as compliant. These coins should be kept in a single address, and should not be moved once the funding transaction is performed.
On receipt of each new block, the non-masternodes will check each transaction for those that affect a currently tracked masternode server. If funds have been moved out of the address, the calculated balance is decreased. If funds come in, the calculated balance increases. Once the balance has been computed for a masternode, its registration is automatically deleted if it falls below the 250 000 STRAT threshold. It is therefore not recommended that significant transactional activity be performed with the collateral funds, to avoid inadvertently invalidating registrations.

The above diagram illustrates 4 basic scenarios for a masternode’s registration sequence.

  • Node 1 has made a sufficient funding transaction within the window period, and as such its collateral is regarded as compliant.
  • Node 2 was initially compliant after the window period, but later removed some funds from the address, and therefore no longer has sufficient collateral.
  • Node 3 made two transfers that when aggregated form sufficient collateral in the target address. This is a valid, but non-standard method of performing the funding.
  • Node 4 took too long for the funding transaction to be performed (it was outside the window period), and is therefore regarded as non-compliant in terms of its collateral obligation.

The collateral verification functionality has also already been implemented into the Stratis software offering.
Future improvements
Inter-node discovery protocol
A drawback of the approach outlined in this paper is that every node has to download the entire blockchain from the genesis block onwards in order to accurately determine collateral balances. It is more efficient for registrations to be accumulated by full nodes, and circulated to their peers (full or light nodes) with sufficient proof of their accuracy.
The inter-node discovery protocol has already been implemented in the Stratis node software, but is not currently used in order to keep the initial version as simple as possible. It also has an indirect requirement for the peer policing described in the Peer policing model section.
Improvement proposal – peer policing model
There are some differences between existing masternode implementations and the envisioned Stratis masternode approach. Briefly:

  • Dash masternodes are remunerated ‘passively’. This requires that they be actively pinged in a verifiable way by the remainder of the network to avoid paying a masternode that performs no work.
  • Conversely, a Stratis masternode can currently only earn remuneration via active participation in the Breeze Privacy Protocol with connected clients. This removes the need to directly police the masternode in this sense.
  • Due to the high cost of a top tier Stratis masternode, it is presumed that the operator will be economically incentivised to positively participate in the network. This is similar to the core tenets of the Proof Of Stake consensus mechanism.

There are also some aspects of the Dash approach that are desirable to emulate, particularly the ability to have the collateral in ‘cold’ storage.
The requirements for the Stratis top tier masternode may be summarised as follows:

  • The node operator must be in possession of at least 250 000 Stratis (i.e. they possess the private key to move or spend them).
  • These collateral Stratis must be present in a single address.
  • Moving the Stratis collateral to a different address invalidates any proof of possession generated prior to the move.

These requirements need to be actively enforced to prevent dilution of the Privacy Protocol security model. It is proposed that the entities most suited to perform the enforcement are the masternode’s peers on the Stratis network. These peers may be one of the following:

  • Another masternode (essentially a full node with additional features).
  • A ‘full’ node with a complete copy of the Stratis blockchain.
  • A ‘light’ node that does not retain a copy of the entire chain, but does at least retain block headers.
  • Other types of nodes are outside of the scope of this document.

The onus is on a particular masternode to advertise its services to the network. This means that every node can elect whether or not to regard a masternode registration as valid, depending on the information it has available to it. From a game-theoretic perspective, it is advantageous for the operators of ‘rival’ masternodes to immediately present proofs of non-compliance of a particular masternode to the rest of the network. It is additionally presumed that there is no advantage to be gained for an honest node to propagate registrations known to be invalid.
An example of the ‘lifetime’ of a registration & implementation of the ‘proof of non-compliance’ concept is as follows:

  1. Operator configures masternode, which generates masternode registration Y on startup.
  2. Node operator moves sufficient collateral into address X (the ‘funding transaction’). This needs to be done within a finite window period after the registration transaction is made.
  3. Registration Y is broadcast as a transaction to peer nodes for inclusion into the Stratis blockchain in block Z.
  4. The registration is cached on each peer node. Nodes that join the network after block Z need not download the entire chain to receive registration Y – they can receive lists of verified historical registrations by communicating with their peers (inter-node discovery protocol). Light nodes can validate registrations for themselves by evaluating the Merkle proof of the registration against their locally downloaded block header storage.
  5. All full nodes on the network can directly evaluate the balance available in address X at any time. Therefore, if it transpires that a spurious masternode registration has been broadcast (which may happen) the full nodes will not forward that registration on to new peers. Peers that attempt to send known-invalid registrations will receive a proof of non-compliance in response.
  6. The status quo persists for a period of time without any changes that affect masternode registration validity.
  7. The masternode operator moves a portion of the funds from address X elsewhere, i.e. they are now below the collateral requirement.
  8. All nodes that download blocks will immediately be able to tell that the balance of X has changed, although a light node may not know what the actual balance is. Full nodes do know (or can calculate) what the balance is, and can construct a proof thereof showing that the masternode is no longer compliant.
  9. The non-compliance proof will be broadcast between nodes. This could be done pre-emptively (i.e. broadcast proof to all known peers immediately), or it could be done passively in response to receiving an invalid registration from a peer.

At a high level, the proof of insufficient funds will consist of the following elements:

  • A copy of the ‘funding transaction’ for the masternode. This is defined in more detail in the Funding Transaction
  • The registration record itself (in its entirety, as the peer may not have downloaded it yet).
  • At least one complete transaction with the funding transaction included as one or more of its inputs i.e. showing that collateral funds have been moved/spent.
  • The net result of the movement transactions must be that the balance of the collateral address is < 250 000 STRAT.
  • Merkle proof(s) for the movement transaction(s) showing that they are included in a block at the same or higher height than the funding transaction.

A light node should be able to interrogate a peer node about the perceived status of one or more masternodes. If the peer being interrogated is also a light node, it will only be able to pass along proofs it already received and stored from the full nodes.
Funding transaction
The funding transaction for a masternode is the transaction that assigns the 250 000 Stratis collateral to a given address. It is recommended that only a single transaction output be used for this, to keep the size of the proofs communicated between peers to a minimum.
There is also naturally a possible gap between the block height of the funding transaction and the block height of the registration transaction, during which some fund movement may have occurred. This should not be a problem, as full nodes will evaluate the solvency of the masternode and determine whether to propagate its registration to other peers via the inter-node protocol.
Some possible attack/DoS vectors
The most vulnerable portion of the network are the light nodes. The proof mechanism therefore needs to be robust enough to allow the light nodes to participate in policing the masternode registrations without having the entire blockchain available.
The masternode operators also need to be protected from rogue full nodes attempting to stifle traffic to particular masternodes by censoring their registrations. This is mitigated by the decentralised nature of the Stratis blockchain. It is only required that a sufficient number of honest nodes participate to minimise or negate the impact of rogue nodes, as the registrations will percolate through the network via the blocks & inter-node protocol. A rogue full node cannot generate a fake proof of non-compliance, as the Merkle proofs will fail to be validated.
Masternode operators may generate copious registration transactions (i.e. spam) in an attempt to sway client nodes to use their server. This is mitigated by a rule that a client node will only keep the most recent valid registration for each known masternode, so spamming the network does not result in an increased likelihood that a client will select a particular masternode server.
It is important that a masternode operator avoid moving their collateral funds in such a way that they inadvertently provide an avenue for full nodes to construct a non-compliance proof. If funds need to be moved it is recommended that an entirely new address be used & a new registration performed. This will naturally cause the previous registration to be invalidated and removed from the caches of nodes on the network. The new registration will, conversely, be cached and used going forwards.

Breeze Wallet with Breeze Privacy Protocol (Dev. Update)

Breeze Wallet with Breeze Privacy Protocol Released

(Powered by TumbleBit and Stratis Blockchain Technology)

Breeze Wallet with TumbleBit has a new name: Breeze Wallet with Breeze Privacy Protocol. Breeze Wallet will be the first wallet of its kind that will not only provide a fully featured crypto wallet, it will also include a unique coin shuffling and swapping technology. The protocol takes small denominations of bitcoins from a source wallet in Breeze, shuffles and swaps the coins with others, and then transfers those coins to a destination wallet.
The process is powered internally by TumbleBit to add privacy to your coins. It is likely to be used by discerning individuals and businesses that accept cryptocurrencies and do not want to leave traces that may reveal their customer and supplier lists.

Alpha Available Now

Stratis Internal and select community testing of Breeze Wallet with Breeze Privacy Protocol is complete and we’d like to offer you, our community, the opportunity to take a look, download and try the Alpha. The new wallet is available now for Windows, Mac and Ubuntu. Download details are available here: (https://github.com/BreezeHub/Breeze/blob/tumblebit-alpha/Breeze.Documentation/alpha/option1.md ). This release runs only on testnet and is an alpha/experimental release.
The work has focused on developing a smooth user experience as well as deep integration into the Stratis Blockchain Technology. There is no longer a need to run BitCoin Core alongside Breeze Wallet when using the protocol to shuffle and swap coins. That functionality is now completely provided by Stratis Blockchain technologies. This work moves us closer to our vision where MasterNodes provide discoverable services – such as the privacy protocol – to the Stratis network in a decentralized, scalable, trustless way.
We’d like to point out that the Breeze Privacy Protocol is a CPU intensive service and although we will be providing a test server, places on the server are limited and part of the goal of the community alpha is to stress the server. Please do not be disappointed if you cannot get on this server – we are working with our community to add more server power. If you are interested in running a server please get in touch.
We’d like to also extend a warm thank you to our dedicated community testing team who have done an excellent job helping to get Breeze and the core NTumbleBit technology to a solid alpha release state. A special mention to badass, zomertje, sigma, demon and kabbie. And lastly to all our capable development team across all functions. Last but not least thanks to Nicolas Dorier and the TumbleBit dev team from MIT. This was a team effort and you guys are awesome.

Breeze Wallet Alpha Release Postponed

We have just got word that the Breeze Wallet Alpha Release had to be postponed due to the fact that the development team has hit several issues running final tests. We apologize for the delay and want to share with you the official statement from the Breeze Wallet team:
As you know we are hard at work on the latest alpha release of Breeze. We are fortunate to be working with some of the leading cryptographers and developers in the crypto-currency space and occasionally their work and reviews surface integration delays and issues such as the one below. Rest assured that this is a normal part of our software development process and is designed to produce a high quality and secure product.
Please bear with us and look out for a new super-secure version of Breeze. Alpha coming soon.

A second bug we are currently addressing:

Thanks for your patience!
The Stratis Team

Bitcoin Privacy is a Breeze: TumbleBit Successfully Integrated Into Breeze

Development Update

This week the Breeze development team reached the final major milestone in their development of the Breeze Privacy Protocol, which is the Breeze implementation of TumbleBit.
This development has allowed us to start seeing considerable volume of transactions protected by Breeze’s Privacy Protocol, the architecture developed by Stratis, which provides a safe way to anonymize cryptocurrencies.

The Breeze Wallet is now fully capable of providing enhanced privacy to bitcoin transactions through a secure connection. Utilising Breeze Servers that are pre registered on the network using a secure, trustless registration mechanism that is resistant to manipulation and censorship.
Breeze Tumbler is expected to be utilized in commercial scenarios including businesses that do not wish to reveal their customer or sensitive data for competitive reasons.
Finally, we want to share with you the latest progress on the Breeze wallet UI, so that you can start getting a feeling of the great things to come from our team.

Follow and contribute to the Breeze Wallet project: BreezeHub and look out for an alpha release of this exciting product coming soon.
 

BreezeHub is Here

This note is a contribution from our new team member Carlton Pringle (@carlton on Slack). One of the key missions in Carlton’s new role as Breeze / Tumblebit development Project Lead, is to coordinate the communications about progress in this exciting technology to internal teams, developers and the public at large.
As he gets more familiarized with the vision and accomplishments of our development team. He will be responsible for providing all the relevant updates and streamlining communications from the Breeze / Tumblebit team to our developers and general community.
Welcome Carlton and we wish you success in your key role, and without further ado… here is his first Breeze Update.

Facilitating Breeze Development Access

We want to simplify access and visibility for the Breeze Project, as we expect many peer reviews and collaborators to this exciting project now and in the future. To this aim we are launching the GitHub open source projects for Breeze / Tumblebit development under the auspices of Stratis.
BreezeHub hosts our TumbleBit Server Experimental build and showcases the Stratis secure node advertisement protocol, which will be utilized by the Breeze wallet to locate Breeze Tumblebit servers without the need for a centralized list. This is therefore a registration mechanism resistant to manipulation or censorship as it does not require trust in third parties.
Check out BreezeHub where you’ll find all our work on the TumbleBit Protocol in one place including code, documentation and all the latest info on the TumbleBit Server Experimental Build.
BreezeHub includes full instructions to walk you through the TumbleBit server installation. Give it a try and please reach out to our team of developers on Slack with your bug reports, suggestions, and comments.
Expect to see lots of activity on BreezeHub – including more incremental releases – as our vision of this exciting technology takes form.
BreezeHub on GitHub

BreezeHub is hosted on GitHub and can be found at https://github.com/BreezeHub.
Acknowledgements: Thanks to @zeptin and @dan.gould for their hard work on this and thanks @jeremy for your support.
TCP Server
This week also, Nicolas Dorier wrote a custom asp.net core server to replace the default Kestrel implementation that runs in asp.net core on Windows, Linux and OS X. This lightweight tcp server will be used within the TumbleBit Server in place of the previous http+json ptotocol to improve anonymity for TumbleBit users. It can be found here.

Breeze Tumblebit Server Experimental Release

Breeze TumbleBit Server is Ready to Test!
The highly anticipated alpha version of the Breeze TumbleBit Server has now been released for testing. As promised, we have been engaging in a process of incremental deliveries and in this opportunity we want to share some technical details of the release. We expect to provide even more details both from an user and an operator perspective in the weeks to come. So, stay tuned!
This release showcases the Stratis secure node advertisement protocol, which will be utilised by the Breeze wallet to locate Breeze Tumblebit servers without the need for a centralised list. This is therefore a trustless registration mechanism resistant to manipulation or censorship.
Node advertisement protocol
A high level overview of the protocol operations performed by each Breeze Tumblebit server is as follows:
1. The node operator starts up the Breeze Tumblebit Server software.
2. The node checks to see if it has registered itself on the Stratis blockchain before.
3. If it has, the tumbler service is initialised as normal.
4. If the node is not yet registered, or if its configuration has changed, the registration transaction updates and broadcast again.
Registration transaction

The registration transaction is a specially-formatted transaction broadcast by the Breeze Tumblebit Server to the Stratis network. In this release, the registration transactions are broadcast to the main Stratis blockchain.
Security features

The registration transaction contains the following information embedded inside it:
1. The IP address of the Breeze Tumblebit Server.
2. (Currently optional) TOR address of the server.
3. The port that wallets should use to connect.
4. All the information is signed by the tumbler’s private keys. This means that the signatures can be validated by a Breeze wallet when it connects to the Breeze Tumblebit Server. The registration protocol will greatly benefit from widespread testing by the Stratis community.
As this is alpha software, the tumbler is currently configured to only operate on the Bitcoin testnet. This is to prevent loss of funds in the event of errors. Once the tumbler is sufficiently stable a Bitcoin mainnet version will be released.
Please reach out to our team of developers on Slack with your bug reports, suggestions and comments.

Stratis announces first ‘Master Nodes’

 

Stratis Group Ltd. has just revealed initial details of the upcoming Breeze Nodes infrastructure release. The blockchain company, that has created one of the most innovative cryptographic tokens – Stratis ($STRAT). Will soon be offering an economic incentive to node operators to participate in securing different types of on-chain and off-chain transactions for the Breeze Wallet. As well as for blockchain apps and services for corporate clients.
The first iteration of the Breeze Tumbler Node (often referred to as a “Master Node”) will see their application supporting the Breeze Wallet, where they will help execute Bitcoin and Stratis TumbleBit transactions. These will have hybrid functionality running both Bitcoin and Stratis full nodes that provide additional services to the network.
There will be future releases of other forms of Stratis Nodes providing functionality, such as:

  • Payment Node – Payment Channels
  • Side-Chain Node – Hybrid Side chain special features
  • Identity Node – Identity management node

A Breeze Tumbler Node can be operated by anyone that meets the minimum protocol requirements. Some of those requirements include:

  • An operator will be required to sign a transaction with an account that has 250,000 STRAT or more.
  • For BTC tumbling transactions, an operator will also need to have 5 BTC or more held in reserve to be able to process payments. The more bitcoin held in reserve, the more payments theoretically can be processed.
  • Server hosts will need to provide a minimum amount of storage capacity (details TBA). It is recommended that your Breeze Node be available 24×7 in order to opt for the most transactions and potential fees.

Breeze Tumbler Nodes will operate in a totally decentralized and trustless manner, meaning that no one can steal the funds trusted to the network. Additionally, the STRAT required to operate a node can be stored on a Ledger Wallet or on offline backup. The private key to the users STRAT address is only required during registration with the Stratis Node network.
The BTC in reserves will need to be in a wallet on the node, as it is required to sign the transactions when processing the tumbler transactions.
Full instructions and documentation will be released in due course and made available via the Stratis Wiki. The intention is to make it near one-click, so operators do not have to deal with configuration files. Our developers will be ready to assist you with any issues you may encounter.
Rewards to the Breeze Node operators will be paid in the form of a transaction fee (estimated at 1%) paid by Breeze users directly to the Breeze Node that processes their TumbleBit transaction. This fee amount and its distribution may vary for specific implementations of the Breeze Node depending on the type of applications and services.

Depending on the operator’s jurisdiction there may be legal and tax related specific requirements and/or restrictions. We highly recommend all operators seek proper advice before operating a Breeze Node. This is a decentralized network not managed, controlled or administered by Stratis Group Ltd.
The Breeze Tumbler Nodes are expected to go live before the end of Q2 2017, by the time of the release to production of the Breeze Wallet.
If you have any questions please contact the team by joining our Discord.

Stratis Bitcoin Full Node in C# Goes Live


Stratis Group Ltd. announced this week that it has officially released the Alpha version of the Stratis Bitcoin Full Node. Built on Stratis Mainnet, it will give developers from around the world, the possibility of building the most advanced blockchain applications by incorporating capabilities from the Stratis Privacy, Security and Identity Protocol.

Building the Blocks

Stratis has adopted a modular approach to the development process of the Stratis Application Framework, a streamlined approach for faster and incremental releases.
On this regard, the Stratis Bitcoin Full Node plays an essential role as the foundation upon which other modules of the Stratis blockchain solutions can be easily and rapidly assembled into the most basic demo or the most sophisticated financial application.
This update released from the Stratis Development team includes the addition of key components to the Stratis Bitcoin Full Node, namely:

  • Mempool
  • Network
  • Blockstore

In addition, the Stratis Full Node has been activated on the Mainnet, providing a full SDK that allows developers to start testing their blockchain apps on live blockchain conditions.

Stratis Privacy, Authenticity and Identity Protocol
Currently under development, the Stratis Privacy, Authenticity and Identity protocol, includes capabilities inherited from the Tumblebit integration into Stratis, such as, enhanced privacy and off-chain transactions support.
Stratis plans to release several proof-of-concept projects this year, together with some strategic partners, in which to showcase these advanced features. The Stratis Privacy Protocol, an integration of the Tumblebit on the Stratis Full Node and Bitcoin networks, will be the first proof of concept offering a long awaited enhanced and secure privacy solution for cryptocurrencies. Currently being implemented into the Breeze Wallet, Stratis plans to extend its application to authentication and identity solutions for the enterprise and major corporate clients.
These implementations are not only positive additions to the Stratis portfolio of technological advancements, but also will serve as a production environment where latest improvements to the Bitcoin network can be tested.

Integration with C# and .Net Core Tools

Written with C# and .Net Core developers in mind, the Stratis Bitcoin Full Node opens to developers from around the world the opportunity to start developing blockchain applications within a familiar environment for them and their clients. If you are a C# developer, and would like to start coding your first blockchain app, we invite you to join our Slack. Our developers there will be more than happy to guide you and help you get started with the installation and operation of the Stratis Bitcoin Full Node.
We also want to take this opportunity to invite developers to attend our presentations and meet with us at the C# Annual Conference in India. This is one of the major C# / .Net developers events in the world, and we are thrilled to be presenting Stratis to such reputable audience.
A Blockchain is made of many components, from a Full Node that validates blocks to a Wallet that tracks addresses. Our objective is to offer a set of Nuget packages, from which an implementer can cherry pick what he/she needs. On this regard, we have made available a Nuget for the Alpha Release that can be found here.

The Road Ahead

The Stratis team has plans to add many more features on top of the Stratis Bitcoin Full Node. Starting with a sleek GUI for Stratis Wallet (due in aprox. 4 weeks) and later for the Breeze Wallet (due in aprox, 8 weeks), we are methodically putting together the pieces for the most advanced features to be offered on the Stratis Platform: POS/DPOS, Sidechains, Private/Permissioned blockchain, Compiled Smart Contracts, etc. These features, will undoubtedly bring us closer to offer purpose-built Blockchain solutions in a very short time-frame.
Included in this release (V1.0.1-alpha)

  • Stabilizing the consensus validation and block download code.
  • Signaling of new blocks and transactions that are discovered on the network.
  • Block Store is stand alone:
  • Store can respond to GetData payloads enabling FullNode capabilities.
  • Push blocks in batches to disk.
  • Download missing blocks from the network (catch-up mode).
  • Broadcast blocks to peers using Inv or Header payload
  • Cache store for faster block reads.
  • Memory Pool:
  • Async lock free implementation of the memory pool.
  • Logic and tests pulled form core.
  • Broadcast transactions to peers.
  • Fee estimation.
  • Introducing the Builder Pattern:
  • Build a full node in an easy and familiar builder pattern in a modular approach.
  • Support for creating new features inject-able to the full node.
  • Dependency Injection
  • Testing
  • Adding many more unit tests
  • A separate integration test project
  • Full Block SPV
  • Laying the grounds for a full block spv (for Breeze wallet)

Links:

Project Repository: https://github.com/stratisproject/StratisBitcoinFullNode/releases/tag/V1.0.1
Getting Started / Installation Guide: https://github.com/stratisproject/StratisBitcoinFullNode/blob/master/Documentation/getting-started.md

Acknowledgements:

We would like to thank Nicolas Dorier for all of his work for the Stratis Bitcoin Full Node. Also we would like to thank our other team members Dan Gershony, Pieterjan Van Hoof and Jeremy Bokobza for their outstanding work on the different modules. Special mention to our collaboration with Adam Ficsor as well as other participants from the Tumblebit project, which have been actively supporting the implementation. And last but certainly not least we would like to thank our community members for helping testing the Stratis Bitcoin Full Node and providing support to our team.

Stratis’ Breeze Wallet Redefines Financial Privacy for Blockchains


TumbleBit is probably one of the most promising technological advancements built on top of Bitcoin to date. Not only does it offer one of the best — if not the best — privacy related innovations so far, it can also provide significant scaling benefits as a payment hub. The solution is also fully compatible with the current Bitcoin protocol and, most important, it is in an advanced stage of development.

(Bitcoin Magazine , Feb. 2017)

 
Stratis Group has announced today it is launching an ambitious cryptocurrency project, aimed at increasing financial privacy available to the users of Bitcoin and the Stratis Platform.
The project dubbed “Breeze Wallet” incorporates the innovations brought by TumbleBit to both Bitcoin and Stratis, into a real-world production environment combined with the privacy enhancements introduced by the Full Block Secure Payment Validation system.
Stratis plans to integrate TumbleBit into the Breeze Wallet making it the first Bitcoin wallet that addresses the privacy issues in blockchain transactions, the Breeze Wallet works with the current Bitcoin protocol and does not require any forks.
Stratis Financial Privacy Protocol
The Stratis development team will be extending the Stratis blockchain to support the Stratis Financial Privacy Protocol based on the TumbleBit concept. Our goal is to offer a truly trustless and decentralized privacy protocol on the Stratis blockchain and its private chains, while working with financial services regulators on developing regulatory compliant blockchain solutions utilizing the Stratis Privacy protocol.
Enhanced Privacy
Presently there is a huge demand for privacy on the blockchain. One of the main hurdles faced by the adoption of Blockchain technologies in the financial services industry is the privacy of financial data on the blockchain. When the Stratis Financial Privacy protocol is implemented into the Stratis Platform, businesses will have the possibility to use the Stratis Blockchain with a guarantee of privacy from their transactions (payments, records and data). That’s a big advantage over other Blockchain projects.
Why TumbleBit?
The team behind Stratis carefully evaluated the different concepts and technological options to deliver a truly trustless and secure privacy solution that would meet the requirements of enterprise and consumers worldwide. After extensive research, it became evident that TumbleBit was the best fit for our future development goals because it is:
Private: Transactions are truly private and unlinkable.
Untrusted: No one (including Tumbler) can steal payments
Compatible: TumbleBit is fully compatible with today’s Bitcoin protocol.
TumbleBit includes (offblockchain) cryptographic protocols that work with the very limited set of (on-blockchain) instructions provided by today’s Bitcoin scripts
The TumbleBit/Stratis Roadmap
A few weeks ago, Stratis put in motion a development plan for the integration of TumbleBit capabilities into Stratis. Having established the feasibility of such an endeavour, we immediately took the initial steps to make this a reality in the shortest term.
To help us accomplish a smooth and speedy process, we secured the services of Adam Ficsor, one of the contributors to the TumbleBit research paper (https://eprint.iacr.org/2016/575.pdf) and the official implementation of Tumblebit NTumbleBit. As a Technical Advisor for the development of a production ready Tumblebit full block SPV wallet in C# (Breeze Wallet), Adam will help us achieve our goal, by delivering a fully functional full block SPV, while also working on the Stratis Wallet framework and the completion of NTumbleBit.
According to Adam:
“Everyone who is not using Bitcoin Core has already had all their addresses linked together by third parties. This is not a theoretical “assume the worst case” strategy, this is reality. The third parties are either the central servers your wallet relies on or in case of SPV wallets all Blockchain surveillance companies.”
Trustless Exchange: Trustless Stratis <-> Bitcoin exchange
The planned TumbleBit implementation not only will speed up and streamline the development of Stratis full-block SPV TumbleBit wallet, but will also make possible to include in it a trustless, secure exchange for Bitcoin-Stratis pair.
Exposure of Stratis to millions of Bitcoin Users
The expected inflow of Bitcoin users towards a TumbleBit enabled Bitcoin wallet offering enhanced privacy, will undoubtedly translate into making it the de-facto wallet for such transactions around the world. This in turn, will represent an extraordinary opportunity to expose Stratis and its platform to all those users, and this will further cement our symbiotic relationship with the leading cryptocurrency and its community.

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google
Spotify
Consent to display content from Spotify
Sound Cloud
Consent to display content from Sound