Does an OP_RETURN script always need another output within the transaction?


OP_RETURN is a script opcode used to mark a transaction output as invalid. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to burn bitcoins.

Is storing data in the blockchain acceptable?

Many members of the Bitcoin community believe that use of OP_RETURN is irresponsible in part because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Additionally, it is trivially obvious that the demand for external, massively-replicated data store is essentially infinite. Despite this, OP_RETURN has the advantage of not creating bogus UTXO entries, compared to some other ways of storing data in the blockchain.

From Bitcoin Core release 0.9.0:

This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as...

0 0

The framework has no way of knowing if you started a transaction. You can even use $db->query('START TRANSACTION') which the framework would not know about because it doesn't parse SQL statements you execute.

The point is that it's an application responsibility to track whether you've started a transaction or not. It's not something the framework can do.

I know some frameworks try to do it, and do cockamamie things like count how many times you've begun a transaction, only resolving it when you've done commit or rollback a matching number of times. But this is totally bogus because none of your functions can know if commit or rollback will actually do it, or if they're in another layer of nesting.

(Can you tell I've had this discussion a few times? :-)

edit: Propel is a PHP database access library that supports the concept of the "inner transaction" that doesn't commit when you tell it to. Beginning a transaction only increments a counter, and...

0 0

The Bitcoin network bundles transactions together into a distributed database known as the block chain. When viewed from within the network, transactions simply represent electronic cash payments. Outside the Bitcoin network, more complex interpretations are possible. Adding application-specific data to transactions opens the door to using Bitcoin not just for electronic cash payments, but new kinds of financial, property, and legal transactions. Questions around how - and even whether - to support these uses have been hotly debated for years.

The 0.9.0 release of Bitcoin Core took the first step toward settling the debate through the standardization of a new transaction type. This article reviews the problem of extending the block chain, and the importance of a solution.

One Man's Trash

Back in 2010, an ambitious proposal for building a decentralized domain name service on top of Bitcoin appeared on the bitcointalk forum. The proposal consisted...

0 0

Last week on the train back to my parents’ place for Christmas I decided to follow @wmougayar’s example and read a couple of landmark Bitcoin and cryptocurrency papers. If you’re interested, William’s list is here and includes an interesting cross section of topics. Out of the list, Satoshi’s original paper Bitcoin: A Peer-to-Peer Electronic Cash System helped clarify the specifics of how Bitcoin works and why it has potential to be incredibly important. At nine pages including graphics and footnotes it’s both short and accessible so if you’re on the fence just go read it.

After reading the paper and following down the Bitcoin wiki rabbit hole I rediscovered the Script page on the Bitcoin wiki. Disregarding some cases, one of the key features of a blockchain is that new transactions must contain inputs from a previous transaction. With Bitcoin specifically, in order to use the output of a previous transaction you need to supply inputs that cause the previous output’s...

0 0

Transactions are the most important part of the bitcoin system. Everything else in bitcoin is designed to ensure that transactions can be created, propagated on the network, validated, and finally added to the global ledger of transactions (the blockchain). Transactions are data structures that encode the transfer of value between participants in the bitcoin system. Each transaction is a public entry in bitcoin’s blockchain, the global double-entry bookkeeping ledger.

In this chapter we will examine all the various forms of transactions, what they contain, how to create them, how they are verified, and how they become part of the permanent record of all transactions.

A transaction’s lifecycle starts with the transaction’s creation, also known as origination. The transaction is then signed with one or more signatures indicating the authorization to spend the funds referenced by the transaction. The transaction is then broadcast on the bitcoin network, where each...

0 0

The pull request submitted by Coinprism’s Flavien Charlon to increase the default maximum size of the OP_RETURN payload to 80 bytes has been merged into the master branch of Bitcoin last week.

The colored coins protocol Open Assets was already able to handle 40 bytes without much problems, but an increase to 80 bytes will make it even more efficient. The change to 80 bytes will also benefit other 2.0 protocols like Counterparty and Mastercoin.

What is the change about?

Bitcoin transactions are made of inputs and outputs. The inputs indicate where the money is taken from, and the outputs indicate when it’s going to. OP_RETURN is a script operator which makes it possible to have a special output that doesn’t actually send money to anyone, but lets the creator of the transaction embed some data in it.

The amount of data that can be put in such output was previously limited to 40 bytes. Open Assets, being a light protocol, was able to fit everything it...

0 0
0 0

Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide

a public key that, when hashed, yields destination address D embedded in the script, and a signature to show evidence of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.

A transaction is...

0 0

@zathras-crypto posted in #267 a OP_RETURN strategy as a sidenote and I think it's better to keep it this in a seperated thread. I'm not sure, if it's ready for prime time, but nevertheless:

This means that Class C transactions cannot currently completely replace Class B for larger transaction types such as smart property issuances ....

I know you don't like it, but what's your objection against mix-encodings? Class A is soft-depreciated, that's for sure, but it's actually not that simple to decide op_return is the new standard from now and the use of bare multisig should be discouraged. At the very moment using op_return comes with a significant confirmation delay, even though I agree: it should be used most of the time - but it's not that black and white.

Lowered Cost

A switch to op_return should only yield minimal cost savings and the most part at the very moment is based on the way to high outputs...

0 0

Here is an important aspect of blockchain technology that shouldn't be taken lightly. I'm talking far off into the future, but this is some thing that visionaries now should be prepared for...

Even if this becomes an issue after we're all dead, and future generations need to deal with it.

Blockchain pruning and reorg will eventually happen. If you plan for storage space, speed, and computers of the future to handle blockchain size (Moores Law) it is irresponsible in the early stages of designing Peercoin to hope that works out.

None of us know how many transactions will happen in the future if this becomes adopted worldwide. None of us know how large blockchains will grow.

An example:

Some one mined Peercoin early on, generated 500,000 peercoin, and even shows up in the forum and admits, yes, I was a whale, I had 500,000 peercoin, but my hard drive died, I had no backup, and those 500,000 peercoin never minted a block as a result. That 1/2 million...

0 0

A Unity Coroutine is a C# generator. Every time you call yield in a generator you are "returning" a value. That's what they are intended to do, generate values. The problem isn't about returning values from a Coroutine, because you're doing that. The problem is getting access to those values that the Unity engine absorbs.

You do it by running the generator yourself instead of letting Unity do it, and exposing the yielded value using a public property.

Create a utility class for invoking coroutines...

public class CoroutineWithData { public Coroutine coroutine { get; private set; } public object result; private IEnumerator target; public CoroutineWithData(MonoBehaviour owner, IEnumerator target) { = target; this.coroutine = owner.StartCoroutine(Run()); } private IEnumerator Run() { while(target.MoveNext()) { result = target.Current; yield return result; } } }

Put a yield at the end of your coroutine with...

0 0
0 0

When an application executes multiple operations against a database, a common requirement is that all of the operations must succeed or the database must roll back to its original state (that is, its state before the operations began). This all-or-nothing requirement is referred to as a transaction. Transactions ensure the integrity of a database system's state. For example, in a classic banking scenario, an application must debit one account and credit another with a particular amount of money. For proper accounting, it is essential that either both operations succeed or neither operation succeeds. This means that both operations should be performed in the context of a single transaction.

The typical goal in this scenario is that all updates to a database must succeed or none of them should be performed.

There are several ways to perform database methods within a transaction. The solution shown here demonstrates how to use the overload of the ExecuteNonQuery method...

0 0

Bitcoin is digital - it is entirely based on 0s and 1s. A more efficient way of showing 0 and 1s is to use hexadecimal representation. This is also known as base 16.

For example, here is a raw bitcoin transaction:


So, what can we do with a raw transaction? The above hex decodes to:

{ “addresses”: “1BvAjjRGERmQvUBprkpPeZYZQNxCbLKe4P”, “fees”: 2500, “hash”: “7f2875779f2429ee76e50857c6407e56ecc5ba7b0c9cfb102a477e50072233fa”, “inputs”: [ { “addresses”: [...
0 0

Note: I went out and learned about how the OP_RETURN opcode works at the byte level in a bitcoin transaction. I’m writing it here so that others can learn quickly. First, a brief history of why we’re even talking about OP_RETURN

Back in 2013 different players in the bitcoin ecosystem were trying to include bits of information into transactions so that they could take advantage of the irreversibility of the blockchain. Imagine for instance you wanted to write a contract and place it in an unchangeable location that at any future date one could go back to verify it existed. You can do this by using the blockchain. You add some bits to the transaction's scriptSig value that don't alter the end result of running that script, but allow you to store information like “I hereby declare to give asset A to address XYZ at time UNIX_TIMESTAMP”. There were even stranger ways people would add extra bits, like including it in the BTC value of an output. Some members of the community did...

0 0

No notes for slide

Transactions are an expression of intent to transfer value between parties.


Pic: do they do?
Movement of value across a decentralized network.
Although cryptographic solutions abound in Bitcoin, transactions are clear text.
A signed transaction is broadcasted to all nodes on the network, not just to the address receiving a payment.
Every node independently validates each transaction to prevent an invalid transaction. What are they?

Just because these are data structures and must therefore conform to well defined rules - that doesn’t say anything about knowing what those rules are. I had to search through multiple sources. As no one source held a complete record what exactly the role of each byte.

Also, never forget that one is reading HEX.

A block...
0 0

I answered the following question earlier this evening: Return an output parameter from SQL Server via a stored procedure and c#

Here is the proc in question, take a good look at it, do you see the problem?

ALTER PROCEDURE [dbo].[Insert_UnknownCustomer_Quote_Document] -- Add the parameters for the stored procedure here @NewDocumentFileName nvarchar(100), @NewDocumentWordCount int, @NewQuoteAmount money, @NewQuoteNumber int OUTPUT = 0 AS DECLARE @Today datetime SELECT @Today = GETDATE() BEGIN TRANSACTION BEGIN TRY BEGIN -- SET NOCOUNT ON added to prevent extra result sets from interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here INSERT INTO dbo.Customers(DateAdded) VALUES (@Today) INSERT INTO dbo.Quotes(CustomerID, QuoteAmount, QuoteDate) VALUES (@@IDENTITY, @NewQuoteAmount, @Today) SELECT @NewQuoteNumber = @@IDENTITY INSERT INTO dbo.DocumentFiles(QuoteNumber, DocumentFileName, DocumentFileWordCount) VALUES (@NewQuoteNumber,...
0 0

See on Github

Script is a simple scripting language, as well as the core of Bitcoin transaction processing. If you ever wrote assembly code you’ll find this article very easy to understand –probably entertaining–, otherwise it might well be one of the most challenging. Keep focused!

Meet machine code

A script is a computer program, and as a programmer you certainly know what a program is. A program takes an input, executes for some time, then returns an output. Programming languages are our tool to write programs that computers will understand, because most languages come with compilers that map human-friendly code to CPU operations, also known as opcodes.


Opcodes include memory manipulation, math, loops, function calls and everything you find in procedural programming languages like C. They make up the spoken language of a CPU, the so-called machine code. Since bytes are computers’ preferred idiom, no wonder opcodes are bytes...

0 0