Search content
Sort by

Showing 12 of 12 results by z5k_alt
Post
Topic
Board Development & Technical Discussion
Re: Tail emission ideas that retain the 21 million limit
by
z5k_alt
on 29/05/2025, 05:39:38 UTC
Of course it would be. But it is good to have a backup plan, if the community will reject your changes. [...]
Also, you can try to convince the current miners, to accept a proposal, where they will send some of the current coinbase rewards to some future block numbers. Or: you can make a mining pool, which will produce such block templates, and try to encourage miners to join it.
That's maybe more interesting than I thought at first. At least there seems to be an "intermediate" group of possibilities where no hardfork and no mandatory tx fee burn is needed. It would not be a real tail emission but it could achieve a similar effect (to make rewards more predictable).

One could for example nudge people towards such "future-miner-friendly" behavior. For example creating an output type which has half of the weight units of a normal output (and thus costs only half of the fees, or any other percentage), but spends automatically a certain fee to a future block. Or a transaction type. Have to think about that a bit ...

The principle would be: : if you use this kind of output/transaction, you pay a lower fee now, but transfer a small amount of coins to future miners (best would be a fixed block number ahead).

This would make blocks slightly bigger due to this new "discount" but remain probably close to cost-neutral for users if it's designed well (depending on congestion / fee level).

The only "losers" of this model would be normal full nodes, who have to invest a little bit more into hardware, but not by much. If I'm not understanding something wrong.

But that is a problem. If blocks are empty for 4 years, then there would be no tail emission for the next 4 years.
That's true, at least there is a dependency of the past usage. However, if usage is very low, then we maybe don't need that much security.

I checked your demurrage idea and so far I cannot find any real flaw. The only problem is that this would probably never be accepted by the Bitcoin community, because above all the "hodler" fraction would consider it a confiscation. It could however be a measure of last resort -- for example, if a model like the "tail emission based on burnt transaction fees" doesn't work.
Post
Topic
Board Development & Technical Discussion
Merits 4 from 3 users
Re: Tail emission ideas that retain the 21 million limit
by
z5k_alt
on 28/05/2025, 04:02:45 UTC
⭐ Merited by vapourminer (2) ,stwenhao (1) ,ABCbits (1)
Thanks for the example with "1000000 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_TRUE". I briefly thought  would be possible to be claimed by a non-miner user too, but this transaction would simply be double-spent by the miner mining that block, so you're correct imo. I still think doing this via transaction fees would be cleaner.

NameCoin implemented Merged Mining in a wrong way, because it is possible to do 51% attack on NameCoin, even if you cannot do 51% attack on Bitcoin. They should trace the heaviest chain of double SHA-256 headers, and calculate the global difficulty, based on that. Instead, they have their own difficulty, which is one of their mistakes.
Ah, thanks. That's really interesting Smiley

Would miner prefer to have more reward in future, rather than now?
If the protocol prevented them from grabbing that "burnt" part of the transaction fee, then they would not have this option. Or maybe you refer to the possibility that miners could reject that soft/hardfork? I think in this case everything would depend on the signalled support from economic nodes.

The proposal would probably lead to a more stable hashrate even in periods with low onchain activity, so miners should support the proposal also for their own good to make it more predictable. However, maybe 210000 blocks is too long for that period in which the miners "renounce" to a part of their fees. That could of course be optimized.

Regarding your other comment, the problem is that there are always swings in the amount of transaction fees. They may be seasonal or caused by waves of data transactions (Ordinals). And that would make hashrate potentially unstable, or incentive miners to create spam fads.

Merged mining also can be done with Bitcoin layers rather than altcoin. On theory, Bitcoiner would use of one of those Bitcoin layers to make TX with lower fee and faster confirmation. But Rootstock proved it's unpopular option among Bitcoiner.
I think RSK has also the problem that they are considered a centralized entity (instead of a real decentralized sidechain) due to their federation model, and thus they aren't that popular.

Imagine that your employer says to you, "In order to motivate you, we are going to hold half of your salary for 4 years."
See my answer to ABCbits.

Also, consider the steady state -- the amount burned during the current period is the same as the amount paid to you from the previous period. The two cancel each other.
Yes, but that's exactly the idea Smiley

And we could see it also that way: Block rewards that add more coins to the supply (like the current rewards) only dilute the coins of the Bitcoin holders making them less valuable. In reality, it's all about psychology. We feel better if we can say we have "1 BTC" and not "1/19,870,000 of the current Bitcoin supply".

