Cardano und Litecoin Gründer diskutieren Cross-Chain Projekt

Bull Bitcoin’s Dollar-Cost Averaging tool for Canadians: a detailed overview

Hello fellow Canadian Bitcoiners!
I'm Francis Pouliot, CEO and founder of Bull Bitcoin (previously known as Bitcoin Outlet) and Bylls.
I haven't been active on Reddit for a while but I thought I'd pop back here to let the community know about our new dollar-cost averaging feature, "Recurring Buy"
This post is a copy of my most recent medium article which you can read here if you want to see the screenshots. https://medium.com/bull-bitcoin/bull-bitcoins-dollar-cost-averaging-tool-for-canadians-the-right-time-to-buy-bitcoin-is-every-day-82a992ca22c1
Thanks in advance for any feedback and suggestions!
[Post starts here]
The Bull Bitcoin team is constantly trying to reduce the frictions ordinary people face when investing in Bitcoin and propose innovative features which ensure our users follow Bitcoin best practices and minimize their risks.
We are particularly excited and proud about our latest feature: an automated Bitcoin dollar-cost averaging tool which we dubbed “Recurring Buy”.
The Recurring Buy feature lets Bull Bitcoin users create an automated schedule that will buy Bitcoin every day using the funds in their account balance and send the Bitcoin directly to their Bitcoin wallet straight away.
We put a lot of thought in the implementation details and striking the right trade-offs for a simple and elegant solution. Our hope is that it will become a standard other Bitcoin exchanges will emulate for the benefit of their users. This standard will certainly evolve over time as we accumulate feedback and operational experience.
In this article, I cover:
The problem that we are trying to solve
Recurring Buy feature details, processes and instructions
The rationale (and tradeoffs) behind the main feature design choices
Bull Bitcoin is only available to Canadians, but non-Canadians that wish to have a look at how it works are welcome to make a Bull Bitcoin account and check out how it works here. You will be able to go through the process of create the schedule for testing purposes, but you wont be able to fund your account and actually purchase Bitcoin.
What problems does Dollar-Cost Averaging solve?
The most common concern of Bitcoin investors is, not surprisingly, “when is the right time to buy Bitcoin?”. Bitcoin is indeed a very volatile asset. A quick glance at a Bitcoin price chart shows there are without a doubt “worse times” and “better times” to invest in Bitcoin. But is that the same as the “right” time?
Gurus, analysts and journalists continuously offer their theories explaining what affects the Bitcoin price, supported by fancy trading charts and geopolitical analysis, further reinforcing the false notion that it is possible to predict the price of Bitcoin.
Newbies are constantly bombarded with mainstream media headlines of spectacular gains and devastating losses. For some, this grows into an irresistible temptation to get rich quick. Others become crippled with the fear of becoming “the sucker” on which early adopters dump their bags.
Veterans are haunted by past Bitcoin purchases which were quickly followed by a crash in the price. “I should have waited to buy the dip…”
Many Bitcoin veterans and long-term investors often shrug off the question of when is the right time to buy with the philosophy: “just hodl”. But even those holding until their death will recognize that buying more Bitcoin for the same price is a better outcome.
Given the very high daily volatility of Bitcoin, a hodler can find himself in many years having significantly less wealth just because he once bought Bitcoin on a Monday instead of a Wednesday. His options are either to leave it up to chance or make an attempt to “time the market” and “buy the dip”, which can turn into a stressful trading obsession, irrational decisions (which have a negative impact on budget, income and expenses) and severe psychological trauma. In addition, trying to “buy the dip” is often synonymous to keeping large amounts of fiat on an exchange to be ready for “when the time comes”.
There must be a better way.
Bitcoin investors should be rewarded for having understood Bitcoin’s long-term value proposition early on, for having taken the risk to invest accordingly and for having followed best practices. Not for being lucky.
Overview of features and rules
In this section I go into every detail of the Recurring Buy feature. In the following section, I focus on explaining why we chose this particular user experience.
The user first decides his target investment amount. Ideally, this is a monthly budget or yearly budget he allocates to investing in Bitcoin based on his projected income and expenses.
The user then chooses either the duration of the Recurring Buy schedule or the daily purchase amount. The longer the better.
The frequency is each day and cannot be modified.
The user must submit a Bitcoin address before activating a Recurring Buy schedule. By default, every transaction will be sent to that Bitcoin address. It’s the fallback address in case they don’t provide multiple addresses later.
Once the user has filled the form with target amount, the duration and the Bitcoin address, he can activate the Recurring Buy Schedule.
The user is not required to already have funds in his account balance to activate the schedule.
We will randomly select a time of day at which his transaction will be processed (every hour, so 24 possible times). If the user insists on another time of day, he can cancel his Recurring Buy schedule and try again.


The Recurring Buy feature as displayed on bullbitcoin.com/recurring-buys
The schedule is then displayed to the user, showing the time and date at which transactions that will take place in the future. The user will be able to see how long his current balance will last.
He can follow the progress of the dollar-cost averaging schedule, monitor in real time his average acquisition cost, and audit each transaction individually.
At this point, the user can and should change the Bitcoin address of his next transactions to avoid address re-use. Address re-use is not forbidden, but it is highly discouraged.
After having modified the Bitcoin addresses, there is nothing left for the user to do except watch the bitcoins appear in his Bitcoin wallet every day!
The Bitcoins are sent right away at the time of purchase.
Bitcoin transactions using the Recurring Buy feature will have the lowest possible Bitcoin network transaction fee to avoid creating upwards pressure on the fee market impact other network users.


What users see after first activating a schedule
The Recurring Buy schedule will be cancelled automatically at the time of the next purchase if the balance is insufficient. He can add more funds to his balance whenever he wants.
The Recurring Buy schedule will continue until the target amount is reached or until the account balance runs out.
The user can cancel his Recurring Buy schedule whenever he wants.
If the user wants to change the amount or duration of the schedule, he can simply cancel his current schedule and create a new one.
Each schedule has a unique identifier so that users can keep track of various schedules they perform over time.
Once a schedule is completed, either fully or partially, a summary will be provided which shows the number of transactions completed, the average acquisition cost, the total amount of Bitcoin purchase and the total amount of fiat spent. Useful for accounting!


A partially completed Recurring Buy schedule cancelled after 9 days due to insufficient funds
Though process in making our design choices
Recurring Bitcoin Purchases vs. Recurring Payment/Funding
The first and most important design choice was to separate the processes of funding the account balance with fiat (the payment) from the process of buying Bitcoin (the purchase). Users do not need to make a bank transaction every time they do a Bitcoin purchase. They first fund their account manually on their own terms, and the recurring purchases are debited from their pre-funded account balance.
Another approach would have been to automatically withdraw fiat from the user’s bank account (e.g. a direct debit or subscription billing) for each transaction (like our friends at Amber) or to instruct the user to set-up recurring payments to Bull Bitcoin from their bank account (like our friends at Bittr). The downside of these strategies is that they require numerous bank transactions which increases transaction fees and the likelihood of triggering fraud and compliance flags at the user’s bank. However, this does remove the user’s need to keep larger amounts of fiat on the exchange and reduces the friction of having to make manual bank payments.
Bull Bitcoin is currently working on a separate “Recurring Funding” feature that will automatically debit fiat from the user’s bank accounts using a separate recurring schedule with a minimum frequency of once a week, with a target of once every two weeks or once a month to match the user’s income frequency. This can, and will, be used in combination from the “Recurring Buy” feature, but both can be used separately.
The ultimate experience that we wish to achieve is that users will automatically set aside, each paycheck (two weeks), a small budget to invest in Bitcoin using the “Recurring Funding” feature which is sufficient to refill their account balance for the next two weeks of daily recurring purchases.
Frequency of transactions
The second important decision was about customizing the frequency of the schedule. We decided to make it “each day” only. This is specifically to ensure users have a large enough sample size and remain consistent which are the two key components to a successful dollar-cost averaging strategy.
A higher amount of recurring transactions (larger sample size) will result in the user’s average acquisition being closer to the actual average Bitcoin price over that period of time. Weekly or monthly recurring purchases can provide the same effectiveness if they are performed over a duration of time which is 7x longer (weekly) or 30x longer (monthly).
It is our belief that the longer the duration of the schedule, the more likely the user is to cancel the recurring buy schedule in order to “buy the dip”. Dollar-cost averaging is boring, and watching sats appear in the wallet every day is a good way to reduce the temptation of breaking the consistency.
We do not force this on users: they can still cancel the schedule if they want and go all-in. We consider it more of a gentle nudge in the right direction.
Frequency of withdrawals (one purchase = one bitcoin transaction)
This is one of the most interesting design choices because it is a trade-off between scalability (costs), privacy and custody. Ultimately, we decided that trust-minimization (no custody) and privacy were the most important at the expense of long-term scalability and costs.
Realistically, Bitcoin network fees are currently low and we expect them to remain low for the near future, although they will certainly increase massively over the long-term. One of the ways we mitigated this problem was to select the smallest possible transaction fee for transactions done in the context of Recurring Buy, separate from regular transaction fees on regular Bitcoin purchases (which, at Bull Bitcoin, are very generous).
Note: users must merge their UTXOs periodically to avoid being stuck with a large amount of small UTXOs in the future when fees become more expensive. This is what makes me most uncomfortable about our solution. I hope to also solve this problem, but it is ultimately something Bitcoin wallets need to address as well. Perhaps an automated tool in Bitcoin wallets which merges UTXOs periodically when the fees are low? Food for thought.
When transaction fees and scalability becomes a problem for us, it will have become a problem for all other small payments on the Bitcoin network, and we will use whatever solution is most appropriate at that time.
It is possible that Lightning Network ends up being the scalability solution, although currently it is logistically very difficult to perform automated payouts to users using Lightning, particularly recurring payouts, which require users to create Bolt11 invoices and to convince other peers in the network to open channels and fund channels with them for inbound capacity.
These are the general trade-offs:
Send a Bitcoin transaction for every purchase (what we do) - Most expensive for the exchange - Most expensive for the user (many UTXOs) - Increases Bitcoin Network UTXOs set - Inefficient usage of block space - Most private - Zero custody risk
Keep custody of the Bitcoin until the schedule is over or when the user requests a withdrawal (what Coinbase does) - No additional costs -No blockchain bloating - Same level of privacy - High custody risk
Batch user transactions together at fixed intervals (e.g. every day) - Slightly lower transaction costs for the exchange - Same costs for the user - Slightly more efficient use of block space - Same level of UTXO set bloating - Much lower level of privacy - Slightly higher custody risk
Single address vs multiple addresses vs HD keys (xpubs)
The final decision we had to make was preventing address re-use and allowing users to provide an HD key (xpub) rather than a Bitcoin address.
Address re-use generally decreases privacy because it becomes possible for third-party blockchain snoops to figure out that multiple Bitcoin transactions are going to the same user. But we must also consider that even transactions are sent to multiple addresses, particularly if they are small amounts, it is highly likely that the user will “merge” the coins into a single transaction when spending from his wallet. It is always possible for users to prevent this using Coinjoin, in which there is a large privacy gain in not re-using addresses compared to using a single address.
It is important to note that this does not decrease privacy compared to regular Bitcoin purchases on Bull Bitcoin outside of “Recurring Buy”. Whether a user has one transaction of $1000 going to a Bitcoin address or 10x$100 going that same Bitcoin address doesn’t reveal any new information about the user other than the fact he is likely using a dollar-cost averaging mechanism. It is rather a missed opportunity to gain more privacy.
Another smaller decision was whether or not we should ask the user to provide all his addresses upfront before being able to activate the schedule, which would completely remove the possibility of address re-use. We ultimately decided that because this process can take a very long time (imagine doing Recurring Buy every day for 365 days) it is better to let the user do this at his own pace, particularly because he may eventually change his Bitcoin wallet and forget to change the addresses in the schedule.
There are also various legitimate use-cases where users have no choice but to re-use the same address . A discussion for another day!
Asking the user to provide an XPUB is a great solution to address re-use. The exchange must dynamically derive a new Bitcoin address for the user at each transaction, which is not really a technical challenge. As far as I can tell, Bittr is the only Bitcoin exchange exchange which has implemented this technique. Kudos!
It is however important that the user doesn’t reuse this XPUB for anything else, otherwise the exchange can track his entire wallet balance and transaction history.
It is worth noting that not all wallets support HD keys or have HD keys by default (e.g. Bitcoin Core). So it is imperative that we offer the option to give Bitcoin addresses. We believe there is a lot of potential to create wallet coordination mechanisms between senders and recipients which would make this process a lot more streamlined.
In the future, we will certainly allow users to submit an XPUB instead of having to manually input a different address. But for now, we wanted to reduce the complexity to a minimum.
Conclusion: personal thoughts
I have a somewhat unique perspective on Bitcoin users due to the fact that I worked at the Bitcoin Embassy for almost 4 years. During this time, I had the opportunity to discuss face-to-face with thousands of Bitcoin investors. One of my favourite anecdotes is a nocoiner showing up at our office in December 2013 with a bag full of cash attempting to buy Bitcoin, “I know how to read a chart”, furious after being turned away. Many people who went “all-in” for short-term gains (usually altcoins) would show up to the Bitcoin Embassy office months later with heart-breaking stories.
This isn’t what I signed up for. My goal is to help people opt-out of fiat and, ultimately, to destroy the fiat currency system entirely.
This instilled in me a deep-rooted concern for gambling addiction and strong aversion to “trading”. I do not believe that Bitcoin exchanges should blindly follow “what the market dictates”. More often than not, what dictates the market is bad habits users formed because of the other Bitcoin services they used in the past, what other people are used to, and what feels familiar. Running a Bitcoin company should be inseparable from educating users on the best practices, and embedding these best practices into the user experience is the best way for them to learn.
Another important anecdote which motivated me to build a dollar-cost averaging tool is a person very close to me that had made the decision to buy Bitcoin, but was so stressed out about when was the right time to buy that they ended up not buying Bitcoin for a whole 6 months after funding their Bull Bitcoin account. That person eventually gave up and ultimately invested a large amount all at once. In hindsight, it turned out to be one of the worst possible times to invest in Bitcoin during that year.
Investing in Bitcoin can, and should be, a positive and rewarding experience.
Buying Bitcoin every day is the right strategy, but it is not necessarily lead to the best outcome.
The reality is that the best time to buy Bitcoin is at when market hits rock bottom (obviously). Sometimes, the upside from buying the dip can be much bigger than the risk (e.g. when the price dropped below $200 in 2015). But these are exceptions rather than the rule. And the cost of chasing dips is very high: stress, investing time and mental energy, and the very real psychological trauma which results from making bad trading decisions. Ultimately, it’s better to do the right thing than being lucky, but it’s not always a bad idea to cheat on your dollar-cost averaging from time to time if you can live with the costs and consequences.
Yours truly,
Francis
submitted by FrancisPouliot to BitcoinCA [link] [comments]

FlowCards: A Declarative Framework for Development of Ergo dApps

