Bitcoin Wiki - User contributions [en]

Talk:Litecoin

2012-07-04T16:32:31Z

Makomk: /* Objectivity please, missing citation */

There is nothing on this discussion page about this article at the moment. Use it. Reasonable informed edits will be allowed through until a consensus is reached and the page unlocked. That is comments that are neither pro or anti litecoin, but are ''neutral'' and objective. [[User:Genjix|Genjix]] 10:01, 28 November 2011 (GMT)

== Objectivity please, missing citation ==

There are two criticisms in the article, that I believe are not objective:

* Mining Monopoly - while I heard claims that Litecoin is volnurable to botnets, I never heard anything about a single monopoloy, or anyone possibly building a "single piece of specialized/custom hardware to overtake all the commodity mining systems combined". Can we have a citation for this, or remove it if no citation is found?
* Pyramid Scheme - The article states, as if it is a fact, that "Litecoin effectively functions as a pyramid scheme". This is hardly objective. Litecoin could possibly become say 1% of the total Bitcoin market, and could indeed function as "silver". The same arguments in [[FAQ#Is Bitcoin a Ponzi_scheme]] apply here.

Can we fix this?

[[User:Ripper234|Ripper234]] 13:43, 13 January 2012 (GMT)

* Mining Monopoly - This isn't Wikipedia. Independent research is acceptable. Litecoin's scrypt is not (and cannot be, by definition) resistant to custom mining hardware. It is, however, resistant to all commodity hardware. This leaves a huge gap in mining capabilities between commodity hardware and custom hardware, which enables even a single person designing custom hardware to easily gain a 51% attack over all other miners. Bitcoin's double-SHA256 performs well on commodity GPUs, which serve as a "tier" between CPUs and custom hardware.
* Pyramid Scheme - If you can make this more objective without being wrong, feel free. However, the fact is that Litecoin functions as a pyramid scheme because it has no long-term viability like Bitcoin does. It cannot function as "silver" or any other kind of currency because it cannot survive. Therefore, late comers do NOT benefit from it. Bitcoin is only exempt from the 'pyramid scheme' claim because of its long-term function as a currency.

[[User:Luke-jr|Luke-jr]] 17:12, 16 January 2012 (GMT)

: I believe the way to make the "pyramid scheme" section more objective is to remove it altogether. Meaningful criticism does not begin by assuming as a premise that all obstacles are insurmountable and that the currency is an inevitable failure. (Also, for clarification: did you delete my previous comments on this page because they were considered to not be objective?)

[[User:Angus|Angus]] 23:35, 17 January 2012 (GMT)

* Redundancy - Simply stating personal axioms is not helpful. There are several assumptions that are neither explained, supported by an argument or citation. The phrase, "...and Bitcoins much greater size..." has no context. What is meant by Bitcoin's size? Does this refer to the its userbase?

* Vulnerability to mining monopoly - "a malicious entity needs only produce a single piece of specialized/custom hardware to overtake all the commodity mining systems combined." There needs to be citation to back this up or a solid "homegrown" argument. What are the economics of this type of attack?

* Pyramid scheme - Without further context, the choice of the words, "Pyramid scheme", is simply not applicable, as there are no promises being made, investments being soliciated, etc. Regardless of the the ultimate fate of Litecoin, the term "pyramid scheme" is simply not applicable. As for the fate of Litecoin, the case of its inevitable demise has simply not been made within the confines of the article.

[[User:Dooley|Dooley]] 09:05, 9 February 2012 (GMT)

The "Mining monopoly" section is actually totally and utterly false. scrypt is not in fact designed to be inefficient on commodity hardware; if you read the original scrypt paper it's actually designed from the ground up for efficient implement on standard CPUs. One of the main design goals of scrypt was actually to limit the benefits an attacker using custom hardware could gain over people using off-the-shelf hardware. The designers of scrypt did this by cleverly making its performance dependant on memory bandwidth rather than processing power. Since the high-speed cache RAM on modern processors already takes up most of the die space, you won't be able to get much of an improvement over them by creating custom chips. In theory the best attack would be to find off-the-shelf processors whose balance of computational resources and cache fit scrypt-as-used-in-Litecoin perfectly, but that probably still wouldn't gain you a huge amount, especially as Intel has a big process advantage over the competition. - [[User:Makomk|Makomk]] ([[User talk:Makomk|talk]]) 16:32, 4 July 2012 (GMT)

== redundancy ==

It would be useful if a counter-argument to this criticism were mentioned. It does add something bitcoin doesn't have - it uses CPUs rather than GPUs to mine. --[[User:Rebroad|Rebroad]] 17:59, 21 February 2012 (GMT)

Merged mining specification

2011-11-07T22:07:33Z

Makomk: /* Aux work merkle tree */

== Aux proof-of-work ==
This is used to prove work on the aux chain. In vinced's original implementation it's generated by calling the getworkaux RPC method on the parent bitcoind and then the work is then submitted by passing it to the aux-chain namecoind as the second parameter to getauxblock.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || txns || [[Protocol specification#tx|txn]] || Coinbase transaction linking the aux to its parent block
|-
| ? || merkle_link || [[#Merkle link|mrkllink]] || The merkle path linking the coinbase (above) to its block
|-
| ? || aux_branch_count || var_int || Number of merkle branches linking this aux chains to the aux root
|-
| 32* || aux_branch[] || char[32] || Linking aux merkle branches
|-
| 4 || index || int32_t || Index of "this" block chain in the aux chain list
|-
| 80 || parent_block || [[Protocol specification#block|block header]] || Parent block header
|}

== Merkle link ==

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the block header
|-
| ? || branch_count || var_int || The number of links to bring the transaction to the block's merkle root
|-
| 32* || branch[] || char[32] || Linking merkle branches
|-
| 4 || index || int32_t || Index of this transaction in the merkle tree
|}

== Merged mining coinbase ==
Insert exactly one of these headers into the scriptSig of the coinbase on the parent chain. vinced's code always inserts an OP_2, 0xfa, 0xbe, 'm', 'm' in front of it, but you don't have to.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the aux work merkle tree
|-
| 4 || merkle_size || int32_t || Number of entries in aux work merkle tree. '''Must be a power of 2.'''
|-
| 4 || merkle_nonce || int32_t || Nonce used to calculate indexes into aux work merkle tree; you may as well leave this at zero
|}

==Aux work merkle tree==
If you're just mining a single auxiliary chain and using getauxblock, you don't have to worry about this - just set the merkle tree hash in the coinbase to the aux chain block's hash as given by getauxblock, the merkle size to 1, and the merkle nonce to 0. If you're mining more than one, this is a bit broken. It uses the following algorithm to convert the chain ID to a slot at the base of the merkle tree in which that chain's block hash must slot:

<pre>unsigned int rand = merkle_nonce;
rand = rand * 1103515245 + 12345;
rand += chain_id;
rand = rand * 1103515245 + 12345;
slot_num = rand % merkle_size</pre>

The idea is that you can increment merkle_nonce until the chains you're mining don't clash for the same slot. The trouble is that this doesn't work; because it just adds a number derived from the merkle_nonce to the chain_id, if two chains clash for one nonce they'll still clash for all possible nonces.<ref>https://bitcointalk.org/index.php?topic=51069.0</ref> New implementers: please pick your chain_id so that not clashing with existing chains requires as small a value of merkle_size as possible, or use a better algorithm to calculate the slot id for your chain.

Once you know where in the merkle tree the different chains go, ''reverse the bytes of each chain's block hash as given you by getauxblock'' (so the byte at the start moves to the end, etc) and insert into the appropriate slot, filling the unused ones with arbitrary data. Now build up the merkle tree as usual by taking each pair of values in the initial row and double SHA-256 hashing them to give a new row of hashes, repeating this until you only have a single hash. This last hash is the merkle root. You need to ''reverse the bytes of this again'' before inserting it into the coinbase. If you're not using getauxblock to get the block hash, you can skip the first reversal but still need to reverse the final merkle root when adding it to the coinbase.

The aux proof-of-work also needs a merkle branch, which is built as follows: find the location of the block's hash in the merkle tree, and add the other value that you hashed it with in building the merkle tree. Now add the value you hashed that result with. Keep doing this until you reach the root. The merkle root itself is ''never'' included in the merkle branch. If you just have a single aux chain, this can be left entirely empty. (It also appears you ''don't'' need to reverse these hashes.)

==Notes==
<references />

Merged mining specification

2011-11-07T22:06:52Z

Makomk:

== Aux proof-of-work ==
This is used to prove work on the aux chain. In vinced's original implementation it's generated by calling the getworkaux RPC method on the parent bitcoind and then the work is then submitted by passing it to the aux-chain namecoind as the second parameter to getauxblock.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || txns || [[Protocol specification#tx|txn]] || Coinbase transaction linking the aux to its parent block
|-
| ? || merkle_link || [[#Merkle link|mrkllink]] || The merkle path linking the coinbase (above) to its block
|-
| ? || aux_branch_count || var_int || Number of merkle branches linking this aux chains to the aux root
|-
| 32* || aux_branch[] || char[32] || Linking aux merkle branches
|-
| 4 || index || int32_t || Index of "this" block chain in the aux chain list
|-
| 80 || parent_block || [[Protocol specification#block|block header]] || Parent block header
|}

== Merkle link ==

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the block header
|-
| ? || branch_count || var_int || The number of links to bring the transaction to the block's merkle root
|-
| 32* || branch[] || char[32] || Linking merkle branches
|-
| 4 || index || int32_t || Index of this transaction in the merkle tree
|}

== Merged mining coinbase ==
Insert exactly one of these headers into the scriptSig of the coinbase on the parent chain. vinced's code always inserts an OP_2, 0xfa, 0xbe, 'm', 'm' in front of it, but you don't have to.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the aux work merkle tree
|-
| 4 || merkle_size || int32_t || Number of entries in aux work merkle tree. '''Must be a power of 2.'''
|-
| 4 || merkle_nonce || int32_t || Nonce used to calculate indexes into aux work merkle tree; you may as well leave this at zero
|}

==Aux work merkle tree==
If you're just mining a single auxiliary chain and using getauxblock, you don't have to worry about this - just set the merkle tree hash in the coinbase to the aux chain block's hash as given by getauxblock, the merkle size to 1, and the merkle nonce to 0. If you're mining more than one, this is a bit broken. It uses the following algorithm to convert the chain ID to a slot at the base of the merkle tree in which that chain's block hash must slot:

<pre>unsigned int rand = merkle_nonce;
rand = rand * 1103515245 + 12345;
rand += chain_id;
rand = rand * 1103515245 + 12345;
slot_num = rand % merkle_size</pre>

The idea is that you can increment merkle_nonce until the chains you're mining don't clash for the same slot. The trouble is that this doesn't work; because it just adds a number derived from the merkle_nonce to the chain_id, if two chains clash for one nonce they'll still clash for all possible nonces.<ref>https://bitcointalk.org/index.php?topic=51069.0</ref> New implementers: please pick your chain_id so that not clashing with existing chains requires as small a value of merkle_size as possible, or use a better algorithm to calculate the slot id for your chain.

Once you know where in the merkle tree the different chains go, ''reverse the bytes of each chain's block hash as given you by getauxblock'' (so the byte at the start moves to the end, etc) and insert into the appropriate slot, filling the unused ones with arbitrary data. Now build up the merkle tree as usual by taking each pair of hashes in the initial row and double SHA-256 hashing them to give a new row of hashes, repeating this until you only have a single hash. This last hash is the merkle root. You need to ''reverse the bytes of this again'' before inserting it into the coinbase. If you're not using getauxblock to get the block hash, you can skip the first reversal but still need to reverse the final merkle root when adding it to the coinbase.

The aux proof-of-work also needs a merkle branch, which is built as follows: find the location of the block's hash in the merkle tree, and add the other value that you hashed it with in building the merkle tree. Now add the value you hashed that result with. Keep doing this until you reach the root. The merkle root itself is ''never'' included in the merkle branch. If you just have a single aux chain, this can be left entirely empty. (It also appears you ''don't'' need to reverse these hashes.)

==Notes==
<references />

Merged mining specification

2011-11-07T22:06:10Z

Makomk: More on multiple aux chains

== Aux proof-of-work ==
This is used to prove work on the aux chain. In vinced's original implementation it's generated by calling the getworkaux RPC method on the parent bitcoind and then the work is then submitted by passing it to the aux-chain namecoind as the second parameter to getauxblock.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || txns || [[Protocol specification#tx|txn]] || Coinbase transaction linking the aux to its parent block
|-
| ? || merkle_link || [[#Merkle link|mrkllink]] || The merkle path linking the coinbase (above) to its block
|-
| ? || aux_branch_count || var_int || Number of merkle branches linking this aux chains to the aux root
|-
| 32* || aux_branch[] || char[32] || Linking aux merkle branches
|-
| 4 || index || int32_t || Index of "this" block chain in the aux chain list
|-
| 80 || parent_block || [[Protocol specification#block|block header]] || Parent block header
|}

== Merkle link ==

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the block header
|-
| ? || branch_count || var_int || The number of links to bring the transaction to the block's merkle root
|-
| 32* || branch[] || char[32] || Linking merkle branches
|-
| 4 || index || int32_t || Index of this transaction in the merkle tree
|}

== Merged mining coinbase ==
Insert exactly one of these headers into the scriptSig of the coinbase on the parent chain. vinced's code always inserts an OP_2, 0xfa, 0xbe, 'm', 'm' in front of it, but you don't have to.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the aux work merkle tree
|-
| 4 || merkle_size || int32_t || Number of entries in aux work merkle tree. '''Must be a power of 2.'''
|-
| 4 || merkle_nonce || int32_t || Nonce used to calculate indexes into aux work merkle tree; you may as well leave this at zero
|}

==Aux work merkle tree==
If you're just mining a single auxiliary chain and using getauxblock, you don't have to worry about this - just set the merkle tree hash in the coinbase to the aux chain block's hash as given by getauxblock, the merkle size to 1, and the merkle nonce to 0. If you're mining more than one, this is a bit broken. It uses the following algorithm to convert the chain ID to a slot at the base of the merkle tree in which that chain's block hash must slot:

<pre>unsigned int rand = merkle_nonce;
rand = rand * 1103515245 + 12345;
rand += chain_id;
rand = rand * 1103515245 + 12345;
slot_num = rand % merkle_size</pre>

The idea is that you can increment merkle_nonce until the chains you're mining don't clash for the same slot. The trouble is that this doesn't work; because it just adds a number derived from the merkle_nonce to the chain_id, if two chains clash for one nonce they'll still clash for all possible nonces.<ref>https://bitcointalk.org/index.php?topic=51069.0</ref> New implementers: please pick your chain_id so that not clashing with existing chains requires as small a value of merkle_size as possible, or use a better algorithm to calculate the slot id for your chain.

Once you know where in the merkle tree the different chains go, ''reverse the bytes of each chain's block hash as given you by getauxblock'' (so the byte at the start moves to the end, etc) and insert into the appropriate slot. Now build up the merkle tree as usual by taking each pair of hashes in the initial row and double SHA-256 hashing them to give a new row of hashes, repeating this until you only have a single hash. This last hash is the merkle root. You need to ''reverse the bytes of this again'' before inserting it into the coinbase. If you're not using getauxblock to get the block hash, you can skip the first reversal but still need to reverse the final merkle root when adding it to the coinbase.

The aux proof-of-work also needs a merkle branch, which is built as follows: find the location of the block's hash in the merkle tree, and add the other value that you hashed it with in building the merkle tree. Now add the value you hashed that result with. Keep doing this until you reach the root. The merkle root itself is ''never'' included in the merkle branch. If you just have a single aux chain, this can be left entirely empty. (It also appears you ''don't'' need to reverse these hashes.)

==Notes==
<references />

Merged mining specification

2011-11-07T21:47:02Z

Makomk: Formatting fix

== Aux proof-of-work ==
This is used to prove work on the aux chain. In vinced's original implementation it's generated by calling the getworkaux RPC method on the parent bitcoind and then the work is then submitted by passing it to the aux-chain namecoind as the second parameter to getauxblock.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || txns || [[Protocol specification#tx|txn]] || Coinbase transaction linking the aux to its parent block
|-
| ? || merkle_link || [[#Merkle link|mrkllink]] || The merkle path linking the coinbase (above) to its block
|-
| ? || aux_branch_count || var_int || Number of merkle branches linking this aux chains to the aux root
|-
| 32* || aux_branch[] || char[32] || Linking aux merkle branches
|-
| 4 || index || int32_t || Index of "this" block chain in the aux chain list
|-
| 80 || parent_block || [[Protocol specification#block|block header]] || Parent block header
|}

== Merkle link ==

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the block header
|-
| ? || branch_count || var_int || The number of links to bring the transaction to the block's merkle root
|-
| 32* || branch[] || char[32] || Linking merkle branches
|-
| 4 || index || int32_t || Index of this transaction in the merkle tree
|}

== Merged mining coinbase ==
Insert exactly one of these headers into the scriptSig of the coinbase on the parent chain. vinced's code always inserts an OP_2, 0xfa, 0xbe, 'm', 'm' in front of it, but you don't have to.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the aux work merkle tree
|-
| 4 || merkle_size || int32_t || Number of entries in aux work merkle tree. '''Must be a power of 2.'''
|-
| 4 || merkle_nonce || int32_t || Nonce used to calculate indexes into aux work merkle tree; you may as well leave this at zero
|}

==Aux work merkle tree==
If you're just mining a single auxiliary chain, you don't have to worry about this - just set the merkle tree hash in the coinbase to the aux chain block's hash, the merkle size to 1, and the merkle nonce to 0. If you're not, well have fun because this is a bit broken. It uses the following algorithm to convert the chain ID to a slot at the base of the merkle tree in which that chain's block hash must slot:

<pre>unsigned int rand = merkle_nonce;
rand = rand * 1103515245 + 12345;
rand += chain_id;
rand = rand * 1103515245 + 12345;
slot_num = rand % merkle_size</pre>

The idea is that you can increment merkle_nonce until the chains you're mining don't clash for the same slot. The trouble is that this doesn't work; because it just adds a number derived from the merkle_nonce to the chain_id, if two chains clash for one nonce they'll still clash for all possible nonces.<ref>https://bitcointalk.org/index.php?topic=51069.0</ref> New implementers: please pick your chain_id so that not clashing with existing chains requires as small a value of merkle_size as possible, or use a better algorithm for your chain.

==Notes==
<references />

Merged mining specification

2011-11-07T21:46:04Z

Makomk: Mining multiple chains: a caveat

== Aux proof-of-work ==
This is used to prove work on the aux chain. In vinced's original implementation it's generated by calling the getworkaux RPC method on the parent bitcoind and then the work is then submitted by passing it to the aux-chain namecoind as the second parameter to getauxblock.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || txns || [[Protocol specification#tx|txn]] || Coinbase transaction linking the aux to its parent block
|-
| ? || merkle_link || [[#Merkle link|mrkllink]] || The merkle path linking the coinbase (above) to its block
|-
| ? || aux_branch_count || var_int || Number of merkle branches linking this aux chains to the aux root
|-
| 32* || aux_branch[] || char[32] || Linking aux merkle branches
|-
| 4 || index || int32_t || Index of "this" block chain in the aux chain list
|-
| 80 || parent_block || [[Protocol specification#block|block header]] || Parent block header
|}

== Merkle link ==

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the block header
|-
| ? || branch_count || var_int || The number of links to bring the transaction to the block's merkle root
|-
| 32* || branch[] || char[32] || Linking merkle branches
|-
| 4 || index || int32_t || Index of this transaction in the merkle tree
|}

== Merged mining coinbase ==
Insert exactly one of these headers into the scriptSig of the coinbase on the parent chain. vinced's code always inserts an OP_2, 0xfa, 0xbe, 'm', 'm' in front of it, but you don't have to.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || block_hash || char[32] || Hash of the aux work merkle tree
|-
| 4 || merkle_size || int32_t || Number of entries in aux work merkle tree. [b]Must be a power of 2.[/b]
|-
| 4 || merkle_nonce || int32_t || Nonce used to calculate indexes into aux work merkle tree; you may as well leave this at zero
|}

==Aux work merkle tree==
If you're just mining a single auxiliary chain, you don't have to worry about this - just set the merkle tree hash in the coinbase to the aux chain block's hash, the merkle size to 1, and the merkle nonce to 0. If you're not, well have fun because this is a bit broken. It uses the following algorithm to convert the chain ID to a slot at the base of the merkle tree in which that chain's block hash must slot:

<pre>unsigned int rand = merkle_nonce;
rand = rand * 1103515245 + 12345;
rand += chain_id;
rand = rand * 1103515245 + 12345;
slot_num = rand % merkle_size</pre>

The idea is that you can increment merkle_nonce until the chains you're mining don't clash for the same slot. The trouble is that this doesn't work; because it just adds a number derived from the merkle_nonce to the chain_id, if two chains clash for one nonce they'll still clash for all possible nonces.<ref>https://bitcointalk.org/index.php?topic=51069.0</ref> New implementers: please pick your chain_id so that not clashing with existing chains requires as small a value of merkle_size as possible, or use a better algorithm for your chain.

==Notes==
<references />

Merged mining specification

2011-10-11T19:51:34Z

Makomk: More notes.