Author Topic: [BTS2.0] Concern about account id on blockchain instead of address  (Read 6017 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.

Offline theoretical

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.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline jamesc

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).
« Last Edit: June 14, 2015, 06:21:56 pm by jcalfee1 »




Offline bytemaster

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
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"
    ]
  ]
}

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
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.
Weibo:http://weibo.com/zhangweis

Offline svk

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.
Worker: dev.bitsharesblocks

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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 ..

Offline bytemaster

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. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline xiahui135

  • Sr. Member
  • ****
  • Posts: 496
    • View Profile
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.

Offline svk

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.
Worker: dev.bitsharesblocks

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
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.
Weibo:http://weibo.com/zhangweis