FlowCards: A Declarative Framework for Development of Ergo dApps
Introduction
ErgoScript is the smart contract language used by the Ergo blockchain. While it has concise syntax adopted from Scala/Kotlin, it still may seem confusing at first because conceptually ErgoScript is quite different compared to conventional languages which we all know and love. This is because Ergo is a UTXO based blockchain, whereas smart contracts are traditionally associated with account based systems like Ethereum. However, Ergo's transaction model has many advantages over the account based model and with the right approach it can even be significantly easier to develop Ergo contracts than to write and debug Solidity code.
Below we will cover the key aspects of the Ergo contract model which makes it different:
Paradigm
The account model of Ethereum is imperative. This means that the typical task of sending coins from Alice to Bob requires changing the balances in storage as a series of operations. Ergo's UTXO based programming model on the other hand is declarative. ErgoScript contracts specify conditions for a transaction to be accepted by the blockchain (not changes to be made in the storage state as result of the contract execution).
Scalability
In the account model of Ethereum both storage changes and validity checks are performed on-chain during code execution. In contrast, Ergo transactions are created off-chain and only validation checks are performed on-chain thus reducing the amount of operations performed by every node on the network. In addition, due to immutability of the transaction graph, various optimization strategies are possible to improve throughput of transactions per second in the network. Light verifying nodes are also possible thus further facilitating scalability and accessibility of the network.
Shared state
The account-based model is reliant on shared mutable state which is known to lead to complex semantics (and subtle million dollar bugs) in the context of concurrent/ distributed computation. Ergo's model is based on an immutable graph of transactions. This approach, inherited from Bitcoin, plays well with the concurrent and distributed nature of blockchains and facilitates light trustless clients.
Expressive Power
Ethereum advocated execution of a turing-complete language on the blockchain. It theoretically promised unlimited potential, however in practice severe limitations came to light from excessive blockchain bloat, subtle multi-million dollar bugs, gas costs which limit contract complexity, and other such problems. Ergo on the flip side extends UTXO to enable turing-completeness while limiting the complexity of the ErgoScript language itself. The same expressive power is achieved in a different and more semantically sound way.
With the all of the above points, it should be clear that there are a lot of benefits to the model Ergo is using. In the rest of this article I will introduce you to the concept of FlowCards - a dApp developer component which allows for designing complex Ergo contracts in a declarative and visual way.
From Imperative to Declarative
In the imperative programming model of Ethereum a transaction is a sequence of operations executed by the Ethereum VM. The following Solidity function implements a transfer of tokens from sender to receiver . The transaction starts when sender calls this function on an instance of a contract and ends when the function returns.
// Sends an amount of existing coins from any caller to an address function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Insufficient balance."); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); } 
The function first checks the pre-conditions, then updates the storage (i.e. balances) and finally publishes the post-condition as the Sent event. The gas which is consumed by the transaction is sent to the miner as a reward for executing this transaction.
Unlike Ethereum, a transaction in Ergo is a data structure holding a list of input coins which it spends and a list of output coins which it creates preserving the total balances of ERGs and tokens (in which Ergo is similar to Bitcoin).
Turning back to the example above, since Ergo natively supports tokens, therefore for this specific example of sending tokens we don't need to write any code in ErgoScript. Instead we need to create the ‘send’ transaction shown in the following figure, which describes the same token transfer but declaratively.
https://preview.redd.it/id5kjdgn9tv41.png?width=1348&format=png&auto=webp&s=31b937d7ad0af4afe94f4d023e8c90c97c8aed2e
The picture visually describes the following steps, which the network user needs to perform:
  1. Select unspent sender's boxes, containing in total tB >= amount of tokens and B >= txFee + minErg ERGs.
  2. Create an output target box which is protected by the receiver public key with minErg ERGs and amount of T tokens.
  3. Create one fee output protected by the minerFee contract with txFee ERGs.
  4. Create one change output protected by the sender public key, containing B - minErg - txFee ERGs and tB - amount of T tokens.
  5. Create a new transaction, sign it using the sender's secret key and send to the Ergo network.
What is important to understand here is that all of these steps are preformed off-chain (for example using Appkit Transaction API) by the user's application. Ergo network nodes don't need to repeat this transaction creation process, they only need to validate the already formed transaction. ErgoScript contracts are stored in the inputs of the transaction and check spending conditions. The node executes the contracts on-chain when the transaction is validated. The transaction is valid if all of the conditions are satisfied.
Thus, in Ethereum when we “send amount from sender to recipient” we are literally editing balances and updating the storage with a concrete set of commands. This happens on-chain and thus a new transaction is also created on-chain as the result of this process.
In Ergo (as in Bitcoin) transactions are created off-chain and the network nodes only verify them. The effects of the transaction on the blockchain state is that input coins (or Boxes in Ergo's parlance) are removed and output boxes are added to the UTXO set.
In the example above we don't use an ErgoScript contract but instead assume a signature check is used as the spending pre-condition. However in more complex application scenarios we of course need to use ErgoScript which is what we are going to discuss next.
From Changing State to Checking Context
In the send function example we first checked the pre-condition (require(amount <= balances[msg.sender],...) ) and then changed the state (i.e. update balances balances[msg.sender] -= amount ). This is typical in Ethereum transactions. Before we change anything we need to check if it is valid to do so.
In Ergo, as we discussed previously, the state (i.e. UTXO set of boxes) is changed implicitly when a valid transaction is included in a block. Thus we only need to check the pre-conditions before the transaction can be added to the block. This is what ErgoScript contracts do.
It is not possible to “change the state” in ErgoScript because it is a language to check pre-conditions for spending coins. ErgoScript is a purely functional language without side effects that operates on immutable data values. This means all the inputs, outputs and other transaction parameters available in a script are immutable. This, among other things, makes ErgoScript a very simple language that is easy to learn and safe to use. Similar to Bitcoin, each input box contains a script, which should return the true value in order to 1) allow spending of the box (i.e. removing from the UTXO set) and 2) adding the transaction to the block.
If we are being pedantic, it is therefore incorrect (strictly speaking) to think of ErgoScript as the language of Ergo contracts, because it is the language of propositions (logical predicates, formulas, etc.) which protect boxes from “illegal” spending. Unlike Bitcoin, in Ergo the whole transaction and a part of the current blockchain context is available to every script. Therefore each script may check which outputs are created by the transaction, their ERG and token amounts (we will use this capability in our example DEX contracts), current block number etc.
In ErgoScript you define the conditions of whether changes (i.e. coin spending) are allowed to happen in a given context. This is in contrast to programming the changes imperatively in the code of a contract.
While Ergo's transaction model unlocks a whole range of applications like (DEX, DeFi Apps, LETS, etc), designing contracts as pre-conditions for coin spending (or guarding scripts) directly is not intuitive. In the next sections we will consider a useful graphical notation to design contracts declaratively using FlowCard Diagrams, which is a visual representation of executable components (FlowCards).
FlowCards aim to radically simplify dApp development on the Ergo platform by providing a high-level declarative language, execution runtime, storage format and a graphical notation.
We will start with a high level of diagrams and go down to FlowCard specification.
FlowCard Diagrams
The idea behind FlowCard diagrams is based on the following observations: 1) An Ergo box is immutable and can only be spent in the transaction which uses it as an input. 2) We therefore can draw a flow of boxes through transactions, so that boxes flowing in to the transaction are spent and those flowing out are created and added to the UTXO. 3) A transaction from this perspective is simply a transformer of old boxes to the new ones preserving the balances of ERGs and tokens involved.
The following figure shows the main elements of the Ergo transaction we've already seen previously (now under the name of FlowCard Diagram).
https://preview.redd.it/9kcxl11o9tv41.png?width=1304&format=png&auto=webp&s=378a7f50769292ca94de35ff597dc1a44af56d14
There is a strictly defined meaning (semantics) behind every element of the diagram, so that the diagram is a visual representation (or a view) of the underlying executable component (called FlowCard).
The FlowCard can be used as a reusable component of an Ergo dApp to create and initiate the transaction on the Ergo blockchain. We will discuss this in the coming sections.
Now let's look at the individual pieces of the FlowCard diagram one by one.
  1. Name and Parameters
Each flow card is given a name and a list of typed parameters. This is similar to a template with parameters. In the above figure we can see the Send flow card which has five parameters. The parameters are used in the specification.
  1. Contract Wallet
