| 9 May 2018 |
|  nlcnlc joined the room. | 21:41:11 |
|  Cable joined the room. | 21:51:58 |
|  Peter - ooo joined the room. | 22:23:58 |
|  Jack (DONT USE, use @jack:web3.foundation) joined the room. | 23:02:13 |
|  null_radix joined the room. | 23:31:51 |
| 10 May 2018 |
 lockehart | What have I signed up for... 😳 | 01:10:16 |
|  peterhe joined the room. | 03:42:03 |
|  jd-01 joined the room. | 14:07:35 |
| 13 May 2018 |
|  geleeroyale changed their profile picture. | 02:31:05 |
| geleeroyale removed their profile picture. | 02:33:24 |
| geleeroyale set a profile picture. | 02:34:00 |
|  v123456 joined the room. | 16:59:18 |
| 14 May 2018 |
| Jack (DONT USE, use @jack:web3.foundation) changed their display name from pimpindots to web3jack. | 15:23:48 |
| Jack (DONT USE, use @jack:web3.foundation) changed their display name from web3jack to web3jp. | 23:53:06 |
| 15 May 2018 |
 qaa | Hey everyone, does anyone know a strategy to perform timestamp validation in state channels? For instance, if there is an expiry timestamp for validity of a transaction. How can the timestamp be validated? | 13:23:24 |
 lefterisjp | you would rather use block numbers than timestamps I suppose. | 16:33:19 |
| qaa | I think my question was not clear. Let me give an example: Let's say I create an order in state channel and give it an expiry time. Another party B can take my order within expiry time. All using state channels. It's trivial on chain as block timestamp can be checked. Here party B should provide the timestamp which he can any value there's no way to validate that. The not so ideal strategy is thought about is require party A (me) to sign and acknowledge B's acceptance of my order. | 16:39:47 |
 abhuptani | You can query block time in UTC with a view function. There's some documentation that points to a +/- 15s unreliability, but we haven't run into that problem ourselves | 17:30:15 |
| qaa | abhuptani: Thanks for the response. Got your point. But here's where my conflict arises: So if I A wants to cancel an order, how would i do that without acknowledgement from B? If acknowledgement is required, a maclicious B can simply not give acknowledgement | 17:58:33 |
 kingflurkel | You would need Proof Of Time 🙂 | 18:03:58 |
| 16 May 2018 |
| abhuptani | @qaa | 21:56:41 |
| abhuptani | qaa: Oops. So if A is signing the order upon creation and B signs on taking, then that gives finality to the order. In other words, it seems like you're saying either A has to sign AFTER B takes the order, or agree to match the order no matter what.
You could build a cancel order mechanism which can be called by A prior to B signing the order, but to keep it fair you would have to make sure that timestamp on A's signed "cancellation" would be lower than that of B's signed "take order". It seems like you're worried that this cannot be enforced off-chain correct?
| 22:02:14 |
| abhuptani | This can be resolved with a fallback to a contract function in the event of a dispute. A and B will have nonced or timestamped state updates corresponding to making/cancelling/taking orders. In the ideal case, A can cancel an order and B can accept it, which can come with a double-signed update off-chain. In the event that B does not accept, A and B can call the contract function (paying gas) and submit each update for the contract to act as final adjudicator. In the vast majority of cases, the cost of gas to do this will encourage A and B to resolve off-chain, so you do not need to be too worried about increasing the cost of operating in the channel. | 22:06:12 |
| abhuptani | Does that help? | 22:07:09 |
| 17 May 2018 |
| qaa | Thank you for the explanation. Correct me if i understood it wrong, when A cancels the order, it's a double-signed or single-signed update? Either way, if it's double signed, there's a chance B doesn't accept. If it's single signed, there's no way to check the order or timestamp in case B takes the order even after it's cancelled (Since taking is only single signed). So in either case, how can the contract as adjudicator decide which is right? | 11:59:53 |
| 21 May 2018 |
 edwardt | In case people are interested, we've added Polkadot to the scaling spreadsheet! Can't remember if I announced that Diamond Drops (Eth sharding solution) was also added a few weeks back. Apologies if I didn't!
(I'm aware of a few other projects that would like to be added, apologies for the delay but it takes a bit of time to review the text before adding them.)
https://docs.google.com/spreadsheets/d/1BQ0bK_LhSQvxtvXryVoIcmxeKMuVJCq6oD0aS5_hpC8/edit#gid=0 | 08:19:52 |
| 29 May 2018 |
|  light changed their profile picture. | 06:51:32 |
| 26 Jun 2018 |
| Peter - ooo set a profile picture. | 10:01:18 |
| 27 Jun 2018 |
| nlcnlc changed their display name from snarks to nlcnlc . | 03:26:46 |
| 9 Jul 2018 |
|  jbaylina set a profile picture. | 10:24:35 |
