Entering the second week of the Great Byteball Bot War as Christmas and New Years Eve usually requires people to spend time with their families and loved ones. Yet, our contestants are making great progress, and this week we had 2 progress reports. Due to the holidays, time has been a bit limited on the contest jury as well, so this update will be a bit short. But we will of course cover the two reports as well as award one of them with the 2GB award for best report of the week.

So without further delay, let's dive right in and take a look at the two reports.

The second progress report on the Q&A bot provides some really useful pointers that other developers might find highly relevant when starting to develop a bot. Particularly the time required to sync a full wallet and get a functioning pairing code for the bot to work are the two points that will definitely be useful to others.

The Byteball Slack once again proved a great place for developers to ask question and get quick replies. And after having cleared out a few mistakes, everything was up and running and actual development and testing could commense.

While waiting for the main net headless wallet to synch, exploring the ease at which bots can be developed and realizing it basically only takes a bit of front-end development skills with JavaScript to get something rather fast is a super relevant point. When developing a bot and testing on the main net, it of course requires a couple of bytes for transactions, and we therefore urge @whoisterencelee to hit us up on slack and ask for some free bytes to use for testing. As little as a few MB will be plenty enough for hundreds of transactions during testing and be worth just pennies, so please hit us up on the Slack and we can arrange for some bytes to fly your way.

Having just entered the contest, this time not as the creator of the Byteball Market bot, but instead in an attempt to realize a use case requiring a new bot, pmiklos submitted his first report for the contest, describing a carpooling for Byteball users use case.

The idea is to allow an uber-like service to be available to Byteball users, where the ride fare is depited on a Smart Contract and only becomes available for the driver, once the GPS position of both the driver and the passenger is at the destination.

There has been previous suggestions about somehow using the GPS location of smart phones to resolve conditions on Smart Contracts, but since the position data is quite easily tampered with, so far it hasn't been viable to apply that solution. But for this particular use case, where both parties of the Smart Contract has to be at the same location it might actually work. The driver could fake his position to withdraw the funds, but it would also require the passenger to fake his locationm which he would have absolutely no incentive to do. That would cost him the ride fare without getting to the destination.

When they arrive at the destination, the passenger would now have the incentive to present a fake GPS position to avoid having the Smart Contract funds released to the driver. However, at this time, the passenger would be physically next to the driver in the car, and it is very unlikely the passenger would convince the driver of not getting paid.

So all in all, we believe that in this particular use case, relying on GPS positions would actually work just great, since the two parties are at the same place and both have incentives to not fake their positions.