Bitcoin Wiki - User contributions [en]

Armory

2016-08-19T08:58:58Z

TierNolan: Fixed typo in link

'''Bitcoin Armory''' is an open-source, python-based, wallet-management application for the Bitcoin network.

'''Note:''' The Armory project is no longer maintained by its creator<ref>[https://bitcointalk.org/index.php?topic=1351792.0 The End of the Road for Armory]</ref>, however there is an effort underway to [https://github.com/etotheipi/BitcoinArmory/issues/325 change to a new maintainer].

==Features==

* Available for Windows, Mac OSX, and Linux.
* Licensed under AGPL v3.
* Encrypted wallet (optional).
* Maintain offline wallets for 100% security from online attackers.
* Import addresses created with [[vanitygen|VanityGen]] or sweep funds from Casascius physical Bitcoins.
* Toggle between “Standard”, “Advanced”, and "Expert" modes to guarantee an appropriate set of options and information.
* Custom [[deterministic wallet]] format.
* Ability to add "Watching-Only" Wallets.
* Fragmented (M-of-N) Backups.
* SecurePrint for all Backup Types.
* Decentralized Multi-Signature "Lockboxes" (up to 7-of-7).
* Daemon/API for Services and Network Integration.
* Message Signing.

See the [http://bitcointalk.org/index.php?topic=56424.0 project's forum thread] for full details or on [https://bitcoinarmory.com/ their website].

==History==

The Armory project was announced January 3rd, 2012<ref>[http://bitcointalk.org/index.php?topic=56424.0 Armory - The most advanced Bitcoin Client in existence!] on [[BitcoinTalk Forum]]</ref>.

=== Crowdfunding ===

The project received $2,661 by 26 funders on crowdfunding site RocketHub. The project completed it's funding on 2012-03-19<ref>[http://www.rockethub.com/projects/6056-armory-bitcoin-development-funding Armory Bitcoin Development Funding]</ref>.

==See Also==

* [[Thin Client Security]]

==External Links==

* [http://btcarmory.com/ Armory Site]
* [https://bitcointalk.org/index.php?board=97.0 Armory project page on bitcointalk.org]
* [https://github.com/goatpig/BitcoinArmory Armory Source on GitHub]
* [http://www.expresscoin.com/wallets/bitcoin/armory How to Setup a Armory Bitcoin Wallet for Windows, Mac, and Linux]

'''Discontinued'''
* [https://www.bitcoinarmory.com/ Armory Official Website] (ATI no longer maintains Armory)
* [https://github.com/etotheipi/BitcoinArmory Armory Project GitHub Page] (no longer maintained)

==References==
<references />

[[Category:Clients]]
[[Category:Open Source]]

Armory

2016-08-18T08:57:08Z

TierNolan: Adds links to new website and github (goatpig's)

'''Bitcoin Armory''' is an open-source, python-based, wallet-management application for the Bitcoin network.

'''Note:''' The Armory project is no longer maintained by its creator<ref>[https://bitcointalk.org/index.php?topic=1351792.0 The End of the Road for Armory]</ref>, however there is an effort underway to [https://github.com/etotheipi/BitcoinArmory/issues/325 change to a new maintainer].

==Features==

* Available for Windows, Mac OSX, and Linux.
* Licensed under AGPL v3.
* Encrypted wallet (optional).
* Maintain offline wallets for 100% security from online attackers.
* Import addresses created with [[vanitygen|VanityGen]] or sweep funds from Casascius physical Bitcoins.
* Toggle between “Standard”, “Advanced”, and "Expert" modes to guarantee an appropriate set of options and information.
* Custom [[deterministic wallet]] format.
* Ability to add "Watching-Only" Wallets.
* Fragmented (M-of-N) Backups.
* SecurePrint for all Backup Types.
* Decentralized Multi-Signature "Lockboxes" (up to 7-of-7).
* Daemon/API for Services and Network Integration.
* Message Signing.

See the [http://bitcointalk.org/index.php?topic=56424.0 project's forum thread] for full details or on [https://bitcoinarmory.com/ their website].

==History==

The Armory project was announced January 3rd, 2012<ref>[http://bitcointalk.org/index.php?topic=56424.0 Armory - The most advanced Bitcoin Client in existence!] on [[BitcoinTalk Forum]]</ref>.

=== Crowdfunding ===

The project received $2,661 by 26 funders on crowdfunding site RocketHub. The project completed it's funding on 2012-03-19<ref>[http://www.rockethub.com/projects/6056-armory-bitcoin-development-funding Armory Bitcoin Development Funding]</ref>.

==See Also==

* [[Thin Client Security]]

==External Links==

* [http://http://btcarmory.com/ Armory Site]
* [https://bitcointalk.org/index.php?board=97.0 Armory project page on bitcointalk.org]
* [https://github.com/goatpig/BitcoinArmory Armory Source on GitHub]
* [http://www.expresscoin.com/wallets/bitcoin/armory How to Setup a Armory Bitcoin Wallet for Windows, Mac, and Linux]

'''Discontinued'''
* [https://www.bitcoinarmory.com/ Armory Official Website] (ATI no longer maintains Armory)
* [https://github.com/etotheipi/BitcoinArmory Armory Project GitHub Page] (no longer maintained)

==References==
<references />

[[Category:Clients]]
[[Category:Open Source]]

OP CHECKSIG

2011-07-03T00:55:00Z

TierNolan:

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. After the scriptSig script is run the script is deleted but the stack is left as is, and then then 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 script code itself and the stack parameters, to operate OP_CHECKSIG needs to know the current transaction, the current transaction input, and the current hashtype (discussed later)

== How it works ==

# the public key and the signature are popped from the stack, in that order.
# A new subscript is created from the instruction from the most recent OP_CODESEPARATOR 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.
# The hashtype is removed from the last byte of the sig and stored
# A deep copy is made of the current transaction (hereby referred to txCopy)
# All OP_CODESEPARATORS are removed from subScript
# The scripts for all transaction inputs in txCopy are set to empty scripts
# The script for the current transaction input in txCopy is set to subScript

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
|}

=== Hashtype SIGHASH_ALL (default) ===

No special handling occurs in the default case

=== 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

=== 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

=== Hashtype SIGHASH_ANYONECANPAY ===

# The txCopy input vector is resized to a length of one
# The current input is set as the first and only member of this vector

== Final signature ==

An array of bytes is constructed from the serialized txCopy + four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to to check the supplied signature against the hash.

== 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.

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

OP CHECKSIG

2011-07-03T00:54:48Z

TierNolan:

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. After the scriptSig script is run the script is deleted but the stack is left as is, and then then 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 script code itself and the stack parameters, to operate OP_CHECKSIG needs to know the current transaction, the current transaction input, and the current hashtype (discussed later)

== How it works ==

# the public key and the signature are popped from the stack, in that order.
# A new subscript is created from the instruction from the most recent OP_CODESEPARATOR 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.
# The hashtype is removed from the last byte of the sig and stored
# A deep copy is made of the current transaction (hereby referred to txCopy)
# All OP_CODESEPARATORS are removed from subScript
# The scripts for all transaction inputs in txCopy are set to empty scripts
# The script for the current transaction input in txCopy is set to subScript

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 || 0x0000000080
|}

=== Hashtype SIGHASH_ALL (default) ===

No special handling occurs in the default case

=== 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

=== 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

=== Hashtype SIGHASH_ANYONECANPAY ===

# The txCopy input vector is resized to a length of one
# The current input is set as the first and only member of this vector

== Final signature ==

An array of bytes is constructed from the serialized txCopy + four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to to check the supplied signature against the hash.

== 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.

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

Base 58 Encoding

2011-06-30T13:56:04Z

TierNolan:

==Base 58 Encoding==

Base 58 encoding is used for encoding addresses.

Address = Base58Encode(RIPEMD160(SHA-256(public key))

The public key is expressed as an encoded point.

{| class="wikitable"
|-
!Code
!Character
!Code
!Character
!Code
|Character
!Code
!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 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(output_string[remainder])
}

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

output_string.reverse();

== Source ==
https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

Base 58 Encoding

2011-06-29T15:16:41Z

TierNolan: Created page with "==Base 58 Encoding== Base 58 encoding is used for encoding addresses. Address = Base58Encode(RIPEMD160(SHA-256(public key)) The public key is expresses as an encoded point. {..."

==Base 58 Encoding==

Base 58 encoding is used for encoding addresses.

Address = Base58Encode(RIPEMD160(SHA-256(public key))

The public key is expresses as an encoded point.

{| class="wikitable"
|-
!Code
!Character
!Code
!Character
!Code
|Character
!Code
!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 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(output_string[remainder])
}

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

output_string.reverse();

== Source ==
https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

Talk:Protocol rules

2011-06-26T12:53:56Z

TierNolan: Created page with "= Proposed Recommended Rule Changes = == Transaction override == === Change === {| class="wikitable" |- | Before|| Tx || 9 || Reject if any other tx in the pool uses the same ..."

= Proposed Recommended Rule Changes =

== Transaction override ==

=== Change ===

{| class="wikitable"
|-
| Before|| Tx || 9 || Reject if any other tx in the pool uses the same transaction output as one used by this tx.
|-
| After || Tx || 9 || Reject if any other tx in the pool uses the same transaction output as one used by this tx, and has a greater or equal transaction fee
|}

=== Rationale ===

When the default client sends a transaction without a sufficient transaction fee to complete, the coin ends up in limbo. The default client won't allow spending of any of the input coins, but the network won't forward the coin to any neighbours. This means that miners never add the coin to the chain.

This change would allow the client to re-send the transaction with an increased fee. Clients which already saw the old transaction will still forward the new transaction, since it has a higher fee. The client could even prompt the user about any transaction which has been pending for more than an hour or 2.