This is a key element of the flow card. Every box has a guarding script. Often it is the script that checks a signature against a public key. This script is trivial in ErgoScript and is defined like the def pk(pubkey: Address) = { pubkey } template where pubkey is a parameter of the type Address . In the figure, the script template is applied to the parameter pk(sender) and thus a concrete wallet contract is obtained. Therefore pk(sender) and pk(receiver) yield different scripts and represent different wallets on the diagram, even though they use the same template.
Contract Wallet contains a set of all UTXO boxes which have a given script derived from the given script template using flow card parameters. For example, in the figure, the template is pk and parameter pubkey is substituted with the `sender’ flow card parameter.
  1. Contract
Even though a contract is a property of a box, on the diagram we group the boxes by their contracts, therefore it looks like the boxes belong to the contracts, rather than the contracts belong to the boxes. In the example, we have three instantiated contracts pk(sender) , pk(receiver) and minerFee . Note, that pk(sender) is the instantiation of the pk template with the concrete parameter sender and minerFee is the instantiation of the pre-defined contract which protects the miner reward boxes.
  1. Box name
In the diagram we can give each box a name. Besides readability of the diagram, we also use the name as a synonym of a more complex indexed access to the box in the contract. For example, change is the name of the box, which can also be used in the ErgoScript conditions instead of OUTPUTS(2) . We also use box names to associate spending conditions with the boxes.
  1. Boxes in the wallet
In the diagram, we show boxes (darker rectangles) as belonging to the contract wallets (lighter rectangles). Each such box rectangle is connected with a grey transaction rectangle by either orange or green arrows or both. An output box (with an incoming green arrow) may include many lines of text where each line specifies a condition which should be checked as part of the transaction. The first line specifies the condition on the amount of ERG which should be placed in the box. Other lines may take one of the following forms:
  1. amount: TOKEN - the box should contain the given amount of the given TOKEN
  2. R == value - the box should contain the given value of the given register R
  3. boxName ? condition - the box named boxName should check condition in its script.
We discuss these conditions in the sections below.
  1. Amount of ERGs in the box
Each box should store a minimum amount of ERGs. This is checked when the creating transaction is validated. In the diagram the amount of ERGs is always shown as the first line (e.g. B: ERG or B - minErg - txFee ). The value type ascription B: ERG is optional and may be used for readability. When the value is given as a formula, then this formula should be respected by the transaction which creates the box.
It is important to understand that variables like amount and txFee are not named properties of the boxes. They are parameters of the whole diagram and representing some amounts. Or put it another way, they are shared parameters between transactions (e.g. Sell Order and Swap transactions from DEX example below share the tAmt parameter). So the same name is tied to the same value throughout the diagram (this is where the tooling would help a lot). However, when it comes to on-chain validation of those values, only explicit conditions which are marked with ? are transformed to ErgoScript. At the same time, all other conditions are ensured off-chain during transaction building (for example in an application using Appkit API) and transaction validation when it is added to the blockchain.
  1. Amount of T token
A box can store values of many tokens. The tokens on the diagram are named and a value variable may be associated with the token T using value: T expression. The value may be given by formula. If the formula is prefixed with a box name like boxName ? formula , then it is should also be checked in the guarding script of the boxName box. This additional specification is very convenient because 1) it allows to validate the visual design automatically, and 2) the conditions specified in the boxes of a diagram are enough to synthesize the necessary guarding scripts. (more about this below at “From Diagrams To ErgoScript Contracts”)
  1. Tx Inputs
Inputs are connected to the corresponding transaction by orange arrows. An input arrow may have a label of the following forms:
  1. [email protected] - optional name with an index i.e. [email protected] or u/2 . This is a property of the target endpoint of the arrow. The name is used in conditions of related boxes and the index is the position of the corresponding box in the INPUTS collection of the transaction.
  2. !action - is a property of the source of the arrow and gives a name for an alternative spending path of the box (we will see this in DEX example)
Because of alternative spending paths, a box may have many outgoing orange arrows, in which case they should be labeled with different actions.
  1. Transaction
A transaction spends input boxes and creates output boxes. The input boxes are given by the orange arrows and the labels are expected to put inputs at the right indexes in INPUTS collection. The output boxes are given by the green arrows. Each transaction should preserve a strict balance of ERG values (sum of inputs == sum of outputs) and for each token the sum of inputs >= the sum of outputs. The design diagram requires an explicit specification of the ERG and token values for all of the output boxes to avoid implicit errors and ensure better readability.
  1. Tx Outputs
Outputs are connected to the corresponding transaction by green arrows. An output arrow may have a label of the following [email protected] , where an optional name is accompanied with an index i.e. [email protected] or u/2 . This is a property of the source endpoint of the arrow. The name is used in conditions of the related boxes and the index is the position of the corresponding box in the OUTPUTS collection of the transaction.
Example: Decentralized Exchange (DEX)
Now let's use the above described notation to design a FlowCard for a DEX dApp. It is simple enough yet also illustrates all of the key features of FlowCard diagrams which we've introduced in the previous section.
The dApp scenario is shown in the figure below: There are three participants (buyer, seller and DEX) of the DEX dApp and five different transaction types, which are created by participants. The buyer wants to swap ergAmt of ERGs for tAmt of TID tokens (or vice versa, the seller wants to sell TID tokens for ERGs, who sends the order first doesn't matter). Both the buyer and the seller can cancel their orders any time. The DEX off-chain matching service can find matching orders and create the Swap transaction to complete the exchange.
The following diagram fully (and formally) specifies all of the five transactions that must be created off-chain by the DEX dApp. It also specifies all of the spending conditions that should be verified on-chain.

https://preview.redd.it/fnt5f4qp9tv41.png?width=1614&format=png&auto=webp&s=34f145f9a6d622454906857e645def2faba057bd
Let's discuss the FlowCard diagram and the logic of each transaction in details:
Buy Order Transaction
A buyer creates a Buy Order transaction. The transaction spends E amount of ERGs (which we will write E: ERG ) from one or more boxes in the pk(buyer) wallet. The transaction creates a bid box with ergAmt: ERG protected by the buyOrder script. The buyOrder script is synthesized from the specification (see below at “From Diagrams To ErgoScript Contracts”) either manually or automatically by a tool. Even though we don't need to define the buyOrder script explicitly during designing, at run time the bid box should contain the buyOrder script as the guarding proposition (which checks the box spending conditions), otherwise the conditions specified in the diagram will not be checked.
The change box is created to make the input and output sums of the transaction balanced. The transaction fee box is omitted because it can be added automatically by the tools. In practice, however, the designer can add the fee box explicitly to the a diagram. It covers the cases of more complex transactions (like Swap) where there are many ways to pay the transaction fee.
Cancel Buy, Cancel Sell Transactions
At any time, the buyer can cancel the order by sending CancelBuy transaction. The transaction should satisfy the guarding buyOrder contract which protects the bid box. As you can see on the diagram, both the Cancel and the Swap transactions can spend the bid box. When a box has spending alternatives (or spending paths) then each alternative is identified by a unique name prefixed with ! (!cancel and !swap for the bid box). Each alternative path has specific spending conditions. In our example, when the Cancel Buy transaction spends the bid box the ?buyer condition should be satisfied, which we read as “the signature for the buyer address should be presented in the transaction”. Therefore, only buyer can cancel the buy order. This “signature” condition is only required for the !cancel alternative spending path and not required for !swap .
Sell Order Transaction
The Sell Order transaction is similar to the BuyOrder in that it deals with tokens in addition to ERGs. The transaction spends E: ERG and T: TID tokens from seller's wallet (specified as pk(seller) contract). The two outputs are ask and change . The change is a standard box to balance transaction. The ask box keeps tAmt: TID tokens for the exchange and minErg: ERG - the minimum amount of ERGs required in every box.
Swap Transaction
This is a key transaction in the DEX dApp scenario. The transaction has several spending conditions on the input boxes and those conditions are included in the buyOrder and sellOrder scripts (which are verified when the transaction is added to the blockchain). However, on the diagram those conditions are not specified in the bid and ask boxes, they are instead defined in the output boxes of the transaction.
This is a convention for improved usability because most of the conditions relate to the properties of the output boxes. We could specify those properties in the bid box, but then we would have to use more complex expressions.
Let's consider the output created by the arrow labeled with [email protected] . This label tells us that the output is at the index 0 in the OUTPUTS collection of the transaction and that in the diagram we can refer to this box by the buyerOut name. Thus we can label both the box itself and the arrow to give the box a name.
The conditions shown in the buyerOut box have the form bid ? condition , which means they should be verified on-chain in order to spend the bid box. The conditions have the following meaning:
  • tAmt: TID requires the box to have tAmt amount of TID token
  • R4 == bid.id requires R4 register in the box to be equal to id of the bid box.
  • script == buyer requires the buyerOut box to have the script of the wallet where it is located on the diagram, i.e. pk(buyer)
Similar properties are added to the sellerOut box, which is specified to be at index 1 and the name is given to it using the label on the box itself, rather than on the arrow.
The Swap transaction spends two boxes bid and ask using the !swap spending path on both, however unlike !cancel the conditions on the path are not specified. This is where the bid ? and ask ? prefixes come into play. They are used so that the conditions listed in the buyerOut and sellerOut boxes are moved to the !swap spending path of the bid and ask boxes correspondingly.
If you look at the conditions of the output boxes, you will see that they exactly specify the swap of values between seller's and buyer's wallets. The buyer gets the necessary amount of TID token and seller gets the corresponding amount of ERGs. The Swap transaction is created when there are two matching boxes with buyOrder and sellOrder contracts.
From Diagrams To ErgoScript Contracts
What is interesting about FlowCard specifications is that we can use them to automatically generate the necessary ErgoTree scripts. With the appropriate tooling support this can be done automatically, but with the lack of thereof, it can be done manually. Thus, the FlowCard allows us to capture and visually represent all of the design choices and semantic details of an Ergo dApp.
What we are going to do next is to mechanically create the buyOrder contract from the information given in the DEX flow card.
Recall that each script is a proposition (boolean valued expression) which should evaluate to true to allow spending of the box. When we have many conditions to be met at the same time we can combine them in a logical formula using the AND binary operation, and if we have alternatives (not necessarily exclusive) we can put them into the OR operation.
The buyOrder box has the alternative spending paths !cancel and !swap . Thus the ErgoScript code should have OR operation with two arguments - one for each spending path.
/** buyOrder contract */ { val cancelCondition = {} val swapCondition = {} cancelCondition || swapCondition } 
The formula for the cancelCondition expression is given in the !cancel spending path of the buyOrder box. We can directly include it in the script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = {} cancelCondition || swapCondition } 
For the !swap spending path of the buyOrder box the conditions are specified in the buyerOut output box of the Swap transaction. If we simply include them in the swapCondition then we get a syntactically incorrect script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = { tAmt: TID && R4 == bid.id && @contract } cancelCondition || swapCondition } 
We can however translate the conditions from the diagram syntax to ErgoScript expressions using the following simple rules
  1. [email protected] ==> val buyerOut = OUTPUTS(0)
  2. tAmt: TID ==> tid._2 == tAmt where tid = buyerOut.tokens(TID)
  3. R4 == bid.id ==> R4 == SELF.id where R4 = buyerOut.R4[Coll[Byte]].get
  4. script == buyer ==> buyerOut.propositionBytes == buyer.propBytes
Note, in the diagram TID represents a token id, but ErgoScript doesn't have access to the tokens by the ids so we cannot write tokens.getByKey(TID) . For this reason, when the diagram is translated into ErgoScript, TID becomes a named constant of the index in tokens collection of the box. The concrete value of the constant is assigned when the BuyOrder transaction with the buyOrder box is created. The correspondence and consistency between the actual tokenId, the TID constant and the actual tokens of the buyerOut box is ensured by the off-chain application code, which is completely possible since all of the transactions are created by the application using FlowCard as a guiding specification. This may sound too complicated, but this is part of the translation from diagram specification to actual executable application code, most of which can be automated.
After the transformation we can obtain a correct script which checks all the required preconditions for spending the buyOrder box.
/** buyOrder contract */ def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long) { val cancelCondition: SigmaProp = { buyer } // verify buyer's sig (ProveDlog) val swapCondition = OUTPUTS.size > 0 && { // securing OUTPUTS access val buyerOut = OUTPUTS(0) // from [email protected] buyerOut.tokens.size > TID && { // securing tokens access val tid = buyerOut.tokens(TID) val regR4 = buyerOut.R4[Coll[Byte]] regR4.isDefined && { // securing R4 access val R4 = regR4.get tid._2 == tAmt && // from tAmt: TID R4 == SELF.id && // from R4 == bid.id buyerOut.propositionBytes == buyer.propBytes // from script == buyer } } } cancelCondition || swapCondition } 
A similar script for the sellOrder box can be obtained using the same translation rules. With the help of the tooling the code of contracts can be mechanically generated from the diagram specification.
Conclusions
Declarative programming models have already won the battle against imperative programming in many application domains like Big Data, Stream Processing, Deep Learning, Databases, etc. Ergo is pioneering the declarative model of dApp development as a better and safer alternative to the now popular imperative model of smart contracts.
The concept of FlowCard shifts the focus from writing ErgoScript contracts to the overall flow of values (hence the name), in such a way, that ErgoScript can always be generated from them. You will never need to look at the ErgoScript code once the tooling is in place.
Here are the possible next steps for future work:
  1. Storage format for FlowCard Spec and the corresponding EIP standardized file format (Json/XML/Protobuf). This will allow various tools (Diagram Editor, Runtime, dApps etc) to create and use *.flowcard files.
  2. FlowCard Viewer, which can generate the diagrams from *.flowcard files.
  3. FlowCard Runtime, which can run *.flowcard files, create and send transactions to Ergo network.
  4. FlowCard Designer Tool, which can simplify development of complex diagrams . This will make designing and validation of Ergo contracts a pleasant experience, more like drawing rather than coding. In addition, the correctness of the whole dApp scenario can be verified and controlled by the tooling.
submitted by Guilty_Pea to CryptoCurrencies [link] [comments]

FlowCards: A Declarative Framework for Development of Ergo dApps

FlowCards: A Declarative Framework for Development of Ergo dApps
Introduction
ErgoScript is the smart contract language used by the Ergo blockchain. While it has concise syntax adopted from Scala/Kotlin, it still may seem confusing at first because conceptually ErgoScript is quite different compared to conventional languages which we all know and love. This is because Ergo is a UTXO based blockchain, whereas smart contracts are traditionally associated with account based systems like Ethereum. However, Ergo's transaction model has many advantages over the account based model and with the right approach it can even be significantly easier to develop Ergo contracts than to write and debug Solidity code.
Below we will cover the key aspects of the Ergo contract model which makes it different:
Paradigm
The account model of Ethereum is imperative. This means that the typical task of sending coins from Alice to Bob requires changing the balances in storage as a series of operations. Ergo's UTXO based programming model on the other hand is declarative. ErgoScript contracts specify conditions for a transaction to be accepted by the blockchain (not changes to be made in the storage state as result of the contract execution).
Scalability
In the account model of Ethereum both storage changes and validity checks are performed on-chain during code execution. In contrast, Ergo transactions are created off-chain and only validation checks are performed on-chain thus reducing the amount of operations performed by every node on the network. In addition, due to immutability of the transaction graph, various optimization strategies are possible to improve throughput of transactions per second in the network. Light verifying nodes are also possible thus further facilitating scalability and accessibility of the network.
Shared state
The account-based model is reliant on shared mutable state which is known to lead to complex semantics (and subtle million dollar bugs) in the context of concurrent/ distributed computation. Ergo's model is based on an immutable graph of transactions. This approach, inherited from Bitcoin, plays well with the concurrent and distributed nature of blockchains and facilitates light trustless clients.
Expressive Power
Ethereum advocated execution of a turing-complete language on the blockchain. It theoretically promised unlimited potential, however in practice severe limitations came to light from excessive blockchain bloat, subtle multi-million dollar bugs, gas costs which limit contract complexity, and other such problems. Ergo on the flip side extends UTXO to enable turing-completeness while limiting the complexity of the ErgoScript language itself. The same expressive power is achieved in a different and more semantically sound way.
With the all of the above points, it should be clear that there are a lot of benefits to the model Ergo is using. In the rest of this article I will introduce you to the concept of FlowCards - a dApp developer component which allows for designing complex Ergo contracts in a declarative and visual way.

From Imperative to Declarative

In the imperative programming model of Ethereum a transaction is a sequence of operations executed by the Ethereum VM. The following Solidity function implements a transfer of tokens from sender to receiver . The transaction starts when sender calls this function on an instance of a contract and ends when the function returns.
// Sends an amount of existing coins from any caller to an address function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Insufficient balance."); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); } 
The function first checks the pre-conditions, then updates the storage (i.e. balances) and finally publishes the post-condition as the Sent event. The gas which is consumed by the transaction is sent to the miner as a reward for executing this transaction.
Unlike Ethereum, a transaction in Ergo is a data structure holding a list of input coins which it spends and a list of output coins which it creates preserving the total balances of ERGs and tokens (in which Ergo is similar to Bitcoin).
Turning back to the example above, since Ergo natively supports tokens, therefore for this specific example of sending tokens we don't need to write any code in ErgoScript. Instead we need to create the ‘send’ transaction shown in the following figure, which describes the same token transfer but declaratively.
https://preview.redd.it/sxs3kesvrsv41.png?width=1348&format=png&auto=webp&s=582382bc26912ff79114d831d937d94b6988e69f
The picture visually describes the following steps, which the network user needs to perform:
  1. Select unspent sender's boxes, containing in total tB >= amount of tokens and B >= txFee + minErg ERGs.
  2. Create an output target box which is protected by the receiver public key with minErg ERGs and amount of T tokens.
  3. Create one fee output protected by the minerFee contract with txFee ERGs.
  4. Create one change output protected by the sender public key, containing B - minErg - txFee ERGs and tB - amount of T tokens.
  5. Create a new transaction, sign it using the sender's secret key and send to the Ergo network.
What is important to understand here is that all of these steps are preformed off-chain (for example using Appkit Transaction API) by the user's application. Ergo network nodes don't need to repeat this transaction creation process, they only need to validate the already formed transaction. ErgoScript contracts are stored in the inputs of the transaction and check spending conditions. The node executes the contracts on-chain when the transaction is validated. The transaction is valid if all of the conditions are satisfied.
Thus, in Ethereum when we “send amount from sender to recipient” we are literally editing balances and updating the storage with a concrete set of commands. This happens on-chain and thus a new transaction is also created on-chain as the result of this process.
In Ergo (as in Bitcoin) transactions are created off-chain and the network nodes only verify them. The effects of the transaction on the blockchain state is that input coins (or Boxes in Ergo's parlance) are removed and output boxes are added to the UTXO set.
In the example above we don't use an ErgoScript contract but instead assume a signature check is used as the spending pre-condition. However in more complex application scenarios we of course need to use ErgoScript which is what we are going to discuss next.

From Changing State to Checking Context

In the send function example we first checked the pre-condition (require(amount <= balances[msg.sender],...) ) and then changed the state (i.e. update balances balances[msg.sender] -= amount ). This is typical in Ethereum transactions. Before we change anything we need to check if it is valid to do so.
In Ergo, as we discussed previously, the state (i.e. UTXO set of boxes) is changed implicitly when a valid transaction is included in a block. Thus we only need to check the pre-conditions before the transaction can be added to the block. This is what ErgoScript contracts do.
It is not possible to “change the state” in ErgoScript because it is a language to check pre-conditions for spending coins. ErgoScript is a purely functional language without side effects that operates on immutable data values. This means all the inputs, outputs and other transaction parameters available in a script are immutable. This, among other things, makes ErgoScript a very simple language that is easy to learn and safe to use. Similar to Bitcoin, each input box contains a script, which should return the true value in order to 1) allow spending of the box (i.e. removing from the UTXO set) and 2) adding the transaction to the block.
If we are being pedantic, it is therefore incorrect (strictly speaking) to think of ErgoScript as the language of Ergo contracts, because it is the language of propositions (logical predicates, formulas, etc.) which protect boxes from “illegal” spending. Unlike Bitcoin, in Ergo the whole transaction and a part of the current blockchain context is available to every script. Therefore each script may check which outputs are created by the transaction, their ERG and token amounts (we will use this capability in our example DEX contracts), current block number etc.
In ErgoScript you define the conditions of whether changes (i.e. coin spending) are allowed to happen in a given context. This is in contrast to programming the changes imperatively in the code of a contract.
While Ergo's transaction model unlocks a whole range of applications like (DEX, DeFi Apps, LETS, etc), designing contracts as pre-conditions for coin spending (or guarding scripts) directly is not intuitive. In the next sections we will consider a useful graphical notation to design contracts declaratively using FlowCard Diagrams, which is a visual representation of executable components (FlowCards).
FlowCards aim to radically simplify dApp development on the Ergo platform by providing a high-level declarative language, execution runtime, storage format and a graphical notation.
We will start with a high level of diagrams and go down to FlowCard specification.

FlowCard Diagrams

The idea behind FlowCard diagrams is based on the following observations: 1) An Ergo box is immutable and can only be spent in the transaction which uses it as an input. 2) We therefore can draw a flow of boxes through transactions, so that boxes flowing in to the transaction are spent and those flowing out are created and added to the UTXO. 3) A transaction from this perspective is simply a transformer of old boxes to the new ones preserving the balances of ERGs and tokens involved.
The following figure shows the main elements of the Ergo transaction we've already seen previously (now under the name of FlowCard Diagram).
https://preview.redd.it/06aqkcd1ssv41.png?width=1304&format=png&auto=webp&s=106eda730e0526919aabd5af9596b97e45b69777
There is a strictly defined meaning (semantics) behind every element of the diagram, so that the diagram is a visual representation (or a view) of the underlying executable component (called FlowCard).
The FlowCard can be used as a reusable component of an Ergo dApp to create and initiate the transaction on the Ergo blockchain. We will discuss this in the coming sections.
Now let's look at the individual pieces of the FlowCard diagram one by one.
1. Name and Parameters
Each flow card is given a name and a list of typed parameters. This is similar to a template with parameters. In the above figure we can see the Send flow card which has five parameters. The parameters are used in the specification.
2. Contract Wallet
This is a key element of the flow card. Every box has a guarding script. Often it is the script that checks a signature against a public key. This script is trivial in ErgoScript and is defined like the def pk(pubkey: Address) = { pubkey } template where pubkey is a parameter of the type Address . In the figure, the script template is applied to the parameter pk(sender) and thus a concrete wallet contract is obtained. Therefore pk(sender) and pk(receiver) yield different scripts and represent different wallets on the diagram, even though they use the same template.
Contract Wallet contains a set of all UTXO boxes which have a given script derived from the given script template using flow card parameters. For example, in the figure, the template is pk and parameter pubkey is substituted with the `sender’ flow card parameter.
3. Contract
Even though a contract is a property of a box, on the diagram we group the boxes by their contracts, therefore it looks like the boxes belong to the contracts, rather than the contracts belong to the boxes. In the example, we have three instantiated contracts pk(sender) , pk(receiver) and minerFee . Note, that pk(sender) is the instantiation of the pk template with the concrete parameter sender and minerFee is the instantiation of the pre-defined contract which protects the miner reward boxes.
4. Box name
In the diagram we can give each box a name. Besides readability of the diagram, we also use the name as a synonym of a more complex indexed access to the box in the contract. For example, change is the name of the box, which can also be used in the ErgoScript conditions instead of OUTPUTS(2) . We also use box names to associate spending conditions with the boxes.
5. Boxes in the wallet
In the diagram, we show boxes (darker rectangles) as belonging to the contract wallets (lighter rectangles). Each such box rectangle is connected with a grey transaction rectangle by either orange or green arrows or both. An output box (with an incoming green arrow) may include many lines of text where each line specifies a condition which should be checked as part of the transaction. The first line specifies the condition on the amount of ERG which should be placed in the box. Other lines may take one of the following forms:
  1. amount: TOKEN - the box should contain the given amount of the given TOKEN
  2. R == value - the box should contain the given value of the given register R
  3. boxName ? condition - the box named boxName should check condition in its script.
