Author Topic: giving up TITAN will make it easier to develop the client?  (Read 4447 times)

0 Members and 1 Guest are viewing this topic.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I like the idea that accounts can specify if they want to be sent titan or regular. If the update is rolled out simultaneously with the light wallet then there should be nothing wrong with interpreting blank as = titan.

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
It'll be an additional field in the public_data json of EACH account on the blockchain that will DEFAULT to "non-TITAN". Though you can set it to "TITAN" if you prefer to ..

Actually, I would like some clarification about this from the devs. New accounts registered with new clients will likely specify the account to either be a public_account or titan_account. Light wallets will automatically specify it to be a public_account, since without mail support they wouldn't be able to receive funds otherwise. And of course any account can change these parameters for their account in the future.

But will accounts registered with the full client also default to public_account, or will they still default to titan_account?

Furthermore, what about all the accounts already registered that do not have either public_account or titan_account set? The new client will have to interpret these accounts as one or the other. So does it interpret such an account with no specification given as public_account or a titan_account?

My preference would be that a blank is interpreted as a titan_account, and that the full client default to a titan_account for any newly registered accounts unless otherwise specified. I would also prefer to allow all clients (both light wallets and full clients) to override the preferences of the receiver for a particular transaction and force the transaction to be treated as if the receiver is a public_account. This could allow users to publicly pay another account even if the recipient is set to be a titan_account, which can provide transparency and accountability. For example, I could have a titan_account with some amount of funds held in public balances (balances spendable by the address of my account's public active key) and I can create a transaction that transfers funds from those public balances via a non-TITAN transaction to another titan_account. Thus, everyone could look at the blockchain and verify that account A spent X BitUSD of their money to account B.

I think these are valid concerns and should be addressed.  You have a good suggestion and I hope to see some feedback too.
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline xiahui135

  • Sr. Member
  • ****
  • Posts: 496
    • View Profile
It'll be an additional field in the public_data json of EACH account on the blockchain that will DEFAULT to "non-TITAN". Though you can set it to "TITAN" if you prefer to ..

Actually, I would like some clarification about this from the devs. New accounts registered with new clients will likely specify the account to either be a public_account or titan_account. Light wallets will automatically specify it to be a public_account, since without mail support they wouldn't be able to receive funds otherwise. And of course any account can change these parameters for their account in the future.

But will accounts registered with the full client also default to public_account, or will they still default to titan_account?

Furthermore, what about all the accounts already registered that do not have either public_account or titan_account set? The new client will have to interpret these accounts as one or the other. So does it interpret such an account with no specification given as public_account or a titan_account?

My preference would be that a blank is interpreted as a titan_account, and that the full client default to a titan_account for any newly registered accounts unless otherwise specified. I would also prefer to allow all clients (both light wallets and full clients) to override the preferences of the receiver for a particular transaction and force the transaction to be treated as if the receiver is a public_account. This could allow users to publicly pay another account even if the recipient is set to be a titan_account, which can provide transparency and accountability. For example, I could have a titan_account with some amount of funds held in public balances (balances spendable by the address of my account's public active key) and I can create a transaction that transfers funds from those public balances via a non-TITAN transaction to another titan_account. Thus, everyone could look at the blockchain and verify that account A spent X BitUSD of their money to account B.
just think if it will simplify the system. if it does, do it. if not, just do not do it.I do not think it is wise to add additional complex to the system.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
It'll be an additional field in the public_data json of EACH account on the blockchain that will DEFAULT to "non-TITAN". Though you can set it to "TITAN" if you prefer to ..

Actually, I would like some clarification about this from the devs. New accounts registered with new clients will likely specify the account to either be a public_account or titan_account. Light wallets will automatically specify it to be a public_account, since without mail support they wouldn't be able to receive funds otherwise. And of course any account can change these parameters for their account in the future.

But will accounts registered with the full client also default to public_account, or will they still default to titan_account?

Furthermore, what about all the accounts already registered that do not have either public_account or titan_account set? The new client will have to interpret these accounts as one or the other. So does it interpret such an account with no specification given as public_account or a titan_account?

My preference would be that a blank is interpreted as a titan_account, and that the full client default to a titan_account for any newly registered accounts unless otherwise specified. I would also prefer to allow all clients (both light wallets and full clients) to override the preferences of the receiver for a particular transaction and force the transaction to be treated as if the receiver is a public_account. This could allow users to publicly pay another account even if the recipient is set to be a titan_account, which can provide transparency and accountability. For example, I could have a titan_account with some amount of funds held in public balances (balances spendable by the address of my account's public active key) and I can create a transaction that transfers funds from those public balances via a non-TITAN transaction to another titan_account. Thus, everyone could look at the blockchain and verify that account A spent X BitUSD of their money to account B.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
However all that is easy to ask for in hindsight, just like knowing that all the raised funds should have been instantly dumped for fiat. At this point the important thing is that titan is getting disabled by default and that we're getting light wallets and web wallets with trading relatively soon.
That is not totally correct. You cannot "disable" TITAN as it is a client-side feature. But from what I have read, TITAN - as implemented in the client atm - will read the recipient's recommendations of whether she want's TITAN or non-TITAN transactions.
It'll be an additional field in the public_data json of EACH account on the blockchain that will DEFAULT to "non-TITAN". Though you can set it to "TITAN" if you prefer to ..

So, saying that TITAN will be *disabled* is not only wrong but also a drawback marketing-wise as it is a nice-to-have feature .. though certainly not as a default behavior ..
Does this make sense to you?

Quote
In fact nathan hourt light wallet is coming out today?
Hu? Haven't read about that .. would be a nice surprise 8)

Offline Rune

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

This is totally true and in hindsight implementing TITAN from the beginning was probably an error similar to brian page. If bitshares had been DPOS + market pegged assets and then just used traditional bitcoin public keys from the beginning development would probably have been a lot faster, and things like trading in the light wallet would have been easier. Then registered names could have been added on top of the public key system after a couple of months (when the faucet came online), and then far into the future when anonymity becomes a real concern due to higher scrutiny stealth addresses or ring signature mixing could have been added.

However all that is easy to ask for in hindsight, just like knowing that all the raised funds should have been instantly dumped for fiat. At this point the important thing is that titan is getting disabled by default and that we're getting light wallets and web wallets with trading relatively soon.

In fact nathan hourt light wallet is coming out today?

Offline arhag

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

Offline arhag

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

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

julian1

  • Guest
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: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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

Offline xiahui135

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

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
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 arhag

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

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