Author

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

member
Activity: 111
Merit: 10
Digitizing Valuable Hard Assets with Crypto
Is there a way for the bitcoin protocol to prevent the way XCP is using it, without breaking anything else?
That seems like a very big potential issue if we dont get this resolved...
The miners are supposed to filter out abuses.
Human problems need human solutions.

Not sure i understand right but bitcoin core dev team dont want anyone make new layers over bitcoin blockchain?
The problem isn't new layers, it's forcing things on people against their will.
New layers can be done on an opt-in basis, without polluting the blockchain and forcing non-participants to store the data.

Thanks for engaging with us Luke-Jr. Will you be able to elaborate on how this opt-in basis would work and why reducing OP_RETURN from the proposed 80 bytes was better for bitcoin? It seems that the 40byte reduction might be the first step in a slippery slope to zero bytes in the future by the bitcoin core devs.

Will you help us understand the ways we can work together constructively?
hero member
Activity: 700
Merit: 500
+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.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

"All volunteer"?  I think that's somewhat misleading.  It's not like Bitcoin is Folding@home or something where the nodes are running for a glorious altruistic purpose.  Bitcoin nodes are running because it is profitable to do so (in the case of mining) or they hold Bitcoin and have a vested interest in preserving its value.

Counterparty and Mastercoin play by the rules of Bitcoin.  XCP users pay transaction fees and, to my limited understanding, frequently create unspendable outputs which effectively deflate Bitcoin and so theoretically make every BTC worth a little more, given a set market cap.

Furthermore, XCP is basically extending the utility of Bitcoin.  I think of XCP/MSC as being the JavaScript to Bitcoin's HTML.  Yes, HTML was a revolution, but you essentially could only do one thing with it.  The truly interesting stuff started happening once we allowed little programs to run on top of it and modify it.  We now have fully dynamic, interactive programs running within a Web browser with no plugins needed.  As somebody who started in Web Development back when Netscape was dominant and the coolest thing you could do with JavaScript was change an image on mouseover, I am blown away at the orders of magnitude how much more useful basic HTML is today than it was 15 years ago.

There are some competitors such as BitShares or NXT that run on completely different networks but are trying to achieve the same thing.  Kinda like, say, Flash -- abandon HTML completely, start from scratch and build something that in some ways is more capable than HTML+JS but less compatible, requiring a separate software download and install.

We all know how that story played out.  But if Microsoft had never added a little thing which came to be called XMLHttpRequest to Internet Explorer 5, eventually birthing AJAX and the fully interactive JSON-loaded sites that we have today, the Web might have moved on past HTML.  Would HTML still be around today, or would everybody have moved on to something more fully-featured like Flash (God forbid)?  The duo of HTML+JS = "Web 2.0" has won, but there's no guarantees in this world.

I believe in the BitShares idea, and the NXT idea, and the Ripple idea.  All of these are starting from scratch and building their own networks.  I also believe in the Counterparty and Mastercoin ideas.  Mastercoin and XCP are preserving the Bitcoin blockchain and creating useful structures on top of that blockchain.  To my mind, that should be exciting as hell to someone invested in the Bitcoin community and (presumably) Bitcoins as a currency.  It's a value-add, pure and simple.  And while nobody can predict the future, IMO these features provide a much more compelling future for Bitcoin than the alternative, where so-called "Crypto-Currency 2.0" products simply leave Bitcoin in the dust and abandon PoW-mined blockchains altogether.

I think that I understand your point about unspent outputs being memory hogs for the Bitcoin network nodes.  But AFAIK, this is the one thing that Bitcoin CANNOT do away with.  It seems that Counterparty would be happy to use the 80-byte OP_RETURN space (which, AFAIK, only takes up space in the blockchain and does not remain resident in the active memory of nodes), but with only 40 bytes of space, they are forced to use unspent outputs for some transactions; and if OP_RETURN gets shortened further, unspent outputs will be used for all transactions..

