 Show Posts
|
|
Pages: « 1 2 3 [4] 5 6 »
|
Thanks! We definitely have more good news to share! We're just waiting on another partner to close on our agreements. |
|
|
|
Product and Service Updates March 25, 2014Our mission is to digitize all valuable hard assets into the Counterparty platform and to build a reputable service that can increase the value of all XCP holders. BitcoinTangible Trust partners with Agora CommoditiesWe're pleased to share that BitcoinTangible Trust has opened a bulk-purchasing relationship with Agora Commodities for select gold and silver bars and coins. Customers of BitcoinTangible Trust, who wish to move into and out of gold in bulk, can do so quickly and without concern for losing premium on their gold or silver holdings. Agora Commodities has also agreed to help BitcoinTangible Trust deliver independent Proof of Custody for all BitcoinTangibleTrust purchases. Agora's CEO understands exactly what we are doing and has expressed enthusiasm to see us succeed and has given us permission to use Agora's logo on the BitcoinTangibleTrust website. We're excited to have Aogra as a digital custodian partner. We expect to add other gold and silver sales partners in the future. If you have a particular reseller you prefer, please PM us so we may establish a relationship with them. BitcoinTangible Trust will offer BTC to Digital SilverThrough community feedback, we will lower the barrier for professionals to try Bitcoin Tangible Trust with as little financial risk as possible. We have removed our minimum order from 2BTC. We also now offer Silver for those interested in testing our platform with only minimums requested by Agora Commodities by weight. This means that if you have wish to purchase a few silver coins to test the platform, we will welcome your trial with us. Thank you Counterparty Devs and the Counterparty Community, Bitcoin Tangible Trust Team
|
|
|
|
|
Taking policy fights out in the press never gets the wronged party what it wants.
Blockchain.info got Apple to allow wallets in the iPhone when they took out multilple press releases/blog posts. People even shot up their iphones and Apple cried.
|
|
|
|
I can't help but feel like we're wasting our time fighting over bitcoin, when it's not all that well suited to a DEX anyway, due to the long confirmation times. Didn't somebody just post that this has become excruciatingly clear with the advent of counterwallet?
Not all Counterwallet DEX transactions require short confirmation times, my good sir!  |
|
|
|
+1 Congratulations Jah and Counterparty Devs. Excellent work! A very logical and great move for XCP. |
|
|
|
Hey guys, so to my understanding the reason for the idea of making multisig transactions non-standard was the high amount of unspent outputs that were created by data-storage transactions. I want to put this into some perspective:  ( https://i.imgur.com/c9mpd8h.png) I did not evaluate how many unspent outputs were created by all multisig outputs, because I'm unable to do so efficiently, but here are some observations nevertheless: Out of 35.508.561 multisig outputs ever seen on the blockchain XCP and MSC account for 5.192 multisig outputs. That's about 0.000146 %. Out of 9.819.223 unspent outputs at the very moment (RPC: gettxoutsetinfo) the amount of unspent XCP and MSC multisig outputs is 3.226. That's about 0.000329 %. In the case one wants to run some tests on this data: multisig-usage.rar (format: "txid vout rawtxhex" -- file size is about 8 MB, but be aware that multisig-all-full.txt is over 1.4 GB unpacked!) Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead.  Thank you for the intelligent analysis dexX7. The numbers are pretty stark when you "see" them. |
|
|
|
I still don't see what mastercoin is doing about this ....
Mastercoin needs more than 80bytes in OP_RETURN for asset issuance. Theirs seems to be a different problem. |
|
|
|
I think it's a ludicrous idea.
Basically Luke-Jr is saying we should have a model of explicit whitelisting where people ask permission first to use Bitcoin. Right now that wouldn't be one patch, it'd be two patches: Counterparty and Mastercoin. Very soon it'll be three patches as Colored Coins adds decentralized exchange functionality, and probably soon after that four patches when Zerocoin is deployed, five once the guys doing secure multiparty computation with Bitcoin release their software, six for... You get the idea. On top of that from technical perspective writing a general purpose patch to distinguish even just Counterparty transactions from "spam" is impossible without having access to the Counterparty consensus state. Sorry guys, but Luke is either foolish or trolling you.
There's a bigger issue too: You know, one of my criticisms of Mastercoin and Counterparty is that because they don't have a scripting system adding new functionality requires the co-operation from core developers to deploy as an upgrade. Yet here, we see Luke wanting the exact same model for Bitcoin in perpetuity.
Anyway, as I've said before, getting OP_RETURN deployed makes Counterparty and Mastercoin transactions a bit cheaper. That's it. This isn't a "sky is falling" scenario, this is a "better get the umbrellas out" scenario.
Peter, I admire you immensely and I enjoy you work and respect your passion. However, I'm disappointed that your response (as a paid Counterparty representative) seems equally mixed with personal anger against Luke-Jr and insightful comments on how to resolve our issues. Your post above accusing Luke-Jr of trolling and calling the proposal "ludicrous" was unnecessary to help us move forward and may have set us back. Neither jgarzick nor Luke-Jr have made any personal attacks on anyone in the Counterparty team during this exchange. If we wish to continue to make progress together on this issue, I must ask that you refrain from making personal attacks against other bitcoin core devs, particularly as you officially represent Counterparty. Yes, we have our differences and we may not like each other that much, but I would ask that we keep our focus on the commenting on the merits of the solutions proposed. If I recall, it was you who said we must stay in the herd with the greatest numbers for the greatest security. I agree with you and hope that you'll agree with me to keep our exchanges professional so we can stick together. EDIT: I will also that ask that you and Luke-Jr discuss the Coiledcoin 51% attack accusations separately from this thread, if that's okay. |
|
|
|
This is not a good proposal. If nothing else, you're seriously misunderstanding the motivations for the various proposals at the table. We don't need six months to implement anything, and the Bitcoin protocol shouldn't go backwards as you suggest. This also doesn't address the security issue that Peter Todd brought up.
As I see it, the best solution is to keep the OP_RETURN size at 40 bytes, for simplicity and compatibility, but to allow multiple OP_RETURN outputs per transaction. There's no reason that 40 bytes of misc. data per transaction is better for Bitcoin than 80, or 120 bytes. Luke-Jr, jgarzik, et al. are merely uncomfortable with the idea of using Bitcoin for things that they had never thought of, so they don't want to encourage people to do anything but store hashes in the blockchain (as if everyone had explicitly agreed to do that!).
Much better than anything I could come up with. I crossed out what I wrote above. Thanks for outlining a sensible approach. I'll bow out from here on out. |
|
|
|
P2SH multisig can replace bare multisig, by moving the data stored in outputs to the inputs.
This also avoids bloating the UTXO database, the key database that is queried multiple times per second by all full nodes on the network.
Solutions have existed for years. UTXO database is not the place for data storage. It impacts everyone, network-wide. It impacts the real-time performance of the network.
Dear Jeff, Luke-Jr and Peter. Thank you for taking time to communicate and engage with us here. We've discovered quite a bit and we're happy to have you bitcoin core devs sharing your interest on our thread. In the interest of a way forward, will you let me propose 3 steps based on your note above that will include some give and take to make sure we can all work together? Step 1: Give us the 80bytes for OP_RETURN. Let Counterparty and other metaprotocols like Mastercoin take the pressure OFF the UTXO database for EVERYONE as its in all our best interests and improves UTXO database performance immediately. Our interest is to improve Bitcoin performance and to avoid spamming the network. Together, let us monitor OP_RETURN behaviors with you as it is in our interest to do so. If SPAM gets out of hand, we can always disable or reduce the size to 40bytes.
Step 2: We will give you OP_RETURN in 6 months so it can be taken into obsolescence. Together, why don't we set a community deadline date for OP_RETURN to be removed from protocol so that Counterparty and Mastercoin both move to P2SH or other solutions. Given that this stuff is hard, we will be able to have the breathing room necessary to implement a blockchain friendly solution. Again, the blockchain performance is still protected here. We also assume that you'll continue to restrict bare multisig transactions, but that won't impact Counterparty or Mastercoin as we'll be using P2SH or better.
Step 3: We will take Peter Todd's continued guidance as our liason with the bitcoin core devs. He has showed immense value bringing up solutions to keeping us together/secure on the same blockchain. We will work with him to exchange further questions and issues wiith the broader bitcoin coredev/security community so that we don't lose touch with each other's interests. As you've mentioned here, you like his proposals and we would benefit to use them.
Is there any reason why this is against your interests and not something we can work on together?EDIT: See Phantom's follow-up below as a much better approach. |
|
|
|
Think about it. Mastercoin is a competitor to Counterparty. Mastercoin is already aware of, and working on solving this storage-in-multisig problem.
Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable.
Thanks Jeff. This is very helpful data. I was not aware of Peter's proposal and I have emailed him and asked him to respond here. It appears that Peter is also employed by Counterparty so he may be able to share some further insights about his proposal and how Counterparty may participate and add to the interests of both the bitcoin developer and bitcoin mining communities. It's in our interest to support proposals that everyone finds agreeable. I believe the post Jeff is referring to is this one: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depthHowever, anyone please correct me if that's the wrong thread? EDIT: Peter's follow-up reply is here: https://bitcointalk.org/index.php?topic=395761.msg5824079#msg5824079 |
|
|
|
Isn't Peter Todd working on Mastercoin? Why would he propose that?
Think about it. Mastercoin is a competitor to Counterparty. Mastercoin is already aware of, and working on solving this storage-in-multisig problem. Peter Todd's proposal simultaneously (a) benefits Mastercoin, (b) disadvantages Counterparty, and (c) presents a proposal that portions of the developer and mining community already find agreeable. Isn't Peter Todd also employed by Counterparty? https://www.counterparty.co/sergio-lerner-peter-todd/Maybe the devs at Counterparty should learn Peter's proposal and we explore how we might participate to benefit alongside Mastercoin? |
|
|
|
Zero bytes is exactly how it's intended to be.
Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.
Thanks Luke-Jr. Please bear with me. Although I am not the most technically bitcoin-competent, I'm trying to ask questions so we can continue to host a conversation and share further insights from bitcoin core-devs like yourself. Maybe I'm wrong, but I am reading your words as follows: Miners will always decide their interests in what type of transactions they wish to mine. Currently, Counterparty uses multisig which are standard transactions. Although we do not wish to add to blockchain bloat, it would appear that as long as we are allowing miners to achieve their economic interests in mining all standard multisig transactions, then the system is working as it should. Am I understanding your thoughts correctly? |
|
|
|
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? |
|
|
|
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? |
|
|
|
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! |
|
|
|
If you're like me, a less technical user, the answer is that you can sell them for BTC or other asset: XBTC: https://forums.counterparty.co/index.php/topic,160. Gold: https://forums.counterparty.co/index.php/topic,179.msg1219. With a little bit of technical prowess you can: Create your own altcoin that functions within the rules you specify. Create a callable, debt based asset. IPO a company. The easiest example is if you owned a mining pool, you could distribute shares to all the miners, then automatically pay dividends in bitcoin, instead of doing it by hand with an excel spreadsheet. As the system fills out over the coming month or so: Make simple Win/Less bets (sports), or more complex financial bets, which will allow you to leverage or hedge your position in various currencies. Please keep in mind that if you are in the USA or selling any of your cool Counterparty-based products to customers in the USA, you may be investigated by the Securities and Exchange Commission (SEC) for the illegal issuance of company shares for sale to US citizens or residents and/or the illegal hosting of betting platforms for US customers. I don't like these rules anymore than you do, but please take note of the rules and regulations in your country. You can run a successful betting platform on Counterparty, you just may not be able to have US customers. See Erik Vorhees problems with SEC: http://trilema.com/2014/interacting-with-fiat-institution-a-guide/ |
|
|
|
I think you misunderstood what jgarzik is saying. The idea is that we store the data in a second blockchain, and put hashes of that timestamped data in Bitcoin, which hashes would also be less than 40 bytes. The reason we did not do something like that is not a matter of "intellectual laziness", but rather of implementation complexity. Counterparty is not a project in computer science; it is designed to be a simple as possible, for the benefits in development speed. Even if we have to store our data in multi-sig outputs rather than the too-small OP_RETURN outputs. Worse is definitely better in this space.
In any case, we appreciate the suggestion, jgarzik, and if you think we're still missing anything here, specifically w.r.t. the space of technical possibilities, please let us know. Thanks.
Thanks for the correction, Phantom. I definitely stepped out of my comfort zone today and was promptly schooled. This stuff is hard. |
|
|
|
|
