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

I no longer run a pool or solo mine.

So you suggest major pool operators  (e.g. eleuthria) and large, independent mining owners (e.g. gigavps) are the ones to discuss the options with?

If testnet goes well, webwllet should be released by April 1st week(as told by XNOVA) and yes you can import the burner private keys

sounds like hassle,

Is this solution also what is in store for mastercoin?

Satoshi came up with merged mining for this, which BitDNS (now Namecoin) has used to much success.
Other innovative altcoins like p2pool and Freimarkets have further developed merged mining technology.
As I have said before, I completely encourage making better use of merged mining to extend things in any way you like.

Pedantic point: Projects which aim to "start over" are not Bitcoin 2.0 projects, they are just new innovative altcoins, and their developers are not Bitcoin developers (unless they so happen to also do Bitcoin development, of course).
Bitcoin developers are continually working on new improvements to Bitcoin:

• Hierarchical deterministic wallets, and recurring invoice ids
• Headers-first full nodes
• Payment protocol
• GetBlockTemplate decentralised mining
• Pegged side-chains (XCP should be participating in this!)
• ...

After having read the Counterparty document, I would personally suggest using 80-byte OP_RETURN transactions as a temporary solution, and collaborating with the Freimarket developers to move forward, ideally providing a clean upgrade where XCP assets become Freimarket assets.

Then contact more than a couple of pools. This statement sounds like you wish to force miners to include your transactions; surely you didn't mean it that way?
If you can provide a patch that identifies transactional-only Counterparty OP_RETURN transactions uniquely from 80-byte abuse, I will discuss whitelisting it on Eligius with wizkid057.
This is with the understanding that Counterparty will seek to migrate to a more acceptable solution long-term.

Different topic: When about will the web wallet be ready for use and can I import burner private keys with the webwallet?

+1,

Yes, in terms of process, perhaps best if core devs take this discussion offline and then present options to the community incl. merits and demerits once they've had a chance to consider all available options.

Thank you very much!

The definition of a miner is someone who collects bitcoin transactions into a block, and attempts to produce a nonce value that seals the block into the blockchain.

According to BFL_Josh's off-the-cuff estimate, we have about 12 miners in bitcoin.

Stop being a clown. the guy is chinese. I understood the question perfectly well. If this was a chinese-localized project primarily on a chinese forum for instance you would run into same issues trying to speak natively or run through a translation. just because you speak a language other than english does't mean you are any less eligible to invest in crypto projects as other guy above rightly said. and doesn't mean you are more or less stupid. fucking hell come on. no need to be intentionally abrasive over non issues like that.. and to answer the question it's because A get's translated as 0. Asset names are converted to decimal, decimal cannot begin with a 0.


Huh? you mean pool operators?

What pool do you run?

I'm talking about miners -- the people who collect transactions into a block -- not the people who contribute computing services to a mining pool, yet have zero impact over how the network is run.

Don't be a provincial ass, Bellebite. (How's that for a complete, grammatically correct sentence?) Not everyone on this forum is a native English speaker, but their input is significant and valuable.

You might want to get a dictionary, or learn how to make a proper full sentence first before posting, thanks.

Assets name why can not start with "A"?

Wouldn't this solution please everybody ?

It's not enough to have a couple of pools mine our transactions. We need to keep the block time as close to ten minutes as possible.

There are myriad ways of imbedding data in the Bitcoin blockchain. We support two already. We based the architecture of Counterparty on that.

Again, Counterparty was originally designed to use OP_RETURN exclusively, which is obviously the technically superior option. You're 'killing innovation' by supporting arbitrary, very low limits on the amount of data that can be stored in the blockchain properly---i.e. with OP_RETURN. If the limit on the size of OP_RETURN is raised back to 80 bytes, then we'll have no need to use CheckMultiSig outputs the way we are doing now.

As a miner I fully support exploring any functionality which adds value to Bitcoin, the only request being that introducing it be done in a controlled manner. The risk of increasing OP_RETURN to 80 bytes does not seem to outweigh the potential benefits, especially when multisig might not be prunable.

Of course a lone miner's opinion is unlikely to sway the argument, so what would the dev criteria be -- a major pool supporting the change, Gigavps getting onboard, a certain number of signatures obtained for a petition, etc?

I hope you can appreciate that this is a bit if a chicken and egg situation. It's not like Counterparty intended to use multisig in perpetuity. Much older responses in the thread will show how eagerly we waited for 0.9 so that OP_RETURN can be used. So you can understand the disappointment when we come to know that it does not provide enough space for our needs. It also means that our current implementation will have to continue for the foreseeable future.

More disturbing is Peter Todd's identification of a problem with CHECKMULTISIG, if the proposal is indeed accepted, a more viable solution needs to be found not just for Counterparty but for all other such projects that depend on the blockchain as a transport layer.

To this end, I think the Bitcoin core developers must decide if these innovations are of any benefit to bitcoin itself and if the answer is yes then help us find a way for make this work while addressing all your concerns.

I also know that your response to this perhaps will be that Counterparty store transactions off the blockchain and only store the reference hash in OP_RETURN. It helps keep the size of the blockchain to the absolute minimum.

The alternate proposal is that the size of data stored in OP_RETURN should result in increased mining fees. The more space you use the more pay for that transaction. (At least that's what I understood from the thread). Can you please give the thread your opinion on such a solution?

Incorrect.  Re-read the quoted bullet point #1.  Additionally, one post in this thread contained a sentence listing 4+ specific technical solutions.

But I shouldn't have to spoon-feed solutions, to get someone else to fix their system.

Engage the community and miners, listen to feedback and Counterparty can get what it wants.  There is plenty of innovation going on right now in the bitcoin space and it is ludicrous to suggest otherwise.  The bitcoin protocol is easily extensible.  You do not have to abuse a feature meant for ECDSA public keys to do what needs to be done.

Re-read the quoted post...  "Right, the exchange rate between domains and bitcoins would float. ... A longer interval than 10 minutes would be appropriate for BitDNS."

That implies a separate chain, a la namecoin, because "longer..than 10 minutes" would be a hard-fork protocol change for bitcoin.  And then of course

"It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin's chain"

Which is clearly referring to using space not in Bitcoin's chain.

But we still haven't heard any suggestions from you all on how we might do it properly.