#UTF8# Especificaciones Protocolo Trueque 1.0 ESPECIFICACIONES PROTOCOLO TRUEQUE 1.0
Una propuesta para informáticos y economistas.



1.- Introducción
2.- Cuentas de trueque
3.- Consideraciones generales sobre el protocolo informático
4.- Archivo trueque.xml
5.- Protocolo de transferencias
6.- IBU1000: ¿Como se crean los trueques?
7.- Estadísticas públicas obligatorias
8.- Protocolo de búsqueda de cuentas IBU1000
9.- Fraude multicuenta e id_fraude
10.- Lucha contra la inflación
11.- Conclusiones





1.- Introducción

Este documento es una propuesta abierta y libre para establecer un protocolo formal de 
comunicaciones entre “Bancos de Trueque Online”. Un banco de trueque online es un ordenador 
mantenido por una o varias personas, que contiene una serie de cuentas de usuarios. 

Los usuarios acceden a su banco via web o desde el teléfono movil y el banco les permite 
hacer operaciones económicas (transferencias, pagos, cobros, etc) en una moneda virtual 
llamada trueque o ibu.

El trueque o ibu se crea como Ingreso Básico Universal de forma igualitaria, descentralizada, 
constante, nominal, universal y en forma de dinero tiempo-persona. Consideramos la posibilidad 
de que cualquier persona pueda recibir su Ingreso (o Renta) Básico Universal, como un 
derecho universal para TODOS.

Este protocolo permite a todo el mundo saber cuantos ibus hay en circulación en todo momento, 
que bancos los han creado y cuando, así como garantiza que todo el mundo tenga acceso a esta 
nueva economia de forma igual, libre y responsable, y simultáneamente garantiza el derecho a 
la intimidad de todas las personas implicadas en el sistema de trueque.


“A medida que sigo dándole vueltas al tema del trueque, voy viendo que la mejor solución, 
la mas sencilla y las mas versátil es establecer un protocolo mínimo entre bancos (o servidores) 
de trueque, de forma que cualquiera pueda desarrollar software (con cualquier sistema operativo, 
lenguaje, tipo de servidor, etc) para montar un banco de trueque que pueda comunicarse 
fácilmente con otros bancos de trueque para hacerse transferencias entre si, independientemente 
de la plataforma utilizada en cada caso.

Esto es complementario y no excluyente con el hecho de desarrollar nosotros mismos nuestro 
propio software servidor de banco de trueque con el sistema tprx-inidos.

Los diferentes bancos de trueque pueden evolucionar de forma distinta en el tiempo (algunos 
generar dinero como renta básica, otros simplemente no crear dinero en absoluto pero si mantener 
cuentas y aceptar transferencias, otros crear el dinero de otras formas diferentes, etc), pero 
a la vez mantener un mínimo de "funcionalidades comunes" si el protocolo básico está 
bien establecido.”

(Extracto de un email de Alejandro Bonet a Pedro Barrio en Octubre de 2011)


Así que aquí va un primer borrador del protocolo, para someter a discusión pública.

Este documento está orientado a informáticos, y es la conclusión de una recopilación de 
discusiones entre Pedro Barrio, Miguel Gonzalez, Oscar Garcia Colombo, yo (Alejandro Bonet) y 
otros.

2.- Cuentas de trueque
Definimos una cuenta de trueque como una cadena de caracteres (string) que tiene la siguiente 
forma:

cuenta$dominio.ext

Donde:

cuenta: Es el nombre de la cuenta local en el banco de trueques de que se trate.

dominio.ext: Es el nombre de dominio del banco de trueques que aloja y gestiona la cuenta.

Este string es único a nivel de toda la internet para una cuenta de trueques concreta, de 
forma que no puede haber dos cuentas con el mismo nombre en toda la red internet.

Se parece a una cuenta de correo eléctrónico (email), pero en lugar de usar el signo 
arroba (@) para separar usuario y dominio, usa el signo dólar ($), que existe en todos los 
teclados del mundo y sugiere “una cierta relación con el dinero”.

Lo que haya delante del signo dolar (la cuenta o usuario) puede ser cualquier cosa, según la 
política de administración de cuentas de cada banco de trueques particular. Por ejemplo, puede 
haber bancos de trueque que usen el nombre del usuario como nombre de cuenta, y sus cuentas 
serían de la forma:

         pepito_grillo$bancotrueque.com
         alberto$trinke.org

Otros pueden usar el email del usuario como nombre de cuenta:

         pepe@yahoo.es$bancotrueque.com
         manolo@gmail.com$trinke.com

Y otros simplemente numerar las cuentas de forma consecutiva o arbitraria:

         534576$trinke.com
         cuenta2345$trinke.com

No es necesario ni obligatorio que un usuario dado de alta en un banco de trueques tenga una 
sola cuenta, puede tener varias y el banco será quien asigne los nombres diferentes de cuentas 
para este usuario.

Tampoco es necesario ni obligatorio que una cuenta pueda ser manejada por un único usuario, 
de forma que varios usuarios pueden tener acceso a una misma cuenta concreta, (para consultas 
solo, o con capacidad de hacer movimientos) según la política del banco de trueques concreto.

Los nombres de cuentas de trueque son información pública: Se pueden divulgar sin miedo, 
siempre que cada uno tenga el control de como se puede operar con ellas, y evite por ejemplo 
que alguien saque trueques de ellas sin permiso.

La política general de cada banco de trueques es totalmente libre, en relación a como se usan 
las cuentas, quienes tienen acceso y que tipo de acceso, y sobre si admiten retiradas de 
terceros desconocidos o no, según su propio criterio.

3.- Consideraciones generales sobre el protocolo informático
Los servidores de banco de trueque llevan una cuenta (o varias) por cada email de usuario. 
Consideran un usuario único como uno (o varios) email. Tienen disponible públicamente un 
archivo de nombre trueque.xml con los datos de configuración para establecer 
relaciones con ellos por parte de otros servidores de banco de trueque, y llevan un registro 
histórico de cada transacción, así como los extractos de cada cuenta.

Se comunican con los usuarios por medio de http o https con resultado en HTML,
y con otros bancos de trueque por medio de http o https con resultado en XML.

Deben disponer al menos de dos servicios básicos: 

Servicio Transfer: Que permite realizar transferencias entre cuentas de trueque.

Servicio Estadis: Que permite obtener (al público u otros servidores) estadísticas 
del estado del banco sin ninguna clase de datos de carácter personal.

Y un tercer servicio opcional:

Servicio Buscador IBU: Que permite buscar rápidamente que banco se encarga
de crear la IBU1000 (Ingreso Básico Universal de 1000 trueques al mes) para un email dado.

Las solicitudes siempre son por método GET y llevan los nombres de los parámetros indicados 
en este protocolo siempre en minúsculas.

Las respuestas en XML siempre llevan un dato por línea y con los nombres de las variables 
de respuesta en minúsculas.

Todos los tokens (constantes alfanuméricas fijas que significan cosas diferentes) deberán 
siempre ir en mayúsculas tanto en las solicitudes como en las respuestas.

4.- Archivo trueque.xml
Puesto que los posibles softwares de bancos de trueque pueden implementarse sobre múltiples 
plataformas informáticas, hace falta que cada cual sepa como comunicarse con otros, 
independientemente del sistema utilizado por cada cual.

En este sentido, la forma mas fácil de que un servidor reconozca a otros sin problemas, es 
la norma 1:

NORMA 1: Todo servidor de banco de trueque debe hacer publico un archivo con el 
nombre trueque.xml que contenga los datos necesarios para que cualquier otro servidor de 
trueque sepa como comunicarse con el.

Este archivo trueque.xml debe tener las siguientes variables como mínimo:

TABLA 1: Variables obligatorias en trueque.xml
Variable Ejemplo Explicación
version_trueque 1.0 Versión del protocolo de trueque soportada
dominio bancotrueque.com Nombre de dominio del servidor
fecha_inicio 20110823 Fecha de inicio de actividad del servidor
modo_creacion_dinero NINGUNO Modo de creacion de dinero
url_transfer https://www.bancotrueque.com/transfer.transfer? URL del servicio para hacer una transferencia
url_estadis https://www.bancotrueque.com/estadis.estad? URL para consulta de estadisticas publicas


Estas variables (que son las que definen el protocolo de trueque versión 1.0 
y son necesarias en todo servidor de banco de trueque), pueden ser ampliadas a otras diferentes 
que se vayan creando con el tiempo, y definen el perfil básico del banco de trueque.


Deben estar disponibles en un archivo trueque.xml con estructura XML, en el que el orden de 
disposición de las mismas es irrelevante.

Las indicadas son obligatorias, pero pueden ser complementadas con estas otras, que son solo 
recomendadas (las tres ultimas si son obligatorias para los servidores que creen dinero en modo 
IBU1000):



TABLA 2: Variables recomendadas en trueque.xml
Variable Ejemplo Explicación
email_admin admin@bancotrueque.com Email de contacto administrador
pais España Pais donde opera
telefonos 341-8977654 Telefonos de contacto
nombre_admin Pepito Grillo Nombre del administrador
software_trueque EcoTrueque 1.9 Nombre del software que usa este banco
url_buscador https://www.bancotrueque.com/buscador? URL del servicio buscador de emails
ibu1000_inimail aaaa Prefijo de inicio del buscador de emails
ibu1000_finmail azzz Prefijo de fin del buscador de emails


Ejemplo de archivo trueque.xml:


<trueque>
<dominio>bancotrueque.com</dominio>
<version_trueque>1.0</version_trueque>
<software_trueque>ecotrueque 1.9</software_trueque>
<fecha_inicio>20110823</fecha_inicio>
<modo_creacion_dinero>IBU1000</modo_creacion_dinero>
<url_transfer>https://www.bancotrueque.com/transfer.transfer?</url_transfer>
<url_estadis>https://www.bancotrueque.com/estadis.estadis?</url_estadis>
<url_buscador>https://www.bancotrueque.com/buscador.busca?</url_buscador>
<ibu1000_inimail>aaaa</ibu1000_inimail>
<ibu1000_finmail>azzz</ibu1000_finmail>
</trueque>


Para simplificar el tratamiento de este archivo en diferentes lenguajes, se recomienda que, al 
menos las variables obligatorias, estén contenidas en lineas separadas y cada variable en una y
 solo en una linea.







5.- Protocolo de transferencias

El protocolo de transferencias entre cuentas de trueque alojadas en diferentes bancos de trueque, 
debe hacerse por http o https (esto lo indica cada servidor en su trueque.xml, en la variable 
url_transfer), siempre con metodo GET, y con los siguientes parámetros indicados en la propia URL:

TABLA 3: Variables obligatorias en solicitud de transferencia
Variable Ejemplo Explicación
modo TRANSFER Modo de la transferencia (TRANSFER, RECIBO, TEST, etc)
reloj 20110823143512 Fecha y hora de la transferencia en formato AAAAMMDDHHMMSS (opcional)
orig pepito$grillo.com Cuenta de origen de la transferencia
dest maromo$fuerza.com Cuenta de destino de la transferencia
idorig AGHJGJH3447687 ID unico de la transferencia segun el banco origen (opcional, maximo 20 caracteres)
iddest 7987987985465 ID unico de la transferencia segun el banco destino (opcional, maximo 20 caracteres)
importe 27.50 Importe de la transferencia (siempre positivo y con dos decimales)
concepto Pago factura 234 Texto descriptivo para los usuarios implicados
El modo por defecto es el modo TRANSFER, que indica que la 
transferencia esta solicitada por el usuario de la cuenta de origen, e incluye un idorig.

Otro modo posible es el modo RECIBO, que indica que la transferencia está solicitada por el usuario 
de la cuenta de destino, e incluye un iddest.

Los diferentes servidores de banco de trueque implementarán estos dos modos según su propio 
criterio, y devolverán un texto XML con el resultado de la transferencia, incluyendo de forma 
obligatoria todos los siguientes datos, la mayoría de los cuales son copia de la propia solicitud:

Los idorig e iddest identifican la operación de forma única en ambos lados. 

El idorig lo asigna el banco de origen y el iddest el banco destino. Ambos pueden llevar números o 
letras, pero no espacios, acentos, tabuladores o saltos de linea. Tampoco pueden llevar ningún 
carácter no imprimible de código ASCII menor o igual que 32 (espacio) ni mayor de 128 (acentos, 
eñes, etc).

La mejor manera de implementar los idorig e iddest es con un contador decimal o hexadecimal y 
nunca deben superar los 20 caracteres.

TABLA 4: Variables obligatorias en respuesta a solicitud de transferencia
Variable Valor de ejemplo Explicación
resultado OK Código de resultado de la transferencia (ver tabla 5)
modo TRANSFER Modo de la transferencia (TRANSFER, RECIBO, TEST, etc)
reloj 20110823143512 Fecha y hora de la transferencia en formato AAAAMMDDHHMMSS (obligatorio)
orig pepito$grillo.com Cuenta de origen de la transferencia
dest maromo$fuerza.com Cuenta de destino de la transferencia
idorig AGHJGJH3447687 ID único de la transferencia segun el banco origen (obligatorio, maximo 20 caracteres)
iddest 7987987985465 ID único de la transferencia segun el banco destino (obligatorio, maximo 20 caracteres)
importe 27.50 Importe de la transferencia (siempre positivo, con separador punto y con dos decimales)
concepto Pago factura 234 Texto descriptivo para los usuarios implicados (Maximo 100 caracteres)




El caso mas frecuente de resultado será OK, que indica que la transferencia ha sido aceptada por 
el banco al que se le hizo la solicitud, e implica obligatoriamente la NORMA 2:

NORMA 2 (o norma de PEROGRULLO): En una transferencia con resultado OK, es 
obligatorio que el banco origen descuente el importe de la cuenta del usuario origen, y el 
banco destino aumente el importe en la cuenta del usuario destino.

Otros posibles códigos de resultado (todos ellos erróneos excepto el primero y ninguno de ellos 
afecta a los saldos de las cuentas implicadas) están reflejados en la siguiente tabla:



TABLA 5: Códigos de resultado en respuesta a solicitud de transferencia
Código Explicación
OK Todo correcto. Cuentas actualizadas en ambos lados.
PTE_USUARIO Pendiente de confirmar por usuario origen (RECIBO)
ANULADO Anulado o no confirmado por usuario origen (RECIBO)
ERROR_PROTO Error de protocolo: La solicitud no es correcta
ERROR_BORIG El banco de origen no se reconoce o no se admite
ERROR_BDEST El banco de destino no se reconoce o no se admite
ERROR_ORIG La cuenta de origen es incorrecta
ERROR_DEST La cuenta de destino es incorrecta
ERROR_IDORIG El idorig es incorrecto
ERROR_IDDEST El iddest es incorrecto
ERROR_SALDO La cuenta origen no tiene saldo suficiente
ERROR_IMPORTE Importe incorrecto según política
ERROR_SATURA El servidor esta saturado y no puede gestionarlo ahora

Por ejemplo: Un banco decide enviar 2589909.65 trueques desde una 
cuenta propia, a otra cuenta en el banco de destino trinke.com. Hace su solicitud en modo 
TRANSFER, pero el banco de destino no confia en el de origen, o le parece excesivo el importe, y 
le responde con un ERROR_BORIG, o con un ERROR_IMPORTE, y a otra cosa mariposa.

Es potestad de ambos bancos, el tratar este evento como les de la gana a cada cual.

Uno puede registrarlo en un archivo log de errores, otro puede olvidarlo, etc.

Sin embargo, si el banco destino responde OK, se supone que ambos bancos archivan la 
transferencia (con todos sus datos, fundamentalmente los idorig e iddest) en su diario de 
movimientos y a la vez, actualizan las cuentas implicadas.

En cualquier momento, cualquiera de los dos bancos puede hacer una solicitud al otro con 
el modo TEST, y los datos idorig e iddest, y el otro deberá responder con la misma respuesta 
que se dio en la transferencia real. 

Este modo TEST, sirve por tanto para medir la confianza que se puede tener en otro banco, y 
cada banco puede aplicar sus propias reglas para aceptar o no transferencias de otros bancos, 
en función de la confianza que le merece cada cual. 

Cada banco por tanto, según opere, tendrá su propio karma, (sea esto lo que cada
cual entienda que es), que afectara a sus operaciones futuras con otros bancos según el criterio 
de cada cual.

En principio la regla básica del karma podría ser: "Si tu no recuerdas lo que has hecho en el 
pasado, entonces mi confianza en ti disminuye".

Estas solicitudes TEST, es conveniente hacerlas de forma aleatoria y en momentos de bajo tráfico, 
con el fin de no entorpecer los flujos de datos naturales: Pensemos que un servidor de trueques 
no solo sirve peticiones a otros bancos, sino que genera peticiones a otros bancos y además 
atiende a sus clientes todo a la vez.

Las peticiones de transferencia son síncronas: El banco "cliente" (el que origina la petición, sea el 
de la cuenta origen o destino), conecta con el banco "servidor" (sea este el origen o el destino), 
y espera un timeout prudencial (digamos 30 segundos máximo) a que este conteste una respuesta 
válida. 

En caso de no poder conectar o no recibir una respuesta válida, es potestad del banco "cliente" 
(en el sentido comunicacional) decidir que hacer: Reintentar mas tarde, olvidar la transacción, 
devolver error al usuario, o lo que mejor le parezca.

En todo caso, no se admite que una petición no quede resuelta (con OK o con cualquier ERROR) 
en un marco de timeout razonablemente corto (unos pocos segundos).

Este es el significado de "transferencias síncronas": Ocurren y se resuelven en un breve espacio 
de tiempo, y si no es así, entonces no son válidas.

En el caso de que un banco "servidor" este muy ocupado con una cola de peticiones grandes y 
no pueda atender en este momento al banco "cliente", puede devolver un ERROR_SATURA, 
o simplemente no devolver nada, con lo cual el "cliente" puede hacer TEST posteriormente sobre 
la transferencia un determinado numero de veces, con una periodicidad de algunos minutos 
entre peticiones, hasta recibir una respuesta definitiva, sea OK o ERROR.



En fin... Aquí va un ejemplo de transferencia correcta:

Petición:

http://www.trinke.com/transfer?modo=TRANSFER&orig=pepito$grillo.com&dest=maromo$fuerza.com&importe=23.45&idorig=AGHJGJH3447687&concepto=Pago+Factura+234

Respuesta:


<trueque>
<resultado>OK</resultado>
<modo>TRANSFER</modo>
<reloj>20110823143512<reloj>
<orig>pepito$grillo.com</orig>
<dest>maromo$fuerza.com</dest>
<idorig>AGHJGJH3447687</idorig>
<iddest>7987987985465</iddest>
<importe>23.45</importe>
<concepto>Pago factura 234</concepto>
</trueque>







6.- IBU100: ¿Como se crean los trueques?


En principio y hasta ahora, el protocolo de transferencias no implica en 
modo alguno, ni sabe nada en absoluto, sobre cual es el método de creación de los trueques.

En principio, puede haber bancos de trueque que no creen trueques en absoluto.

Por ejemplo: Un banco dispone de algún tipo de sistema de mercadillo en el que los usuarios 
promueven sus productos y servicios, o sus cachivaches de segunda mano que quieren vender, 
y a cambio reciben trueques de otros usuarios. En este caso, el banco debe indicar en su archivo 
trueque.xml el dato modo_creación_dinero con el token NINGUNO.

En este caso, que es el mas limpio y puro posible, el banco no crea trueques en absoluto, y por 
tanto tiene una confianza (por parte de otros bancos de trueque) bastante alta, siempre que 
responda bien a las solicitudes TEST.

Otros bancos pueden crear los trueques como dinero-deuda (es así como funcionan los bancos 
tradicionales), de forma que prestan a los usuarios una serie de trueques concretos y los ingresan 
directamente en sus cuentas, creándolos de la nada. 

En este caso, el servicio de estadísticas del banco en cuestión, deberá indicar públicamente 
cuanto dinero ha creado y a ser posible disponer de algún texto explicativo y convincente de cual 
es el método de creación de dinero que usa. El token para este tipo de creación de dinero debe ser 
DEUDA, e incluir una variable adicional en trueque.xml con el nombre: url_metodo_dinero que 
indique la dirección del texto explicativo sobre cual es el criterio de creación de dinero de este banco.

Otros bancos de trueque pueden confiar en este banco o no, y aceptar transferencias desde/hasta 
este banco o no, según les parezca oportuno.

Un tercer caso, seria el de un banco de trueque que esta basado en monedas tradicionales como 
el euro, la peseta, el dolar o el maravedí añejo vinculante, de forma que los usuarios ingresan 
X euros en alguna cuenta tradicional, el banco lo confirma y le agrega los trueques correspondientes 
en su cuenta de trueques, según el tipo de cambio que considere oportuno.

En este caso el token de modo_creación_dinero seria CAMBIO, y también debe haber una variable 
url_metodo_dinero que apunte al correspondiente documento explicativo.

Por último (solo de momento, pues pueden surgir nuevas formas de crear dinero desconocidas 
hasta ahora) el cuarto caso es el de creación de dinero como tiempo-persona según un Ingreso 
Basico Universal de 1000 trueques (o ibus) al mes por cada usuario único.

Este modo es el que recomendamos desde aquí. La razón del valor concreto “1000” es que es 
aproximadamente el PIB mundial percápita en dolares. También es facilmente divisible (en base 10), 
y facil de recordar. De esta forma un ibu (o trueque) vale lo mismo que un euro o un dólar, 
aproximadamente.

En resumen este método significa creación de dinero constante, igualitaria, nominal y con ratio 
fijo por persona y tiempo. Puede conllevar inflación o no (depende de como evolucione), y forma 
parte de una teoría económica novedosa, que se viene discutiendo desde hace décadas en foros 
de economistas muy variados a lo largo y ancho del globo, desde innumerables puntos de vista.

El token asociado es modo_creacion_dinero IBU1000



El IBU1000 implica varias responsabilidades (normas) para el banco de trueque:

NORMA IBU1000 1: El banco solo generara dinero de forma nominal en las cuentas 
de los usuarios personales. Las cuentas de organizaciones, clubs, empresas, asociaciones, etc, 
no tienen derecho a percibir dinero creado como IBU1000.

NORMA IBU1000 2: El banco se hace responsable de garantizar que ningún usuario 
personal cobra mas de un IBU1000, tanto en sus propias cuentas locales, como en ninguna otra 
cuenta de la red de bancos de trueque. Para ello, deberá informar a la red de bancos de trueque, 
de forma pública, de que este banco es el que crea el IBU1000 para dicho usuario (ver protocolo 
de búsqueda de emails).

NORMA IBU1000 3: Los bancos deben admitir, tras una solicitud del usuario, el 
traspaso de la IBU1000 del usuario, a otro banco cualquiera que soporte IBU1000 en el que el 
usuario tenga otra cuenta. Es decir: Cada usuario puede siempre decidir que banco de trueques 
es el que va a crear su IBU1000

NORMA IBU1000 4: El banco el día uno de cada mes, creara un ingreso de 1000 
trueques en la cuenta de cada usuario con derecho a percibir el IBU1000

NORMA IBU1000 5: Para recibir la IBU1000, los usuarios deben haber hecho un 
mínimo de 5 movimientos en su cuenta a lo largo del mes anterior (esto evita creación de IBU1000 
en cuentas desatendidas, o de usuarios fallecidos).

NORMA IBU1000 6: El banco cancelará la IBU1000 de cualquier usuario que considere 
sospechoso de fraude: Uno puede crearse 25 emails y 25 cuentas y solicitar la IBU1000 en 25 
bancos distintos, pero esto es considerado fraude.

NORMA IBU1000 7 (O norma del karma) El principio de creación de dinero como 
tiempo-persona es ampliamente reconocido como un sistema de creación de dinero mas justo y 
sensato que muchos otros. Este sistema está basado en la firme creencia de que el mayor valor 
que hay en el mundo es el tiempo de las personas vivas, hagan estas con su tiempo lo que hagan. 
El banco debe ser responsable de garantizar que la justicia impere en cada creación de IBU1000, 
y que se respete este principio.

