March 5

Pay Button with BTCPAY Server and Mynode without Woocommerce

In this article, I comment on my experiments with BTCPAY Server integrated in Mynode, in order to be able to easily create a payment button to integrate on our website, autonomously, without having to have third-party services, against our own bitcoin node.

INTEGRATION WITH WOOCOMMERCE. SOMETHING NOT SUITABLE FOR BEGINNERS

BTCPAY advertise itself as something easy and accessible for anyone who wants to open a business accepting bitcoins without the need to resort to third parties. As of today, this objective is certainly complex, even for those who have expert-level knowledge ( https://www.sosthene.net/btcpay-bilan/ ). As far as I can see, the average user is necessarily doomed to either spend the money on a Lunanode-like hosting solution, or at best, have to resort to a DDNS service like no-ip.com ( free) and turn to friends or professionals with high knowledge in the field. Another highly recommended option would be to use the services of bitcoinheiros . For those interested in this initiative, I recommend the recent talk led by Lunaticoin , accessible on youtube .

After many attempts and hours of study, I got stuck in step 3 of this tutorial ( https://docs.btcpayserver.org/DynamicDNS/ , Configure your BTCPay docker install to provide HTTPS certificates) for which you have to go to the command line and the instructions are simply that you connect to your “instance” and run some commands, without further explanation on, for example, how to access the “instance”. If the two previous steps can be done from the graphical interface, I do not understand why they have not done the same with this third step. Maybe that’s nonsense and you really have to do it like this, but I think this should be improved.

To access mynode by ssh, I think the most operative thing to do is to do it on the “settings” page

Image 1

But there it is accessed as admin, not as root and as indicated in the BTCPAY control panel it seems that it should be accessed as root

Picture 2

If you leave it so, when trying the pairing from Woocommerce (by the way we must put the virtual domain that we have followed by “: 49392”, the BTCPAY port) we get a message saying that we must access it through https or of TOR, without instructions on how to access with TOR.

Picture 3

Anyway … After giving up on my attempt to integrate BTCPAY with Woocomerce, I started to think of some other option to, at least, use the “Pay button” that can be configured once we generate a store in BTCPAY:

Picture 4

ALTERNATIVE SOLUTION APPROACH

As we say, the idea was to create a payment button with bitcoins without the need to develop and match a store with Woocommerce or similar with our BTCPAY server, and all this, as BTCPAY is supposed to achieve, using its own means without having to resort to nodes or third-party payment button solutions that, among other things, carry commission in many cases.

We start from the base that we use as a tool Mynode and BTCPAY SERVER included in the Mynode package.

An artisanal solution is simply to give each new customer a new address and send it through traditional means, such as email, but the idea is an automatic solution so that each payment goes to a new address and thus not having to reuse addresses.

The objective, therefore, is to be able to create payment buttons easily, with the generation of an html code to include on the web so that BTCPAY SERVER can interact with our local node, regardless of the server where the web page is hosted where let’s insert the code.

After thinking a lot about the matter, the key to the solution that I present was given to me by the video https://www.youtube.com/watch?v=hQxCOSgYqTo from Satoshi Radio, which showed me the way forward.

Next, I explain the steps with which the commented solution is reached. I am not a computer scientist and surely there may be other methods to achieve the goal set; With this work, I simply explain the path followed in case it could be of interest and utility for other people in a similar or analogous situation.

The idea is to be able to create a payment button or, as indicated below, a link to generate receipts, based on Mynode’s BTCPAY Server, so that we can easily embed it on our website (hosted on a site other than the node de Mynode), which operates against our own Bitcoin node, and without the need to install and integrate BTCPAY with Woocommerce or similar platforms.

STEPS TO FOLLOW

Store creation in BTCPAY Server

First, from Mynode we access BTCPAY Server and create a store. We will have to configure the wallet to which we associate the store, for which there are different options. One of them is to enter the public master key of a wallet whose private keys are not in the node or equipment connected to it. This will then allow each user, collaborator or client who clicks on the payment button or link to generate a new address not previously used, which benefits the privacy of both the site that hosts the payment button and the payer.

In the “Payment” section of “General Settings” of the store created, we have to enable the “Allow anyone to create invoice” box.

Picture 5

Enable VPN in Mynode

At first, I thought it was necessary to enable VPN access to our Mynode node ( https://mynodebtc.com/guide/vpn ) with the port forwarding mentioned in the guide. I did so in the beginning, but, curiously, I have realized that for this solution it is not necessary to enable the VPN in Mynode, nor the port forwarding in the router. We avoid all this port forwarding if we use TOR, as I comment at the end of the article.

BTCPAY Server port forwarding

This is one of the keys to the process, as it is necessary to do so if we do not want to use TOR. We have to go to our router and do a port forwarding (Port Forwarding) 49392 which is the one used by BTCPAY Server. Depending on your router, this will be done in one way or another. In this redirection, you will have to put the local IP of your Mynode node in a similar way to that mentioned in the previous section. I have tried to remove this forwarding and then, as expected, the thing does not work, unless we use the TOR option that I comment later.

Create the payment button

Once this is done, within the BTCPAY store menu we go to the “Pay Button” section and configure the parameters we want, such as the button payment amount, the size of the image, etc.

By clicking the Preview button on the right side, we can check if the whole process is on the right track.

Using the generated HTML code

Once everything is correct, at the end of the page we can see the “Generate Code” that will be something like the following:

If we look at it, there are 2 calls to… mynode.local: 49392… What we have to do is copy all the code, paste it into a plain text editor and replace the two instances of “mynode.local” with the public IP that it has. the Mynode node. If we paste that code in the WordPress input like this, I don’t know exactly for what reasons, the thing does not work well.

But if instead of copying the code, we paste it into a txt file, change the extension to html and upload it to the web as a standalone file, curiously then it works ( here example which will only work if we use TOR browser). Another problem that I have observed is that the image of the payment button does not resolve well depending on what circumstances. With the computer with which I am doing everything and locally, it goes well, but when I connected from my mobile or another device, the image did not load, although the link to generate the receipt did. I understand that a solution could be to download the image upload the file to the web and in the aforementioned txt replace the call to the image that is made to the node by the uploaded image. By the way, wordpress wouldn’t let me upload the svg file and what I had to convert to png.

In some browsers, and depending on the security settings, warnings may appear that the connection is not secure, but hey, this is an experiment and no data will be collected from the visitor. We must also bear in mind that in this way we are exposing the public IP of our node installation, which is why I decided not to make the html files that I referred to earlier accessible.

Creation of payment link for a fixed amount in FIAT currency

The truth is that I don’t really understand why I can’t put the payment button in an entry like this and yet I can put it in a separate html file. If you don’t want to go around with button flourishes and simply generate the receipt directly and for a fixed amount, instead of copying the code at the bottom of the page, you can copy the link that appears to the right of the “preview” image from the “Pay button” section. Keep in mind that every time we make a change in the configuration of the pay button, a new link is generated. And that link, changing “mynode.local” for the node’s public IP does seem to work. In this way, we can embed the link in a normal entry like this, either in text or in an image that we want.

But of course, the problem we have is that when generating the “invoice” the public IP of the node is being revealed, which affects our privacy .

An option to avoid this problem of revealing our IP would be to do the whole process from TOR . That is, we access MYNODE from TOR, from there we access btcpayserver and then the links that are generated, as well as the corresponding ” invoice”, are made to TOR addresses.

The links are generated with the pay button appear like this:
http://u76hm3kfcuro4qyf6mc7ng2x7optl75x6moq6r25ahkc2bx7wwhmsbqd.onion:49392/api/v1/invoices?storeId=FAy9ZoVKrixZwLECeS7FbJ7TkKpxpEm6NUunWGooeNo5&price= 5¤cy = EUR
and thus does not work the thing. The part in bold “5¤cy” should be replaced by “5&currency”. This error in the generation of the link text must be corrected. The error is in the text, the link that is generated after the text is correct. In addition, with this link, we can create all the payment instances that we want with different prices “price = X ” without having to enter the BTCPAY Server again.

Here are a couple of links generated with different values. That will only work if you are viewing the page using TOR Browser.

Example donate 5 euros.

Example donate 10 euros .

Example of a donation page_for variable amount. It will only work if you are viewing the page using TOR Browser.

Read more
Posted by Javier Maestre | no comments
November 19

Judgment acquittal for SQL injection

SENTENCIA núm. 422/19

En Madrid, a veinte de enero de dos mil veinte.

Habiendo visto Doña María Nieves Bayo Recuero, Juez del Juzgado de lo Penal nº 24 de Madrid los presentes autos de Procedimiento Abreviado nº 198/2017, procedentes del Juzgado de Instrucción nº 2 de Madrid (Diligencias Previas 79/2014) seguidos por un Delito de DESCUBRIMIENTO DE SECRETOS en CONCURSO MEDIAL con un delito de ACCESO NO AUTORIZADO A DATOS O PROGRAMAS INFORMATICOS contra JS con D.N.I. nº X, de nacionalidad española, nacido en X, hijo de JG y de CG, sin antecedentes penales, asistido por el Letrado Don Javier Maestre Rodríguez y el Ministerio Fiscal en la representación que por Ley le corresponde.

ANTECEDENTES DE HECHO

PRIMERO.- Las presentes actuaciones se iniciaron como Diligencias Previas nº 79/2014 por el Juzgado de Instrucción nº 2 de Madrid, habiendo sido repartidas a este Órgano jurisdiccional para su enjuiciamiento.

SEGUNDO.- Recibidas las actuaciones en este Juzgado, se formó el correspondiente Juicio Oral, se pronunció sobre la admisión de las prueba, celebrándose el juicio en el día señalado.

TERCERO.- El Ministerio Fiscal en el acto del juicio elevó a definitivas sus conclusiones provisionales calificando los hechos como constitutivos de un delito de descubrimiento de secretos previsto en el artículo 197.2 del Código Penal en concurso medial del artículo 77 del Código Penal con un delito de acceso no autorizado de datos o programas informáticos, previsto y penado en el artículo 197.3 del Código Penal en su redacción vigente en el momento de los hechos, considerando responsable del mismo al acusado como autor, sin la concurrencia de circunstancias modificativas de la responsabilidad criminal, interesando la imposición de una pena de prisión de dos años de prisión con la accesoria de inhabilitación especial para el ejercicio del derecho de sufragio pasivo durante el tiempo de la condena y multa de 18 meses a razón de 6 euros diarios con aplicación de la responsabilidad personal subsidiaria prevista en el artículo 53 del Código Penal para el supuesto de impago, así como el comiso del disco duro de marca SAMSUNG n1 de serie S19, disco duro marca WESTERN DIGITAL, nº de serie WC, disco duro marca WESTERN DIGITAL nº de serie WC extraídos del ordenador de sobremesa intervenido conforme al artículo 127 del Código Penal y las costas causadas en este procedimiento.

El Letrado de la defensa elevó a definitivas su escrito de conclusiones provisionales, interesando la libre absolución de su patrocinado, y subsidiariamente que se aplique la atenuante muy cualificadas de dilaciones indebidas prevista en el artículo 21.6ª del CP.

CUARTO: Tras los correspondientes informes, y concedida al acusado el uso de la última palabra, quedaron los autos vistos para sentencia.

HECHOS PROBADOS

Resulta probado y así se declara expresamente que JS de profesión ingeniero superior informático por la Universidad Pontificia de Comillas, en el mes de noviembre de 2012 y período comprendido entre el 12 de noviembre de 2013 y el 12 de diciembre de 2013 accedió, sin estar autorizado para ello, desde el ordenador que utilizaba en su domicilio sito en CCC, a través de las direcciones IPs x, x, x, a las bases de datos de la Universidad Pontificia de Comillas mediante la inyección de parámetros SQL en las páginas web de la Universidad www.iit.upcomillas.es y www.upcomillas.es llegando a acceder a dos de esas bases de datos sin estar autorizado para ello.

Por auto de fecha 18 de julio de 2014 del Juzgado de Instrucción nº 2 se autorizó la entrada y registro en el domicilio del acusado así como en su puesto de trabajo, interviniéndose en su domicilio el ordenador personal y los discos duros de marca SAMSUNG n1 de serie S19, disco duro marca WESTERN DIGITAL, nº de serie WC, disco duro marca WESTERN DIGITAL nº de serie WC, y el disco duro marca SEAGATE con nº de serie 9W.

Tras el análisis técnico policial practicado en el equipo personal intervenido al acusado en su domicilio, se localizaron ficheros correspondientes a las bases de datos de la Universidad Pontificia de Comillas.

No ha resultado acreditado de la prueba practicada que el acusado utilizara ningún medio o programa para vulnerar los sistemas de seguridad de la Universidad Comillas, ni que su intención fuera apoderarse, utilizar o modificar algún dato contenido en las bases de datos, ni que haya ocasionado ningún perjuicio a la Universidad.

FUNDAMENTOS DE DERECHO

PRIMERO.- Los hechos declarados probados se derivan de la valoración conjunta de la prueba practicada y, en especial, del resultado arrojado por las pruebas testifical, pericial y documental.

El acusado en el acto del juicio, manifestó que es ingeniero informático especializado en seguridad, y que es cierto que utilizó la base de datos de la Universidad de Comillas donde había estudiado su carrera de ingeniería informática en los años 2006 a 2011, pero lo hizo con la finalidad de hacer consultas desde su casa para el ejercicio de entrenamientos y ver cómo funcionaba la web. Que la página era pública y no había ninguna medida de seguridad. Que cuando hicieron la intervención lo que se llevaron era lo único que había de la Universidad Comillas, que accedió a esos datos pulsando en cada uno de ellos. Que descargó los datos con la idea de poder operar, y los datos a los que accedió eran de naturaleza pública. Que no se descargó todo. Que si pudo comprobar que el sistema tenía 12 agujeros importantes y sólo hizo dos pruebas en la Universidad, porque la tecnología que usaba estaba obsoleta. Pero que no quiso entrar más al ver que había datos delicados. Que una vez que lanzó la herramienta y vio que el troncal de la base de datos era único, cortó con lo que estaba haciendo y lo dejó, porque vio que podía ser delicado el tema. La universidad detecta el tráfico sospechoso de acceso a datos. Que lo que encontró la Guardia Civil en su ordenador son los nombres de los investigadores, porque no se descargó la información que encontró.

El testigo B, como Representante Legal de la Universidad de Comillas declaró que él interpuso la denuncia porque le informaron que había habido una persona que había accedido a los datos de la universidad a través de la página web, pero que él plasmó en su denuncia lo que les comentaron los informáticos de la Universidad ya que son los que tienen conocimiento del tema al no ser el declarante especialista técnico en informática, y como consecuencia de ello encargaron a una empresa externa la realización de un análisis de lo que había sucedido. Que por lo que le dijeron, en el acceso no se borró ninguna información, ni se modificaron los datos que estaban en la base de datos de la Universidad, y tampoco se causaron daños, más allá del coste que se ocasionó de tener que encargar a una empresa el estudio, que es lo que reclaman, así como los costes internos de dedicarse los técnicos para poder solucionar el problema. Que le dijeron que se accedió a información de carácter básico, como el nombre de investigadores o su DNI. No se accedió a las cuentas bancarias.

Por su parte, MM, como técnico informático de la Universidad y director de redes de seguridad, declaró que aquel día se dieron cuenta de que habían entrado en la red de la Universidad porque ésta tenía un comportamiento extraño y vieron instrucciones raras en el sistema. Que comenzaron a buscar de donde venía y empezaron a cortar, porque por los portales se puede acceder a mucha información. Que encargaron a unos peritos que hicieran un estudio. Que los datos a los que se accedió por el acusado, eran nombres y apellidos y DNI u otros datos de gestión de la Universidad, pero no tiene conocimiento que esos datos a que se accedió hayan sido divulgados. Que han introducido algunas modificaciones desde entonces para evitar el acceso de terceros, porque saben que el sistema tenía una brecha de seguridad. El perjuicio causado a la Universidad se traduce en el coste del peritaje, pero no hubo daños en el sistema, porque el declarante no tuvo que reparar nada. Que la herramienta SQL se suele utilizar para ver si el sistema de seguridad de acceso es vulnerable y esa herramienta es gratuita, y que el declarante la usa en su casa para ver si todo está correcto.

Los agentes de la Guardia Civil con TIP nº U y B, declararon que su trabajo consistió en averiguar la IP desde donde se había hecho la conexión para acceder a la web de la Universidad, además de llevar a cabo la entrada y registro e incautar los ordenadores del acusado. Que para ello analizaron la pericial que les mandaron y los “logs” que aportaron. Que el hecho de utilizar la herramienta SQL provoca daños al sistema por el impacto que tiene en el mismo, porque los sistemas dejan de funcionar correctamente, al provocar un stress en el sistema que puede ocasionar daños. Que sospecharon que el acusado estaba utilizando “proxis” y después él mismo confirmó que las utilizaba. Que aunque había más IPs, la más sospechosa era la que les llevó hasta el acusado. Que ellos no analizaron el material intervenido. Aunque nada les hizo pensar que con la intrusión se borrara o modificada nada.

En el mismo sentido declaró MF, que ratificó que firmó todos los oficios que se mandaron al Juzgado como alférez del grupo, manifestando que fueron sus compañeros los que hicieron el informe y que su trabajo consistió en identificar las IPs. Que al contenido que accedió se lo facilitó la universidad y ECIX y que luego lo comprobaron cuando se incautó el ordenador del acusado.

Los agentes de la Guardia Civil S y G que realizaron el informe pericial, así como el perito JM, declararon que la primera línea de investigación fue identificar las IPs y vieron que había 3 direcciones que habían hecho consultas accediendo a la base de datos y obteniendo información y vieron como esa información se había extraído de la carpeta del servidor de la web de la universidad, que como se puede apreciar en el folio 51, el acceso se hizo a datos privados como DNI. Que la Universidad no les ha comunicado que existiera algún daño de funcionamiento. Que en el sistema de la universidad existía un fallo de programación en la aplicación que producía vulnerabilidad. Que consideran que solo se accedió en modo de lectura. Que cuando analizaron el ordenador del acusado, en el disco duro había algunas bases de datos descargadas y en carpetas ordenadas y que tenía una caja de herramientas que se utilizan en el mundo del hacking, pero solo dos bases estaban relacionadas con la Universidad. Que no recordaban si había accedido a nóminas, pero creía recordar que si a bajas laborales. Que pensaban que la intención del acusado en todo momento fue didáctica, porque no hubo daños, ni tampoco descarga. Que el SQL es lo que utilizó y esa aplicación detecta vulnerabilidades. Que cuando el sistema genera un código 500, eso quiere decir que te deniega el acceso, pero queda registrado el intento, y que algunas cosas de la base de datos de la universidad venían con contraseña y se produjo un código 500.

Finalmente, declaró el perito de la defensa CAS, el cual ratificó su informe unido a los folios 373 a 404, cuyo original fue aportado en el acto del juicio, el cual, además de aclarar aspectos del funcionamiento de las herramientas informáticas utilizadas para acceder a los sistemas o bases de datos de terceros, también manifestó que el fichero que se aportó refleja todo el frontal, donde dice a lo que no se pudo acceder, como por ejemplo a “nóminas” ya que arrojó un Código 500. Además, quedó registrado que solo se hizo el acceso a nivel de consulta. Además, añadió que había que tener en cuenta, que los datos fueron facilitados por la Universidad, que fueron fácilmente manipulables y por ello, no se respetó la cadena de custodia. Además para un estudio exhaustivo del alcance, habría que haber comprobado los 200 logs, porque cuando da código 500 no se puede acceder a la información. Además, añadió que el sistema de la Universidad tenía agujeros de tensión y que fueron más IPs las que intentaron o accedieron a la Universidad.

Por otra parte, consta unido a los folios 24 a 29 el informe inicial que realizó los agentes de la Guardia Civil para poder analizar e identificar qué IP era la utilizada para acceder a las bases de datos de la Universidad, partiendo de los datos que les habían sido facilitados por la entidad ECIX que había realizado un informe pericial de la amenaza informática que habían sufrido. En este informe inicial de la Guardia Civil, puede apreciarse como fueron varias las IPs localizadas y que habían intentado acceder a la información de la Universidad mediante el empleo de herramientas FOCA, SQL y ACUNETIX utilizadas para poder encontrar fallos informáticos o vulnerabilidades del sistema. Asimismo, también consta que fue utilizando por el usuario, el programa o dispositivo PROXI para poder encubrir su real identidad.

No obstante, de este primer informe, se observa que fueron varias IPs las que intentaron acceder a los datos de la universidad, y que según se expone, dos fueron las que arrojaron un resultado más agresivo y que posteriormente fueron identificadas como del acusado, como consta en los folios 74 a 95 de las actuaciones.

Asimismo, consta en los folios 98 y 104 los autos acordando la entrada y registro tanto en el domicilio de JS, así como en su lugar de trabajo, y las actas levantadas en la citada diligencia, unidas al folio 107 a 113, donde se incautó todo el material informático del acusado y que había sido utilizado para el acceso a los datos de la Universidad Comillas, como puede apreciarse del informe elaborado por el Grupo de Delitos Telemáticos de la Unidad de la Guardia Civil, unido a los folios 143 y siguientes, y en donde se llega a la misma conclusión, en cuanto al alcance de la actividad desarrollada por el acusado de acceso a la información de la Universidad Comillas, que la expuesta en el informe pericial de la empresa ECIX .

A los folios 31 a 64 consta unido el informe pericial de la empresa ECIX que fue encargado por la Universidad Comillas, para valorar el alcance de la intrusión que podrían haber sufrido, y según consta en el mismo, el estudio se realizó desde las bitácoras o “logs” de los servidores de la web corporativa y las bases de datos de la Universidad, siendo éstos los que sirvieron para almacenar la actividad sospechosa de la persona o personas que habían accedido a la información. Llegando a la conclusión los peritos, que solo tres de las direcciones IPs la x,x,x fueron las que consiguieron acceder a las base de datos mediante la inyección de parámetros SQL. Que no obstante, esas IPs identificadas solo realizaron consultas de lectura de información, sin haber modificado, introducido o eliminado información adicional, siendo la última IP de las mencionadas, la que mayor actividad maliciosa presentó, al haber accedido a un mayor número de bases de datos, siendo los datos consultados los que aparecen en el informe (folio 51). Asimismo, consta que la Universidad tras lo sucedido había procedido a subsanar el problema técnico que tenía en su sistema con el fin de limitar en la medida de lo posible la repetición de hechos como los ocurridos.

Igualmente, puede apreciarse el análisis realizado por el acusado a la base de datos de la Universidad Comillas en los folios 145 y siguientes en donde aparecen distintas carpetas y bases con nombres y apellidos de personas relacionadas con la Universidad, que como se expone en los informes y así fue confirmado en el acto del juicio, se corresponde en la mayoría con datos relativos a nombres de alumnos y profesores. Pero para tener un mejor conocimiento de los derechos que podrían haber sido vulnerados por el acusado, por el Juzgado de Instrucción se requirió a la Universidad Comillas para que facilitara de forma específica los datos a los que tuvo acceso el acusado en su intrusión, los cuales fueron aportados, como puede apreciarse en los folios 240 a 244, donde constan todas las bases de datos a las que se tuvo acceso, y como puede comprobarse en algunas constan los nombres y apellidos de determinadas personas, en otras son datos de contacto, en algunos existen datos codificados, siendo las que se puede calificar de contenido más personal las de datos de atención psicológica y terapeutas y pacientes, pero sin que conste el contenido exacto de lo que existía dentro de ellas, al no haber sido facilitado, pese el requerimiento judicial efectuado por el Juzgado de Instrucción nº 2 de Madrid (folio 236 y 237), por lo que se hace imposible poder valorar el alcance verdadero y la gravedad de la intrusión realizada por el acusado.

Finalmente a los folios 373 a 404, se encuentra el informe pericial aportado por el perito de la defensa CAS, donde se expone que no se realizó una cadena de custodia correcta, porque la información facilitada por la Universidad pudo ser manipulada. Además, de faltar un examen del detalle de los ficheros, porque se pudo constatar que a la mayor parte de la información no se pudo acceder. Además, de que los datos consultados por el acusado es información pública, que al día de hoy se puede visionar desde cualquier navegador web, sin el uso de claves, siendo por ello, todos los exámenes periciales parciales, al no analizar toda la información.

SEGUNDO.- El delito que se imputa a JS es el de descubrimiento de secretos previsto en el artículo 197.2 del Código Penal en concurso medial del artículo 77 del Código Penal con un delito de acceso no autorizado de datos o programas informáticos, previsto y penado en el artículo 197.3 del Código Penal en su redacción vigente al momento de comento de cometer los hechos.

En cuanto al delito de descubrimiento y revelación de secretos tipificado en el artículo 197.2 del Código Penal, castiga al que, “sin estar autorizado, se apodere, utilice o modifique, en perjuicio de tercero, datos reservados de carácter personal o familiar de otro que se hallen registrados en ficheros o soportes informáticos, electrónicos o telemáticos, o en cualquier otro tipo de archivo o registro público o privado. Iguales penas se impondrán a quien, sin estar autorizado, acceda por cualquier medio a los mismos y a quien los altere o utilice en perjuicio del titular de los datos o de un tercero”.

Por lo tanto, la conducta que se castiga es el de apoderamiento, utilización o modificación, en perjuicio de tercero, de datos reservados de carácter personal o familiar de otro, que se encuentren registrados o archivados, o de acceder por cualquier medio a los mismos. Por lo tanto, son conductas de apoderamiento -aprehensión material o virtual de los mencionados datos reservados-, de utilización -hacer uso ilegítimo de la información contenida en los mismos-, de modificación o alteración -cambiar alterar o transformar esos datos reservados registrados-, y de acceder -mediante el conocimiento o la obtención de información sobre tales datos, es decir, tenerlos a disposición- de los datos reservados de carácter personal o familiar registrados en ficheros, soportes informáticos o archivos, siempre y cuando se lleven a cabo con la finalidad de perjudicar a un tercero (SSTS de 18 de febrero de 199, 11 de julio de 2001, SAP Barcelona de 18 de enero de 2008)

Tales datos reservados  han de entenderse en un sentido funcional, y no vinculado estrictamente a los efectos administrativos, como los relativos a datos no públicos -secretos-, no conocidos por el sujeto activo y que el sujeto pasivo no desea que se conozcan (STS 11 de julio de 2001), que afectan a la privacidad de la persona o de su ámbito familiar. Han de ser ajenos, siendo indiferente el modo de tratamiento de tales datos que han de hallarse registrados en ficheros, soportes informáticos, etc. o en cualquier otro tipo de archivos o registro público o privado.

Los datos reservados de carácter personal o familiar, no pueden ser confundidos con los datos personales  que pertenecen al núcleo duro de la privacidad -ideología, creencias, salud, etc.-, cuya tutela penal se articula a través del tipo cualificado del  art.197.5 del Código Penal.

La conducta del tipo básico de los delitos contra la libertad informática solo admite la comisión dolosa. Además, se requiere la concurrencia de un especial elemento subjetivo del tipo, al exigir que el agente obre «en perjuicio» de otro. No es necesaria la causación del perjuicio ajeno para consumar el delito, al ser suficiente con que la realización de la acción típica se lleve a cabo para causar a otro, cualquier clase de perjuicio, no necesariamente económico (TS 11-7-01, EDJ 16167).

Como ha declarado el Tribunal Supremo, “en el art. 197.2 se incrimina tanto el hurto, como el espionaje informático, dentro del tipo básico, al que también corresponde el número anterior, de modo que se sanciona el “apoderamiento, utilización o modificación” de los datos personales o familiares, tanto automatizados (soportes informáticos, electrónicos o telemáticos) como residentes en ficheros (archivo o registro) de tipo manual, (tanto público como privado); es decir, cuando las referidas conductas se hayan efectuado de manera ilegal con infracción de la Ley de protección de datos de carácter personal 15/1999, de 13 de diciembre, vigente” (STS 1084/10, de 9 de diciembre).

En cuanto a la conducta que castiga el tipo penal, la Sala Segunda explica que “el primer inciso se refiere a la conducta de apoderarse, que evoca la acción de sustraer, mientras que el segundo inciso se refiere al acto de acceder por cualquier medio, con el que se alude a todo forma ilícita de llegar a conocer los datos reservados” (STS 234/99, de 18 de febrero).

El delito requiere que la conducta se realice en perjuicio de tercero. El Tribunal Supremo recuerda: “tres formas comisivas se recogen en el párrafo segundo del artículo 197.2 del Código Penal: a) el apoderamiento, utilización o modificación de los datos que hemos descritos; b) el mero acceso; y c) la alteración o utilización. Sólo con relación a la primera y a la tercera de ellas, menciona expresamente el legislador que la conducta se haga en perjuicio de tercero, mientras que no exigiría tal perjuicio en el caso de la conducta de acceso. Pero como decíamos en la resolución ya mencionada, es necesario realizar una interpretación integradora del precepto, en el sentido de que como en el inciso primero se castigan idénticos comportamientos objetivos que el inciso 2º (apodere, utilice, modifique) no tendría sentido que en el mero acceso no se exija perjuicio alguno, y en conductas que precisan ese previo acceso añadiendo otros comportamientos, se exija ese perjuicio, cuando tales conductas ya serían punibles -y con la misma pena- en el inciso segundo” (STS 990/12, de 18 de octubre).

