Bitcoin Forum
December 10, 2023, 02:10:15 AM *
News: Mixers will no longer be allowed after Jan 1
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Local / Español (Spanish) / AMA: Soy un desarrollador de Bitcoin Core que habla español on: November 26, 2016, 01:32:08 AM
Hola, me doy cuenta de que la información en español no siempre es muy buena. Probablemente los desarrolladores que hablamos español podríamos haber comunicado sobre los progresos en Bitcoin Core.
AMA significa "Ask Me Anything" en inglés. Preguntamé lo que quieras sobre el desarrollo de Bitcoin Core o Bitcoin en general en este hilo.

Viendo artículos como no me extraña que la comunidad hispanoparlante esté confundida. Mi intención es ayudar a aclarar las confusiones que pueda.

A menudo gente acusa a Bitcoin Core de "dictadores", pero la verdad es que no son los desarrolladores ni los mineros quienes deciden las reglas de consenso sino los usuarios.

También veo muchas confusiones respecto a "segregated witness" ("testigos separados" si uno traduce literalmente). Tanto desde gente que se opone a él tanto como de gente que lo defiende.

NOTA PARA LOS MODERADORES: También oigo a mucha gente protestar de "censura" en este foro. Por favor, no borreis ningún mensaje de este hilo a menos que sea claramente publicidad o algo por el estilo. No soy moderador en este foro y aunque no creo que moderación de foros sea censura (no es díficil empezar otro foro y moderarlo de otra manera), no quiero que nadie piense que ninguna buena pregunta fue "censurada". Si hay muchos insultos o similar, a mi no me importa, simplemente tendré menos tiempo para contestar las buenas preguntas.

