Author

Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 380. (Read 1276933 times)

legendary
Activity: 1176
Merit: 1134
Welcome back. What's op return
Its the 40 bytes that can be used to store info that was supposed to be 80 bytes.

I've been doing a lot of programming and working on stuff that builds on NXT, which might seem competitive to some people here, but I dont see it that way. I just read about the eternity of a 10 minute wait. I can imagine how long that would feel during some of the big market moves. NXT runs on a 1 minute clock. I am working on various gateways and mixers and other enhancements to the core.

I have not figured out how to do it yet, but one of my goals is to bridge the NXT Asset Exchange using 1 minute clock to the XCP Dex using 10 minute clock. I can only see benefits to both XCP and NXT as increasing liquidity and trading options can only help. Things are still evolving on the NXT side, but when it stabilizes and I finish with the current set of projects I will have a better perspective on how to make this bridge.

Of course, maybe the smart guys here will have ideas to help this.

James
legendary
Activity: 1176
Merit: 1134
Can somebody (devs?) send me a file with all the historic OP_RETURN 80 bytes of data, or rather what these 80 bytes would have been had that method been used?

I want to take a crack at making a custom lossless codec for it, based on what I have seen so far I think I have a decent shot to get the vast majority of cases to fit into 40 bytes. As long as there is the ability to spill over into the multisig method, I believe we can get the best of both worlds, eg. save on extra fees by using OP_RETURN when possible and if not just end up where we are now. I cant see the harm in this. Once the 40 bytes is released into the wild, I doubt the bitcoin camp will be able to easily reduce it as once people start using it there will be large outcries from more than just the XCP community.

I will write this 100% from scratch without any external libraries. All in portable C. I just need the dataset. Binary file 80 bytes * number of examples would be easiest. Today I came up with a pretty advanced method of compression using context sensitive SVM's, so even if the simple approaches dont work I have a few aces up my sleeve.

If there is a description of what is in the 80 bytes, that will help me design the codec.

James

P.S. I think the rather large price drop recently is a direct fallout from OP_RETURN appearing to be nonviable, the implication being that the temporarily high transaction fees becoming permanent. Lets fix this! Give me a chance

James I like some of your ideas and vision and I write the following with respect: but Unless you already left some of your multiple NXT projects that according to you take all your time and have caused you to go through emotional rampages/rolercoasters/quitting in the middle/coming back on the NXT threads-- than I dont see why/how you should take on more projects here. I would beware- we have a good factual-not emotional and very professional thing here that should be kept this way.
I am talking about taking on a single well defined project here that I have a lot of experience with and I enjoy doing and isnt mission critical. For example, I would fiddle with this instead of playing some chess.

I own a much larger percentage of XCP than I do of NXT, but until now there wasnt anything I could do technically that wasnt already being done.

I thought that is what XCP community was about. All of us doing what we can to help XCP. Does the fact that you dont approve of my "day job" at NXT change this?

James

sr. member
Activity: 262
Merit: 250

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.


I've documented a case on the official forums where I think 2 orders should have matched off perfectly but didn't. It left residuals of the originals.

https://forums.counterparty.co/index.php/topic,171.0.html

I'd like to know if this has been addressed.
legendary
Activity: 1022
Merit: 1000

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

Thanks a bunch for taking the time and effort to regularly point out all the things that pose a problem/need rethinking with the Counterparty project! I enjoy reading your criticism where helpful because it shows the other side people dont like to talk/think about in this forum. Its important to see the problems and discuss them in order to find a mindful solution. I agree with a lot of what you say and can only encourage regulars in this thread to think more critical about this project because they wont go away by themselves (and no the devs dont always have the best answers up their sleeves either!)

P.S.: Thx to the devs and contributors, you are doing a great job but of course things can always be improved, like encouraging public discussion/education more amongst stakeholders. Maybe some educated member of this community could fulfil this duty (as Stakeholder Relations Officer), interacting with you guys and the community at large to intermediate between both sides of the table. Because the need is there to and you are all busy programming and we have a host of ideas and questions to ask all the time yoiu cannot take care of all day, so communication is suboptimal and valuable information gets lost in tramsmission (trust me, Im studying this kind of stuff;).

Cheers
legendary
Activity: 1176
Merit: 1134
Can somebody (devs?) send me a file with all the historic OP_RETURN 80 bytes of data, or rather what these 80 bytes would have been had that method been used?

