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

Can work around it now problem just posted to report problem

Make the internet browser into fullscreen mode , i had the same problem

wallet is still buggy, but awesome

On chrome browser, after creating a new wallet I can't scroll down page to log into wallet.

same here, this is error from log.


and on that domain


edit: that was quick, back up 

It took some hurdles to get Counterwallet working on testnet. xnova is asleep. Please give us some time to figure out what's going on.

EDIT: xnova is looking into it.

I'm not able to open a wallet. I tried different browsers, always getting this error:

wallet is so awesome Xnova, bravo

If BTC reveals to be not so "XCP friendly", why not changing ? 
Would the protocol easily work with litecoin-qt and litecoin's OP-return ??
Sorry for this so blasphematic remark, I have low technical skills, so excuse me if it is a very bad idea for the protocol.  Disclaimer : I am NOT a LTC holder and fan. LTC is just the natural competitor at the moment, with ATM, exchanges, high hashrates...

Works fine for me in full-screen and presentation mode, what browser/OS are you running? You can click the settings icon in top right and copy the
Eng/Res & Browser UA fields.

Counterwallet, chat box does not work while in fullscreen mode.

Thanks for the correction, Phantom. I definitely stepped out of my comfort zone today and was promptly schooled. This stuff is hard.

Also, with the second blockchain, you have a second blockchain to secure, and due to this, Counterparty could not fully leverage the unparalleled PoW security that Bitcoin offers end-to-end. Moreover, unless I am overlooking something here, we would still need to parse out the data from the blocks in that second blockchain (assuming it's a Bitcoin or Bitcoin derivative implementation, at least) to get our stored data. So:
* it would not enable SPV-type Counterparty clients for what Counterparty offers over Colored Coin functionality (i.e. DEx, Betting, asset callbacks, dividends, CFDs, etc)
* it would lessen security of Counterparty transactions
* it would greatly increase the complexity of the implementation (i.e. increasing the chance of bugs and vulnerabilities)

The only dubious benefit would be the *slight* lessening our storage requirements on the block chain (i.e. maybe 20-40 bytes less per transaction?). I just don't see how this would make any sense here.

One more point: Counterparty can bring immense benefits to Bitcoin, and this will especially become more apparent if/as Ethereum (and other similar non-Bitcoin-meta "2.0" type coins) enter the picture. My personal feeling here at least is that Bitcoin may very well need offerings in the ecosystem with this kind of functionality to effectively compete with Ethereum and (future) crowd's feature list and draws -- or risk becoming obsoleted, at least among investors and financial market operators, which offer the ability to bring billions and even trillions into the Bitcoin ecosystem as it gains more recognition, trust, and mindshare with them. This process is, of course, only beginning, but we feel that the clear benefits that the blockchain can offer to finance (for not only Bitcoin payment operations, but for the more advanced finance operations that the technology can enable) will set off the next great phase of Bitcoin's growth, IF allowed to unfold organically.

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.

Greetings Jeff. Thank you for stopping by. I was chatting with Eric and Stephen tonight at Bitpay's new offices about this topic and we had agreed to share an email to explore further, but you beat me to it.

You're absolutely right.
You don't need to store data in the blockchain.
Timestamping hash(data) is just as secure, while more efficient.
A secondary chain can be provably pegged to bitcoin.

However, Counterparty IS storing data in the blockchain using 256 bytes in each one-of-three multi-sig transactions, as per PhantomPhreak's note below. Additionally, all these multisig transactions are processed by the miners.



If OP_RETURN was meant to stop/curtail the multisig behavior (Unspent Outputs) and hereby reduce blockchain bloat, then I fear by reducing the size of OP_RETURN from 80 to 40 bytes, you've inadvertently made multisig MORE ATTRACTIVE to all the metaprotocols and you've made OP_RETURN less attractive. The cost of paying the miners fees has not reduced the ability to survive with multisig.

The technical details are well beyond my abilities, but PhantomPhreak's assertion that the economics of time/effort of squeezing into 40bytes should be noted. Here are Phantom's words:



We (All the metaprotocols) WANT to use OP_RETURN as it is in everyone's interests to do so, but if you hobble the feature's functionality such that the costs to use OP_RETURN are too high to consider, then markets will find other, less costly alternatives to achieve its goals.

We have a mutual interest in reducing blockchain bloat. Is there any reason why 80 bytes will reduce both our abilities to reach that shared objective and is there any reason 40 bytes will make it easier?

Best,
BTT

EDIT & NOTE: Jeff, we're totally okay to take this conversation to the bitcoin core dev mailing list if that's a more appropriate location for this discussion. I will cross-post my follow-up here on the bitcoin core dev mailing list as a new topic.
Thanks!
BTT

While you are here sir, interested to know why the QT client still has bugs - I never got a response on the newbie forum: https://bitcointalksearch.org/topic/why-does-the-bitcoin-qt-client-still-have-bugs-3-years-in-development-518482

Tried the wallet.

1: "No counterparty servers are currently available. Please try again later. ERROR: undefined"

2: Second, the webpage cannot be scrolled or zoomed in both Safari and Chrome. This is not friendly to small screens especially for mobile phones.

3: In the page for enter words with screen keyboard, the words entered are not masked. Moreover, sometimes the keyboard does not work at all and has to press the screen keyboards and the response is pretty slow. (Chrome) Screen keyboard is really really painful and I doubt anyone will like to use it.

Thanks for the hard working and wish my comment helps.

Oops. Then we have to keep using multisig for long data.
do we know how many percent of current transactions can be squeezed into 40 bytes now?
Could we use asset id instead of using the name everywhere?

Awesome Job guys...will give it a whirl...

To date, I've not seen a blockchain data dumping scheme that could not be securely replaced with a simple hash.

You don't need to store data in the blockchain.  That is purely intellectual laziness.  Timestamping hash(data) is just as secure, while more efficient.

Furthermore, a secondary chain can be provably pegged to bitcoin: http://sourceforge.net/p/bitcoin/mailman/message/32108143/

The idea is that it is possible to implement name and category functionality without altering the protocol by making some filtration standards for indexing Assets, so an asset may be DKGCEWU (some unique 8 letter base_58 asset code or 'short name') ~ Gold Troy Ounce ~ ~ (issuer) ~ ~ (comment /pgp link) ~
of course one has to trust the issuer and check the link for the valid pgp signature, but once one has done this all the problems are gui / client problems, you could exclude the ability for someone else to create ~ Gold Troy Ounce ~ on the protocol level but then you are back to the original asset name problem. Instead you link the ~ Gold Troy Ounce ~ to the DKGCEWU that identifies the asset. Sure someone else can make a ~ Gold Troy Ounce ~ but it can easily be distinguished by the 'short name' as different.