Por lo tanto, se precisa, el acceso a la información que en el caso de autos ha sido probado, pero también se requiere, que ese acceso se haga en perjuicio de tercero. Perjuicio que no ha resultado acreditado, porque aunque la Universidad lo cuantifica en la suma que ha tenido que abonar a los técnicos para averiguar la intromisión y arreglar las posibles brechas que tenía el sistema por donde terceros podían acceder. Ese gasto económico no puede considerarse perjuicio, ya que no es un perjuicio causado por el acusado al acceder al sistema de la Universidad, pues su conducta, según ha resultado probado, no provocó ningún tipo de daño, ni modificación en el sistema, por lo que no puede considerarse que su acción fuera realizada con el fin de causar un perjuicio al titular de los datos, como expone y exige el precepto.

Tampoco se ha acreditado que por parte del acusado ejecutara los verbos que exige la conducta del tipo, apoderarse, utilizar o modificación los datos sin autorización de su propietario, porque según expusieron los peritos, la intromisión solo se realizó a los efectos de consultar o modo lectura, sin que haya resultado probado que esos datos hayan sido utilizados, y el hecho de que en su ordenador constara alguno de estos datos consultados, es porque como se explicó en el acto del juicio por los peritos, la herramienta SQL provoca que en el ordenador del usuario de esta herramienta informática, quede reflejo de los datos consultados.

