Talk:Electrum/Documentation - Revision history

ThomasV at 08:26, 14 June 2012

2012-06-14T08:26:52Z

← Older revision		Revision as of 08:26, 14 June 2012
Line 8:		Line 8:
	I am not an expert in cryptography.		I am not an expert in cryptography.
	However, 128 bits of entropy is believed to be enough to prevent attacks.		However, 128 bits of entropy is believed to be enough to prevent attacks.
	([[User talk:ThomasV\|talk]]) 08:24, 14 June 2012 (GMT)		[[User:ThomasV\|ThomasV]] ([[User talk:ThomasV\|talk]]) 08:26, 14 June 2012 (GMT)

ThomasV at 08:26, 14 June 2012

2012-06-14T08:26:35Z

← Older revision		Revision as of 08:26, 14 June 2012
Line 6:		Line 6:
	}		}

	128 bits of entropy is believed to be enough. ~~[[User:ThomasV\|ThomasV]]~~ ([[User talk:ThomasV\|talk]]) 08:24, 14 June 2012 (GMT)		I am not an expert in cryptography.
			However, 128 bits of entropy is believed to be enough to prevent attacks.
			([[User talk:ThomasV\|talk]]) 08:24, 14 June 2012 (GMT)

ThomasV at 08:24, 14 June 2012

2012-06-14T08:24:44Z

← Older revision		Revision as of 08:24, 14 June 2012
Line 6:		Line 6:
	}		}

	128 bits of entropy is believed to be enough. 08:24, 14 June 2012 (GMT)		128 bits of entropy is believed to be enough. [[User:ThomasV\|ThomasV]] ([[User talk:ThomasV\|talk]]) 08:24, 14 June 2012 (GMT)


Line 21:		Line 21:
	of course you can always recover your coins.		of course you can always recover your coins.
	but some people will never go into the details of understanding this; these people are at risk of losing coins.		but some people will never go into the details of understanding this; these people are at risk of losing coins.
	we want to design a client that can be used by non-techies. Not having to worry about an extra parameter is important.		we want to design a client that can be used by non-techies. Not having to worry about an extra parameter is important.
			[[User:ThomasV\|ThomasV]] ([[User talk:ThomasV\|talk]]) 08:24, 14 June 2012 (GMT)

	===tx===		===tx===
Line 28:		Line 29:
	Does this "Tx" come from blockchain/blockexplorer terminology? Or why is it called "Tx" ("transmit") and not "Rx" ("receive")? To be clarified.		Does this "Tx" come from blockchain/blockexplorer terminology? Or why is it called "Tx" ("transmit") and not "Rx" ("receive")? To be clarified.
	}		}
	tx=transaction.
			tx=transaction. [[User:ThomasV\|ThomasV]] ([[User talk:ThomasV\|talk]]) 08:24, 14 June 2012 (GMT)

ThomasV at 08:24, 14 June 2012

2012-06-14T08:24:15Z

← Older revision		Revision as of 08:24, 14 June 2012
Line 1:		Line 1:
			===seeds===
	{		{

	Open Point: It is _not clear_ whether the algorithm of deterministic address generation is designed such that for any two seeds "S1" and "S2" (out of the 2^128 possible different seeds) the following condition holds true:		Open Point: It is _not clear_ whether the algorithm of deterministic address generation is designed such that for any two seeds "S1" and "S2" (out of the 2^128 possible different seeds) the following condition holds true:
	* If 4.3 Billion (2^32 to be exact) new addresses are calculated from each S1 and from S2, does the algorithm guarantee that there will be no collision between the set of 2^32 addresses from S1 and the set of 2^32 addresses from S2?		* If 4.3 Billion (2^32 to be exact) new addresses are calculated from each S1 and from S2, does the algorithm guarantee that there will be no collision between the set of 2^32 addresses from S1 and the set of 2^32 addresses from S2?
	If this condition does not hold true, it needs to be clarified whether the use of deterministic wallets still bares an acceptably low probability of address collisions.		If this condition does not hold true, it needs to be clarified whether the use of deterministic wallets still bares an acceptably low probability of address collisions.
			}

			128 bits of entropy is believed to be enough. 08:24, 14 June 2012 (GMT)

	}


			===gap limit===
	{		{

Line 16:		Line 19:
	}		}

			of course you can always recover your coins.
			but some people will never go into the details of understanding this; these people are at risk of losing coins.
			we want to design a client that can be used by non-techies. Not having to worry about an extra parameter is important.

			===tx===
	{		{
	The number of outgoing transactions is apparently not counted. It is unclear why the column is called "Tx" and not "Rx", because it indicates the number of times that Bitcoins have been sent to this address, i.e. how often this address has "received" Bitcoins.		The number of outgoing transactions is apparently not counted. It is unclear why the column is called "Tx" and not "Rx", because it indicates the number of times that Bitcoins have been sent to this address, i.e. how often this address has "received" Bitcoins.
	Does this "Tx" come from blockchain/blockexplorer terminology? Or why is it called "Tx" ("transmit") and not "Rx" ("receive")? To be clarified.		Does this "Tx" come from blockchain/blockexplorer terminology? Or why is it called "Tx" ("transmit") and not "Rx" ("receive")? To be clarified.
	}		}
			tx=transaction.

