Topic: On a decentralized bitcoin-based stock market... - page 2. (Read 9654 times)
Just wanted to point everyone watching this thread to this new thread by btc_artist about DBSE
There's no reason there can't be more than one stock exchange.
Which is why I think a hybrid solution may be the best bet.
Have the stock ownership and transfers handled by a decentralized blockchain and then allow multiple exchanges to support higher level tools like placing trades/orders against that blockchain.
But even if GLBSE wants nothing to do with a blockchain based solution, they could keep running.
True but I hope they would see the advantage (maybe not personal advantage) of having the actual "shares" exist outside of GLBSE. Imagine if for whatever reason GLBSE goes down forever tomorrow. The chaos and yet more negative PR that brings to Bitcoin.
There's no reason there can't be more than one stock exchange.
Which is why I think a hybrid solution may be the best bet.
Have the stock ownership and transfers handled by a decentralized blockchain and then allow multiple exchanges to support higher level tools like placing trades/orders against that blockchain.
But even if GLBSE wants nothing to do with a blockchain based solution, they could keep running.
True but I hope they would see the advantage (maybe not personal advantage) of having the actual "shares" exist outside of GLBSE. Imagine if for whatever reason GLBSE goes down forever tomorrow. The chaos and yet more negative PR that brings to Bitcoin.
There's no reason there can't be more than one stock exchange.
Which is why I think a hybrid solution may be the best bet.
Have the stock ownership and transfers handled by a decentralized blockchain and then allow multiple exchanges to support higher level tools like placing trades/orders against that blockchain.
But even if GLBSE wants nothing to do with a blockchain based solution, they could keep running.
There's no reason there can't be more than one stock exchange.
Which is why I think a hybrid solution may be the best bet.
Have the stock ownership and transfers handled by a decentralized blockchain and then allow multiple exchanges to support higher level tools like placing trades/orders against that blockchain.
There's no reason there can't be more than one stock exchange.
There isn't any reason why this project can't work along side GLBSE. In fact, I think that would help make it much more successful.
The genesis block for our chain could contain everything in GLBSE at whatever time we decide to launch. When the chain gets launched, a new GLBSE back-end would also be launched that would use our chain instead of w/e database it is using right now.
The genesis block for our chain could contain everything in GLBSE at whatever time we decide to launch. When the chain gets launched, a new GLBSE back-end would also be launched that would use our chain instead of w/e database it is using right now.
Maybe they prefer to stay the way they are. Remember that the trades will be slower if they're executed within a chain.
But they can always do both.
There isn't any reason why this project can't work along side GLBSE. In fact, I think that would help make it much more successful.
The genesis block for our chain could contain everything in GLBSE at whatever time we decide to launch. When the chain gets launched, a new GLBSE back-end would also be launched that would use our chain instead of w/e database it is using right now.
The genesis block for our chain could contain everything in GLBSE at whatever time we decide to launch. When the chain gets launched, a new GLBSE back-end would also be launched that would use our chain instead of w/e database it is using right now.
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.I agree it's not relevant for 99.9% of Bitcoin users. Oh well.
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. 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.
It can't be succeed, because the dealy of the p2p network is too big.
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.
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.
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.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.
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.
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. 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.
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.
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
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.
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.
Quote
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.
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.
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".
Unless I'm missing something, this still doesn't allow placing committing orders.
You can use the "trading across chains" scheme.(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. Jump to: