El código fuente del terminal de recepción de pagos de XMR ya fue publicado｜El aviso de “cero confirmaciones” no es el pago final｜Alrededor de 550 dólares, esperaré primero
Mi postura es observar primero, no tratar como una nueva demanda de compra de Monero el terminal de recepción que aún no se ha probado en el mundo real. Es valioso dar seguimiento a la herramienta de pago, pero “mostrar que el pago fue exitoso” y “que los fondos ya recibieron confirmación en el bloque” deben verse por separado; esto es más importante que ponerle una etiqueta optimista al precio con prisa.
Los hechos: Monero Observer reportó el 23 de septiembre que el desarrollador fujimoto44 publicó el código fuente de XMR POS. El repositorio de GitHub del desarrollador describe el estado actual como v0.9 y que el hardware todavía no se ha probado; el desarrollo se hizo en un entorno de escritorio y en la red de pruebas de Monero. Es un proyecto de desarrollo comunitario, no un anuncio oficial de Monero sobre una actualización de la red principal, y no se puede afirmar a partir de esto que las tiendas ya hayan desplegado masivamente. Leí de forma cruzada la documentación del proyecto y el archivo SECURITY; la discusión de abajo trata sobre el diseño público y sus límites, no es una conclusión de una auditoría independiente.
Intenta incorporar la fijación de precio en fiat, el QR de pago, la identificación de la transacción y el registro de recibos dentro del flujo de cobro para pequeños comercios. La parte más fácil de malinterpretar es el modo de “cero confirmaciones” por defecto: si se encuentra una transacción que coincide en el mempool, se puede mostrar el pago como exitoso; si se configura que se requieren más confirmaciones, se espera la confirmación del bloque. Este diseño reduce el tiempo de espera del cliente, pero no elimina el riesgo de doble gasto de transacciones no confirmadas. Los pequeños cobros de comida rápida y la entrega de mercancía de alto valor soportan pérdidas distintas; no se puede aplicar el mismo criterio de “liberación”.
Otro límite es el de permisos. El terminal utiliza direcciones y una clave privada de visualización; por diseño no tiene permisos para gastar fondos. Pero el archivo de seguridad advierte con claridad que la filtración de la clave de visualización revelaría el historial de ingresos del comerciante. “No puede transferir monedas” no equivale a “no hay pérdida de privacidad”. El comerciante también debe verificar el origen del software, la confiabilidad del nodo y el tratamiento de los registros; no se puede omitir la verificación de seguridad solo porque sea open source o porque se vea una pantalla de “éxito”.
¿Por qué se relaciona con XMR? Un flujo de recepción más fluido podría reducir la barrera de adopción; esa es una inferencia de mecanismo. Sin embargo, la necesidad real aún depende de pruebas del hardware, el uso de los comercios y la retención. Incluso si alguien paga con XMR, el comercio que recibe podría volver inmediatamente a fiat, así que el aumento en número de operaciones no equivale automáticamente a una compra neta sostenida. Aquí no hay datos confiables que demuestren que la publicación de ese código haya traído fondos adicionales, y tampoco se puede atribuir las subidas o bajadas posteriores a él.
Sobre el precio: la instantánea de re-chequeo de Kraken para XMR/USD en esta ronda ronda los 549.83 dólares; el rango de 24 horas va de 540 a 562.95 dólares. Actualmente sigue dentro del rango, así que no se puede escribir como que ya se superó. En el corto plazo, miraré si 555 puede obtener confirmación de cierre por hora; 560 y 563 están cerca de los objetivos planeados; 546 y 540 por debajo se usan para acotar el riesgo. Son líneas de observación del trading, no una estimación del valor del proyecto.
Si fuera mi propia operación, no participaría ahora; la posición es cero. Solo consideraría intentar con spot sin apalancamiento: cierre horario por encima de 555, luego retroceso a 552–555 y que se mantenga, y que el canal de operaciones esté normal; entonces entraría con un máximo del 0.4% de los fondos totales. En 560, reduciría a la mitad; en 563, cerraría el resto. Si después de operar cae a 546, saldría con stop de inmediato; o si dos velas horarias consecutivas cierran por debajo de 552, saldría por completo. Si antes de entrar el precio cae por debajo de 540, cancelaría el plan. Si aparece alguna falla en la identificación del pago o en la seguridad de la clave, también retiraría la decisión de adoptar mejoras, sin seguir aumentando por el “relato del pago”. Si no se activa nada, no hay operación; no se registra como una entrada, y menos como ganancia.
Fuente: descripción del proyecto en GitHub del desarrollador y los archivos SECURITY, el reporte de Monero Observer del 23 de septiembre, y el listado público de Kraken. #XMR
Lo anterior es solo una observación personal del mercado y no constituye asesoramiento de inversión.
Mi postura es observar primero, no tratar como una nueva demanda de compra de Monero el terminal de recepción que aún no se ha probado en el mundo real. Es valioso dar seguimiento a la herramienta de pago, pero “mostrar que el pago fue exitoso” y “que los fondos ya recibieron confirmación en el bloque” deben verse por separado; esto es más importante que ponerle una etiqueta optimista al precio con prisa.
Los hechos: Monero Observer reportó el 23 de septiembre que el desarrollador fujimoto44 publicó el código fuente de XMR POS. El repositorio de GitHub del desarrollador describe el estado actual como v0.9 y que el hardware todavía no se ha probado; el desarrollo se hizo en un entorno de escritorio y en la red de pruebas de Monero. Es un proyecto de desarrollo comunitario, no un anuncio oficial de Monero sobre una actualización de la red principal, y no se puede afirmar a partir de esto que las tiendas ya hayan desplegado masivamente. Leí de forma cruzada la documentación del proyecto y el archivo SECURITY; la discusión de abajo trata sobre el diseño público y sus límites, no es una conclusión de una auditoría independiente.
Intenta incorporar la fijación de precio en fiat, el QR de pago, la identificación de la transacción y el registro de recibos dentro del flujo de cobro para pequeños comercios. La parte más fácil de malinterpretar es el modo de “cero confirmaciones” por defecto: si se encuentra una transacción que coincide en el mempool, se puede mostrar el pago como exitoso; si se configura que se requieren más confirmaciones, se espera la confirmación del bloque. Este diseño reduce el tiempo de espera del cliente, pero no elimina el riesgo de doble gasto de transacciones no confirmadas. Los pequeños cobros de comida rápida y la entrega de mercancía de alto valor soportan pérdidas distintas; no se puede aplicar el mismo criterio de “liberación”.
Otro límite es el de permisos. El terminal utiliza direcciones y una clave privada de visualización; por diseño no tiene permisos para gastar fondos. Pero el archivo de seguridad advierte con claridad que la filtración de la clave de visualización revelaría el historial de ingresos del comerciante. “No puede transferir monedas” no equivale a “no hay pérdida de privacidad”. El comerciante también debe verificar el origen del software, la confiabilidad del nodo y el tratamiento de los registros; no se puede omitir la verificación de seguridad solo porque sea open source o porque se vea una pantalla de “éxito”.
¿Por qué se relaciona con XMR? Un flujo de recepción más fluido podría reducir la barrera de adopción; esa es una inferencia de mecanismo. Sin embargo, la necesidad real aún depende de pruebas del hardware, el uso de los comercios y la retención. Incluso si alguien paga con XMR, el comercio que recibe podría volver inmediatamente a fiat, así que el aumento en número de operaciones no equivale automáticamente a una compra neta sostenida. Aquí no hay datos confiables que demuestren que la publicación de ese código haya traído fondos adicionales, y tampoco se puede atribuir las subidas o bajadas posteriores a él.
Sobre el precio: la instantánea de re-chequeo de Kraken para XMR/USD en esta ronda ronda los 549.83 dólares; el rango de 24 horas va de 540 a 562.95 dólares. Actualmente sigue dentro del rango, así que no se puede escribir como que ya se superó. En el corto plazo, miraré si 555 puede obtener confirmación de cierre por hora; 560 y 563 están cerca de los objetivos planeados; 546 y 540 por debajo se usan para acotar el riesgo. Son líneas de observación del trading, no una estimación del valor del proyecto.
Si fuera mi propia operación, no participaría ahora; la posición es cero. Solo consideraría intentar con spot sin apalancamiento: cierre horario por encima de 555, luego retroceso a 552–555 y que se mantenga, y que el canal de operaciones esté normal; entonces entraría con un máximo del 0.4% de los fondos totales. En 560, reduciría a la mitad; en 563, cerraría el resto. Si después de operar cae a 546, saldría con stop de inmediato; o si dos velas horarias consecutivas cierran por debajo de 552, saldría por completo. Si antes de entrar el precio cae por debajo de 540, cancelaría el plan. Si aparece alguna falla en la identificación del pago o en la seguridad de la clave, también retiraría la decisión de adoptar mejoras, sin seguir aumentando por el “relato del pago”. Si no se activa nada, no hay operación; no se registra como una entrada, y menos como ganancia.
Fuente: descripción del proyecto en GitHub del desarrollador y los archivos SECURITY, el reporte de Monero Observer del 23 de septiembre, y el listado público de Kraken. #XMR
Lo anterior es solo una observación personal del mercado y no constituye asesoramiento de inversión.
