@MinoRaiola: So ganz stimmt die Meldung nicht.

Es gibt laut der vorgeschlagenen Reform in Argentinien mehr Freiheiten beim Abschluss von Verträgen. Das hat erstmal nichts mit Bitcoin zu tun. Sondern es heißt, es können Verträge auch in Sachwerten beliebiger Art aufgesetzt werden. Also auch solche, die in Bitcoin beglichen werden müssen - nicht (wie bisher möglich) zum Preis des Bitcoin in der Landeswährung zu einem irgendwie gearteten Wechselkurs.

Mit einer irgendwie gearteten Anerkennung als gesetzliches Zahlungsmittel hat das nicht wirklich was zu tun. Mondino hat auch "Liter Milch" als Beispiel genannt. Ist also jetzt Milch auch gesetzliches Zahlungsmittel?

Im Übrigen war Bitcoin als Zahlungsmittel in Argentinien schon immer erlaubt - mit Ausnahme von Produktexporten, die nach einem streng regulierten Schema durchgeführt werden mussten.

Es ist im übrigen unsicher ob die Reform nicht vom Kongress kassiert wird. Die Regierung (Allianz La Libertad Avanza) hat nur ca. 15% der Sitze, 15 weitere Prozent gehören einer Partei (PRO) die zustimmen könnte, weil Teile der Partei die Regierung unterstützen, aber der Rest lehnt das Reformpaket ab, weil es als Notstandsdekret deklariert wurde. Notstandsdekrete darf der Kongress nicht verändern, nur annehmen oder ablehnen. Da das Reformpakert ca. 300 Gesetze ändern oder annullieren würde, ist ein Notstandsdekret nicht wirklich der vom Gesetzgeber "gewollte" Weg.

Yes, but compared to the current policy, it's not correct to call it a "tax" or "discrimination", because nothing would have been changed and these transactions are even favoured because blocks would be, on the whole, emptier. And if the blocks are not full, like it was the case many times even in 2022/early 2023 before Ordinals came up, then there is no tax at all.

With the other part of your post, you are correct - it's possible that fee income goes down if demand is not high enough. To avoid this, in the block size debate models for a flexible block size were proposed, where the maximum weight is adjusted by demand or there are incentives to miners to adjust the blocksize carefully if needed. Monero (which was already mentioned in this thread) is an example how such a policy could look like. In contrast to Monero, however, Bitcoin needs slightly stricter parameters, because of Monero's tail supply which ensures they get rewards infinitely, so the necessity of a fee market isn't that pronounced on XMR.

So you could combine the "payment transaction discount" with a "flexible blocksize" policy. In this case, if the minimum max size is set too low, then the contract/Ordinals transactions could pay a "tax" indeed even compared to today. I think it would make sense, if such a change was decided, to ensure the minimum max block size is never lower than the current 4 vMB.

Anyway, such a policy is, again, meant as a possibility if there is general consensus in the community of the need for a block size increase, and that would be decided only if demand justifies it. Simply: instead of moving max block size "straight" to 8 MB, one could change the weight formula in a way simple payment transactions take less weight and pay half the fees.

Even if the current fee situation is a bit annoying, in my opinion we have not reached the point, and my hope is we'll never need it due to sidechains/LN improvements.

Censorship? I don't think so. But it would be of course arbitrary. It would be a bold statement screaming "We want Bitcoin to be a payment coin, not a contract coin nor data cloud storage platform!".

However: Those who use other scripts than those benefitting from the additional discount would not be punished at all. They would even be benefitted partly too, because if "payment-style" transactions have less weight, the weight which is then "liberated" can also be used for things like Ordinals and it's likely that initially they'll pay less fees too. But payment transactions would benefit proportionally much more from such an hypothetical change.

Also, it's not the first time such a "discrimination of a particular user group" happened. When OP_RETURN was introduced it was limited to 80 bytes and to one output per transaction - because the devs thought that larger data storage should be disincentived.

