Bitcoin Forum
May 02, 2024, 09:55:15 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 [281] 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 ... 661 »
  Print  
Author Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread  (Read 1276298 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
romerun
Legendary
*
Offline Offline

Activity: 1078
Merit: 1001


Bitcoin is new, makes sense to hodl.


View Profile
March 20, 2014, 12:53:13 PM
 #5601

If BTC reveals to be not so "XCP friendly", why not changing ?  Shocked
Would the protocol easily work with litecoin-qt and litecoin's OP-return ??
Sorry for this so blasphematic remark, I have low technical skills, so excuse me if it is a very bad idea for the protocol.  Disclaimer : I am NOT a LTC holder and fan. LTC is just the natural competitor at the moment, with ATM, exchanges, high hashrates...

If I understand correctly, since Litecoin is a fork of bitcoin its a few versions behind and does not support OP_RETURN yet.



Well, say LTC want to beat bitcoin by being LTC 2.0 friendly, they allow 120 bytes on OP_RETURN, can we just put the real data on LTC chain and put the hash of it on BTC, this way we would have a reasonably secure network without requiring anyone running another alt chain from scratch, crap this might not work since we have to spend both BTC, and LTC to send a XCP tx...
1714686915
Hero Member
*
Offline Offline

Posts: 1714686915

View Profile Personal Message (Offline)

Ignore
1714686915
Reply with quote  #2

1714686915
Report to moderator
1714686915
Hero Member
*
Offline Offline

Posts: 1714686915

View Profile Personal Message (Offline)

Ignore
1714686915
Reply with quote  #2

1714686915
Report to moderator
1714686915
Hero Member
*
Offline Offline

Posts: 1714686915

View Profile Personal Message (Offline)

Ignore
1714686915
Reply with quote  #2

1714686915
Report to moderator
According to NIST and ECRYPT II, the cryptographic algorithms used in Bitcoin are expected to be strong until at least 2030. (After that, it will not be too difficult to transition to different algorithms.)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714686915
Hero Member
*
Offline Offline

Posts: 1714686915

View Profile Personal Message (Offline)

Ignore
1714686915
Reply with quote  #2

1714686915
Report to moderator
1714686915
Hero Member
*
Offline Offline

Posts: 1714686915

View Profile Personal Message (Offline)

Ignore
1714686915
Reply with quote  #2

1714686915
Report to moderator
halfcab123
Full Member
***
Offline Offline

Activity: 224
Merit: 100

CabTrader v2 | crypto-folio.com


View Profile
March 20, 2014, 01:15:05 PM
 #5602

If BTC reveals to be not so "XCP friendly", why not changing ?  Shocked
Would the protocol easily work with litecoin-qt and litecoin's OP-return ??
Sorry for this so blasphematic remark, I have low technical skills, so excuse me if it is a very bad idea for the protocol.  Disclaimer : I am NOT a LTC holder and fan. LTC is just the natural competitor at the moment, with ATM, exchanges, high hashrates...

If I understand correctly, since Litecoin is a fork of bitcoin its a few versions behind and does not support OP_RETURN yet.



Well, say LTC want to beat bitcoin by being LTC 2.0 friendly, they allow 120 bytes on OP_RETURN, can we just put the real data on LTC chain and put the hash of it on BTC, this way we would have a reasonably secure network without requiring anyone running another alt chain from scratch, crap this might not work since we have to spend both BTC, and LTC to send a XCP tx...

Sounds to me like whats happening here is, after seeing the incredibility of Counterwallet, the elephant in the room is this daunting 10+ minute time between trades. Its something that we all knew about, but it didn't become painfully obvious until we experienced that wait time in conjunction with a beautiful UI. It's almost like having 1,000 Horsepower Corvette, with 8 inch plastic wagon wheels made my Tyco.

I think the thing that is going to have to happen to make this situation more attractive is we're going to have to implement some kind of progress tracker for confirmations... either that or move to another block chain that has a super high hash rate like Bitcoin, but a much faster block time.


EDIT: Could we have 3rd party projects to apply Counterparty to all other coins protocols that are applicable and then Counterwallet can allow asset issuers to pick which block chain they want to issue on with Counterparty ? That'd be neat. I'm thinking in imagination land right now, but that sounds cool. So say you wanted to issue on Bitcoin and Litecoin, you'd have to send a BTC tx and LTC tx to store the tx in both block chains, or possibly other ones if you've issued on those others as well.. I don't know I think my idea is falling apart already haha, but I digress.

Maybe this is where Ethereum comes in. eh ? How incredibly sexy would it be to be able to do what Counterwallet does with 5 - 10 sec tx times?

DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
cryptrol
Hero Member
*****
Offline Offline

Activity: 637
Merit: 500


View Profile
March 20, 2014, 01:24:20 PM
 #5603

can we just put the real data on LTC chain and put the hash of it on BTC, this way we would have a reasonably secure network without requiring anyone running another alt chain from scratch, crap this might not work since we have to spend both BTC, and LTC to send a XCP tx...
I don't see the point in having to secure two blockchains, if the bitcoin blockchain is already storing a hash of the block, well, that hash is the integrity check of the transactions mapped to that block, isn't it ?  No need to have a PoW (or even a blockchain) to store the real transactions, it could just be a simple DB.

The multisig hack is surely not elegant at all and the fees (and bloat) are higher but it can't be broken. Unlike the OP_RETURN feature.
The possibility of the BTC core devs dropping support for OP_RETURN was always there, and in the end they only capped it's max. size, oh well, it sucks but the spam concerns are legit IMO.

BTW, counterwallet is NICE!
romerun
Legendary
*
Offline Offline

Activity: 1078
Merit: 1001


Bitcoin is new, makes sense to hodl.


View Profile
March 20, 2014, 01:45:56 PM
 #5604

I don't see the point in having to secure two blockchains, if the bitcoin blockchain is already storing a hash of the block, well, that hash is the integrity check of the transactions mapped to that block, isn't it ?  No need to have a PoW (or even a blockchain) to store the real transactions, it could just be a simple DB.

ah you are right, so I guess it's not so difficult to implement then, just a cloud of db replicating data. This also allows us to create more sophisticate protocols as the space problem is lifted.
jimhsu
Sr. Member
****
Offline Offline

Activity: 364
Merit: 264


View Profile
March 20, 2014, 03:31:44 PM
 #5605

If BTC reveals to be not so "XCP friendly", why not changing ?  Shocked
Would the protocol easily work with litecoin-qt and litecoin's OP-return ??
Sorry for this so blasphematic remark, I have low technical skills, so excuse me if it is a very bad idea for the protocol.  Disclaimer : I am NOT a LTC holder and fan. LTC is just the natural competitor at the moment, with ATM, exchanges, high hashrates...

If I understand correctly, since Litecoin is a fork of bitcoin its a few versions behind and does not support OP_RETURN yet.



Well, say LTC want to beat bitcoin by being LTC 2.0 friendly, they allow 120 bytes on OP_RETURN, can we just put the real data on LTC chain and put the hash of it on BTC, this way we would have a reasonably secure network without requiring anyone running another alt chain from scratch, crap this might not work since we have to spend both BTC, and LTC to send a XCP tx...

Sounds to me like whats happening here is, after seeing the incredibility of Counterwallet, the elephant in the room is this daunting 10+ minute time between trades. Its something that we all knew about, but it didn't become painfully obvious until we experienced that wait time in conjunction with a beautiful UI. It's almost like having 1,000 Horsepower Corvette, with 8 inch plastic wagon wheels made my Tyco.

I think the thing that is going to have to happen to make this situation more attractive is we're going to have to implement some kind of progress tracker for confirmations... either that or move to another block chain that has a super high hash rate like Bitcoin, but a much faster block time.


EDIT: Could we have 3rd party projects to apply Counterparty to all other coins protocols that are applicable and then Counterwallet can allow asset issuers to pick which block chain they want to issue on with Counterparty ? That'd be neat. I'm thinking in imagination land right now, but that sounds cool. So say you wanted to issue on Bitcoin and Litecoin, you'd have to send a BTC tx and LTC tx to store the tx in both block chains, or possibly other ones if you've issued on those others as well.. I don't know I think my idea is falling apart already haha, but I digress.

Maybe this is where Ethereum comes in. eh ? How incredibly sexy would it be to be able to do what Counterwallet does with 5 - 10 sec tx times?

Note testnet confirmation times are usually more painful than 10 minutes, because of the paucity of miners. While the main chain has the habit of being just under 10 minutes, due to the "growth of bitcoin" and such.

Dans les champs de l'observation le hasard ne favorise que les esprits préparé
Elokane
Hero Member
*****
Offline Offline

Activity: 817
Merit: 1000


Truth is a consensus among neurons www.synereo.com


View Profile WWW
March 20, 2014, 03:54:38 PM
Last edit: March 31, 2020, 05:18:54 AM by Elokane
 #5606

Long time XCP supporter coming in to say that the wallet is amazing. Kudos, XNOVA.

Synereo: liberating the Internet from abusive business models.

Beware of he who would deny you access to information, for in his heart, he dreams himself your master.
<br>
SyRenity
Hero Member
*****
Offline Offline

Activity: 756
Merit: 502


View Profile
March 20, 2014, 04:39:08 PM
 #5607

Long time XCP supporter coming in to say that the wallet is amazing. Kudos, XNOVA. When the wallet goes live I'll send some XCP your way. Smiley

Same here - it's amazing how fast it progressed to the current stage.
I checked the wallet and it feels very intuitive - clearly you put a lot of UX thinking into it.

Looking for the moment it goes live!
GLaDOS
Newbie
*
Offline Offline

Activity: 24
Merit: 0


View Profile
March 20, 2014, 05:16:00 PM
 #5608

I think you misunderstood what jgarzik is saying. The idea is that we store the data in a second blockchain, and put hashes of that timestamped data in Bitcoin, which hashes would also be less than 40 bytes. The reason we did not do something like that is not a matter of "intellectual laziness", but rather of implementation complexity. Counterparty is not a project in computer science; it is designed to be a simple as possible, for the benefits in development speed. Even if we have to store our data in multi-sig outputs rather than the too-small OP_RETURN outputs. Worse is definitely better in this space.

In any case, we appreciate the suggestion, jgarzik, and if you think we're still missing anything here, specifically w.r.t. the space of technical possibilities, please let us know. Thanks.

Also, with the second blockchain, you have a second blockchain to secure, and due to this, Counterparty could not fully leverage the unparalleled PoW security that Bitcoin offers end-to-end. Moreover, unless I am overlooking something here, we would still need to parse out the data from the blocks in that second blockchain (assuming it's a Bitcoin or Bitcoin derivative implementation, at least) to get our stored data. So:
* it would not enable SPV-type Counterparty clients for what Counterparty offers over Colored Coin functionality (i.e. DEx, Betting, asset callbacks, dividends, CFDs, etc)
* it would lessen security of Counterparty transactions
* it would greatly increase the complexity of the implementation (i.e. increasing the chance of bugs and vulnerabilities)

The only dubious benefit would be the *slight* lessening our storage requirements on the block chain (i.e. maybe 20-40 bytes less per transaction?). I just don't see how this would make any sense here.

One more point: Counterparty can bring immense benefits to Bitcoin, and this will especially become more apparent if/as Ethereum (and other similar non-Bitcoin-meta "2.0" type coins) enter the picture. My personal feeling here at least is that Bitcoin may very well need offerings in the ecosystem with this kind of functionality to effectively compete with Ethereum and (future) crowd's feature list and draws -- or risk becoming obsoleted, at least among investors and financial market operators, which offer the ability to bring billions and even trillions into the Bitcoin ecosystem as it gains more recognition, trust, and mindshare with them. This process is, of course, only beginning, but we feel that the clear benefits that the blockchain can offer to finance (for not only Bitcoin payment operations, but for the more advanced finance operations that the technology can enable) will set off the next great phase of Bitcoin's growth, IF allowed to unfold organically.


+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.
Matt Y
Hero Member
*****
Offline Offline

Activity: 647
Merit: 510


Counterpartying


View Profile WWW
March 20, 2014, 05:24:41 PM
 #5609

I've just bought my first XCP today. and now, wtf can i do with them?

Bellebite is the best person to answer your question

If you're like me, a less technical user, the answer is that you can sell them for BTC or other asset:

XBTC: https://forums.counterparty.co/index.php/topic,160.
Gold: https://forums.counterparty.co/index.php/topic,179.msg1219.

With a little bit of technical prowess you can:

Create your own altcoin that functions within the rules you specify.

Create a callable, debt based asset.

IPO a company. The easiest example is if you owned a mining pool, you could distribute shares to all the miners, then automatically pay dividends in bitcoin, instead of doing it by hand with an excel spreadsheet.

As the system fills out over the coming month or so:

Make simple Win/Less bets (sports), or more complex financial bets, which will allow you to leverage or hedge your position in various currencies.

Alias
Full Member
***
Offline Offline

Activity: 127
Merit: 100

Money be green


View Profile
March 20, 2014, 05:45:07 PM
 #5610

I think you misunderstood what jgarzik is saying. The idea is that we store the data in a second blockchain, and put hashes of that timestamped data in Bitcoin, which hashes would also be less than 40 bytes. The reason we did not do something like that is not a matter of "intellectual laziness", but rather of implementation complexity. Counterparty is not a project in computer science; it is designed to be a simple as possible, for the benefits in development speed. Even if we have to store our data in multi-sig outputs rather than the too-small OP_RETURN outputs. Worse is definitely better in this space.

In any case, we appreciate the suggestion, jgarzik, and if you think we're still missing anything here, specifically w.r.t. the space of technical possibilities, please let us know. Thanks.

Also, with the second blockchain, you have a second blockchain to secure, and due to this, Counterparty could not fully leverage the unparalleled PoW security that Bitcoin offers end-to-end. Moreover, unless I am overlooking something here, we would still need to parse out the data from the blocks in that second blockchain (assuming it's a Bitcoin or Bitcoin derivative implementation, at least) to get our stored data. So:
* it would not enable SPV-type Counterparty clients for what Counterparty offers over Colored Coin functionality (i.e. DEx, Betting, asset callbacks, dividends, CFDs, etc)
* it would lessen security of Counterparty transactions
* it would greatly increase the complexity of the implementation (i.e. increasing the chance of bugs and vulnerabilities)

The only dubious benefit would be the *slight* lessening our storage requirements on the block chain (i.e. maybe 20-40 bytes less per transaction?). I just don't see how this would make any sense here.

One more point: Counterparty can bring immense benefits to Bitcoin, and this will especially become more apparent if/as Ethereum (and other similar non-Bitcoin-meta "2.0" type coins) enter the picture. My personal feeling here at least is that Bitcoin may very well need offerings in the ecosystem with this kind of functionality to effectively compete with Ethereum and (future) crowd's feature list and draws -- or risk becoming obsoleted, at least among investors and financial market operators, which offer the ability to bring billions and even trillions into the Bitcoin ecosystem as it gains more recognition, trust, and mindshare with them. This process is, of course, only beginning, but we feel that the clear benefits that the blockchain can offer to finance (for not only Bitcoin payment operations, but for the more advanced finance operations that the technology can enable) will set off the next great phase of Bitcoin's growth, IF allowed to unfold organically.


+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

While I mostly agree with your points, I feel that you have made one slight oversight in your consideration. The additional "books" that you refer to needn't be full-blown cryptocurrencies. They could simply be Distributed Autonomous Organisations utilising lite-blockchains that get overwritten or heavily pruned when their balance of outputs are written to the Bitcoin blockchain every 10 minutes.

Also, in this way, Counterparty could deploy a DAO add-on for high(er)-frequency (of the order of single millisecond latency or better) trading. This could be included with Leonardo for example.

In times of change, it is the learners who will inherit the earth, while the learned will find themselves beautifully equipped for a world that no longer exists.
BitcoinTangibleTrust
Member
**
Offline Offline

Activity: 111
Merit: 10

Digitizing Valuable Hard Assets with Crypto


View Profile WWW
March 20, 2014, 05:46:08 PM
 #5611

If you're like me, a less technical user, the answer is that you can sell them for BTC or other asset:

XBTC: https://forums.counterparty.co/index.php/topic,160.
Gold: https://forums.counterparty.co/index.php/topic,179.msg1219.

With a little bit of technical prowess you can:

Create your own altcoin that functions within the rules you specify.

Create a callable, debt based asset.

IPO a company. The easiest example is if you owned a mining pool, you could distribute shares to all the miners, then automatically pay dividends in bitcoin, instead of doing it by hand with an excel spreadsheet.

As the system fills out over the coming month or so:

Make simple Win/Less bets (sports), or more complex financial bets, which will allow you to leverage or hedge your position in various currencies.

Please keep in mind that if you are in the USA or selling any of your cool Counterparty-based products to customers in the USA, you may be investigated by the Securities and Exchange Commission (SEC) for the illegal issuance of company shares for sale to US citizens or residents and/or the illegal hosting of betting platforms for US customers.

I don't like these rules anymore than you do, but please take note of the rules and regulations in your country. You can run a successful betting platform on Counterparty, you just may not be able to have US customers.

See Erik Vorhees problems with SEC: http://trilema.com/2014/interacting-with-fiat-institution-a-guide/

Digital Tangible
Digitizing Valuable Hard Assets with Crypto http://www.digitaltangibletrust.com
BitcoinTangibleTrust
Member
**
Offline Offline

Activity: 111
Merit: 10

Digitizing Valuable Hard Assets with Crypto


View Profile WWW
March 20, 2014, 06:16:15 PM
 #5612

Counterwallet live on testnet

Link: https://testnet.counterwallet.co/

Report bugs here: https://forums.counterparty.co/index.php?topic=188.0
Get testnet XCP here: https://forums.counterparty.co/index.php/topic,184
Get testnet BTC here: http://tpfaucet.appspot.com/
Blog post outlining functionality: https://www.counterparty.co/counterwallet-live-testnet/

xnova has done a wonderful job developing Counterwallet and he deserves a big thanks from all of us. Let's all start testing and get Counterwallet on mainnet as soon as possible!

Thanks xnova. A truly remarkable job you've done on this.

The functionality here is impressive. Congratulations Xnova and Dev team.

I encourage everyone to test. There are so many interesting features that you'll enjoy!

Digital Tangible
Digitizing Valuable Hard Assets with Crypto http://www.digitaltangibletrust.com
kdrop22
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
March 20, 2014, 06:37:41 PM
Last edit: March 20, 2014, 08:44:57 PM by kdrop22
 #5613


One more point: Counterparty can bring immense benefits to Bitcoin, and this will especially become more apparent if/as Ethereum (and other similar non-Bitcoin-meta "2.0" type coins) enter the picture. My personal feeling here at least is that Bitcoin may very well need offerings in the ecosystem with this kind of functionality to effectively compete with Ethereum and (future) crowd's feature list and draws -- or risk becoming obsoleted, at least among investors and financial market operators, which offer the ability to bring billions and even trillions into the Bitcoin ecosystem as it gains more recognition, trust, and mindshare with them. This process is, of course, only beginning, but we feel that the clear benefits that the blockchain can offer to finance (for not only Bitcoin payment operations, but for the more advanced finance operations that the technology can enable) will set off the next great phase of Bitcoin's growth, IF allowed to unfold organically.


+100
To compete with second and third gen coins, Bitcoin will need meta platforms built on top of it.
Spekulatius
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000



View Profile
March 20, 2014, 10:41:01 PM
 #5614


I think the thing that is going to have to happen to make this situation more attractive is we're going to have to implement some kind of progress tracker for confirmations... either that or move to another block chain that has a super high hash rate like Bitcoin, but a much faster block time.

[...]

How incredibly sexy would it be to be able to do what Counterwallet does with 5 - 10 sec tx times?

Alreday exists and is being tested on large scale Wink
http://www.reddit.com/r/Bitcoin/comments/1xqh51/new_mycelium_wallet_feature_confirmations_within/
Spekulatius
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000



View Profile
March 20, 2014, 10:56:17 PM
 #5615


Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty
[...]
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

..except for: Counter party risk  Tongue  Seriously though, the actual "counter party risk" of Bitcoin or any other chain for that matter dropping vital features like OP_RETURN puts Counterparty's success and longevity into jeopardy. I would go for at least one fall back in case the primary chain becomes defunct or takes a negative approach towards Counterparty's needs. Why not create a second chain faithful to Counterparty's requirements? Or a third and fourth one for different purposes? If the uses the secondary chains are meant for become successful, the chains will be supported by hashpower and decentralization. If not, they become obsolete and should be allowed to die or shrink until utility returns to them.
led_lcd
Sr. Member
****
Offline Offline

Activity: 262
Merit: 250


View Profile
March 20, 2014, 11:12:03 PM
 #5616


I think the thing that is going to have to happen to make this situation more attractive is we're going to have to implement some kind of progress tracker for confirmations... either that or move to another block chain that has a super high hash rate like Bitcoin, but a much faster block time.

[...]

How incredibly sexy would it be to be able to do what Counterwallet does with 5 - 10 sec tx times?

Alreday exists and is being tested on large scale Wink
http://www.reddit.com/r/Bitcoin/comments/1xqh51/new_mycelium_wallet_feature_confirmations_within/

I know you are talking about the utility of transaction propagation for confidence in zero confirmation transactions.

Just to be clear though, that's a little bit different in application. Unless you are saying that large enough transaction propagation would be sufficient for the protocol to process the transaction.

Even so, each node on the network will see these broadcasts at different times. For Counterparty deterministic behaviour is required when matching orders which cannot be assured of across the network if relying on the transaction broadcasts. That is why the 'lock step' at a block interval works well. Even if nodes see these blocks at differing times the transactions contained within the block can be processed deterministically.
MoneypakTrader.com
Sr. Member
****
Offline Offline

Activity: 472
Merit: 250


Never spend your money before you have it.


View Profile
March 20, 2014, 11:53:50 PM
 #5617

ANNOUNCEMENTS:
A monthly dividend of 18000 XCP was issued to stockholders recently. Stockholder input continues to be welcome regarding the method of future dividends or other relevant issues.
http://www.blockscan.com/assetInfo.aspx?q=MPTSTOCK#dividends

MPUSD issued the first weekly kickback to early adopters of MPUSD. Due to volatility of XCP/BTC/USD, please contact us directly via torchat or FBchat to invest in this new USD e-currency or just negotiate via a public DEX listing.
http://www.blockscan.com/assetInfo.aspx?q=MPUSD#dividends

MPBTC is firmly pegged against BTC with buy walls that guarantee it. Once the "protocol hardcoded 10 block time-limit for BTCpay" is lifted, no coordination will be needed to redeem MPBTC for BTC.
http://www.blockscan.com/order.aspx?f=2

More info at bottom in original information releases.

The XCP Dev's have done a great thing here in implementing the first bitcoin to/from Altcoin distributed trading scheme (Ripple was close, but had a central investor/distribution source/base).
KUDO's! Thanks for the great work!

Back when dev [retroactively] levied a 5 XCP fee against issuing assets (which fortunately had a side-effect of blocking our initial issuance of "AAAMPTSTOCK"), the "re-issuance for non-zero quantity" feature of your software was broken. Please fix this.

If you're an XCP true-believer who gets butthurt over criticism, stop reading NOW!

Is it just me, or has the launch of this coin - which seems to have so much innovation - been an unmitigated disaster, exchange-market-wise?

You're obviously correct looking at pricing and functionality of the XCP system over stated claims and goals due to a few CRITICAL problems:

1) Anyone who's tried to trade BTC in/out of the DEX natively at competitive rates has come to understand all too well, the BTC integration SUCKS:
The way the dev dropped the ball by implementing a few misguided solutions (First with the 10 block BTCpay time limit and second by making an offer to buy 100BTC worth of asset have a default of 1BTC cost(!?!) in burn fees (*JUST TO LIST THE OFFER!?!*)) which predictably had the foreseen effect to prevent any legitimate long-standing BTC offer from being placed (due to castrating the choice/power from the BTC giver order as predicted: https://forums.counterparty.co/index.php/topic,71.msg355.html#msg355 ).

2) Was there any explanation why the dev chose to leave residue of assets to hang around the order books after the relevant orders should have 100% matched and traded? http://www.blockscan.com/order_book.aspx
I want to sell 100 asset, existing order matched, only 99.9999995 asset transferred, and put remainder 0.0000005 back on order book. . . WTF!?!

3) Initial distribution was wider and thus MANY more sellers are available over other altcoins which have more centralized break-in periods / premining. More Sellers = lower price. The competitor coins have relatively few initial adopters/investors and don't suffer so much from this despite having massive holdings in total. i.e. competitor altcoins may have 5-10 x the value but only 10% or less total sellers so the price has little resistance against upward movement compared to XCP.
NOTE: This is a good thing for wider distribution but a bad thing for getting rich quick.

4) XCP is just not that useful and initial investors have taken notice: It's a difficult to use and it lacks much practical use for average users due in part to virtually no explanations for novice bitcoiners about how to use and the DEX just doesn't work very well (due to some of the explained problems here and elsewhere). https://forums.counterparty.co/index.php/topic,71
Hopefully the GUI, webwallet/trading and such will alleviate this to some extent.

5) Radical changes to protocol with little public discussion and a private deliberation process by dev.
When a 5 XCP fee was introduced [retroactively] for issuing assets, that was a good reason for buying XCP since asset creation would reward XCP holders and cause XCP demand inducing people to buy and hold, but since the dev lowered that cost recently (to help BTT and others who favor "asset spam" over stakeholder reward) it removed 90% of that 5xcp "per-asset issuance stakeholder reward" that we were receiving. Current stakeholders and future investors can foresee this and similar actions having a negative long-term pricing effect over the status quo and the market shows how stakeholders are voting with their shares on this type decision making process.
There was a rumor of the XCP-dev considering stakeholder feedback in the future, however we are obligated to trust past experiences rather than such vague rumors of a radical shift in their decision-making process.

6) When people see the changelog they're like "WTF? you call this a changelog?". Then they see the amount of "rapid development" taking place and then pushed to their computers with little to no discussion of how it will positively or negatively affect them/stakeholders and they realize this is not something "safe" to invest in. Of course they can refuse the updates and let the software stop working or force-run it using obsolete settings and risk losing coins.

7) Asset reissuances were broken and then never fixed when the 5xcp asset fee was retroactively put into place. Better know EXACTLY how many shares you want issued the first time, all future re-issuance attempts might appear to succeed, but the program won't register them. Fixing this is going to

On a positive note, the dev might consider asking for stakeholder input before implementing radical protocol/program changes. I encourage all you bitcoiners to dump some resources into this alt-coin in hopes that one day you'll have a voice in the direction it takes. Or you could just be vocal here and in the other forum to have the dev push more misguided changes such as those outlined above and elsewhere.

Obviously this is only a partial explanation, please link/quote other analysis for more diverse views that explain the phenomenon you asked about. Historically, the people posting here are unlikely to share such problems either from lack of experience with the software or other reasons.

But perhaps it's not the problems with the existing features, but the need to enhance/implement more features (such as more asset naming options) that is precluding rapid acceptance by other bitcoiners? Too bad we don't have alpha-testers with better reasoning skills influencing development. . .

XCP is not another altcoin. The key is to improve the Dex. Without a working reliable DEX, put it on more exchanges is just a pump and dump. It may make the early investors rich quickly, but never a real success. For those who have tens of thousands of XCP, I don't think you can liquidate all you holding by just pump and dump. A real DEX is a must.
Agreed, specifically for the problems outlined above. Until then, we will continue to vote with our holdings in the marketplace.
Fixes/quickfixes were advised, but other solutions are available if the problems above are acknowledged:
https://forums.counterparty.co/index.php/topic,71

We've launched MPUSD, using a 200% double bitcoin reserve, this USD denominated asset will allow USD trading on the Counterparty DEX.
Buy it and make some free XCP. . .

In order to promote our new Counterparty Assets which are 100% USD backed and redeemable (for full face value in BTC or MP) currency, we'll be paying a total of at least 2000 XCP in dividends to holders of MPUSD over the next month on about a weekly basis. We may or may not continue this promotion after that into future months depending on interest.
At the current distribution levels of 10,000 MPUSD that would be 0.2 XCP per MPUSD if held for the next month (BIG PROFIT!!).
If there is sufficient demand, we will issue and distribute more MPUSD so long as our publicly verifiable Bitcoin reserves are at least 200% of the MPUSD value distributed (to ensure adequate backing for the currency).

We've also designated another 500 XCP to be paid to the first professional/central website exchange that continuously allows MPUSD/BTC trading available to users through TOR for one week without interruptions (linking to the official post description about what MPUSD is). Theoretically, an exchange operator could buy out virtually all of the MPUSD and facilitate trading it on their exchange while doube-dipping into both of these promotions for close to the full XCP reward (provided others don't buy into MPUSD or withdraw their MPUSD from the exchange). This promotion expires April 15th, making April 8th the last day for exchanges to ask for review on the reward (send email or chat message to notify us of your implementation to allow our monitoring of your uptime).

We openly trade cryptocurrencies through Torchat, FacebookChat, and the Counterparty Distributed EXchange (DEX). More info about these new fully backed currencies our feedback thread - https://bitcointalk.org/index.php?topic=133439.msg5664449#msg5664449

zbx
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
March 21, 2014, 12:28:09 AM
 #5618

Back when dev [retroactively] levied a 5 XCP fee against issuing assets (which fortunately had a side-effect of blocking our initial issuance of "AAAMPTSTOCK"), the "re-issuance for non-zero quantity" feature of your software was broken. Please fix this.

If you're an XCP true-believer who gets butthurt over criticism, stop reading NOW!

Is it just me, or has the launch of this coin - which seems to have so much innovation - been an unmitigated disaster, exchange-market-wise?

You're obviously correct looking at pricing and functionality of the XCP system over stated claims and goals due to a few CRITICAL problems:

1) Anyone who's tried to trade BTC in/out of the DEX natively at competitive rates has come to understand all too well, the BTC integration SUCKS:
The way the dev dropped the ball by implementing a few misguided solutions (First with the 10 block BTCpay time limit and second by making an offer to buy 100BTC worth of asset have a default of 1BTC cost(!?!) in burn fees (*JUST TO LIST THE OFFER!?!*)) which predictably had the foreseen effect to prevent any legitimate long-standing BTC offer from being placed (due to castrating the choice/power from the BTC giver order as predicted: https://forums.counterparty.co/index.php/topic,71.msg355.html#msg355 ).

2) Was there any explanation why the dev chose to leave residue of assets to hang around the order books after the relevant orders should have 100% matched and traded? http://www.blockscan.com/order_book.aspx
I want to sell 100 asset, existing order matched, only 99.9999995 asset transferred, and put remainder 0.0000005 back on order book. . . WTF!?!

3) Initial distribution was wider and thus MANY more sellers are available over other altcoins which have more centralized break-in periods / premining. More Sellers = lower price. The competitor coins have relatively few initial adopters/investors and don't suffer so much from this despite having massive holdings in total. i.e. competitor altcoins may have 5-10 x the value but only 10% or less total sellers so the price has little resistance against upward movement compared to XCP.
NOTE: This is a good thing for wider distribution but a bad thing for getting rich quick.

4) XCP is just not that useful and initial investors have taken notice: It's a difficult to use and it lacks much practical use for average users due in part to virtually no explanations for novice bitcoiners about how to use and the DEX just doesn't work very well (due to some of the explained problems here and elsewhere). https://forums.counterparty.co/index.php/topic,71
Hopefully the GUI, webwallet/trading and such will alleviate this to some extent.

5) Radical changes to protocol with little public discussion and a private deliberation process by dev.
When a 5 XCP fee was introduced [retroactively] for issuing assets, that was a good reason for buying XCP since asset creation would reward XCP holders and cause XCP demand inducing people to buy and hold, but since the dev lowered that cost recently (to help BTT and others who favor "asset spam" over stakeholder reward) it removed 90% of that 5xcp "per-asset issuance stakeholder reward" that we were receiving. Current stakeholders and future investors can foresee this and similar actions having a negative long-term pricing effect over the status quo and the market shows how stakeholders are voting with their shares on this type decision making process.
There was a rumor of the XCP-dev considering stakeholder feedback in the future, however we are obligated to trust past experiences rather than such vague rumors of a radical shift in their decision-making process.

