<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comentarios en: Whitepaper de Bitcoin explicado en español	</title>
	<atom:link href="https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/feed/" rel="self" type="application/rss+xml" />
	<link>https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/</link>
	<description>Formación sobre Bitcoin, Criptomonedas y web3</description>
	<lastBuildDate>Mon, 09 Mar 2026 06:40:53 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		Por: Miguel		</title>
		<link>https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-87696</link>

		<dc:creator><![CDATA[Miguel]]></dc:creator>
		<pubDate>Wed, 16 Feb 2022 23:29:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.bit2me.com/es/?page_id=978#comment-87696</guid>

					<description><![CDATA[Está claro que toda esta maravilla no la pudo idear, planificar y crear una sola persona, por más que se base en estructuras similares desarrolladas años o décadas atrás. Es un sistema muy complejo, con muchos puntos resueltos, para garantizar el buen funcionamiento del sistema, y eso no lo hace una sola persona. Ha sido un equipo muy bien coordinado , que ha ido encontrando las mejores soluciones disponibles en el momento. Loable y admirable creación, de estos genios!!]]></description>
			<content:encoded><![CDATA[<p>Está claro que toda esta maravilla no la pudo idear, planificar y crear una sola persona, por más que se base en estructuras similares desarrolladas años o décadas atrás. Es un sistema muy complejo, con muchos puntos resueltos, para garantizar el buen funcionamiento del sistema, y eso no lo hace una sola persona. Ha sido un equipo muy bien coordinado , que ha ido encontrando las mejores soluciones disponibles en el momento. Loable y admirable creación, de estos genios!!</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Por: Bit2Me Academy		</title>
		<link>https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-17082</link>

		<dc:creator><![CDATA[Bit2Me Academy]]></dc:creator>
		<pubDate>Wed, 10 Feb 2021 20:03:09 +0000</pubDate>
		<guid isPermaLink="false">http://blog.bit2me.com/es/?page_id=978#comment-17082</guid>

					<description><![CDATA[En respuesta a &lt;a href=&quot;https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-16858&quot;&gt;Joaquin&lt;/a&gt;.

Saludos Joaquin!

Primero: 

Lo que tu explicas acá, es un doble gasto...eso es fácilmente detectable por los nodos. Cuando Alice hace el gasto de sus monedas y este gasto es confirmado por los nodos de la red, no hay forma posible de que Alice vuelva a usar esas monedas, esto debido a que las mismas no están bajo su control, esto es así, porque el historial de UTXO de esas monedas (que está escrito en el ledger de Bitcoin) deja claro que el control no pertenece a Alice, sino a Bob, y solo él puede desbloquear el uso de dichas monedas. 

Esto lo puedes ver fácilmente en un explorador, cuando Alice envía una TX y es confirmada, la dirección a la que Alice envió las monedas a Bob, toma el saldo enviado y una vez allí, esas monedas están bajo el control de Bob. Alice puede intentar hacer trampa enviado las mismas monedas a varias personas, pero la red solo aceptara UNA transacción, y el resto se invalidan (para evitar el doble gasto).

Sobre el encadenamiento de transacciones, esta funciona tanto hacia el futuro (con transacciones a confirmar) como hacia el pasado. De hecho, en un explorador puedes verificar los movimientos hacia el pasado de las monedas y ver que  direcciones han tenido el control de las mismas hasta llegar a la coinbase que las ha generado. En este sentido, blockchain no deja cabos sueltos, el historial es completo, todo queda grabado, desde el más minimo movimiento de monedas, hasta el principio y final de la propiedad de las mismas, eso es lo que evita este tipo de ataques de doble gasto. 

Segundo:

&quot;La pregunta mía es como hago yo como validador para detectar que la transacción a Carlos es inválida &quot;  Si tu transacción hacia Carlos, usa monedas que ya has usado (y están confirmadas) entonces esa transacción es invalida, porque la clave para su control no está bajo tu poder (están en una caja fuerte en la que tu no tienes la llave), sino de otra persona. Incluso si las monedas estuvieron bajo tu control en algún momento, al pasarlas a otra persona y confirmarse ese movimiento, esas monedas dejan de ser tuyas. 

Eso explica claramente porque no puedes crear una salida adicional para gastar monedas que no están bajo tu poder.]]></description>
			<content:encoded><![CDATA[<p>En respuesta a <a href="https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-16858">Joaquin</a>.</p>
<p>Saludos Joaquin!</p>
<p>Primero: </p>
<p>Lo que tu explicas acá, es un doble gasto&#8230;eso es fácilmente detectable por los nodos. Cuando Alice hace el gasto de sus monedas y este gasto es confirmado por los nodos de la red, no hay forma posible de que Alice vuelva a usar esas monedas, esto debido a que las mismas no están bajo su control, esto es así, porque el historial de UTXO de esas monedas (que está escrito en el ledger de Bitcoin) deja claro que el control no pertenece a Alice, sino a Bob, y solo él puede desbloquear el uso de dichas monedas. </p>
<p>Esto lo puedes ver fácilmente en un explorador, cuando Alice envía una TX y es confirmada, la dirección a la que Alice envió las monedas a Bob, toma el saldo enviado y una vez allí, esas monedas están bajo el control de Bob. Alice puede intentar hacer trampa enviado las mismas monedas a varias personas, pero la red solo aceptara UNA transacción, y el resto se invalidan (para evitar el doble gasto).</p>
<p>Sobre el encadenamiento de transacciones, esta funciona tanto hacia el futuro (con transacciones a confirmar) como hacia el pasado. De hecho, en un explorador puedes verificar los movimientos hacia el pasado de las monedas y ver que  direcciones han tenido el control de las mismas hasta llegar a la coinbase que las ha generado. En este sentido, blockchain no deja cabos sueltos, el historial es completo, todo queda grabado, desde el más minimo movimiento de monedas, hasta el principio y final de la propiedad de las mismas, eso es lo que evita este tipo de ataques de doble gasto. </p>
<p>Segundo:</p>
<p>«La pregunta mía es como hago yo como validador para detectar que la transacción a Carlos es inválida »  Si tu transacción hacia Carlos, usa monedas que ya has usado (y están confirmadas) entonces esa transacción es invalida, porque la clave para su control no está bajo tu poder (están en una caja fuerte en la que tu no tienes la llave), sino de otra persona. Incluso si las monedas estuvieron bajo tu control en algún momento, al pasarlas a otra persona y confirmarse ese movimiento, esas monedas dejan de ser tuyas. </p>
<p>Eso explica claramente porque no puedes crear una salida adicional para gastar monedas que no están bajo tu poder.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Por: Joaquin		</title>
		<link>https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-16858</link>

		<dc:creator><![CDATA[Joaquin]]></dc:creator>
		<pubDate>Wed, 10 Feb 2021 04:18:01 +0000</pubDate>
		<guid isPermaLink="false">http://blog.bit2me.com/es/?page_id=978#comment-16858</guid>

					<description><![CDATA[En respuesta a &lt;a href=&quot;https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-16853&quot;&gt;Bit2Me Academy&lt;/a&gt;.

Saludos Bit2me y gracias por la respuesta.

Comprendo lo del script, por ahí estoy profundizando un poco mucho, pero lo que no llego a comprender es:
En el caso de la foto adjuntada, yo como nodo que voy a validar la transacción. 

Alice con el scriptsig &quot;desbloquea&quot; la salida anterior, y crea un script pubkey en una de las salidas de la transacción. De esta transacción firma casi todo indicando que ella es quien envía los satoshis a la clave pública que se indique, en este caso la de Bob. Hasta que Bob no gaste esa salida se mantendrá ahí como una UTXO.

Despues Alice con el mismo scriptsig desbloqueando el mismo script pubkey que tenía como salida su clave pública genera otra transacción con la misma entrada que usó para Bob pero en este caso la salida será para Carlos.

La pregunta mía es como hago yo como validador para detectar que la transacción a Carlos es inválida, si sobre el script pubkey de la transacción que ha recibido Alice que luego destraba con el script sig para gastar en la transacción hacia Bob no se ha indicado nada. Osea, las transacciones se encadenan hacia adelante pero hacia atras no dejan ninguna marca. 

Entonces yo cuando tomo la transacción hacia Carlos, el script sig sería válido pues la clave privada de Alice coincide con la clave pública indicada en la salida de la transacción, &quot;destrabando&quot; esos satoshis y en el caso que no se deje ninguna &quot;marca&quot;, no habría forma de decir que esa salida se ha gastado. No sé si me explico bien.

O al momento que Alice genera el script pubkey genera una &quot;cadena&quot; o un &quot;cierre&quot; entre la entrada y esa salida? Es decir, a Alice le llega una &quot;caja fuerte&quot; que ella sola puede abrir (scriptSig) y lo que tiene adentro de la caja fuerte lo toma y lo pasa a tantas cajas fuertes como salidas tenga y las bloquea (scriptPubkey con la pública de c/u) y les pone una etiqueta que dice Alice (firma).

Es decir que cuando va a abrir &quot;otra vez&quot; la caja fuerte para armar una caja fuerte para Carlos esa caja fuerte ya ha sido vaciada y está distribuida en las cajas fuertes de salida de la caja fuerte anterior.

Entonces sigo con la misma duda, que impide que Alice cree dos transacciones con la misma salida? Que cuando va a aplicar el scriptSig la segunda vez el scriptPubkey ya ha sido destrabado y se han trabado con las cajas fuertes de salida?

Desde ya disculpas por las preguntas un poco rebuscadas y largas. Gracias.]]></description>
			<content:encoded><![CDATA[<p>En respuesta a <a href="https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-16853">Bit2Me Academy</a>.</p>
<p>Saludos Bit2me y gracias por la respuesta.</p>
<p>Comprendo lo del script, por ahí estoy profundizando un poco mucho, pero lo que no llego a comprender es:<br />
En el caso de la foto adjuntada, yo como nodo que voy a validar la transacción. </p>
<p>Alice con el scriptsig «desbloquea» la salida anterior, y crea un script pubkey en una de las salidas de la transacción. De esta transacción firma casi todo indicando que ella es quien envía los satoshis a la clave pública que se indique, en este caso la de Bob. Hasta que Bob no gaste esa salida se mantendrá ahí como una UTXO.</p>
<p>Despues Alice con el mismo scriptsig desbloqueando el mismo script pubkey que tenía como salida su clave pública genera otra transacción con la misma entrada que usó para Bob pero en este caso la salida será para Carlos.</p>
<p>La pregunta mía es como hago yo como validador para detectar que la transacción a Carlos es inválida, si sobre el script pubkey de la transacción que ha recibido Alice que luego destraba con el script sig para gastar en la transacción hacia Bob no se ha indicado nada. Osea, las transacciones se encadenan hacia adelante pero hacia atras no dejan ninguna marca. </p>
<p>Entonces yo cuando tomo la transacción hacia Carlos, el script sig sería válido pues la clave privada de Alice coincide con la clave pública indicada en la salida de la transacción, «destrabando» esos satoshis y en el caso que no se deje ninguna «marca», no habría forma de decir que esa salida se ha gastado. No sé si me explico bien.</p>
<p>O al momento que Alice genera el script pubkey genera una «cadena» o un «cierre» entre la entrada y esa salida? Es decir, a Alice le llega una «caja fuerte» que ella sola puede abrir (scriptSig) y lo que tiene adentro de la caja fuerte lo toma y lo pasa a tantas cajas fuertes como salidas tenga y las bloquea (scriptPubkey con la pública de c/u) y les pone una etiqueta que dice Alice (firma).</p>
<p>Es decir que cuando va a abrir «otra vez» la caja fuerte para armar una caja fuerte para Carlos esa caja fuerte ya ha sido vaciada y está distribuida en las cajas fuertes de salida de la caja fuerte anterior.</p>
<p>Entonces sigo con la misma duda, que impide que Alice cree dos transacciones con la misma salida? Que cuando va a aplicar el scriptSig la segunda vez el scriptPubkey ya ha sido destrabado y se han trabado con las cajas fuertes de salida?</p>
<p>Desde ya disculpas por las preguntas un poco rebuscadas y largas. Gracias.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Por: Bit2Me Academy		</title>
		<link>https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-16853</link>

		<dc:creator><![CDATA[Bit2Me Academy]]></dc:creator>
		<pubDate>Wed, 10 Feb 2021 02:59:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.bit2me.com/es/?page_id=978#comment-16853</guid>

					<description><![CDATA[En respuesta a &lt;a href=&quot;https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-16835&quot;&gt;Joaquin&lt;/a&gt;.

Saludos Joaquin!

Cuando Alice realiza un gasto (usa sus entradas para dar origen a una salida), Alice en realidad está creando un &quot;script de gasto en el que ella pasa la propiedad de las monedas al usuario que le ha dado una dirección pública para dicho envío&quot; (en este caso, Bob es quien da la dirección pública para que Alice realice un pago a dicha dirección). 

El script es simple y se puede leer de la siguiente forma: &lt;strong&gt;&quot;Yo Alice le paso la propiedad de este dinero a Bob, porque Bob es el único con la llave privada necesaria para manejar la dirección publica que me ha dado&quot;.&lt;/strong&gt; Es decir, el script pubkey generado por Alice solo puede ser desbloqueado bajo ciertas condiciones alcanzables solo por Bob, y esto garantiza que Alice no pueda generar múltiples salidas usando unas mismas monedas, porque bajo el esquema de la blockchain tal acción es imposible, ya que solo una de acciones será aceptada y confirmada, dejando al resto sin efecto, una vez confirmada la acción (al incluirse la transacción en un bloque) el resto de bloques que se agreguen en la blockchain solo agregaran consenso sobre lo sucedido y hará más difícil reescribir el hecho de que Alice le ha pasado dinero a Bob de forma inequívoca. 

Lo de que Alice puede enviar una transacción a Bob y otra a Carlos usando las mismas monedas, es posible, pero de esas acciones, solo una será confirmada, dejando a la otra sin efecto. De allí la importancia de recibir y tomar como validas las transacciones que estén realmente confirmadas en la red, lo normal es esperar al menos 3 confirmaciones, y si quieres más seguridad, esperar hasta las 6 confirmaciones en Bitcoin. En Ethereum, por ejemplo, se suelen esperar 30 confirmaciones para decir que efectivamente la transacción es irreversible, y así muchas otras cripto tienen sus propios esquemas de seguridad en este sentido.]]></description>
			<content:encoded><![CDATA[<p>En respuesta a <a href="https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-16835">Joaquin</a>.</p>
<p>Saludos Joaquin!</p>
<p>Cuando Alice realiza un gasto (usa sus entradas para dar origen a una salida), Alice en realidad está creando un «script de gasto en el que ella pasa la propiedad de las monedas al usuario que le ha dado una dirección pública para dicho envío» (en este caso, Bob es quien da la dirección pública para que Alice realice un pago a dicha dirección). </p>
<p>El script es simple y se puede leer de la siguiente forma: <strong>«Yo Alice le paso la propiedad de este dinero a Bob, porque Bob es el único con la llave privada necesaria para manejar la dirección publica que me ha dado».</strong> Es decir, el script pubkey generado por Alice solo puede ser desbloqueado bajo ciertas condiciones alcanzables solo por Bob, y esto garantiza que Alice no pueda generar múltiples salidas usando unas mismas monedas, porque bajo el esquema de la blockchain tal acción es imposible, ya que solo una de acciones será aceptada y confirmada, dejando al resto sin efecto, una vez confirmada la acción (al incluirse la transacción en un bloque) el resto de bloques que se agreguen en la blockchain solo agregaran consenso sobre lo sucedido y hará más difícil reescribir el hecho de que Alice le ha pasado dinero a Bob de forma inequívoca. </p>
<p>Lo de que Alice puede enviar una transacción a Bob y otra a Carlos usando las mismas monedas, es posible, pero de esas acciones, solo una será confirmada, dejando a la otra sin efecto. De allí la importancia de recibir y tomar como validas las transacciones que estén realmente confirmadas en la red, lo normal es esperar al menos 3 confirmaciones, y si quieres más seguridad, esperar hasta las 6 confirmaciones en Bitcoin. En Ethereum, por ejemplo, se suelen esperar 30 confirmaciones para decir que efectivamente la transacción es irreversible, y así muchas otras cripto tienen sus propios esquemas de seguridad en este sentido.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Por: Joaquin		</title>
		<link>https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-16835</link>

		<dc:creator><![CDATA[Joaquin]]></dc:creator>
		<pubDate>Wed, 10 Feb 2021 01:01:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.bit2me.com/es/?page_id=978#comment-16835</guid>

					<description><![CDATA[Saludos Bit2me
Que evita que Alice transmita una transacción a Bob y repita esa transacción a Carlos?

Si únicamente Alice lo que tiene que hacer es desbloquear la salida con su clave privada. O Alice deja algún tipo de marca sobre la transacción anterior, indicando que se ha gastado? En ese caso, que marca deja? 

Porque en bitcoindeveloper únicamente dice que se crea un script pubkey para bloquear la salida pero una vez que se desbloquea esa salida para usarse en otra transacción como entrada, se deja alguna marca sobre la salida anterior para que no se pueda usar esa salida otra vez? Porque sino se podrían generar muchos scriptpubkey con la misma entrada y sería totalmente válido ya que no existiría forma de verificar que esa salida anterior se ha gastado.

Gracias]]></description>
			<content:encoded><![CDATA[<p>Saludos Bit2me<br />
Que evita que Alice transmita una transacción a Bob y repita esa transacción a Carlos?</p>
<p>Si únicamente Alice lo que tiene que hacer es desbloquear la salida con su clave privada. O Alice deja algún tipo de marca sobre la transacción anterior, indicando que se ha gastado? En ese caso, que marca deja? </p>
<p>Porque en bitcoindeveloper únicamente dice que se crea un script pubkey para bloquear la salida pero una vez que se desbloquea esa salida para usarse en otra transacción como entrada, se deja alguna marca sobre la salida anterior para que no se pueda usar esa salida otra vez? Porque sino se podrían generar muchos scriptpubkey con la misma entrada y sería totalmente válido ya que no existiría forma de verificar que esa salida anterior se ha gastado.</p>
<p>Gracias</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Por: Eduard		</title>
		<link>https://academy.bit2me.com/whitepaper-bitcoin-en-espanol/comment-page-1/#comment-11086</link>

		<dc:creator><![CDATA[Eduard]]></dc:creator>
		<pubDate>Fri, 01 Jan 2021 18:50:43 +0000</pubDate>
		<guid isPermaLink="false">http://blog.bit2me.com/es/?page_id=978#comment-11086</guid>

					<description><![CDATA[Hicieron una maravilla. Hay que reconocer el gran trabajo que hizo o hicieron bajo el pseudónimo de  Satoshi Nakamoto. Les estaremos muy agradecidos por vida.]]></description>
			<content:encoded><![CDATA[<p>Hicieron una maravilla. Hay que reconocer el gran trabajo que hizo o hicieron bajo el pseudónimo de  Satoshi Nakamoto. Les estaremos muy agradecidos por vida.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