NOTA para los que pregunten: si hay muchas preguntas no las podré responder todas. Por favor, intenta leer las preguntas anteriores antes de preguntar y sé lo más claro posible. No supongas que sé algo sólo porque tú lo sabes. Algunas de mis repuiestas pueden ser preguntas.
2  Economy / Services / [WANT] Some of your GPU computing power for bitcoins on: June 12, 2012, 11:26:24 AM
Hi, I want you to stop mining for a little while and run my program (not dangerous, it's free software).
You can find more details in this thread:
I want to pay you more than you would have gained mining, but I'm not sure how to calculate that because I'm not sure how long it will take you to run my program.

3  Bitcoin / Mining / Run my program in your Nvidia GPU (for bitcoins) on: June 11, 2012, 10:17:23 AM
Do you have a relatively new Nvidia graphic card (must support CUDA)? Do you have linux installed?
You could run my project so that I can compare performance times with a better graphic than my GT 9500 and a newer CPU than my old single core AMD.
You will need to install a couple of programs: nvcc (the CUDA compiler), nasm (an assembler), gnuplot (to draw some charts) and maybe some basic C++ dev tools if you don't have them yet. I'll help you set up the program and then you only need to wait for the program to run. I'm not sure how much will it take but it can take a few hours in which you shouldn't be using your computer much.

Here's the software prepared to be installed and run with just "make":

The project is free software and anyone can also download it from this repository:

Please, contact me if you're interested in helping me with your computing power.
Although I have no idea about what would be fair, I'm willing to pay you some bitcoins for this.
I can also pay you with village's hours.
4  Bitcoin / Project Development / Article: "Ripple, Bitcoin and Peer-to-Peer Money" on: February 06, 2012, 08:46:38 AM
Check it out:
5  Bitcoin / Development & Technical Discussion / A generic protocol for cryptographic assets on: January 21, 2012, 09:06:00 PM
I've been thinking about ripple, bitcoin scripts, p2p stock and currency markets, etc. I want to propose a generic protocol so that it can be shared for all those systems. The communication mechanism is out of the protocol like in Open transactions.


Asset: a message with an amount transferred from one public key (PuK) to another.

Transaction: a message that proves that one or more assets are moved.

Promise: an incomplete transaction. It needs more signatures (and often more content too) to become a valid transaction.

Script: a scripting language similar to bitcoin's. Not Turing-complete to avoid infinite loops on verifications.


Minter: Its signature it's required for creating new assets. It's responsible for the "backing" of those assets.  

Accounter: A minter trust it for signing the movements of its issued assets. It's responsible for preventing double-spending. It's supposed to be always online. A minter can also act as its own accounter.

Timestamper: The actors of a transaction trust one of them or a minimum number of them from a list to provide atomicity to transactions in which several assets are moved. They're not mandatory but prevent DoS attacks. They are equivalent to registries in the decentralized ripple protocol draft.
Authenticator: Provides digital certificates and a legal base to the assets by linking a certain public key to a legal contract. Here must be specified if the asset is an IOU, a bond, a stock share, there's an interest rate, etc. They're not mandatory and the protocol can still be used informally.

Market: Receives and stores promises. It is queried by other actors and markets. Its nature is mostly public. For transitive transactions (like ripple's), it search for paths.

Client: The actual users trading the assets.

Proof of work chain: a bitcoin-like system. Acts simultaneously as a Minter, Accounter and timestamper for certain assets.
A chain where anyone can be a minter could be created too.

Examples of assets: currencies backed by fiat by, bonds and stock shares, rippleIOUs, access keys for smart property...

Use cases:

-Trade assets directly for bitcoins using the chain as timestamper. Examples:
-Trade assets instantly with a timestamp server.
-Decentralized Ripple
-Transitive transactions (I have nmc and you accept btc. I sell nmc for mtgoxUSD, mtgoxUSD for btc and I pay you all within the same transaction)
-Circular trades (like the above but I get another asset from you instead of a receipt).

EDIT: I have to rewrite the following design: it's flawed.
Messages (protocol buffers)

message BlockChain {
   required string nombre = 1;
   required bytes genesis_block_hash = 2;
   optional int32 checkpoint_block_number = 3;
   optional bytes checkpoint_block_hash = 4;

Identifies a proof of work chain like bitcoin or namecoin.

message Minter{
   optional PublicKey/hash? minter = 1;
   optional BlockChain block_chain = 1;

A minter can be either a block chain or a regular node.

message Asset{
   optional Minter minter = 1;
   optional PublicKey/hash? accounter = 2;
   required double amount = 3;
   optional PublicKey/hash? receiver = 4;
   optional PublicKey/hash? sender = 5;

For an asset to be valid, it also needs a proof containing at least the signatures of the the accounter and the sender.
If the accounter or the sender are not specified, the minter takes its duties and have to sign for them. Unless an asset says they will specified later (specifies a variable rather than an actual public key).
Not all the participants of the transaction know every asset, only the ones that are relevant to them.

message Script {
   repeated byte assets_hashes = 1;
   repeated string?bytes? commands = 2;

The whole Script message is what the OP_CHECKSIG in the script need to sign. The second field contains the actual commands of the script.

message Proof {
   required Script script = 1;
   repeated bytes signatures_hashes_secrets = 2;

The second field contains the signatures, hashes and secrets, etc. Whatever is needed for the script to return true.

message Transaction {
   repeated Proof proofs = 1;

To be valid, all the proofs must be valid. Timestampers don't need to read the assets, they just need to sign the Scripts.
The script language should have an OP_CHECKTIMESTAMP operation with two parameters, the signature and the expiry time.
Since proof of work chains can act as timestampers, a similar operation is needed for them. The expiries are expressed as block numbers and the chains must be identified. A hash of the genesis block or that and the hash of a given checkpoint block should be enough.
If a chain is designated as a timestamper, there must be an asset without minter affected by the timestamp and a transaction corresponding to that asset must appear in the chain.

Use cases:

A) Trade assets directly for bitcoins using the chain as timestamper. Examples:

minter and accounter: mtgoxUSD
market: something of the the sort of Dark exchange or just a regular server

A puts a promise (incomplete transaction) that contains the following (10 btc for 60 mtgoxUSD):

asset1 = {minter = mtgoxUSD_PuK, amount = 60, sender = A1_PuK, receiver = $asset1.receiver}
asset2 = {minter = bitcoin, amount = 10, sender = $asset1.receiver, receiver = A2_PuK}

script1 = {
   assets_hashes = {hash(asset1), hash(asset2)},
   commands = {OP_CHECKSIG A1_PuK, OP_CHECKSIG $asset1.receiver, OP_CHECKSIG mtgoxUSD_PuK, OP_CHECKTIMESTAMP bitcoin 170000}

proof1 = {
   script = script1,
   signatures_hashes_secrets = {A_PuK1_signature}

transaction1 = {
   proofs = {proof1}

B sees the transaction in the market and wants the 60 mtgoxUSD

He fills $asset1.receiver = B1_PuK. Signs the transaction and sends is to mtgox to sign.
When he receives it back, he builds a bitcoin transaction with source = B1_PuK, destination = A2_PuK and broadcasts it.
When the transaction is confirmed in the bitcoin chain transaction1 becomes valid.

This example could also be applied to bonds, stock shares or other assets instead of mtgoxUSD.

B) Trade assets instantly with a timestamp server.

minters and accounters: mtgoxUSD, tradehillBTC
market: something of the the sort of Dark exchange or just a regular server

asset1 = {minter = mtgoxUSD_PuK, amount = 60, sender = A1_PuK, receiver = $asset1.receiver}
asset2 = {minter = tradehillBTC_PuK, amount = 10, sender = $asset1.receiver, receiver = A2_PuK}

script1 = {
   assets_hashes = {hash(asset1), hash(asset2)},
   commands = {OP_CHECKSIG A1_PuK, OP_CHECKSIG $asset1.receiver, OP_CHECKSIG mtgoxUSD_PuK, OP_CHECKSIG tradehillBTC_PuK,  OP_CHECKTIMESTAMP timestamper_PuK "22/01/2012 00:00:00"}

Both A and B must trust the timestamper. They can query the timestamper to see the state of the transaction.

C) Trades with not binding advertisements

In the two previous cases, A pre-signed the transaction and was binded to the promise, but the promise could lack its signature and be added later without the need of variables.
By the way, I'm not very confident about how variables are used here. Maybe they're not compatible with protocol buffers as I've used them in the previous examples.

D) Decentralized Ripple

With a chain as timestamper (paying a fee and with someone paying to himself) or a timestamp server.
Each ripple node is a minter.
accounters: ripplepay, villages...
markets: something of the the sort of Dark exchange (with the payer client also behaving as a market for searching the path), ripplepay, villages...

Consider the ripple transaction A -> B -> C -> D
Markets also calculate paths.
For example, A queries ripplepay_market "10 d's from A to D". The market looks in its database and answer with promises:

b's for a's at 1:1
c's for b's at 2:1
d's for c's at 1:4
so that 10 d's are 20 a's

There's no need to include the denomination, only the exchange rates are important.
Only the sender, receiver and accounter of each asset must know what it contains and the other participants can still see the hash of the asset and their signatures.
The payer of the ripple transaction, since he creates it, will know all assets involved in the transaction.
Binding promises (assets with variables) must be public for all participants in the transaction so that they can verify that the variables are being used properly.

E) Using secrets and bitcoin scripts to make contracts I haven't thought.

It seems a good idea to me, but maybe there's a fundamental flaw that I don't see. Any constructive criticism is welcomed.
What do you think?
What is missing or not needed?
6  Bitcoin / Development & Technical Discussion / Is a more efficient coin possible (Ben Laurie)? on: December 20, 2011, 04:18:54 PM
Hi, I've just read these papers by Ben Laurie and I'm really curious.

Could this work?
Can a "Byzantine-fault-tolerant agreement" protocol be used to identify participants while maintaining them unique (so people don't cheat to get more random coins) or you need an "efficient unbounded agreement" protocol for that one?
7  Economy / Economics / Debtocracy (documentary) on: November 27, 2011, 04:55:58 PM
An interesting documentary about the legitimacy of the Greek debt.
8  Local / Mercado y Economía / Deudocracia (documental) on: November 27, 2011, 04:52:37 PM
Interesante documental sobre la legitimidad de la deuda en Grecia.
9  Economy / Economics / Is labor theory of value a tautology? on: November 22, 2011, 02:13:38 PM
I've been discussing lately with Etlase2 about this theory in another thread, but I feel we went too off-topic and I decided to start this one.
Sorry, because this subject has been probably discussed several times here.

Although I don't know exactly where we disagree, it's clear that we do.
We're talking about this theory.
This is how understand the theory is wrong:

I don't think LTV is a tautology, I think it is a false proposition: "things are worth (and priced) what it costs to produce them".
And it is based on the false proposition that value is an absolute quality that can be measured through prices.
The reason why stuff is priced approximately what it costs to produce them is that if a business spends more in production it goes bankrupt.
And if a business prices its products far above its costs, the competition takes its place. But never because the costs of production give the product any value.

But he says I'm not getting his point:

"It is not that pearls fetch a high price because men have dived for them; but on the contrary, men dive for them because they fetch a high price."

And it is based on the false proposition that price is an absolute quality that can be measured through value.

See what I did there? It's arguing whether or not A = 3-1 or A = 1+1. The price is known, both theories attempt to discover why the price is what it is. There are no absolutes in either. The variables are always going to add up to the price because the price is the only thing we know. They are both attempts to explain phenomena. LTV is generally an intrinsic explanation, marginalism is generally a subjective explanation. Marginalism just happened to be developed around the same time that Marx adjusted the LTV to suit his needs, and marginalism filled in most of the blanks that Marx (or the LTV) had not yet explained. Just because the LTV has not received similar treatment does not mean that it is false, it just means that modern economists switched perspectives and stopped working on it (mostly because they hated Marx).

Does someone gets his point and can explain to me in a way that I can understand it?
10  Economy / Economics / Bernard Lietaer on alternative currencies on: November 13, 2011, 04:40:42 PM
11  Local / Español (Spanish) / comercia sin dinero ni trueque on: November 08, 2011, 10:38:56 AM
Hola, esto no está directamente relacionado con bitcoin, pero como la mayoría de bitcoineros está interesado en alternativas monetarias...aquí va.

Esta página web ofrece un sistema de banco de tiempo basado en ripple (descentralizado, tú eliges en quién confías).
En realidad no es estrictamente un banco de tiempo, porque podrías vender otras cosas por "horas".
La cuestión es que esta herramienta te permite comerciar sin dinero ni trueque (no necesitas que el que quiere algo tuyo tenga algo que ofrecerte, no sufre el prbolema de coincidencia del trueque).

Más links relacionados:

Así he invitado a mis amigos:

Esta página os permitirá comerciar sin dinero ni trueque.
Puedes poner anuncios de cosas que ofreces (clases de algo, diseño gráfico, las verduras de tu huerto, las carteras de cuero que te haces, masajes, los libros de texto que tu hijo usó el año pasado, la maqueta de tu grupo, etc).
También puedes anunciar cosas que quieres/necesitas (un abrigo calentito, cambiar la alcachofa de la ducha, traducción de un texto, un corte de pelo, un canguro para una tarde, los libros de texto de tu hijo para este año, etc)
En vez de tener que encontrar a alguien que ofrezca lo que tu quieres y quiera lo que tú ofreces (como en el trueque) los favores se pagan reconociendo horas a los demás. Pero aunque puedes pagar a qualquiera de esta manera, tú sólo vas a deber y sólo te van a deber horas tus amigos directos.
Un ejemplo:

Ana confia por hasta 2 horas en Bernardo
Bernardo confia por hasta 1 hora en Ana
Carlos confia por hasta 3 horas en Bernardo
Bernardo confia por hasta 3 horas en Carlos

1) Ana le prepara un bizcocho a Carlos y éste le paga con 1 hora.
Ahora Carlos debe una hora a Bernardo y Bernardo una hora a Ana (Bernardo en total debe 0 horas)

2) Carlos le da unas clases de Italiano a Bernardo y éste le paga con 2 horas.
Ahora Bernardo le sigue debiendo una hora a Ana y le debe (2 - 1 que le debía Carlos a él) 1 hora a Carlos.

¿Entendéis más o menos como funciona?
Echarle un vistazo a la página y si tenéis cualquier duda, podéis preguntarme por aquí o por correo.

En un sistema parecido se basan muchas monedas locales y los bancos de tiempo, aunque en estos casos todos los participantes confían en la organización y la organización tiene que confiar en todos ellos en vez de cada uno elegir en quién confía.
Principalmente la página te servirá para comerciar con gente en tu localidad, pero no está restringida geográficamente.

Aprendamos a ser menos dependientes de los bancos y del dinero, recuperemos el poder que les hemos delegado y del que están abusando.
Participemos activamente en una economía más local y, por ello, menos dependiente del transporte y el petróleo.
12  Alternate cryptocurrencies / Altcoin Discussion / decentralized time banking focused on local trade on: November 08, 2011, 10:27:45 AM
It is based on ripple but only allowing hours as units. But, hey, you can trade anything, not only math class hours.

Some other useful links:

It's only starting and you need to ask for an invitation but looks easy to use and promising.
13  Economy / Economics / Chris Martenson on peakMoment on: October 28, 2011, 02:14:23 PM

I wonder if he knows about bitcoin.
14  Economy / Economics / Who are the shareholders of the Bundesbank? (removed from yahoo answers) on: October 06, 2011, 07:36:12 AM
Hi, I friend of mine is trying to find out who are the share holders of the Bundesbank but he can't.
He asked it in yahoo answers but apparently that violates the "community rules".
Anyone knows the answer?
15  Bitcoin / Development & Technical Discussion / Smart property and stock shares (contracts use case) on: October 04, 2011, 08:50:07 PM
I haven't thought the details, but I'm sure it is possible.
The proposal is simple: decentralized a stock exchange with contracts.
Probably you should read this:

I'll explain it with an example:

1) The founder of the company sells 100 shares of his company by splitting a btc (or less) into 100 transactions with 0.01 btc to the buyers.

2) The holders of those ownership keys will receive the dividends.

3) Owners can place an ask order (not necessarily in the chain, but distribute it in a parallel p2p network) through a transaction that says sumarizing "I send this 0.1 btc to whatever address sends 30 btc (the selling price) to S2". In fact, the founder could have done this from the beginning.

I think the last part is actually the hardest part. Please, correct me if what I propose is not feasible the way I want to do it.

0) The seller just broadcasts a hash of his secret along with his public key (the receiving key for the trade, S2), the current ownership key (S) and the selling price (all signed with the ownership key). Then the chain trade is executed with the seller of the share acting like B and the buyer like A. Almost nothing changes:

1) Both parties generates a new key and some random data (the secret).
2) Party S sends a hash of his secret to A along with his public key. (already done in 0)
3) Party A generates Tx1 (the payment for the share, from A to S2) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key A and key S) or with (secret A, secret S, key S). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.
4) Party A generates Tx2 (the contract) which spends Tx1 and has an output going back to key A. It has a lock time of some point in the future and the input has a sequence number of zero, so it can be replaced. A signs Tx2 and sends it to S, who also signs it and sends it back.
5) A broadcasts Tx1 and Tx2. Party S can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.
6) S performs the same scheme in reverse on the alternative chain to transfer the share. Both sides of the trade are now pending but incomplete.
7) A sends his secret (random data) to S, who then uses it to re-issue the now finalized contract using (secret A, secret S, key S) and an output of his choice (S2). S now owns the coins but in the process of claiming them, revealed his secret, allowing A to claim the other side of the trade (to claim the share).

If someone thinks "hey, you have to trust that the founder/managers of the company will pay you the dividends", he is right. Yes you have to trust the managers when you want to buy shares of their company.

What do you think? Another use case for contracts?
Is there anything wrong in the trade part?

16  Economy / Economics / Freicoin (was Re: Deflation and Bitcoin, the last word on this forum) on: September 21, 2011, 07:26:06 AM
I thought you claimed "there's nothing wrong with deflation" too. Sorry, my fault.

By "undeniable truths" I mean premises that are obvious to anyone and that no one will discuss. Logic is part of math, is not a social science.

I agree, I prefer gold over USD. But national inflationary (I prefer this term over fiat because I don't think fiat is bad per se, in fact I consider bitcoin fiat) currencies are not the only alternative.

I think business cycles are avoidable because I think their root cause is interest.

I consider gold and bitcoin flawed because they have interest. I advocate for ripple and freigeld (freicoin if you want to keep the state out of its issuance) and ripple instead. Well, I advocate for bitcoin (it's enough hard to explain it without the demurrage, one step at a time) and I recommend people to buy gold and silver (to protect themselves against what I see as the "unavoidable global fiat system collapse"), but I think they won't be the "money of the future" because of their flaw.

I bet you're going to answer with one of these two:

-Without interest people invest in stupid things.
-Demurrage is isomorphic with inflation.

But those questions are not about deflation. If you want, we can discuss those points here:
Probably I will start a new thread "Why demurrage is not equivalent to inflation".
17  Bitcoin / Development & Technical Discussion / Why class attributes are not encapsulated? on: September 14, 2011, 09:32:26 AM
Hi, I want to make a bitcoin fork with demurrage. If CTxOut::nValue where properly encapsulated (get/set), it would be much easier for me to add demurrrage and still have a code very similar to bitcoin's when technical changes are committed into the main repository.

[Kind of offtopic]
I mean, I don't see the point in developing technical improvements outside of the bitcoin project. If it is really an improvement, why not testing it and introduce it in bitcoin. I think the closer freicoin's code is to bitcoin's, the better. Being free software, there's no point in competing through technical enhancements. I believe that if another chain is going to be greater than bitcoin the cause will be an economic property of the currency (like freicoin's demurrage) or an embebed service (like namecoin's DNS), but a purely technical advantage can be applied to bitcoin. That's why I don't like solidcoin, i0coin, etc. They can be nice experiments, but I won't trade them. Most of my earlier proposals (for exchange between chains or for escrow) can be implemented through scripts/contracts, so the services that can be embebed in a chain (and are not feasible in bitcoin) are more limited than I first thought.
[/Kind of offtopic]

Is there a reason why class attributes are not encapsulated?
Is there plans to change the code without changing its functionality so that it gets more readable and robust (follow software engineering standarts and these kind of things)?
18  Alternate cryptocurrencies / Altcoin Discussion / New forum for Freicoin on: August 24, 2011, 12:33:32 PM
I've started a new forum to discuss the implementation of freicoin:

The main discussion now is how the generation curve should be.
Everyone is invited to join, but if you think demurrage is a really bad idea, please, don't go there to troll. If you don't like it you already have bitcoin.
Adding support for decentralized ripple in our chain is a possibility too.
19  Economy / Economics / Who Killed Economic Growth? on: August 20, 2011, 02:35:26 PM
An interesting video about the effects of peak oil in the economy by the post carbon institute.

The exponential growth of debt must and will end.
20  Bitcoin / Project Development / Ripple implemented in a block chain as an IOU exchange on: August 16, 2011, 05:08:10 PM
EDIT: the messages design here is probably flawed/obsolete. To know more about the general idea maybe the original post is better. For an updated and more concrete design better read about colored coins. This is basically the same without underlying satoshis (modfying the protocol)

I posted it in the Ripple forum, but some people may be interested here.

I want to propose the block chain as a mean to decentralize ripple again. I think I've simplified the rippleCoin protocol.
The chain would act just as an exchange of IOUs.
Any address can generate new IOUs and transfer them to another address just like bitcoins are transferred.
The new owner of the IOUs can also transfer them.

add1 issues 10 units (the system doesn't care about the denomination) to add2. add2 transfers 5 units to add3. add3 transfers the 5 units to add1 and these IOUs are destroyed

Now, for ripple payments, imagine we have the ripple network: add1 <-> add2 <-> add3 <-> add4.

add2 offers up to 10 add2 IOUs for add1 IOUs at an exchange rate of  1 : 1.1 + 1
add3 offers up to 10 add3 IOUs for add2 IOUs at an exchange rate of  1 : 1.05
add4 offers up to 5 add4 IOUs for add3 IOUS at an exchange rate of  1 : 1

If add1 wants to pay 5 units to add4 he must:

1) Buy 5.25 add2 IOUs for 6.775 [(5.25 * 1.1) + 1] add1 IOUs
2) Buy 5 add3 IOUs for 5.25 add2 IOUs
3) Buy 5 add4 IOUs for 5 add3 IOUs
4) Transfer the add4 IOUs to add4

He could buy IOUs previously to increase its future liquidity, but if he hadn't, he only wants to make the 4 steps or none of them.
So to achieve atomic ripple payments within the block chain, there must be a type of super-transaction that includes smaller transactions and it can be only valid as a whole.

To incentive miners, rippleCoins are issued. To reward miners forever there's a few solutions, but I think the best is to have a stable monetary base (once the maximum has been issued) and destroy by demurrage as much as is given to miners.
RippleCoins can be traded for IOUs, increasing the liquidity of the system.

The connected nodes can share public keys to identify each other in the chain while maintaining a flexible level of privacy.
Trade offers can be sent to neighbors or broadcasted.

In summary we have 3 types of transactions that appear in the chain:

1) Simple transfers (of rippleCoins or IOUs)

2) Trades (of different IOUs or IOUs for ripplecoins)

3) Composite trades (composed of various trades)

Some specifications:

message TradeOffer {
   required PublicKey seller;
   optional PublicKey offeredIOUs;
   required float maxAmount;
   required float exchangeRate;
   optional float flatFee;
   optional PublicKey demandedIOUs;
   required int expirationBlock;
   required Signature sellerSignature;

* offeredIOUs or demandedIOUs must be defined (Doesn't make sense to trade rippleCoins for RippleCoins).

message Trade {
   required TradeOffer offer;
   required PublicKey buyer;
   required float amount;
   required Signature buyerSignature;

message compositeTrade {
   repeated Trade trades;
   optional int expirationBlock;
   optional Transfer payment;

* A composite trade will expire when one of its trades expire, so compositeTrade::expirationBlock only makes sense when is lower than the lowest expiration clock of its trades.
** The payment transfer would be from the ripple payer to the ripple recipient and the currency would be IOUs issued by the recipient. The payer acquires them in this composite transaction, but they may have been issued before.

What do you think? Do you see any important flaw ?

NOTE: Ripplecoins could be exchanged for bitcoins too (within this decentralized chain) if the RippleCoin network watches the bitcoin blocks, which miners are going to store if there's merged mining anyway.
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!