Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: giving up TITAN will make it easier to develop the client?  (Read 721 times)

Offline xiahui135

  • Sr. Member
  • ****
  • Posts: 496
    • View Profile
giving up TITAN will make it easier to develop the client?
« on: February 08, 2015, 01:19:23 PM »

TITAN is useless for me, and maybe for most of the  users. and It seems costs much in dev resource.
Infact I do not want to use TITAN, I just want to find my credit on the blockchain explorer without logging to the wallet client. It is hard and slow to open the client. And it almost can not be accomplished by many people with a normal computer.(I can not use the wallet until I increased the RAM from 4gb to 6gb, and installed a 64 bit system)
there is only several new users everyday now. if this keep to remain the situation, BTS will fail for sure. we should concentrate.  there is a vote in playtalk. though there is little votes, but all choose to not use TITAN. how do you think?

https://playtalk.org/index.php?topic=92.0
https://playtalk.org/index.php?topic=94.0

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11962
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: giving up TITAN will make it easier to develop the client?
« Reply #1 on: February 08, 2015, 01:31:30 PM »
IIRC titan will be optional in future releases .. you will be able to define for yourself if you want to receive titan transactions
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline jabbajabbaつ◕_◕つ

  • Hero Member
  • *****
  • Posts: 650
  • Watch Your Profanity!
    • View Profile
  • BTS: jabbajabba
  • Payrate: 666%
Re: giving up TITAN will make it easier to develop the client?
« Reply #2 on: February 08, 2015, 01:38:21 PM »
IIRC titan will be optional in future releases .. you will be able to define for yourself if you want to receive titan transactions
Yea that sounds a lot better than just removing it.
The client will get better and the lightwallet is already on the way.
I personally want to use it and hopefully the transactions will get fully untracable in the future.

Offline joele

  • Sr. Member
  • ****
  • Posts: 458
    • View Profile
    • Regarding Bitcoin
Re: giving up TITAN will make it easier to develop the client?
« Reply #3 on: February 08, 2015, 01:44:18 PM »
It's a feature that every cryptocoins want, now Bitshares has it why remove.
For general users a short name compare to long 36 chars is way better, beside general users don't care what is happening in technical inside, they just care the ease of use.

Offline jabbajabbaつ◕_◕つ

  • Hero Member
  • *****
  • Posts: 650
  • Watch Your Profanity!
    • View Profile
  • BTS: jabbajabba
  • Payrate: 666%
Re: giving up TITAN will make it easier to develop the client?
« Reply #4 on: February 08, 2015, 01:49:23 PM »
It's a feature that every cryptocoins want, now Bitshares has it why remove.
For general users a short name compare to long 36 chars is way better, beside general users don't care what is happening in technical inside, they just care the ease of use.
I think he is just talking about making account names in the transactions visible for everyone, not getting rid of the names.

Offline joele

  • Sr. Member
  • ****
  • Posts: 458
    • View Profile
    • Regarding Bitcoin
Re: giving up TITAN will make it easier to develop the client?
« Reply #5 on: February 08, 2015, 01:54:44 PM »
It's a feature that every cryptocoins want, now Bitshares has it why remove.
For general users a short name compare to long 36 chars is way better, beside general users don't care what is happening in technical inside, they just care the ease of use.
I think he is just talking about making account names in the transactions visible for everyone, not getting rid of the names.
Opps, yeah, my bad.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11962
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: giving up TITAN will make it easier to develop the client?
« Reply #6 on: February 08, 2015, 03:34:41 PM »
You can still use account names even without TITAN .. TITAN is just the bitshares name for stealth transactions ..
There is no need to use titan but a huge plus as a feature
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: giving up TITAN will make it easier to develop the client?
« Reply #7 on: February 08, 2015, 04:13:48 PM »
You can still use account names even without TITAN .. TITAN is just the bitshares name for stealth transactions ..
There is no need to use titan but a huge plus as a feature

As far as I as know, you could use everything that is typically associated with TITAN in non-TITAN transactions except that the receive address that can spend the balance isn't the address of a child public key of the account's active public key but rather the address of the account's active public key itself. That means you still should have encrypted memos, verified "from" accounts with plausible deniability for the sender, and yes, of course, sending transaction to human-readable account names.

All it really means is that by getting the easy ability to be notified of all transactions sent to you and the ability to recover all your balances from a light wallet without needing to scan the entire blockchain, you have to pay for it with your privacy. Specifically, everyone can see exactly how much money people have sent to your account, and thus know with certainty how much money you (or rather your account) hold at any time (this excludes balances that were sent to one of your accounts via TITAN, or balances that were sent to a manually generated address, such as for cold storage, which cannot with certainty be tied to your account because they could plausibly be a TITAN transaction to someone else).

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Re: giving up TITAN will make it easier to develop the client?
« Reply #8 on: February 08, 2015, 04:19:38 PM »
I think a good start would be to get rid of the TITAN name to make things simpler and more on point. Call it registered names and stealth transactions. You can have registered names without having to use stealth transactions, and you can also do stealth transactions without using a registered name. When sending to someone you'll either be sending to a registered name, or to an account key. When you've typed in the name or account key, you will then have the option of sending either a regular transaction or a stealth transaction. The stealth transaction should have a warning that tells people not to use it unless they understand how it works, and that only full nodes can see them.

Offline xiahui135

  • Sr. Member
  • ****
  • Posts: 496
    • View Profile
giving up TITAN will make it easier to develop the client?
« Reply #9 on: February 09, 2015, 01:19:39 AM »
The most important innovation is pegging. And we need concentrate on the key function. Things like the wallet, the pegging, the gateway are most important. I do not think we should do everything at once. We just need be quick on important things.
We do not need many innovation and function until we make some succeed. I feel it is to heavy for us now.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11962
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: giving up TITAN will make it easier to develop the client?
« Reply #10 on: February 09, 2015, 07:46:19 AM »
You can still use account names even without TITAN .. TITAN is just the bitshares name for stealth transactions ..
There is no need to use titan but a huge plus as a feature

As far as I as know, you could use everything that is typically associated with TITAN in non-TITAN transactions except that the receive address that can spend the balance isn't the address of a child public key of the account's active public key but rather the address of the account's active public key itself. That means you still should have encrypted memos, verified "from" accounts with plausible deniability for the sender, and yes, of course, sending transaction to human-readable account names.

All it really means is that by getting the easy ability to be notified of all transactions sent to you and the ability to recover all your balances from a light wallet without needing to scan the entire blockchain, you have to pay for it with your privacy. Specifically, everyone can see exactly how much money people have sent to your account, and thus know with certainty how much money you (or rather your account) hold at any time (this excludes balances that were sent to one of your accounts via TITAN, or balances that were sent to a manually generated address, such as for cold storage, which cannot with certainty be tied to your account because they could plausibly be a TITAN transaction to someone else).
yup .. that's why a BitShares-TreZor would only work for non-TITAN transactions/funds because the device itself is certainly not able to scan the blockchain transactions in a reasonable time
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

julian1

  • Guest
Re: giving up TITAN will make it easier to develop the client?
« Reply #11 on: February 09, 2015, 07:52:07 AM »
Is it not possible to use a Bloom filter, to enable querying full-nodes about titan transactions with addresses that would be of interest? That way the wallet would only need scan those transactions that are reported to it.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11962
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: giving up TITAN will make it easier to develop the client?
« Reply #12 on: February 09, 2015, 07:58:33 AM »
Is it not possible to use a Bloom filter, to enable querying full-nodes about titan transactions with addresses that would be of interest? That way the wallet would only need scan those transactions that are reported to it.
nop .. you have to try to decrypt every single transaction memo you can find and see if you succeed .. if so, it's your transaction, if not you can continue. So it would be required to have the memos and the private keys on the same system for decrypting
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: giving up TITAN will make it easier to develop the client?
« Reply #13 on: February 09, 2015, 10:29:26 AM »
Is it not possible to use a Bloom filter, to enable querying full-nodes about titan transactions with addresses that would be of interest? That way the wallet would only need scan those transactions that are reported to it.
nop .. you have to try to decrypt every single transaction memo you can find and see if you succeed .. if so, it's your transaction, if not you can continue. So it would be required to have the memos and the private keys on the same system for decrypting

I think there should be ways (with current blockchain features) to implement something like what julian1 is talking about. Here is my attempt at it (please correct me if you see mistakes in this design, particularly about the privacy conclusions):

You still have the 19 original bytes for the encrypted memo, actually make that 18 to put a special character at the end of the first encrypted 32 bytes to designate that is the end of the official memo text. The remaining 32 bytes of the memo will instead not be encrypted. Put a special character at the beginning of these 32 bytes to designate to anyone publicly looking that this is most likely special add-on information and not just encrypted data that is part of the memo, and then put another byte after that to specify the protocol, and specific version of the protocol, to follow for interpreting the rest of the memo data. This leave 30 bytes of data to work with.

The first 4 bytes will be an encrypted version of the recipient's registered account ID. It is encrypted by XORing the ID with the last 4 bytes of the hash of SECRET (which is calculated from EC multiplication of the one-time private key and the recipient's public key, or alternatively EC multiplication of the one-time public key and the recipient's private key). This means that if the recipient receives the one-time public key of the transaction along with these 4 bytes (called RECIPIENT_ID_ENCRYPTED_FOR_RECIPIENT), they will be able to find out whether the transaction was likely intended to them (with some false positive rate of course).

The next 4 bytes will be another encrypted version of the recipient's registered account ID (called RECIPIENT_ID_ENCRYPTED_FOR_SENDER). In this case it is encrypted for the sender. This is just an optional bonus feature to make recovering outgoing transaction histories easier for a user. It is encrypted by XORing the ID with the last 4 bytes of the hash of the one-time private key. This means that if the recipient suspects that a transaction was sent by them, they can scan through the indices sequentially to compute the hardened child keys of some well specified descendant of its account's owner private key, find the private key corresponding to the transaction's one-time public key (thus proving the outgoing transaction is one they created), using the hash of that private key to recover the decrypted recipient ID, look up that ID on the blockchain to get the active public key of the recipient at the time of the transaction, and then do EC multiplication of that public key and the one-time private key to calculate SECRET and thus decrypt the memo. Since the selection of one-time private keys to use in each subsequent outgoing transaction by that account can be derived from an incrementing index, and since all outgoing transactions by that account can be collected in order (just find all transactions spending balances that the account received through income transactions), it should be very fast to decrypt all the outgoing transactions.

The next 20 bytes are the last 20 bytes of a hash of a hash of a special common secret, called the OBSERVER_SECRET. Each registered account can optionally register an observer in its public account record (this can simply be the registered account ID and/or active key address of the observer specified in some field in the public JSON), which is what causes the sender to use the protocol I am describing in the first place. It is important for privacy for users to pick observers that many other users also pick (I imagine there would only be a handful of used observers who would probably also act as the light wallet servers). The sender does EC multiplication with one-time private key and the observer's active public key to get OBSERVER_SECRET. An observer scanning through the blockchain can pay special attention to transaction that seem to follow this protocol in their memo. They will calculate OBSERVER_SECRET (from EC multiplication of their active private key and the transaction's one-time public key) and compare the last 20 bytes of the hash of the hash of OBSERVER_SECRET to the appropriate 20 bytes in the memo transaction. If it is a match, they will then use OBSERVER_SECRET to decrypt the remaining 4 bytes in the memo field, which I will talk about next.

The remaining 4 bytes in the memo field are an encrypted version of 4 bytes called FILTER. They are encrypted by XORing FILTER with the last 4 bytes of the hash of OBSERVER_SECRET (so both the sender and the observer can encrypt/decrypt it). FILTER is split into two parts: the first part is a sequence of bits that communicate how many bits, N, will be used for the second part, and the second part is the last N bits of the hash of the transaction recipient's address. N can range anywhere from 0 to 31. Given a particular value of N, the first sequence of bits will consist of (31-N) ones followed by a single zero. This allows the observer to unambiguously determine from the 4 bytes what the value of N is as well as get the N last bits of the hash of the recipient's address. My guess is that at any given time, there will be wide consensus on what value of N to use. For example, if there are M registered accounts, it would probably be smart to use something like N = max(0, floor(log(M)/log(2)) - 3) to ensure an appropriate number of collisions for the sake of privacy. At the same time, it is not desirable to have too many collisions because that requires the recipient to scan through many more transactions that do not belong to them. The observer takes the transaction hashes/ID as well as the one-time public key and the RECIPIENT_ID_ENCRYPTED_FOR_SENDER of the transaction and stores it as a value in a database where FILTER is the key.

Now if a user wants to recover their transaction history using own their wallet master key, they will first send their account's address to their previous observers (which is recorded in the blockchain) along with proof that they are the holder of the account's private key so that the observer can provide even better privacy to their customers. By the way, if the observers disappear, the user is forced to do a full scan of the blockchain (at least for the periods in which the observers who have now disappeared/gone bankrupt/retired were registered for the account). In addition to the address, they also send the interval of N (for the FILTER) that they are interested in; this allows them to starts with large N and only work their way down to smaller N (which means more transactions to check) if the user thinks there are funds still missing or wants to be extra sure. The observer returns a list of tuples (transaction hash/id, one-time public key, RECIPIENT_ID_ENCRYPTED_FOR_SENDER). The user scans through the list and filters out the tuples that it knows cannot apply to them. For each of the remaining tuples, the recipient requests (through the transaction hash/id) the full transaction for the blockchain. The user can then filter any of these transaction that were actually false positives.

Furthermore, assuming everyone was consistent about the formula for N, it would be easy for the user to reduce the interval of N to minimize the number of extra (false positive) transactions without really compromising privacy. The user could also specify a time filter, in which the observer did not return any transactions that occurred outside a specified time window (the interval between last time the user polled for new transactions and the present time, for example). This would further reduce the number of extra transactions that need to be returned. However, if a user makes the time window too small centered around the time they know a transaction should arrive, then that compromises the user's privacy with respect to the observer (but fortunately not with respect to outside third parties), since the observer can assume of the possible accounts that map to a particular FILTER of a transaction, it is more likely that the accounts that actually asks to receive transactions that have that FILTER within a time close the transaction time are the true recipients of the transaction rather than those who make the request later. Also if the observer is also the same entity as the light wallet server (the entity that the user will be requesting the full transactions from anyway), then there isn't much gained in terms of privacy from the observer. But the point is that the user still has privacy from third-parties and also has plausible deniability with respect to the observer (meaning in theory the user could be requesting transactions that have nothing to do with them just for fun / increasing privacy).

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: giving up TITAN will make it easier to develop the client?
« Reply #14 on: February 09, 2015, 10:43:53 AM »
yup .. that's why a BitShares-TreZor would only work for non-TITAN transactions/funds because the device itself is certainly not able to scan the blockchain transactions in a reasonable time

I'm not all that interested in a Trezor like device for BitShares. I prefer using multisig and a security token. I explained how this could work here and a gave a description of typical UX flow for setting it up over here.

In fact, I think it would be really great if the security token was three devices in one: two flash drives and the security token. The device would have two three-position switches on it to toggle between various states. One of the switches would toggle between powering off the device, powering on the device in standard-drive-disabled mode, and powering on the device in standard-drive-enabled-rw mode (the mode it would usually be in). The second switch would toggle between the following three modes: boot-drive enabled read-only and firmware access to security token disabled (the mode it would usually be in); boot-drive enabled as read/write and firmware access to security token disabled; and, boot-drive enabled as read-only and firmware access to security token enabled.

If you wanted to install a new BitShares boot OS into the boot-drive, you would make sure the device was powered on and set it to the boot-drive enabled as read/write mode. Then you plug it into your computer and install the boot OS to the partition. Afterwards, you would switch it back to the boot-drive enabled read-only and firmware access to security token disabled mode (the mode it would normally be on).

If you wanted to change the secret stored on the security token, you would make sure the device was powered on (likely on the standard-drive-enabled-rw mode) and also on the "boot-drive enabled as read-only and firmware access to security token enabled" mode. Then you would use it to boot the computer off the device into the BitShares boot OS that would guide you through the process.

You could also use the device as a regular flash drive (using the read/write standard-drive and not the boot-drive) and as a means to carry transactions back and forth between online machine and offline machine.

Finally, as long as the device was powered on you would be able to press a button to display the current one-time code for the selected slot. Pressing that button would turn on the display and show the one-time code (as well as the slot number and an indicator of when the one-time code was going to change), and pressing it again would turn off the display (it would also turn off automatically after 1 minute). Another button would allow the user to toggle through the up to 10 slots (numbered 0 to 9) that each can store their own different secret and thus have their own one-time code.

This could be a very cheap small device with excellent battery life (it would recharge its internal battery by plugging it into the USB slot of a computer) that you can put on your key chain and carry with you everywhere you go.
« Last Edit: February 09, 2015, 10:50:56 AM by arhag »

 

Google+