ThomasV at 08:17, 14 June 2012

2012-06-14T08:17:34Z

← Older revision		Revision as of 08:17, 14 June 2012
Line 14:		Line 14:
	* If you enter a too high value for the gap limit when recovering a wallet from seed, you will unnecessarily generate too many new addresses that will then show up in your wallet, all with zero balance. But at least all your funds are recovered in this case.		* If you enter a too high value for the gap limit when recovering a wallet from seed, you will unnecessarily generate too many new addresses that will then show up in your wallet, all with zero balance. But at least all your funds are recovered in this case.

			}

			{
			The number of outgoing transactions is apparently not counted. It is unclear why the column is called "Tx" and not "Rx", because it indicates the number of times that Bitcoins have been sent to this address, i.e. how often this address has "received" Bitcoins.
			Does this "Tx" come from blockchain/blockexplorer terminology? Or why is it called "Tx" ("transmit") and not "Rx" ("receive")? To be clarified.
	}		}

ThomasV at 08:16, 14 June 2012

2012-06-14T08:16:41Z

← Older revision		Revision as of 08:16, 14 June 2012
Line 4:		Line 4:
	* If 4.3 Billion (2^32 to be exact) new addresses are calculated from each S1 and from S2, does the algorithm guarantee that there will be no collision between the set of 2^32 addresses from S1 and the set of 2^32 addresses from S2?		* If 4.3 Billion (2^32 to be exact) new addresses are calculated from each S1 and from S2, does the algorithm guarantee that there will be no collision between the set of 2^32 addresses from S1 and the set of 2^32 addresses from S2?
	If this condition does not hold true, it needs to be clarified whether the use of deterministic wallets still bares an acceptably low probability of address collisions.		If this condition does not hold true, it needs to be clarified whether the use of deterministic wallets still bares an acceptably low probability of address collisions.

			}


			{

			To avoid misunderstandings and panic: This does not mean that you will irrecoverably loose your funds when you have forgotten the gap limit and want to recover your wallet from seed. It just means:
			* If you enter a too low gap limit when recovering a wallet from seed, it may happen that some of the later addresses in the deterministic sequence of addresses are not recovered although they have a balance>0, such that your wallet will not show the full balance.
			* If you enter a too high value for the gap limit when recovering a wallet from seed, you will unnecessarily generate too many new addresses that will then show up in your wallet, all with zero balance. But at least all your funds are recovered in this case.

	}		}

ThomasV: from Mike

2012-06-14T08:14:11Z

from Mike

New page

{

Open Point: It is _not clear_ whether the algorithm of deterministic address generation is designed such that for any two seeds "S1" and "S2" (out of the 2^128 possible different seeds) the following condition holds true:
* If 4.3 Billion (2^32 to be exact) new addresses are calculated from each S1 and from S2, does the algorithm guarantee that there will be no collision between the set of 2^32 addresses from S1 and the set of 2^32 addresses from S2?
If this condition does not hold true, it needs to be clarified whether the use of deterministic wallets still bares an acceptably low probability of address collisions.

}