Asimismo, tampoco podemos apreciar en la conducta del acusado, que la misma se hiciera con el dolo necesario que exige el tipo, pues en ningún momento se ha acreditado que la finalidad o ánimo buscado por el acusado, fuera acceder a las bases de datos con la idea de poder descubrir determinados datos secretos o vulnerar la intimidad de alguna persona, pues como se ha expuesto, la Universidad no ha probado que aquellos datos a los que se tuvo acceso por el acusado, hayan podido vulnerar la intimidad de las personas, porque a los datos que accedió eran públicos, como era el nombre y apellidos o en algunos casos el número del Documento Nacional de Identidad, y sin que se haya demostrado que dentro del contenido de esas bases de datos existieran datos que afectan a la privacidad de la persona o de su ámbito familiar.

Por todo ello, valorando en su conjunto la prueba practicada no puede llegarse a la conclusión que los hechos realizados por el acusado, puedan ser incardinados en la conducta del tipo previsto en el artículo 197.2 del Código Penal.

TERCERO.- Por otra parte también se le imputa al acusado, el delito de acceso no autorizado a datos o programas informáticos, regulado en el apartado tercero del artículo 197 en su redacción a la fecha de los hechos, el cual venía redactado: “ El que por cualquier medio o procedimiento y vulnerando las medidas de seguridad establecidas para impedirlo, acceda sin autorización a datos o programas informáticos contenidos en un sistema informático o en parte del mismo o se mantenga dentro del mismo en contra de la voluntad de quien tenga el legítimo derecho a excluirlo, será castigado con pena de prisión de seis meses a dos años.”