We discuss these conditions in the sections below.
6. Amount of ERGs in the box
Each box should store a minimum amount of ERGs. This is checked when the creating transaction is validated. In the diagram the amount of ERGs is always shown as the first line (e.g. B: ERG or B - minErg - txFee ). The value type ascription B: ERG is optional and may be used for readability. When the value is given as a formula, then this formula should be respected by the transaction which creates the box.
It is important to understand that variables like amount and txFee are not named properties of the boxes. They are parameters of the whole diagram and representing some amounts. Or put it another way, they are shared parameters between transactions (e.g. Sell Order and Swap transactions from DEX example below share the tAmt parameter). So the same name is tied to the same value throughout the diagram (this is where the tooling would help a lot). However, when it comes to on-chain validation of those values, only explicit conditions which are marked with ? are transformed to ErgoScript. At the same time, all other conditions are ensured off-chain during transaction building (for example in an application using Appkit API) and transaction validation when it is added to the blockchain.
7. Amount of T token
A box can store values of many tokens. The tokens on the diagram are named and a value variable may be associated with the token T using value: T expression. The value may be given by formula. If the formula is prefixed with a box name like boxName ? formula , then it is should also be checked in the guarding script of the boxName box. This additional specification is very convenient because 1) it allows to validate the visual design automatically, and 2) the conditions specified in the boxes of a diagram are enough to synthesize the necessary guarding scripts. (more about this below at “From Diagrams To ErgoScript Contracts”)
8. Tx Inputs
Inputs are connected to the corresponding transaction by orange arrows. An input arrow may have a label of the following forms:
  1. [email protected] - optional name with an index i.e. [email protected] or u/2 . This is a property of the target endpoint of the arrow. The name is used in conditions of related boxes and the index is the position of the corresponding box in the INPUTS collection of the transaction.
  2. !action - is a property of the source of the arrow and gives a name for an alternative spending path of the box (we will see this in DEX example)
Because of alternative spending paths, a box may have many outgoing orange arrows, in which case they should be labeled with different actions.
9. Transaction
A transaction spends input boxes and creates output boxes. The input boxes are given by the orange arrows and the labels are expected to put inputs at the right indexes in INPUTS collection. The output boxes are given by the green arrows. Each transaction should preserve a strict balance of ERG values (sum of inputs == sum of outputs) and for each token the sum of inputs >= the sum of outputs. The design diagram requires an explicit specification of the ERG and token values for all of the output boxes to avoid implicit errors and ensure better readability.
10. Tx Outputs
Outputs are connected to the corresponding transaction by green arrows. An output arrow may have a label of the following [email protected] , where an optional name is accompanied with an index i.e. [email protected] or u/2 . This is a property of the source endpoint of the arrow. The name is used in conditions of the related boxes and the index is the position of the corresponding box in the OUTPUTS collection of the transaction.

Example: Decentralized Exchange (DEX)

Now let's use the above described notation to design a FlowCard for a DEX dApp. It is simple enough yet also illustrates all of the key features of FlowCard diagrams which we've introduced in the previous section.
The dApp scenario is shown in the figure below: There are three participants (buyer, seller and DEX) of the DEX dApp and five different transaction types, which are created by participants. The buyer wants to swap ergAmt of ERGs for tAmt of TID tokens (or vice versa, the seller wants to sell TID tokens for ERGs, who sends the order first doesn't matter). Both the buyer and the seller can cancel their orders any time. The DEX off-chain matching service can find matching orders and create the Swap transaction to complete the exchange.
The following diagram fully (and formally) specifies all of the five transactions that must be created off-chain by the DEX dApp. It also specifies all of the spending conditions that should be verified on-chain.

https://preview.redd.it/piogz0v9ssv41.png?width=1614&format=png&auto=webp&s=e1b503a635ad3d138ef91e2f0c3b726e78958646
Let's discuss the FlowCard diagram and the logic of each transaction in details:
Buy Order Transaction
A buyer creates a Buy Order transaction. The transaction spends E amount of ERGs (which we will write E: ERG ) from one or more boxes in the pk(buyer) wallet. The transaction creates a bid box with ergAmt: ERG protected by the buyOrder script. The buyOrder script is synthesized from the specification (see below at “From Diagrams To ErgoScript Contracts”) either manually or automatically by a tool. Even though we don't need to define the buyOrder script explicitly during designing, at run time the bid box should contain the buyOrder script as the guarding proposition (which checks the box spending conditions), otherwise the conditions specified in the diagram will not be checked.
The change box is created to make the input and output sums of the transaction balanced. The transaction fee box is omitted because it can be added automatically by the tools. In practice, however, the designer can add the fee box explicitly to the a diagram. It covers the cases of more complex transactions (like Swap) where there are many ways to pay the transaction fee.
Cancel Buy, Cancel Sell Transactions
At any time, the buyer can cancel the order by sending CancelBuy transaction. The transaction should satisfy the guarding buyOrder contract which protects the bid box. As you can see on the diagram, both the Cancel and the Swap transactions can spend the bid box. When a box has spending alternatives (or spending paths) then each alternative is identified by a unique name prefixed with ! (!cancel and !swap for the bid box). Each alternative path has specific spending conditions. In our example, when the Cancel Buy transaction spends the bid box the ?buyer condition should be satisfied, which we read as “the signature for the buyer address should be presented in the transaction”. Therefore, only buyer can cancel the buy order. This “signature” condition is only required for the !cancel alternative spending path and not required for !swap .
Sell Order Transaction
The Sell Order transaction is similar to the BuyOrder in that it deals with tokens in addition to ERGs. The transaction spends E: ERG and T: TID tokens from seller's wallet (specified as pk(seller) contract). The two outputs are ask and change . The change is a standard box to balance transaction. The ask box keeps tAmt: TID tokens for the exchange and minErg: ERG - the minimum amount of ERGs required in every box.
Swap Transaction
This is a key transaction in the DEX dApp scenario. The transaction has several spending conditions on the input boxes and those conditions are included in the buyOrder and sellOrder scripts (which are verified when the transaction is added to the blockchain). However, on the diagram those conditions are not specified in the bid and ask boxes, they are instead defined in the output boxes of the transaction.
This is a convention for improved usability because most of the conditions relate to the properties of the output boxes. We could specify those properties in the bid box, but then we would have to use more complex expressions.
Let's consider the output created by the arrow labeled with [email protected] . This label tells us that the output is at the index 0 in the OUTPUTS collection of the transaction and that in the diagram we can refer to this box by the buyerOut name. Thus we can label both the box itself and the arrow to give the box a name.
The conditions shown in the buyerOut box have the form bid ? condition , which means they should be verified on-chain in order to spend the bid box. The conditions have the following meaning:
  • tAmt: TID requires the box to have tAmt amount of TID token
  • R4 == bid.id requires R4 register in the box to be equal to id of the bid box.
  • script == buyer requires the buyerOut box to have the script of the wallet where it is located on the diagram, i.e. pk(buyer)
Similar properties are added to the sellerOut box, which is specified to be at index 1 and the name is given to it using the label on the box itself, rather than on the arrow.
The Swap transaction spends two boxes bid and ask using the !swap spending path on both, however unlike !cancel the conditions on the path are not specified. This is where the bid ? and ask ? prefixes come into play. They are used so that the conditions listed in the buyerOut and sellerOut boxes are moved to the !swap spending path of the bid and ask boxes correspondingly.
If you look at the conditions of the output boxes, you will see that they exactly specify the swap of values between seller's and buyer's wallets. The buyer gets the necessary amount of TID token and seller gets the corresponding amount of ERGs. The Swap transaction is created when there are two matching boxes with buyOrder and sellOrder contracts.

From Diagrams To ErgoScript Contracts

What is interesting about FlowCard specifications is that we can use them to automatically generate the necessary ErgoTree scripts. With the appropriate tooling support this can be done automatically, but with the lack of thereof, it can be done manually. Thus, the FlowCard allows us to capture and visually represent all of the design choices and semantic details of an Ergo dApp.
What we are going to do next is to mechanically create the buyOrder contract from the information given in the DEX flow card.
Recall that each script is a proposition (boolean valued expression) which should evaluate to true to allow spending of the box. When we have many conditions to be met at the same time we can combine them in a logical formula using the AND binary operation, and if we have alternatives (not necessarily exclusive) we can put them into the OR operation.
The buyOrder box has the alternative spending paths !cancel and !swap . Thus the ErgoScript code should have OR operation with two arguments - one for each spending path.
/** buyOrder contract */ { val cancelCondition = {} val swapCondition = {} cancelCondition || swapCondition } 
The formula for the cancelCondition expression is given in the !cancel spending path of the buyOrder box. We can directly include it in the script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = {} cancelCondition || swapCondition } 
For the !swap spending path of the buyOrder box the conditions are specified in the buyerOut output box of the Swap transaction. If we simply include them in the swapCondition then we get a syntactically incorrect script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = { tAmt: TID && R4 == bid.id && @contract } cancelCondition || swapCondition } 
We can however translate the conditions from the diagram syntax to ErgoScript expressions using the following simple rules
  1. [email protected] ==> val buyerOut = OUTPUTS(0)
  2. tAmt: TID ==> tid._2 == tAmt where tid = buyerOut.tokens(TID)
  3. R4 == bid.id ==> R4 == SELF.id where R4 = buyerOut.R4[Coll[Byte]].get
  4. script == buyer ==> buyerOut.propositionBytes == buyer.propBytes
Note, in the diagram TID represents a token id, but ErgoScript doesn't have access to the tokens by the ids so we cannot write tokens.getByKey(TID) . For this reason, when the diagram is translated into ErgoScript, TID becomes a named constant of the index in tokens collection of the box. The concrete value of the constant is assigned when the BuyOrder transaction with the buyOrder box is created. The correspondence and consistency between the actual tokenId, the TID constant and the actual tokens of the buyerOut box is ensured by the off-chain application code, which is completely possible since all of the transactions are created by the application using FlowCard as a guiding specification. This may sound too complicated, but this is part of the translation from diagram specification to actual executable application code, most of which can be automated.
After the transformation we can obtain a correct script which checks all the required preconditions for spending the buyOrder box.
/** buyOrder contract */ def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long) { val cancelCondition: SigmaProp = { buyer } // verify buyer's sig (ProveDlog) val swapCondition = OUTPUTS.size > 0 && { // securing OUTPUTS access val buyerOut = OUTPUTS(0) // from [email protected] buyerOut.tokens.size > TID && { // securing tokens access val tid = buyerOut.tokens(TID) val regR4 = buyerOut.R4[Coll[Byte]] regR4.isDefined && { // securing R4 access val R4 = regR4.get tid._2 == tAmt && // from tAmt: TID R4 == SELF.id && // from R4 == bid.id buyerOut.propositionBytes == buyer.propBytes // from script == buyer } } } cancelCondition || swapCondition } 
A similar script for the sellOrder box can be obtained using the same translation rules. With the help of the tooling the code of contracts can be mechanically generated from the diagram specification.

Conclusions

Declarative programming models have already won the battle against imperative programming in many application domains like Big Data, Stream Processing, Deep Learning, Databases, etc. Ergo is pioneering the declarative model of dApp development as a better and safer alternative to the now popular imperative model of smart contracts.
The concept of FlowCard shifts the focus from writing ErgoScript contracts to the overall flow of values (hence the name), in such a way, that ErgoScript can always be generated from them. You will never need to look at the ErgoScript code once the tooling is in place.
Here are the possible next steps for future work:
  1. Storage format for FlowCard Spec and the corresponding EIP standardized file format (Json/XML/Protobuf). This will allow various tools (Diagram Editor, Runtime, dApps etc) to create and use *.flowcard files.
  2. FlowCard Viewer, which can generate the diagrams from *.flowcard files.
  3. FlowCard Runtime, which can run *.flowcard files, create and send transactions to Ergo network.
  4. FlowCard Designer Tool, which can simplify development of complex diagrams . This will make designing and validation of Ergo contracts a pleasant experience, more like drawing rather than coding. In addition, the correctness of the whole dApp scenario can be verified and controlled by the tooling.
submitted by eleanorcwhite to btc [link] [comments]

Aniracetam [email protected]

Aniracetam

What is Aniracetam

This nootropic falls into the racetam class, as it has the common pyrrolidone structure. Aniracetam tends to be more potent than piracetam, which is another nootropic within the group of racetams. In fact, it is considered to be anywhere from three to ten times more potent.

It is known to improve multiple cognitive functions. It has numerous benefits such as; enhancing mental function, decreasing levels of anxiety, improving memory, and even mood. Since Aniracetam is fat-soluble is crosses the blood-brain barrier with ease, having longer lasting effects.
Quick Details
Name Aniracetam
Synonyms 1-(4-methoxybenzoyl)-2-pyrrolidinon
CAS NO. 72432-10-1
Molecular formula C12H13NO3
Molecularweight 219.24
Purity 99%min
Appearance White crystalline powder
Use Aniracetam is a member of the nootropic family that compares favorably to the standard set by Piracetam in many aspects
Description

Aniracetam seems to enhance the results of corticol GABAergic hang-up separate from NMDA. Aniracetam definitely seems to be in a position to potentiate signalling through nicotinic α4β2 receptors with 3.1nM through friendships with GS healthy proteins, separate from necessary protein kinases.
Aniracetam has been shown with 50mg/kg oral consumption (subjects) to lower the particular turn over prices for dopamine within the striatum and minimizing dopamine levels in the hypothalamus gland as well as striatum; serotonin levels lowered in the hypothalamus gland however improved inside the cortex along with striatum, exactly where it reduced return (hypothalamus gland) and also boost return (cortex, striatum, brain base).[ Aniracetam seems to be able to reduce destruction implemented to memory and also studying incapacity brought on by various real estate agents along with shock to the system including cholinergic antagonists, cerebral ischaemia along with electroconvulsive shock.
Aniracetam Application
1) Improving Memory
2) Improving the brain function
3) Preventing and treating senile demential
4) Enhancing the learning ability
5) Increasing the attention
6) Relieving the anxiety
Aniracetam Dosage
Unlike piracetam, which requires a high dosage of many grams per day, aniracetam is highly potent and requires much less. A typical aniracetam dosage might look something like this:
750 mg x twice per day
Keep in mind that aniracetam peaks in your bloodstream around 40 minutes after taking the drug [12], you might want to vary your doses during the hardest work sessions that you have (perhaps 3 - 4 hours apart). That way you can re-up your dosage rather than taking it all at once.
Many beginners use a small aniracetam dosage so as to avoid the risk of adverse effects. Even a normal aniracetam dosage will probably cause few side effects, but it is worthwhile for beginners to protect themselves in any way possible.
How Does Aniracetam Work?
Each nootropic compound that you ingest has what is referred to as a "mechanism of action". The aniracetam mechanism of action is essentially how it works to make a change in your brain and body.

Aniracetam is unique because the mechanism of action is more well-known than many others in the family. It is a nootropic that excites the AMPA receptors (ampakines) in the brain. This is the main mechanism that is responsible for the downstream effects, such as improved mood, less anxiety, and reduced depression.

This AMPA modulation of aniracetam also allows for increased BDNF (as described in the benefits section). It is through AMPA (and secondary mechanisms) that aniracetam sees most of its benefits.
Aniracetam Benefits
Aniracetam can have many off-label uses. It is considered a fairly safe and low toxicity substance to improve cognition and memory or reduce anxiety symptoms. Like other racetams, it can have an added benefit of reducing free radicals and oxidative stress in the brain which can lead to degenerative diseases and neurological complications. It should not be used as a main line of defence or treatment for degenerative diseases like Alzheimer's and Dementia but may have merit in reducing some of the symptoms associated. Below, are some of the common observed benefits of Aniracetam. Results may vary.

Competitive Advantage
  1. Our company is a professional production leading factory in China in pharmaceutical area of many years.
Delivery areas of our products: US, UK, Canada, Australia, Brazil, Russia, Portugal, Latvia, Switzerland, Iceland, Ukraine, Germany, France, Netherlands, Belgium, Peru, Sweden, New Zealand, the Czech Republic, Lithuania, Ireland, Tunisia, Mexico, Greece, Puerto Rico, Thailand, Israel and so on.
Payment method: T/T, Western union, Moneygram, bitcoin etc.
  1. Discreet package. The packing suits you best would be choosen to cross customs safely. Or if you have your own ideal way, it could be also take into consideration.
  2. Top quality. High quality guarenteed, once any problem is found, the package would be reshipped for you.
  3. Security Shipping: Shipping by express (FedEx, UPS, DHL, EMS), by air. The most professional forwarder would be recommanded for you.
  4. We have stock, so we can delivery quickly at the very day when receive the payment.
  5. Warm after-sale service for you 24/7. Any of your question would be solved for the first as soon as possible.
  6. A discount would be given when you make a large order.