Your demurrage idea is nevertheless interesting, just because of the psychology. Thanks! I'll later perhaps comment on it.

I still feel that confiscating stale addresses is what will be done.
I think this would not solve the problem entirely. The supply which could be "reinserted into circulation" from these stale addresses by paying them to miners would be probably lower every year, as most stale addresses are from Bitcoin's early period (mostly 2009-11).

I think also @satoshifan44 has a point that for the market situation a confiscation of old coins would be very similar to a "honest" tail emission with supply increase. However, just the "semantics" are important, see my answer to @odolvlobo.


Post
Topic
Board Development & Technical Discussion
Merits 3 from 2 users
Re: Tail emission ideas that retain the 21 million limit
by
z5k_alt
on 27/05/2025, 05:09:08 UTC
⭐ Merited by vapourminer (2) ,stwenhao (1)
The first proposal would require some pretty invasive changes to consensus (hard fork), and I'm not sure that the advantages would outweigh the disadvantages.
I guess the requirement to burn part of the fee would be a tightening of rules and thus a softfork. However, the new rules for coinbase transactions, with a subsidy higher than previousy, probably would indeed make previously invalid blocks valid if one only changes the subsidy.

I could however imagine if we perhaps redefine what a block subsidy means perhaps it would be possible to create a softfork. If the subsidy no longer is an independent variable, but instead it is derived from "current maximum supply minus current circulating supply". This would not allow blocks which previously were invalid to become valid.

But either way - when block subsidy goes to zero, wouldn't miners be incentivised to fill their blocks? If we assume full or mostly full blocks and a minimum fee rate (e.g. 1 sat/vB), there will still be a baseline predictable block reward.
The problem is that there may be blocks with much fewer transactions, even zero are possible.

Why burn anything? Just lock your coins to the block height, when you want to make it spendable. We have opcodes for that: there is OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY.
I see two problems with this approach:

- first, this would need a lot of quite complicated outputs which would clutter the UTXO set. Instead, straightforward burning can be done via OP_RETURN (no utxo set cluttering) or even with some hardcoded mechanism like some altcoins like Peercoin had implemented.
- second, how do you know to which miner you're locking the coins to? We'd need a mechanism to lock the coins in a way the coinbase transactions of a block can spend it. It could be possible, however I think the burn idea would still be more straightforward. I'm not sure though Smiley

Doing it per transaction is very inefficient.
Yes, I though this too, I agree. The question would be how the fees can be transferred into a coinbase transaction. But perhaps my answer to @askii could be a part of the solution, if the subsidy variable is redefined.

In that case, you have to use zero satoshis, locked with new Script conditions. Because if you want to make it compatible with the current system, then it should be neutral to the current protocol. And the only sum-neutral element in this case is zero.
That's true that it should be neutral to the current protocol. I wonder however what you mean with "use zero satoshis, locked with new Script conditions". I think that approach instead would need new opcodes. The best thing would be if outputs of these new transactions would look like OP_RETURN for old nodes (about the inputs -- no idea ...). Or am I wrong here?

1. The new network with tail supply can use Merged Mining, if creators would have enough knowledge, to implement it properly.
Yes, of course merged mining would be an alternative, but it would disconnect both tokens as they would live on different chains, which could lead into a slow death of the token (see Namecoin). In theory there are a lot of merged mined tokens already but I currently don't see one strong enough to compensate (for the miners) the losses of later halvings. Most are premined. Namecoin is not, but it has declined a lot, and I think it has no tail emission either ...

Thank you both for your answers!
Post
Topic
Board Development & Technical Discussion
Merits 3 from 2 users
Tail emission ideas that retain the 21 million limit
by
z5k_alt
on 27/05/2025, 00:26:04 UTC
⭐ Merited by ABCbits (2) ,stwenhao (1)
Some people are worried about the wellbeing of mining in the late 21th century if the fee market isn't enough to maintain the hashrate constant. But a tail emission which results in a removal of the 21 million BTC limit, like Monero implemented it, seems to be rejected categorically by Bitcoiners. And I can totally understand why: the 21 million limit is a symbol for Bitcoin's "hard money" character, so it's likely that a removal would result in a mass exodus of investors and perhaps even in a hard fork.

I have recently thought a bit about possible ideas to implement a tail emission, i.e. a continuous block reward, without touching the 21 million limit.

I remembered two ideas which were briefly mentioned I think in other discussions, but I haven't seen them really discussed:

1) Burn a part of the transaction fees and distribute them later (e.g. in the next halving period) in the form of a tail emission. This means that the supply will not be touched at all.

