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

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

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

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.

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).

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.

Welcome back. What's op return

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

https://www.counterparty.co/faqs/i-burned-btc-through-blockchain-info-how-do-i-access-my-xcp/

Oh ok. Well you can check the extensive tutorial I wrote that has all the info you need which is in my signature.

Counterparty.co read the docs

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

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?

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.

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!


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. . .

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

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.

..except for: Counter party risk    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.

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

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

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!

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/