https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Jpierre&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-29T15:53:17ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Miner_fees&diff=27633Miner fees2012-06-10T16:05:20Z<p>Jpierre: </p>
<hr />
<div>[[File:fee.png|thumb|Receiving a transaction fee of 0.44 BC]]<br />
Transaction fees may be included with any transfer of bitcoins from one address to another. At the moment, many [[transactions]] are typically processed in a way where no fee is expected at all, but for transactions which draw coins from many bitcoin addresses and therefore have a large data size, a small transaction fee is usually expected.<br />
<br />
The transaction fee is processed by and received by the bitcoin miner. When a new bitcoin block is generated with a successful hash, the information for all of the transactions is included with the block and all transaction fees are collected by that user creating the block, who is free to assign those fees to himself.<br />
<br />
Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction. On the other hand, nobody mining new bitcoins necessarily needs to accept the transactions and include them in the new block being created. The transaction fee is therefore an incentive on the part of the bitcoin user to make sure that a particular transaction will get included into the next block which is generated.<br />
<br />
It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.<br />
<br />
==Minimum transaction fees==<br />
<br />
As of 10 June 2012, minimum transaction fees on the original Bitcoin client are:<br />
<br />
* Accept a transaction for inclusion in a block: '''0.0005 BTC'''<br />
* Relay a transaction to other Bitcoin hosts: '''0.0001 BTC'''<br />
<br />
A transaction can be sent without fees if both of these conditions are met:<br />
<br />
* It is smaller than 10 (SI) kilobytes (10.000 bytes).<br />
* All outputs are 0.01 BTC or larger.<br />
<br />
==Overview==<br />
<br />
* Whoever sends the transaction is often able to guess an appropriate fee based on their own fee rules. The [[Original Bitcoin client|original client]] will always assess the transaction, and if a fee will typically be expected, it will not allow you to send the transaction without the calculated fee.<br />
* The user is prompted to confirm the fee before the transaction is sent.<br />
* The sender makes a transaction with more coins in the ''In'' portion than the ''Out'' portion so that there are “leftovers” not assigned to any address.<br />
* Whoever ends up publishing the [[block]] which contains this transaction will take these (and any other) leftover coins. They are included with their normal generated coins and is an extra bonus for creating the block.<br />
* If a mining node receives a transaction that should include a transaction fee but doesn't, they may refuse to include it in their blocks. It might be included in a later block if someone is willing to accept it. Generators can't force a certain fee on transactions -- they can only accept or reject the transaction's “fee offer”.<br />
[[File:lfm_fee.png|thumb|This balance is made entirely of 0.01 BTC cents. Since sending them requires a lot of data, a very large fee is required.]]<br />
<br />
==Rules for calculating minimum fees==<br />
<br />
Different bitcoin clients and different versions have different rules for determining which transactions to accept and how large a fee to send.<br />
<br />
Current default rules for the original Bitcoin client (Bitcoin 0.3.23):<br />
* minimum TX fee for new transactions reduced to 0.0005 BTC.<br />
<br />
Original Bitcoin client version 0.3.20:<br />
* 0.01 BTC fee if sending any transaction less than 0.01 BTC. This is to help prevent DoS attacks against the network. Remember: fees are not network-enforced, so it's still ''possible'' to send these small transactions without the fee -- you just have to generate the blocks that contain them yourself (after modifying Bitcoin).<br />
* 0.01 BTC fee per kilobyte of transaction, but:<br />
** If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.<br />
** If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.<br />
* Transactions within each fee tier are prioritized based on several factors. Most importantly, a transaction has more priority if the coins it is using have a lot of confirmations. Someone spamming the network will almost certainly be re-using the same coins, which will lower the priority of their transactions. Priority is also increased for transactions with more BTC, and reduced for transactions with more data.<br />
* If the blocksize is over 4kB, free transactions in the above rules are only allowed if the transaction's priority is above a certain level.<br />
<br />
Note that if you want to send a transaction with less than the default rules, or if you are a miner and want to include them in your blocks, you may need to peer with the [[Free transaction relay policy|Free transaction relay network]].<br />
<br />
An advantage for bitcoin users to include a transaction fee is that the likelihood of getting a transaction included into the next block is going to be higher than if a transaction fee is not included. This is a trade off of time vs. money put forward on the transaction fees, as you can be patient with a low or non-existent fee included in a transaction, or you can make sure that the transaction is processed immediately by including a higher fee than is typical.<br />
<br />
The rules are far from set in stone, and the network can support many different rules simultaneously. If there are mining nodes that never require a transaction fee and your client is modified to never send any transaction fee, then your transactions will eventually be picked up by one of those free nodes when they generate a block, though it will probably take a very long time. In the far future, different rules about transaction fees among mining nodes will probably create a clear choice between fees and transaction speed. For example, you might choose to spend 2% for a guaranteed spot in the next block or 0.01% for the transaction to be sent in a few hours.<br />
<br />
If you notice that your sent transactions take a very long time to confirm, this is possibly because no fee was included. Using a more recent release of the client will help lessen the chance of sending a transaction without an adequate fee.<br />
[[File:feesend.png|thumb|Sending a transaction when the sender doesn't have enough money to actually pay the fee]]<br />
<br />
==Technical info==<br />
<br />
Transaction priority is calculated as a value-weighted sum of input age, divided by transaction size in bytes:<br />
priority = sum(input_value_in_base_units * input_age)/size_in_bytes<br />
Transactions need to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold is written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.<br />
<br />
So, for example, a transaction that has 2 inputs, one of 5 btc with 10 confirmations, and one of 2 btc with 3 confirmations, and has a size of 500bytes, will have a priority of<br />
(500000000 * 10 + 200000000 * 3) / 500 = 11,800,000<br />
<br />
==See Also==<br />
<br />
* [[Free transaction relay policy]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
[[Category:Mining]]</div>Jpierrehttps://tests.bitcoin.it/w/index.php?title=Talk:Script&diff=24435Talk:Script2012-03-04T10:49:32Z<p>Jpierre: Corrected text.</p>
<hr />
<div>xOP_IFDUP 115 0x73 x x / x x If the input is true or false, duplicate it.<br />
<br />
Shouldn't it be: "If the input is true, duplicate it."?<br />
--[[User:ThePiachu|ThePiachu]] 11:37, 20 December 2011 (GMT)<br />
<br />
The byte vectors in the stack are specified as being signed integers of variable-length. Then there's an explanation that these integers are considered false if they are either zero or negative zero, which is 0x80. For this to be the case, the elements should be represented in an old binary format called sign-magnitude, which is important to state explicitly, since today virtually all computers use two's complement as representation, and there's no such thing as a negative zero. There's even another representation, one's complement, where negative zero looks like 0xff.<br />
<br />
Reading the source code of the application, I see that arithmetic operations expect unsigned integers, for example, operations OP_2MUL and OP_2DIV are implemented as byte-shifting, which wouldn't work with signed representations.<br />
<br />
It seems to me that, at best, variable-length sign-magnitued integer format is only used for testing for truth, although I haven't read all the code yet.<br />
<br />
--[[User:Jpierre|Jean-Pierre Rupp]] 10:43, 4 March 2012 (GMT)</div>Jpierrehttps://tests.bitcoin.it/w/index.php?title=Talk:Script&diff=24433Talk:Script2012-03-04T10:45:25Z<p>Jpierre: Fixed my signature.</p>
<hr />
<div>xOP_IFDUP 115 0x73 x x / x x If the input is true or false, duplicate it.<br />
<br />
Shouldn't it be: "If the input is true, duplicate it."?<br />
--[[User:ThePiachu|ThePiachu]] 11:37, 20 December 2011 (GMT)<br />
<br />
The byte vectors in the stack are specified as being signed integers or variable-length. Then there's an explanation that these integers are considered false if they are either zero or negative zero, which is 0x80. This is an old binary representation called sign-magnitude, which is important to state, since today virtually all computers use two's complement as representation, and there's no such thing as a negative zero there. There's even another representation, one's complement, where negative zero looks like 0xff.<br />
<br />
Reading the source code of the application, I see that arithmetic operations expect unsigned integers, for example, operations OP_2MUL and OP_2DIV are implemented as byte-shifting, which wouldn't work with signed representations.<br />
<br />
--[[User:Jpierre|Jean-Pierre Rupp]] 10:43, 4 March 2012 (GMT)</div>Jpierrehttps://tests.bitcoin.it/w/index.php?title=Talk:Script&diff=24432Talk:Script2012-03-04T10:43:39Z<p>Jpierre: Signed integers? not so sure!</p>
<hr />
<div>xOP_IFDUP 115 0x73 x x / x x If the input is true or false, duplicate it.<br />
<br />
Shouldn't it be: "If the input is true, duplicate it."?<br />
--[[User:ThePiachu|ThePiachu]] 11:37, 20 December 2011 (GMT)<br />
<br />
The byte vectors in the stack are specified as being signed integers or variable-length. Then there's an explanation that these integers are considered false if they are either zero or negative zero, which is 0x80. This is an old binary representation called sign-magnitude, which is important to state, since today virtually all computers use two's complement as representation, and there's no such thing as a negative zero there. There's even another representation, one's complement, where negative zero looks like 0xff.<br />
<br />
Reading the source code of the application, I see that arithmetic operations expect unsigned integers, for example, operations OP_2MUL and OP_2DIV are implemented as byte-shifting, which wouldn't work with signed representations.<br />
<br />
--[[User:Jpierre|Jpierre]] 10:43, 4 March 2012 (GMT)</div>Jpierrehttps://tests.bitcoin.it/w/index.php?title=Script&diff=24414Script2012-03-03T21:01:04Z<p>Jpierre: Some people associate integers with 32-bit fixed-length INT32. I specified variable-length so it's less ambiguous.</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
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<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence of the private key corresponding to the public key just provided.<br />
<br />
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.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.<br />
<br />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|Ends an if/else block.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the input is true or false, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|Concatenates two strings. ''Currently disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|Returns a section of a string. ''Currently disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|Keeps only characters left of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|Keeps only characters right of the specified point in a string. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|Flips all of the bits in the input. ''Currently disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Arithmetic is limited to max 4 byte integers<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|The input is multiplied by 2. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|The input is divided by 2. ''Currently disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|a is multiplied by b. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|a is divided by b. ''Currently disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|Returns the remainder after dividing a by b. ''Currently disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|Shifts a left b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|Shifts a right b bits, preserving sign. ''Currently disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|out<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|True / false<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VER<br />
|98<br />
|0x62<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|Transaction is invalid even when occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|Transaction is invalid unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1-OP_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above.<br />
<br />
=== Standard Transaction to Bitcoin address ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Standard Generation / transaction to IP address ===<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Transaction with a message ===<br />
<br />
It's possible to add arbitrary data to any transaction by just adding some data along with OP_DROP. Scripts are limited to 10,000 bytes and 201 instructions/values, and each individual instruction/value is limited to 520 bytes.<br />
<br />
scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <message> OP_DROP <pubKey> OP_CHECKSIG<br />
|<br />
|-<br />
|<sig><br />
|<message> OP_DROP <pubKey> OP_CHECKSIG<br />
|scriptSig added to the stack.<br />
|-<br />
|<sig> <message><br />
|OP_DROP <pubKey> OP_CHECKSIG<br />
|The message has been put.<br />
|-<br />
|<sig><br />
|<pubKey> OP_CHECKSIG<br />
|Top stack item has been removed.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
|Checking signature against the public key.<br />
|-<br />
|true<br />
|Empty.<br />
|Stack holds the value of signature check now.<br />
|}<br />
<br />
=== Example non standard transaction on Testnet ===<br />
<br />
These 2 links below show a non standard transaction. It just prepends the hex of "bob" and the operation OP_DROP<br />
which just removes it. As you can see they can be spent as normal.<br />
<br />
Input non-std transaction:<br />
http://blockexplorer.com/testnet/t/6ttfeb55B1<br />
<br />
Spent by:<br />
http://blockexplorer.com/testnet/t/AFdRB1CHS3<br />
<br />
==See Also==<br />
<br />
* [[Contracts]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Jpierrehttps://tests.bitcoin.it/w/index.php?title=Bitcoiner&diff=11515Bitcoiner2011-06-24T17:10:15Z<p>Jpierre: /* External Links */</p>
<hr />
<div>An open source RPC client for Android that connects to a node on a PC via the RPC interface.<br />
It allows transaction and balance overview as well as sending and receiving bitcoins using QR-codes. Going by a similar name is [[Bitcoiners]], a job board a freelancers directory.<br />
<br />
For setting up the node to work with SSL please see [[Enabling_SSL_on_original_client_daemon]].<br />
<br />
==External Links==<br />
<br />
* Bitcoiner on [https://market.android.com/details?id=net.lwi.bitcoiner Android market].<br />
* [http://sourceforge.net/projects/bitcoiner/ Bitcoiner] project page on Sorceforge.<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Clients]]<br />
[[Category:Free Software]]<br />
[[Category:Open Source]]<br />
[[Category:Mobile]]</div>Jpierrehttps://tests.bitcoin.it/w/index.php?title=User:Jpierre&diff=9914User:Jpierre2011-06-06T21:28:01Z<p>Jpierre: </p>
<hr />
<div>=Open Source Consultant · System Administrator · Web Developer=<br />
<br />
==Contact Information==<br />
<br />
* Country: Switzerland<br />
* Home phone: +41325120114<br />
<br />
==About me==<br />
<br />
Fascinated with all things Linux, I've set myself to work with open source technologies since the day I got my first login prompt and didn't have a clue of what to do next. More than ten years later I see myself as a fairly accomplished consultant, always eager to master a new skill while accomplishing something complex and enjoying the ride. In short, I'm a very happy geek.<br />
<br />
==Skills==<br />
===Operating Systems===<br />
* Linux (Red Hat, Debian, Ubuntu, SUSE)<br />
* Windows<br />
* Solaris<br />
* OpenBSD<br />
* AIX<br />
* HP-UX<br />
* SCO Unix<br />
* Virtualization<br />
* Xen<br />
* KVM<br />
* Qemu<br />
===Computer Languages===<br />
* Perl<br />
* Bash<br />
* Python<br />
* PHP<br />
* JavaScript<br />
* C<br />
* VBScript<br />
* HTML/CSS<br />
===Network Protocols===<br />
* TCP/IP<br />
* IPv6<br />
* SMTP<br />
* IPSec<br />
* PPTP<br />
* DNS<br />
* DHCP<br />
* SMB/CIFS<br />
* SSH<br />
* XMPP<br />
* DiffServ<br />
* VLAN<br />
* 802.11<br />
* PPPoE/PPPoA<br />
===Networking Software===<br />
* Nagios<br />
* Postfix<br />
* Sedmail<br />
* Zimbra<br />
* SpamAssassin<br />
* ISC BIND<br />
* ISC DHCP<br />
* Samba<br />
* iptables<br />
* Linux advanced routing<br />
* OpenLDAP<br />
* OpenVPN<br />
* Linux and Cisco QoS<br />
* Cisco IOS (intermediate)<br />
===Web Software===<br />
* Apache<br />
* PHP<br />
* Joomla/Mambo<br />
* Wordpress<br />
* Drupal<br />
===Other Software===<br />
* Inkscape (vector graphics)<br />
* Gimp (image manipulation)<br />
* Word Processing (OpenOffice.org Writer)<br />
* Spreadsheets (OpenOffice.org Calc)<br />
===Communication & Soft Skills===<br />
* Instruction<br />
* Public Addressing<br />
* Documentation<br />
<br />
[[Category:Freelancers]]<br />
[[Category:Freelancers-Sysadmin]]<br />
[[Category:Freelancers-Web Developer]]</div>Jpierrehttps://tests.bitcoin.it/w/index.php?title=User:Jpierre&diff=9913User:Jpierre2011-06-06T21:20:30Z<p>Jpierre: </p>
<hr />
<div>==Open Source Consultant · System Administrator · Web Developer==<br />
<br />
* Country: Switzerland<br />
* Home phone: +41325120114<br />
<br />
===About me===<br />
<br />
Fascinated with all things Linux, I've set myself to work with open source technologies since the day I got my first login prompt and didn't have a clue of what to do next. More than ten years later I see myself as a fairly accomplished consultant, always eager to master a new skill while accomplishing something complex and enjoying the ride. In short, I'm a very happy geek.<br />
<br />
[[Category:Freelancers]]<br />
[[Category:Freelancers-Sysadmin]]<br />
[[Category:Freelancers-Web Developer]]</div>Jpierrehttps://tests.bitcoin.it/w/index.php?title=User:Jpierre&diff=9912User:Jpierre2011-06-06T21:10:47Z<p>Jpierre: Created page with "==Open Source Consultant · System Administrator · Web Developer== * Country: Switzerland * Home phone: +41325120114 ===About me=== Fascinated with all things Linux, I've set..."</p>
<hr />
<div>==Open Source Consultant · System Administrator · Web Developer==<br />
<br />
* Country: Switzerland<br />
* Home phone: +41325120114<br />
<br />
===About me===<br />
<br />
Fascinated with all things Linux, I've set myself to work with open source technologies since the day I got my first login prompt and didn't have a clue of what to do next. More than ten years later I see myself as a fairly accomplished consultant, always eager to master a new skill while accomplishing something complex and enjoying the ride. In short, I'm a very happy geek.</div>Jpierre