Bitcoin Wiki - User contributions [en]

Transaction malleability

2015-07-26T02:46:15Z

Jayemar: Cleaned up the grammar a bit in the opening paragraph

While [[transaction]]s are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus, while uncommon, it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash; the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the later transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block (and potentially even after a confirmation if the block chain is reorganized). In addition, clients must always actively scan for transactions to them; assuming a txout exists because the client created it previously is unsafe.

== Signature Malleability ==

The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but OpenSSL does not enforce this, and as long as a signature isn't horribly malformed, it will be accepted.<ref>https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410</ref> In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message.<ref>https://bitcointalk.org/index.php?topic=8392.msg1245898#msg1245898</ref>

Efforts are underway to first make Bitcoin nodes not relay non-standard signatures, and eventually disallow them from being included in new blocks entirely.

== scriptSig Malleability ==

The [[OP_CHECKSIG|signature algorithm]] used in Bitcoin does not sign any of the scriptSig to create the signature. While signing the whole scriptSig would be impossible - the signature would be signing itself - this does mean that additional data can be added such that it will be pushed on the stack prior to the required signatures and public keys. Similarly OP_DROP can be added to leave the stack exactly as before prior to scriptPubKey execution.

Preventing scriptSig malleability is being considered as well. Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed, and eventually this rule may extend to enforcing that the stack have exactly one item after execution. However doing that may interfere with later extensions to Bitcoin.

==References==
<references/>

[[Category:Technical]]
[[Category:Developer]]

Data directory

2015-07-11T14:57:32Z

Jayemar: Made the opening statement into a complete sentence.

The data directory is the location where Bitcoin's data files are stored, including the [[Wallet|wallet]] data file.

==Default Location==
=== Windows ===

Go to Start -> Run (or press WinKey+R) and run this:

%APPDATA%\Bitcoin

Bitcoin's data folder will open. For most users, this is the following locations:

C:\Documents and Settings\YourUserName\Application data\Bitcoin (XP)

C:\Users\YourUserName\Appdata\Roaming\Bitcoin (Vista and 7)

"AppData" and "Application data" are hidden by default.

You can also store Bitcoin data files in any other drive or folder.

If you have already downloaded the data then you will have to move the data to the new folder.
If you want to store them in D:\BitcoinData then click on "Properties" of a shortcut to bitcoin-qt.exe and
add -datadir=D:\BitCoinData at the end as an example:

"C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" -datadir=d:\BitCoinData

Start Bitcoin, now you will see all the files are created in the new data directory.

=== Linux ===

By default Bitcoin will put its data here:

~/.bitcoin/

You need to do a "ls -a" to see directories that start with a dot.

If that's not it, you can do a search like this:

find / -name wallet.dat -print 2>/dev/null

=== Mac ===

By default Bitcoin will put its data here:

~/Library/Application Support/Bitcoin/

==Directory Contents==