Now, I am just a disinterested observer here (with investments in Bitcoin and all major 2.0 cryptos) so I don't speak for anybody but myself here; but it seems to me that Counterparty has Bitcoin over a barrel somewhat, especially with respect to the unspent outputs, which would be quite difficult to selectively block on the Bitcoin end.  It would quickly turn into a cat and mouse game.  Bitcoin could implement code to detect and block XCP transactions, but XCP changes a few parameters and re-launches a week later to get around it, which causes Bitcoin to respond, which causes a new change in XCP, etc. ad nauseum.  I don't think that anybody wants that.
legendary
Activity: 2576
Merit: 1186
Is there a way for the bitcoin protocol to prevent the way XCP is using it, without breaking anything else?
That seems like a very big potential issue if we dont get this resolved...
The miners are supposed to filter out abuses.
Human problems need human solutions.

Not sure i understand right but bitcoin core dev team dont want anyone make new layers over bitcoin blockchain?
The problem isn't new layers, it's forcing things on people against their will.
New layers can be done on an opt-in basis, without polluting the blockchain and forcing non-participants to store the data.
newbie
Activity: 58
Merit: 0
Not sure i understand right but bitcoin core dev team dont want anyone make new layers over bitcoin blockchain?
legendary
Activity: 1176
Merit: 1134
+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.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.


Is there a way for the bitcoin protocol to prevent the way XCP is using it, without breaking anything else?
That seems like a very big potential issue if we dont get this resolved...
member
Activity: 111
Merit: 10
Digitizing Valuable Hard Assets with Crypto
It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.


Thanks for sharing your thoughts Jeff. So, will you help us start engaging with the existing bitcoin core-dev community? It's in Counterparty's interests to act as a responsible partner as we need the bitcoin blockchain if we are to survive. Will you let us know how we can start working together on these questions?

What would you recommend as some first steps we can take to start to engage and build a constructive relationship?
legendary
Activity: 1596
Merit: 1100
+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.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

sr. member
Activity: 386
Merit: 250
I would like to bring a topic for discussion to get clarity in my mind with your help:
...
CITYGLUT once answered me that XCP is required- but again I am asking: to what extent? can we try to quantify/forecast the use and demand just like we would for a for profit company?
...
NXT- people didnt see a problem - and they see NXT as a store of value backing up the system. I dont see it simply because this ISN'T a company and no stocks are sold. it is a decentralized ecosystem and only the unit of excahange count for real ECONOMIC value (investment wise). the store of value is the platform and code but it cant be quantified financially without real transactions with a currency as mentioned.
...

Thank you, freedomfighter, for asking this question. I saw that you asked at least twice in the NXT forum and did not get an adequate reply. The devil is in the details, but so is the value proposition.

A helpful answer would include examples or a particular use case. Let's use BTT, since they are a live proposition. How will XCPs gain value (how and why will people want to acquire and hold XCPs) if they want to participate in BTT's services? Let's go step-by-step here and see how many times and in what ways a client or BTT has to actually touch XCPs.

EDIT: In 1998, when people were wondering how dotcoms would be worth their extraordinary valuations, the reply was usually "web traffic," "clicks," or something like this. The assumption was that the value of the dotcom had to do with how many users or visitors a website could count. "Just give away some service and once you have your customers locked into your business, then you can figure out how to get money out of them." The business model could come later, they said. For most, alas, that model never did.
legendary
Activity: 1176
Merit: 1134

I shudder at the horrible issues that using backup blockchains will create. Actually, I am having to do exactly this with my automated gateway and there are so many special cases, so many things that usually work but could go wrong. My gateway is just an application, a bug or exploit would be bad, but I am doing my best to contain any damages.

If XCP was spread across multiple blockchains, any problem could well be catastrophic. What happens if the other blockchain goes on a fork or even a blockchain rollback? Disaster.  Even having data in a different block in the same blockchain is a might big pain. It is all nice and tidy if everything needed to resolve the protocol is right there. This is why i suggested the compression approach. This is why the devs do not want to use any "pointers" to other blockchains regardless of how nice it sounds.

Im thinking more along the line of increasing redundancy with additional blockchains. Desaster would be the case if we relied on one blockchain only and something catastrophic happens to it, breaking XCP functionalities. Having copies of the same data in different places sounds like a good idea to me (Bonus points for added decentralization). On top of saving us from catastrophic failure, we also increase stability and reliability of the services XCP provides. After all its a tool for business and no business man wants to use something he cannot rely on. Otherwise risks would outweigh the benefits. We want to avoid that. Maybe I missunderstood your complaint, if so pls explain.
XCP is already in the bitcoin blockchain, which is replicated thousands of times. It already has all the redundancy needed and is currently probably the most secure place to store data, short of some super secret defense dept archive system

