BitShares Forum

Main => Technical Support => Topic started by: zhangweis on June 10, 2015, 06:05:35 am

Title: [BTS2.0] Concern about account id on blockchain instead of address
Post by: zhangweis on June 10, 2015, 06:05:35 am
I remember it's mentioned somewhere that account id is used in transaction on blockchain instead of address. Suppose you're using a lightweight wallet and you want to transfer money to someone account. If the server cheats you by giving wrong account id, your money can go to somewhere else. In bitcoin (or BTS1.0), if I'm using address as transfer target, the worst the server can cheat is not broadcasting and I'm relatively safe.
I think it's better to use address on blockchain and for perfomance reason hash the address to an id for memory and code to use. This way it's still safe and with high performance.
I know if you're using account name, we need to trust the server for getting the account id or public key and it's similar with BTS 1.0. And account id as target has the benefit that changing active/owner key will not impact account's balance. But at least we should have an option to specify address as target in a transaction on blockchain.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: alt on June 10, 2015, 07:37:55 am
to withdraw a balance, only check account ID
to deposit a balance, need to check both account name and account ID, even address.
I think this is the best way, and can avoid to sent to a wrong receiver even if he have update the public key.
sever can't cheap client with a wrong ID, or wrong address.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: svk on June 10, 2015, 07:50:23 am
I don't see why it's different, why can't the server replace the address in the same way as the id? It's simply a unique identifier, in this case it will be an easier one to verify visually as well since you won't need to double-check a huge bitcoin-style address.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: xeroc on June 10, 2015, 10:28:36 am
I am also thinking about this .. in particular for offline devices .. this will be an extra barrier .. but as @svk said .. it's the same thing whether you check an address or an id ...
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: sittingduck on June 10, 2015, 10:36:43 am
An id is far easier on all fronts.  It makes hardware wallets much easier. It is short like a phone number so easy to say or enter by hand. 



Sent from my iPhone using Tapatalk
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: alt on June 10, 2015, 11:18:04 am
I am also thinking about this .. in particular for offline devices .. this will be an extra barrier .. but as @svk said .. it's the same thing whether you check an address or an id ...
how about build transaction with both receiver's id and name?
chain server can't cheat wallet client with wrong id. witness will verify it.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: sittingduck on June 10, 2015, 11:38:41 am
If IDs cannot be trusted then the whole protocol breaks down. 

Users should share the ID as the primary identifier.  The name is a check. 

In some sense names are less necessary and should not be used on their own. 


Sent from my iPhone using Tapatalk
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: zhangweis on June 10, 2015, 01:14:34 pm
If IDs cannot be trusted then the whole protocol breaks down. 

Users should share the ID as the primary identifier.  The name is a check. 

In some sense names are less necessary and should not be used on their own. 


Sent from my iPhone using Tapatalk

Well, in my case, I always use account name and don't even care what the account id is. Actually I fear typo a lot and always copy the name instead of typing. In this sense, it's not different than an address and address has even additional hash check for typo.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: zhangweis on June 10, 2015, 01:27:48 pm
I don't see why it's different, why can't the server replace the address in the same way as the id? It's simply a unique identifier, in this case it will be an easier one to verify visually as well since you won't need to double-check a huge bitcoin-style address.
I think the difference is that there's one more step to get account id from a name from a trusted server. In bitcoin, you only need address (which is somewhat equivalent to id).
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: toast on June 10, 2015, 01:36:40 pm
OP is a bad example because the server could spoof a name->address map just as easily. The real problem has to do with chain reorganization and replay attacks. Seems the solution is that DPOS achieves consensus too quickly for that or something
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: zhangweis on June 10, 2015, 02:00:51 pm
OP is a bad example because the server could spoof a name->address map just as easily. The real problem has to do with chain reorganization and replay attacks. Seems the solution is that DPOS achieves consensus too quickly for that or something

Yes, reorg and replay is another issue and I still think we need an option to transfer to a bitcoin like address.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: svk on June 10, 2015, 02:06:28 pm
I don't see why it's different, why can't the server replace the address in the same way as the id? It's simply a unique identifier, in this case it will be an easier one to verify visually as well since you won't need to double-check a huge bitcoin-style address.
I think the difference is that there's one more step to get account id from a name from a trusted server. In bitcoin, you only need address (which is somewhat equivalent to id).

OK I see what you mean here and how this could be an issue. At least in our web wallet though the id's will be displayed as well as the names, so when you attempt to make a transfer you can verify the name and the id, even looking it up on an external site like Bitsharesblocks if you want to.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: xiahui135 on June 10, 2015, 02:50:13 pm
There are two password for us to pay, using a centralized service.
Usually, we login with a long password, and input a short password to confirm the pay.
The short password can be reset, just to make the owner be serious to pay money.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: bytemaster on June 10, 2015, 03:21:10 pm
OP is a bad example because the server could spoof a name->address map just as easily. The real problem has to do with chain reorganization and replay attacks. Seems the solution is that DPOS achieves consensus too quickly for that or something