Este tipo penal desde la reforma del Código Penal llevada a cabo por LO 1/2015, ha sido objeto de tratamiento sistemático autónomo, sacándole del artículo 197 del Código Penal, que regula los tipos básicos y cualificados de descubrimiento y/o revelación de secretos, e incorporando las conductas objeto de protección al vigente artículo 197 bis.

Las conductas que pretende regular este precepto son las llevadas a cabo por hackers cuya única finalidad consiste en burlar sistemas de seguridad informáticos, sin el menor interés hacia el contenido de la información a la que podría accederse. De hecho, la ética hacker y su evolución sociológic., tiene más que ver con el reto o desafío personal o compartido en la comunidad hacker de quebrar la seguridad de un sistema informático, demostrando sus puntos débiles y con ello incluso ayudando, si bien indirectamente, a mejorarla.

La primera modalidad típica que se regula en este precepto es la de acceso sin autorización a datos o programas informáticos contenidos en un sistema informático o en parte del mismo. El acceso puede ser directo o remoto, debiendo realizarse siempre vulnerando las medidas de seguridad establecidas para evitarlo

El objeto material está integrado por los datos y programas informáticos contenidos en un sistema informático.

La segunda modalidad típica, alternativa a la primera, es la de mantenerse dentro del sistema en contra de la voluntad de quien tiene el legítimo derecho de exclusión. De ahí, que se exija que la entrada haya sido consentida por el titular del sistema, y que el sujeto activo se mantenga después de haber cesado ese consentimiento.

El tipo se consuma desde el momento en que el agente accede sin autorización a los datos o programas informáticos de un sistema informático, vulnerando las medidas de seguridad establecidas para evitar el acceso informático ilícito, o cuando, después de un previo acceso informático lícito, el sujeto activo se mantiene dentro del sistema informático después de que se haya manifestado la voluntad contraria del titular de derecho de exclusión.

La conducta típica consiste en acceder o mantenerse, resultando indiferente que se realice una u otra, o incluso ambas, pues el delito seguirá siendo único

El alcance de la conducta típica, en el plano objetivo, quedará condicionado y limitado por la exigencia de la vulneración de las medidas de seguridad antivirus o firewall, claves de acceso, contraseñas, establecidas para impedir el acceso informático no autorizado. En cuanto al mismo, la modalidad típica más común será el empleo de técnicas de hacking, como es la utilización de generadores de claves o keygens, programas destinados a burlar contraseñas u otras barreras de seguridad interpuestas por el titular de los bienes jurídicos amenazados, como el empleo de cracks y artificios semejantes, hoy por hoy bastante comunes en el ciberespacio y al alcance de cualquier usuario.

En el caso de autos, ha resultado probado que el sistema informático de la Universidad Comillas presentaba ciertas irregularidades o deficiencias que le hacían vulnerable a ciertas amenazas, y que por ello, a raíz de ocurrir los hechos que son objeto de enjuiciamiento, se adoptaron las medidas precisas para arreglar esas posibles deficiencias, como expusieron tanto el testigo MM, o el perito que elaboró el informe de la entidad ECIX y los peritos del Grupo perteneciente a la Guardia Civil de Delitos Telemáticos.