I want to point out however that this "proposal" is only an example for a possible path which could be explored, it's not that myself I would favour such a rule over other possibilities (my own opinion is actually that it's better to concentrate on solutions like sidechains and LN, and in the long term: use a zero-knowledge-based approach to verify the blockchain, which would liberate nodes from the need to store all data). It's to show the theoretical possibility to increase the block size without making data storage-type spam easier. Personally I think it's too difficult to really determine which are "desired" or "undesired" kinds of usage. However: If such a change would be necessary, it could be probably applied via soft fork - I see no technical problem.

Well first these protocol changes would have to be approved by miners. Miners would probably not necessarily against such a policy: while the average fees would level down a bit, there are more transactions they could fit in a block, so the total fees collected per block could increase. A "VIP club" like the one you describe, in contrast, would not make sense for miners. They don't care about the amounts transacted, they care about the fees.

I get what you probably mean though, it could lead to endless senseless discussions about "desired" and "undesired" use cases. So the best thing would actually if such a discount could be applied to transactions which effectively have a resource-saving function (like Segwit had.)

Of course one could include transactions with OP_CSV and multisig, which are required for Lightning, to the list of discounted transaction types. But see my response above to mikeywith: I don't think this approach is ideal.

That wasn't the case initially. It was even argued in this thread (and/or other discussions?) that despite of the high transaction count, the fee level stood relatively low (often below 20 sat/vByte) for a long time. IMO it's the bubbles some of the tokens have seen that led to the big fee increase and thus to the sensation that Ordinals users are fee insensitive.

You're largely correct, while Ordinals transactions are not occupying as much space as some months ago, there was an increase since last weekend, where again some 300.000 transactions per day were BRC-20. In addition, there probably was an increase of "normal payment transactions" too due to seasonal reasons.

There could however be a way to circunvent the problem of space filling by Ordinals and other data-spam transactions: create a special discount for simple payment transactions which only consist of inputs and outputs with the simplest possible P2WPKH script.

Currently we have a two-tier discount scheme due to Segwit:

Tier 1: Segwit witness data (weight in vBytes = weight in bytes)
Tier 2: All other transaction data  (weight in vBytes = 4 * weight in bytes)

We could advance to a three-tier scheme:

Tier 0: Simple payment transactions (weight in vBytes = 0,5 * weight in bytes), i.e. they would have a weight of half of the Segwit witness data*
Tier 1: Other Segwit witness data (weight in vBytes = weight in bytes)
Tier 2: All other transaction data (weight in vBytes = 4 * weight in bytes)

This would have the effect that we would increase the maximum block size to a maximum of 8 MB, but only if it was filled exclusively by Tier 0 data.

Of course that would not be an easy change. In the case of Witness data, there's actually a reason why it got the discount: because in the long run it is cheaper to store, process and transmit this kind of data as Segwit Witnesses are a separate section in transactions and don't clutter the UTXO set. In contrast, the "Simple Payment Transaction discount" would be completely arbitrary, it isn't cheaper to process. It would be a convention to favour this kind of transaction and to make payments cheaper than other contracts.

If there's any problem with that approach please criticise it, after all I'm not really an IT expert.  (A point I've noticed myself is that if implemented that way is that Lightning transaction and sidechain peg-ins/outs for example would not benefit from this discount. They could be included but that would make the measure very complex.)

(An alternative could be to add the Segwit discount to all parts of the transaction if it only contains transaction data payments (edited: previous sentence made no sense ). This would not increase the block size but would fill the 4 MB more often.)

Discussion about mixers is allowed, as long as it's no advertising and not done by the mixer representatives themselves (not that I'm happy about that restriction, but it could be worse). I quote theymos:


URLs will be filtered, but the OP doesn't talk about "banning" anyone because of linking to mixers (besides mixer representatives) in a post anymore. I guess however means that wearing a mixer avatar to bypass the URL filter could be against forum rules and ban-worthy.

Teniendo en cuenta ese "problemita" me sorprende un poco que en el proyecto de Marcos Paz los pagos se limiten a solamente tres criptos (por ahora):

Bitcoin y Ethereum son justamente conocidas por sus fees altas, y USDC ... depende en que cadena. Está bien que sean las más aceptadas, pero si se busca generar un sistema popular de pagos, me parece que tienen que añadir otras opciones.

Habría que recomendarles que añadan quizá algo como Bitcoin-Lightning, LTC, o Avalanche ...

Estuve viendo si ya encuentro la app en algún lado del sitio del municipio, pero todavía no la encontré. En el mismo artículo en la plataforma web de Marcos Paz dice que estará "dentro de poco". Lo que sí encontré es el sitio de la criptomoneda Activos, pero no da muchas informaciones sobre las especificaciones técnicas del token. Juzgando por la página de Koibanx tiene pinta de ser una blockchain privada o semi-centralizada, aunque tampoco hay mucha información en este sitio.

Comparto la hipótesis. Los traders nuevos, y por ende las manos más débiles, son los que en general almacenan todos los BTC en los mismos exchanges, y no les afecta en nada la escalada de fees. O bien especulan con altcoins que no tienen el problema.

El camino hacia la autocustodia en muchos casos es largo, e implica acumular algo de experiencia con los vaivenes de la cotización, esto ayuda a no caer en pánico cada vez que la cotización baje. O sea, los que no pueden mover los fondos ahora por los costos, son en general los que son menos propensos al pánico, mientras que los que sí lo son, los pueden vender en cualquier momento.

Hay un grupo en el que sí podría influir el nivel, que son los hodlers pequeños pero con algo de experiencia. Si bien éstos no son especialmente vulnerables al pánico, les gustaría de vez en cuando vender algo de BTC para toma de ganancias o comprar algún bien y servicio. Y quizá por el nivel de fees actual lo piense dos veces. Pero creo que este grupo es demasiado pequeño como para influir masivamente en la evolución de la cotización.

Podríamos inducir que si en un futuro la tendencia hacia la autocustodia crece, el panorama podría cambiar, pero creo que en este caso la cadena ya se llenaría aún sin Ordinals ni nada por el estilo, y entonces la gente usaría Lightning o alguna cadena lateral, haciendo que el efecto también se debilite.

El único desarrollador que hizo varios intentos de bloquear Ordinals, con distintas estrategias, es Luke-Jr. Creo que DdmrDdmr, si mal no recuerdo, ya había posteado sobre su mecanismo que publicó en Bitcoin Knots (un cliente alternativo a Bitcoin Core dónde "manda" Luke). En Bitcoin Core este cambio fue rechazado en septiembre. (Edit: Sí, ya discutimos el tema, a partir de este post).

El problema es siempre el mismo: No hay mucho que se pueda hacer sin cambiar radicalmente el mecanismo de funcionamiento de Bitcoin.

Si bien se puede hacer algo contra inscripciones grandes, tales como imágenes, videos y audio, limitando la cantidad de datos por transacción o por output (es la estrategia de Luke), esto solo resuelve una pequeña parte del problema, que ya casi no incide en el nivel de congestión. Además hay mineros y pools que ignoran este tipo de limitaciones, que no son duras sino que son una convención de "standardness", un bloque que contiene una transacción más grande de este límite sigue siendo válido (80 bytes por transacción en el caso de OP_RETURN; lo que hizo Luke era aplicar esta limitación a los datos de Taproot también).

Y el problema actual son las transacciones BRC-20 que son más pequeñas que este límite (50-60 bytes de inscripción por transacción). Eso ya lo discutimos hasta el hartazgo tanto acá como "en el norte", por eso creo que no hace falta repetir los argumentos.

Ahora en las discusiones en el subforo en inglés hubo un par de propuestas que sí podrían lidiar con el problema, pero cambiarían el funcionamiento de Bitcoin.