TaPoS prevents that in DPOS 2.   By referencing a particular recent block hash you implicitly reference all allocated IDs.  If the chain reorganizes then your transfer becomes invalid.

The user interface is going to display the ID as the "checksum" for the account name.   The security paranoid will manually verify account IDs as they add accounts to their address book. 

Light nodes should check with multiple servers via a secure channel to prevent man in the middle. 
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: xeroc on June 10, 2015, 03:26:52 pm
You could derive a identicon from the id and use it together with the account name .. thatway you can verify the account name versus the identicon versus the ID ..
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: svk on June 10, 2015, 05:05:32 pm
You could derive a identicon from the id and use it together with the account name .. thatway you can verify the account name versus the identicon versus the ID ..

We are indeed already doing this as well.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: zhangweis on June 10, 2015, 08:49:17 pm
TaPoS prevents that in DPOS 2.   By referencing a particular recent block hash you implicitly reference all allocated IDs.  If the chain reorganizes then your transfer becomes invalid.
What if the server cheats by telling an invalid block hash?

Light nodes should check with multiple servers via a secure channel to prevent man in the middle.
This adds unnecessary burden to wallet.
Adding an optional way to send to address can solve all this but I know it's a fundamental change as there's no address thing in balances and that's not compatible with account thing. Anyway please consider that.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: alt on June 10, 2015, 11:01:26 pm
how about add receiver_name to tx?
the receiver_name just used to verify by witness when confirm tx.

Looking at the tx generated by
transfer "1.3.11" "1.3.1" 100 CORE "memo" true

Quote
{
  "ref_block_num": 832,
  "ref_block_prefix": 1233679879,
  "relative_expiration": 3,
  "operations": [[
      0,{
        "fee": {
          "amount": 0,
          "asset_id": "1.4.0"
        },
        "from": "1.3.11",
        "to": "1.3.1",
+      "receiver_name": "init0"
        "amount": {
          "amount": 10000000,
          "asset_id": "1.4.0"
        },
        "memo": {
          "from": "1.2.1",
          "to": "1.2.0",
          "nonce": "11962994495084021359",
          "message": "001e77e19727022f7d12e3571bf30c4b"
        }
      }
    ]
  ],
  "signatures": [[
      "1.2.1",
      "1f6a44dc809adfced585aa9f393d76061db3cec77d0fa0c65bb07ff0d48426f9175c317351ac10e3e84d580c853c01285913937136d75b1d74c594d9e62ebf4591"
    ]
  ]
}
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: bytemaster on June 11, 2015, 02:31:52 pm
https://github.com/cryptonomex/graphene/issues/39
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: xeroc on June 11, 2015, 02:36:40 pm
https://github.com/cryptonomex/graphene/issues/39
+5%!!!
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: alt on June 11, 2015, 03:45:34 pm
https://github.com/cryptonomex/graphene/issues/39
+5% light wallet is more safe and more easy now  :D
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: zhangweis on June 11, 2015, 09:20:15 pm
https://github.com/cryptonomex/graphene/issues/39
+5%. Thanks for listening.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: jamesc on June 14, 2015, 06:14:22 pm
I would like to see the transfer transaction have an optional account name "to" field.  Because the transfer transaction can also have an account id, it should also be provided and validated when ever possible.

Bytemaster (in github) noticed a few other operations where this might be useful.  I looked into and, well, lets say it started expanding into a lot of other what-ifs...  So, that is getting complicated.  Lets remember we can do things off-chain...   

One case jumps out at me, btercom vrs bter.  This is a real loss.  The BTER exchange registered "btercom" but some other entity registered the shorter name bter.  Sure enough, a user sent money to the wrong address.  It was not good, this user was just getting into BitShares and this was there initial investment. 

So, here is the new hypothetical story...  Example.com creates there new account "examplecom".  When they do, their wallet hashes that name adding 3 base58 encoded characters to the end.  Now, there safe name would look like this:

exampllecom_8d8

Also, assuming this is not a cold-wallet, the wallet will also grab examplecom's account id which is say 37,521 (current registered accounts on BitShares).  Finally, 3 more chars are added which is a check for both examplecom and the encoded account id.  Note, this is the actual length with fake checksums:

examplecom_8d8_6rzDCojw9e9

This becomes useful in anyplace where we use an account ID (for example: active and owner signature authorities).  If the ID is not known a shorter version may be used (just examplecom_8d8).  It should still be possible in every case to simply use examplecom.

The identicon should remain unchanged on the account name, this gives the cold wallet the ability to show a matching identicon even though it can't lookup the account number.

I used an _ because that most often lets one double-click and select the entire name.  An underscore is not allowed in a BTS account name.

btw: did you notice, I really typed two 'l's in the example .. complete accident I promise...  If only exampllecom_8d8 was provided, the computer would catch the mistake in all but 1 case in every 190K cases).
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: theoretical on June 23, 2015, 05:38:50 pm
The real problem has to do with chain reorganization and replay attacks.

I addressed this very early in Graphene development by suggesting adding the full block_id of a recent block (the "reference block") to a tx digest [1].  The blockchain currently implements this by specifying the low 16 bits of the block height, the chain will fetch the block hash from the most recent block whose low 16 bits of height match the tx header, and include that block hash in the tx digest.  As long as the ID's referenced in the tx were assigned in or before the reference block, your tx is invulnerable to a reorg/replay attack -- it will have a different digest, and thus its sig will be invalid, on any fork which doesn't include the ref block (as long as there are no hash collisions).

[1] This idea was actually originally tossed about in the pre-launch discussions of the consensus algorithm for BTS 0.x as TaPoS.
Title: Re: [BTS2.0] Concern about account id on blockchain instead of address
Post by: arhag on June 23, 2015, 08:23:58 pm
The real problem has to do with chain reorganization and replay attacks.

I addressed this very early in Graphene development by suggesting adding the full block_id of a recent block (the "reference block") to a tx digest [1].  The blockchain currently implements this by specifying the low 16 bits of the block height, the chain will fetch the block hash from the most recent block whose low 16 bits of height match the tx header, and include that block hash in the tx digest.  As long as the ID's referenced in the tx were assigned in or before the reference block, your tx is invulnerable to a reorg/replay attack -- it will have a different digest, and thus its sig will be invalid, on any fork which doesn't include the ref block (as long as there are no hash collisions).

[1] This idea was actually originally tossed about in the pre-launch discussions of the consensus algorithm for BTS 0.x as TaPoS.

Yup, I'm really happy you guys added this. It has other great security benefits:

https://bitsharestalk.org/index.php/topic,6584.msg87951.html#msg87951
You may think that you can just filter out all of the transactions that change their vote from the null slate to good-delegate-(k+101), but keep the transactions that changed the vote from good-delegate-k to the null slate in the first place. If you could do this, you would end up with all of your evil delegates in the top 101 slots with 2% approval, and the rest of the good delegates at lower slots with either 1% approval or less. But you cannot do this, because you did not have nearly all of your evil delegates simultaneously in the top 101 slots at any point in time.  The first time you would need to filter out one of these problematic transactions, you would be forced to filter out all of the blocks produced by good delegates after that point (otherwise the hash link would be broken).
...
But if this is not satisfying enough, there is another measure that can be taken to be extra cautious. We can bring back TaPOS on top of DPOS. The transactions do not need to reference the previous block, they can reference a block well enough in the past that is well establish. The point is that TaPOS would make it impossible to even include those unvoting transactions in your fake blockchain.

https://bitsharestalk.org/index.php/topic,14618.msg190100.html#msg190100
From your link I take Economic Clustering to mean the following:
Quote
From technical point of view it means that if someone decides to rewrite the history of the blockchain he won't be able to include transactions of those who don't take part in the attack, because every transaction contains the id of one of the recent blocks.

This seems a lot like Transactions-as-Proof-of-Stake (TaPoS). When BitShares was upgraded to DPOS this feature of binding each transaction not to only the chain ID but to a more recent block of the chain was removed.

...

Furthermore, I do not see how this Economic Clustering completely solves the Nothing-at-Stake problem as you claim in your post. The attacker producing the fake blockchain can simply remove everyone else's transactions from their fake blockchain and include their own transactions between sockpuppets to make it appear that the fake blockchain is valid. If they are able to trick the user onto that chain, they could then carry out the double-spend attack. The only problem for the attacker is if the victim is recovering an existing account where they have already made outgoing transactions to people that they expect to see in their transaction history (that is something that cannot be faked by the attacker). Even incoming transactions can be faked if the fake blockchain starts far enough in the past such that the parties that sent the victim the funds had not yet registered their account names on the blockchain (assuming the victim had not pinned the BTS public keys of their contacts in a wallet backup of course).

The trick is to know accounts of big market players like Walmart. If you don't see transactions made by Walmart then your branch is not legit.

Hmm well that isn't going to be exactly automated into the client code, but it is a smart idea for helping a user determine if the blockchain is fake if they suspect something suspicious (especially if their client warns them using other metrics). Okay, I think there are enough advantages provided by doing this that we absolutely should have transactions include a recent block hash in the transaction digest rather than just the chain ID.