samedi, mai 01, 2021

World mapped crypto metaverse - managing diverging interests part II: Jerusalem / unresolved real world controversies

 This is  the 2nd blog post of a series about OVR, a virtual land different from other metaverses. It is different because it maps above the physical world and this has many implications due to human psychology.

There are many land conflicts in the real world which are called wars. Hopefully (or not?), they should be solved by contract in the crypto metaverses.

However some controversial sites, even if they exist in land nominally at peace, are controversial or highly controversial. Jerusalem is the most obvious one where 3 religions inerests and holy landmarks collide. While religion is always a big part of the controversies linked to these sites, history also always plays a role in the story.

Jerusalem holy sites area is "locked" today by OVR management, and this is good.

The answer to the question: Is total building freedom something that should be wished? is obviously a big NO!

Each site needs specific attention, policy & diplomacy, that will not apply to other controversial sites, but the subject can already be discussed.

Context

Usually, millenaries ago, a group of people assigned a specific meaning to a site and erected a landmark on it. Then centuries later, another group of invaders erected another landmark at the same place as a way to make visible their power & truth. 

But the original group didn't disappear and still hold the place as an important part of their culture today.

Discussion as a list of open questions

Who should decide what to build?

In the crypto metaverse, contractually, the owner decides what to build. 
Morally, the decision of what to do with the building should be a collective decision.

Should a vote be held? 

  • On what basis should the electoral college be built?
  • What would be the the place made for the minority?

Should there be a menu at the entry of the building enabling the visitor to see the building she wants?
Should there be alternative days or hours with different featured huildings?

  • With building ratios based on vote?

Let the local people decide?

  • Who are local people in a metaverse?
    • Surrounding lands owners?
    • Local physical world inhabitants?

Should the controversy be solved?

Why not leaving the site empty as a sign that crypto world acknowledges physical world issues and doesn't consider it can solve all issues?

Tentative list of controversial sites

Jerusalem, Hagia Sophia, Ayodhya, Yasukuni shrine, Hebron's cave of the Patriarchs.

mardi, avril 06, 2021

World mapped crypto metaverse - managing diverging interests part I: Macao / virtual local governance

 This is  the first blog post of a series about OVR a decentralized augmented reality world. OVR is fundamentally different from other metaverses in that it maps above the physical world and this has many implications.

OVR is still in its infancy and there are a whole lot of unanswered questions and possible solutions.

Open OVR questions

When exploring lands with OVR interface, rivers, roads and buildings plus road can be seen with their real-world names. This throws up some interesting questions:

  • What is the freedom that will be left to owners to build an environment? 
  • Can someone buying all hexagons across the fifth avenue, build a wall and be able to block traffic?
  • Can an owner build a virtual building outside the boundaries defined in the hex in the real world?
  • Is total building freedom something that should be encouraged or forbidden?

This post was written early in my discovery of augmented reality and I now better grasp what could be the answers: there are no definite answers.

Exploring answers

  • What is the freedom that will be left to owners to build an environment? 
    • If we look at what is happening in Decentraland, there is total freedom inside the hex up to a certain height. Having many contiguous hexes increase allowed height. 
    • But Decentraland is a VR world while OVR is an AR world.
  • Can someone buying all hexes across the 5th avenue, build a wall and be able to block traffic?
  • Can an owner build a building outside the boundaries defined in the hex in the real world?
    • Let's suppose that this is the case... Regarding walls, it's possible to teleport anyway. Regarding whatever you want in your hex: we're in digital world. As long as it doesn't promote hatred or unlawful digital attitudes, it should be fine.
  • Is total building freedom something that should be wished?
    • If a bunch of hexes is alone in the wild, I guess it's OK.

But what about places where several stakeholders are involved with diverging interests?

From there, 2 different types of possible conflicts should be distinguished:
  • When deep cultural or string religious feelings are involved that will be addressed in a later post, i.e. jew religious landmarks, churches, mosques @ Jerusalem.
  • When some financial is at stake like a famous commercial street such as the fifth avenue in New York or Macao casinos.

Macao Casinos on Cotai

Why casinos in specific places have big potential on OVR

What is missing on Decentraland Casinos though? Some connection with the real world. this physical and emotional connection is brought by OVR with Las Vegas & Macao locations. 


Success of a place as Macao most probably needs some kind of governance in order to offer the visitor:
  • Unity, towards the same goal: gambling. I guess it's obvious and doesn't need any governance, but some sort of rules such as agreeing on not promoting internet sex is needed? 
  • Diversity (same as physical world where several casinos are installed).
  • Accessibility (move between different sites without constant teleportation)
How can this be achieved?
  • Another contract supported by another layer of ERC20 coin? 
  • Activate a new organisation on https://colony.io/?
  • Begin to organize Macao at "OVR land level" . "OVR land level" means use what is available and known today in OVR land.

Organize Macau at "OVR land level" in 4 steps.

  1. Make sure some streets with continuity allowing access to various lands without any walls. I built some of those streets in Macao : status- started
  2. Advertising for Macao: status - started with this post
    • In the real world, Macao,is far ahead of Las Vegas in terms of gambling revenue.
    • While in OVR the Las Vegas strip is almost already 90% owned, Macao land is still 95% available. 
  3. Buy lands in Las Vegas : status- started
    • to display advertising boards for Macao
    • to install one way teleportation machines to Macao

Casinos on OVR land are starting their history!

Given the OVR land management open questions. Let's be proactive to make sure that Macao consumer's experience is superior.









mercredi, février 20, 2019

ECC backdoors for dummies in 5 steps

It will be explained in the most simple and pragmatic way, what possible ECC backdoors look like and why choosing the right curve and the right prime number to build the cryptographic curve is important.

1st step: understand how ecc cryptography works

Read and meditate https://www.coindesk.com/math-behind-bitcoin/


2nd step: Understand graphically how a scalar multiplication looks like when choosing the right base point with a good prime number on a good curve 


We first takes a random base point (2,22) and scalar multiply from 1 to n until it reaches infinity or point (0,0), then we look for the next base point that was not part of previous loop and multiply it, and so on until there are no free untouched base points.

For [y2 = x3 + 0x + 7  Ordre 67  size 78] curve whatever base point you start with, the loop contains all points of the curve (plus(0,0)), Thus there is only one curve.

To decrypt some data, without knowing the key, using these parameters you have to do 78 tests.


3rd step: choose a wrong prime number on a good curve


We first takes a random base point (1,9) and scalr multiply from 1 to n until it reaches infinity or point (0,0), then we look for the next base point that was not part of previous loop (6,2) and multiply it, and so on until there are no free untouched base points.

For [y2 = x3 + 0x + 7  Ordre 73  size 63] curve, loop sizes are 8 or 4.  

To decrypt some data, without knowing the key, using these parameters you have to do only a maximum of 8 tests.

What makes the [y2 = x3 + 0x + 7  Ordre 73  size 63] curve a bad choice is that at least one base point is on the x axis here zero_base_points are (42,0), (44,0) & (60,0)

4th step: choose a wrong curve

Some curves do not show any prime number without any zero_base_points:

(y2 = x3 + 0x + 1,TreeSet())
(y2 = x3 + 0x + 2,TreeSet(13, 37, 67, 139, 379, 541))
(y2 = x3 + 0x + 3,TreeSet(7, 31, 43, 79, 163, 199, 223, 463))
(y2 = x3 + 0x + 4,TreeSet())
(y2 = x3 + 0x + 5,TreeSet(43, 73, 193, 223, 277, 307, 397, 433))
(y2 = x3 + 0x + 6,TreeSet(31, 199, 223, 271, 367))
(y2 = x3 + 0x + 7,TreeSet(67, 229, 241, 499))
(y2 = x3 + 0x + 8,TreeSet())


5th step: going further open points

https://www.coindesk.com/math-behind-bitcoin/
https://crypto.stackexchange.com/questions/44304/understanding-elliptic-curve-point-addition-over-a-finite-field
https://fr.wikipedia.org/wiki/Courbe_elliptiquehttps://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Point_addition

The code to draw these curves : https://github.com/emariacher/kebra/blob/master/elliptique_sbt/core/src/main/scala/FaisGaffeAuxBackDoors.scala

lundi, juin 24, 2013

How bitcoin may be already crumbling under its own success


The bitcoin community has recently discussed about government interference, but today, I want to discuss 2 mostly overlooked bitcoin news:
 * blockchain has reached a size of 8 Gb
 * transactions shall have, now, a minimum size

 These 2 events/news are closely related. Every transaction contributes to the 8Gb ledger size, and "they (the miners?)" want to limit the ledger size. This will be done by fighting transaction spam i.e. eliminating insignifiant exchanges and non-financial transactions such as those initiated by satoshidice.

Why is it needed to limit transactions when there are so few users?
Is limiting transactions today a sign that bitcoin will not scale well?

Some predict that bitcoin market capitalization will reach orders tens, hundred of billions or even trillions.
 * How many people will use bitcoins in a few years?
 * What will be, then, the size of the bitcoin ledger? Will it still be manageable? 

Most probably to keep the ledger at a computable size, transaction size will be limited to higher limits. People will be less able to use it, then, for day to day transactions, if the limit is set to 0.1 bitcoin (equivalent to 100$?) for instance.

Maybe are we going to need to use other currencies, for smaller amounts, such as litecoin sometimes deemed as "silver compared to bitcoin's gold"? If "open currencies" become mainstream, I guess in addition to gold and silver, copper, iron, lead and feather coins are going to be needed to be able to manage the huge number of transactions when half the planet is going to use these new currencies.

Today's amount of transfers is looking like ripples compared to tomorrow's tsunamis of transactions. If we consider bitcoin as the "Napster" of open currencies and expect future open currencies, answering to those questions, which I personnally find unsolved yet, is something essential.

Or ... did I miss something?
A few weeks ago, I understood that maybe oldest parts of the ledger will be dropped. When will that happen?

 Anyway the amount of transactions is already a problem because today  "they" feel they should limit the number of transactions.

vendredi, novembre 02, 2012

Managing dates with a DSL implemented in Scala

Following Paulo "JCranky" Siqueira's post who himself built it based on Sergio Lopes's post, I also enhanced this class by adding the ability to set dates and to compare them.

Another good link: Baysick: A Scala DSL Implementing BASIC



package kebra

import java.util.Calendar
import java.text.SimpleDateFormat
import java.text.ParsePosition

class DateDSL(val cal: Calendar) {
 cal.clear(Calendar.HOUR)
 import DateDSL.Conjunction
 
 def this(d: DateDSL) = this(d.cal)

 private var last = 0;

 def plus(num: Int) = { last = num; this }
 def minus(num: Int) = { last = -num; this }

 def +(num: Int) = plus(num)
 def -(num: Int) = minus(num)

 def months = { cal.add(Calendar.MONTH, last); this }
 def months(and: Conjunction): DateDSL = months
 def month = months
 def month(and: Conjunction): DateDSL = months

 def years = { cal.add(Calendar.YEAR, last); this }
 def years(and: Conjunction): DateDSL = years
 def year = years
 def year(and: Conjunction): DateDSL = years

 def days = { cal.add(Calendar.DAY_OF_MONTH, last); this }
 def days(and: Conjunction): DateDSL = days
 def day = days
 def day(and: Conjunction): DateDSL = days

 def is(then: Calendar) = {
  cal.setTimeInMillis(then.getTimeInMillis)
  cal.clear(Calendar.HOUR)
  this
 }

 def is(then: String) = {
  val cthen = ParseDate(then,"MM/dd/yyyy")
  cal.setTimeInMillis(cthen.getTimeInMillis)
  cal.clear(Calendar.HOUR)
  this
 }

 def ParseDate(s_date: String, s_format: String): Calendar = {
  var cal = Calendar.getInstance()
  cal.setTime(new SimpleDateFormat(s_format).parse(s_date, new ParsePosition(0)))
  cal
 }

 def before(d: DateDSL): Boolean = cal.before(d.cal)
 def after(d: DateDSL): Boolean = cal.after(d.cal)

 override def toString = new String(new SimpleDateFormat("ddMMMyy").format(cal.getTime()))
}

object DateDSL {
 class Conjunction
 val and = new Conjunction

 def Today = new DateDSL(Calendar.getInstance)
 def Tomorrow = Today + 1 day
 def Yesterday = Today - 1 day

 def today = Today
 def tomorrow = Tomorrow
 def yesterday = Yesterday

 def Now = Today
 def now = Today
}
I also added a testcase below:
package kebra

import java.util.Calendar
import java.text.SimpleDateFormat
import kebra.DateDSL._


object TestKebra extends App {

 println("Hello World!")
 println(Tomorrow minus 1 month and plus 10 years and plus 1 day)
 println(Today + 2 months and plus 9 years and minus 1 day)
 println(Today - 9 years and minus 1 day)
 println(((Today + 2 months and) + 9 years and) - 1 day)
 println(now is "10/1/2011" plus 3 days)
 println("\n"+printZisday((now is "10/1/2011" plus 3 days).cal,"ddMMMyy"))
 assert(printZisday((now is "10/1/2011" plus 3 days).cal,"MM/dd/yyyy").indexOf("10/04/2011")==0)
 assert((now is "10/1/2011" plus 3 days).before(now is "10/1/2011" plus 4 days))
 assert((now is "10/1/2011" plus 4 days).after(now is "10/2/2011" plus 2 days))
 
 val zendDate = new DateDSL(now is "2/2/2011")
 var ago = new DateDSL(now is "2/2/2011" minus (9*7) days)
 println("***** ago: "+ago+", zendDate: "+zendDate)
 while(ago.before(zendDate)) {
  println("      ago: "+ago)
  ago plus 7 days
 }
 println("***** ago: "+ago+", zendDate: "+zendDate)
 assert((ago plus 1 day).after(zendDate))
 println("***** ago: "+ago+", zendDate: "+zendDate)
 assert((ago minus 2 days).before(zendDate))
 println("***** ago: "+ago+", zendDate: "+zendDate)
 
 def printZisday(zisday:  Calendar, fmt: String): String = new String(new SimpleDateFormat(fmt).format(zisday.getTime()))
}