6) When people see the changelog they're like "WTF? you call this a changelog?". Then they see the amount of "rapid development" taking place and then pushed to their computers with little to no discussion of how it will positively or negatively affect them/stakeholders and they realize this is not something "safe" to invest in. Of course they can refuse the updates and let the software stop working or force-run it using obsolete settings and risk losing coins.

7) Asset reissuances were broken and then never fixed when the 5xcp asset fee was retroactively put into place. Better know EXACTLY how many shares you want issued the first time, all future re-issuance attempts might appear to succeed, but the program won't register them. Fixing this is going to

This is all just FUD. All of your "criticisms" are nothing but evidence of your misunderstanding. For those inclined to believe anything this guy writes:

The 5 XCP fee was not retroactive. Look at the code. Lines 80-87 of issuances.py. You were running an old version of Counterpartyd for too long and got confused.

1) The 1% is just the default. Of course, it doesn't scale to very large/small amounts.

2) The trade residue is an unavoidable consequence of the finite divisibility of Bitcoin. Yes, it's ugly, but that's what slick GUI's, like Counterwallet, are for.

3) This isn't a pump and dump. That's better because then there will be no crash later!

4) The distributed exchange works great. Yes, trading with BTC with awkward with Counterpartyd, but it's really slick with Counterwallet... by design.

5) This is just nonsense.

6) You don't get to complain about missing features and the rapid development of the code. The devs are moving fast!

7) See above.
mcjavar
Hero Member
*****
Offline Offline

Activity: 784
Merit: 500


View Profile
March 21, 2014, 12:35:39 AM
 #5619

I am running BoottleXCP and would like to access the XCP I got for the BTC I burnt with blockchain. Can I? If yes, how?
halfcab123
Full Member
***
Offline Offline

Activity: 224
Merit: 100

CabTrader v2 | crypto-folio.com


View Profile
March 21, 2014, 12:36:02 AM
 #5620

I think the tone with which you criticize appears to be am attack.

DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
Pages: « 1 ... 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 [281] 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 ... 661 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!