Bitcoin Forum
August 29, 2024, 10:02:37 AM *
News: All versions of Windows are affected by a critical security bug; make sure you update.
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17 18 19 20 21 »
241  Bitcoin / Development & Technical Discussion / Re: Proposal: dynamic max blocksize according to difficulty on: September 03, 2015, 03:53:20 AM
Generally this kind of proposals cannot function without a second factor, which is meant to define a resizing threshold.

How is your code supposed to distinguish between the release of a new ASIC and actual growth in block space demand?
When the hash rate increases because of new ASIC, the difficulty rises, this will allow for the max block size to increase. This increases supply so transaction fees go down, which will cause an increase in block space demand. All of which if you think it over, it makes sense. The bitcoin network has gotten stronger because of a massive increase of hash rate due to new ASIC, therefore it stands to reason it should support more transaction throughput.
Quote
Quote
However I believe this to be nearing its maximum efficiency and closing in with Moore's Law.

Not necessarily. Consider that Intel is a $55B business whereas the Bitcoin as a whole has a $3~4B market capitalization. We're not yet at a stage where professional chip manufacturers have an incentive to build ASICs.
Intel has been around for decades, bitcoin only 6 years, of which 3 has shown dramatic growth.
Quote
And generally, what makes you believe block space demand will grow at least at the same pace as Moore's Law?
It doesn't matter really at which rate block space demand grows. If it grows slowly, then transaction fees stay low and investment in mining will be low.
Quote
Your proposal has no thresholds. It simply links block size evolution to difficulty. I believe difficulty changes are a good metric to define by how much the block size should be changed, but difficulty is not a good enough metric to reflect block size demand.

You need another factor to track block size demand, and use that as a trigger for resizing. On top of that, a decay function would be preferable for when the resizing condition doesn't trigger. That's a safety harness that will correct the effect of spam attacks, large miners trying to game the system, and too large a jump in block ceiling.
Unfortunately we don't have any other metric to determine the max blocksize. All the other proposals so far only arbitrarily set this limit, or in the case of BIP 100 it gives the miners a way to set it via voting which the more I think about it, the more I tend to believe its a terrible idea.

I really appreciate your input. I have been obsessing over my solution for this max blocksize conundrum and I really think it is the best one by far.
242  Bitcoin / Development & Technical Discussion / Re: Proposal: dynamic max blocksize according to difficulty on: September 02, 2015, 05:31:54 AM
FWIW isn't Lightning Network a band-aid solution?
No, far from it. I suggest you seriously look into it.
243  Bitcoin / Development & Technical Discussion / Re: Proposal: dynamic max blocksize according to difficulty on: September 02, 2015, 05:20:10 AM
I like great ideas, but great ideas do not fair well on the forums.
thanks
Quote

Dynamic Block size with min. change to 2MB no doubt.

Whether or not the change is proportionate to difficulty of mining is not really what I would call relevant. The main concern is latency when blocks begin to get into the double digits but people overlook the added incentive of increased transaction volumes = increased incentive.
As I said the problem with latency is resolved when blocks get orphaned by the miners. This affects difficulty directly because the hash rate is affected by the wasted block - the hashes that went into generating the discarded block are lost.
Quote
We could keep 1MB until it starts slowing down the network and then go to a Fibonacci Sequence that increases dynamically based upon whether the block size is deemed too small by Core. Say if Mempools start crashing Nodes etc...

1MB,2MB,3MB, 5MB,8MB, 13MB, 21MB etc
That seems to be a part of another suggestion to hard fork. You would need to elaborate.
Quote
I really appreciate your time and contribution but I believe all the Core developers have already been bought out by Blockstream so they can be the First Lightning Network hub and take fees from miners and keep 1MB forever because they want to capitalize on the inability of the community to reach consensus without arguing.
I really detest any suggestion of politics or buying out of core developers in this discussion. FWIW I fully support the Lightning Network. I think its a fantastic idea. The Lightning network also needs an increase in max blocksize btw.
Quote
People like you are who keep bitcoin going. Thank you. Remember, We Are Satoshi.

was
thanks
244  Bitcoin / Development & Technical Discussion / Re: Proposal: dynamic max blocksize according to difficulty on: September 02, 2015, 04:25:14 AM
Either my idea is so bad its not worth commenting or its so good nobody has been able to find an objection?

What am I missing?

Lets explore this proposal a bit, by examining different scenarios.

1. The hash rate shoots through the roof and difficulty increase at a disproporcionate rate: The max blocksize also increases and the risk of spamming the blockchain becomes more plausible. But this risk is negated by the fact that blockchain itself is a lot stronger because of the increased hash rate. The network might not be able to sustain such mega blocks. However if blocks becomed orphaned and all the hashing that went into building such a block disappears from the aggregate calculating difficulty, so it contributes to a lower difficulty and consequently to lower max blocksize.

2. The demand for blockchain space increases at a faster rate than the difficulty: In this case there will be pressure in fees, so miners will have more profits and consequently more incentivize to invest in hardware for mining. It will then lead to higher hashrates and consequently larger max blocksize which will then satisfy the demand for blockchain space.

3. The amount of transactions fees fall, leading to lower miner income and thus lower hashrate and thus lower blocksizes.

In summary, the chain of causation is like this

Increasing:

More demand for blockchain space -> more transaction fees -> increased miner profits -> increase in mining investment -> more hashing power -> increased difficulty -> larger blocks

Decreasing:

Less transactions -> less transaction fees -> decreasing miner profits -> less miners hashing -> less hashing power -> lower difficulty -> smaller blocks sizes

Another way to explore this proposal is assuming it was adopted earlier:

Lets suppose this BIP was incorporated when Satoshi established the 1MB max blocksize. This was in July of 2010. The average blocksize was about 1k then. Satoshi decides to set the max blocksize at 2k. The difficulty was about 1,379,000 and the current difficulty is 54,256,630,328. If this proposal had been implemented then the current max blocksize would be: 2000 * 57,432,508,738 / 1,379,000 =832,958,792 bytes (832MB). Clearly this is not right and the reason for such a large disparity is that obviously bitcoin mining hardware has had a lot of catching up to do (CPU>GPU>FPGA>Asic>Huh). However I believe this to be nearing its maximum efficiency and closing in with Moore's Law.

Lets instead suppose this BIP was incorporated exactly one year ago.

The max block size was 1MB and difficulty 27,428,630,902. This is roughly to half of what is now, so the max blocksize now would be 2MB. A much more reasonable increase. In fact it would be a very healthy limit right now. There is an 80% consensus that this should be the minimum  max blocksize increase.

Also the economic dynamics will be much more applicable when the block reward subsidy is reduced.

Other advantages of this proposal:

1. Very clear and simple. Everyone can see what the impact of such a hard fork will be.
2. Changes in the max blocksize will be gradual and change at a predicted rate, much like how difficulty will affect the profitability of miners.
3. Trivial to implement and test in testnet.
4. Ties changes to the max blockchain to the strength of the bitcoin network itself. The more mining power there is, the bigger blocks can exists.
5. Allows for wallets to more easily determine the right transaction fee per kilobyte.
6. Gives us steady adjustments of max blocksize for the long term, without requiring another hard fork in a while at least.

A further way to refine this, which I think is even better (at the cost of a bit more complexity), is to factor in the block reward subsidy. I would propose a formula of new maxblocksize * (1 +(1 - coinbase/50)).

So when the block reward is 25 BTC the increases/decreases are reduced by 50% of the difficulty change. When the block reward is 12.5 BTC, max blocksize increase/decrease are reduced by 25% and so on. When we reach 0 BTC block rewards, the max blocksize becomes on par with the difficulty.

I really wish some input on my proposal. Even though there is a question of whether the hashrate can grow to accomodate to the increasing demand of transactions and therefore more space in the blockchain (transaction fees should pressure this in the end), I think this solution is vastly superior to the other proposals so far.
245  Bitcoin / Development & Technical Discussion / Proposal: dynamic max blocksize according to difficulty on: August 31, 2015, 08:57:45 PM
I propose a very simple solution to determine the new maximum blocksize:

Increase or decrease to the maximum blocksize at the same rate as how difficulty is increased or decreased. This can be set at every 2016 blocks or a multiple of such.

For example currently the blocksize is 1,000,000B and the difficulty rate of the last 20160 blocks has increased by 9.72%  (from 49,446,390,688 to 54,256,630,328) then the new block size = 1,097,277B

We could do an initial jump to 2MB, since I believe there is consensus that this is what is needed to begin with.

Rationale: Even though hardware advances do not exactly match in different computing areas, for example network vs computation speed, it is roughly similar (perhaps some research can be made) to the degree that it gives us at least some guidance as to what the network can support in terms of block relaying latency.

A very big advantage is that implementation would be trivial.

246  Bitcoin / Development & Technical Discussion / Re: What is the status of BIP62? on: August 30, 2015, 11:40:09 PM
I agree, this needs to be prioritized!
247  Bitcoin / Development & Technical Discussion / Re: Maximum transaction fee to include transaction in block on: August 30, 2015, 11:34:39 PM
I understand that once the blockchain is set, it is always 100% "voting" by the miner since they all must agree to keep building blocks on top the last block.

However I was referring to the BIP100 where miners "vote" on increasing and decreasing the blocksize. This becomes a real vote mechanism because it is implemented at the protocol level. ie the protocol counts the votes and sets a *hard* limit on the new blocks.

It is my belief that such voting is actually useless. Miners will always vote for the ability to create larger blocks, because any individual miner can choose to make smaller blocks regardless.

Previously I was convinced not limiting the block size would be a serious problem since I thought it would lead to unhealthy fee levels (transactions become increasing cheaper since there is unlimited space in blocks, but now I am thinking that miners actually do face the real increased risk of their blocks getting orphaned if the block is too big for it to get propagated in the network, so they will enforce a better fee structure for transactions to mitigate this risk.

So yeah, I think Gavin was right after all and maybe BIP101 is the right way to go.
248  Bitcoin / Development & Technical Discussion / Re: Dynamically Controlled Bitcoin Block Size Max Cap on: August 29, 2015, 06:34:42 AM
It has come to my understanding (please correct me if I am wrong and why) that miners can inject bogus transactions in their blocks.

If that is true then this proposal is crap: miners can put whatever transactions with whatever fees to inflate the statistic to suit whatever new block size they target.

I firmly believe miners will do whatever it takes to make the blocksize as large as they can make it, via whatever mechanism allowed (includingi BIP100) since it will give them maximum flexibiility to decide. They can always soft limit if they choose after all.
249  Bitcoin / Development & Technical Discussion / Re: Why I support Jeff's BIP100 on: August 29, 2015, 05:14:10 AM
I initially thought BIP100 was pretty good too but now after some serious thought I am convinced miners will ALWAYS vote for bigger blocks. It simply gives them more flexibility. They can always soft limit whenever they want.

So once BIP100 is hard coded, miners will continually push and vote for bigger blocks.

I think the real limitation resides in the ability of nodes to relay blocks. Excessively large blocks affects the bitcoin network when nodes aren't up to par (obviously).

Therefore I am tending  to believe that any hard fork will have to deal with verifying transactions in the block that were actually in the mempool and not able to be fabricated by the miner when consolidating his block (or "vote" for larger size).  Is that even possible?

250  Bitcoin / Development & Technical Discussion / Re: Maximum transaction fee to include transaction in block on: August 29, 2015, 03:52:31 AM
I am thinking also on what a miner can do, thinking about solutions to increasing (or not) the max blocksize.

Can a miner fake a lot of transaction, transactions that were never in the mempool, even with transactions fee (which he can reclaim) and include it in his block?

Yes, a solo miner or (mining pool operator) can.

He can also fake a lot of transactions with no fee and include them all in his block (so that he doesn't need to "reclaim" them).

I think then any solution that allows miners to set their maximum block size is completely useless, either by voting in blocks like BIP100, or by average transaction fees like BIP upal, or average block size. Miners will always try to maximize the possible block size since they can always soft minimize later.

There should be a way to enforce transactions to be in the mempool for them to be valid in blocks. Is that posible?
251  Bitcoin / Development & Technical Discussion / Re: Maximum transaction fee to include transaction in block on: August 29, 2015, 03:37:24 AM
I am thinking also on what a miner can do, thinking about solutions to increasing (or not) the max blocksize.

Can a miner fake a lot of transaction, transactions that were never in the mempool, even with transactions fee (which he can reclaim) and include it in his block?

If not, how is this enforced?
252  Bitcoin / Development & Technical Discussion / Re: Dynamically Controlled Bitcoin Block Size Max Cap on: August 24, 2015, 08:29:02 PM
I was about to post a similar suggestion too. I think this is a great idea.

I hope the core devs take a serious look at it.
253  Economy / Trading Discussion / Re: Skyhook opensource ATM - Opinions? on: December 30, 2014, 03:42:13 AM
I got my Skyhook BTM today and I think its just great. I am going to set it up here in Mexico City.

I have some questions though which I tried to look up on the internet and I could not find any answers.

What does "open source" mean when referring to this BTM? I understand the software side of it, but does it also include the design and hardware aspects too?
I would like to explore the possibility of manufacturing this BTM in Mexico, importing the bill acceptor for Mexican currency, but before I do that I want to be sure if the "open source" also means I can actually produce my own BTMs without running into patent or licensing issues. If that is not a problem, where can I find detailed instructions on how to build your own Skyhook BTMs, including parts lists.

Of course I would also contribute and make my own hardware specific changes open source.

TIA.



254  Bitcoin / Project Development / Re: Proposal to imprint bitcoin unto paper currency on: June 03, 2014, 02:08:57 PM
Good idea but is a federal crime to mutilate a bill. I prefer the way to have own paper money as paper wallets, just as casaciuos coins and bills, only with multisign addresses.
Yeah, the best solution would be to create an organization with reputable members who would provide their own public keys and print its own currency.

Actually I kind of like the idea of repurposing a national currency. There's something poetic about this. Consider the Venezuala Bolívar:



If I was a Venezualan, and I'd watched the value of my 500 Bolívar bill decrease 46% overnight (http://wealthcycles.com/blog/2013/02/08/venezuela-devalues-almost-47-too-late-for-many) I might take some satisfaction from "guaranteeing" the value of my bill by adding bitcoins to it.

Do I understand correctly however that this is almost a "proof of burn" type of valuation? The bitcoins allocated to a bill are *provable* yet *unspendable*?

Thats correct. However a centralized institution having several public key holders could theoretically create redeemable bills. People using imprinted bitcoined bills would have to trust the "board" of this institution that they would not arbitrarily remove the bitcoins from bills unless the bills are also physically destroyed.
255  Local / Español (Spanish) / Re: Propuesta para imprimir bitcoin en billetes. on: March 27, 2014, 03:39:39 PM
Y no podría el que hizo el billete recuperar los bitcoins cuando le de la gana? Al fin y al cabo tiene todo lo necesario no?

No, según he entendido, le faltarían todo el resto de claves privadas de las otras direcciones con las que ha generado la dirección multifirma.

La principal pega que le veo es que una vez se deteriore el billete, entiendo que se pierden los btc. Huh

Mi idea mas que nada va enfocado a que alguien saque sus propios billetes y monedas con su propio set de llaves publicas donde la gente que los use pueda confiar en que no se van a desaparecer los fondos en bitcoin.

Si los billetes se deterioran, esta organizacion las puede recuperar y volver a imprimir.

En economias donde la inflacion es severa, se pueden imprimir los bitcoins en los billetes oficiales para que estos mantengan su valor.

256  Local / Español (Spanish) / Propuesta para imprimir bitcoin en billetes. on: March 25, 2014, 06:02:30 AM
Una Propuesta para imprimir bitcoin en billetes.
(originalmente posteado en inglés aqui: https://bitcointalk.org/index.php?topic=516273.msg5706034

Tengo la siguiente idea para integrar bitcoins en billetes: tomas el folio del cualquier billete de cualquier país y creas una cartera multisig con el. Envias fondos a esta direccion, marcas el billete con la cantidad de bitcoins que contiene y (opcionalmente) mutilas el billete.

Los bitcoins depositados en la dirección multisig no se pueden gastar porque este multisig esta compuesto por varias llaves públicas de diversas personas y organizaciones que nada les importa y no se van a reunir para firmar la P2SH. Esto significa que quien tenga en su poder el billete puede estar seguro que es dueño de bitcoins unicos que no nadie puede gastar electronicamente.

Es importante que el billete a marcar sea muy dificil de falsificar y que tenga un folio único. Es por eso que los billetes expedidos por los gobiernos son perfectos para hacer esto. Claro, esta idea se puede aplicar a cualquier objeto que cumpla con estas dos caracteristicas (folio unico y dificil de falsificar) incluyendo la expedición de tus propios billetes o monedas con numeros de serie.

Sería bueno si pudieramos ponernos de acuerdo para especificar un estandar de llaves públicas para facilitar la verificación de los saldos en las direcciones multisig. De lo contrario la persona que este bitcoineando sus billetes tiene publicar el set de llaves públicas que utilizó para que el público que use sus billetes pueda verificarlos.

Cual es el propósito de esto? Permite que cualquiera pueda tener bitcoins sin tener que accesar una computadora o connexión de internet. Los billetes solo se tiene que verificar una vez por el poseedor del billete consultando el blockchain y ya. El blockchain no tiene que mantenerse actualizado ya que es virtualmente imposible "sacar" los bitcoins del billete con una futura transaccion.

Pasos para crear un multisig para un billete específico.

1. Determina la nacionalidad y denominación del billete.
2. Agrega el numero de serie del billete (folio).
3. Crea un cartera cerebro (brain wallet) con estos datos usando un método estandard, separando con un espacio la nacionalidad, denominación y folio del billete.
4. Escoge 4 o mas llaves públicas de direcciones regulares muy conocidas.
5. Crea la dirección multisig combinando las llaves públicas empezando por el que se generó con la cartera cerebro del billete.
6. Envia los fondos a esta dirección. Sugiero usar la denominación del billete como guía: 0.0005 BTC for $5.00 USD, 0.001 BTC for $10 USD, etc
7. Escribe con tinta indeleble en el billete la nacionalidad y denominación a lado del folio de como se determino la dirección y la cantidad depositada de bitcoins.
Opcionalmente mutila el billete para que sea facil de distinguir de otro billeto no bitcoineado para evitar que se pierda por error. Sugiero doblarlo dos veces a la mitad y luego cortar con guillotina en el tercer doblez.

Ejemplo:
1. US. 5 dollar bill.
2. US 5 IF84621533C
3. Genera el "Brain Wallet"
Imagen:  http://fantasticocomic.com/bc/bitcoinedbill-1.png
4. Genera la direccion P2SH. Vamos a utilizar las siguientes llaves públicas que escogí arbitrariamente de transacciones que encontre en el blockchain:
Code:
Linux Mint Donations:
04abc9f887ac2273df9c8db1d68cf520fd343bb567e2da68d057ae5d5b0e93d6b413c56762c0db15b582aeaeb4455c814f67b582da117b177b776b353145452e5d
Free Talk Live:
041ab4dcddd2c7a7b9928ff278661040d242080b8adf85870f5af01a7a3c77fd74af031e365cc1d9b8d5dc102e87f6dd183f3884b23cd1dafc5ea9c86db9ba42e9
Bitcoinity:
048ac1b0a436bec71eeab01becd493be697f78a72131f15501720d1791ad90521647fe8f1d539d21569ff7f6c15c890731b6b3e247fa2f2255171c2f4342e72f8d
BitcoinTalk Forums:
04271bb147a592a7cbb0323ec42ff1d056f125c431383cc4480b4d2f511c06802beb475ade7c29eb2572a4fc73895a806c5c0d2efc84f2bead24399980f41e2889
Archive.org
043b640c644e5cda2f2e4be20bca4535882fd5053e7a72c18736d179049aaa27c33febcb12ae597f80c29b4ce9bff32ef5654351ac310b514b66064755d8e24af2
SatoshiDice 0.78%
04c78beee103e8392bc3aa13ee779b8084fa9fd3b54cbace8520fa427a19f5aebfe8aba1cca8a7c1ec3f858ba8fb050c2e603cf932782bc78ec4eac258c8db1e13
5. Le agregamos la llave publica generada por el passphrase del brain wallet de los USD 5 y folio.
Code:
045119754ff7cd6bcf1116a5b74c0af7a2d25fa9b631d735e1b232646b2f24ffa4004f870d97c01b8dbb27393473c3124af669aa505baf73da0a7682e216c06d81
Imagen: http://fantasticocomic.com/bc/bitcoinedbill-2.png

6. Enviamos fondos por 0.0005 BTC a la dirección Multisig ( 3FScohu2zS57323xt58LBc3if9r2juLCTw ) usando cualquier software de monedero. Se le agrega 0.00001 comisión de transacción.
7. Escribimos en el billete el monto enviado y lo mutilamos.


8. Se publica el redeem script para que otros lo puedan verificar:
Code:
5741045119754ff7cd6bcf1116a5b74c0af7a2d25fa9b631d735e1b232646b2f24ffa4004f870d97c01b8dbb27393473c3124af669aa505baf73da0a7682e216c06d814104abc9f887ac2273df9c8db1d68cf520fd343bb567e2da68d057ae5d5b0e93d6b413c56762c0db15b582aeaeb4455c814f67b582da117b177b776b353145452e5d41041ab4dcddd2c7a7b9928ff278661040d242080b8adf85870f5af01a7a3c77fd74af031e365cc1d9b8d5dc102e87f6dd183f3884b23cd1dafc5ea9c86db9ba42e941048ac1b0a436bec71eeab01becd493be697f78a72131f15501720d1791ad90521647fe8f1d539d21569ff7f6c15c890731b6b3e247fa2f2255171c2f4342e72f8d4104271bb147a592a7cbb0323ec42ff1d056f125c431383cc4480b4d2f511c06802beb475ade7c29eb2572a4fc73895a806c5c0d2efc84f2bead24399980f41e288941043b640c644e5cda2f2e4be20bca4535882fd5053e7a72c18736d179049aaa27c33febcb12ae597f80c29b4ce9bff32ef5654351ac310b514b66064755d8e24af24104c78beee103e8392bc3aa13ee779b8084fa9fd3b54cbace8520fa427a19f5aebfe8aba1cca8a7c1ec3f858ba8fb050c2e603cf932782bc78ec4eac258c8db1e1357ae
Repito, este paso podría ser evitado si podemos ponernos de acuerdo a un estandar de llaves públicas para usar universalmente en esto.

Tambien se puede imprimir el redeem script base64 encoded  con un código QR en el reverso del billete. Utilize la herramienta localizado aqui: http://brainwallet.org/#converter. Por conveniencia le agregue el código QR code de la direccion P2SH address y mas detalles. Utilize el generador de códigos QR de http://bitcoinqrcode.org/


Otro ejemplo con un billete Mexicano de 20 pesos:
1. Genera el Brain wallet con los siguientes palabras clave: MEX 20 T6944908
Imagen: http://fantasticocomic.com/bc/bitcoinedbill-3.png
2. Genera la direccion P2SH, copia y pega la llave pública del brain wallet y agrega las otras 6 llaves públicas. Usaremos las mismas 6 del billete anterior.
Imagen: http://fantasticocomic.com/bc/bitcoinedbill-4.png
3. Envia .0002 BTC a la direccion P2SH address ( 3JgyBtcQ7Sp9R17jSRdhi9TCWqbz2vQUed ) Asegurate de agregar 0.0001 de comisión.
4. Escribe en el billete la cantidad de bitcoins depositados y como se derivaron las palabras clave:

5. Publica el redeem script para que otros lo puedan verificar:
Code:
5741049ccb1f411b983644512b9ba63f30a7e74f20d035571fb18b1c03f988e1342ef2742dad15ef44a984eeb04dcd0e16a9031f32f5eba278aa65bef3ec4e5e347bb54104abc9f887ac2273df9c8db1d68cf520fd343bb567e2da68d057ae5d5b0e93d6b413c56762c0db15b582aeaeb4455c814f67b582da117b177b776b353145452e5d41041ab4dcddd2c7a7b9928ff278661040d242080b8adf85870f5af01a7a3c77fd74af031e365cc1d9b8d5dc102e87f6dd183f3884b23cd1dafc5ea9c86db9ba42e941048ac1b0a436bec71eeab01becd493be697f78a72131f15501720d1791ad90521647fe8f1d539d21569ff7f6c15c890731b6b3e247fa2f2255171c2f4342e72f8d4104271bb147a592a7cbb0323ec42ff1d056f125c431383cc4480b4d2f511c06802beb475ade7c29eb2572a4fc73895a806c5c0d2efc84f2bead24399980f41e288941043b640c644e5cda2f2e4be20bca4535882fd5053e7a72c18736d179049aaa27c33febcb12ae597f80c29b4ce9bff32ef5654351ac310b514b66064755d8e24af24104c78beee103e8392bc3aa13ee779b8084fa9fd3b54cbace8520fa427a19f5aebfe8aba1cca8a7c1ec3f858ba8fb050c2e603cf932782bc78ec4eac258c8db1e1357ae
6. De otra forma, imprime el redeem script base64 encoded con info adicional en el billete.

Notese como escribir la info en la parte inferior a diferencia del billete de $5 USD. La razón de hacerlo así es para que el que sostiene el billete le sea mas facil verificar que es el mismo numero de serie utilizado al doblar el billete para ver la info pertinente de ambos lados.

Yo utilizé etiquetas ordinarias (2"x4") y los pegué a los billetes. Lo ideal seria haber imprimido directo en el billete pero desafortunadamene las imagenes de fondo causan demasiado ruido para que los códigos QR sean legibles. Lo importante a notar es que en teoria toda esa info se puede imprimir en el espacio de cualquier billete ordinario.

Como determinar si cierto billeto tiene una direccion multisig válida y tiene los supuestos bitcoins:

1. Primero vas a https://coinb.in/multisig/#verify y pegas el redeem script (decodifica base64 antes si fue escaneado desde un código QR). Deberá mostrar la dirección multisig
que comienza con 3 y la lista de llaves públicas que se requieren para cobrar los fondos de la transacción. Tambien verificar que todas las firmas son requeridas. Notese que si usaramos un estandard set de llaves públicas este redeem script se podria regenerar unicamente con el folio y no sería necesario imprimirlo en cada billete.

2. Una vez obtenido la dirección multisig checa en un explorador de blockchain (eg blockchain.info) y checa que si contiene los supuestos bitcoins.

Propósitos

Pienso que este sistema puede ser muy útil en paises donde se sufre severa inflación (Venezuela, Argentina, etc). Los ciudadanos pueden tomar sus propia moneda y comenzar a imprimirle los bitcoins para evitar que se devaluen aun mas, y utilazarlos en lugar de billetes no bitcoineados para las transacciones diarias. Podrian funcionar como propinas y pequeños obsequios en lugares donde ya se utiliza bitcoin en monedores digitales o en cualquier lado. Puede tambien ayudar a difundir la idea de bitcoin particularmente en paises subdesarollados.

Se podría desarollar una app movil que escanea el billete, determina el tipo de moneda y lee el folio. Desglozaria las llaves públicas utilizadas y el importe de bitcoins. El usuario podria mantener una base de datos de llaves publicas que confia y si una de esa llaves publicas estan encodificados en el billete puede tener la tranquilidad que su billete se mantendrá bitcoineado. bitcoins will not be withdrawn. La app intentaria guardar todo el blockchain para que pueda verificar billetes sin tener que estar conectado al internet.

Se podría tambien desarollar una página web usando javascript, donde el usuario ingresa la moneda, denominacion y numero de serie y este regresa la multisig con sus llaves públicas correspondientes y el importe de bitcoins contenidos ahí. Tambien esta misma página podría hacer la operación inversa: generar una direccion multisig, incluyendo códigos QR, sugeriendo un set de llaves públicas reconocidas de los cuales el puede escoger para que así enviar los bitcoins y sellar el billete.

Los invito a que bitcoineen sus propios billetes y posteen fotos aqui.
257  Alternate cryptocurrencies / Altcoin Discussion / Human mine-able cryptocurrency that works indexing projects? on: March 20, 2014, 12:58:15 AM
I think it would be a great idea to make a human mine-able crypto currency that rewards people who work on indexing genealogical records.

This is a tedious thankless job that requires several steps that no computer can automate.

It would be great if all these volunteers could be rewarded like this.

For more info on how indexing works: https://familysearch.org/indexing/
258  Bitcoin / Project Development / Re: Proposal to imprint bitcoin unto paper currency on: March 15, 2014, 11:09:06 PM
Good idea but is a federal crime to mutilate a bill. I prefer the way to have own paper money as paper wallets, just as casaciuos coins and bills, only with multisign addresses.
Yeah, the best solution would be to create an organization with reputable members who would provide their own public keys and print its own currency.

Caucassius coins could do it with its own coins and they wouldn't even need to hide a private key on their own coins, just coin them with a serial number.

The main point of my OP is to show that it can be done, as long as the paper currency is hard to counterfeit and that it has a serial number.
259  Bitcoin / Project Development / Re: Proposal to imprint bitcoin unto paper currency on: March 15, 2014, 03:56:28 PM
I like this idea. However, there's something that bugs me...

When you add the bitcoins to the bill address, they are unspendable online (unless you happen to agree with all the parties required for the multisig). That means that if I receive a physical 0.5 BTC payment, there's no way I can add them to my phone wallet so I can buy this nice thing I just saw on the Internet.

Doing this would “fork” the bitcoins, in the sense that physical bitcoins would be separate from the online ones, which would lead to having two currencies.

I know all this is a very tough problem, but maybe the solution doesn't need to be literally having bitcoins in your hand.
Yeah, the bitcoins become unspendable electronically. You can only spend them if someone else accepts the physical bill, which is kinda of the point. The way this "fork" can be prevented  is if an organization decides to print their own currency using this system with a set of public keys of which it can later get the signatures from to redeem the funds in an ordered and transparent way and physically destroying the bills afterwards. The public using the bills will have to trust the organization but up to a point because if such organization cannot actually strip the bitcoins from the bills without the public knowing it since they can continually check that the bitcoin addresses still has the purported bitcoins.

You have a good point about using currency codes.
260  Bitcoin / Project Development / Proposal to imprint bitcoin unto paper currency on: March 15, 2014, 04:34:11 AM
Proposal to imprint bitcoin unto paper currency

I have the following idea to put bitcoin unto paper currency: you take the serial number of any government issued paper bill and create a multisig wallet with it. You then send funds to this address. Mutilate and mark the bill with the amount of bitcoins.

The bitcoins deposited in the multisig P2SH address cannot be redeemed because the multisig will be composed by several keys owned by diverse people and organizations who wouldn't care less to actually come together to sign the P2SH. This means that whoever is holding the paper bill can be assured he is holding unique bitcoins that are not spendable by anyone else.

It is important that the bill to be marked is very hard to counterfeit and that it holds a unique serial number. That is why government issued paper bills are perfect. Of course, this idea can be applied to anything that fulfills these two characteristics (unique serial number and hard to counterfeit) including issuing your own paper bills or coins with serial numbers.

It would be good if we can come up with a standard set of public keys, to make the generation and verification of multisig address conforming predictable, otherwise the one bitcoining the bills will have to publish his own set.

What is the purpose of this? It allows anyone to actually have bitcoins in their possession without access to any computer device or internet connection. Bills only have to be verified once by the possessor of the bill by consulting the blockhchain and thats it. This blockchain doesn't have to be up to date since it is virtually impossible for the bitcoins to be extracted from the multisig address so there will be no future transactions showing any redeeming of these bitcoins.

Step by step way to create the multisig address for a specific bill.

1. Determine the nationality and denomination of a bill.
2. Add the serial number imprinted on the bill
3. Create a brain wallet with this data as the seed using a standard method, separating with a space the nationality, denomination and serial number
4. Select 4 or more regular (starting with 1) address from known addresses.
5. Create a multisig P2SH address combining all the bitcoin address starting with the one generated from the serial number of the bill.
6. Send funds to this address. I suggest using the denomination of the bill as guide. 0.0005 BTC for $5.00 USD, 0.001 BTC for $10 USD, etc
7. Write on the bill the nationality and denomination beside the serial number so the original address can be determined, and the amount of bitcoins it is holding.
8. Mutilate the bill so that it becomes easily distinguishable from another non bitcoined bill to avoid losing it by mistake. I suggest a standard double fold in half then a vertical cut on the third crease.

Example:
1. US. 5 dollar bill.
2. US 5 IF84621533C
3. Generate Brain Wallet
Image:  http://fantasticocomic.com/bc/bitcoinedbill-1.png
4. Generate P2SH Address. We will use the following arbitrarily chosen public keys which I took from transactions I found on the blockchain:
Code:
Linux Mint Donations:
04abc9f887ac2273df9c8db1d68cf520fd343bb567e2da68d057ae5d5b0e93d6b413c56762c0db15b582aeaeb4455c814f67b582da117b177b776b353145452e5d
Free Talk Live:
041ab4dcddd2c7a7b9928ff278661040d242080b8adf85870f5af01a7a3c77fd74af031e365cc1d9b8d5dc102e87f6dd183f3884b23cd1dafc5ea9c86db9ba42e9
Bitcoinity:
048ac1b0a436bec71eeab01becd493be697f78a72131f15501720d1791ad90521647fe8f1d539d21569ff7f6c15c890731b6b3e247fa2f2255171c2f4342e72f8d
BitcoinTalk Forums:
04271bb147a592a7cbb0323ec42ff1d056f125c431383cc4480b4d2f511c06802beb475ade7c29eb2572a4fc73895a806c5c0d2efc84f2bead24399980f41e2889
Archive.org
043b640c644e5cda2f2e4be20bca4535882fd5053e7a72c18736d179049aaa27c33febcb12ae597f80c29b4ce9bff32ef5654351ac310b514b66064755d8e24af2
SatoshiDice 0.78%
04c78beee103e8392bc3aa13ee779b8084fa9fd3b54cbace8520fa427a19f5aebfe8aba1cca8a7c1ec3f858ba8fb050c2e603cf932782bc78ec4eac258c8db1e13
5. We also add the public key generated by the brain wallet with the USD 5 and serial number passphrase
Code:
045119754ff7cd6bcf1116a5b74c0af7a2d25fa9b631d735e1b232646b2f24ffa4004f870d97c01b8dbb27393473c3124af669aa505baf73da0a7682e216c06d81
Image: http://fantasticocomic.com/bc/bitcoinedbill-2.png

6. We send 0.0005 BTC funds to the Multisig addrress ( 3FScohu2zS57323xt58LBc3if9r2juLCTw ) using any wallet software. Add 0.00001 transaction fee.
7. We write on the bill the amount sent and mutilate the bill.


8. Publish the redeem script so others can verify it:
Code:
5741045119754ff7cd6bcf1116a5b74c0af7a2d25fa9b631d735e1b232646b2f24ffa4004f870d97c01b8dbb27393473c3124af669aa505baf73da0a7682e216c06d814104abc9f887ac2273df9c8db1d68cf520fd343bb567e2da68d057ae5d5b0e93d6b413c56762c0db15b582aeaeb4455c814f67b582da117b177b776b353145452e5d41041ab4dcddd2c7a7b9928ff278661040d242080b8adf85870f5af01a7a3c77fd74af031e365cc1d9b8d5dc102e87f6dd183f3884b23cd1dafc5ea9c86db9ba42e941048ac1b0a436bec71eeab01becd493be697f78a72131f15501720d1791ad90521647fe8f1d539d21569ff7f6c15c890731b6b3e247fa2f2255171c2f4342e72f8d4104271bb147a592a7cbb0323ec42ff1d056f125c431383cc4480b4d2f511c06802beb475ade7c29eb2572a4fc73895a806c5c0d2efc84f2bead24399980f41e288941043b640c644e5cda2f2e4be20bca4535882fd5053e7a72c18736d179049aaa27c33febcb12ae597f80c29b4ce9bff32ef5654351ac310b514b66064755d8e24af24104c78beee103e8392bc3aa13ee779b8084fa9fd3b54cbace8520fa427a19f5aebfe8aba1cca8a7c1ec3f858ba8fb050c2e603cf932782bc78ec4eac258c8db1e1357ae
Again this step could be avoided if we can come up with a standard set of public keys to be used universally.
Alternately print the redeem script base64 encoded with a QR code on the other side of the bill. I used the handy conversion tool at http://brainwallet.org/#converter. I also added for convenience sake QR code of P2SH address and info. I used the Bitcoin QR Code generator at http://bitcoinqrcode.org/


Another example using Mexican 20 peso bill:
1. Generate Brain wallet with the following pass phrase: MEX 20 T6944908
Image: http://fantasticocomic.com/bc/bitcoinedbill-3.png
2. Generate P2SH Address, copy and paste the public key from the brain wallet and add the other 6 public keys. We will use the same 6 from the previous bill.
Image: http://fantasticocomic.com/bc/bitcoinedbill-4.png
3. Send .0002 BTC to the P2SH address ( 3JgyBtcQ7Sp9R17jSRdhi9TCWqbz2vQUed ) Be sure to add 0.0001 transaction fee.
4. Write on bill the amount of bitcoins it holds and how the passphrase was derived:

5. Publish redeem script so others can verify it:
Code:
5741049ccb1f411b983644512b9ba63f30a7e74f20d035571fb18b1c03f988e1342ef2742dad15ef44a984eeb04dcd0e16a9031f32f5eba278aa65bef3ec4e5e347bb54104abc9f887ac2273df9c8db1d68cf520fd343bb567e2da68d057ae5d5b0e93d6b413c56762c0db15b582aeaeb4455c814f67b582da117b177b776b353145452e5d41041ab4dcddd2c7a7b9928ff278661040d242080b8adf85870f5af01a7a3c77fd74af031e365cc1d9b8d5dc102e87f6dd183f3884b23cd1dafc5ea9c86db9ba42e941048ac1b0a436bec71eeab01becd493be697f78a72131f15501720d1791ad90521647fe8f1d539d21569ff7f6c15c890731b6b3e247fa2f2255171c2f4342e72f8d4104271bb147a592a7cbb0323ec42ff1d056f125c431383cc4480b4d2f511c06802beb475ade7c29eb2572a4fc73895a806c5c0d2efc84f2bead24399980f41e288941043b640c644e5cda2f2e4be20bca4535882fd5053e7a72c18736d179049aaa27c33febcb12ae597f80c29b4ce9bff32ef5654351ac310b514b66064755d8e24af24104c78beee103e8392bc3aa13ee779b8084fa9fd3b54cbace8520fa427a19f5aebfe8aba1cca8a7c1ec3f858ba8fb050c2e603cf932782bc78ec4eac258c8db1e1357ae
6. Alternately print redeem script base64 encoded with additional info on the bill.

Notice how I put the writted info on the bottom unlike the 5 USD bill. THe reason for this is for the holder of the bill to be able to more easily verify that the same serial number is being used by slightly bending the bill to view the pertinent info from both sides and compare.

I used ordinary labels (2"x4") and stuck it on the bill. Ideally would be to print directly on the bill. Unfortunately the background image creates too much noise for QR codes to be readable. The important issue is that all the data can be theoretically printed on an area of an ordinary currency bill. Best would be if we could set a standard stating the list of well known public keys and use for all bills so the redeem script does not have to be printed on each bill.

How to determine if the bill has a valid multisig address with the funds:

1. First goto https://coinb.in/multisig/#verify and paste the redeem script (decode base64 if it was scanned from the QR code. It should show you the multisig address beginning with 3 and a list of public keys requiered for releasing the transaction. Also check that all of them are required. Note that if we use a standard set of public keys, the redeem script can be regenerated using the passphrase composed with the serial number and it would not be be necessary to print it on each bill.

2. Next go to a block explorer (eg blockchain.info) and see that the multisig address contains the purported bitcoins.

I believe this system could be very useful in countries that suffer from severe inflation (Venezuela, Argentina, etc). Citizens there can take their own currency and start to imprint bitcoins on them to prevent them from getting further devalued and use these bills instead of non bitcoined bills for day to day transactions. It can also serve for tips and small gifts and just regular small transactions anywhere. It might also help spread the use of bitcoin, particularly in less developed countries.

A mobile application could be develop that scans a bill, determines the type of currency and reads the serial number. Then it lists the public keys of the multisig addresses and the amount of bitcoin it has in store. The user could maintain a white list of public keys he can trust and if the multisig address contains any of these public keys he can be more reassured the bitcoins will not be withdrawn. This app could try to store the whole blockchain in order to be able to check a bill without having to be connected to the internet.

A webpage using javascript could also be developed where the user types in the currency type, denomination and serial number, and it returns the multisig addresses with its corresponding public key and the amount of bitcoins it has. It can also do the reverse: generate a multisig address, including QR codes, suggesting different well known public keys he can choose from so the user knows where to send bitcoins to fund the desired bill.

This is of course an open idea and I hope suggestions come up if it is worthwhile.

(Note about mutilating currency: the idea is to avoid the bills getting confused with normal currency. I am aware it is technically illegal in most if not all countries but then again its your own money and there are freedom of speech issues to consider. In brief I am not going to get into the legality of mutilating or defacing currency.)
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17 18 19 20 21 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!