My goal was to be in the top 98% of chess players at chess.com (meaning that 2% plays better than me, or uses an engine 🙂 ). I’ve reached that goal for both Blitz as well as Daily chess, see below:
An extended version of our drivers paper has been accepted at Concurrency and Computation: Practice and Experience, Wiley, 2020.
In this extended version we evaluate three more use cases. These analysis suggests that, similar to our previous paper, blockchain may not be the best technological choice. As such, choosing blockchain as a technology in these use cases seems like an irrational choice.
Our drivers may explain the rationality behind this seemingly irrational choice.
In a recent study that I did on blockchain use cases, I found that most use cases focus on addressing a particular use case problem with blockchain. However, what consistently was lacking was a discussion of potential threats that are introduced when applying blockchain. From an empirical perspective, I also find that in practice blockchain advocates tend to focus on addressing the use case problem with blockchain, and the threats of blockchain are usually not mentioned.
Personally, I’m a huge fan of blockchain and distributed ledger technology. However, I believe these technologies should be applied where necessary; these technologies should not be applied where possible. Applying these technologies where it could be applied may introduce unnecessary threats.
In this white paper we survey potential organizational threats for use cases that adopt blockchain. We grouped the 22 threats in two categories, 1. Threats caused by human behavior, and 2. Threats caused by blockchain. Our survey complements the existing work on security and privacy threats of blockchain. These surveys can be used for the identification of blockchain risks in use case that (plan to) adopt blockchain.
Here’s a game I played with the black pieces (online) which show the importance of activity of one’s pieces, or, the consequences when there is a major lack of piece activity. In short, I sacrificed material to severely limit the activity of my opponent’s knight, bishop and rook. In the end, it all payed off, as almost all of his pieces were immobilized.
After Bb3 the idea of trapping the bishop came to mind. But first finishing development.
Here we go. Sacrificing a pawn to immobilize the white squared bishop.
But now white’s entire Queen side becomes passive. Look at the knight on b1, it literally can’t go anywhere. The dark-squared bishop on c1 and the rook on a1 are not active either. Ideally, I want a black knight on a4, a black pawn on e4, and a black knight on d3, and those white pieces will be burried alive.
Nc5 immediately may have been better as a4 is white’s freeing move.
And that’s black rook for a white knight. However, that knight (and white’s Queen) are its only active pieces.
See my comment at move 13. Mission accomplished. I’m down in material (2 points), but white simply can’t use his Queen-side forces (11 points).
White resigned. None of his pieces (except for the king) can move.
Today (21-10-2019) I was challenged to a game of chess with the black pieces. Nothing special, as it happens 50% of the time. However, in this case I was blindfolded (literally) and the game was timed (9 minutes per person for the whole game).
My opponent told me his moves, and I told him mine. He moved both the white and black pieces, and handled the clock for both sides (pretty fair ;-)).
Here is how the game went:
- e4 c6
- Nf3 d5
- Nc3 Bg4
- Be2 e6
- 0-0 Nf6
- d4 dxe4
- Ne5 Bxe2
- Qxe2 Qxd4
- Bf4 Be7
- Rad1 Qb4 – The Silicon Monster even likes white position. White has a lead in development, and the black king will be stuck in the center.
- Rb1 too passive. 0-0
- f3 -trying to complicate matters, but now the position is lost. exf3
- Rxf3 Nbd7
- Nxd7 Nxd7
- Rh3 Bc5+ (I missed Qxf4, winning the bishop.)
- Be3 Rad8
- Qh5 Bxe3+
- Kh1 Bh6
- Re1 Nf6
- Qe2 Bd2
- Rf1 Bxc3
- bxc3 Qe7
- Rxf6 Qxf6 – 1 minute on the clock!
- Qh5 Qg6 – Missed a mated in one 🙂 Qf1++ Time pressure and being blindfolded don’t mix well.
- Qd1 A final trick Rxd1++ Black sees it, it’s just mate.
Not too bad. Next time, two boards blindfolded!
Yes! Two more goals achieved. Single digit body fat (8%) and finished a photo-shoot.
After months of following a strict diet, cardio at 05:30 in the morning, and fitness training 5 times a week I was ready for the gruesome last week of photo-shoot prepping. Dropping caloric intake to max 1700 kcal (which used to be 5500 kcal max at some point last year) and very low in carbohydrates, this became a mental challenge due to the complete lack of energy.
The cheat meal the evening before the shoot was divine.
Thanks to Kenneth Nwosu who is an awesome photographer. He is able to make you feel more relaxed during the shoot, provides great advice, and the results are incredible. Follow Kenneth or have a look at his collection on instagram, twitter, or his website.
Thanks to everyone else who supported me during these last few weeks. Photos are available upon request.
Prepping for the shoot was a great experience, one I wouldn’t recommend to anyone 🙂
I’m happy because a third paper has been accepted for my PhD. A fourth is under review and two more are currently being written.
The accepted paper (my own version can be found here which is an improved version of this paper) is on Assessing Interoperability Solutions for Distributed Ledgers and will be published in Elsevier’s Journal Pervasive and Mobile Computing.
Now and then I play a quick game of chess against on my mobile phone. We all know that computers are much better at the game nowadays. I’m impressed by the way modern chess computers play, and here’s another example. However, now and then I manage to beat the computer (AI Factory), which has an estimated elo rating of around 2000. Here’s a nice example of me winning a chess game against a computer at max level, within 20 moves:
“][Date “2019.04.11”][White “U”][Black “Cpu (12)”][PlyCount “37”][Result “1-0”]
1. e4 c5 2. Nf3 e6 3. d4 a6 4. d5 exd5 5. exd5 d6 6. c4 Bf5 7. Nc3 Nd7 8. Bd3 Ne7 9. O-O g6 10. Re1 Bxd3 11. Qxd3 Bg7 12. Bf4 Nb6 13. Ne4 Nb6c8 14. Bg5 O-O 15. Bf6 b5 16. Bxg7 Kxg7 17. Qc3+ Kh6 18. Nf3g5
On Monday, March 24 2019, I became a member of the 1000-pound club.
Bench: 242 (110 kilo), Squat: 352 (160 kilo), Deadlift: 407 (185 kilo).
Doing sports helps me to stay fit and healthy, in particular when having a busy life (family, work, doing a PhD, teaching, etc.). Setting goals helps me to focus. Reaching the 1000-pound was one of such goals. It was fun to achieve this goal, although sometimes hard and frustrating (e.g. lacking 11 pounds (5 kilo) while giving all you’ve got).
Happy to see to have inspired others to follow and achieve the same goal. Who’s next?
Interestingly, my 1000-pound stats resemble that of Hugh Jackman.
Now all I need is a t-shirt.
Although distributed ledgers gradually become and accepted technology, there currently are some challenges that need to be solved. As nearly all current ledgers are siloed, one of those challenges is interoperability between ledgers. Interoperability, from a broad perspective, allows two different, separate ledgers to work with each other.
The need for interoperability is shown by the many initiatives that aim to achieve interoperability between distributed ledgers. Indeed, several solutions have been proposed and an initial classification of these solutions was proposed by Vitalik Buterin here.
However, it is not always clear which properties these solutions have, nor which particular issues exist in such solutions. This makes it hard to decide which solution to choose. Even more, some consequences of interoperability may be an argument for not interoperating with other ledgers.
In this (extended) paper we assess interoperability solutions for distributed ledgers. We propose 12 key properties with which we can distinguish between interoperability solutions in three ways.
First, we can distinguish between three kinds of interoperability solutions, being notary schemes, relay schemes, and hash-locking schemes. Second, these properties allow us to distinguish between subcategories of these kinds of solutions. And third, we can distinguish between generic and specific issues of these kinds of solutions.
Furthermore, by using these properties, we describe and analyze five real world solutions, being Polkadot, Cosmos, BTCRelay, Dogethereum and hashlocking schemes in general.
We discuss in detail the zone-spend attack. This attacks considers two interoperating ledgers, and under the assumption that one ledger uses a probabilistic consensus algorithm, we conclude that there exist a risk of creating an immutable, invalid state between the two ledgers, even if one of the ledgers uses a deterministic consensus algorithm. Note that no interoperability solution can mitigate this risk.
Finally we evaluate these 5 solutions and discuss several interoperability issues. We conclude that although the three kinds of solutions offer different functionalities, there exists an overlap of issues between these kinds of solutions. This is useful for deciding which interoperability solution to choose, and becoming aware of the current issues that come with each solution.
Our paper can be found here and feedback is, of course, welcome.