===Files===
* .lock
**BDB lock file
* bitcoin.conf [optional]
**Contains [[Running_Bitcoin#Bitcoin.conf_Configuration_File|configuration options]].
* blk''xxxx''.dat [Versions prior to v0.8.0]
**Contains concatenated raw blocks. Stored are actual Bitcoin blocks, in network format, dumped to disk raw.
* blkindex.dat [Versions prior to v0.8.0]
**Indexing information used with blk''xxxx''.dat
* __db.''xxx''
**Used by BDB
* db.log
* debug.log
**Bitcoin's verbose log file. Automatically trimmed from time to time.
* wallet.dat
**Storage for keys, transactions, metadata, and options. <span style="color:red">Please be sure to make backups of this file. It contains the keys necessary for spending your bitcoins.</span>
* addr.dat [Versions prior to v0.7.0]
** Storage for ip addresses to make a reconnect easier
* peers.dat [Versions v0.7.0 and later]
** Storage for peer information to make a reconnect easier. This file uses a bitcoin-specific file format, unrelated to any database system<ref>[http://bitcointalk.org/index.php?topic=119525.msg1287284#msg1287284 Ultraprune merged in mainline]</ref>.
The data, index and log files are used by Oracle [http://en.wikipedia.org/wiki/Berkeley_DB Berkeley DB], the embedded key/value data store that Bitcoin uses.

===database subdirectory===
Contains BDB journaling files

===testnet3 subdirectory===
Contains testnet versions of these files (if running with -testnet)

===blocks subdirectory===
[v0.8 and above] Contains blockchain data.

* blk*.dat
** Stored are actual Bitcoin blocks, in network format, dumped to disk raw. They are only needed for re-scanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.

* blocks/index subdirectory
** [v0.8 and above] A LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.

===chainstate subdirectory===
[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (7 GB as of may 2013) for every output being spent.

===locks subdirectory===
[v0.8 and above] Contains "undo" data.

* rev*.dat
You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganizations.

===Bootstrapping the blockchain from a snapshot distributed through BitTorrent===
There is a [https://bitcoin.org/bin/block-chain/ torrent file that gets updated] every few months that enables a much faster download of the blockchain. Once downloaded, the bootstrap.dat file can be placed in the root of the data directory, and Bitcoin Core 0.7.1 and above will automatically import it. '''NOTE:''' As of Bitcoin Core version 0.10.0 and later, the blockchain bootstrap
torrent is ''slower'' than a direct download using the bitcoin P2P protocol & client.<ref>[https://bitcoin.org/bin/block-chain/README.txt README.txt for bootstrap.dat.torrent]</ref>

===Personally identifiable data [v0.8 and above]===
This section may be of use to you if you wish to send a friend the blockchain, avoiding them a hefty download.

*wallet.dat
**Contains addresses and transactions linked to them. <span style="color:red">Please be sure to make backups of this file. It contains the keys necessary for spending your bitcoins.</span> You should not transfer this file to any third party or they may be able to access your bitcoins.
*db.log
**May contain information pertaining to your wallet. It may be safely deleted.
*debug.log
**May contain IP addresses and transaction ID's. It may be safely deleted.
*database/ folder
**This should only exist when bitcoin-qt is currently running. It contains information (BDB state) relating to your wallet.
*peers.dat
**Unknown whether this contains personally identifiable data. It may be safely deleted.

Other files and folders (blocks, blocks/index, chainstate) may be safely transferred/archived as they contain information pertaining only to the public blockchain.

==See Also==

* [[Running Bitcoin]]
* [[Securing your wallet]]
* [http://bitcoin.stackexchange.com/a/11108/153 What is the database for?] Question on Bitcoin Stack Exchange

==References==
<references />

[[Category:Technical]]

[[es:Directorio de datos]]

Smart Property

2015-07-11T13:39:29Z

Jayemar: Minor grammar fix breaking a phrase into two sentences

'''Smart property''' is property whose ownership is controlled via the Bitcoin block chain, using [[Contracts|contracts]]. Examples could include physical property such as cars, phones or houses. Smart property also includes non-physical property like shares in a company or access rights to a remote computer. Making property smart allows it to be traded with radically less trust. This reduces fraud, mediation fees and allows trades to take place that otherwise would never have happened. For example, it allows strangers to loan you money over the internet taking your smart property as collateral, which should make lending more competitive and thus credit cheaper.

Smart property was first proposed by Nick Szabo in his 1997 paper, [http://szabo.best.vwh.net/idea.html "The idea of smart contracts"]. There are currently no implementations of this idea. This page was written by [mailto:mike@plan99.net Mike Hearn]. Contact him with any questions or ask on the forums.

==Background==

Primitive forms of smart property are already common - if you own a car, it probably comes with an immobilizer. Immobilizers augment the physical key with a protocol exchange ensuring only the holders of the correct cryptographic token can activate the engine. They have dramatically reduced car theft, for example, immobilisers are fitted to around 45% of all cars in Australia, but account for only 7% of the cars that are stolen.

Many other forms of modern property are protected against theft using cryptography, for example, some smartphones will refuse to release certain keys if the correct PIN unlock isn't entered, and cryptography not only renders a stolen device fairly useless but makes it impossible to steal someone's phone number as well.

Although these are victories for cryptography, the potential of cryptographically activated property has not been fully explored. The private key is usually itself held in a physical container (like a key or SIM card) and can't be easily transferred or manipulated. Smart property changes this, allowing ownership to be intermediated by Bitcoin miners.

==Theory==

This section assumes you are familiar with the Bitcoin protocol, and have a good understanding of [[contracts]].

Let's start with the example of a car. The cars computer requires authentication using an ''ownership key''. The ownership key is a regular Bitcoin ECDSA-256 key. The car starts its life at the factory gate with the public part of a newly created ownership key. A small token amount of Bitcoins are deposited on that key, call the amount T (it could be 0.0001 BTC for example). Additionally the car has a digital certificate from its manufacturer, and an ''identification key'' which has the public part in the certificate. This allows the car to prove things like its existence, age or mileage to third parties.

When the car is sold, the following protocol is used:

# The buyer generates a nonce (random number) and asks the seller to send them the car data.
# The seller gives the car that nonce, and the car returns a data structure signed with its identification key. The data contains the nonce, the cars public cert, data about the car, the public key of the current owner, and the transaction+merkle branch which transferred ownership last time. This ensures the buyer knows what they are getting and that it came from the real seller (it's not a replay).
# The seller selects a key to receive the payment, k1, and names their price P.
# The buyer generates a new ownership key, k2.
# The buyer creates a transaction with two inputs and two outputs. The first input signs for P coins. The second input is connected to the output holding T coins for the ownership address. The first output sends P coins to k1 and the second output sends T coins to k2. This transaction is not valid because only the first input can be signed. The buyer passes this partially complete transaction to the seller, who then signs the second input with the car's current ownership key and broadcasts the transaction.
# They wait for some confirmations.
# The buyer presents the car with the Bitcoin transaction, a merkle branch linking it to the block header and then enough block headers to fill in the gap from the cars current ownership transaction. The car sees that the new transaction re-assigns ownership and is further along in the chain than its current one, plus it has enough work piled on top to be sure the tx won't be reversed. It then updates its ownership information. The car does not need to keep a full record of the chain nor all headers, but rather just enough data to be able to connect future block headers to the one it was previously presented with.

In practice this process would likely be handled using smartphones with NFC hardware -- the act of touching the phone containing the ownership key to the dashboard would start your wallet app in a special mode that knows how to do smart property trades, after inputting the price the buyer and seller would then touch their phones together to finalize the deal. Although the cryptography is complex they would never need to know anything about it. The phone could double as a way to start the car as well.

==Loans and collateral==

Being able to trade physical property without fraud risk is useful, but we can add an extra layer to allow for secured low-trust loans. Consider a loan with which to start a small business. Rather than deal with a bank, you decide to allow people from around the world bid on your debt so you can get the best rates. For this to work, the strangers need some assurance that if the loan is not repaid, they get to keep the collateral - yet you still need to be able to use the car to set up the business.

We can do this by adding ''access keys'' to the ownership key. By signing a message with the ownership key, access keys can be added or removed. Access keys can be temporary in nature. This means that for the duration of the loan, you can re-assign ownership of the vehicle to the creditor whilst keeping an access key for yourself.

It would be best if the debtor had an assurance that, on repaying his debt, the cars ownership would indeed revert to his control. We can implement this as follows:

# The creditor generates k1, which is used to receive the loan repayments. The loan size is L.
# The creditor signs Tx1 that has an input/output re-assigning ownership of the car back to the debtor which is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY, and an output for L coins to k1. This transaction is not valid because the loan has not yet been repaid, so the output sums to more value than the inputs. The creditor sends this transaction to the debtor who keeps it.
# As the debtor re-earns the money they spent, they add inputs to Tx1 to increase its value. This doesn't break the signature on the ownership key input/output pair because it was signed with SIGHASH_ANYONECANPAY so is independent of other inputs. They can't adjust the outputs or anything else about the transaction because that would invalidate the ownership input/output (SIGHASH_ALL).
# Once the transaction has enough inputs to sum to L, the debtor broadcasts the transaction, thus repaying their debt and simultaneously retaking ownership of the vehicle.

Because access keys can be given time limits, if the debtor does not repay the loan by its maturity period his access key expires and the car will no longer start for him. The new owner can now either come and pick it up himself, or if he doesn't want to (eg he is in another country), he can sell it using the low-trust sales protocol described above and collect the money that way.

Most loans are repaid in multiple installments. The same protocol as above can work in this case by embedding some control data in the extra input/output pair, the ownership key would not change but the signature would cover a command that extends the lifetime of the access key for another month. The vehicle would know how to parse the data out of the transaction.

==Implementation details==

For expiring access keys, the device must have a trustable source of time. Some devices like cars and phones keep time by themselves. In other cases where that's not practical for some reason, a secure timestamping service can be used. This is a service that signs a message containing the current time and a nonce. The device generates a nonce, and as part of the activation/switch-on protocol, a network connected device like a smartphone sends the nonce to the timestamping service then hands back the signed message. The block chain itself cannot be used as a source of time because there's no challenge/response aspect - the device has no way of knowing if you've handed it the latest blocks or not. Signing the time with a nonce solves this.

Smart phones play a key role in smart property because they have the ability to bridge devices without network access to the network, using Bluetooth or NFC radio. For instance, requiring internet access for a smart lock on a house door is too expensive and impractical. However, a lock with an NFC touchpoint that understands how to check block header progression is quite feasible. The only operations needed to implement Bitcoin-linked smart property is hashing, ECDSA and a small amount of storage. Smartcard chips that implement everything required are common and cheap.

[[Category:Technical]]

Distributed markets

2015-07-11T13:35:31Z

Jayemar: /* Detour: a financial distributed hashmap */ Added a link for Kademlia

Bitcoin allows us to create '''distributed markets''' for the trading of securities, like stocks and bonds. Such markets have no central clearing house and can support securities of a size too small to be practical with today's techniques. It's also possible to build a P2P replacement for ''investment funds''.

This page was written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have any questions. Jeff Garzik has started implementing some of these ideas in his [https://github.com/jgarzik/smartcoin smartcoin] project.

== Introduction ==

Let's start by defining some terms.

A ''bond'' is a securitized loan. That means somebody who wants a loan can sell some bonds and whoever owns that bond receives the re-payments and any interest that accrues. The bond, being an asset like any other, is transferable - if you get tired of receiving the repayments you can sell the bond to somebody else. Once the full amount of the bond has been repaid, we say it has reached maturity. Some bonds never mature and yield interest payments in perpetuity.

A ''stock'' is somewhat similar to a bond, except it never matures, yields irregular dividend payments instead of regular interest payments and confers voting rights upon the owner. In this document we will talk mostly about bonds, but the same ideas can be applied to build a stock market too.

A ''ratings agency'' evaluates the creditworthiness of bond sellers and assigns bonds a consistent score (AAA, AA, junk, etc).

''Sahai-Waters CP-ABE'' is a recent advance based on pairing-based encryption. Standard Bitcoin payments are point-to-point: I must know the target of my payment by knowing their key/address, and then I can send value to that target alone. Bitcoin script allows some flexibility, eg, by allowing threshold signatures or password based coins. But we lack the ability to pay to anyone who satisfies an arbitrary policy. Ciphertext-policy attribute based encryption (CP-ABE) allows you to encrypt some data such that anyone in possession of a key with attributes that match a formula can decrypt it.

== Detour: a financial distributed hashmap ==

A common problem encountered when designing advanced financial markets on top of Bitcoin is the need for a place to temporarily store small pieces of data, keyed by hash. This is because the block chain is not always the right place to put non-trivial amounts of data. The [https://en.wikipedia.org/wiki/Kademlia Kademlia] protocol and similar designs have solved this problem, albeit in a way that is vulnerable to a variety of DoS and Sybil attacks. But there is no network designed specifically for use in Bitcoin related systems. Today, their most common usage is in file sharing networks that are typically used for copyright infringement.

A separate Kademlia network can be built that is optimized solely for financial usage. Nodes would restrict the size of the stored data and artificially throttle the serving of it, thus discouraging storage of movies, games, MP3s and other such things. Initial insertion or value longevity could be made subject to proof of a Bitcoin stake (aged balances or posted bond), deterring garbage. This means users who are interested in the financial applications but don't wish to assist file sharing can donate their resources to the network without issue.

== A P2P bond network ==

We start with the familiar structure of an independent P2P broadcast network that connects to the financial hashmap. There is no need for an alternative block chain. Bonds can be modeled as if they were [[Smart Property]].

<nowiki>
message OutPoint {
required bytes tx_hash = 1;
required int index = 2;
}

message Issuer {
enum AuthType {
PUBLIC_KEY,
EMAIL_ADDRESS,
// Could add more in future, like EV SSL.
}
required AuthType auth_type = 1;

// Only one of the following should be set, according to authtype.
optional bytes pubkey = 2;
optional string email = 3;

// Name of the issuer as it will appear in the software, eg, a real name or company name.
required string display_name = 4;
// The script the issuer wants to receive the payments on.
required bytes pay_to_script = 5;
}

message Bond {
required OutPoint start_point = 1;
required Issuer issuer = 3;
required int value = 2;
required int coupon_value = 3;

// You could model more complex repayment schedules in future.
required int repayment_value = 4;

// UNIX time of when the bond was issued.
required int timestamp = 5;

// URL of the peer issuing the bond. This can be http://<home ip>:12345/ or
// perhaps a Tor onion address.
required string peer_url = 6;
}
</nowiki>

The issuer, timestamp and value fields should be self explanatory. The bond message would be inserted into the hashmap so others who know its hash can find it.

The start point identifies an output on the Bitcoin network that is created by the bond issuer. That output has a special form: it is of zero value and contains a script like this:

"BOND" <hash of bond message> 2DROP <issuer pubkey> CHECKSIG

This output tracks the current owner of the bond. The owner receives the repayments and any accrued interest. Of course a newly issued bond is special, it starts out being owned by the issuer.

The bond market client app that runs on your desktop follows the block chain, looking for Bitcoin transactions of that form. When it finds one, it downloads the bond message from the hashmap and shows the details in the UI.

If the bond owner wishes to sell the bond, a sale message is broadcast on the exchange p2p network:

<nowiki>
message ProposedBondSale {
required bytes bond_hash = 1;
required int requested_value = 2;
required bytes pay_to_script = 3;
required string peer_url = 4;
}
</nowiki>

If somebody wishes to buy that bond and sees the broadcast, they construct a transaction that spends requested_value of their own money to the pay_to_script, and add an input that connects to the zero-valued output of the current bondholder, and adds an output of the same BOND form to their own key. They pass it to the selling peer who checks that it looks valid and if so, signs for it then broadcasts thus atomically transferring the bond and the money.

By scanning the block chain for payments to the current owner of the bond, and checking them against the repayment schedule, the software can automatically calculate which bonds are delinquent and which are mature. Issuers of delinquent bonds would show up in the UI as in debt until sufficient sums were paid to the owners pubkey.

== Pay to policy outputs ==

Creating a decentralized bond market is a good start, but real financial markets are more complex. Often there is a layer of abstraction between buyer and seller: an investment fund. The funds encapsulate general instructions from the clients, such as "buy low risk municipal bonds" or "invest in energy stocks" and translates that into a stream of purchases and sales of specific assets. Funds compete on how they choose the specific assets and therefore what return they get.

Bitcoin payments today must be to a specific, concrete owner. By combining Bitcoin with CP-ABE we can instead make payments to a '''policy'''. A policy is a formula over a set of attributes. Attributes are arbitrary strings or string=integer pairs. Example policies include:

# ''ceo or (accounts_department AND manager)'' - a policy that allows the CEO of the company access, or a manager in the accounts department, but not any other kind of manager or member of accounting.
# ''master_key OR (3 OF (a, b, c, d, e))'' - a threshold policy that is overridable by a master key. Your key must have at least 3 of the 5 lettered attributes to be usable.
# ''verification_class=MtGoxBasicKYC AND common_name=MikeHearn AND access_level > 5'' - a policy that requires a key with a basic identity assertion of a specific name, verified according to the MtGox basic class, and which has an "access level" above a certain number.
# ''debt_rating(bobs_rating_agency) > 3 AND mining_bond AND interest_rate > 2300 AND interest_rate < 5000 AND repayment_months < 6'' - a policy stating that it can be unlocked by anyone in possession of a key that asserts it was issued for a mining bond with better than a rating of "3" (imagine an AAA like rating system), that will repay fully within 6 months and with an interest rate between 2.3 and 5%.

The policy is encoded into the ciphertext at encryption time, and the result can only be unlocked by a key that matches the policy. Keys attributes are assigned by an issuing authority.

It may at first appear that some of the policies expressed above are also expressible with script. For instance, if each attribute is considered to be a separate private key, you could try expressing the first example as a script that uses some CHECKSIGs along with boolean operators. But there are some problems with that approach.

The first problem is that people can collude to give themselves "superkeys". The Sahai-Waters scheme is collusion-resistant. In the first example, a manager who is not in accounting could team up with somebody who's not a manager but in the right department, and combine their keys to be able to spend the companies money. With CP-ABE the keys cannot be combined to merge attributes like that.

The second problem is that script cannot contain signatures over anything other than transactions, and only limited forms at that. So you cannot have numeric assertions in outputs because you have no way to verify the inputs are legitimate.

The third problem is that script rapidly becomes inefficient if you want complex policies over hundreds or thousands of attributes. CP-ABE policies can be quite large whilst remaining feasible.

There is a final reason to explore CP-ABE: whilst keys cannot be merged together to elevate privilege, you ''can'' remove attributes and thus delegated weakened power to others. In the first example, the manager of the accounts department does not need to get a new key issued from the key authority when a new employee joins: he can just remove the "manager" attribute from his key and generate a new key for the employee himself.

In the straightforward CP-ABE scheme, there must be exactly one key issuing authority that verifies the client deserves the attributes they're about to be given and then mints the keys. It is possible to decentralize the scheme to become [http://eprint.iacr.org/2010/351.pdf multi-authority CP-ABE] using the Lewko-Waters design.

Whilst some ABE schemes allow for hiding of the policy, the most expressive types make the policy public as part of the ciphertext. Fortunately this constraint is not a problem for us, indeed, it is an advantage.

An implementation of single-authority CP-ABE (as well as KP-ABE where keys contain policies and ciphertexts contain attributes) is available in [http://code.google.com/p/libfenc/ libfenc]. Multi-authority CP-ABE is available in a Python library called Charm. There are obviously many applications of this technique. Here we will explore only one.

== Investment funds ==

Rather than wait for specific bonds to become available and then manually evaluate each one by hand, we can construct a kind of distributed investment fund by sending money to a Bitcoin private key that is then encrypted under a policy and uploaded into the financial hashmap:

"POLICY" <hash of InvestmentFundAdvertisement message> 2DROP <pubkey> CHECKSIG

Policy-locked ciphertexts are potentially quite large, depending on the size of the policy (a comparison against a large number like a date can use over a kilobyte), so it makes sense to use the same hash disassociation used in the bond protocol above in order to minimize block chain size.

The hash would actually identify a data structure containing the ciphered private key:

<nowiki>
message InvestmentFundAdvertisement {
required bytes owner_pubkey = 1; // The key that will control the bond once sold.
required bytes ciphertext = 2; // Policy is embedded within this.
}
</nowiki>

As the bond market client crawls the block chain, it may encounter policy locked coins. By downloading the ciphertext from the hashmap, it can identify what conditions would unlock the coins and advertise that in the client. Somebody who is looking for business opportunities may see a message like this in their GUI:

There are ''200 BTC'' available to any bond issuer meeting the following criteria:
# Must be a mining bond.
# Must be repaid entirely within 6 months.
# Must yield an interest rate between 2.3% and 5%
# Debt must be rated as AA or better by one of {MtGox Ratings, Moodys, Standard&Poors}.
# These assertions must have been issued within the last month

Therefore demand is communicated to suppliers. By submitting such policy-locked coins, investors can send a message to the markets indicating that more mining capacity should be built.

To be able to find the private key and take the coins, you must obtain a key that matches these attributes by talking to the various issuing authorities. Once you have such a key, any coins sent to such a policy can be taken by yourself. By requiring attributes such as "issued_in=2012/06" the policies can be expired when needed (at the cost of an additional block chain transaction to update the hash).

Base58Check encoding

2015-07-03T13:59:18Z

Jayemar: /* Creating a Base58Check string */ Added a link to the technical background of the bitcoin address

A modified Base 58 [http://en.wikipedia.org/wiki/Binary-to-text_encoding binary-to-text encoding] known as '''Base58Check''' is used for encoding [[Bitcoin address|Bitcoin addresses]].

More generically, Base58Check encoding is used for encoding byte arrays in Bitcoin into human-typable strings.

==Background==
The original Bitcoin client source code explains the reasoning behind base58 encoding:

base58.h:
// Why base-58 instead of standard base-64 encoding?
// - Don't want 0OIl characters that look the same in some fonts and
// could be used to create visually identical looking account numbers.
// - A string with non-alphanumeric characters is not as easily accepted as an account number.
// - E-mail usually won't line-break if there's no punctuation to break at.
// - Doubleclicking selects the whole number as one word if it's all alphanumeric.

==Features of Base58Check==
Base58Check has the following features:
* An arbitrarily sized payload.
* A set of 58 alphanumeric symbols consisting of easily distinguished uppercase and lowercase letters (0OIl are not used)
* One byte of version/application information. Bitcoin addresses use 0x00 for this byte (future ones may use 0x05).
* Four bytes (32 bits) of SHA256-based error checking code. This code can be used to automatically detect and possibly correct typographical errors.
* An extra step for preservation of leading zeroes in the data.

==Creating a Base58Check string==
A Base58Check string is created from a version/application byte and payload as follows.
# Take the version byte and payload bytes, and concatenate them together (bytewise).
# Take the first four bytes of SHA256(SHA256(results of step 1))
# Concatenate the results of step 1 and the results of step 2 together (bytewise).
# Treating the results of step 3 - a series of bytes - as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. The result should be normalized to not have any leading base-58 zeroes (character '1').
# The leading character '1', which has a value of zero in base58, is reserved for representing an entire leading zero '''byte''', as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading '1's when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character '1' in the final result.
# Concatenate the 1's from step 5 with the results of step 4. '''This is the Base58Check result.'''
A more detailed example is provided on the page describing the [[Technical_background_of_version_1_Bitcoin_addresses#How_to_create_Bitcoin_Address | technical background]] of the bitcoin address.

==Encoding a Bitcoin address==
Bitcoin addresses are implemented using the Base58Check encoding of the hash of either:
* Pay-to-script-hash (p2sh): payload is [[RIPEMD160]]([[SHA256]](redeemScript the wallet knows how to spend)); version 0x05 (these addresses begin with the digit '3')
* Pay-to-pubkey-hash (p2pkh): payload is [[RIPEMD160]]([[SHA256]](ECDSA public key the wallet knows the private key for)); version 0x00 (these addresses begin with the digit '1')

The resulting hash in both of these cases is always exactly 20 bytes.
These are big-endian (most significant byte first). (Beware of [[bignumber]] implementations that clip leading 0x00 bytes, or prepend extra 0x00 bytes to indicate sign - your code must handle these cases properly or else you may generate valid-looking addresses which can be sent to, but cannot be spent from - which would lead to the permanent loss of coins.)

==Encoding a private key==
Base58Check encoding is also used for encoding [[private key|ECDSA private keys]] in the [[wallet import format]].
This is formed exactly the same as a Bitcoin address, except that 0x80 is used for the version/application byte, and the payload is 32 bytes instead of 20 (a private key in Bitcoin is a single 32-byte unsigned big-endian integer).
For private keys associated with an uncompressed public key, such encodings will always yield a 51-character string that starts with '5', or more specifically, either '5H', '5J', or '5K'.

==Base58 symbol chart==
The Base58 symbol chart used in Bitcoin is specific to the Bitcoin project and is not intended to be the same as any other Base58 implementation used outside the context of Bitcoin.
{| class="wikitable"
|-
!Value
!Character
!Value
!Character
!Value
!Character
!Value
!Character
|-
|0
|1
|1
|2
|2
|3
|3
|4
|-
|4
|5
|5
|6
|6
|7
|7
|8
|-
|8
|9
|9
|A
|10
|B
|11
|C
|-
|12
|D
|13
|E
|14
|F
|15
|G
|-
|16
|H
|17
|J
|18
|K
|19
|L
|-
|20
|M
|21
|N
|22
|P
|23
|Q
|-
|24
|R
|25
|S
|26
|T
|27
|U
|-
|28
|V
|29
|W
|30
|X
|31
|Y
|-
|32
|Z
|33
|a
|34
|b
|35
|c
|-
|36
|d
|37
|e
|38
|f
|39
|g
|-
|40
|h
|41
|i
|42
|j
|43
|k
|-
|44
|m
|45
|n
|46
|o
|47
|p
|-
|48
|q
|49
|r
|50
|s
|51
|t
|-
|52
|u
|53
|v
|54
|w
|55
|x
|-
|56
|y
|57
|z
|}

The algorithm for encoding address_byte_string (consisting of 1-byte_version + hash_or_other_data + 4-byte_check_code) is

code_string = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
x = convert_bytes_to_big_integer(hash_result)

output_string = ""

while(x > 0)
{
(x, remainder) = divide(x, 58)
output_string.append(code_string[remainder])
}

repeat(number_of_leading_zero_bytes_in_hash)
{
output_string.append(code_string[0]);
}

output_string.reverse();

==Version bytes==
Here are some common version bytes:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
|-
|0
|1
|Bitcoin pubkey hash
|-
|5
|3
|Bitcoin script hash
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|-
|52
|M or N
|Namecoin pubkey hash
|-
|128
|5
|Private key
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|-
|196
|2
|Bitcoin testnet script hash
|}
[[List of address prefixes]] is a more complete list.

== See Also ==
* [http://lenschulwitz.com/base58 Online Base58 Decoder, Encoder, and Validator]

== Source code ==
* [https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp "Satoshi" C++ codebase (decode and encode, no external libraries needed)]
* [https://github.com/luke-jr/libbase58 libbase58 C code (decode and encode, no external libraries needed)]
* [http://lenschulwitz.com/b58/base58perl.txt Base58 Decode, Encode, and Validate in Perl]

[[Category:Technical]]

[[es:Codificación Base58Check]]

OP CHECKSIG

2015-07-02T23:54:02Z

Jayemar: Clarified some of the grammar use in the explanation

'''OP_CHECKSIG''' is [[Script|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack. These are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. The scriptSig script is deleted after it is run, but the stack is left as is. Then, the scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.

The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.

For normal transaction inputs, if the creator of the current transaction can successfully create a ScriptSig signature that uses the right public key for the ScriptPubKey of the transaction output they are attempting to spend, that transaction input is considered valid.

== Parameters ==

In addition to the stack parameters and the script code itself, in order to operate correctly OP_CHECKSIG needs to know the current transaction and the index of current transaction input.

== How it works ==
Firstly always this (the default) procedure is applied:
[[File:Bitcoin_OpCheckSig_InDetail.png|thumb|right|Signature verification process of the default procedure]]
# the public key and the signature are popped from the stack, in that order. If the hash-type value is 0, then it is replaced by the last_byte of the signature. Then the last byte of the signature is always deleted.
# A new subscript is created from the instruction from the most recently parsed OP_CODESEPARATOR (last one in script) to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the subscript (hereby referred to as subScript)
# The sig is deleted from subScript.
# All OP_CODESEPARATORS are removed from subScript
# The hashtype is removed from the last byte of the sig and stored
# A copy is made of the current transaction (hereby referred to txCopy)
# The scripts for all transaction inputs in txCopy are set to empty scripts (exactly 1 byte 0x00)
# The script for the current transaction input in txCopy is set to subScript (lead in by its length as a var-integer encoded!)

Now depending on the hashtype various things can happen to txCopy, these will be discussed individually.

'''Hashtype Values (from script.h):'''
{|class="wikitable"
! Name !! Value
|-
| SIGHASH_ALL || 0x00000001
|-
| SIGHASH_NONE || 0x00000002
|-
| SIGHASH_SINGLE || 0x00000003
|-
| SIGHASH_ANYONECANPAY || 0x00000080
|}

<ol>
<li> If (hashtype&31) = SIGHASH_NONE then apply the SIGHASH_NONE-procedure
<li> If (hashtype&31) = SIGHASH_SINGLE then apply the SIGHASH_SINGLE-procedure
<li> If hashtype & SIGHASH_ANYONECANPAY then apply the SIGHASH_ANYONECANPAY-procedure
</ol>
Hence, hashtype SIGHASH_ANYONECANPAY may be applied also after any other hashtype-procedure<ref>[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/bitcoin-0.7.1-linux.tar.gz file src/src/script.cpp in bitcoin-0.7.1]</ref>. Besides the four listed hashtypes only a hashtype of value 0 appears a few times in the (main) block chain (and is handled like SIGHASH_ALL).

=== Hashtype SIGHASH_ALL (default) ===

No special further handling occurs in the default case. Think of this as "sign '''all''' of the outputs." Which is already done by the default procedure.

=== Procedure for Hashtype SIGHASH_NONE ===

# The output of txCopy is set to a vector of zero size.
# All other inputs aside from the current input in txCopy have their nSequence index set to zero

Think of this as "sign '''none''' of the outputs-- I don't care where the bitcoins go."

=== Procedure for Hashtype SIGHASH_SINGLE ===

# The output of txCopy is resized to the size of the current input index+1.
# All other txCopy outputs aside from the output that is the same as the current input index are set to a blank script and a value of (long) -1.
# All other txCopy inputs aside from the current input are set to have an nSequence index of zero.

Think of this as "sign '''one''' of the outputs-- I don't care where the other outputs go".

Note: The transaction that uses SIGHASH_SINGLE type of signature should not have more inputs than outputs.
However if it does (because of the pre-existing implementation), it shall not be rejected, but instead for every "illegal" input (meaning: an input that has an index bigger than the maximum output index) the node should still verify it, though assuming the hash of 0000000000000000000000000000000000000000000000000000000000000001 [https://bitcointalk.org/index.php?topic=260595.0]

=== Procedure for Hashtype SIGHASH_ANYONECANPAY ===

# The txCopy input vector is resized to a length of one.
# The subScript (lead in by its length as a var-integer encoded!) is set as the first and only member of this vector.

Think of this as "Let other people add inputs to this transaction, I don't care where the rest of the bitcoins come from."

===Final signature check===

An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash.
The secp256k1 elliptic curve is used for the verification with the given public key.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIG_VERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.

== Code samples and raw dumps ==

Taking the first transaction in Bitcoin which is in block number 170, we would get after serialising the transaction but before we hash+sign (or verify) it:

* http://blockexplorer.com/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee
* http://blockexplorer.com/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

See also [https://gitorious.org/libbitcoin/libbitcoin libbitcoin] for code samples.

<pre>
01 00 00 00 version
01 number of inputs (var_uint)

input 0:
c9 97 a5 e5 6e 10 41 02 input address hash
fa 20 9c 6a 85 2d d9 06
60 a2 0b 2d 9c 35 24 23
ed ce 25 85 7f cd 37 04
00 00 00 00 input index

48 size of script (var_uint)
47 push 71 bytes to stack
30 44 02 20 4e 45 e1 69
32 b8 af 51 49 61 a1 d3
a1 a2 5f df 3f 4f 77 32
e9 d6 24 c6 c6 15 48 ab
5f b8 cd 41 02 20 18 15
22 ec 8e ca 07 de 48 60
a4 ac dd 12 90 9d 83 1c
c5 6c bb ac 46 22 08 22
21 a8 76 8d 1d 09 01
ff ff ff ff sequence

02 number of outputs (var_uint)

output 0:
00 ca 9a 3b 00 00 00 00 amount = 10.00000000
43 size of script (var_uint)
script for output 0:
41 push 65 bytes to stack
04 ae 1a 62 fe 09 c5 f5
1b 13 90 5f 07 f0 6b 99
a2 f7 15 9b 22 25 f3 74
cd 37 8d 71 30 2f a2 84
14 e7 aa b3 73 97 f5 54
a7 df 5f 14 2c 21 c1 b7
30 3b 8a 06 26 f1 ba de
d5 c7 2a 70 4f 7e 6c d8
4c
ac OP_CHECKSIG

output 1:
00 28 6b ee 00 00 00 00 amount = 40.00000000
43 size of script (var_uint)
script for output 1:
41 push 65 bytes to stack
04 11 db 93 e1 dc db 8a
01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48
2e ca d7 b1 48 a6 90 9a
5c b2 e0 ea dd fb 84 cc
f9 74 44 64 f8 2e 16 0b
fa 9b 8b 64 f9 d4 c0 3f
99 9b 86 43 f6 56 b4 12
a3
ac OP_CHECKSIG

00 00 00 00 locktime
01 00 00 00 hash_code_type (added on)

result =
01 00 00 00 01 c9 97 a5 e5 6e 10 41 02 fa 20 9c 6a 85 2d d9 06 60 a2 0b 2d 9c 35
24 23 ed ce 25 85 7f cd 37 04 00 00 00 00 43 41 04 11 db 93 e1 dc db 8a 01 6b 49
84 0f 8c 53 bc 1e b6 8a 38 2e 97 b1 48 2e ca d7 b1 48 a6 90 9a 5c b2 e0 ea dd fb
84 cc f9 74 44 64 f8 2e 16 0b fa 9b 8b 64 f9 d4 c0 3f 99 9b 86 43 f6 56 b4 12 a3
ac ff ff ff ff 02 00 ca 9a 3b 00 00 00 00 43 41 04 ae 1a 62 fe 09 c5 f5 1b 13 90
5f 07 f0 6b 99 a2 f7 15 9b 22 25 f3 74 cd 37 8d 71 30 2f a2 84 14 e7 aa b3 73 97
f5 54 a7 df 5f 14 2c 21 c1 b7 30 3b 8a 06 26 f1 ba de d5 c7 2a 70 4f 7e 6c d8 4c
ac 00 28 6b ee 00 00 00 00 43 41 04 11 db 93 e1 dc db 8a 01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48 2e ca d7 b1 48 a6 90 9a 5c b2 e0 ea dd fb 84 cc f9 74 44
64 f8 2e 16 0b fa 9b 8b 64 f9 d4 c0 3f 99 9b 86 43 f6 56 b4 12 a3 ac 00 00 00 00
01 00 00 00
</pre>

To understand where that raw dump has come from, it may be useful to examine tests/ec-key.cpp in [https://gitorious.org/libbitcoin/libbitcoin libbitcoin],

[https://gitorious.org/libbitcoin/libbitcoin libbitcoin] has a unit test under tests/ec-key.cpp (make ec-key && ./bin/tests/ec-key). There is also a working OP_CHECKSIG implementation in src/script.cpp under script::op_checksig(). See also the unit test: tests/script-test.cpp

<source lang="cpp">
#include <iostream>
#include <iomanip>
#include <bitcoin/util/serializer.hpp>
#include <bitcoin/util/elliptic_curve_key.hpp>
#include <bitcoin/util/sha256.hpp>
#include <bitcoin/util/assert.hpp>
#include <bitcoin/util/logger.hpp>
#include <bitcoin/types.hpp>
#include <openssl/ecdsa.h>
#include <openssl/obj_mac.h>
using libbitcoin::elliptic_curve_key;
using libbitcoin::serializer;
using libbitcoin::hash_digest;
using libbitcoin::data_chunk;
using libbitcoin::log_info;
using libbitcoin::log_fatal;

int main()
{
serializer ss;
// blk number 170, tx 1, input 0
// version = 1
ss.write_4_bytes(1);
// 1 inputs
ss.write_var_uint(1);

// input 0
// prevout hash
ss.write_hash(hash_digest{0x04, 0x37, 0xcd, 0x7f, 0x85, 0x25, 0xce, 0xed, 0x23, 0x24, 0x35, 0x9c, 0x2d, 0x0b, 0xa2, 0x60, 0x06, 0xd9, 0x2d, 0x85, 0x6a, 0x9c, 0x20, 0xfa, 0x02, 0x41, 0x10, 0x6e, 0xe5, 0xa5, 0x97, 0xc9});
// prevout index
ss.write_4_bytes(0);

// input script after running OP_CHECKSIG for this tx is a single
// OP_CHECKSIG opcode
data_chunk raw_data;
raw_data = {0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
data_chunk raw_script;
raw_script = data_chunk();
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
raw_script.push_back(172);
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);
// sequence
ss.write_4_bytes(0xffffffff);

// 2 outputs for this tx
ss.write_var_uint(2);

// output 0
ss.write_8_bytes(1000000000);
// script for output 0
raw_data = {0x04, 0xae, 0x1a, 0x62, 0xfe, 0x09, 0xc5, 0xf5, 0x1b, 0x13, 0x90, 0x5f, 0x07, 0xf0, 0x6b, 0x99, 0xa2, 0xf7, 0x15, 0x9b, 0x22, 0x25, 0xf3, 0x74, 0xcd, 0x37, 0x8d, 0x71, 0x30, 0x2f, 0xa2, 0x84, 0x14, 0xe7, 0xaa, 0xb3, 0x73, 0x97, 0xf5, 0x54, 0xa7, 0xdf, 0x5f, 0x14, 0x2c, 0x21, 0xc1, 0xb7, 0x30, 0x3b, 0x8a, 0x06, 0x26, 0xf1, 0xba, 0xde, 0xd5, 0xc7, 0x2a, 0x70, 0x4f, 0x7e, 0x6c, 0xd8, 0x4c};
// when data < 75, we can just write it's length as a single byte ('special'
// opcodes)
raw_script = data_chunk();
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
// OP_CHECKSIG
raw_script.push_back(172);
// now actually write the script
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);

// output 1
ss.write_8_bytes(4000000000);
// script for output 0
raw_data = {0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
// when data < 75, we can just write it's length as a single byte ('special'
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
// OP_CHECKSIG
raw_script.push_back(172);
// now actually write the script
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);

// End of 2 outputs

// locktime
ss.write_4_bytes(0);

// write hash_type_code
ss.write_4_bytes(1);

// Dump hex to screen
log_info() << "hashing:";
{
auto log_obj = log_info();
log_obj << std::hex;
for (int val: ss.get_data())
log_obj << std::setfill('0') << std::setw(2) << val << ' ';
}
log_info();

data_chunk raw_tx = {0x01, 0x00, 0x00, 0x00, 0x01, 0xc9, 0x97, 0xa5, 0xe5, 0x6e, 0x10, 0x41, 0x02, 0xfa, 0x20, 0x9c, 0x6a, 0x85, 0x2d, 0xd9, 0x06, 0x60, 0xa2, 0x0b, 0x2d, 0x9c, 0x35, 0x24, 0x23, 0xed, 0xce, 0x25, 0x85, 0x7f, 0xcd, 0x37, 0x04, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3, 0xac, 0xff, 0xff, 0xff, 0xff, 0x02, 0x00, 0xca, 0x9a, 0x3b, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0xae, 0x1a, 0x62, 0xfe, 0x09, 0xc5, 0xf5, 0x1b, 0x13, 0x90, 0x5f, 0x07, 0xf0, 0x6b, 0x99, 0xa2, 0xf7, 0x15, 0x9b, 0x22, 0x25, 0xf3, 0x74, 0xcd, 0x37, 0x8d, 0x71, 0x30, 0x2f, 0xa2, 0x84, 0x14, 0xe7, 0xaa, 0xb3, 0x73, 0x97, 0xf5, 0x54, 0xa7, 0xdf, 0x5f, 0x14, 0x2c, 0x21, 0xc1, 0xb7, 0x30, 0x3b, 0x8a, 0x06, 0x26, 0xf1, 0xba, 0xde, 0xd5, 0xc7, 0x2a, 0x70, 0x4f, 0x7e, 0x6c, 0xd8, 0x4c, 0xac, 0x00, 0x28, 0x6b, 0xee, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3, 0xac, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00};
BITCOIN_ASSERT(raw_tx == ss.get_data());

hash_digest tx_hash = libbitcoin::generate_sha256_hash(ss.get_data());

data_chunk pubkey{0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
// Leave out last byte since that's the hash_type_code (SIGHASH_ALL in this
// case)
data_chunk signature{0x30, 0x44, 0x02, 0x20, 0x4e, 0x45, 0xe1, 0x69, 0x32, 0xb8, 0xaf, 0x51, 0x49, 0x61, 0xa1, 0xd3, 0xa1, 0xa2, 0x5f, 0xdf, 0x3f, 0x4f, 0x77, 0x32, 0xe9, 0xd6, 0x24, 0xc6, 0xc6, 0x15, 0x48, 0xab, 0x5f, 0xb8, 0xcd, 0x41, 0x02, 0x20, 0x18, 0x15, 0x22, 0xec, 0x8e, 0xca, 0x07, 0xde, 0x48, 0x60, 0xa4, 0xac, 0xdd, 0x12, 0x90, 0x9d, 0x83, 0x1c, 0xc5, 0x6c, 0xbb, 0xac, 0x46, 0x22, 0x08, 0x22, 0x21, 0xa8, 0x76, 0x8d, 0x1d, 0x09};
BITCOIN_ASSERT(signature.size() == 70);

elliptic_curve_key key;
if (!key.set_public_key(pubkey))
{
log_fatal() << "unable to set EC public key";
return -1;
}

log_info() << "checksig returns: " << (key.verify(tx_hash, signature) ? "true" : "false");
return 0;
}

</source>

==References==
<references/>

[[Category:Technical]]
[[Category:Developer]]
{{DISPLAYTITLE:OP_CHECKSIG}}
{{good}}