Web: www.rawsgear.com
Web: www.rawsgearpharma.com
Email: [[email protected]](mailto:[email protected])
Skype: +8615711952876
Whatsapp +8615711952876
submitted by Flora007 to u/Flora007 [link] [comments]

Tamoxifen [email protected]

Tamoxifen gear@quality-steroid.com
Tamoxifen

Quick detail
Product Name: Tamoxifen citrate
Synonyms: 1-p-beta-dimethylaminoethoxyphenyl-trans-1,2-diphenylbut-1-ene citrate;(z)-2-(4-(1,2-diphenyl-1-butenyl)phenoxy)-n,n-dimethylethanamine,citrate(1:;(z)-2-(para-(1,2-diphenyl-1-butenyl)phenoxy)-n,n-dimethylethylaminecitrate(;2-(4-(1,2-diphenyl-1-butenyl)phenoxy)-n,n-dimethyl-ethanamin(z)-ethanamin2-hydrox;ici46,474;kessar;noltam;tamofen
CAS: 54965-24-1
MF: C32H37NO8
MW: 563.64
EINECS: 259-415-2
Melting point: 140-144 °C
Mol File: 54965-24-1.mol
Tamoxifen citrate Structure
Web: www.rawsgear.com
Web: www.rawsgearpharma.com
Email: [[email protected]](mailto:[email protected])
Skype: +8615711952876
Whatsapp +8615711952876
Tamoxifen Citrate description:
Tamoxifen Citrate is a Selective Estrogen Receptor Modulator (SERM) that was created in 1961 by ICI now known as AstraZenaca. There are numerous brands including generic forms of Tamoxifen Citrate on the market, but Nolvadex is the most well known. Often referred to as an anti-estrogen, Tamoxifen Citrate is actually both an antagonist and agonist. This means it will act as an anti-estrogen in certain areas of the body while acting as an estrogen in other areas.
Tamoxifen Citrate has been used medically for decades and has been highly successful in breast cancer treatment, specifically hormone-responsive breast cancer. It is also a medication that is used by many anabolic steroid users, but it is not a steroid. This is a drug steroid users will sometimes use during steroid use to help with estrogenic related side effects brought on by specific steroids. However, it is most commonly used during Post Cycle Therapy (PCT). PCT is the 3-6 week period following steroid use that is implemented in order to help with natural testosterone production that is suppressed during anabolic steroid use.

Tamoxifen Citrate Functions & Traits

Tamoxifen Citrate is a SERM that acts as both antagonist and agonist in relation to the estrogen hormone. It is an anti-estrogen in that it binds to estrogen receptors in certain parts of the body, particularly in the mammary tissue. This action prevents estrogen from acting on its originally intended point of binding. This makes Tamoxifen Citrate valuable to breast cancer patients as breast cancer feeds off of estrogen. And it’s valuable to steroid users as increased estrogen levels can bind to the mammary tissue and lead to gynecomastia.
The relationship Tamoxifen Citrate has in being an anti-estrogen is fairly straightforward and well understood by many, but it’s its relationship to being an estrogen in other areas that’s surprising to some. Tamoxifen Citrate acts as an estrogen on the liver. Liver related estrogenic activity has been shown to improve cardiovascular health, particularly as it relates to cholesterol. This can be very advantageous for the bodybuilding steroid user as most steroids have a negative impact on cholesterol levels.
Beyond its estrogen related activity Tamoxifen Citrate possesses strong testosterone stimulating properties. The use of Tamoxifen Citrate will stimulate the pituitary to increase its production of Luteinizing Hormone (LH) and Follicle Stimulating Hormone (FSH) with a strong emphasis on LH. LH and FSH are the gonadotropins that signal to the testicles to produce testosterone. Without LH and FSH there is no testosterone production.
Effects of Tamoxifen Citrate

For the anabolic steroid user the positive effects of Tamoxifen Citrate can be seen both during and post anabolic steroid use with post use being primary. Anabolic steroids like Testosterone and Nandrolone among others will increase the body’s serum estrogen levels. This occurs by the testosterone hormone converting to testosterone, which happens due to it being metabolized by the aromatase enzyme. Once aromatized you have more estrogen, and this can lead to gynecomastia and water retention. It can also lead to high blood pressure if water retention becomes severe. Tamoxifen Citrate does not lower serum estrogen levels, but it will bind to the receptors in the chest preventing the estrogen from binding. It will not do a lot for water retention if that is an issue. It is also not enough gynecomastia protection for all men, but that depends on how high estrogen levels go as well as genetics. If more or stronger protection is needed Aromatase Inhibitors (AI’s) are recommended. AI’s are anti-estrogens that inhibit aromatase activity and lower serum estrogen levels.
We then have the testosterone stimulating effects of Tamoxifen Citrate. This is by far the most important effect for the anabolic steroid user. When we use anabolic steroids we suppress our natural testosterone production, and this will occur regardless of the steroids used. Steroid use creates a negative feedback and tells your pituitary to stop making LH and FSH. This is why almost all steroid cycles include exogenous testosterone so that the negative feedback doesn’t cause a low testosterone level. Once steroid use is complete something is then needed to jump start testosterone production. It will occur on its own, but it will be slow and Tamoxifen can both speed it up and make it more efficient. Tamoxifen Citrate is introduced, LH and FSH levels go up and as a result testosterone is produced.
Important Note: PCT use that includes Tamoxifen Citrate or any SERM, for it to be successful this assumes no prior low testosterone condition existed. It also assumes no damage was done to the Hypothalamic-Pituitary-Testicular-Axis (HPTA) during use. If prior low levels existed Tamoxifen Citrate won’t magically fix this. If severe damage was done to the HPTA you will not recover and may be in need of low testosterone treatment.
Important Note: Many steroid users believe that a good PCT brings about full recovery, but this is a false belief. A PCT that includes Tamoxifen Citrate will stimulate recovery, but it will not end it. It will still take several months for full recovery to occur, but it stands a much better chance with PCT than without.
For the breast cancer patient the effects of Tamoxifen Citrate are perhaps even more straightforward than they are for the anabolic steroid user. Estrogen attaches and feeds the cancer, but Tamoxifen Citrate prevents it from attaching and starves the cancer. This is a simple yet effective means of treatment. This is not the only drug used in treatment; commonly treatment will begin with an AI and then will be switched to a SERM like Tamoxifen Citrate. It is also sometimes used as a preventative measure in those that have a strong family history of breast cancer.
How to make order ?

1.Browse our online shop and tell me what product do you want to buy .
2.Contact aimee if there are some problems.
3.Our payment way is Western Union , Money Gram,T/T and Bitcoin.
4.We will send out the parcel in 24 hours after your payment .
5.And then you will get a tracking number .
Top reason why you choose us ?

1.Fast discreet delivery with great shipping success!
3.Pictures with your order & details!
2.We will provide you the tracking number!
3.Keep track of your goods untill the goods are sent in to your hands.
4.We confirm 99% clearance,100% resending.
6.High quality,100% pure products!
7.Delivery time approx. 4-6 business days.
8.Best, Safe and Secure services.
9.Customer support 24/7.


SHIPPING & DELIVERY

1.Packages are generally dispatched within approximately 2 days after receipt of payment.
2.After the each shipping we will provide you with:
1) a link & tracking number to track your package online.
2) the few pictures with your order & details.
3.About the Custom clearance,we packed in disguise ways.In our experience,the appropriate and safe delivery,there won't be problems.
4.We confirm 99% clearance,100% resending.
5.Is it the best & safest shipping for all our repeat customers!

NO minimum amount order , 100% pure products!
Our advantages:

Our company is a professional raw powder factory in China for over 10 years, all powders are factory directly supplying.

Our products have exported to Germany, Norway, Poland, Finland, Spain, UK, France, Russia, USA, Australia, Japan, Korea and many other countries, over 100kgs each month.

Professional team special for package and shipment and staring on tracking code 24hours for customs pass guaranteed. 100% pass to UK, Norway, Poland, Spain, USA, Canada, Brazil; 98% pass to Germany, Russia, Australia, New Zealand.

Most of powders are in stock, Chargeable samples are available, Could be shipped out within 24hours.
High quality, good price, fast and safety delivery. Shipment by DHL, TNT, FEDEX, HKEMS, UPS, etc.

https://preview.redd.it/pyfetpmu1db31.jpg?width=700&format=pjpg&auto=webp&s=a87b7a7b0bd968ffb7daa9be518a26843f01b172
submitted by Flora007 to u/Flora007 [link] [comments]

BIP 199 HTLC initial stack state

Hey fellow bitcoiners and redditors

I'm trying to understand how HTLCs (Hashed Time-Locked Contracts) can be implemented in Bitcoin and BIP-199 turned out to be the best resource for that purpose.

TL;DR
Question answered!
  1. Does the stack need to feature the secret/image twice in the OP_IF case? => call the script with [pubKey, signature, 1]
  2. How can the OP_ELSE flow ever be executed successfully (since this requires the stack to be empty, but [pubKey, signature] are required for OP_CHECKSIG at the very end of the script )? => call the script with [pubKey, signature, 0]

Full story
This is the example HTLC script I copied from BIP-199:
OP_IF
[HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160
OP_ELSE
[TIMEOUTOP] OP_DROP OP_DUP OP_HASH160
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

IF-Case (seller can claim the buyers deposited BTCs)
TL;DR: detailed debug log of this path. Question: Can I avoid providing the preimage twice?

Before running this script, the preimage should be known and the stack should looks:
preimage
preimage
pubKey
signature

  • So since the stack is not empty, it will jump into the OP_IF clause.
    • the OP_IF will pop the top value => stack is now: [preimage, pubKey, signature]
  • [HASHOP] will hash the preimage
    • the preimage on the stack will, be replaced by the image => stack: [image, pubKey, signature]
  • digest (a synonym for image) will be pushed
    • => stack: [image, image pubKey, signature]
  • OP_EQUALVERIFY checks the two top items for equality: image == image => true
    • ...and removes them, if they are equal => stack: [pubKey, signature]
  • OP_DUP will duplicate the pubKey, => stack: [pubKey, pubKey, signature]
  • OP_HASH160 will double-hash the pubKey => stack: [p2pkhAddress, pubKey, signature]
  • represents the p2pkhAddress => stack: [p2pkhAddress, p2pkhAddress, pubKey, signature]
  • OP_EQUALVERIFY checks the two top items for equality: p2pkhAddress == p2pkhAddress => true
    • ...and removes them, if they are equal => stack: [pubKey, signature]
  • OP_CHECKSIG checks the signature
  • Done, all fine!
  • Question: This flow requires the secret to be on the stack twice before starting the script; Can I avoid that somehow?

ELSE-Case (buyer claims refund of his/her deposited BTCs)
Since the script runs an OP_CHECKSIG at the very end. This means the stack has to contain at least [pubKey, signature] before the execution pointer moves to OP_IF. However, OP_IF returns true "If the top stack value is not False". So how can the script possibly ever execute the OP_ELSE flow?

Disclaimer
  • My mother tongue is not English, please forgive me any mistakes. :)
  • I'm just getting started with BTC scripting, please forgive me any noob mistakes.
  • I also searched the whole stackexchange/search engine/reddit/github universum for this issue, obivously without success.
PS - buy Bitcoin :)
submitted by redditeraya to Bitcoin [link] [comments]

Build the POR Consensus Algorithm

Build the POR Consensus Algorithm

A Call for Decentralization

Centralized systems are at the backbone of our society, often working unnoticed or otherwise taken for granted as given facets of life. These institutions handle our most sensitive data and our most intimate of communications; our entire life’s savings exist as strings of numbers stored on their servers. These are the banks, the Facebooks, and the Googles that have become increasingly interwoven into our daily lives. We depend on them to make sure their systems run smoothly, efficiently, and fairly. Generally, we can go about our lives without any hiccups, trusting that our paychecks are kept safe and our emails are impenetrable. It’s comforting knowing there are authorities guarding our information and looking out for our best interest - but what if our trust is misplaced?
Facebook is currently negotiating a multi-billion dollar settlement for mishandling user data, Equifax recently compromised 100 million social security numbers, and we can’t even access our own money without paying someone else a fee. These third parties have become judge and jury, siphoning away the rights of the individual in favor of their own bottom line.
We are conditioned to brush off these grave institutional failures as inconveniences - mention a fine or tighter regulation for the offender, and life grinds on until the next incident. The truth is, however, there is an alternative to having third parties dictate the terms by which we live our lives. We don’t need to accept the latest bank fee increase or hope agreeing to the latest “terms of service” doesn’t mean our personal data gets sold.
More than just a buzzword or a new investment, blockchain represents ideology. It represents a major shift from unwavering trust in the institutions that own our data and control our money toward a more people-centered future. It represents a system built for and maintained by the people, a system where “person” and “consumer” are not synonymous - a system where rights are valued over profits.

The Emergence of a New System

Like any emerging complex system, blockchain was not born perfect. The underlying technology was first billed as Bitcoin - an alternative currency that eliminated the need for banking institutions. This made it possible to send electronic payments directly from person to person without the need to trust third parties with the transactions. No fees, no waiting 3 to 5 business days, no limits, no paperwork. Inadvertently, Bitcoin gave birth to something much more lasting - blockchain. Akin to first sending emails and later discovering that the internet powering those emails could be used for other purposes, use cases of blockchain have diversified immensely. Its decentralized and non-tamperable nature provide increased data security, speedy transactions, and an easily verifiable record while being free from any singular governing authority. Due to this, it is an ideal environment to send payments, develop applications, store contracts, track global shipments, manage assets, and much more.
However, pragmatically reaching this point has been a work in progress due to design flaws in the preliminary systems. Based on the decentralized nature of blockchain, information is not stored on a singular server - no one taskmaster updates the server or is responsible for authenticating the information and then relaying it to users. Instead, the blockchain system relies on a global network of users relaying information, updating the ledgers, and authenticating transactions. Each one of these relaying users - called nodes - must agree on the same history of events in order for it to appear on the blockchain. Reaching an agreement can be time and labour intensive - making the process slower than centralized systems that rely on a singular central core. Deciding just how to reach an agreement is the first of two issue that must be solved in order to increase speed and security.
The second lies in the fact that some nodes may even attempt to falsify information for personal gain. This means that we must work to make the system as fast as possible while also eliminating malicious users. Even if we solve the latter issue, the amount of data going through the system is slowed down to a trickling bottleneck as all of the nodes work to verify what gets added to the growing chain. Therefore, the current nature of blockchain results in sacrificing speed for increased security unseen in centralized systems. These issues must then be solved in order to build a truly secure, efficient, and fast environment for mass user adoption.
Both Bitcoin and the second generation blockchain Ethereum use versions of the Proof-of-Work algorithm - a methodology through which the nodes reach a consensus on what gets added to the chain. While Ethereum improved upon the first generation by implemented what are known as Smart Contracts and the Ethereum Virtual Machine, which provided users with what was thought to be an ideal operating platform, slow performance is still an issue.
In order for a blockchain to be practical for those who use it, the amount of traffic the system can handle at any given time must be scaled higher. Bitcoin can handle around 7 transactions per second (TPS) while Ethereum pushes the limit to 20 TPS. In comparison, Visa can manage an impressive 24,000 transactions per second. Later projects such as EOS, which use the Delegated Proof-of-Stake (DPoS) consensus mechanism, have reached speeds of more than 9000TPS - but the battle is not over.
Of course, speed is at the cornerstone of any platform. Developers care about how many people their app can support at any given time and users care about not having their access throttled, but the process through which these outcomes are achieved also hold importance in the arena. Not only must we work to build faster blockchains, but these efforts cannot skew away from the ideology which first gave birth to them.

A Fast, Secure, and Conscientious Blockchain Platform for Mass Adoption

