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 Expand

{
    "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.