Qora | POS | Assets | Names | Polls | Automated Transactions | Social Network

[olcaytu2005]

F.ci bter and poloniex. We need bittrex.

[1714030044]

1714030044

[1714030044]

1714030044

[Lorenzo]

poloniex has come a long way. funny because I thought they were the underdog, and so far to my knowledge they haven't had major issues.

They did have one major issue back in March 2014 when they were hacked (or more accurately, someone discovered a method to exploit a bug in their withdrawal mechanism) which saw them lose about 15% of their users' funds. They did eventually make all of this back though.

Few exchanges have had zero major security issues. Cryptsy is one of the luckier ones, although lots of people complain about withdrawal delays there. I think Bittrex is another one that hasn't suffered a major hack yet.

I know some people actually prefer to deal with exchanges that have been hacked in the past too. The idea is that they would have learned from the experience and strengthened their security practices. Personally, after witnessing what happened to Mt. Gox and Bter after their first hacking incidents, I think it's a stupid idea.

[CryptKeeper]

Very interesting! I'm trying to wrap my head around this. I see a potential security issue with the "refund timeouts". What if Alice post her tx just before the timeout elapses, resulting in Bob never get the chance to receive his BURST? Could you elaborate on that?

[Vrontis]

Very interesting! I'm trying to wrap my head around this. I see a potential security issue with the "refund timeouts". What if Alice post her tx just before the timeout elapses, resulting in Bob never get the chance to receive his BURST? Could you elaborate on that?

Bob's AT must have have less length (expiration) than Alice's AT.So in case Alice sends the TX with the key to Bob's AT just before the expiration, Bob will have time to send the key to Alice's AT afterwards.

[CryptKeeper]

Very interesting! I'm trying to wrap my head around this. I see a potential security issue with the "refund timeouts". What if Alice post her tx just before the timeout elapses, resulting in Bob never get the chance to receive his BURST? Could you elaborate on that?

Bob's AT must have have less length (expiration) than Alice's AT.So in case Alice sends the TX with the key to Bob's AT just before the expiration, Bob will have time to send the key to Alice's AT afterwards.

Can this be enforced by the AT code or must the trade participants agree on the timeouts?

[vbcs]

Very interesting! I'm trying to wrap my head around this. I see a potential security issue with the "refund timeouts". What if Alice post her tx just before the timeout elapses, resulting in Bob never get the chance to receive his BURST? Could you elaborate on that?

Bob's AT must have have less length (expiration) than Alice's AT.So in case Alice sends the TX with the key to Bob's AT just before the expiration, Bob will have time to send the key to Alice's AT afterwards.

Can this be enforced by the AT code or must the trade participants agree on the timeouts?

No it cannot be enforced by the AT code itself as the AT on one side is not aware of the other AT. When user A initiates the ACCT then user B can see the timeout and use a proper one when creating the response ACCT.

[CIYAM]

Can this be enforced by the AT code or must the trade participants agree on the timeouts?

The timeouts can be defaulted by the UI but of course you cannot prevent a user from changing the default.

This is why Bob and Alice must carefully check each others AT's before proceeding. I think we'll eventually create a tool for AT "verification" down the track in order to make it very easy to be sure you aren't being cheated by an incorrectly coded AT.

[favdesu]

news from BTER Support: "we are updating and configure the qora wallet. withdrawal and deposit will be effect. it is expected to finish in 1-2 days."

[CryptKeeper]

Can this be enforced by the AT code or must the trade participants agree on the timeouts?

The timeouts can be defaulted by the UI but of course you cannot prevent a user from changing the default.

This is why Bob and Alice must carefully check each others AT's before proceeding. I think we'll eventually create a tool for AT "verification" down the track in order to make it very easy to be sure you aren't being cheated by an incorrectly coded AT.

OK, I understand that if Alice's AT - which goes first - has a small timeout of 24 hrs and Bob's AT has a much greater timeout, say 72 hrs, not much can go wrong.
Could the timeouts somehow be part of the secret, so that none of the participants can be tamper with it?

[CIYAM]

OK, I understand that if Alice's AT - which goes first - has a small timeout of 24 hrs and Bob's AT has a much greater timeout, say 72 hrs, not much can go wrong.

Actually you haven't quite got it - Alice's timeout needs to be the longer one (as it is Alice that will be sending the "key" to Bob's AT first).

Could the timeouts somehow be part of the secret, so that none of the participants can be tamper with it?

I'm not sure how that could be achieved - the best approach IMO is that the hash of the ACCT AT code could be published and compared to (to prove that it is the code that you think it is without having to actually understand AT machine code) and that you check the timeout value before proceeding.

Assuming there is enough of a time gap then there is not much that can go wrong (unless Bob's internet dies after Alice sent the secret and he can't get it working until the refund expiry time for Alice happens).

[Lorenzo]

news from BTER Support: "we are updating and configure the qora wallet. withdrawal and deposit will be effect. it is expected to finish in 1-2 days."

Sweet!

I just checked Poloniex and it seems that they were able to fix whatever issues they had with their wallet. Only a few weeks ago, there was no way to buy, sell, or trade QORA. With both exchanges working again (or soon to be working again) and the recent news regarding ACCT integration, Qora is looking much healthier these days.

[CryptKeeper]

OK, I understand that if Alice's AT - which goes first - has a small timeout of 24 hrs and Bob's AT has a much greater timeout, say 72 hrs, not much can go wrong.

Actually you haven't quite got it - Alice's timeout needs to be the longer one (as it is Alice that will be sending the "key" to Bob's AT first).

I always fail when the chances are 50:50 ... 

Could the timeouts somehow be part of the secret, so that none of the participants can be tamper with it?

I'm not sure how that could be achieved - the best approach IMO is that the hash of the ACCT AT code could be published and compared to (to prove that it is the code that you think it is without having to actually understand AT machine code) and that you check the timeout value before proceeding.

Assuming there is enough of a time gap then there is not much that can go wrong (unless Bob's internet dies after Alice sent the secret and he can't get it working until the refund expiry time for Alice happens).

Couldn't you hard code reasonable timeout values into the AT code and publish the code's hash? So if everyone agrees on using the same AT code for ACCT, the timeout values would be common knowledge.

[mrvegad]

OK, I understand that if Alice's AT - which goes first - has a small timeout of 24 hrs and Bob's AT has a much greater timeout, say 72 hrs, not much can go wrong.

Actually you haven't quite got it - Alice's timeout needs to be the longer one (as it is Alice that will be sending the "key" to Bob's AT first).

Could the timeouts somehow be part of the secret, so that none of the participants can be tamper with it?

I'm not sure how that could be achieved - the best approach IMO is that the hash of the ACCT AT code could be published and compared to (to prove that it is the code that you think it is without having to actually understand AT machine code) and that you check the timeout value before proceeding.

Assuming there is enough of a time gap then there is not much that can go wrong (unless Bob's internet dies after Alice sent the secret and he can't get it working until the refund expiry time for Alice happens).

Can you have this has a pop up where the user has to click OK on the pop up to close it? Having some kind of reminder is better then nothing, might help cut down on mistakes.

[CIYAM]

It is possible to hard-code values into ATs but understand as the Initiator and Responder would need different values we'd have to have two ACCT ATs rather than just one (at the moment the code is the same regardless of which role).

The next main focus for the AT project is going to be UI so we will consider how we can make the workflow and UX better as we proceed.

[rlh]

Check out thr block explorer.  What's with the 0 tx blocks, with 50 Qora fees.  Is this a bug on the explorer, or is Qora being exploited?

[wizzardTim]

Check out thr block explorer.  What's with the 0 tx blocks, with 50 Qora fees.  Is this a bug on the explorer, or is Qora being exploited?

Quoting from slack:

http://qora.co.in/?q=AVMvpJxRpdHxxEHcmnibDt6nYC3cBe8oH5
this is the address of an Infinite Loop AT that make's the 50 :qora: block reward

you can extend it by sending funds to it


So it is a gift for forgers!

[rlh]

Ah, ok.  Nice!  I would have assumed there would have been a 0 Qora TX for such a thing.  I'll take a look in the code to try and figure this one out.

[bonipper]

It is possible to hard-code values into ATs but understand as the Initiator and Responder would need different values we'd have to have two ACCT ATs rather than just one (at the moment the code is the same regardless of which role).

The next main focus for the AT project is going to be UI so we will consider how we can make the workflow and UX better as we proceed.

Have you considered testing your blockchain pruning concept on Qora?

[wizzardTim]

@all: let's upvote, for visibility. It's worth it!

https://www.reddit.com/r/Bitcoin/comments/36brps/worlds_first_atomic_crosschain_transfer_performed/


http://www.reddit.com/r/CryptoCurrency/comments/36bao4/worlds_first_atomic_crosschain_transfer_completed/

[CIYAM]

Have you considered testing your blockchain pruning concept on Qora?

I am not sure exactly what you are referring to - but in regards to blockchain pruning ATs could be removed provided that they have become inactive (we are likely to further formalise this down the track).