BitShares Forum
Main => Technical Support => Topic started by: xeroc on June 17, 2014, 12:14:18 pm
-
This series of articles/posts is intended to be an extensible work considering parts of DPOS/BitShares technically. If you feel something is missing just tell me and I will add it.
The goal is to have an article we can use to construct a FAQ for a technical description of the ecosystem.
BitShares-Wiki: http://wiki.bitshares.org/index.php/TITAN
-
+5%
-
Studying... +5% +5%
-
OMG, this is the kind of stuff that should be on our website
+5% +5% +5%
-
OMG, this is the kind of stuff that should be on our website
+5% +5% +5%
+5% I have sent PM to Stan and Brian to request that. And we should have a new section for these articles, not in faq.
-
Fantastic very good doc/s +20%
-
The wiki is also a good place to put these, it is publicly editable:
https://github.com/BitShares/bitshares_toolkit/wiki
-
The wiki is also a good place to put these, it is publicly editable:
https://github.com/BitShares/bitshares_toolkit/wiki
Thanks .. gonna do that when I have the time
-
I edited the post to reflect that with the new protocol it does not require a 2-step process and thus the transfer is not reversible.
-
I edited the post to reflect that with the new protocol it does not require a 2-step process and thus the transfer is not reversible.
Wanted to ask about that, because I was unsure .. thx for the edit!
-
I edited the post to reflect that with the new protocol it does not require a 2-step process and thus the transfer is not reversible.
One more question: From my understanding we have instant confirmation (or maybe 30 sec) here .. is this true .. No real need to wait for 6 confirmations .. a single one must be sufficient?!?
-
I edited the post to reflect that with the new protocol it does not require a 2-step process and thus the transfer is not reversible.
One more question: From my understanding we have instant confirmation (or maybe 30 sec) here .. is this true .. No real need to wait for 6 confirmations .. a single one must be sufficient?!?
More confirmations means more certainty - just say "30 second block times"
-
I know about that .. but as we have delegates which confirm tx .... do we have an 'estimate' on how 'long' I need to wait?
-
I edited the post to reflect that with the new protocol it does not require a 2-step process and thus the transfer is not reversible.
One more question: From my understanding we have instant confirmation (or maybe 30 sec) here .. is this true .. No real need to wait for 6 confirmations .. a single one must be sufficient?!?
It shouldnt be sufficient because forks are still real possibility. But lets someone with more knowledge elaborate.
-
I edited the post to reflect that with the new protocol it does not require a 2-step process and thus the transfer is not reversible.
One more question: From my understanding we have instant confirmation (or maybe 30 sec) here .. is this true .. No real need to wait for 6 confirmations .. a single one must be sufficient?!?
It shouldnt be sufficient because forks are still real possibility. But lets someone with more knowledge elaborate.
Confirmation time is dynamic based upon the number of missed blocks. If no blocks have been missed recently then 1 confirmation is enough. For every block that is missed you add 2 confirmations to the requirement. Generally speaking 2 confirmations should be plenty (30 sec to 1 minute).
The real issue is that you don't want to require someone to be online to receive funds.
-
Confirmation time is dynamic based upon the number of missed blocks. If no blocks have been missed recently then 1 confirmation is enough. For every block that is missed you add 2 confirmations to the requirement. Generally speaking 2 confirmations should be plenty (30 sec to 1 minute).
Well, that's what I was thinking. Thanks for the confirmation
The real issue is that you don't want to require someone to be online to receive funds.
I don't get that! don't you need to check that the network sees the transaction, and check that the transaction is valid (in terms if signature and input)?
Why would one use crypto offline without the ability to verify?
-
Confirmation time is dynamic based upon the number of missed blocks. If no blocks have been missed recently then 1 confirmation is enough. For every block that is missed you add 2 confirmations to the requirement. Generally speaking 2 confirmations should be plenty (30 sec to 1 minute).
Well, that's what I was thinking. Thanks for the confirmation
The real issue is that you don't want to require someone to be online to receive funds.
I don't get that! don't you need to check that the network sees the transaction, and check that the transaction is valid (in terms if signature and input)?
Why would one use crypto offline without the ability to verify?
If I am out at dinner I still want you to be able to pay the invoice I sent you before I left for the day without having my computer on to handshake with you.
Not all transactions are 'immediate' or based upon complete lack of trust.
-
According to my understanding, under TITAN no one else has knowledge of the spendable balances linked to an address, except the private key owner. And to check your exact balance, you need to have a full copy of the blockchain and scan every TXs to find spendable balances.
Does this mean lite clients (SPV/blockchain.info wallet) are impossible under TITAN?
-
According to my understanding, under TITAN no one else has knowledge of the spendable balances linked to an address, except the private key owner. And to check your exact balance, you need to have a full copy of the blockchain and scan every TXs to find spendable balances.
Does this mean lite clients (SPV/blockchain.info wallet) are impossible under TITAN?
Correct, there is a plan to add "observer key" to give to semi-trusted server for this application
Sent from my SCH-I535 using Tapatalk
-
I have a question.
If I run two client with same account.
Each client wil create dynamic key and can not keep sync.
when client A get transaction which is create by client B from the block chain.
client A can't decrypt this transaction, can get nothing info from this?
this is very confuse. I have met this situation already.
I dump the private key, crate a new wallet, and import key again.
Here is what I can see. Should we need to handle this?
default (unlocked) >>> wallet_account_balance
alt:
0.009740 XTS
dorian:
0.029998 XTS
default (unlocked) >>> wallet_account_transaction_history
BLK.TRX TIMESTAMP FROM TO MEMO AMOUNT FEE ID
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
----
10092.1 2014-06-16T06:41:45 alt dorian hello 0.100000 XTS 0.000000 XTS f65a6b4d
10133.0 2014-06-16T06:58:45 UNKNOWN UNKNOWN 0.000000 XTS 0.000000 XTS ee5dd73a
10296.0 2014-06-16T08:05:00 clout alt 50.000000 XTS 0.000000 XTS e2c9cbc9
10339.0 2014-06-16T08:22:45 mauritso alt 10.000000 XTS 0.000000 XTS 37671f7e
10341.0 2014-06-16T08:23:15 mauritso alt 10.000000 LOVE 0.000000 XTS fe819ec6
10355.0 2014-06-16T08:30:45 betax alt 20.000000 XTS 0.000000 XTS 2ebd73be
10384.0 2014-06-16T08:42:15 betax alt 100,000.000000 HAP 0.000000 XTS 851d86be
10511.0 2014-06-16T09:32:15 spartako alt some love 100.000000 LOVE 0.000000 XTS 870cd6e6
12772.0 2014-06-16T23:37:15 alt dorian send LOVE 20.000000 LOVE 0.000000 XTS 35e018a8
12911.0 2014-06-17T00:20:45 alt alt create DREAM (Dream) 0.000000 XTS 0.000000 XTS a7f1c1fe
.....
13791.0 2014-06-17T05:28:30 UNKNOWN UNKNOWN 0.000000 XTS 0.000000 XTS da389b2e
17561.0 2014-06-18T02:10:30 delegate-alt alt fff 1.000000 DRINK 0.000000 XTS f26f33dd
17565.0 2014-06-18T02:11:30 UNKNOWN UNKNOWN 0.000000 XTS 0.000000 XTS ce9065bf
17565.1 2014-06-18T02:11:30 UNKNOWN UNKNOWN 0.000000 XTS 0.000000 XTS e2867fd0
17570.1 2014-06-18T02:13:00 UNKNOWN UNKNOWN 0.000000 XTS 0.000000 XTS 316df9d2
17570.2 2014-06-18T02:13:00 UNKNOWN UNKNOWN 0.000000 XTS 0.000000 XTS 48d51c58
17570.3 2014-06-18T02:13:00 UNKNOWN UNKNOWN 0.000000 XTS 0.000000 XTS f7188d13
17570.0 2014-06-18T02:13:00 UNKNOWN UNKNOWN 0.000000 XTS 0.000000 XTS 137264b5
17579.0 2014-06-18T02:16:15 UNKNOWN UNKNOWN 0.000000 XTS 0.000000 XTS 1d298173
.....
-
According to my understanding, under TITAN no one else has knowledge of the spendable balances linked to an address, except the private key owner. And to check your exact balance, you need to have a full copy of the blockchain and scan every TXs to find spendable balances.
Does this mean lite clients (SPV/blockchain.info wallet) are impossible under TITAN?
Correct, there is a plan to add "observer key" to give to semi-trusted server for this application
Sent from my SCH-I535 using Tapatalk
Great I just thought of that too.
I have a feeling that these delegate key, observer key thing bring us to a new level on par with the days that file system permissions are first introduced.
-
this thread is pinned and promises all you need to know but leads to a dead page on github. You should probably change that.
-
this thread is pinned and promises all you need to know but leads to a dead page on github. You should probably change that.
Oh yeha ... sorry about that ..
fixed to:
http://wiki.bitshares.org/index.php/TITAN
-
This sticky is old and outdated. There is a reason TiTAN was deactivated which has not been discussed in depth. The "I" in TITAN no longer stands for "Invisibly", it is "Immediately". Stealth addresses are (temporarily?) disabled, but no details have been provided on when they might return.
-
This sticky is old and outdated. There is a reason TiTAN was deactivated which has not been discussed in depth. The "I" in TITAN no longer stands for "Invisibly", it is "Immediately". Stealth addresses are (temporarily?) disabled, but no details have been provided on when they might return.
Technically they haven't been disabled yet. The light client will not support them. They will be re-enabled once we identify a viable privacy system.
-
Would you please elaborate to enlighten the audience, me included?
Which chunks of software have stealth and which do not, and when (what target version) will that change?
What I'm hearing is that stealth addresses are still the default in 0.51 of the toolkit but I don't know when (if) they're going away in 0.6, 0.7 ... 1.0 It is my understanding that all variations of BitShares code use the toolkit, with the possible exception that the light wallet only uses the client-side javascript library (but those clients talk to a server that must be using the same toolkit code the "heavy" wallets use).
Please elaborate as I'm hearing a mixed message. Perhaps knowing the above will help.
-
Would you please elaborate to enlighten the audience, me included?
Which chunks of software have stealth and which do not, and when (what target version) will that change?
What I'm hearing is that stealth addresses are still the default in 0.51 of the toolkit but I don't know when (if) they're going away in 0.6, 0.7 ... 1.0 It is my understanding that all variations of BitShares code use the toolkit, with the possible exception that the light wallet only uses the client-side javascript library (but those clients talk to a server that must be using the same toolkit code the "heavy" wallets use).
Please elaborate as I'm hearing a mixed message. Perhaps knowing the above will help.
I have been loath to disable stealth addresses in the full client because they do provide some value. That said, ease of use and performance are higher priorities than privacy right now.
My guess is we will not disable stealth addresses in the full client until after the light client has gained acceptance. So lets just say, "1.0" or later for now.
-
Will we still be able to use names instead of addresses without titan?
No privacy I realize.
-
Will we still be able to use names instead of addresses without titan?
No privacy I realize.
Yes
-
Thanks for the clarification. If this changes please let us know.It would be great if you would provide some advance notice by saying stealth will be disabled by default in the x.x.x release.
Any chance that when you do disable stealth addresses (to support the thin client / web wallet) you could leave them turned on for unregistered accounts? If a person is truly trying to be stealthy why use a registered account anyway?