Asimismo, ha resultado probado, que las herramientas utilizadas por el acusado fueron aquellas que sirven para encontrar vulnerabilidades en los sistemas, y que el mismo lo hizo con la finalidad de encontrar esa posible vulnerabilidad de los sistemas de seguridad de la Universidad donde él había cursado sus estudios de Ingeniería Informática, accediendo por su página web. Sin que en ningún momento haya utilizado programas u otros artificios semejantes, destinados a burlar contraseñas u otras barreras de seguridad interpuestas por el titular y que actualmente pueden utilizarse, y que no cabe la menor duda que el acusado conoce y pudo utilizar, en virtud de los conocimientos que tiene como ingeniero informático y experto en sistemas de seguridad.

Es por ello, por lo que no se puede apreciar que concurra en la conducta del acusado los elementos exigidos en el tipo, pues su actuación no fue dirigida a burlar los sistemas de seguridad de la Universidad, sino que su conducta fue dirigida a comprobar si el citado sistema era vulnerable, porque como explicaron todos los peritos el empleo de las herramientas SQL y ACUNETIX son utilizadas para poder encontrar fallos o carencias informáticas o vulnerabilidades en los sistemas de seguridad. Pues así lo expuso el propio acusado en todas sus declaraciones, como también lo expusieron prácticamente la totalidad de los peritos, al manifestar que dada la forma de acceder y las herramientas utilizadas por el acusado, no tenían dudas que la intención del acusado fue en todo momento didáctica.

Por lo que ante tales circunstancias, existiendo una total falta de prueba de cargo, sobre la concurrencia de los presupuestos del delito de descubrimiento de secretos y del delito de acceso no autorizado a datos o programas informáticos que se le imputa a JS, se hace necesario el dictado de una sentencia absolutoria en favor de ambos acusados.

Porque en este sentido cabe manifestar que el derecho a la presunción de inocencia, consagrado en el art. 24.2 de la Constitución, es además de un derecho fundamental que vincula a todos los poderes y que resulta de aplicación directa, una regla de juicio que debe ser aplicada en el momento de dictar sentencia. Y en base a su significado, se extrae la conclusión que le incumbe a quien acusa aportar las pruebas destructoras de aquella presunción iuris tantum, pues es la inocencia la que se presume como cierta hasta que no se demuestre lo contrario (STC 124/1983, de 21 de diciembre). Se trata pues, como recuerda la STS 2073/2007, de 25 abril, de un derecho que presenta una naturaleza de carácter “reaccional”, o pasiva, de modo que no precisa de un comportamiento activo de su titular sino que, antes al contrario, constituye una auténtica e inicial afirmación interina de inculpabilidad, respecto de quien es objeto de acusación. Ahora bien, su carácter de interinidad o de presunción “iuris tantum”, es el que posibilita, precisamente, su legal enervación, mediante la aportación, por quien acusa, de material probatorio de cargo, válido y bastante, sometido a la valoración por parte del Juzgador y desde la inmediación, de la real concurrencia de esos dos requisitos: el de su validez, en la que por supuesto se ha de incluir la licitud en la obtención de la prueba; y el de su suficiencia para producir la necesaria convicción racional acerca de la veracidad de los hechos sobre los que se asienta la pretensión acusatoria. La prueba de cargo, además, debe estar referida a los elementos esenciales del delito objeto de la condena, tanto de naturaleza objetiva como subjetiva, y a la participación en dichos hechos del acusado, lo que constituye el ámbito propio de este derecho fundamental (Sentencias del Tribunal Supremo de 9 de mayo de 1989, 30 de septiembre de 1993, 30 de septiembre de 1994 y 10 de octubre de 1997).

Pero junto a este derecho fundamental de presunción de inocencia, que da derecho a no ser condenado sin prueba de cargo válida, que es la obtenida en el juicio (salvo las excepciones constitucionalmente admitidas), que haya sido racional y explícitamente valorada, de forma motivada, en la sentencia (STC 17/2002, de 28 de enero y STS 213/2002, de 14 de febrero), contamos con el principio “in dubio pro reo”, que pertenece al momento de valoración de la prueba y que juega cuando, concurrente aquella actividad probatoria indispensable, y que no permite que exista una duda racional sobre la real concurrencia de los elementos objetivos y subjetivos del tipo penal de que se trate ( STC 44/1989, de 20 de febrero), y que en caso de existir la duda, habrá de resolverse a favor el reo.

Igualmente esta doctrina jurisprudencial también ha sido recogida en las Sentencias del Tribunal Supremo 1386/2003 de 24 de octubre, 1565/2003 de 21 de noviembre, 1415/2003 de 29 de octubre y 1280/2003 de 8 de octubre entre otras.

CUARTO.- Por lo que respecta a las costas del presente procedimiento, deben ser declaradas de oficio ante la absolución de los acusados, por aplicación del artículo 240 de la Ley de Enjuiciamiento Criminal.

FALLO

Que debo declarar la LIBRE ABSOLUCIÓN de JS de los hechos que se le imputaban en la presente causa.

Impónganse las costas de oficio.

Notifíquese la presente a las partes y al Ministerio Fiscal y a los ofendidos y perjudicados, aun cuando no se hayan mostrado parte en la causa.

Esta Sentencia no es firme. Contra ella cabe interponer recurso de apelación, en el plazo de DIEZ DÍAS a contar desde su notificación, ante este Juzgado para su resolución por la Audiencia Provincial de Madrid.

Llévese testimonio de la presente resolución a los autos principales, quedando el original en el libro de Sentencia.

Así lo acuerdo, mando y firmo.

Magistrado/a-Juez

Read more
Posted by Javier Maestre | no comments
September 25

Analysis of the European Union Regulation on Markets in Crypto-assets (MiCA) 1. Concepts

Google translation. Working on improving the text.

Index

1. Introduction
2.- The importance of the concept. Definitions of the standard

1. Introduction

A draft of the European Regulation on Cryptoasset Markets (MiCA) (COM (2020) 593) has recently been published, and it is going to bring a tremendous change in the European legislative landscape of cryptocurrencies, crypto-assets if we use the terminology used by the regulator [1 ].

The explanatory memorandum indicates that the proposal supports a holistic approach to blockchain and Distributed Ledger Technologies (DLT), that is, it aims to establish comprehensive regulation of what it calls “crypto-assets”.

The four main objectives mentioned in the memorandum (p. 2) seem laudable, namely: 1.- the creation of a sound legal framework , 2.- to support innovation , 3.- to ensure financial stability, and 4.- to instil appropriate levels of consumer and investor protection. Unfortunately, the impudence and hypocrisy of our politicians make that, more and more often, the explanations of our regulations hide their true intentions, or even express the opposite of what is intended, so that these worthy objectives could be those who are led by the blue pill [2] , and that the red one shows us, instead, the imposition of strong entry barriers to the markets related to crypto-assets through a thick blanket (168 pages) of bureaucratic , financial and technical requirements, thus discouraging innovation, to prolong the agonizing configuration of the current financial system (protect banks), using the protection of citizens as an excuse , since they are very clumsy to know what suits them.