An example: The Bitcoin protocol is modified to require a proof-of-burn of 500 satoshis per kB of each transaction. A regular payment of ~128 bytes would result in about 65 sats as additional fee. In 210,000 blocks of the halving period, we achieve an average of 2 MB blocks, which result in 2100 BTC which can be distributed. This would allow us a block reward of 0.01 BTC for the next halving period without touching the supply.

What is true is that in this proposal we are basically transferring a part of the transaction fees into the future. But there is a crucial advantage for miners: at least a part of the reward would be predictable. And in with "additional" block rewards all we do is diluting the supply anyway.

2) Create a second official Bitcoin token which is distributed in an infinite manner, e.g. 1 per block, to miners, from a specific block on.

The crucial question here seems to be: where should the demand for this token come from, isn't it just an altcoin and would thus be a flawed alternative to simply merge-mine with some altchain?

First, in contrast to a simple altcoin, you would benefit from Bitcoin's blockchain security. An idea could be to restrict this token to simple transactions (and swaps from/to BTC) without any Bitcoin Script programmability, and assign their components a lower weight in the blocks. This would mean that if you transact often, you would like to do it with this token and not with the original BTC. Perhaps even some ideas from modern cryptography (zk proofs?) could be used to decrease the size of transactions further, e.g. creating a kind of "rollup on the BTC chain".

