wallet_import_private_key on uncompressed key generates compressed BTS pubkey?

[monsterer]

It wont solve the problem in the OP, though - that would require the bitshares client to carry the compressed status of any imported private key over into the public key.

Can you work around this? This would require a hardfork to handle a 6th address type, as well as the added complexity of tracking this in the wallet.

Yes, we can work around it - importing private keys carries a lot of user friction anyway, so we'll be moving away from it

[vikram]

It wont solve the problem in the OP, though - that would require the bitshares client to carry the compressed status of any imported private key over into the public key.

Can you work around this? This would require a hardfork to handle a 6th address type, as well as the added complexity of tracking this in the wallet.

[monsterer]

Would it help to have an API call that will return you a public key corresponding to a withdrawal address in the BitShares transaction, so that you could send Bitcoin to that public key without caring about BitShares accounts?

This would allow the gateway to handle unregistered bitshares accounts, so that would be excellent

It wont solve the problem in the OP, though - that would require the bitshares client to carry the compressed status of any imported private key over into the public key.

[vikram]

How do you tie this account to the BitAssets that were deposited to the gateway? Is each account assigned a specific BitAsset deposit address?

By looking up the from_account field in the transaction ledger and pulling out the public key from the get_account call.

Would it help to have an API call that will return you a public key corresponding to a withdrawal address in the BitShares transaction, so that you could send Bitcoin to that public key without caring about BitShares accounts?

[monsterer]

How do you tie this account to the BitAssets that were deposited to the gateway? Is each account assigned a specific BitAsset deposit address?

By looking up the from_account field in the transaction ledger and pulling out the public key from the get_account call.

[vikram]

* Bitassets sent to the gateway are converted to bitcoin and sent to the bitcoin address derived from the bitshares public key, which is always compressed

Where does the BitShares public key come from in this step?

wallet_get_account -> active_key_history.Last()

How do you tie this account to the BitAssets that were deposited to the gateway? Is each account assigned a specific BitAsset deposit address?

[monsterer]

* Bitassets sent to the gateway are converted to bitcoin and sent to the bitcoin address derived from the bitshares public key, which is always compressed

Where does the BitShares public key come from in this step?

wallet_get_account -> active_key_history.Last()

steps to replicate the situation in the OP:

import_key 5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss testkey
wallet_account_list_public_keys testkey

Code: [Select]

{
    "hex": "03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd",
    "native_pubkey": "BTS859gxfnXyUriMgUeThh1fWv3oqcpLFyHa3TfFYC4PK2HqhToVM",
    "native_address": "BTS1HiftbrvT87siVvaSjp6F6Cvqovjjmim",
    "pts_normal_address": "PpVitpSnLuWjFiPAKiawjM124JWQZCVtDd",
    "pts_compressed_address": "PmyeJqnhf3HEH4XxzXnfRHCwdHrJz2omJW",
    "btc_normal_address": "1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN",
    "btc_compressed_address": "1F3sAm6ZtwLAUnj7d38pGFxtP3RVEvtsbV"
  }
Note that 5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss is an uncompressed key, and also that hex above refers to a compressed public key.

[vikram]

* Bitassets sent to the gateway are converted to bitcoin and sent to the bitcoin address derived from the bitshares public key, which is always compressed

Where does the BitShares public key come from in this step?

[monsterer]

Once a BTC is sent from an address, the public key is revealed, which means you can derive any form you want.
Can you describe your problem in a bit more detail?

Here is the problem, use case BTC/bitAsset gateway:

* User imports their bitcoin wallet into bitshares
* Their wallet contains a mix of compressed/uncompressed private keys (don't ask me why)
* Bitshares converts all imported private keys into compressed public keys
* Bitassets sent to the gateway are converted to bitcoin and sent to the bitcoin address derived from the bitshares public key, which is always compressed
* The user will/will not receive the bitcoins depending on whether they imported uncompressed/compressed private keys

If you approach this from the other angle and ask the user to import their bitshares private key into their bitcon wallet, they will have to fund the particular address generated from that private key and then only send funds from that address in order for the gateway to forward bitAssets to the correct bitshares account.

[toast]

The solution I chose for http://xchain.info was to always use the uncompressed addresses. The fact that Bitshares always exports a private key in long form, simplifies this process because you can instruct the end-user to export their Bitshares account key into a Bitcoin client (rather than the other way) and they're guaranteed to get the correct key type.

The trouble with that is they have to then fund that address and only send funds from bitcoin, from that particular address, which is difficult?

Once a BTC is sent from an address, the public key is revealed, which means you can derive any form you want.
Can you describe your problem in a bit more detail?

[monsterer]

The solution I chose for http://xchain.info was to always use the uncompressed addresses. The fact that Bitshares always exports a private key in long form, simplifies this process because you can instruct the end-user to export their Bitshares account key into a Bitcoin client (rather than the other way) and they're guaranteed to get the correct key type.

The trouble with that is they have to then fund that address and only send funds from bitcoin, from that particular address, which is difficult?

[julian1]

When exporting a key, Bitshares will only export the long form.  So if you import a compressed private key, and then immediately dump it, it will have a different representational value.

The issue for a Gateway is that it has to take a decision on receipt of the token asset, as to whether to send to the compressed or uncompressed Btc address. If it gets this wrong, then funds are lost, until the end-user can take remedial steps to reimport the keys in the alternate form.

The solution I chose for http://xchain.info was to always use the uncompressed addresses. The fact that Bitshares always exports a private key in long form, simplifies this process because you can instruct the end-user to export their Bitshares account key into a Bitcoin client (rather than the other way) and they're guaranteed to get the correct key type.

[pc]

Currently, every private key (uncompressed WIF starting with "5"), can control 5 different addresses in BTS:

• standard BTS
• uncompressed BTC
• compressed BTC
• uncompressed PTS
• compressed PTS

For every private key, the wallet currently checks all 5 addresses for balances.

But if you import an uncompressed private key, bitshares generates a compressed public key?

That question doesn't really make sense.
compressed / uncompressed are just different representations of the same key. To validate a signature you need *the* public key. You can then create compressed/uncompressed BTC+PTS *addresses* for *the* public key in order to check if the signature is sufficient to claim a genesis balance sharedropped on one or more of these BTS/PTS addresses.

[monsterer]

Currently, every private key (uncompressed WIF starting with "5"), can control 5 different addresses in BTS:

• standard BTS
• uncompressed BTC
• compressed BTC
• uncompressed PTS
• compressed PTS

For every private key, the wallet currently checks all 5 addresses for balances.

But if you import an uncompressed private key, bitshares generates a compressed public key?

[vikram]

Currently, every private key (uncompressed WIF starting with "5"), can control 5 different addresses in BTS:

• standard BTS
• uncompressed BTC
• compressed BTC
• uncompressed PTS
• compressed PTS

For every private key, the wallet currently checks all 5 addresses for balances.

[xeroc]

It seems uncompressed privkeys correspond to the uncimpressed pubkey while compressed keys correspond to compress pubkey and thus a different btc address ...

Maybe a dev can confirm

This makes sense to me.

yea.. every wif key has to correspond to jus a SINGLE address (stated in the btc wiki too).. though the pubkey can be represented in twobways reaulting in two addresses ... thus you distinguish the addresses by prefix for the privkey

@vikram: is this about right?

[monsterer]

It seems uncompressed privkeys correspond to the uncimpressed pubkey while compressed keys correspond to compress pubkey and thus a different btc address ...

Maybe a dev can confirm

This makes sense to me.

[xeroc]

It seems uncompressed privkeys correspond to the uncimpressed pubkey while compressed keys correspond to compress pubkey and thus a different btc address ...

Maybe a dev can confirm

[xeroc]

From the bitcoin wiki:

For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5 on mainnet (9 on testnet). Private keys associated with compressed public keys are 52 characters and start with a capital L or K on mainnet (c on testnet).

[monsterer]

oh .. learned something again ..

Still .. a single private key (also) corresponds to an uncompressed an a compressed pubkey which result in two different addresses accesable from the same private key .. AFAIK

Not sure what a compressed privkey is .. and what it is used for ..

I'm not sure, but I have both kinds in my bitcoin wallet.

[xeroc]

oh .. learned something again ..

Still .. a single private key (also) corresponds to an uncompressed an a compressed pubkey which result in two different addresses accesable from the same private key .. AFAIK


Not sure what a compressed privkey is .. and what it is used for ..

[monsterer]

The private key afaik cannot be compressed .. if you check out pycoin you will see that a private key corresponds to TWO btc addresse .. one is the base58checkencoded version of the uncompressed key .. the other usea the compeessed keys ... not sure how clients handle this though ..

.. worth a research

Compressed private key: L15CvRxwgLY1sBdGXCQz3kk7XD2sNCpuUnPE1yMR8jYDZcUgkujT
Bitcoin address: 1EGVFMirpv59mkWw7cAdtCSTphUpLnK8f6

Uncompressed private key: 5JgvT9q24UY3Tn14Wx9c8RQpF6SoJVWS2mGTWg3pA185D24q2u2
Bitcoin address: 1aDSxwBJN1uczBwCSNoSmUMA9xcG5bi22

Check them out via: https://brainwallet.github.io/

[xeroc]

The private key afaik cannot be compressed .. if you check out pycoin you will see that a private key corresponds to TWO btc addresse .. one is the base58checkencoded version of the uncompressed key .. the other usea the compeessed keys ... not sure how clients handle this though ..

.. worth a research

[monsterer]

I'd say so .. anyway compress keys and uncompressed keys carry the same information and can be computed from eachother

Though the compressed version obviously needs less space

For the gateway stuff it becomes a problem, because someone could import their uncompressed private key from bitcoin, which would get turned into a compressed bitshares pub-key, so when bitAssets are sent to the gateway, the bitshares pub-key of the sender is looked up, which maps to a different bitcoin address than the one the user has in their wallet because it's now compressed instead of uncompressed.

This would mean bitcoins would never arrive in the users wallet, they'd need to add the compressed private key in order to get their funds.

[xeroc]

I'd say so .. anyway compress keys and uncompressed keys carry the same information and can be computed from eachother

Though the compressed version obviously needs less space

[monsterer]

I've just done a wallet_import_private_key on an uncompressed private key and looking at the results of wallet_account_list_public_keys, it looks like the generated public key is compressed. Is this the expected behavior?