Under the Proof-of-Work consensus algorithm seen in Bitcoin and Ethereum, all nodes may take part in the data verification process. This greatly limits the amount of transactions that the systems can handle, meaning that mass adoption is limited. The more users that onboard, the more nodes the data must be verified by, increasing exponentially the strain on the system.
The Delegated Proof-of-Stake consensus algorithm was able to solve this issue by allowing only a select few “super” nodes to take part in the verification process. These nodes are selected randomly based on the amount and age of coins that the users hold in the system. Hypothetically this would be a decent system, but in practice the incentives for bribery are increased which result in a higher probability of malicious nodes working for self gain.
The Proof-of-Reputation (PoR) consensus algorithm developed by Bitconch has not only solves the issue of slow transaction speeds, but has also laid the foundation to create a more well-rounded community and efficient operating platform with reduced incentives for malicious behavior. Through building upon previous generations of consensus algorithms, PoR has produced speeds of up to 120,000 transactions per second, rivaling the efficiency of centralized systems while also exemplifying the security present in decentralized systems.
The methodology is similar to the DPoS consensus algorithm in that PoR relies on special nodes for the verification process, however, the amount of coins held is no longer a consideration. The reputation value (Bit-R) of Bitconch coin (BUS) holders participating in the verification process is determined by three factors: user socialization, currency holding time, and computing power contribution.
https://preview.redd.it/fioo7azlr8h21.png?width=2033&format=png&auto=webp&s=1a46501c37d08b9af916e8da043b7cb178d02561
In short, through detailing users habits, trustworthiness and contributions, users are assigned a comprehensive and quantitative reputation value. Only those with Bit-R values in the top 5% are eligible for the verification process, and in order to balance efficiency and decentralization, between 30 and 500 nodes from those within this top 5% are randomly selected for the final verification. Therefore, the Bitconch chain builds an ecosystem that mirrors the organic nature of society - rewarding those who make positive contributions in the community, not only those who have the most resources. Alone, however, this process is still not enough to push TPS above those already produced through DPoS consensus algorithms - maxing out around 10,000TPS.
Achieving the 120,000TPS seen in the Bitconch ecosystem depends on further optimization known as BLAZE (Bitconch Ledger Access Zero-delay Extension). This allows for the simultaneously verification of multiple blocks through factoring the operation into five unique yet concurrent phases - fetching data, decoding, hashing, stating the change, and finally writing data.
https://preview.redd.it/a9aobk0nr8h21.png?width=1064&format=png&auto=webp&s=55956d8ddbd696d4986cc7c21fc414e5454e09a4
When coupled with BLAZE, the Bitconch Proof-of-Reputation consensus algorithm produces a platform capable of withstanding large scale commercial traffic that would otherwise cripple previous blockchains.
The result is an efficient operating platform scaled to the requirements of diversified business, creative, and personal needs that also integrates fundamental values vital in building a self-sustained and conscientious ecosystem.

Bitconch

submitted by dongchpp to BitConch [link] [comments]

Thermodynamics & Silent Weapons for Secret Wars or Crypto Anarchy 101: Statists Failing & Anarchists Thriving

Crypto Anarchy 101: Statists Failing & Anarchists Thriving
The black-market, the free-market, is what kept people alive throughout the worst of oppressions. The black market has been the art of surviving amidst all types of tyrannies and slaveries. The black market, aka System D, is something that everyone in the world will need to start getting comfortable with. CryptoAnarchy is the ultimate manifestation of complete market freedom, and it is here to stay.
Libertarians are beginning to finally realize their incredible advantage within this new market environment. The unfortunate statist masses have been programmed to feel uncomfortable with the mere idea of complete market freedom. Keep in mind that as of 2009, half of the world’s workers- around 1.8 billion – were employed by System D. The black market is only expected to grow even more so with the incentive structures being built out in order to advance the technological advancements of cryptography.
Humanity has never experienced a true free-market until now. For the first time in history one is beginning to take shape. The traditional business sector is beginning to realize that they are not even mentally equipped for the implications of having applied cryptography that is powered by market incentives. This is evident in their trite attempts at integrating these new technologies with traditional banking and financial systems. Their lack of creativity, and dependence on government, is a clear testament to how much they will be hurt in the coming future.
Statists Double Down after Failure: Tether and Stablecoins
Many within the crypto space have attempted to bridge the gap between legacy banking and cryptocurrencies. Amongst the various attempts at capitalizing with these new technologies, the idea of a stablecoin entered the space via Tether (USDT).
A stable coin is a cryptocurrency that is pegged on a 1 to 1 ratio to the US dollar, or any other asset- like gold- or fiat. Tether operated as a stable coin pegged to the US dollar on a 1 to 1 ratio. The biggest attribute behind stablecoins resided in their ability to provide stability in an otherwise volatile market.
For a long time many within the crypto space were curious about Tether’s means of operating with USD. Earlier this year TDV was the first entity to exclusively reported to its subscribers the origin of Tether’s “secret sauce;” fractional reserve banking.
The laws of fractional reserve banking allowed the Noble Bank of Puerto Rico to provide Tether with the legal means of operating as a stable coin pegged to the US dollar. The Noble Bank recently went bankrupt due to being insolvent. Noble Bank was the bank of Bitfinex and Tether. As a result, Tether and Bitfinex ended their relationship with Noble Bank.
It is important that you as a subscriber move your crypto out of Bitfinex. You should never keep your cryptoin exchanges. When you do this you don’t actually control the private keys of your coins.
(If you are an active trader, please consider using Bisq. Bisq is an open source decentralized exchange that does not control your private keys while trading. It is the most Anarchist exchange in the market right now.)
After losing its partnership with Noble Bank, Bitfinex began banking with HSBC. On October 15th, Bitfinex tweeted that their fiat deposit system was re-enabled. Overall, Bitfinex is still in the midst of reorganizing itself as an exchange with proper banking liquidity. For this reason we are of the opinion that it is best to stay away from Bitfinex until they are more solvent in their banking partnerships.
Tether (USDT) on the other hand is suffering from a lack of proper banking structures. Binance paused all USDT withdrawals and KuCoin, the exchange, also paused USDT deposits and withdrawals.
Tether is currently at around 2.1bn dollar market cap. Tether holders are having a difficult time cashing out of their Tether for USD. It is expected that unless Tether gets its banking situation sorted out, we will see movement out of Tether. This situation has caused the price of Tether to hit a low of $0.90 to the USD. As of writing this, Tether is trading at around $0.97 to the dollar.
The situation for Tether is dire at the present moment. We expect to see many Tether holders drop their Tether for Bitcoin, or other more cryptographically secure cryptocurrencies. This will more than likely be one of the main strategies that will be implemented in order to cash out of Tether.
This overall situation is once again showing us how unstable things are when dealing with fiat. We hope for the market to realize that there is more security in cryptocurrencies than there is in fiat backed stablecoins. Stablecoins will always have the instability of the fiat currencies that they are pegged to. The time will eventually come when people will realize that cryptocurrencies are a better store of value than stablecoins.
In spite of all of the issues circulating Tether, statist entrepreneurs are doubling down on their desire for stablecoins. We are seeing the beginning of what we believe will be a trend in the upcoming future; that is, stable coins pegged to various countries’ fiat and assets like precious metals. The new USD stablecoins recently announced to the market are GeminiUSD, TrueUSD, and Paxos Standard.
Volatility as a Sign of Life in the Market
Contrary to the statist perception on volatility, one can also view volatility in crypto as proper to a market that is fully alive. Crypto, for the first time in history, freed the market from bankster manipulation. Arguably, volatility is to be expected in an unregulated free-market where everyone in the world is for the first time welcomed to participate.
In comparison to the legacy financial system, crypto is fully alive while the former is handicapped by regulations, coercion, and disconnected from true free-market signals. That is, volatility signals of a free-market that breathes freely for the first time. Volatility is indicative of a market that is fully alive.
The desire for individuals to attach crypto to the legacy financial system, under the pretense of “less volatility,” is indicative of individuals that will have a hard time operating outside the bounds of regulation and government coercion. As long as we have statists uncomfortable with Anarchy, we will have stablecoins pegged to fiat.
Various Libertarian entrepreneurs are also beginning to dabble with the idea of a stablecoin that is pegged to precious metals. The challenge of these projects will be the same regulation that oversees fiat. Remember that the difference offered to the world by cryptocurrencies resides in crypto’s ability to operate freely within System D, without regulation. It is this new market, the true free-market, that for the first time is unstoppable.
Bitfinex’s Effect on EOS
Bitfinex is one of the entities that holds the greatest amount of votes for EOS Block Producers (BPs). For this and other reasons, we are currently expecting a shakeup of votes for selected top BPs. It is important that you remain attentive to the happenings within EOS and move your votes accordingly.
We will soon be coming out with more details on our perceptions regarding various BPs.
There are various discussions regarding BPs pending arbitration. This is a good thing. All shakeups lead us closer to more transparency and accountability. This should not directly affect the price of EOS, aside from what will result from the expected FUD of future BP shake-ups.
The Resilience of CryptoAnarchy after Blockstream’s Fake Sidechain
Amongst the various innovations within Bitcoin, sidechains have- for the past 5 years- existed as one of the holy grails of innovation. Blockstream, as a company, was put together to manifest sidechains. They sold us the concept of a sidechain as they were sourcing capital during their first rounds of investment; this was in October of 2014.
Sidechains were supposed to be delivered by Blockstream as a way to make Bitcoin innovation competitive to that of altcoin innovation. Sidechains were supposed to be “the Altcoin killer.”
After all of this time, Blockstream only delivered Liquid - which is not a sidechain- and called it a “sidechain.” That is, Liquid is not a sidechain when properly defined. Liquid is a multi-signature layer that allows for multiple exchanges to pool their money together to transfer funds amongst themselves. Liquid is not a true sidechain, it is more precisely a multi-signature wallet.
Calling Liquid a “sidechain” was just a marketing scheme by Blockstream in order to impress the illusion that they had delivered what they had promised. They didn’t. Blockstream gave up in attempting to create a true sidechain and created a multi-signature wallet instead. Keep in mind that Liquid is a “private sidechain.” Note that a proper sidechain ought to be made with open-source innovation in mind. Many of us see the actions of Blockstream as a bait and switch marketing scheme.
(For the rest of this article I will use the words “Drivechains” and “sidechains” interchangeably as synonyms. Drivechains are what sidechains originally were supposed to be- according to the original Blockstream Sidechain white paper. Blockstream’s bait and switch marketing scheme led to them calling “sidechain” a multisignature wallet that is not at all what they promoted on their white paper. Paul Sztorc, in an attempt to differentiate himself from the Blockstream perversion of the word “sidechains,” called his development of true sidechains “Drivechains.”)
Drivechain Sidechains
Paul Sztorc, the creator of decentralized prediction markets, was very much looking forward to Blockstream’s creation of sidechains. It was his hope that his decentralized prediction market would run as a Bitcoin sidechain. At about the end of 2015 Sztorc was done with BitcoinHiveMind, his decentralized predictions market (previously known as TruthCoin).
After realizing that Blockstream was not going to deliver on sidechains, as promised, Sztorc felt he needed to build it himself. The creation of his Drivechains started off as a means to an end for Sztorc; he needed true Sidechains for his decentralized predictions market- so he build it himself.
On September 24, 2018 Paul Sztorc announced the launch of the first Drivechain release. This release was accompanied with fervent followingof old-school Bitcoiners that immediately jumped into experimenting with Drivechains on the testnet known as “Testdrive.”
The Drivechain protocol is an alternative to the sidechain project originally proposed by Blockstream. It is a simpler design that enables blockchain compatibility in which the system still utilizes the same 21 million bitcoin ruleset- the Nakamoto consensus.
Drivechains are intended to allow for permissionless innovation without diluting or challenging the value of the main cryptocurrency. Contrary to other means of innovation within crypto, any innovation that comes from a Drivechain sidechain actually adds value to the Bitcoin protocol- for it does not dilute the main cryptocurrency. Satoshi vaguely discussed the importance of the ideas of sidechains and multi-blockchain connectivity on June 17, 2010.
This creation, of providing varied market options, make infighting and political discourses regarding consensus upgrades now seem infantile. Drivechains will provide the market with ongoing competitive solutions for blockchain development. Investors will now be exposed to options that would otherwise have been shunned in a less free environment.
The strategic advantage of Drivechain sidechains is that they will offer investors various options in the form of alternative chains. It is important to keep in mind that Drivechains are available for blockchains with the same UTXO set. That is, Drivechains are available for both BitcoinCore (BTC) and BitcoinCash (BCH).
How Drivechains work
Namecoin was the vision of early Bitcoin adopters of creating a DNS and identity infrastructure based on Bitcoin; that is, .bit DNS. This technology piggy backed on top of Bitcoin mining. That is, if you so chose you could merged-mined Namecoin alongside BTC or BCH. Namecoin can absorb hashrate from BTC or BCH without needing its own miners.
Merge-mining with BTC or BCH is also the process of validating and safeguarding Drivechain sidechains. Unlike Namecoin, Drivechain sidechains don’t require miners to run special software. For Drivechain sidechains miners implement what is known as blind-merge-mining. In blind-merge-mining the nodes of the sidechain run the software, not the miners. This operates under the assumption that the nodes running the software also hold BTC or BCH.
A payment fee is paid to miners to blind-merge-mine the sidechain, in a similar way that Namecoin merge-mining pays a fee. In this process, miners don’t have to run any software- they just passively make money for blind-merge-mining blocks with sidechains.
The main difference with sidechains is that you are not mining another coin like Namecoin, but rather you are mining the same BTC or BCH in another sidechain when you do the blind-merge-mining. Miners don’t get paid with the sidechain, they receive payment from the mainchain that they already trust when they blind-merge-mine. Miners are also economically benefited by always getting paid in the superior coin that they are already intentionally mining; BTC or BCH.
As BTC or BCH moves in and out from the mainchain to a sidechain, there might be claims of ownership that may cause disputes. Drivechain prevents this by emphasizing the superiority of the mainchain over sidechains. Sidechains have to report on exactly what it is doing- at all times- to the main chain. Whenever a sidechain wants to transfer money back to the mainchain it has to do it very slowly. This safeguards the network from theft. The slow movement of funds from the sidechain to the mainchain can be arbitrage by individuals who will be willing to purchase sidechain receipts for BTC or BCH coming from sidechains at a discount. People will also be able to do atomic swaps between chains in the near future. (Atomic swaps, or atomic cross chain trading, is the exchange of one cryptocurrency to another cryptocurrency, without the need of trusting a third-party).
It is the intent of Drivechains to create the interaction of miners with sidechains as seamless as possible. However, it is still important to have guarantee that money ends up in the right place. This is the reason for the slow movement of funds from sidechains to the mainchain.
The movement of a certain amount of transactions coming from a sidechain to the mainchain is batched up into one transaction with its own transaction ID. This transaction is frozen in place where miners and developers can examine it for at least a month (there are talks of even making this process longer between 3 to 6 months). During this time miners vote on whether to allow the payment to go through or not. Upon receiving enough upvotes, the batched up transactions are released unto the mainchain. The slowing down of movement of BTC or BCH from sidechains to mainchain decreases the threat of miners stealing BTC or BCH from a sidechain.
The sidechains are always watching the mainchain, so they know to credit people immediately when the mainchain sends money to it. Sidechains also know when the miners have accepted the release of batched up locked funds that are released unto the mainchain. Once the sidechain receives notification of the miners acceptance of funds in the mainchain, the sidechain destroys the funds that were frozen awaiting miner upvotes.
It is overall acknowledged that sidechains increase the value of BTC and BCH, which eventually make mining more profitable. It would be counterproductive for miners to attack and steal funds from sidechains. That is, miners acting maliciously decreases the value of their own equipment. In spite of this fact, it is good that Drivechains make it increasingly more difficult for theft to occur.
Miners, through their voting process, also get to punish bad sidechain actors. Any malicious sidechain will be cleaned out by miners. This is the opposite of the Ethereum model where anyone can code anything into the Ethereum blockchain, to the point that it could become a detriment to the Ethereum mainchain itself. That is, anyone can create a new ERC20 or ERC721 token without any vetting from the network.
Coins are moved from the mainchain to the sidechain by means of sending coins to an address that represents the sending of funds from the mainchain to the sidechain. Anyone running the given sidechain software will recognize that funds were sent to the sidechain- this will automatically credit the person with the same amount of BTC or BCH on the sidechain. Also, the sidechain is programmed to recognize the reception of funds unto the mainchain address from where it will automatically credit the user the same amount of BTC or BCH unto a sidechain wallet. People on the mainchain don’t have to know anything about this particular address. As far as they know, it is just another address.
Embrace the Spontaneous Order of Market Anarchy It is important that people within BTC and BCH take on a more Hayekian approach to entrepreneurship. Many within crypto are uncomfortable with the mere notion of spontaneous order. It is important that we as Ancaps lead the way in motivating people to experiment with their entrepreneurship.
In the past few years, the desire of individuals to covet the development of crypto has become more apparent. These people need to be ignored. No one is the leader of Bitcoin or crypto development. The best innovators within crypto are those that create tools that empower other entrepreneurs to create more options.
It is this spontaneous order that we should welcome and promote at all times. Many within BTC and BCH will not accept or feel comfortable with the radical spontaneous order enabled by Drivechains. This is good reasonto brush up on your Austrian Economics in order to properly confront minds that are fearful of human freedom.
The Ancap entrepreneurs who are most comfortable with spontaneous order will be the same ones who will produce the greatest amount of value. The development of CryptoAnarchy is guided by the science of praxeology and Austrian Economics. Drivechains are testament to the augmentation of our libertarian order are necessary for CryptoAnarchy to thrive.
Drivechains and Investment Strategy
The philosophical and economic advantage of sidechain innovation is that it enables the development of BTC and BCH with an investor-centric intention. It is the market’s investment that now decides the best means for scaling and development. Politics and propaganda take an almost insignificant backseat to that of market forces. The technology is now readily available for investors to test drive with their BTC or BCH on any given proposed sidechain. That is, you actually get to experience the value, or lack of value of a new innovation without jeopardizing your position as an investor.
All investment decisions are about strategy. Sidechains empower the investor’s strategy by allowing the investor to survey all of the possible value propositions of his/her original investment without having to incur any actual costs. In a similar way, sidechains also provide developers with quick market feedback on the aspects of development that are most favored by the market.
Drivechains are a pivotal step in maturing the crypto space into becoming more conscientious in considering the investment strategy of those buying the coins. It is important for innovators to start taking the investor’s strategy into account. Drivechains force developers to consider what is best for the investor, not just what is desired by a given team of developers.
Here we have not only a better proposition for investors, but also an incentive for developers to use Drivechains in future crypto experimentation. When experimenting with an altcoin, the measure of success is contingent on this new altcoin gathering a new pool of investors to literally buy into the project. With a sidechain you are already dealing with a more seasoned group of investors that will provide you with more accurate market feedback, being that their investment is now fortified by all other sidechain experimentations that they have already tested at no cost.
Altcoins will soon no longer be the locus of innovation within crypto. All future innovation will be offered the option to experiment within BTC or BCH via sidechains. Keep in mind that all previous innovations, already tested in the market by successful altcoins, are now easily adopted by BTC or BCH. It is also important to note that creative experimentation on sidechains do not at all jeopardize the mainnets of BTC or BCH. On the contrary, sidechains will make BTC and BCH much more valuable. When the Drivechain craze begins we will see a BTC and BCH bull run. Don’t be surprised if sidechains are the main reason for the next all time highs.
Statists Failing & Anarchists Thriving
It is important that we understand that the legacy banking system is completely dead. They are barely adopting simulations of cryptocurrencies unto their banking structures to stay alive. Stablecoins are a manifestation of this bankster angst to remain current.
True market innovation is found in the embrace of Market Anarchy. CryptoAnarchy is growing exponentially with tools that are beyond the reach of state megalomaniacs. Drivechains are an example of the CryptoAnarchist tools that will result in further anti-fragility of this new crypto free-market.
Proper Austrian Economic incentive structures coupled with applied cryptography is our lethal weapon against nation states and central banks. Arguably, our Ancap philosophy is what guides applied cryptography in the market towards success. For this reason it is important that we keep revisiting the texts of Rothbard, Mises, Hayek, and Konkin throughout our crypto endeavors. Peace!
by Rafael LaVerde
Source
TL;DR: How familiar are you with thermodynamics and silent weapons for secret wars? How familiar are you with the Brave New World Order?
submitted by 2012ronpaul2012 to conspiracy [link] [comments]

Bi-Weekly Rational Feed

===Highly Recommended Articles:
Superintelligence Risk Project Update II by Jeff Kaufman - Jeff's thoughts and the sources he found most useful. Project is wrapping up in a few day. Topics: Technical Distance to AI. Most plausible scenarios of Superintelligence risk. OpenPhil's notes on how progress was potentially stalled in Cryonics and Nanotech.
Superintelligence Risk Project Update by Jeff Kaufman - Links to the three most informative readings on AI risk. Details on the large number of people Jeff has talked to. Three fundamental points of view on AI-Safety. Three Fundamental points of disagreement. An update on the original questions Jeff was trying to answer.
Podcast The World Needs Ai Researchers Heres How To Become One by 80,000 Hours - "OpenAI’s latest plans and research progress. Concrete Papers in AI Safety, which outlines five specific ways machine learning algorithms can act in dangerous ways their designers don’t intend - something OpenAI has to work to avoid. How listeners can best go about pursuing a career in machine learning and AI development themselves."
Radical Book Club The Decentralized Left by davidzhines (Status 451) - The nature of leftwing organizing and what righties can learn from it. An exposition of multiple books on radical left organization building. Major themes are "doing the work" and "decentralized leadership".
Study Of The Week To Remediate Or Not To Remediate by Freddie deBoer - Should low math proficiency students take remedial algebra or credit bearing statistics. The City University of New York ran an actual randomized study to test this. The study had pretty good controls. For example students were randomly assigned to three groups, participating professors taught one section of each group.
Kenneth Arrow On The Welfare Economics Of Medical Care A Critical Assessment by Artir (Nintil) - "Kenneth Arrow wrote a paper in 1963, Uncertainty and the Welfare Economics of Medical Care. This paper tends to appear in debates regarding whether healthcare can be left to the market (like bread), or if it should feature heavy state involvement. Here I explain what the paper says, and to what extent it is true."
Becoming Stronger Together by b4yes (lesswrong) - "About a year ago, a secret rationalist group was founded. This is a report of what the group did during that year."
The Destruction Of American Cuisine by Small Truths - America used to have a tremendous number of regional cuisines, most are dead. They were killed by supermarkets and frozen food. This has been costly both in terms of culture and health (antibiotic resistance, crop monoculture risk)
===Scott:
Targeting Meritocracy by Scott Alexander - Education and merit are different. Programming is one of the last meritocracies, this lets disadvantaged people get into the field. If a job is high impact we want to hire on merit. The original, literal meaning of meritocracy is important.
Classified Thread 2 Best In Classified by Scott Alexander - Scott is promoting a project to accelerate the trend of rationalists living near each other. There are four houses available for rent near Ward Street in Berkeley. Ward street is currently the rationalist hub in the Bay. Commenters can advertise other projects and services.
Url Of Sandwich by Scott Alexander - Standard links post, somewhat longer than usual.
Opec Thread by Scott Alexander - Bi-weekly open thread. Update on Scott and Katja's travels. Salt Lake City Meetup highlight. Topher Brennan is running for Senate.
Can We Link Perception And Cognition by Scott Alexander - SSC survey optical illusions. "So there seems to be a picture where high rates of perceptual ambiguity are linked to being weirder and (sometimes, in a very weak statistical way) lower-functioning." Speculation about fundamental connections between perception and cognitive style. Ideas for further research.
Change Minds Or Drive Turnout by Scott Alexander - Extreme candidates lower turnout among their own party. Is base turnout really the only thing that matters? Lots of quotes from studies.
===Rationalist:
Learning From Past Experiences by mindlevelup - "This is about finding ways to quickly learn from past experiences to inform future actions. We briefly touch upon different learning models." Model-based and Model-Free reinforcement learning. Practical advice and examples.
How Long Has Civilization Been Going by Elo (BearLamp) - Human agricultural society is only 342-1000 generations old. "Or when you are 24 years old you have lived one day for every year humans have had written records." Human civilization is only a few hundred lifetimes old.
Choices Are Bad by Zvi Moshowitz - Choices reduce perceived value. Choices require time and energy. Making someone choose is imposing a real cost.
Erisology Of Self And Will: The Gulf by Everything Studies - "Part 4 will discuss some scientific disciplines with bearing on the self, and how their results are interpreted differently by the traditional paradigm vs. the scientific."
Philosophy Vs Duck Tests by Robin Hanson - Focusing on deep structure vs adding up weak cues. If it looks like an x... More discussion of whether most people will consider ems people and/or conscious.
Knowing How To Define by AellaGirl - "These are three ways in which a word can be ‘defined’ – the role it plays in the world around it (the up-definition), synonyms (lateral-definition), and the parts which construct the thing (down-definition)." Applications to morality and free-will.
Change Is Bad by Zvi Moshowitz - "Change space, like mind space, is deep and wide. Friendly change space isn’t quite to change space what friendly mind space is to mind space, but before you apply any filters of common sense, it’s remarkably close." A long list of conditions that mean change has lower expected value. Why we still need to make changes. Keep your eyes open.
Meditation Insights Suffering And Pleasure Are Intrinsically Bound Together by Kaj Sotala - The concrete goal of meditation is to train your peripheral awareness. Much suffering comes from false promises of pleasure. Procrastinating to play a videogame won't actually make you feel better. Temptation losses its power once you truly see the temptations for what they truly are.
Be My Neighbor by Katja Grace - Katja lives in a rationalist house on ward street in Berkeley and its great. The next step up is a rationalist neighborhood. Katja is promoting the same four houses as Scott. Be her neighbor?
What Value Subagents by G Gordan (Map and Territory) - Splitting the mind into subagents is a common rationalist model (links to Alicorn, Briene Yudkowsky, etc). However the author preferred model is a single process with inconsistent preferences. Freud. System 1 and System 2. The rider and the Elephant become one. Subagents as masks. Subagents as epicycles.
The Order Of The Soul by Ben Hoffman (Compass Rose) - The philosophy of accepting things vs the impulse to reshape them. Many philosophical and psychological models split the soul into three. Internalized authority vs seeing the deep structure of moral reality. In some sense math is the easiest thing in the world to learn. School poisons the enjoyment of rational thought. Lockhart's lament. Feynman. Eichmann and thinking structurally.
Aliens Merely Sleeping by Tyler Cowen - The universe is currently too hot for artificial life to be productive. Advanced civilizations might be freezing themselves until the universe cools. "They could achieve up to 1030 times more than if done today" [short]
Book Reviews by Torello (lesswrong) - Rationalist Adjacent. Each book has an interesting 'ideas per page' rating. Homo Deus, Sapiens, Super-intelligence, Surfaces and Essences, What Technology Wants, Inside Jokes, A Skeptic's Guide to the Mind.
Geometers Scribes Structure Intelligence by Ben Hoffman (Compass Rose) - "How does spatial reasoning lead to formal, logical reasoning?" Fluid and crystalized intelligence. Some history of Philosophy. How social dynamics lead to the evolution of reasoning. Talmudic and Western law, and their oddities. Universal Grammar and connecting with the divine. FizzBuzz.
High Dimensional Societies by Robin Hanson - In high dimensional space the distance between points varies less. What implications does this have for 'spatial' social science models (ex analogues of 1D spectrums and 2D graphs).
Feelings In The Map by Elo (BearLamp) - Confusion is not a property of the external world. The same holds for many emotions. Non-violent communication and speaking from your own perspective.
Lesswrong Is Not About Forum Software by enye-word (lesswrong) - The best way to increase activity on lesswrong is to get back the top posters, especially Scott and Eliezer.
Explication by mindlevelup - "This essay is about explication, the notion of making things specific. I give some examples involving Next Actions and systematization. This might also just be obvious to many people. Part of it is also a rehash of Act Into Uncertainty. Ultimately, explication is about changing yourself."
Concrete Instructions by Elo (BearLamp) - "The objective test of whether the description is concrete is whether the description can be followed by an anonymous person to produce the same experience." Some examples including the 'paper folding game'.
Human Seems Low Dimensional by Robin Hanson - 'Humanness' seems to be a one dimensional variable. Hence people are likely to consider ems conscious and worthy of decent treatment since ems are human-like on many important factors. Some discussion of a study where people rated how human-like various entities were.
Erisology Of Self And Will: A Natural Offering by Everything Studies - A description of naturalism and it relation to science. Daniel Dennet. Many philosophers are still dualists about the self. The self as a composite. Freedom as emergent.
The Hungry Brain by Bayesian Investor - A short review that focuses on the basics of Guynet's ideas and meta-discussion of why Guynet included so much neuroscience. "Guyenet provides fairly convincing evidence that it’s simple to achieve a healthy weight while feeling full. (E.g. the 20 potatoes a day diet)."
Boost From The Best by Robin Hanson - [Age of Em] How many standard deviations above the mean will be the best em be? How much better will they be than the second best em? How much of a wage/leisure premium will the best em receive.
Becoming Stronger Together by b4yes (lesswrong) - "About a year ago, a secret rationalist group was founded. This is a report of what the group did during that year."
In Praise Of Fake Frameworks by Valentine (lesswrong) - "I use a lot of fake frameworks — that is, ways of seeing the world that are probably or obviously wrong in some important way. I think this is an important skill. There are obvious pitfalls, but I think the advantages are more than worth it. In fact, I think the "pitfalls" can even sometimes be epistemically useful."
Letter To Future Layperson by Sailor Vulcan (BYS) - A letter from someone in our age to someone post singularity. Description of the hardships and terrors of pre-singularity life. Emotional and poetic. ~5K words.
===AI:
Conversation With An Ai Researcher by Jeff Kaufman - The anonymous researcher thinks AI progress is almost entirely driven by hardware and data. Back propagation has existed for a long time. Go would have taken at least 10 more years if go-aI work had remained constrained by academic budgets.
Openai Baselines PPO by Open Ai - "We’re releasing a new class of reinforcement learning algorithms, Proximal Policy Optimization (PPO), which perform comparably or better than state-of-the-art approaches while being much simpler to implement and tune. PPO has become the default reinforcement learning algorithm at OpenAI because of its ease of use and good performance."
Superintelligence Risk Project Update II by Jeff Kaufman - Jeff's thoughts and the sources he found most useful. Project is wrapping up in a few day. Topics: Technical Distance to AI. Most plausible scenarios of Superintelligence risk. OpenPhil's notes on how progress was potentially stalled in Cryonics and Nanotech.
Real Debate Robots Education by Tyler Cowen - Robots are already becoming part of the classroom. K-12 is an artificially creation anyway. Robots can help autistic or disabled children. Children sometimes trust robots too much.
Robust Adversarial Inputs by Open Ai - "We’ve created images that reliably fool neural network classifiers when viewed from varied scales and perspectives. This challenges a claim from last week that self-driving cars would be hard to trick maliciously since they capture images from multiple scales, angles, perspectives, and the like."
What Is Overfitting Exactly by Andrew Gelman - "If your model is correct, “overfitting” is impossible. In its usual form, “overfitting” comes from using too weak of a prior distribution."
Conversation With Bryce Wiedenbeck by Jeff Kaufman - "AGI is possible, it could be a serious problem, but we can't productively work on it now." AGI will look very different from current technologies. Utility functions are a poor model of human behavior.
Examples Of Superintelligence Risk by Jeff Kaufman - A series of extended quotes describing ways AI with innocent seeming goals can destroy the world. Authors: Nick Bostrom, Eliezer (and collaborators), Luke M, 80K hours, Tim Urban. Jeff finds them unpersuasive and asks for better ones. Lots of interesting comments. Eleizer himself comments describing how 'paperclip maximizers' might realistically occur.
Superintelligence Risk Project Update by Jeff Kaufman - Links to the three most informative readings on AI risk. Details on the large number of people Jeff has talked to. Three fundamental points of view on AI-Safety. Three Fundamental points of disagreement. An update on the original questions Jeff was trying to answer.
Conversation With Michael Littman by Jeff Kaufman - CS Professor at Brown's opinions: Deep Learning is surprisingly brittle in his experience. General Intelligence will require large fundamental advances. The AI risk community isn't testing their ideas so they probably aren't making real progress.
===EA:
EAGX Relaunch by Roxanne_Heston (EA forum) - The EA global satellite EAGA-X conferences have been low activity. Changes: More funding and flexibility. Standardized formats. Fewer groups approved. Stipends to primary organizers.
Uncertainty Smoothes Out Differences In Impact by The Foundational Research Institute - Many inside view evaluations conclude that one intervention is orders of magnitude more effective than another. Uncertainty significantly reduces these ratios.
Autonomy: A Search For A Measure Will Pearson (EA forum) - "I shall introduce a relatively formal measure of autonomy, based on the intuition that it is the ability to do things by yourself with what you have. The measure introduced allows you to move from less to more autonomy, without being black and white about it. Then I shall talk about how increasing autonomy fits in with the values of movements such as poverty reduction, ai risk reduction and the reduction of suffering."
Eight media articles on GiveDirectly, Cash Transers and Basic Income.- A world where 8 men own as much wealth as 3.6 billion people by GiveDirectly -
More Giving Vs Doing by Jeff Kaufman - EA is moving far more money than it used to and the ramp up will continue. This means direct work has become relatively more valuable. Nonetheless giving money is still useful, capacity isn't being filled. Jeff plans on earning to give based on his personal constraints.
Why I Think The Foundational Research Institute by Mike Johnson (EA forum) - A description of the FRI. Good things about FRI. FRI's research framework and why the author is worried. Eight long objections. TLDR: "functionalism ("consciousness is the sum-total of the functional properties of our brains") sounds a lot better than it actually turns out to be in practice. In particular, functionalism makes it impossible to define ethics & suffering in a way that can mediate disagreements."
Tranquilism by The Foundational Research Institute - A paper arguing that reducing suffering is more important than promoting happiness. Axiology. Non-consciousness. Common Objections. Conclusion.
An Argument For Why The Future May Be Good by Ben West (EA forum) - Factory farming shows that humans are deeply cruel. Technology enabled this cruelty, perhaps the future will be even darker. Counterargument: Humans are lazy, not evil. Humans as a group will spend at least small amounts altruistically. In the future the cost of reducing suffering will go down low enough that suffering will be rare or non-existent.
Arguments Moral Advocacy by The Foundational Research Institute - "What does moral advocacy look like in practice? Which values should we spread, and how? How effective is moral advocacy compared to other interventions such as directly influencing new technologies? What are the most important arguments for and against focusing on moral advocacy?"
An Argument For Broad And Inclusive by Kaj Sotala (EA forum) - "I argue for a very broad, inclusive EA, based on the premise that the culture of a region is more important than any specific group within that region... As a concrete strategy, I propose a division into low-level and high-level EA"
Not Everybody wants a Goat by GiveDirectly - Eight links on GiveDirectly, Cash Transfers, Effective Altruism and Basic Income.
Mid Year Update by The GiveWell Blog - Encouraging more charities to apply. More research of potential interventions. Short operations recap. GiveWell is focusing more on outreach.
===Politics and Economics:
College Tuition by Tom Bartleby - Sticker prices for college have gone up 15K in twenty years, but the average actual cost has only gone up 2.5K. High prices are almost compensated by high aid. Advantage: more equitable access to education. Disadvantages: Not everyone knows about the aid, financial aid is large enough it can seriously distort family financial decisions.
War Of Wages Part 1 Apples And Walmarts by Jacob Falkovich (Put A Number On It!) - The Author thinks minimum wage hurts the poor. Walmart can't afford higher wages. Copenhagan Interpretation of Ethics: Walmart helps the poor and gets blamed, Apple does nothing for the poor but avoids blame.
Links 10 by Artir (Nintil) - Tons of links. Economics, Psychology, AI, Philosophy, Misc.
Pretend Ask Answer by Ben Hoffman (Compass Rose) - A short dialogue about Patriarchy and the meaning of oppression. Defensive actions are often a response to bad faith from the other side. Its not ok to explicitly say you think your partner is arguing in bad faith.
Cultural Studies Ironically Is Something Of A Colonizer by Freddie deBoer - An origin story for Writing Studies. The fields initial methodological diversity. Cultural studies took over the field, empirical work has been pushed out. Evidence that some cultural studies professors really do believe its fundamentally bigoted to do science and empirical research endangers marginalized students. The field has become insular.
The Dark Arts Examples From The Harris Adams Debate by Stabilizer (lesswrong) - The author accuses Scott Adams of using various dark Arts: Changing the subject, Motte-and-bailey, Euphemisation, Diagnosis, Excusing, Cherry-picking evidence.
Study Of The Week Modest But Real Benefits From Lead Exposure Interventions by Freddie deBoer - Freddie reviews a survey he found via SSC. The study had very good controls. Methodology is explained and key graphs are posted and discussed. Scott and Freddie seem to agree on the facts but have a different opinion on how large to consider the effects.
Descriptive And Prescriptive Standards by Simon Penner (Status 451) - Leadership means winning the Keynesian Beauty Contest. Public opinion doesn't exist as a stable reality. Prescribing public opinion. Dangers of social reform and leaders twisting the facts to promote noble outcomes.
A Taylorism For All Seasons by Lou (sam[]zdat) - "Christopher Lasch – The Culture of Narcissism, part 1/X, current essay being more of an overview." A Masquerade where you must act out the mask you choose.
Mechanism Agnostic Low Plasticity Educational Realism by Freddie deBoer - Freddie's educational philosophy. People sort into persistent academic strata. Educational attainment is heavily determined by factors outside of school's control. The mechanism differences in academic ability is unknown. Social and political implications.
Kin Aesthetics Excommunicate Me From The Church Of Social Justice by Frances Lee - A SJ-insider's critical opinion of SJ. Fear of being impure. Original Sin. Reproducing colonial structures of power and domination within social justice. Everyday Feminism's belittling articles. More humility. Bringing humanity to everyone, even those who have been inhumane.
Study Of The Week To Remediate Or Not To Remediate by Freddie deBoer - Should low math proficiency students take remedial algebra or credit bearing statistics. The City University of New York ran an actual randomized study to test this. The study had pretty good controls. For example students were randomly assigned to three groups, participating professors taught one section of each group.
Should We Build Lots More Housing In San Francisco: Three Reasons People Disagree by Julia Galef - For each of the three reasons Julia describes multiple sub-reasons. More housing might not lower prices much. More housing won't help the poor. NIMBY objections might be legitimate.
Kenneth Arrow On The Welfare Economics Of Medical Care A Critical Assessment by Artir (Nintil) - "Kenneth Arrow wrote a paper in 1963, Uncertainty and the Welfare Economics of Medical Care. This paper tends to appear in debates regarding whether healthcare can be left to the market (like bread), or if it should feature heavy state involvement. Here I explain what the paper says, and to what extent it is true."
Thoughts On Doxxing by Ozy (Thing of Things) - CNN found the identity of the guy who made the video of Trump beating up CNN. They implied they would dox him if he continued being racist. Is doxxing him ok? What about doxxing someone who runs jailbait? Ozy discusses the practical effect of doxxing and unleashing hate mobs.
On The Seattle Minimum Wage Study Part 2 by Zvi Moshowitz - Several relevant links are included. Seattle's economic boom and worker composition changes are important factors. Zvi dives deep into the numbers and tries to resolve an apparent contradiction.
Radical Book Club The Decentralized Left by davidzhines (Status 451) - The nature of leftwing organizing and what righties can learn from it. An exposition of multiple books on radical left organization building. Major themes are "doing the work" and "decentralized leadership".
On The Seattle Minimum Wage Study Part 1 by Zvi Moshowitz - The claimed effect sizes are huge. Zvi's priors about the minimum wage. Detailed description of some of the paper's methods and how it handle potential issues. Discussion of the raw data. More to come in part 2.
===Misc:
Childcare II by Jeff Kaufman - A timeline of childcare for Jeff's two children. Methods: Staying at home, Daycare, Au pair, Nanny.
Easier Chess Problem by protokol2020 - How many pieces do you need to capture a black queen?
Book Review Mathematics For Computer Science by richard_reitz (lesswrong) - Why the text should be in the MIRI research guide. Intro. Prereqs. Detailed comparisons to similar texts. Complaints.
Information is Physical by Scott Aaronson - Is information is physical a contentful expression? Why 'physics is information' is tautological. A proposed definition. Double slit experiment. Observation in Quantum Mechanics. Information takes up a minimum amount of space. Entropy. Information has nowhere to go.
Book Review Working Effectively With Legacy Code By Michael C Feathers by Eli Bendersky - To improve code we must refactor, to refactor we have to test, making code testable may take heroic efforts. "The techniques described by the author are as terrible as the code they're up against."
The Ominouslier Roar Of The Bitcoin Wave by Artem and Venkat (ribbonfarm) - A video visualizing and audiolizing the bitcoin blockchain. A related dialogue.
From Monkey Neurons To The Meta Brain by Hal Morris (ribbonfarm) - Neurons that only fire in response to Jennifer Anniston. Mirror Neurons. Theory of Mind. The path from copying movement to human-level empathy. Infant development. Dreams as social simulator. Communicating with our models of other people. He rapidly accelerating and dangerous future. We need to keep our mind open to possibilities.
Newtonism Question by protokol2020 - Balancing Forces. Gravity problem.
Short Interview Writing by Tyler Cowen - Tyler Cowen's writing habits. Many concrete details such as when he writes and what program he uses. Some more general thoughts on writing such as Tyler's surprising answer to which are his favorite books on writing.
Unexpected by protokol2020 - Discussion of gaps between primes. "Say, that you have just sailed across some recordly wide composite lake and you are on a prime island again. What can you expect, how much wider will the next record lake be?"
Interacting With A Long Running Child Process In Python by Eli Bendersky - Using the subprocess module to run an http server. Solutions and analysis of common use cases. Lots of code.
4d Mate Problem by protokol2020 - How many queens do you need to get a checkmate in 4D chess.
The Destruction Of American Cuisine by Small Truths - America used to have a tremendous number of regional cuisines, most are dead. They were killed by supermarkets and frozen food. This has been costly both in terms of culture and health (antibiotic resistance, crop monoculture risk)
===Podcast:
Sally Satel On Organ Donation by EconTalk - "The challenges of increasing the supply of donated organs for transplantation and ways that public policy might increase the supply." Tax Credits. The ethics of donor compensation.
Podcast The World Needs Ai Researchers Heres How To Become One by 80,000 Hours - "OpenAI’s latest plans and research progress. Concrete Papers in AI Safety, which outlines five specific ways machine learning algorithms can act in dangerous ways their designers don’t intend – something OpenAI has to work to avoid. How listeners can best go about pursuing a career in machine learning and AI development themselves."
88 Must We Accept A Nuclear North Korea by Waking Up with Sam Harris - "Mark Bowden and the problem of a nuclear-armed North Korea."
Triggered by Waking Up with Sam Harris - "Sam Harris and Scott Adams debate the character and competence of President Trump."
Conversation Atul Gawande by Tyler Cowen - The marginal value of health care, AI progress in medicine, fear of genetic engineering, whether the checklist method applies to marriage, FDA regulation, surgical regulation, Michael Crichton and Stevie Wonder, wearables, what makes him weep, Knausgaard and Ferrante, why surgeons leave sponges in patients.
Nneka Jones Tapia by The Ezra Klein Show - The first psychologist to run a prison. 30% of inmates have diagnosed mental health problems. Mental heath view of the penal system, balancing punishment and treatment, responsibility versus mental instability, the tension between what we use jail for and what we should use jail for.
Tamar Haspel by EconTalk - "Why technology helps make some foods inexpensive, how animals are treated, the health of the honey bee, and whether eggs from your backyard taste any better than eggs at the grocery."
From Cells To Cities by Waking Up with Sam Harris - "Biological and social systems scale, the significance of fractals, the prospects of radically extending human life, the concept of “emergence” in complex systems, the importance of cities, the necessity for continuous innovation"
Inside The World Of Supertraining: Mark Bell by Tim Feriss - "Mark’s most important lessons for building strength. How to avoid injury and breakdown. Lesser-known training techniques that nearly everyone overlooks. How Mark became a millionaire by offering his gym memberships for free."
Eddie Izzard by The Ezra Klein Show - 27 marathons in 27 days, process for writing jokes, why he wants to run for parliament, inspiration from Al Franken's, borrowing confidence from his future self. What he learned as a street performer, routines are based on history and anthropology, World War I, 'cake or death?'. His gender identity, and how he integrated it into his act early on, etc.
Martha Nussbaum by EconTalk - "The tension between acquiring power and living a life of virtue. Topics discussed include Hamilton's relationship with Aaron Burr, Burr's complicated historical legacy, and the role of the humanities in our lives."
Rs 188 Robert Kurzban On Being Strategically Wrong by Rationally Speaking - Why Everyone (Else) is a Hypocrite." The "modular mind" hypothesis, and how it explains hypocrisy, self-deception, and other seemingly irrational features of human nature.
submitted by deluks917_ to slatestarcodex [link] [comments]

JoinMarket, une implémentation de Coinjoin Bitcoin script IDE — Princeton Bitcoin seminar final project BITCOIN BATTLE Workshop : Liquid, une sidechain de Bitcoin Constructing a Bitcoin transaction using python - 3/5

This flaw allowed anyone to change small details that modified the transaction id (and the subsequent hash) but not the content. While not a critical problem for bitcoin, it prevented the ... Bitcoin technology keeps on maturing rapidly since its launch and hence there is a drastic variation of their implementation details making the study of blockchains vast, complex, and dynamic. Since the genesis, blockchains have become more mature to work smarter and faster. It is being perfected and refined more and more as it expands. Some blockchains like Ethereum also support smart ... For example, suggest “bike” as a synonym for bicycle, or “sock” for socks. The following tags will be remapped to implementation. implementation-details. see all tag synonyms » Users with more than 2500 reputation and a total answer score of 5 or more on the tag, can suggest tag synonyms. Users with a total answer score (total upvotes minus total downvotes) of 5 or more on the tag ... Bitcoin: A Peer-to-Peer Electronic Cash System Satoshi Nakamoto [email protected] www.bitcoin.org Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still ... Bitcoin Cash Address. Die Verwaltung erhebt Daten aus ihrer administrativen Tätigkeit (etwa Dienstreisen). (Ein anderes Wort für Unternehmen).Wenn Führungskräften der Mut fehlt, Macht abzugeben, wenn Unternehmen sich digital option rebate weiterhin das unternehmen definition abhängig von KPIs machen, bleibt agil nur Does Paypal Accept Bitcoin

[index] [26741] [29759] [30713] [12669] [33823] [8021] [4981] [1939] [35298] [16970]

JoinMarket, une implémentation de Coinjoin

In this webinar, Jens Klatt — a professional trader – discusses recent developments in Bitcoin and if the cryptocurrency can go even higher. He introduces so... Fonctionnant depuis 2018, Liquid est une sidechain de Bitcoin reposant sur une fédération de validateurs. Liquid est basé sur Elements, une implémentation générique de Bitcoin développée ... Complete detail of how Bitcoin works - Duration: 45:35. davincij15 Recommended for you. 45:35. LIVESTREAM - Living a Life of Divine Worship - Fr. Michael O'Connor, O.P. The Thomistic Institute 140 ... In this video I go over websocket and how to implement a bitcoin websocket in your website to display new transactions in real-time using javascript and jquery . My Bitcoin Web Dev Book: https ... This video is for people who want to use (almost) raw python code to Constructing a Bitcoin transaction. In the previous videos, I've explained how to connect to the bitcoin network, as well as ...

#