The problem I see with having some of the XCP mission critical data in a different blockchain is that if something happened to that blockchain, then it will affect part of the trades, but not all of them. With XCP fully resident on the bitcoin blockchain, if anything strange happens, like a blockchain rewind, all the XCP transactions get rewound too!

If some of the transaction details are on the LTC chain and it gets rolled back, now we have some transactions that half happened and half didnt happen. The Poloniex XCP incident on a across the board scale.

Short of increasing confirmation times to the neighborhood of a day to be sure the other blockchain is stable, I see no way to avoid this risk. Clearly, a one day confirmation time will make Mr. Moneypack start having a lot more fits, so lets not go there. I doubt anybody would agree to a one day confirm time.

So, even though it sounds like we get more redundancy by utilizing a different blockchain, we actually get a LOT more risk and very little added redundancy. After all what is BTC redundancy vs (BTC+LTC) redundancy?

James
legendary
Activity: 1022
Merit: 1000

I shudder at the horrible issues that using backup blockchains will create. Actually, I am having to do exactly this with my automated gateway and there are so many special cases, so many things that usually work but could go wrong. My gateway is just an application, a bug or exploit would be bad, but I am doing my best to contain any damages.

If XCP was spread across multiple blockchains, any problem could well be catastrophic. What happens if the other blockchain goes on a fork or even a blockchain rollback? Disaster.  Even having data in a different block in the same blockchain is a might big pain. It is all nice and tidy if everything needed to resolve the protocol is right there. This is why i suggested the compression approach. This is why the devs do not want to use any "pointers" to other blockchains regardless of how nice it sounds.

Im thinking more along the line of increasing redundancy with additional blockchains. Desaster would be the case if we relied on one blockchain only and something catastrophic happens to it, breaking XCP functionalities. Having copies of the same data in different places sounds like a good idea to me (Bonus points for added decentralization). On top of saving us from catastrophic failure, we also increase stability and reliability of the services XCP provides. After all its a tool for business and no business man wants to use something he cannot rely on. Otherwise risks would outweigh the benefits. We want to avoid that. Maybe I missunderstood your complaint, if so pls explain.
hero member
Activity: 647
Merit: 510
Counterpartying
Regardless of if it is 500% or 800% above burn price, it is still at all time lows as far as post-exchange pricing. The market is telling us something.

Also, a common saying among traders is to "buy the rumor, sell the news" What this means is that anybody that knows about the counterwallet probably has bought all the XCP they want and is expecting the price to go up when it is released. However, if everybody already bought XCP, who is left to buy XCP after the wallet is out? Only the people who didnt even know anything about the counterwallet, which means they dont know much about XCP, which means they probably dont have a lot of BTC.

In addition to some selling from burners who were waiting for counterwallet to access their XCP, the "sell the news" part will most likely put some more downward pressure on the price. How far is anybody's guess.

the relatively high transaction fees are one of the frictions that will slow XCP usage. I would find it helpful to understand what exactly the new fee structure would be. By fee, I mean any and all costs somebody that uses Dex pays, regardless of whether it is to miners or multisig limbo, etc.

James

The market is saying an entire currency was divided between a few thousand people who made significant returns and those poeple are now cashing some of those returns out faster than new money is coming in. I partially addressed "what the market is telling us" in my previous post so I won't repeat my opinions again. Suffice to say, I am not overly worried, but I do understand that some people could have concerns and I'm not trying to downplay the risk, of which there is plenty, or shun people for having opinions that are different than my own.

There are a number of sayings among traders, some of them more cliche than others, and they are welcome to them. In the end, I don't think short term traders will play a large role in the long term success or failure of Counterparty, they will create volume and price fluctuations, and that is fine.

Unlike just about all other "altcoins", Counterparty *will have* significant utility - it does not have that utility yet. If people are buying the rumor and selling the news I just don't care that much. They can have at it. Although, certainly more people will find out about Counterparty and Counterwallet between now and the launch and buyers will continue to trickle in and this will help offset the news/rumor stuff.

Once the utility is there, there will be more than enough people who get *use* out of XCP and this is what will make it a success. I see this period as a transition from the community being completely comprised of believers and speculators to also include people who use XCP exclusively for the utility it provides and I welcome the shift, even if it is a rocky road. When people can use XCP to hedge currency risk, use leverage, and so on, it will not matter what the price was at the time. The underlying utility of XCP will be there and that is all that will matter to the people who have legitimate financial needs.

NOTE: I am not saying the price will go down or up in the short term. I just don't think it matters all that much.
full member
Activity: 238
Merit: 100
+1
Nice analysis freedomfigh, especially the part on the incorporating XCP on every transaction for it to have value.

full member
Activity: 210
Merit: 100
I would like to bring a topic for discussion to get clarity in my mind with your help:

without getting into the fees issue in detail I think that moneypaktrader mentioned a point that should be principally discussed:

"5) .......a 5 XCP fee was introduced  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....."

i dont care 5, 4, or 1 xcps-- and I believe that at that DEVs should call the shots at this juncture (feedback is always good to have or give)- but even a decentralized movement needs some centralized aspect and leadership to not go all over the place (like NXT recently did)

what I do want to emphasize/raise for discussion is the economic value of a project such as counterparty and how and why its market cap will increase:

1) moneypaktrader's  assertion is valid in the sense that the more use there is for XCP "the unit of exchange" the more economical value it could give the project as a whole as more XCPs will be in demand. simple supply/demand.

2) BTC for example is clearly (also) a unit of exchange that is recognized by tens of thousands of businesses around the world as a currency for which services and products can be granted. It also serves as a payment and micro payment system -- requiring the BTC itself again as the unit of exchange. This in itself will create a value/market valuation that can mathematically be calculated based on total annual volumes + savings account etc + speculation on its potential ALL around an economy surrounding the usage of the unit of exchange and its potential ACTUAL USAGE.  

If we use a fable: No one needs to have "shares" in BTC since the BTC itself is the share.

3) However- how will vertical 2.0 projects like counterparty derive value and a higher market cap? just like BTC, the real economic value is going to be derived from demand for XCPs. Demand for XCPs is derived from its use/function as some sort of a unit of exchange within the valuable CP ecosystem/platform.

While the platform is a prerequisite, the CP valuation CAN'T in my opinion be derived from it per se, but rather ONLY from the actual demand for XCPs (obviously the platform and tools such as GUI are as mentioned a prerequisite and must be an excellent field for all functions/operations).

If this was a centralized company than the platform's potential would be it and holding a share would provide the asset value and valuation. I believe that this is why RIPPLE is structured the way that it is. HOWEVER in our case, as well as in NXT MSC etc-- there is no real meaning for a stock/shares model.

4) Thus, and this goes back to MPTraders's point- the more demand driving REAL use for ACTUAL XCPs within the ecosystem - the higher overall transactions value in XCPs- and the higher valuation of the overall project.

5) A HUGE advantage for CP is its seamless interaction with BTC and its being built on top of the BTC network-a proven and relatively established network. with the right marketing it can draw on tens and hundreds of thousands of users in due time that BTC already attracted. HOWEVER- every transaction even on an asset or coin or what have you, should require an ongoing use and therefore demand of XCPs.

6) Based on this: I want to ask: - if someone issues a coin (lets call it "gamblingcoin or GAMC) on top of CP and than issue a betting asset with "GAMC" as the currency of payment and bet - what happens with the XCP the unit of exchange? is it only used ONCE when issuing the GAMC? if so- than it is problematic as a user doesnt need to use XCPs at all anymore AFTER issuing their coin. (just like with letstalkbitcoin's coin I believe). AM I MISSING SOMETHING HERE?

CITYGLUT once answered me that XCP is required- but again I am asking: to what extent? can we try to quantify/forecast the use and demand just like we would for a for profit company?

The etherium team once answered me that ETHER is the fuel to the system i.e. that EVERY transaction will involve it. NOW if that is true than obviously this is your demand driver for ETH.

NXT- people didnt see a problem - and they see NXT as a store of value backing up the system. I dont see it simply because this ISN'T a company and no stocks are sold. it is a decentralized ecosystem and only the unit of excahange count for real ECONOMIC value (investment wise). the store of value is the platform and code but it cant be quantified financially without real transactions with a currency as mentioned.

(I am not a dev but have been around valuations and venture capital for nearly 20 years with clients raising hundreds of millions)- maybe I am having a serious case of tunnel vision-BUT i just dont see any cap generator without real and constant demand for the unit of exchange to drive the economy. especially in a vertical context such as CP. Am i wrong?
legendary
Activity: 1176
Merit: 1134
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

We still up something like 800% from the burn period prices which is nice.

It seems likely (to me) that the price decrease is from something as non spectacular as people cashing out portions of their investments because of the gains they made. And unfortunately, new community members are coming in slower than we would like which means the 1400% price increase from burn prices was not permanent.

The more recent price decrease probably has some correlation with where we are as a project and public perception of Counterparty because of the previous failures and endless delays of other projects in the second generation space. When Counterwallet is live on mainnet and the Counterparty ecosystem develops further to give more utility to XCP, it's game over.

Also, it's worth noting that bitcoin just experienced a drop in value percentage wise, albeit over a longer period of time, that is similar to what XCP just went through (perhaps Litecoin is a better example though), and bitcoin is, well, bitcoin. I see no reason to think XCP will be more stable than the king of digital currencies. Price swings are just part of the game.

All that said, the OP_RETURN thing is annoying and it would be awesome if someone could "fix" it. Having backup blockchains seems like a good idea, but I have no idea what something like that would take to accomplish.
I shudder at the horrible issues that using backup blockchains will create. Actually, I am having to do exactly this with my automated gateway and there are so many special cases, so many things that usually work but could go wrong. My gateway is just an application, a bug or exploit would be bad, but I am doing my best to contain any damages.

If XCP was spread across multiple blockchains, any problem could well be catastrophic. What happens if the other blockchain goes on a fork or even a blockchain rollback? Disaster.  Even having data in a different block in the same blockchain is a might big pain. It is all nice and tidy if everything needed to resolve the protocol is right there. This is why i suggested the compression approach. This is why the devs do not want to use any "pointers" to other blockchains regardless of how nice it sounds.

Regardless of if it is 500% or 800% above burn price, it is still at all time lows as far as post-exchange pricing. The market is telling us something.

Also, a common saying among traders is to "buy the rumor, sell the news" What this means is that anybody that knows about the counterwallet probably has bought all the XCP they want and is expecting the price to go up when it is released. However, if everybody already bought XCP, who is left to buy XCP after the wallet is out? Only the people who didnt even know anything about the counterwallet, which means they dont know much about XCP, which means they probably dont have a lot of BTC.

In addition to some selling from burners who were waiting for counterwallet to access their XCP, the "sell the news" part will most likely put some more downward pressure on the price. How far is anybody's guess.

the relatively high transaction fees are one of the frictions that will slow XCP usage. I would find it helpful to understand what exactly the new fee structure would be. By fee, I mean any and all costs somebody that uses Dex pays, regardless of whether it is to miners or multisig limbo, etc.

James
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder

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.

I'm looking into this now.
hero member
Activity: 647
Merit: 510
Counterpartying
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

We still up something like 800% from the burn period prices which is nice.

It seems likely (to me) that the price decrease is from something as non spectacular as people cashing out portions of their investments because of the gains they made. And unfortunately, new community members are coming in slower than we would like which means the 1400% price increase from burn prices was not permanent.

The more recent price decrease probably has some correlation with where we are as a project and public perception of Counterparty because of the previous failures and endless delays of other projects in the second generation space. When Counterwallet is live on mainnet and the Counterparty ecosystem develops further to give more utility to XCP, it's game over.

Also, it's worth noting that bitcoin just experienced a drop in value percentage wise, albeit over a longer period of time, that is similar to what XCP just went through (perhaps Litecoin is a better example though), and bitcoin is, well, bitcoin. I see no reason to think XCP will be more stable than the king of digital currencies. Price swings are just part of the game.

All that said, the OP_RETURN thing is annoying and it would be awesome if someone could "fix" it. Having backup blockchains seems like a good idea, but I have no idea what something like that would take to accomplish.
full member
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
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

Yeah the ten minute thing is painful. It's basically like every transaction is the same thing as if you were withdrawing from an exchange to a local wallet. Having spent so much time on centralized exchanges, the wait time on the DEX just seems off putting.
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.
Jump to: