On a decentralized bitcoin-based stock market...

[Meni Rosenfeld]

It's pretty easy.

Create a separate message system with messages that handle asset creation, voting, transfer of assets, etc. These messages will contain all of the public-key crypto. A centralized message distribution server instead of a P2P protocol would be OK, since the server doesn't have all that much power.

To prevent double-spending during asset transfer, some of the messages need to be timestamped by including a hash in the Bitcoin block chain. You wouldn't even need to modify Bitcoin to do timestamping: just send some BTC to an address that is not real and actually consists of message data. (Modifying Bitcoin would allow you to do this without destroying any BTC.)

Unless I'm missing something, this still doesn't allow placing committing orders.

[1713513025]

1713513025

[1713513025]

1713513025

[1713513025]

1713513025

[1713513025]

1713513025

[DeathAndTaxes]

Maybe not all the services GLBSE can be decentralized, but the stock issuance and exchange can be.
That would make GLBSE more resilient and less dependent on government regulations.

A hybrid is a way to bootstrap it quickly.

A decentralized network for issuance and ownership.  Centralized tools (like GLBSE) could be built on top of that.  One of the difficulties in decentralized exchanges is enforcing open orders.  Having the decentralized network handle issurance and ownership changes is much easier.

Then centralized exchanges (much like there are more than 1 exchange which trades NYSE or NASDAQ stock shares) can handle trades.  

Granted a completely decentralized network which can handle:
* issuance
* order enforcement
* ownership changes
* internal escrow (trading 1 share for 1 BTC neither party can cheat and end up w/ both)
* dividend payments
* voting
* etc

would be superior but it is much more challenging to build and would require some proof-of-work type method to reach consensus and prevent attacks.

A network which only handles issuance and ownership changes is "decentralized lite".  It would require centralized exchanges to handle "higher level functions" but would allow competing exchanges and even OTC trades not involving any exchange.

[theymos]

Unless I'm missing something, this still doesn't allow placing committing orders.

You can use the "trading across chains" scheme.

What I described is a lot like having a separate chain with merged mining, but without the mining. So you can do most of the fancy things that Bitcoin-based chains can do.

(Maybe this kind of trading is also possible with your design, but I intuitively don't like tying assets to BTC, since BTC is meant to be split and combined, and assets are not.)

[ripper234]

(Maybe this kind of trading is also possible with your design, but I intuitively don't like tying assets to BTC, since BTC is meant to be split and combined, and assets are not.)

Assets are certainly meant to be split ... why wouldn't they?
It wouldn't make sense to combine assets of different "types", but of the same type - why not?

[DeathAndTaxes]

(Maybe this kind of trading is also possible with your design, but I intuitively don't like tying assets to BTC, since BTC is meant to be split and combined, and assets are not.)

Assets are certainly meant to be split ... why wouldn't they?
It wouldn't make sense to combine assets of different "types", but of the same type - why not?

The issue is across different types.

I have asked this everytime this method comes up and never got a good answer.

Say Address 123 has 1 satoshi to represent 1 "something" (share/USD/ounce of gold/etc).

What happens if I send 1000 satoshis to that address.  Address 123 now has 1001 satoshis.  Obviously you don't have 1001 "somethings".

To make it a little bit more complicated say you then send 1 satoshi to Address 999 and 1 satoshi to Address 888 and the change gets sent to adresss 456.

So it is now
Address 999: 1 satoshi
Address 888: 1 satoshi
Address 456: 999 satoshi

who has the share?

[ripper234]

Say Address 123 has 1 satoshi to represent 1 "something" (share/USD/ounce of gold/etc).

What happens if I send 1000 satoshis to that address.  Address 123 now has 1001 satoshis.  Obviously you don't have 1001 "somethings".

According to Meni's "design", only the specific Bitcoins that were part of the generating transaction (that was signed by the issuer) signify any ownership of the asset. It doesn't matter what other Bitcoins also reside in the same address - since every satoshi can be traced back to its origin, you can never artificially inflate an asset, because the number of satoshis in the original transaction is constant.

To make it a little bit more complicated say you then send 1 satoshi to Address 999 and 1 satoshi to Address 888 and the change gets sent to adresss 456.

So it is now
Address 999: 1 satoshi
Address 888: 1 satoshi
Address 456: 999 satoshi

who has the share?

You can't do arbitrary transactions with assets - the special "asset tokens" satoshis are colored, and don't relate at all to normal satoshis. The one who owns the colored satoshi owns the asset.

[DeathAndTaxes]

only the specific Bitcoins that were part of the generating transaction (that was signed by the issuer) signify any ownership of the asset. It doesn't matter what other Bitcoins also reside in the same address - since every satoshi can be traced back to its origin, you can never artificially inflate an asset, because the number of satoshis in the original transaction is constant.

Except you can't.
Bitcoin can't trace unique satoshis anywhere (that would be very bad for psuedo-anonymous network).

Bitcoin actually has no concept of unique coins/bills/satoshis.

Bitcoin simply tracks VALUE.  

You can't do arbitrary transactions with assets - the special "asset tokens" satoshis are colored, and don't relate at all to normal satoshis. The one who owns the colored satoshi owns the asset.

That is the problem or misconception.

If you have an account with 1000 Satoshis it isn't 1000 uniquely identifable satoshis.  It is simply a unique ADDRESS which currently has a value of 1000.

Thus in the example above:
Address 123 has a value of 1 satoshi which represents a share.  That satoshi isn't unique.  The address is unique.  The satoshi is simply a integer value of 1 (same as any other address w/ 1 satoshi in it).

Bitcoin doesn't track satohi's back to their source it tracks values back to their source.  Once combined you can no longer say which value came from where.  You can simply say the value is correct.

Maybe I am not being clear but take this no share example.

Address 123:  5000s
Address 456:  1s

I make a transaction using 123 & 456 as input and sending 2s to 888 & 4999s to 999.
The ending output is
Address 888: 2s
Address 999: 4999s.  The only thing you (and network can say) is the combined value of 5001s is CORRECT because it matches the inputs VALUES (not unique coins) of 5000 + 1.  If the transaction is valid we know the ending output values are also valid.

However you can't say "where" the 2s in address 888 "came from".  You simply know the value 2 is accurate.

TL/DR version:
While we call it Bitcoin there are no "coins".  
There is no unique identifier on each unit.

Bitcoin is simply an accounting system.  It ensures the inputs match the outputs in "value".

[ripper234]

TL/DR version:
While we call it Bitcoin there are no coins.  There is no unique identifier on any "coin".  It is simply integer values tied to addresses.

I heard this argument all the time, and only now I understood what it means - thanks!

My original thoughts about implementing a p2p stock network revolved around Namecoins or a Namecoin-esque coin.

A name is something unique that can be tracked. See also this post about the cost of "long Namecoins".

[Meni Rosenfeld]

only the specific Bitcoins that were part of the generating transaction (that was signed by the issuer) signify any ownership of the asset. It doesn't matter what other Bitcoins also reside in the same address - since every satoshi can be traced back to its origin, you can never artificially inflate an asset, because the number of satoshis in the original transaction is constant.

Except you can't.

You can if you're careful. Bitcoins are fungible only at the intra-transaction level, not the address level.

If you carelessly combine token bitcoins with normal bitcoins in the same transaction then yeah, in the outputs you can't tell which one is the real one. But an address that has coins from several outputs can certainly tell how many came from each output.

Suppose that you never pay transaction fees, and never merge several tokens in the same transaction. Then there is a linear chain leading from the original output to wherever the token ended up (there can be multiple chains for the original output, but one chain for the endpoint). When an address wants to show it has tokens, it simply references the output from which it received them, and by assumption the transaction with this output only has a single input, so you just follow the chain backwards until the original output.

Transaction fees complicate things a little, because you need an unambiguous way to determine which inputs are tx fees and needn't be traced back. But it should be possible to agree on such a designation (eg tokens are only transferred in multiples of 10 satoshis, and for tx fees the input will be chosen not to be a multiple of 10).

Merging tokens also adds complication because for each output it's possible that several inputs will need to be verified. But the total work shouldn't exceed the total token transfers done.

And this whole thing becomes trivial if a protocol-enforced way is introduced to add markers to outputs. So a marker will be the hash of an output, and a transaction is valid only if the marked total in the output is at most the marked total in the input, where the output itself which has this hash is also considered marked. If not in Bitcoin itself, then in an alternative Bitstock blockchain (or maybe it will be BitAsset to make it more general).

Bitcoin can't trace unique satoshis anywhere (that would be very bad for psuedo-anonymous network).

You can't trace them if you're careful to cover your tracks. You can trace them if you're careful to "expose your tracks" (distinguishing tokens from normal BTC). Depending on the implementation you can still obfuscate tokens with other tokens.

Address 123:  5000s
Address 456:  1s

I make a transaction using 123 & 456 as input and sending 2s to 888 & 4999s to 999.
The ending output is
Address 888: 2s
Address 999: 4999s.

This is exactly the kind of transaction you will avoid if the 1s is a token.

[Meni Rosenfeld]

Unless I'm missing something, this still doesn't allow placing committing orders.

You can use the "trading across chains" scheme.

It looks like you're talking about enabling atomic trades where one side can't run away with the money. That's indeed easy. I'm talking about preventing people from not going through with an order they've placed. That is, someone puts an offer, he is contacted to execute it, and ignores the request if it's no longer profitable for him or he never intended to honor it but just wanted to manipulate the market.

(Maybe this kind of trading is also possible with your design, but I intuitively don't like tying assets to BTC, since BTC is meant to be split and combined, and assets are not.)

The design of using BTC as tokens, which is by no means mine, also can't enforce orders. Which is why I suggested on SE that indeed a separate system/blockchain will be needed for the shares. But I only went as far as saying that such a system can be designed to have the functionality required to enforce orders (as well as other asset-friendly features, such as markers) - but how exactly to implement this is still an open problem.

[DeathAndTaxes]

If you carelessly combine token bitcoins with normal bitcoins in the same transaction then yeah, in the outputs you can't tell which one is the real one. But an address that has coins from several inputs can certainly tell how many came from each output.

On edit:  I am wrong & Meni is right.  A third party couldn't pollute the "chain of custody" for a unique share.  Using satoshis as tokens should work fine.  The key point is that each transaction includes not only the address (which I knew) but also the prior address (which I didn't). 

You can't prevent the combining.

You have 100 satoshi in address 123 which represents 1 share.
I (the attacker) send 1 BTC to address 123.

The value of address is now  1000000123s.

How do you sell 50 shares?

Maybe I am just not seeing it?  Maybe you need to write a white paper but AFAIK Bitcoin doesn't track unique "coins" or unique satoshis.  It tracks value.  

If an address has a value >1 satoshi and that value is the result of multiple prior inputs (and those inputs have multiple inputs, etc) you can trace where each individual satoshi came from.  You can trace all the potential sources but not a definitive source.

So in the example above the 1000000123s all came either from the "stock address" or the "BTC address".  You can say in aggregate you have 1 BTC & 123 shares but you can't identify a single satoshi as a share.  

You can't create a transaction that for example
1 BTC (1000000000s) -> Address A
70s (representing 70 shares) -> Address B
30s (representing 30 shares) -> Address C

TLDR
An attack can comingle assets by simply sending you BTC.
Once comingled the assets can never be split without losing definitive ownership of the shares v/ "attack coins".

[Meni Rosenfeld]

Maybe I am just not seeing it?  Maybe you need to write a white paper but AFAIK Bitcoin doesn't track unique "coins" or unique satoshis.  It tracks value.

You are confused about how Bitcoin transactions work. And while what you're describing may be the ideal, where all bitcoins are fungible, the reality is different.

When I have BTC in an address A and I want to send some to address B, I don't say "Hey, I have bitcoins in address A, I'm sending amount X to address B", I say "Hey, I have bitcoins in address A which I got from some specific output, and I want to redeem this particular output in a transaction whose input is this output, and has an output sending X coins to B, and if the output I redeemed has more than X coins then I'm sending the extra to a change address in a second output".

So an attacker can't force me to comingle tokens with normal bitcoins. If he sends me 1 BTC I still have one redeemable output with 1 BTC and one redeemable output which can be traced back to the agreed upon token output with 123 satoshis.

I certainly can, and will, choose the output that traces back to the original output when I want to transfer tokens. As I said it can be tricky with tx fees and merging of tokens but still doable.

This will become much clearer if you spend some time in block explorer.

[DeathAndTaxes]

Maybe I am just not seeing it?  Maybe you need to write a white paper but AFAIK Bitcoin doesn't track unique "coins" or unique satoshis.  It tracks value.

You are confused about how Bitcoin transactions work. And while what you're describing may be the ideal, where all bitcoins are fungible, the reality is different.

I am completely wrong.  Learned something new today.  Yeah based on the actual transaction data it doesn't look like your could "pollute" the chain of custody for a share. 

This will become much clearer if you spend some time in block explorer.

It is.  Thanks.

I would go bad and delete my misinformation but it has been quoted so much it would make the thread even more confusing I think.

[jtimon]

I fear the only soulution to the "committing orders" would be through extending the bitcoin scripting language.
You could sign and broadcast partially completed transactions as "binding advertisements" like
"I send 1 shatoshi (share) to $BUYER_PUT_YOUR_ADDRESS_HERE if this transaction also satisfies 4.33 btc to addressC "
This also removes the need for secrets to achieve atomicity but would probably need an expiry condition too.

The btc tokens implementation is feasible, But the altchain is another possibility. The only problem I see is that you still have to incentive miners (even with MM). You could do it directly through bitcoin fees or by issuing a new currency. Although it seems less optimal, I would prefer to not creating it for this purpose (unless it has demurrage). Because unlike in namecoin where miners are actually "mining domains", the tokens here only represent promises from the companies and can be issued at will without the need of new currency. Anyway, although directly related, this is a controversial issue that can wait for later.
The question of having another chain or use the btc tokens is more important (and probably also controversial).
I guess it depends on how many changes bitcoin requires to make it work that don't serve to the currency itself.

[Meni Rosenfeld]

I fear the only soulution to the "committing orders" would be through extending the bitcoin scripting language.
You could sign and broadcast partially completed transactions as "binding advertisements" like
"I send 1 shatoshi (share) to $BUYER_PUT_YOUR_ADDRESS_HERE if this transaction also satisfies 4.33 btc to addressC "
This also removes the need for secrets to achieve atomicity but would probably need an expiry condition too.

The difficult part is how to retract orders. When I put an order I don't want it to stand forever, I want either to be able to retract it (which is difficulty to synchronize and probably won't be supported), or to set in advance a time limit. So you need to have a transaction like you described, but which is only accepted if completed up to a given time. And it needs to be able to be completed even without the issuer's cooperation. And the proof that it was indeed executed before expiration needs to survive block reorgs. This seems challenging even if you design a new blockchain just for that.

[jtimon]

I fear the only soulution to the "committing orders" would be through extending the bitcoin scripting language.
You could sign and broadcast partially completed transactions as "binding advertisements" like
"I send 1 shatoshi (share) to $BUYER_PUT_YOUR_ADDRESS_HERE if this transaction also satisfies 4.33 btc to addressC "
This also removes the need for secrets to achieve atomicity but would probably need an expiry condition too.

The difficult part is how to retract orders. When I put an order I don't want it to stand forever, I want either to be able to retract it (which is difficulty to synchronize and probably won't be supported), or to set in advance a time limit. So you need to have a transaction like you described, but which is only accepted if completed up to a given time. And it needs to be able to be completed even without the issuer's cooperation. And the proof that it was indeed executed before expiration needs to survive block reorgs. This seems challenging even if you design a new blockchain just for that.

That's the expiry condition I was talking about. To see if the trade has been executed both parties need to wait until they think no block reorgs can occur to be sure that the trade has been made or not. But they don't lose anything, being the trade atomic it is either executed or not as a whole.
But that's two extra features for standard transactions: "if there's also an output for X btc to AAA address within this transaction" and "if it is included in the chain before the block Exp".

I wonder if what fellowTraveller is coding for open transactions could be useful for this.

My latest project, which I will be announcing soon, is a full implementation of smart contracts, agnostic to scripting language, which will allow users to design their own financial instruments by adding scripted clauses to their contracts.  If you are curious to see the progress, look at the github code for OT, there is a "smartcontracts" branch where I have been checking in commits every night (lately.) It's not done yet.

Maybe a single standard contract protocol should be developed for the whole ecosystem of "crypto-financial tools" (I'm thinking about bitcoin, OT and Ripple right now) to be adopted for all of them. But identifying use cases and reusable messages seems hard work, because you want to make it once and don't need to extend or change it significantly later.
Sorry for going a little off-topic.

[ripper234]

That is the problem or misconception.

If you have an account with 1000 Satoshis it isn't 1000 uniquely identifable satoshis.  It is simply a unique ADDRESS which currently has a value of 1000.

...

You are confused about how Bitcoin transactions work. And while what you're describing may be the ideal, where all bitcoins are fungible, the reality is different.

I am completely wrong.  Learned something new today.  Yeah based on the actual transaction data it doesn't look like your could "pollute" the chain of custody for a share. 

I see. If a Hero Member of this forum can be confused about this, then I'm sure many others are getting it wrong as well.
I believe this is a common misconception indeed, that is repeated a lot. Most people don't open up blockexplorer and dig this deep.

I wonder if there's a way to propagate this bit of knowledge so misinformation about this stops spreading.

[finway]

It can't be succeed, because the dealy of the p2p network is too big.

[ripper234]

It can't be succeed, because the dealy of the p2p network is too big.

So Bitcoin can't succeed as well because its p2p?

Most people don't care so much about high frequency trading, and wouldn't actually mind a delay.
For those who do want to do HFT, they can use Green Addresses or simply trade inside an exchange that is built on top of the p2p backbone.

[Meni Rosenfeld]

I wonder if there's a way to propagate this bit of knowledge so misinformation about this stops spreading.

Does it matter? For most intents and purposes this is just a technical implementation issue. For normal use it doesn't really have anonymity implications either, it's known that all funds in a given address belong to the same entity, so it doesn't matter which of the outputs they choose to use to send. Only when you want to do fancy stuff like we've discussed here it matters.