Y NORMA 8 (o norma del usuario austero) 
cualquier usuario PUEDE DESTRUIR trueques propios 
cuando lo considere oportuno. Solo tiene que solicitar a su banco su deseo de que desaparezcan 
esos trueques de su cuenta y de la red. Esta destrucción junto con la creación vía IBU1000  son 
las únicas formas de que aparezcan o desaparezcan trueques en la red de bancos IBU1000.




El token de una operación de creación de dinero (sea IBU1000 o de cualquier otro modo), será 
CREADO. Y debe llevar su dest y su iddest correspondientes en los registros del banco que cree 
el dinero, aunque no tenga orig, ni idorig.

El token de una operación de destrucción de dinero (que solo lo puede hacer el dueño del mismo) 
será DESTRUIDO. Ciertamente es mejor donarlo a una ONG, pero si hay gente que considera 
que “hay demasiada inflación y demasiado dinero en circulación”, siempre puede hacerse el 
harakiri libremente, destruyendo su propio dinero.

Conviene por tanto (y esto no tiene nada que ver con el protocolo en si, sino que es una sugerencia 
de implementación del software), que el banco guarde el token de modo para cada transferencia, 
recibo, destrucción o creación de dinero de cada operación, tanto en el extracto de la cuenta del 
usuario, como en el diario general del banco.











7.- Estadísticas públicas obligatorias

Un banco de trueques sensato y razonable, esta obligado a varias cosas:

- Publicar su archivo trueque.xml para facilitar la comunicación con otros bancos de trueque.

- Llevar un registro histórico de movimientos con sus idorig e iddest respectivos.

- Tener al día los extractos de las cuentas y servirlos rápidamente a sus usuarios.

- Responder a solicitudes TEST razonablemente (puede por ejemplo responder a todas, vengan de 
donde vengan, o solo a las de los bancos implicados en las transacciones concretas).

- Explicar claramente cual es su procedimiento de creación de dinero en caso de que cree dinero 
a partir de la nada.

- Perseguir por todos los medios el fraude de posibles usuarios que pretendan recibir la IBU1000 
mas de una vez (si es el caso).

- Trasferir la creación de la IBU1000 de un usuario a otro banco si este lo solicita y el usuario lo 
confirma.

- Medir constantemente el karma (sea esto lo que cada cual entienda) de los demás bancos y 
usuarios con los que se relaciona.

- Disponer de un servicio de estadísticas públicas que reflejen su estado e historial en todo momento.

Respecto de esto último (el servicio de estadísticas públicas) vamos a establecer algunas cosas 
en este capítulo.

Lo primero es entender que las estadísticas de un banco, jamás deben llevar datos personales 
asociados. Solo los usuarios tienen derecho a ver sus propios movimientos de sus propias cuentas. 
Una cuenta puede tener varios usuarios que operen con ella (en este caso, la cuenta no debe 
percibir la IBU1000, porque no es una cuenta personal), pero nadie mas que los usuarios con 
permisos adecuados, debe poder ver los movimientos u operar en dicha cuenta. 

Por supuesto, el administrador o administradores del banco concreto, pueden ver todos los 
movimientos de todas las cuentas, pero no deben operar sobre ellas mas que en los casos 
que corresponda: Cuando reciban solicitudes de transferencia de otros bancos, o cuando creen 
dinero de la nada según su propio criterio (que insistimos, debe ser público y publicado).

En ningún caso un administrador de un banco de trueques debe realizar operaciones extrañas 
o diferentes a estas indicadas. Si un usuario nota algún movimiento extraño en su cuenta, 
siempre puede transferir su saldo a otra cuenta en cualquier otro banco de trueques y, si es el 
caso, solicitar que el banco transfiera su IBU1000 al otro banco.

Esto en cuanto a reglas básicas de "operación sensata y honesta" por parte de los bancos de 
trueque y los usuarios.

Por otro lado, el banco tiene su "imagen pública" que debe mantener "limpia".

Para ello debe tener un servicio de estadísticas públicamente accesible, que indique su estado 
actual y su historial de movimientos en el tiempo.

Este historial de movimientos típicamente se devolverá en HTML (con los colorines y aspecto 
que cada banco prefiera) y deberá incluir para cada dia desde la puesta en marcha del banco 
(fecha indicada en la variable fecha_inicio del archivo trueque.xml) los siguientes datos:


TABLA 5: Datos a devolver ante una peticion estadistica
Dato Ejemplo Explicación
Modo DIA El modo de la consulta
Fecha 20110224 Fecha de la estadística
Saldo 234768723.23 Suma total del saldo de todas las cuentas en esa fecha (a las 23:59 horas)
Creado 0.00 Importe total creado en esa fecha
Destruido 0.00 Importe total destruido por los usuarios austeros
Enviado 1123456.23 Importe total enviado a otros bancos en esa fecha
Recibido 876834.89 Importe total recibido de otros bancos en esa fecha
Incremento -246621.34 Creado+Recibido-Enviado (puede ser negativo)
NTotalCuentas 1756 Numero total de cuentas existentes
NCuentasAbiertas 13 Nuevas cuentas abiertas ese dia
NCuentasCerradas 0 Cuentas cerradas ese dia
IncrementoCuentas 13 Cambio ese dia en el NumeroCuentas (puede ser negativo)
NTotalOperaciones 5670 Numero total de operaciones realizadas ese dia
NOpTRANSFER 4356 Numero de operaciones TRANSFER
NOpRECIBO 997 Numero de operaciones RECIBO
NOpCREADO 0 Numero de operaciones CREADO
NOpTEST 317 Numero de operaciones TEST
Adicionalmente, para los bancos que tengan modo_creacion_dinero 
IBU1000, serán obligatorios los siguientes datos:

TABLA 6: Datos a devolver ante una peticion estadistica para un banco IBU1000
Dato Ejemplo Explicación
CuentasIBU1000 1230 Numero total de cuentas con derecho a IBU1000
IBU1000Abiertas 8 Nuevas cuentas IBU1000 abiertas ese dia
IBU1000Transferidas 2 Cuentas cuyo derecho IBU1000 fue transferido a otro banco (no implica cierre de cuenta)
Es evidente, a la vista de estos datos, que en caso de "maquillar" 
estos datos manualmente, un administrador de un banco de trueques puede cometer errores que 
una máquina no cometería jamás, ya que los propios datos deben ser coherentes. Los datos son 
absolutamente independientes de los usuarios, y solo reflejan el "estado del banco de trueques 
en un día concreto".

Puesto que estos datos deben ser públicos, y el banco esta obligado a entregarlos a cualquiera 
que los solicite para cualquier fecha posterior a la fecha de inicio de operaciones del banco, 
cualquier otro banco o persona puede asignar a este banco "el karma que considere oportuno". 
Si un banco maquilla los datos flagrantemente, su karma colectivo decrecerá en cuanto un 
suficiente número de otros bancos o personas detecten estos "maquillajes incoherentes".

Para entregar estos datos, se sugiere (no es normativo) que se entreguen en html con los 
nombres de datos indicados. Aunque cualquier banco puede hacer su propia recopilación 
de datos y publicarlos con el formato que prefiera, siempre y cuando contengan todas estas 
informaciones indicadas.

Un banco que no entregue estos datos a cualquier persona o banco de la red que lo solicite, 
de forma completamente transparente y pública, "no es un banco de trueques serio y confiable".

Para solicitar estos datos a un banco de truques, el solicitante debe usar la url_estadis que el 
banco indica en su archivo trueque.xml, agregando dos parámetros después del signo 
interrogación:



TABLA 7: Parámetros de consulta estadística
Parámetro Ejemplo Explicación
modo DIA Indica que se requieren los datos de un DIA, MES o ANO
fecha 20110823 Indica el 23 de Agosto de 2011
Algunos ejemplos de solicitudes estadísticas:

Consultar los datos del día 20110823:

http://www.bancotrueque.com/estadis.estadis?modo=DIA&fecha=20110823

Consultar los datos del mes 201108:

http://www.bancotrueque.com/estadis.estadis?modo=MES&fecha=201108

Consultar los datos del año 2011:

http://www.bancotrueque.com/estadis.estadis?modo=ANO&fecha=2011

Solo es obligatorio para los bancos de trueque responder a los datos de un día concreto, pero es 
recomendable que también se respondan las consultas de MES y ANO completas.

En el caso de consultas MES y ANO, la respuesta debe incluir las variables de la consulta, junto 
a una tabla en la que cada línea indica un día y cada columna un dato.

La forma mas sencilla de incluir esta información es en formato tabla CSV (Comma Separated 
Values = Valores Separados por Comas), en la que la primera linea indica los nombres de las 
columnas, y el resto de las filas indica cada una un dia concreto.


Ejemplo:


<trueque>
<modo>MES</modo>
<dominio>trinke.com</dominio>
<fecha>201108</fecha>
<csv>
Fecha,Creado,Enviado,Recibido,Saldo,Incremento,NTotalCuentas,NCuentasAbiertas,NCuentasCerradas,IncrementoCuentas,NTotalOperaciones,NOpTRANSFER,NOpRECIBO,NOpCREADO,NOpTEST
20110801,23023.00,234534.45,  Etc...
20110802,562789.00,98009.45,  Etc...
Etc...
</csv>
</trueque>


Los nombres de los datos no son normativos, pero si altamente recomendados por esta 
especificación. Se pueden usar otros nombres para los datos, pero los datos en si deben significar 
lo que aquí se ha explicado.

Otro tipo de estadística obligatoria para los bancos de trueque que produzcan dinero con sistema 
IBU1000 es la estadística de intercambios de un día. Esta estadística indica, para cada dominio 
de banco de trueque, las salidas y entradas de trueques intercambiadas. 

Así, un banco de trueques con sistema IBU1000 debe responder a este tipo de estadística con 
la siguiente tabla de datos para consultas con modo INT_DIA, INT_MES y INT_ANO (INT se 
referiere a intercambios):


<trueque>
<modo>INT_MES</modo>
<fecha>201109</fecha>
<dominio>trinke.com</dominio>
<csv>
Dominio,Recibido,Enviado,SaldoRelativo
trueque.com,124345.67,345.45,124000.22
bancotrueque,400.00,456.45,-56.45
</csv>
</trueque>


Este ejemplo contiene los datos de intercambios de todo un mes, con distintos bancos de trueque. 
Puede igualmente solicitarse para un día concreto o para todo un año entero. Solamente es 
normativo para esta especificación del protocolo trueque 1.0, que los bancos que creen dinero 
IBU1000, respondan a consultas de un día, es decir el modo INT_DIA.

Como puede observarse, este sistema de publicación de estadísticas, respeta completamente la 
intimidad de los usuarios, pues no existe en las estadísticas ningún dato de carácter personal, pero 
a la vez garantiza fuertemente la fiabilidad de toda la red de bancos y cuentas de trueques, al 
obligar a todo banco de trueques a publicar su información estadística de forma totalmente abierta 
y accesible para cualquiera.

Puesto que la información publicada es muy redundante (muchos de los datos pueden obtenerse 
con simples sumas y restas de otros datos), es muy difícil maquillar estos números sin que se note.

Además, el hecho de que existan las estadísticas de intercambios, facilita la persecución del fraude 
interbancario: Si uno publica datos falsos de intercambios con otros bancos, estos datos no 
coincidirán con los que publican a su vez estos otros bancos, de forma que es fácil detectar 
incoherencias y aislar a los bancos fraudulentos.

Por último, estas estadísticas de intercambios permiten obtener a todo el mundo una vista general 
de toda la economía de trueques: Es muy fácil, recopilando estadísticas de todos los bancos 
conocidos, averiguar cuanto dinero se crea y cuanto se intercambia a nivel global.

La economía de trueques implica TRANSPARENCIA ESTADISTICA TOTAL, así como TOTAL 
RESPETO A LA INTIMIDAD DE LAS PERSONAS.

¡Igualibresponsabilidad!



Búsqueda de cuentas IBU1000 en la Red de Bancos de Trueque

La IBU1000 es un derecho para todas las personas, pero puede ser una fuente de conflictos y 
fraudes por parte de las propias personas, mas allá del posible fraude interbancario o intrabancario.


Cada persona debe poder recibir su IBU1000 cada mes, y elegir el banco de trueques que se la 
gestione, sin ninguna condición previa.

Sin embargo, es posible (y probable al principio) que algunas personas pretendan recibir mas 
de una IBU1000. Esto sería fraude porque rompe la REGLA 7 o REGLA DEL KARMA, indicada en 
el párrafo sobre la creación de dinero IBU1000.

La primera medida para frenar este posible fraude (pero no la única, por supuesto) es la NORMA 8:

NORMA 9: Un email solo puede recibir la IBU1000 en una única cuenta en toda la red 
de trueque. 

Esta norma es de obligado cumplimiento para todos los bancos de trueque cuyo 
modo_creación_dinero sea IBU1000.

Para facilitar el cumplimiento de esta norma, definimos el protocolo de búsqueda de emails con 
IBU1000, que funciona de la siguiente manera:

Si un usuario de un banco de trueques solicita recibir la IBU1000 el día uno de cada mes en su 
cuenta, el banco está obligado a confirmar que este usuario no está recibiendo ya la IBU1000 en 
otro banco de trueques diferente.

Para ello realiza una consulta de búsqueda de email IBU1000 y si el email no recibe la IBU1000 
en ningún otro banco de trueques, entonces y solo entonces, le asigna la IBU1000 al usuario.

¿Como busca un banco de trueques si un email recibe la IBU1000?

Bueno, esto significa que debe haber en alguna parte una tabla con todos los emails que reciben 
IBU1000, junto con los nombres de las cuentas en las que lo reciben.

Esta tabla puede ser tan grande, que organizar un servicio centralizado para resolver las consultas 
podría ser poco menos que imposible, de forma que esta "tabla gigante de emails y cuentas 
IBU1000" la troceamos y repartimos entre los servidores de banco de trueque que crean dinero 
con el esquema IBU1000.

Esto es muy parecido al sistema DNS de resolución de direcciones IP de internet a partir de 
nombres de dominio: Es una especie de "agenda de teléfonos" que cubre toda la internet, pero 
que esta troceada en multitud de servidores, cada uno de los cuales solo se encarga de una parte 
concreta de la red (un dominio o un grupo de dominios).

Un servidor de banco de trueques que genere trueques con esquema IBU1000, es responsable 
de saber que cuentas concretas de su incumbencia reciben la IBU1000, y debe hacer esta 
información públicamente accesible a todos los demás bancos de trueque, para que estos 
puedan confirmar si un email dado, ya recibe su IBU1000 en otro banco.

Esto puede hacerse de varias maneras: Una puede ser que cuando un banco recibe la solicitud 
de un usuario para percibir la IBU1000, compruebe con todos los demás bancos, a ver si el email 
del usuario ya está asociado a alguna cuenta que reciba la IBU1000, pero este método es muy 
lento si en la red hay muchos bancos.

Otro método es un servidor centralizado que contenga toda la tabla de pares email/cuenta 
IBU1000 completa, y que cualquier banco pueda hacer consultas a esta tabla gigante cuando 
lo necesite, pero este método significa que el servidor centralizado se saturará a poco que la 
red de trueque tenga varios miles de bancos y algunos millones de usuarios.

Por extraño que parezca, este tipo de problema (estrictamente técnico en el sentido informático, 
pues solo es un problema de saturación de aparatos) ya se resolvió en las décadas de los 80 o 90, 
del siglo XX, por parte de las mismas personas que crearon los protocolos básicos de la red 
internet: La solución fue, EL SISTEMA DNS.

El sistema DNS convierte nombres de dominio en direcciones IP. Nuestro sistema de búsqueda 
de emails con cuenta IBU1000 convierte emails en cuentas de trueque.

El sistema DNS está troceado por dominios, de forma que los servidores DNS se encargan cada 
uno de un dominio o grupo de dominios, y así ninguno se satura.

Hay unos servidores centrales para las bésquedas de dominios de primer nivel (los .com, .net y 
.org famosos), pero como el propio protocolo DNS ya establece criterios de cacheado (recuerdo de 
peticiones previas), ni siquiera estos servidores centrales están saturados, ya que todo operador 
de telecomunicaciones ya se encarga de cachear sus respuestas y actualizarlas según su propio 
criterio.

¿Se podria usar el propio sistema DNS para resolver cuentas de trueque IBU1000 a partir de emails?

Pues... Probablemente si, pero la burocracia necesaria para hacerlo,seguramente sería interminable 
(el gobierno de estados unidos es el encargado de la burocracia del sistema DNS y no lo hace mal 
del todo).

Por otro lado, el protocolo DNS es un protocolo binario: Hay que escribir un programa de un montón 
de lineas para montar los paquetes de datos binarios para hacer una simple consulta, y esto es 
un engorro a estas alturas de la película.

Así que aquí proponemos un nuevo protocolo que hemos llamado "Protocolo de Búsqueda de 
cuentas IBU1000 a partir de Emails", que, siendo similar en funcionalidad al DNS, esta basado 
en consultas de texto http y respuestas de texto XML, en lugar de en paquetes de datos binarios 
farragosos y complicados.

El protocolo se basa en la variable url_buscador del archivo trueque.xml del banco de trueques en 
cuestión.

A esta url (que termina con un signo de interrogación), se le agregan dos parámetros: función y 
email.

Ejemplo:

http://www.bancotrueques.com/buscador.busca?funcion=CONS&email=pepito@grillo.com

Mas un tercer parámetro cuenta, en el caso de altas o modificaciones.

El protocolo tiene 4 funciones, cada una con su token descriptivo:

TABLA 8: Funciones del protocolo buscador IBU1000
Función Explicación
CONS Consulta. Devuelve la cuenta IBU1000 asociada al email
ALTA Alta de un nuevo email con cuenta IBU1000 asociada
MODI Modificación de la cuenta IBU1000 asociada a un email
BAJA Baja de la cuenta IBU1000 asociada al email
CONS_INV Consulta inversa para evitar fraude multicuenta


Ejemplo de solicitud de modificación de cuenta:

http://www.bancotrueques.com/buscador.busca?funcion=MODI&email=pepito@grillo.com&cuenta=pepito_grillo$trinke.com


El resultado de la petición, se entrega en texto XML con las siguientes variables:


<trueque>
<funcion>CONS</funcion>
<resultado>OK</resultado>
<reloj>20110823123456</reloj>
<caduca>20110901000000</caduca>
<email>pepito@grillo.com</email>
<cuenta>pepito_grillo$supertrueque.org</cuenta>
<dominio>supertrueque.org</dominio>
<dominio>trinke.org</dominio>
</trueque>



Como puede observarse, las variables funcion y email son copia de las de la solicitud. La variable 
reloj sirve para que el solicitante cachee (si lo cree conveniente) la fecha y hora de la petición, y la 
variable caduca sirve para indicar hasta que momento es valida la petición. Estos datos de fecha 
y hora sirven para limitar cacheo (recuerdo) de peticiones.

La variable cuenta se refiere a la cuenta de trueque en la que el usuario dueño del email recibe la 
IBU1000, caso de que exista.

La variable resultado indica un token OK o ERROR, con el mismo criterio que en el protocolo de 
transferencias (tabla 5). En caso de que no exista una cuenta IBU1000 asociada a este email, la 
respuesta debe ser ERROR ORIG o bien ERROR DEST. Cualquiera de las dos indica que no existe 
ninguna cuenta IBU1000 asociada a dicho email, con total certeza.

Si un servidor no puede, no quiere, no sabe o no acepta una solicitud de búsqueda, debe devolver 
ERROR SATURA, para que el solicitante sepa que no es que no existe cuenta IBU1000 para este 
email, sino que el servidor no sabe o no puede o no quiere encontrarlo.

La implementación del protocolo es posiblemente recursiva: Si un servidor que implemente este 
protocolo no es capaz de resolver un email en cuenta de trueque por sus propios registros internos, 
puede entregar ERROR SATURA o puede realizar la consulta a otro que si pueda resolverla y se la 
entregará al solicitante original sin modificar.

Esto último puede hacerse por medio de desvio http tradicional, o bien haciendo el servidor la 
consulta al servidor secundario (para poder cachearla si lo cree conveniente) y entregándosela 
después al cliente.

El servidor puede (y debe, si es honesto) añadir en cualquier respuesta, el dominio de los servidores 
directos encargados de esta clase de consulta (ver mas abajo el tema del troceado de emails con 
cuatro letras).

De forma que la respuesta puede incluir una, ninguna o varias variables dominio, con los dominios 
de los servidores encargados.

Este protocolo no establece casi ningún criterio de implementación del mismo, de forma que 
diferentes softwares pueden usar diferentes sistemas o lenguajes para implementarlo.

Lo que si obliga este protocolo, es que todo banco de trueque que implemente el 
modo_creacion_dinero IBU1000, tenga su servicio url_buscador funcionando correctamente 
para resolver estas peticiones, de una u otra forma.

La única exigencia de implementación para servidores IBU1000, es que troceen los emails por 
sus cuatro primeras letras.

Me explico: Es imposible para la mayoría de los servidores (quizá no para google, facebook y 
otros spammers) tener una lista completa de todos los emails del mundo. Además es 
completamente absurdo, saturante e inmantenible.

Sin embargo es fácil para cualquier servidor, encargarse de tener copia de todos los pares 
email/cuenta cuyo email empiece por cuatro letras concretas.

Para esto están las variables ibu1000_inimail y ibu1000_finmail del archivo trueque.xml: En ellas 
se indica el rango de prefijos de 4 letras de emails de los que se encarga dicho servidor. Estas 
variables son obligatorias para todo servidor de trueque con modo_creacion_dinero IBU1000, 
al igual que la variable url_buscador en el archivo trueque.xml.

Evidentemente, el troceado de este problema, implica que los administradores de los bancos de 
trueque se pongan de acuerdo para cubrir todos los rangos de cuatro primeras letras posibles 
de emails.

Si un email no distingue mayusculas de minusculas, y usa el alfabeto latino de 25 letras, mas los 
diez dígitos del 0 al 9, las combinaciones son: 

35 x 35 x 35 x 35 = 1500625 combinaciones de 4 letras

Este seria el numero de servidores de búsqueda IBU1000 necesarios si cada uno solo se 
encargase de un grupo de 4 letras.

Las variables ibu1000_inimail y ibu1000_finmail del archivo trueque.xml indican el grupo de cuatro 
letras inicial y final del que se encarga dicho banco de trueques.

Ejemplos:

Un servidor que se encarga de guardar copia de todos los emails (y sus cuentas IBU1000 
asociadas) que empiecen por la letra a, tiene en su archivo trueque.xml las siguientes variables, 
junto al resto de obligatorias y opcionales:


<ibu1000_inimail>aaaa</ibu1000_inimail>
<ibu1000_finmail>azzz</ibu1000_finmail>


Un servidor que tiene copia de todos los mails que empiecen por un número cualquiera, o las 
letras a, b y c:


<ibu1000_inimail>0000</ibu1000_inimail>
<ibu1000_finmail>czzz</ibu1000_finmail>


Los grupos de letras son siempre consecutivos y entendemos que no hay emails que no empiecen 
por una letra o un numero, y que todo el mundo usa el alfabeto ASCII para los emails (en el que 
los números tienen códigos mas bajos que las letras) y que no se distinguen las mayúsculas y 
minúsculas en los emails.

Es decir, es lo mismo pepe@yahoo.es que PEPE@YAHOO.ES en todo lo que se refiere a 
protocolos tanto de email, como de trueque.

Ejemplo de servidor que cubre absolutamente todos los emails posibles:


<ibu000_inimail>0000</ibu1000_inimail>
<ibu1000_finmail>zzzz</ibu1000_finmail>


Y un ejemplo de un servidor que solo cubre los emails que empiecen por las letras "info":


<ibu1000_inimail>info</ibu1000_inimail>
<ibu1000_finmail>info</ibu1000_finmail>


Este ultimo ejemplo muestra que las variables rbu1000_inimail y rbu1000_finmail
establecen "un intervalo cerrado, en el que los propios límites están incluidos".




9.- Fraude multicuenta e id_fraude

Un email implica una única cuenta de trueque con derecho IBU1000 como mucho, pero una cuenta 
de trueque no implica un único email.

Me explico: Una persona puede tener varios emails, pero no puede tener varias cuentas de trueque 
con derecho a recibir la IBU1000.

Así pues, la enorme tabla de emails/cuentas IBU1000, que está repartida entre los diferentes 
servidores de bancos de trueque indicados en el apartado anterior, no es una tabla biyectiva, sino 
inyectiva: Varios emails pueden estar relacionados con una misma cuenta de trueque IBU1000, 
pero un email no puede tener varias cuentas IBU1000.

Así pues puede darse el siguiente caso de relaciones entre emails y cuentas: 

pepito@gmail.com -> pepito$trueque.com 
pepito_grillo@yahoo.es -> pepito$trueque.com 

Pero no este otro: 

pepito@gmail.com -> pepito$trueque.com 
pepito@gmail.com -> pepito$bancotrueque.com 

Es responsabilidad de los bancos de trueque que creen dinero como IBU1000, como ya hemos 
dicho anteriormente, asegurarse de que un email no tenga nunca mas de una cuenta de trueque 
con derecho a recibir la IBU1000. Para ello, antes de crear un ALTA para ese email, deben hacer 
una CONS para ese email y comprobar que no existe previamente una cuenta de trueque con 
derecho a recibir la IBU1000 asociada a dicho email. 

Por otro lado, el fraude de personas que tengan varios emails y pretendan cobrar varias IBU1000, 
también debe ser perseguido y evitado por los bancos de trueque. 

Esto es un problema complejo que los administradores de bancos de trueque deben considerar y 
tratar de resolver, por lo general, de forma semi-automática. 

Semi-automática quiere decir que los softwares de banco de trueques deben poner a disposición de 
los administradores una serie de "alarmas" que permitan a estos detectar el "fraude multicuenta" 
(una misma persona tratando de cobrar varias veces la IBU1000, usando varios emails). 

Entre las alarmas puede haber chequeos de varios tipos: Direcciones IP, cookies, nombres de 
usuario, contraseñas, timestamps, modelos de navegador, etc. 

Es relativamente sencillo comprobar que desde un mismo ordenador se están manejando varias 
cuentas con derecho a recibir IBU1000, sobre todo si hay transferencias de trueques entre ellas. 

Esto debe hacer saltar las alarmas, de forma que los administradores del banco en cuestión, puedan 
detectar a las posibles personas defraudadoras y corregir la situación. 

Para esto el sistema de búsqueda de emails, debe incluir también un sistema inverso de búsqueda 
de emails relacionados con una cuenta de trueque con derecho a IBU1000. 

Por ello se define una nueva función de consulta: CONS_INV (Consulta inversa), que requiere un 
parámetro "cuenta" y devuelve uno o varios emails asociados a dicha cuenta: 

Ejemplo de consulta inversa: 

http://www.bancotrueques.com/buscador.busca?funcion=CONS_INV&cuenta=pepito_grillo$trinke.com 

Respuesta: 


<trueque>
<funcion>CONS_INV</funcion>
<resultado>OK</resultado>
<reloj>20110823123456</reloj>
<caduca>20110901000000</caduca>
<cuenta>pepito_grillo$trinke.com</cuenta>
<email>pepito@grillo.com</email>
<email>pepito@gmail.com</email>
<email>pepito_grillo@yahoo.es</email>
<id_fraude>897987/supertrueque.org</id_fraude>
<id_fraude>6546/trinke.com</id_fraude>
<dominio>supertrueque.org</dominio>
<dominio>trinke.org</dominio>
</trueque>


Como puede observarse, hay varios emails asociados a la cuenta IBU1000 pepito_grillo$trinke.com

Estos emails fueron detectados por diversos administradores de bancos de trueques, en base al 
estudio de cookies, IPs, usuarios, contraseñas y movimientos entre cuentas. Indica que el tal 
pepito_grillo es un hacker muy activo e intentó varias veces crear múltiples cuentas con derecho 
IBU1000, aunque fue "detectado por la red".

Esto obliga al tal pepito_grillo (si quiere insistir) a crearse constantemente emails nuevos y reclamar 
en bancos distintos su supuesto "múltiple derecho IBU1000", pero este tipo de actividad no debe 
llegar muy lejos, y debe tender a que el propio pepito_grillo desista de su actitud insolidaria.

No creemos que sea necesario saber que el tal pepito_grillo viva en Vitigudinos, en la calle Santuario 
numero 14, con código postal 56008, en el pais Cantabria y tenga telefono movil 876879887. 

Con sus emails (y su rastro dejado de IPs, Cookies, Navegadores, Timestamps y movimientos 
bancarios) es suficiente para pararle los pies.

La red de trueque, basada en administradores de bancos de trueques, dispone de su propia justicia 
independiente de la justicia ordinaria, y de sus propias "sentencias y castigos" independientes de 
la justicia ordinaria.

Su único castigo posible es "Quitarle el derecho a recibir la IBU1000 a un email concreto, 
asociándolo a una cuenta previamente existente con tal derecho".

Es responsabilidad y prerrogativa por tanto de los administradores de bancos de trueques, el 
rechazar la IBU1000 para un email dado.

No obstante, para que la posible arbitrariedad de los administradores de bancos de trueque no 
impida a las personas reales ejercer su derecho a recibir su IBU1000, QUE ES UN DERECHO 
UNIVERSAL, es recomendable que los administradores de banco de trueque, documenten sus 
decisiones concretas por medio de "EVENTOS DE FRAUDE NUMERADOS", o id_fraude.

¿Que es un id_fraude?, pues un identificador único que permite relacionar una serie de actividades 
sospechosas de fraude.

Una especie de "Numero de Expediente" que permite que los bancos de trueque documenten los 
fraudes que detecten y permita a los otros bancos de trueque estar alerta ante determinados 
emails.

Un evento de fraude (o numero de expediente) tiene la forma de un par numero/dominio. Es 
generado (con un contador por ejemplo) por el administrador del dominio de banco de trueque, 
al tomar la decisión de asignar un email a una cuenta de trueque con derecho a recibir IBU1000 
que ya existiera previamente, en la red de búsquedas de emails.

Así, si el administrador del banco de trueques trinke.com detecta algún tipo de actividad sospechosa 
del usuario pepito_grillo que le haga pensar que está recibiendo varias IBU1000, lo que hace es 
relacionar sus emails conocidos con una única cuenta IBU1000, impidiendo por tanto que estos 
emails puedan recibir la IBU1000 en cualquier otro banco de trueque.

No se trata de cerrar las cuentas de pepito_grillo: Se trata de que solo reciba la IBU1000 en una de 
ellas.

Y para que otros bancos puedan conocer los detalles, el banco puede disponer de algún servicio 
público de consulta de expedientes, en el que el administrador haya escrito todos los datos por los 
que tomó la decisión: IPs, Cookies, Relojes, Transacciones, nombres de usuario, emails, etc.

La política de decisiones para realizar este paso (asociar un nuevo email a una cuenta IBU1000 
ya existente) es responsabilidad del administrador del banco de trueques, de forma que este 
protocolo simplemente establece el mecanismo para "ejecutar el castigo", pero no presupone 
nada acerca de la toma de decisiones que conduzcan a tal "castigo".

Simplemente, este protocolo SUGIERE que los softwares de banco de trueques dispongan de algún 
wiki o foro, en el que otros administradores de bancos de trueques (o incluso cualquier otra persona, 
incluyendo al propio interesado "sospechoso de fraude multicuenta") comentar o discutir los 
detalles concretos de los datos y explicarse convenientemente.

Para ello, los administradores indican un dato id_fraude en sus registros de relaciones email-cuenta. 
Este id_fraude, emitido por un dominio, debe ser único a nivel de toda la red de trueque, de forma 
que puede ser cualquier cadena de caracteres (por ejemplo un número secuencial y el nombre de 
dominio):

879875/trinke.com


El sistema de trueque permite a los administradores perseguir la actividad fraudulenta de los 
usuarios individuales, pues permite a los administradores detectar actividades sospechosas y 
realizar asociaciones email-cuenta-id_fraude.

De está manera, los usuarios personales fraudulentos que pretenden cobrar varias IBU1000 son 
detectados por la propia red, y su rastro queda bien documentado, para que la propia red pueda 
defender el principio del karma o regla numero 7, previamente expuesta.

Por otro lado, la posible arbitrariedad o persecución injustificada de personas concretas, por parte 
de administradores de bancos de trueque concretos, (porque se conozcan personalmente y se 
caigan mal o se odien), debe tratar de corregirse: Al asignar un id_fraude a un email o una cuenta 
de trueque ambos se pillan los dedos, tanto el supuesto usuario defraudador, como el administrador 
del banco de trueque que denuncia públicamente el fraude.

Así mismo, el derecho a la intimidad de las personas, claramente puede ser vulnerado por 
determinados administradores de bancos de trueque con pocos escrúpulos, y con fines muy 
diversos (espionaje industrial, persecución, competencia desleal, etc).

Las diferentes implementaciones de softwares de gestión de bancos de trueque, deben tender a 
evitar este tipo de abusos. A la vez que emiten alarmas sobre conductas sospechosas de fraude 
para información de los administradores, deben impedir el estudio indiscriminado de cuentas, sin 
antes registrar este tipo de estudios de alguna forma.

Este protocolo no presupone ningún tipo de algoritmo de búsqueda de fraude, ni ningún tipo de 
sistema de protección de acceso a información de cuentas concretas por parte de los 
administradores, entendiendo que esto serán nuevas funcionalidades ampliadas de futuras 
versiones del protocolo, una vez se normalicen determinadas políticas compartidas por toda la
red, y sometidas siempre a discusión colectiva.

Una sugerencia bastante consensuada entre las personas que discutimos y proponemos este 
protocolo, es la inclusión de una url_consulta_fraude en el archivo trueque.xml que permita saber 
como realizar consultas sobre id_fraudes concretos en cada banco de trueque:

url_consulta_trueque?id_fraude=8798/trueque.com

Pero esta nueva variable, aunque recomendada para todo banco de trueque, no es obligatoria en 
esta especificación 1.0 del protocolo.



10.- Medidas contra la inflación excesiva

El universo crece constantemente. Es totalmente inflacionario o eso creemos actualmente. 
El "universo trueque", en tanto que crea dinero constantemente, también es inflacionario. 
Esto puede llegar a representar un problema en el futuro.

De ahí que la destrucción de dinero RBU1000 sea completamente legal desde el punto de vista 
de este protocolo, siempre que sea el propio dueño del dinero el que lo destruya “solidariamente, 
para evitar la inflación y reducir el circulante mundial”.

De todo el PIB mundial que generamos los humanos, hay una buena parte que es intercambiable: 
Por ejemplo si tu construyes una casa, estas creando un tipo de riqueza que después puedes vender.

Sin embargo, no toda la riqueza que creamos los humanos es intercambiable. Por ejemplo: Si tu 
me cortas el pelo, yo no puedo cambiar este corte de pelo por dinero con un tercero. Lo mismo 
ocurre con los alimentos: Alguien los cultiva, alguien comercia con ellos y finalmente se consumen 
y desaparecen.

De forma que hay dos tipos de riqueza que creamos los humanos: La intercambiable
(nunca lo es de forma eterna, pues cualquier cosa intercambiable siempre pierde valor con el 
tiempo y el uso), y la no intercambiable en absoluto, como los alimentos ya consumidos o los 
cortes de pelo ya realizados.

El dinero trueque, debe tener en cuenta este detalle. Este protocolo no establece como normativo 
(obligatorio) ningún procedimiento de "lucha contra la inflación", pues pensamos que hay muchas 
formas y unas son mas justas que otras.

Una formula sería ajustar la IBU1000 al PIB mundial percápita pero solo de la riqueza intercambiable. 
Personalmente esta es la solución que mas me gusta, al ser la mas justa: Evita que finalmente todo 
el dinero "sobrante" termine en manos de unos pocos.

Pero hay otras soluciones, por ejemplo: "Los que tengan mas de 10.000 trueques entre todas sus 
cuentas, no cobran la IBU1000".

Otra sería: "Toda cuenta personal que tenga mas de cierto límite de saldo, debe pagar impuestos 
que se reparten equitativamente". Esta, que supuestamente es la solución del capitalismo-deuda 
actual, ya estamos viendo que no funciona: Los grandes capitalistas compran a quien hace las 
leyes y estos nunca van a "morder la mano que les alimenta".

El tema es demasiado complejo como para que haya "soluciones mágicas", pero esto no debe 
desanimarnos para seguir buscándolas. Las soluciones no mágicas, pero si simples (entendibles 
por cualquiera) siempre son mucho mejores que un berenjenal de reglas complicadas que solo 
pueden entender unos pocos.

Particularmente práctico todo lo que puedo la austeridad personal e intrasferible (y mucho menos 
imponible por decreto ley), y seguramente destruya algunos trueques mios en el futuro (por el 
procedimiento de aniquilación indicado) según considere conveniente. Pero insisto: La austeridad 
no se puede imponer a nadie: Es una decisión totalmente personal.





11.- Conclusiones

Este protocolo de trueque versión 1.0 es una propuesta concreta con el fin de establecer un 
mecanismo de Ingreso Básico Universal para creación de dinero tiempo-persona, que no es 
excluyente con respecto a cualquier otra propuesta.

Permite establecer relaciones claras, precisas, transparentes, seguras y honestas entre bancos 
de trueque por internet, asi como entre sus usuarios.

No presupone en absoluto como deben escribirse los diferentes softwares de gestión de bancos 
de trueques, ni que idioma o plataforma usarán estos.

Lo único que determina, son dos tipos de reglas: Reglas de comunicación (protocolos de 
intercambio de datos) y Reglas de honestidad (redundancia de datos, obligatoriedad de estadísticas 
públicas y formas de evitar el fraude).

Asume como Derecho Universal Inalienable el derecho a recibir el Ingreso Básico 
Universal para toda persona viva, independientemente de cualquier condición de la misma.

Asume a si mismo, que puedan existir otras formas de creación de dinero diferentes al 
tiempo-persona, aunque aboga por la difusión de esta forma de "dinero fiat" (basado en la 
confianza), y lo hace independiente de cualquier autoridad central de control, democratizándola 
por tanto.

Implícitamente, delega este control en la propia red, a través de las estadísticas obligatorias para 
cualquier banco de trueques que maneje dinero creado como IBU1000.

No hace suposiciones ni previsiones de efectos secundarios como inflaciones, devaluaciones, 
crecimientos o decrecimientos, ni otros efectos deseados o no: De hecho ni desea ni deja de 
desear ninguno de estos efectos, simplemente los ignora.

Propone y promueve que el dinero se cree de forma igualitaria, otorgando los mismos derechos 
a todas las personas, y tratando de vigilar que no se produzcan abusos de ningún tipo.

Los autores de este protocolo, no se hacen responsables de ningún efecto indeseado que este 
documento, o las ideas expresadas en el puedan causar a nadie.

Por tanto, la intención de este documento es clara, concisa y completamente limpia: Este 
documento no puede declararse "ilegal", desde el punto de vista del derecho natural.

Los autores de este documento no reconocen a ningún tribunal que manifieste la ilegalidad de este 
documento, del protocolo de trueque, o de cualquiera de las ideas contenidas en el, o del software 
que lo implemente, o de el intercambio comercial derivado del uso o implementación en software 
del protocolo descrito en este documento.

Este documento aboga por la igualibresponsabilidad del ser humano, dentro de la sociedad 
humana. No puede declararse "antisocial", por tanto, sino todo lo contrario.

Alejandro Bonet - Valdemorillo - Madrid - España – Oct/2011