I am using wallet_account_list_public_keys.
It lists 6 different versions of each public key, right?
Yes .. same information .. different format. You will also find a corresponding
PTS and BTC address .. for that particular key. if you dump the private key for
that particular key (haven't tested) you should be able to import it in electrum
and redeem and btc/pts
You said: "you can get the balance ids and addresses", I didn't know these were different. What is the difference, and which one is which, in what wallet_account_list_public_keys provides?
Oh, seems like balance_ids are the same as addresses
For me a balance id is a "unspent output" .. but those do not really exist in
BTS so you are right .. balance_ids == addresses
Also roadkill is asking for "something like wallet_sign_bal_hash", which seems
to me to be wrong in multiple ways. Number one, you don't want the balance
included, as you want thin wallets to be able to perform the validate public
keys operation, without needing the blockchain. The balance query need not be
verified, only the validation of the public keys. So a voting system must make
a single validation query, to a thin wallet, and repeated balance queries, when
needed, using validated public keys, in the open, to any client with a block
chain, right?
with wallet_sign_bal_hash you could sign with the key for the balance_id/address
.. thus, the signed message identifies an address for which you can (onchain)
figure out how much stake the signer has.
example:
- I own balance ID BTSXFooBar
- I sign the text "This is xeroc, and I vote for candidate A with my 100 BTS
stake" .. signing (the hash of the message) with the key for BTSXFooBar and
append it to the text
- everyone can now identify my balance address BTSXFooBar and check ONCHAIN, if
I really have 100 BTS in that address .. if so .. the vote counts (more
precisouly, the vote counts with the weight of all BTS in the address)
thus you can vote with your stake without moving it, but the checker has to have
a recent copy of the blockchain to verify the "weight".
Second, you don't want a specific signing mechanism, do you? You just need an
ability to sign any arbitrary hash. And the hash must be of a data set that
includes not only the public key, but also include a random UUID generated by
the voting system so that people can't re-use the signed block, fraudulently, as
other people have pointed out is a problem, right? Isn't there already a
generic sign any old hash function out there? That is all you need, right?
you can sign ANY data that is as long as a SHA256 hash .. i.e. 256 bit. no
matter where it comes from. But to be able to verify the signature you might be
required to also publish the signing address/balance_id .. otherwise you might
need to bruteforce verify all existing balance_ids.
The same happens when you sign sth. with a BTC address. The format goes
something like this:
---------------
Text
---------------
address to sign
signature of hash(Text) with the address above!
And I am interested in first things first. For the first version proof of
concept prototype, I am thinking you can get by with people submitting non
verified public keys, which we can query balances on in real time, every time we
canonize things. Then, once we get that running, we can move on to validating
people's keys.
It seems to me this validation of keys process needs a way to enable a voting
system, like Canonizer.com, to contact a users wallet (thin or thick), for this
validation process to be easy. Would everyone agree? What is the best way to
do this? Can you make an RPC or even an http call to a person's thin wallet
from a system like Canonizer.com? If so, how would that be done?
Seems reasonable to me
I still think blockchain_get_balance is broken (can anyone get this to work,
recently?), but you are right, I will move this to the technical support thread.
can't check right now .. I am compiling