I want to take a crack at making a custom lossless codec for it, based on what I have seen so far I think I have a decent shot to get the vast majority of cases to fit into 40 bytes. As long as there is the ability to spill over into the multisig method, I believe we can get the best of both worlds, eg. save on extra fees by using OP_RETURN when possible and if not just end up where we are now. I cant see the harm in this. Once the 40 bytes is released into the wild, I doubt the bitcoin camp will be able to easily reduce it as once people start using it there will be large outcries from more than just the XCP community.

I will write this 100% from scratch without any external libraries. All in portable C. I just need the dataset. Binary file 80 bytes * number of examples would be easiest. Today I came up with a pretty advanced method of compression using context sensitive SVM's, so even if the simple approaches dont work I have a few aces up my sleeve.

If there is a description of what is in the 80 bytes, that will help me design the codec.

James

P.S. I think the rather large price drop recently is a direct fallout from OP_RETURN appearing to be nonviable, the implication being that the temporarily high transaction fees becoming permanent. Lets fix this! Give me a chance

There are lots of things that can be done to reduce the default fees for Counterparty transactions, though these are not widely known. If nothing else, the fee amounts (and multi-sig output amounts, which are not fees) are currently hard-coded constants (and obsolete as of Bitcoin Core 0.9, which should be much cheaper), instead of calculated on the fly to accord with the default relay policies.

Even now, counterpartyd has no problem mixing and matching OP_RETURN and multi-sig outputs. If the transaction-construction code were refactored to create one OP_RETURN, and only then multi-sigs as necessary, fees would be lower immediately, with no changes to the protocol. Moreover, each multi-sig output, as it's currently encoded, is only 50% to 33% optimally data-efficient (the latter number is if we're OK creating unspendable outputs). Once these easy changes are made, we'll know how much we'll need to compress the data to reach certain fee goals.
Assuming that we might need a "magical" level of compression, the more time I have with the dataset the better. If it turns out it is not necessary, no biggie. I have a fair amount of stress in my "day job" I find data compression puzzles relaxing.

I guess adding a codec would create a hard fork, but as long as its activation was set to be a couple weeks ahead, everybody would have time to upgrade.

If you can get to the absolute minimum fees without codec, then clearly there is no point for the codec,but I just get this feeling that if you were able to pack more data into the same space it can only be a good tool to have

James
full member
Activity: 210
Merit: 100
Can somebody (devs?) send me a file with all the historic OP_RETURN 80 bytes of data, or rather what these 80 bytes would have been had that method been used?

I want to take a crack at making a custom lossless codec for it, based on what I have seen so far I think I have a decent shot to get the vast majority of cases to fit into 40 bytes. As long as there is the ability to spill over into the multisig method, I believe we can get the best of both worlds, eg. save on extra fees by using OP_RETURN when possible and if not just end up where we are now. I cant see the harm in this. Once the 40 bytes is released into the wild, I doubt the bitcoin camp will be able to easily reduce it as once people start using it there will be large outcries from more than just the XCP community.

I will write this 100% from scratch without any external libraries. All in portable C. I just need the dataset. Binary file 80 bytes * number of examples would be easiest. Today I came up with a pretty advanced method of compression using context sensitive SVM's, so even if the simple approaches dont work I have a few aces up my sleeve.

If there is a description of what is in the 80 bytes, that will help me design the codec.

James

P.S. I think the rather large price drop recently is a direct fallout from OP_RETURN appearing to be nonviable, the implication being that the temporarily high transaction fees becoming permanent. Lets fix this! Give me a chance

James I like some of your ideas and vision and I write the following with respect: but Unless you already left some of your multiple NXT projects that according to you take all your time and have caused you to go through emotional rampages/rolercoasters/quitting in the middle/coming back on the NXT threads-- than I dont see why/how you should take on more projects here. I would beware- we have a good factual-not emotional and very professional thing here that should be kept this way.
full member
Activity: 238
Merit: 100
It is not a just a matter of fees. It is better to have a Plan B, in case something, happens to our current way of encoding data.
(i.e., future Bitcoin protocol changes interfere with our current encoding).
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
Can somebody (devs?) send me a file with all the historic OP_RETURN 80 bytes of data, or rather what these 80 bytes would have been had that method been used?

I want to take a crack at making a custom lossless codec for it, based on what I have seen so far I think I have a decent shot to get the vast majority of cases to fit into 40 bytes. As long as there is the ability to spill over into the multisig method, I believe we can get the best of both worlds, eg. save on extra fees by using OP_RETURN when possible and if not just end up where we are now. I cant see the harm in this. Once the 40 bytes is released into the wild, I doubt the bitcoin camp will be able to easily reduce it as once people start using it there will be large outcries from more than just the XCP community.

