[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[halfcab123]

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

[1714928351]

1714928351

[halfcab123]

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.

[BitcoinTangibleTrust]

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?

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

[jl777]

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

[halfcab123]

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

[PhantomPhreak]

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.

[kdrop22]

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

[freedomfighter]

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.

[jl777]

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

[Spekulatius]

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

[led_lcd]

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.

[jl777]

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

[jl777]

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

[halfcab123]

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.

[Matt Y]

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.

[PhantomPhreak]

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.

[jl777]

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

[freedomfighter]

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?

[kdrop22]

+1
Nice analysis freedomfigh, especially the part on the incorporating XCP on every transaction for it to have value.

[Matt Y]

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.