Difference between revisions of "Talk:Keyset (voting pools)"

From Open Transactions
Jump to navigation Jump to search
(Created page with "I understand what an xpub is (an extended public key) but it might not be clear for the first time reader, maybe we should write that. Do we have a good reference on extended ...")
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 
I understand what an xpub is (an extended public key) but it might not be clear for the first time reader, maybe we should write that. Do we have a good reference on extended keys? I guess this might be the best: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Extended_keys
 
I understand what an xpub is (an extended public key) but it might not be clear for the first time reader, maybe we should write that. Do we have a good reference on extended keys? I guess this might be the best: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Extended_keys
 +
 +
[[User:Larshesel|Larshesel]] ([[User talk:Larshesel|talk]]) 08:36, 6 November 2014 (UTC):
 +
 +
I might just fail to remember. Does the auditors make the decision that a series should become active? Is the wallet supposed to know if a series is active or not? Since I don't see a way that the wallet is explicitly told, I assume the wallet is not to know this. That assumption is also reinforced by the fact that getdepositscript tells the wallet from which series it should create an address.
 +
 +
On the other hand, currently we have some assumptions in the code that we know which series is the active one (for instance, we're saving a bit saying if the series is active or not) and are starting to build further on this assumption, so it would be good to get clarified what the initial design idea was.
 +
 +
I can't tell right now if there are things in the wallet that actually *need* to know if a series is active or not. But if it did, it could enforce certain things, like not allowing getdepositscript to create deposit addresses for an inactive series, or eliminating the series id from the getdepositscript call entirely.
 +
 +
Update: [[User:Larshesel|Larshesel]] ([[User talk:Larshesel|talk]]) 09:15, 6 November 2014 (UTC):
 +
 +
Never mind - this is clearly spelled out elsewhere. The charter output defines the active series, and we can check if a series is active by looking for the charteroutput at the specified address. In that way we can provide relevant error messages etc.

Latest revision as of 09:15, 6 November 2014

I understand what an xpub is (an extended public key) but it might not be clear for the first time reader, maybe we should write that. Do we have a good reference on extended keys? I guess this might be the best: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Extended_keys

Larshesel (talk) 08:36, 6 November 2014 (UTC):

I might just fail to remember. Does the auditors make the decision that a series should become active? Is the wallet supposed to know if a series is active or not? Since I don't see a way that the wallet is explicitly told, I assume the wallet is not to know this. That assumption is also reinforced by the fact that getdepositscript tells the wallet from which series it should create an address.

On the other hand, currently we have some assumptions in the code that we know which series is the active one (for instance, we're saving a bit saying if the series is active or not) and are starting to build further on this assumption, so it would be good to get clarified what the initial design idea was.

I can't tell right now if there are things in the wallet that actually *need* to know if a series is active or not. But if it did, it could enforce certain things, like not allowing getdepositscript to create deposit addresses for an inactive series, or eliminating the series id from the getdepositscript call entirely.

Update: Larshesel (talk) 09:15, 6 November 2014 (UTC):

Never mind - this is clearly spelled out elsewhere. The charter output defines the active series, and we can check if a series is active by looking for the charteroutput at the specified address. In that way we can provide relevant error messages etc.