Una, el cambio "menos radical", sería cambiar el esquema del "Segwit discount". Actualmente hay transacciones que pagan menos comisiones por byte que otras, que son las que usan "testigos" (Witness) del sub-protocolo Segwit. Las transacciones Ordinals normalmente usan este tipo de inputs y outputs por ende también se benefician.

Tranquilamente se podrían añadir otros tipos de transacciones que podrían "declararse" más baratas aún. Esto se conseguiría si se baja su "peso" en bytes virtuales (vBytes). Por ejemplo, yo en un momento propuse que se añada una clase de transacciones simples de pago, que consista solamente de inputs y outputs del tipo Segwit, sin OP_RETURN y sin contratos que no sean el simple chequeo de firmas, y darles un descuento adicional. (En realidad no es tan fácil, porque lo que se beneficia con descuentos actualmente no son categorías de transacciones, sino elementos de las transacciones. Pero sería posible.)

De hecho esto significaría que el tamaño de los bloques pueda aumentar. Si declaramos que las transacciones de este tipo solo pesen la mitad de las transacciones Segwit "comunes", el tamaño máximo de un bloque podría aumentar al doble, es decir teóricamente hasta 8 MB (el límite actual es de 4). Como ya dije no es tan simple pero para tener una idea

La segunda posibilidad es restringir el protocolo.

Lo que se ha propuesto pero actualmente no ayudaría en nada es dar marcha atrás con Taproot. Simplemente el spam se buscaría otro tipo de protocolo sin Taproot, como Doginals DRC-20 o Counterparty.

Lo que sí ayudaría es cambiar al protocolo de Monero o Grin. En estos protocolos la cantidad de datos arbitrarios que se pueden almacenar en la blockchain es mínima. Es decir las transacciones BRC-20 serían 10 o más veces más caras (en el caso de Grin probablemente 100 veces) que las transacciones comunes de pago. Creo que ahí sí lo pensarían dos veces los spammers si realmente conviene especular con tokens.

Esto sería un cambio extremamente radical: No sería posible ni siquiera Lightning, las cadenas laterales tampoco.

La tercera posibilidad, la que favorezco yo, es avanzar de una vez con la flexibilización del Script (el lenguaje de programación de Bitcoin) para permitir cadenas laterales descentralizadas. Con una sóla cadena lateral podemos multiplicar por cien o más la capacidad de la blockchain sin tener que aumentar el tamaño de los bloques. Existen varias propuestas, algunas ya funcionan en Ethereum, como los rollups, y otras, como Drivechain, solo existen en testnets de distintas altcoins, pero ya se cuenta con algo de experiencia. Hace poco vi una propuesta nueva llamada L2Ordinals para que al menos los Ordinals se puedan pasar a una cadena lateral, sin perder seguridad. No la he investigado todavía, pero podría ser interesante. Sobre estos temas si se está discutiendo en la lista de correos bitcoin-dev, pero la discusión va lenta.

@DdmrDdmr: Observé lo mismo. Se parece confirmar la tendencia que los Ordinals ahora se concentran durante los fines de semana (y nos c*gan los días que tradicionalmente tenían comisiones más bajas ). Hubo una tregua hasta el jueves pasado (que se ve en el gráfico en mi post anterior), pero a partir del viernes volvieron a ser más de 300 mil transacciones por día con inscripciones.

Mirando el precio de los tokens principales BRC-20 parece que el pico máximo de la burbuja puede haber pasado, pero todavía no me quiero ilusionar, es posible que sea simplemente una pequeña ola de toma de ganancias por la cercanía de los feriados navideños, como la que vivió Bitcoin la semana pasada.

Lo que todavía no registré en Ordiscans es una ola de inscripciones del supuesto "sucesor" del BRC-20, CBRC-20 (que es un poquito más eficiente con el espacio). No se si siquiera ya existe una implementación de este formato. Quizá este estándar provoque la próxima burbuja (probablemente en enero).

Mein Bauchgefühl sagt mir, dass nach der doch recht starken Phase über 40k die Situation eher zum Bullischen geändert hat. Zwar ist immer noch ein Dip unter 40k wahrscheinlich. Aber 32k scheint doch etwas tief gegriffen (das hätte ich erwartet, wenn der Kurs nicht über 42k gestiegen wäre). Für mich wäre der heißeste Kandidat für einen Abpraller der Bereich 36-38k, wo sich der Kurs ja ein paar Tage aufgehalten hat.

theymos ha publicado una hoja de ruta:

El primero de enero habrá las siguientes medidas:
- Filtros de URL comenzarán a funcionar
- Se clausurarán (pero no se borrarán por ahora) los hilos ANN de las batidoras.
- Las cuentas de usuario de las que se sabe que son de representantes de batidoras, no podrán postear más, solamente recibir y enviar PM (por cuestiones de soporte que quedaron pendientes).

Después de unos días se blanquearán los espacios de firmas que todavía lleven anuncios de batidoras.

Con los hilos de las campañas no serán tan estrictos, quedarán abiertos pero se clausurarán si son usados para promocionar a alguna batidora.

En fin, me parece razonable que lo haga así, habla mucho menos de baneos de usuarios en los últimos post, y más de restricciones técnicas (filtro de URL etc.). Lo que sí, ha puesto en claro que no se tolerarán avatares de batidoras de frutas; estas serían una forma de escaparse a la prohibición ya que los filtros no los pueden detectar.

En cuanto a la medida en si, no me gusta demasiado, porque creo que usar una batidora debería ser hasta un derecho humano por lo públicamente accesibles que son los datos de la blockchain, pero la entiendo. No creo que sea un "antes y después", ya que anteriormente ya se prohibieron campañas sobre servicios que en gran parte del mundo son ilegales, como servicios DDoS.

For me, that's clearly an exchange. If you get a private key, then you have got coins - that means, you just have exchanged Bitcoin to Monero. These coins are now under your control. While in the exchange process, the exchanger could have stolen your coins, it was clearly an exchange process.

From my point of view, it would be only a mixer if the website presents itself as if the point of the operation was to return to Bitcoin later. For example, if on the landing page you see the heading "Step 1: Exchange to Monero", and then a button is displayed leading you to a "Step 2: Exchange back to Bitcoin". That would be perhaps the kind of service that theymos described in rule 1d.

I'm not even sure about that, because in theymos' rules there is the following interesting word:
Thus, if you get Monero coins in the process and have control over them, that can't be described as "internally". You are the one who takes the decision to exchange them back.

What you write here:

... in my opinion isn't enough for the service to be considered a mixer, or directing you to use it as a mixer, because it's simply common sense and you could read it as an advice in every Bitcoin blog or forum. The point of the website model you describe, is still to exchange one coin to another.

In other words, if the described service was a mixer, probably all non-KYC exchanges would be mixers - and theymos' rules clarify clearly that exchangers are not mixers.

Of course.

One could ask what is better, use services which do the KYC themselves, or those who pay a third party authentication service?

In general, I think I'd prefer the third-party service, because they should work with the newest standards regarding identity theft protection and storage of the documents. Ideally, they wouldn't even need to store them, only to give an "OK" to the service provider, that the data of their users is correct. And the "verified data" items should also be stored more safely, of course.

One could argue that identity verification services could be an especially interesting target for hackers to steal identities, but I guess these would target mainly "DIY KYC" crypto services and smaller specialized KYC services knowing that their practices aren't on the newest state of the art. Only in the case of a big, established service provider I'd accept them to do KYC themselves.

The problem is of course that often you don't even know who does the KYC verification - the crypto service provider or a third party, and which third party. So you don't know whom you'd have to trust. It is definitely better if the provider clarifies this on their website or in their ToS.

I thus agree that there are many problems with KYC and it should be avoided if possible. But for some service categories it's difficult, and thus I continue to think that thinking about "best practices" - or better: "least worst practices" - isn't a bad idea.

En esta nueva ola de congestión Ordinals solo tiene parte de la culpa. La cantidad de bytes consumida por inscripciones se mantuvo estable comparado con la semana pasada, incluso bajó un poco.



Yo creo que esta vez simplemente estamos viendo, además de la actividad en alza por la suba de la cotización, también un factor estacional: la cercanía de Navidad. Creo que las tomas de ganancias que vimos en BTC y que mandaron la cotización casi a 40000, fueron la razón para el incremento de la congestión, gente mandó sus coins a los exchanges para gastar las ganancias en regalos y quizá viajes (dependiendo de la región y su cultura).

Recently the CBRC-20 token format from the Cybord project was published. It is an improvement of BRC-20, the Ordinals-based token format, which is available on Bitcoin, Litecoin and some other chains like Groestlcoin (GRS).

On its website Cybord.org you can find lots of info, from technical data to examples.

What is CBRC-20?

CBRC-20 tokens work exactly like BRC-20 tokens. They can be minted and transfered with the Ordinals inscription mechanisms, which use a data item in a Taproot transaction.

However, they consume less data, and thus the fees that have to be paid are smaller. I have investigated a bit: On a standard inscription you can save about 10-15% of the bytes, and thus of the fees.

For example, a BRC-20 mint transaction pair with 400 bytes could be reduced to about 360.

How do CBRC-20 transactions save data?

BRC-20 transactions store the data in a very inefficient way: as JSON text. This means you have to use bytes for all brackets, colons, commas and other special characters. An example:


CBRC-20 uses a new field added in newer versions of the Ordinals protocol: the Metaprotocol field. There, the same values are stored in the following way:


It is obvious that this consumes much less bytes: 21 instead of 52.

But take into account this only makes the "content" part smaller, which in normal BRC-20 transactions had about 50-60 bytes. The rest of the transaction (inputs and any coin-transferring outputs), which are at least 250-300 bytes more, is identic.

Personal opinion

I still think that CBRC-20 is quite inefficient due to the overhead of ~50-110 bytes for the commitment transaction or output. For all ordinals-based protocols, you need two transactions (or a transaction and an additional output of another transaction). And I think on the Bitcoin chain only the most efficient token mechanisms, which put lots of the data offchain, like RGB and Taproot Assets should be used.

However, I would not be against to these tokens used on chains like LTC and GRS, where you can create these tokens almost for free.

It has to be noted however that even this format can still be improved, for example using Google's Protobuf format. In CRBC-20 you have to store the colons too as text, while in protobuf, you would use a binary data blob, which would save additional bytes (perhaps 5 to 10 depending on the operation).

La compra de dólares es muy popular. Como ya he posteado en páginas anteriores hay muchos usuarios de criptomonedas (se estima un 15%), pero gran parte las usa principalmente para comprar stablecoins como USDT. Ahorrar en Bitcoin se limita más al público con algún grado de conocimiento en tecnología, y a parte de los "libertarios".

Los bancos y fintechs también ofrecen algunos productos como plazos fijos y bonos que si bien en los últimos meses no empataron la inflación pero sí permitían conservar una gran parte del valor por los intereses que generan (bastante superiores al 100% anual). Particularmente las billeteras electrónicas (estilo PayPal, en Argentina hay un gran número de proveedores como MercadoPago, Ualá, Prex, Moni ...) están ofreciendo productos similares a los plazos fijos con tasas de interés bastante altas. Eso fueron opciones populares en los sectores que no querían ni lidiar con MEP/CCL, ni ir a la "cueva" para comprar dólar informal, ni contaban con conocimientos para invertir en acciones, bonos o Bitcoin.

Hay topes mensuales para usar el mercado oficial de divisas. Pero los mercados extra-oficiales, tanto legales (CCL y MEP, básicamente consisten en comprar valores que cotizan en pesos Y dólares, por ejemplo acciones que cotizan en Bs. As. y en Nueva York, o distintos tipos de bonos, y luego venderlos para obtener dólares) como ilegales, si bien tienen algunas trabas no tienen topes.

Se esperaba una devaluación fuerte, pero la mayoría esperaba una cotización a $650 o $700 pesos por dólar. Sin embargo, las cotizaciones informales no se movieron mucho una vez que se conoció la medida. Por eso no creo que la sorpresa fue tan grande. Milei en un momento también había prometido sacar todas las restricciones desde el día 1 de su mandato, lo que hubiera resultado probablemente en una cotización aún más alta del dólar, cercana a $1000.

PD: Eso de pasar a tener "el doble" no funcionó, porque para comprar dólares a cotización oficial, hay que pagar un impuesto que acercaba la cotización a las informales  aunque todavía había una ganancia que se podía hacer (estaba a $750-800 justo antes de la devaluación, con impuestos incluidos, y las informales a $900-1100). Después de la devaluación, quedó más caro comprar dólar oficial con impuestos que MEP.

Basically you're proposing a new hybrid PoW/PoS protocol? The requirement for miners to back their payment addresses with coins is basically PoS. Wouldn't open this new attack vectors, like nothing-at-stake problems?

To me, that looks even quite similar to the Peercoin protocol (your difficulty depends on the coins you send in the mining transaction) mixed with elements of Bitcoin-NG and/or the NXT and Cardano protocols.

That's an interesting question if there is more "waste" in a "solo mining world" than in a "mining pool world".

From my view, a "solo mining world" will always result in a lower hashrate/difficulty in comparison with a "mining pool world" like the one we have now. Miners wanting to be profitable need to "price in" that they will always never get selected, so miners will mine with lower hashrate than if they were bundled in a pool. The used energy (by all miners) should be roughly the same in both scenarios.

Thus, I doubt there is any significant energy consumption reduction if we compare a "mining pool world" with a "solo mining world" given the same Bitcoin price (which determines the incentives to mine) and the same hardware.

It could however be argued that the "solo mining world" would have a lower hashrate and thus lower security because an attacker needs less hashrate to 51% the chain. I believe from that point of view you could talk about "wasted" energy.

Thinking about it, I think this is wrong and @tromp is correct below, as the cumulative hashrate is the same, the attack cost is also the same.

Justo hoy se habló de lo que posteó @darbitmobilerecovery en la página anterior: que la Provincia de Buenos Aires podría analizar de emitir una moneda propia (ver este artículo de Clarín).

Una cita:

Dato de color: Hace unos meses Carlos Maslatón, un economista liberal "disidente" (no apoyó a Milei en las elecciones) bastante amigo de las criptomonedas le recomendó exactamente eso, una moneda propia, al Gobierno provincial. En su momento dijo eso:

Fuente

Ya veo que en algún momento aparece una altcoin emitida por algún scammer llamada "Moneda Oficial de la Provincia de Buenos Aires" con exactamente estas características

Igual como ya argumentó Clarín puede ser simplemente una medida para presionar a Milei para que habilite más transferencias a la provincia. Hay que recordar que por la Ley de Coparticipación, la provincia de Buenos Aires es la que menos fondos recibe por habitante de todo el territorio argentino, después de CABA (Ciudad Autónoma de Buenos Aires). Por ende depende de transferencias "discrecionales", que son justo las que quiere reducir al mínimo Milei.

@garlonicon: I had deleted my post because I actually found some interesting information about one of the topics you mentioned and wanted to re-write it to not bore you with similar arguments as in my discussion with vjudeu .

As you were fast and already quoted my post before I deleted, I re-post my original post you cited from, here for reference (other interested people please exchange my post with garlonicons')

I'll reply once I read the mentioned documents.

---

But who would merge-mine a chain where you get zero revenue from merge-mining? I guess there could be some altruist merge-mining ("Sidechain/Metachain is good for Bitcoin, so we should mine it") and maybe you can also charge some small fees for peg-ins and peg-outs, but would that be enough to prevent 51% attacks? I don't believe these fees can be high, otherwise only seldom people would use the peg mechanism and instead use atomic swaps or centralized/P2P exchanges.

How do you achieve this? How can this script look like? Don't we need covenants or some other opcodes Script does currently not provide, to really create a blocking/unblocking mechanism on Bitcoin which ensures that we can't do the above mentioned attack? How exactly can homomorphic encryption help here? Can you create a sort of "covenant" with it?

My specific problem is: How do you exactly block the coins on Bitcoin, before you "move to the sidechain", to be later able to release them exactly to the person/address who pegs-out BTC on the sidechain? I still fail to understand which kind of script you could use. I know only the following methods:

- Drivechain, as described by Paul Sztorc. Needs more opcodes on Bitcoin.
- Dynamic multisig federations where simultanity is enforced by consensus on the sidechain (Nomic, Stacks). A subset of the strongest sidechain validators can enter the federation and thus move coins on the Bitcoin chain to those addresses who perform a peg-out on the sidechain to BTC. If they misbehave, they are not only excluded from the federation but also penalized on the sidechain. That's not completely bulletproof but may work well enough.
- Rollups, where part of the info is stored on-chain, so the whole transaction chain can be "reconstructed" if needed, but uses less bytes and thus can reduce tx weight/fees.

The goal of course is to prevent attacks where someone transfers coins from BTC to the side/metachain, buys things on the sidechain, and once he received the goods (or fiat/coins) moves the "blocked" coins on the mainchain. This could even be made in Nomic by colluding misbehaving federation members. They would be penalized but maybe the sidechain has enough value to be able to make a profit stealing coins.

I believe you are talking about a similar sidechain model like @vjudeu above, but I can't find any information about that concept. Are there any whitepapers/links?

Is there any real-world example for that concept? My impression is that this isn't an easy task and may be even be impossible if both metachain and pegged chain (Bitcoin) are decentralized, because it could allow attacks on several of the weaker chains happen at once to harm the metachain or steal coins.

Of course in the semi-centralized altcoin world there are models claiming they work this way (Komodo ecosystem, for example) but they're very likely only pegged together because all chains have the same set of colluding validators, or because this applies to the "commitment collectors" (in models like Komodo's dPoW).

That could work, but I can imagine a growing attack risk when a metachain (or sidechain) is losing security because its EOL is near and miners may abandon it gradually.
However, a similar model with "constantly renewing" sidechains could also work if the metachain contains an own altcoin, which could make the process safer because these coins (and the incentives for consensus their validation provides) would continue to exist. They could be simply swapped to a new chain, i.e. the new chain being a hardfork of the old one, and then "forgetting" the old transactions once it is secure enough. Or with a mini-blockchain scheme, like Cryptonite or Kaspa.

Gerne, würde ich mitmachen. Ich bin mir zwar ziemlich sicher, dass es so einen Faden schon mal gab, aber hab zumindest für die letzten 3 Jahre in diesem Unterforum keinen gefunden. Das Thema wurde durchaus häufig diskutiert, aber meines Wissens nach hauptsächlich im Kursverlaufthread.

Kurzfassung meiner Einstellung: Eigentlich halte ich TA für Esoterik. Manche Muster wiederholen sich aber tatsächlich ab und zu, und einigen der psychologischen und sonstigen Begründungen für sehr einfache Patterns (z.B. "Double Tops/Bottoms", "Dreiecke", "überkauft/verkauft" und die Grundtendenz der Elliott-Wellen) kann ich durchaus Sinn abgewinnen. Dazu kommt das Thema "selbsterfüllende Prophezeihung" durch die Aktion von TA-nutzenden Tradern und insbesondere Tradingbots, das mich auch noch eine ungeklärte Frage darstellt, d.h. die der Grund dafür sein könnte, dass sich in bestimmten Situationen auch weniger psychologisch offensichtliche TA-Aussagen wie z.B. die Fibonacci-Levels "bestätigen" können.