I have already seen similar proposals been mentioned, so they aren't my invention, but they weren't really discussed anywhere (at least I didn't find the discussions, any link would be very useful!). So what I would like to know: Are there there any unsurmountable problems with these proposals?
Post
Topic
Board Español (Spanish)
Re: Bitcoin Pizza Day - 10 Años
by
z5k_alt
on 26/05/2025, 23:33:44 UTC
Se me hace cómico el poder de 1 pizza y la forma en la que ha echo historia.
Algo parecido pasó durante un tiempo con las medias hechas de lana de alpaca, uno de los primeros productos comercializados en un sitio de ecommerce que explícitamente ofrecía BTC como medio de pago.

Eso ya fue unos meses después de la pizza de Laszlo, quizá ya existió en 2010 pero fue en febrero de 2011 que el sitio se volvió viral en Slashdot.

Pero por qué no festejar el "día de las medias de lana de alpaca" también? Otra excusa para concursos, ATHs etcétera Wink


Antes que nada bienvenido al foro, primer cruce de post, en un hilo que dignamente invita a comer Pizza como tributo, Smiley ya pagar con bitcoin es cosa de cada quien, el hecho simbólico es lo que nos trae cada año a recordarlo, dudo mucho que hoy algunos quieran comprar Pizza con bitcoin estando en modo ATH  Smiley

Gracias ---> Wink

Al final en casa comimos una pizza casera que hice yo, pero no participé de ningún concurso. En mi ciudad no encontré nada para comprar una pizza con BTC, al menos no sin pasar por una gift card o algo similar.
Post
Topic
Board Español (Spanish)
Re: Hilo de seguimiento del precio del bitcoin a corto plazo
by
z5k_alt
on 26/05/2025, 23:11:44 UTC
Esto es un poco off topic, pero ¿te importa decirnos de quién eres alt? No estás obligado a decirlo pero como pones alt en tu nick me pica la curiosidad.
De alguien que desapareció misteriosamente del foro español Tongue (no el de los turbo méritos). No la usaré para infringir ninguna norma (no es un test con IA o algo por el estilo, simplemente quería tener una cuenta "no valiosa"). Smiley
Post
Topic
Board Español (Spanish)
Re: ¿La IA un peligro para Bitcoin?
by
z5k_alt
on 22/05/2025, 22:20:37 UTC
En cuánto a la fuerza bruta no sé cuán efectiva es a día de hoy y si es real que hay gente que se hace con saldos grandes de BTC,
No hay forma de craquear a una dirección de Bitcoin que fue creada correctamente, es decir cuando la clave se obtuvo partiendo de datos completamente aleatorios.

La "dirección puzzle" (ver todas en btcpuzzle) más difícil que se ha obtenido hasta ahora a través de fuerza bruta es el puzzle 130, tenía la clave privada 000000000000000000000000000000033e7665705359f04f28b88cf897c603c9. Como ves es mucho más fácil encontrar esta clave que una clave "real", ya que se sabía que iba a tener que tener 31 ceros al comienzo. Si bien pareciera que ya estarían "a mitad de camino" para craquear una dirección de verdad, esto no es así, porque cada bit duplica la dificultad, y cada letra/número de la clave hexadecimal contiene 16 bits, es decir por cada letra más que uno tenga que buscar de la clave privada, craquear es 216 (65536) veces más difícil.

Según la ley de Moore, la capacidad computacional de un microchip se duplica cada 1-2 años, pero aún así, se ve que tardaríamos varios años para el próximo puzzle si no hay algún salto cuántico como lo sería la computación cuántica. Esta si puede acelerar la tarea.

Además, por una razón que no recuerdo, esta clave del puzzle 130 era más fácil de encontrar que otras de similar número de bits (por ejemplo el puzzle 128 y 129, que siguen sin solución). En realidad las que se craquearon realmente son las que tienen hasta 70 bits, el puzzle con 71 bits sigue sin resolver, y nuevamente, el 71 tiene el doble de la dificultad del puzzle 70.

pero, gracias a Dios, que, por ahora, la IA no tiene capacidad de crackear el ecosistema Bitcoin y su empleo es más para mera analítica y procesamiento e interpretación de datos.
Lo único que podría pasar es que una IA "científica" ayude a alguien a encontrar un algoritmo de "fuerza bruta" más eficiente. Pero para usar el algoritmo, el LLM no sirve, hay que usar una supercomputadora o un botnet tradicional optimizada para dichas tareas.

Complementariamente, tengo la duda de lo que representa Bech-32, P2SH y Vanity en cuánto a las direcciones y claves privadas y si hay alguna diferencia a nivel de encriptación o sólo existe esa diferenciación nominal.
Bech-32 y P2SH son simplemente formatos distintos pero las claves son igual de difíciles de craquear. Las Bech-32 son las direcciones "comunes" desde que se implementó Segwit en 2017. Las P2SH son direcciones que no corresponden a carteras comunes, sino a un script con un contrato, como los contratos multifirma (multisig). Pero las claves privadas necesarias para mover los coins asociados a estas address tienen la misma longitud.

En cuanto a Vanity, ahí sí uno podría pensar que la tarea sea un poco más fácil. Vanity son direcciones que parecen contener una "palabra" o un "nombre" concreto, por ejemplo una dirección que comience con bc1bitcoinpizzaday..... Si necesito que mi dirección sea por ejemplo algo como bc1bitcoinpizzaday...., hay menos address que cumplen con esa condición que si solamente busco una que comience con bc1b..... Sin embargo tampoco son tan inseguras las direcciones vanity porque las address no tienen una relación directa con las claves privadas sino que son un hash de la clave pública.

Es decir con la clave privada creas la clave pública, de ésta hacés un hash y ahí obtenés la address. Y esta operación no se puede hacer de forma inversa. Es decir conociendo la dirección no me permite obtener ni la clave pública ni mucho menos la privada. Y por tal razón, que la address contenga bc1bitcoinpizzaday no quiere decir necesariamente que haya algún patrón que se pueda usar para acelerar la búsqueda de la clave privada con fuerza bruta.
Post
Topic
Board Español (Spanish)
Re: Hilo de seguimiento del precio del bitcoin a corto plazo
by
z5k_alt
on 22/05/2025, 18:56:10 UTC
¡Feliz ATH de mi parte también! Wink

Lo mejor es que pasó en el "día de la Pizza", uno de los feriados más venerados por muchos Bitcoineros je (bah, en realidad el ATH se batió ayer pero hoy sigue habiendo más ATHs ...). Y nos hace recordar que el Bitcoin también puede ser "efectivo P2P", no solo una forma de acumular valor.

Yo honestamente me esperaba rangos de precios más modestos con todo el caos que se está produciendo en los mercados debido a los aranceles y a la volatilidad que están experimentando los stocks de los estados Unidos.
Para mí hay dos razones. Por un lado, el tema de los aranceles desapareció nuevamente de los titulares cuando Trump anunció negociaciones con muchos países, hasta con el "archienemigo" China. Y luego la esperanza por las negociaciones de paz en Ucrania cambió el rumbo de los mercados. Quizá también el alivio que el "crac" en el caso de Bitcoin fue muy moderado.

La paz en Ucrania se sigue haciendo esperar, pero los mercados funcionan así: una vez que se va el miedo, hay cada vez más gente que vuelve a entrar para no perderse la subida. Además hubo noticias positivas del mundo Bitcoin también, como la reserva en New Hampshire y quizá en Texas.
Post
Topic
Board Español (Spanish)
Re: ¿Hackeo cuántico a Bitcoin?
by
z5k_alt
on 22/05/2025, 18:46:01 UTC
Bastante alarmista y sensacionalista el artículo, casi se podría hablar de FUD.

90 bits de RSA no son prácticamente "nada", es una clave que una supercomputadora clásica también puede craquear sin problemas, de hecho ya en 2007 cuando terminó la RSA Factoring Challenge ya se factorizaron (="craquearon") claves RSA de más de 500 bits, el récord fue de 829 bits según el artículo de Wikipedia. Y una de 100 bits ya se factorizó en 1991.

La diferencia con 2048 o 4096 bits (las que se usan habitualmente) es abismal. Y en este experimento de la Universidad de Shanghai se usó también bastante potencia "clásica", combinada con el D-WAVE.

Sin embargo, hay que seguir estando atento. Y hay maneras de actualizar el protocolo de Bitcoin para incluir operaciones post-cuánticas. Simplemente habría que añadir una instrucción (un opcode) que funcione como alternativa a OP_CHECKSIG (que es la que chequea la firma digital ECDSA). Este mecanismo puede coexistir con el OP_CHECKSIG "antiguo" durante un tiempo, como lo propuso Jameson Lopp hace poco.

No creo que haya resistencia por parte de los mineros para una actualización de este tipo. Eso es lo que más me molesta del artículo: que quiere hacernos creer que Bitcoin sería más vulnerable que el mundo de las finanzas clásicas, cuando probablemente es al revés, porque la banca tradicional es muy fragmentada y por ende más vulnerable al error humano ("todavía hay tiempo para esta actualización ..."), mientras que en el caso de Bitcoin tenemos la seguridad de los "1000 ojos" (en el caso de BTC son muchos más) por ser de código abierto.
Post
Topic
Board Español (Spanish)
Re: Hilo de seguimiento del precio del bitcoin a corto plazo
by
z5k_alt
on 18/05/2025, 17:00:41 UTC
Pero bueno la cuestion es que venimos notando un enorme numero de empresas entrando al BTC con grandes sumas y la gran pregunta es, Quien esta vendiendo para sostener el precio en estos margenes sin que se dispare?
Es que un par de decenas de miles de BTC no son nada comparado con el volumen de Bitcoin que se tradea todos los días.

En Coingecko, por ejemplo, hoy el volumen es de 20 mil millones de USD, es decir casi 200 mil BTC. Y eso que es domingo. Los días de semana habitualmente son 25-40 mil millones.

Si una empresa compra 20k o algo así, eso quizá puede hacer subir la cotización diaria un poco, pero el efecto a mediano/largo plazo es prácticamente insignificante.
Post
Topic
Board Español (Spanish)
Re: Bitcoin Pizza Day - 10 Años
by
z5k_alt
on 16/05/2025, 22:06:06 UTC
Estaba con la duda si este año podré celebrar el Día de la Pizza con una pizza pagada con BTC Wink

Estuve consultando BTC Map, y desafortunadamente no encontré nada cerca.

¿Alguien conoce más sitios web con lugares que acepten Bitcoins, quizá alguno que abarque el mundo hispano? Conozco el hilo de Bitcointalk pero no tiene nada.
Post
Topic
Board Español (Spanish)
Re: ¿La IA un peligro para Bitcoin?
by
z5k_alt
on 16/05/2025, 21:56:15 UTC
No creo en absoluto que esto sea un peligro real. Quiero ver ejemplos.

LLMs como DeepSeek o ChatGPT funcionan como un buscador un poco más "inteligente", su base de datos se basa en publicaciones humanas (la web, libros etc.). No tienen capacidades de atacar claves con "fuerza bruta", porque su algoritmo está optimizado para otra cosa [1]. Lo único que puede hacer es recopilar claves existentes que hayan sido publicadas en algún momento.

Es remotamente posible que una de estas claves todavía tenga BTC, porque quizá las IA sean las únicas que hayan "buscado" [2] estas claves, pero esto no cambia nada de lo que escribí arriba.



[1] Aún si lo fueran, Bitcoin es incraqueable; todos los que dicen que "hackearon Bitcoin" con Kangaroo u otro algoritmo "especializado" mienten, sus "logros" se limitan a claves de entropía deliberadamente baja, principalmente las "direcciones puzzle" que fueron generadas hace unos años justo para probar hasta dónde llega la potencia de la fuerza bruta.

[2] Me refiero aquí a las claves que hayan sido obtenido a través de los buscadores que llenan las bases de datos para las IIAA. (LLM's)