For example: the explanatory memorandum reflects on the difficulties that crypto-asset businesses have to access certain services today when it states on p. 4 that : “the lack of applicable regimes to crypto-asset service providers in many Member States limits the availability of funding and sometimes even wider access to necessary financial services, such as banking services, due to the regulatory uncertainty associated with crypto-assets and therefore crypto-asset service providers” That is, it links the difficulties of access to banking services with the lack of regulation, when, as anyone linked to the sector knows for sure, banks, although they are ready to sell all the blockchain vaporware they can, especially if they are financing it with everyone’s money, they don’t allow legitimate cryptocurrency businesses to make use of the banking system [3] . Something that in Chile has led to litigation by buda.com against the banks [4] , for which, in iterim, they were forced to reopen the accounts that had been closed.

        

2.- The importance of the concept [5]. Definitions of the Regulation

The draft articulated text, after identifying the object of the regulation, its scope of application and exemptions, in article 3 deals with defining the main concepts that will be used, some of which we will analyze below and which are of great importance.

In this regard, it should be noted that this regime of definitions, if the rule as we know it is approved, can be easily modified in practice, since art. 3.2 empowers the Commission to “to adopt delegated acts in accordance with Article 121 to specify technical elements of the definitions laid down in paragraph 1, and to adjust those definitions to market developments and technological developments.“

A true catch-all that will allow the European executive power to decide what behaviors and to what extent fall within the scope of the Regulation.

2.1.- Definition of crypto-asset and distributed ledger technology (‘distributed ledger technology’ or ‘DLT’). Is bitcoin a crypto-asset?

The first two definitions of art. 3 deal with these two concepts. Thus, the Regulation understands by crypto-asset a  digital representation of value or rights which may be transferred and stored electronically, using distributed ledger technology or similar technology. And distributed ledger technology (DLT) is simply defined as a type of technology that support the distributed recording of encrypted data.

One of the doubts that arise with this definition is whether cryptocurrencies such as bitcoin fall within the concept of crypto-asset that the Regulation establishes.

Although it is foreseeable that the European authorities consider bitcoin as one more crypto-asset, the truth is that if we pay attention to the literal wording of the exposed definition, a “digital representation of value“, there are doubts about whether bitcoin fits into it, since that, rather than representing value, bitcoin HAS value [6], it is not a mere representation of it. According to twitter user @fiscalidadbtc, it seems that this expression “comes from the European Banking Authority and is a twisted way of avoiding mentioning the concept of “unit of account”, in a similar way to how it was recommended to change “medium payment” by “means of exchange.” In the aforementioned twitter topic there is an interesting discussion on the concepts of “having value” and “representing value” for those who want to expand the information on this issue. Personally, I share the opinion of @fiscalidadbtc when he compares bitcoin with gold, to consider, as Manuel Polavieja also defends, that bitcoin is an asset with value in itself [7]  and not a mere representation of value.

For a more detailed analysis of the terminology that European authorities have been using to define crypto assets and cryptocurrencies, I recommend the chapter “Cryptocurrencies: legal nature, electronic evidence and taxation” by David Maeztu in the book coordinated by Ofelia Tejerina “Legal Aspects of Cybersecurity” [8], where we see that in 2012 [9], the ECB referred to cryptocurrencies as“ a type of digital money ”, while in 2015 [10] already adopted the current definition of “a digital representation of value”. Later, in another 2016 report [11], the ECB qualified them as “alternative means of payment”, but indicating that ” it would be more accurate to regard them as a means of exchange, rather than as a means of payment.”

For the current Directive on Money Laundering, in the wording conferred by Directive (EU) 2018/843 [12], “virtual currencies” would be a type of crypto-asset, following the definition of the Central Bank of 2015: “representation digital of value that is not issued or guaranteed by a central bank or a public authority, is not necessarily attached to a legally established currency and does not possess a legal status of currency or money, but is accepted by natural or legal persons as a means of exchange and which can be transferred, stored and traded electronically.”

Anyway, if we accept “neatness” as a desease[13] and that bitcoin digitally represents value, even in a self-referential way, as David Maeztu indicates in the aforementioned work, then it would fall within the generic category of crypto-assets, but the European legislator dispenses to go further in defining the key concept of all regulation.

Below we will analyze the types of crypto-assets that the draft expressly mentions.

2.2.- Types of crypto-assets (Art. 3)

Recital 9 of the Regulation tells us that, “beyond the general definition of crypto-assets” (a phrase that doesn’t figure in the second draft published), “A distinction should be made between three sub-categories of crypto-assets, which should be subject to more specific requirements” and these are the following:

2.2.1.- Asset-referenced tokens. Application to the Lightning Network?

The Regulation considers that ‘asset-referenced token’ means a type of crypto-asset that purports to maintain a stable value by referring to the value of several fiat currencies that are legal tender, one or several commodities or one or several crypto-assets, or a combination of such assets.

One of the questions raised by this definition is whether it is applicable to second-layer networks such as the Lightning Network in relation to bitcoin, and which has led to an interesting debate on Twitter [14].

Surely, the European authorities have not claimed that the regime is applicable to the Lightning Network, but the truth is that there are interpretative doubts since it could be considered that the tokens of the said network would be assets referenced to bitcoin. However, if we observe the regime envisaged for these crypto-assets, I understand that we must conclude that the Lightning Network does not imply that we are before the figure of the asset-referenced token, among other things, although there may be those who think otherwise, because we cannot glimpse the existence of the figure of the token issuer (which we will analyze later), to which we require compliance with the requirements imposed for the creation and offer of the token, so in practice, in the network, the Regulation could not influence. And, although [15] the Regulation could be imposed on market operators preventing the exchange of the token, the truth is that this would not affect the very existence and operation of the Lightning Network, just, centralized exchanges could not be used.

Another issue that this wording introduces is the consideration of crypto-assets as means of payment, an expression that does not seem to be to the liking of the European authorities,  or means of exchange (an expression used in the Directive on Money Laundering). Without going into this terminological disquisition now, the evolution of which we have commented in the previous section, it should be noted that the draft, although in the articulated text the expression “means of payment” is not mentioned, it does admit it clearly in the Recitals, at least in relation to the referenced tokens, and especially in which the reference “asset” is a fiat currency and that it even alludes to another of the classic functions of money, the store of value. [16]

2.2.2.- Electronic money token or e-money token)

‘electronic money token’ or ‘e-money token’ means a type of crypto-asset the main purpose of which is to be used as a means of exchange and that purports to maintain a stable value by referring to the value of a fiat currency that is legal tender.

As we can see, the definition is practically identical to the previous one, simply limit the referenced asset to a specific fiat currency. Therefore, this type of crypto-assets, in short, is only one type of referenced crypto-assets, when the reference is a specific FIAT currency.

The Regulation subsequently deals with these figures, which it subjects to a differentiated regime with respect to crypto assets in general.

-.-.-.

2.2.3.- Utility tokens (Utility token)

These are the crypto assets intended to  provide digital access to  an  application ,  services  or  resources  available in a distributed registry and that  are accepted only by the issuer of that token  to grant access to said application, services or available resources. Let’s think, for example, of the exchange’s own tokens to pay transaction fees or, at a given moment, the one that represents the latest model sword of a game [17] .

2.2.4.- Crypto assets not expressly defined

The above are the  three types of cryptoa-ssets that the standard expressly mentions, but, as we discussed in the previous section, there are other tokens that, falling into the category of crypto-assets, do not have a specific regulation, such as those they represent (or have) value, but that are not referenced to another asset or are not utility tokens, such as bitcoin. As we have said, it is foreseeable that the European authorities will consider bitcoin as a crypto-asset, despite its deficient definition, as shown in Article 4 of the Regulation, which makes a very brief reference to this category when it refers to “cryptoa-ssets [that] are created automatically through mining as a reward for the maintenance or validation of transactions, or similar technology ”.

2.3 Subjective scope. Types of affected by the regulations

As we will see below, the standard establishes a series of subjective figures on which it imposes various obligations that it details throughout its articulated text. In short, there are three: Cryptoasset issuers, crypto-asset service providers, and, as a catch-all, anyone related to crypto-assets.

2.3.1.- Emisor (issuer)

In principle, an issuer (issuer) should be understood as the person who creates and puts the crypto-asset into circulation, but the definition of the Regulation gives the impression of being a bit broader since the issuer is considered to be the person who “offers” crypto assets to third parties. without more. Then we have another definition that should be considered, that of “offer to the public”, which consists of the offer to acquire a crypto asset in exchange for fiat currency or other crypto assets.

A literal interpretation of this definition would result in anyone selling a crypto asset falling into the category, which doesn’t make much sense. It gives the impression that the standard wants to go beyond the concept of creating the crypto-asset, because when it establishes its obligations it refers both to the issuers that offer the crypto-asset and to those who seek its inclusion in a trading or trading platform for crypto-assets, but it is not clear how far this extension goes. Of course, a more precise definition of this figure would have been preferable.

Then we will see that it is expressly excluded from the regime applicable to “issuers” related to currencies such as bitcoin. The art. 4 establishes some of the obligations to which these issuers are subject and the second paragraph of this precept expressly establishes that said obligations will not be enforceable if, among other assumptions, “the crypto assets are created automatically through mining as a reward for the maintenance or validation of transactions, or similar technology ”. It gives the impression that here you are expressly excluding from the figure of the issuer the miners who are constituted as the first holders of the bitcoins that are generated with their activity and that would formally fall within the broad definition of issuer provided by the standard.

2.3.2.- Crypto-asset services Providers

The art. 3 defines the Crypto-asset Service Provider as any person whose occupation or business is the provision of one or more crypto-asset services to third parties on a professional basis. This last expression is important, as it excludes people who do these activities in an unprofessional way, such as an individual who sells cryptocurrencies sporadically.

        And the activities that are considered crypto-asset services are the following:

  1. The  custody and administration of crypto assets  on behalf of third parties, understood as the custody or control, on behalf of third parties, of the crypto assets or the means of access to said crypto assets, when appropriate in the form of private cryptographic keys;
  2. Operating a  crypto-asset trading  or trading platform, which means managing one or more crypto-asset trading platforms, within which multiple third parties, through purchase and sale orders on crypto-assets, can interact in a way that results in a contract, either by exchanging one crypto asset for another or a crypto asset for legal tender;
  3. The  exchange of crypto assets for fiat currency , whereby contracts for the purchase or sale of crypto assets are entered into with third parties against legal tender, using their  own capital ;
  4. The  exchange criptoactivos by other criptoactivo s , for which contracts to buy or sell criptoactivos held with third against other criptoactivos, using  equity ;
  5. The  execution of orders for cryptoassets  on behalf of third parties that means the conclusion of agreements to buy, sell or subscribe one or more cryptoassets on behalf of third parties;
  6. The  placement of crypto assets , which means the marketing of newly issued crypto assets or crypto assets that are already issued, but not admitted to trading on a crypto asset trading platform, to specific buyers and that does not imply an offer to the public or an offer to existing holders of the issuer’s crypto assets;
  7. The  reception and transmission of orders on cryptoassets  on behalf of third parties, which means the receipt by a person of an order to buy, sell or subscribe cryptoassets and the transmission of that order to a third party for execution;
  8. The advice on criptoactivos , consisting of the offering, giving or accepting provide customized or specific recommendations to a third party, either at the request of the party or on the initiative of the service provider criptoactivos providing advice on the purchase or sale of one or more crypto assets, or the use of crypto asset services; 
  9. The  execution of payment transactions  in tokens referenced to assets , consisting of the activity, carried out on behalf of one or more natural or legal persons, of transferring a referenced token from an address or registered position used to receive crypto assets to another, regardless of the underlying obligations between sender and recipient.

The Regulation then provides in its articulated text a differentiated regime for each of these services.

2.3.4.- Anyone related to crypto assets

Finally, in this section of concepts, we have to refer to the provisions contained in Title VI, relating to the abuse of markets that involve crypto assets and that affects, in a generic way, any person related to crypto assets. We will have the opportunity to analyze this Title more closely, but, basically, it affects the use of privileged information and market manipulation.

And so far this first approach to the draft that has been made public. As discussed, it is foreseeable that it will not be definitively approved until 2022, so there will surely be changes in the process. We are currently working on other articles to comment on the implications that this regulation will have and that we will publish.

[4] https://www.buda.com/blog/categories/juicio/  Especially interesting is the intervention of Guillermo Torrealba (@Guilletorrealba) in the Court of Defense of Free Competition (TDLC) of Chile. A gem that anyone interested in bitcoin cannot miss: https://open.spotify.com/episode/5os43SpBh73FSAeeSeNJVk?si=PudYZ-6uTzGL-SyY5vrpJw  

[6] https://twitter.com/fiscalidadbtc/status/1305211216256806913 Reviewing the definition of virtual currencies of the 5AMLD I see that it speaks of “digital representation of value”, as if it were financial assets. Bitcoin does not represent any value, it * has * value. The difference is important. 

[7] “… the essence of Bitcoin… is to be… a present good, a real asset. In other words, it is not the liability or the obligation of anyone, it is not a contract, nor does its nature or qualities depend on any person, entity or group of entities in particular, but on the market in general. Just as who decides what is gold and what is not gold is the market as a whole, with Bitcoin it is exactly the same ”. Cryptocurrencies and Bitcoin: https://www.juandemariana.org/ijm-actualidad/analisis-diario/criptomonedas-y-bitcoin 

[15] https://twitter.com/AleGuardia/status/1307637568662577158 

[16] Recital 10 (first draft): It admits that the referenced asset tokens may have a “payment functionality” and (Recital 9 second draft) that their objective is for their holders to use them as a  means of payment to buy goods and services and as a store of value.
Recital 22 (first draft) and 25 (second draft) : they could be widely adopted by users to transfer value or as a means of payments.
Recital 61 (first and second draft): asset-referenced tokens can be used as means of payment.

[17] https://cointelegraph.com/news/new-platform-helps-developers-tokenize-their-games-on-ethereum 

Read more
Posted by Javier Maestre | no comments
NEWER OLDER 1 2 … 18 19