I will write this 100% from scratch without any external libraries. All in portable C. I just need the dataset. Binary file 80 bytes * number of examples would be easiest. Today I came up with a pretty advanced method of compression using context sensitive SVM's, so even if the simple approaches dont work I have a few aces up my sleeve.

If there is a description of what is in the 80 bytes, that will help me design the codec.

James

P.S. I think the rather large price drop recently is a direct fallout from OP_RETURN appearing to be nonviable, the implication being that the temporarily high transaction fees becoming permanent. Lets fix this! Give me a chance

There are lots of things that can be done to reduce the default fees for Counterparty transactions, though these are not widely known. If nothing else, the fee amounts (and multi-sig output amounts, which are not fees) are currently hard-coded constants (and obsolete as of Bitcoin Core 0.9, which should be much cheaper), instead of calculated on the fly to accord with the default relay policies.

Even now, counterpartyd has no problem mixing and matching OP_RETURN and multi-sig outputs. If the transaction-construction code were refactored to create one OP_RETURN, and only then multi-sigs as necessary, fees would be lower immediately, with no changes to the protocol. Moreover, each multi-sig output, as it's currently encoded, is only 50% to 33% optimally data-efficient (the latter number is if we're OK creating unspendable outputs). Once these easy changes are made, we'll know how much we'll need to compress the data to reach certain fee goals.
full member
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
Can somebody (devs?) send me a file with all the historic OP_RETURN 80 bytes of data, or rather what these 80 bytes would have been had that method been used?

I want to take a crack at making a custom lossless codec for it, based on what I have seen so far I think I have a decent shot to get the vast majority of cases to fit into 40 bytes. As long as there is the ability to spill over into the multisig method, I believe we can get the best of both worlds, eg. save on extra fees by using OP_RETURN when possible and if not just end up where we are now. I cant see the harm in this. Once the 40 bytes is released into the wild, I doubt the bitcoin camp will be able to easily reduce it as once people start using it there will be large outcries from more than just the XCP community.

I will write this 100% from scratch without any external libraries. All in portable C. I just need the dataset. Binary file 80 bytes * number of examples would be easiest. Today I came up with a pretty advanced method of compression using context sensitive SVM's, so even if the simple approaches dont work I have a few aces up my sleeve.

If there is a description of what is in the 80 bytes, that will help me design the codec.

James

P.S. I think the rather large price drop recently is a direct fallout from OP_RETURN appearing to be nonviable, the implication being that the temporarily high transaction fees becoming permanent. Lets fix this! Give me a chance

Welcome back. What's op return
legendary
Activity: 1176
Merit: 1134
Can somebody (devs?) send me a file with all the historic OP_RETURN 80 bytes of data, or rather what these 80 bytes would have been had that method been used?

I want to take a crack at making a custom lossless codec for it, based on what I have seen so far I think I have a decent shot to get the vast majority of cases to fit into 40 bytes. As long as there is the ability to spill over into the multisig method, I believe we can get the best of both worlds, eg. save on extra fees by using OP_RETURN when possible and if not just end up where we are now. I cant see the harm in this. Once the 40 bytes is released into the wild, I doubt the bitcoin camp will be able to easily reduce it as once people start using it there will be large outcries from more than just the XCP community.

I will write this 100% from scratch without any external libraries. All in portable C. I just need the dataset. Binary file 80 bytes * number of examples would be easiest. Today I came up with a pretty advanced method of compression using context sensitive SVM's, so even if the simple approaches dont work I have a few aces up my sleeve.

If there is a description of what is in the 80 bytes, that will help me design the codec.

James

P.S. I think the rather large price drop recently is a direct fallout from OP_RETURN appearing to be nonviable, the implication being that the temporarily high transaction fees becoming permanent. Lets fix this! Give me a chance
member
Activity: 111
Merit: 10
Digitizing Valuable Hard Assets with Crypto
full member
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
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?

Counterparty.co read the docs

Thank you, very helpfull.

Oh ok. Well you can check the extensive tutorial I wrote that has all the info you need which is in my signature.
full member
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
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?

Counterparty.co read the docs
full member
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
I think the tone with which you criticize appears to be am attack.
hero member
Activity: 784
Merit: 500
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?
zbx
member
Activity: 64
Merit: 10
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.
sr. member
Activity: 472
Merit: 250
Never spend your money before you have it.
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://bitcointalksearch.org/topic/m.5664449
sr. member
Activity: 262
Merit: 250

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.
legendary
Activity: 1022
Merit: 1000

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.
legendary
Activity: 1022
Merit: 1000

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/
Jump to: