Author

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

hero member
Activity: 588
Merit: 500
Where is xcp traded? Is the wallet going to be more user friendly any time soon. Bitcoin has a better wallet at this point.

Bter and Poloniex.

Yes, and you can test it here: https://testnet.counterwallet.co/

Thanks
full member
Activity: 210
Merit: 100
Counterwallet live on testnet

Link: https://testnet.counterwallet.co/

Report bugs here: https://forums.counterparty.co/index.php?topic=188.0
Get testnet XCP here: https://forums.counterparty.co/index.php/topic,184
Get testnet BTC here: http://tpfaucet.appspot.com/
Blog post outlining functionality: https://www.counterparty.co/counterwallet-live-testnet/

xnova has done a wonderful job developing Counterwallet and he deserves a big thanks from all of us. Let's all start testing and get Counterwallet on mainnet as soon as possible!

Thanks xnova. A truly remarkable job you've done on this.

this is your answer. should go live later this month (any new update?)
hero member
Activity: 647
Merit: 510
Counterpartying
Where is xcp traded? Is the wallet going to be more user friendly any time soon. Bitcoin has a better wallet at this point.

Bter and Poloniex.

Yes, and you can test it here: https://testnet.counterwallet.co/
hero member
Activity: 588
Merit: 500
Where is xcp traded? Is the wallet going to be more user friendly any time soon. Bitcoin has a better wallet at this point.
sr. member
Activity: 350
Merit: 250
Vires in Numeris
After 340 pages, is it possible this thread has become unmanageable and sidetracked?

Regarding Bellebite, he may seem a bit rough but his frustration (i assume that is what it is) is warranted.

We are all frustrated  (except those that sold at 10  Undecided).

We have an amazing protocol with a great community but we are being strangled by a dependency on something that is in all honestly becoming redundant and losing relevance by the month (if not week). We are limited by a large barrier to entry (downloading bitcoin blockchain, slow and complicated setup process). We have to admit that for most people, this process is just too large and technical for widespread adoption.

Again, Counterparty is amazing and I feel somehow inadequate to properly convey the possibilities that it grants us to people who are not so technically inclined.

Unfortunately, due to its initial design, we now have this large unwieldy beast which has no central control. We have no marketing team to ensure its usage and success. We have no one with more of a vested interest than anyone else. For fairness sake this is wonderful, but for producing a profitable brand and achieving widespread adoption this is fairly weak.
The developers had to burn BTC just like the rest of us, and so they have just as much to gain and lose as the rest of us, and nothing more.

That is not the most productive model.

Some of you may remember when we first started on this journey I was pushing to have the burn address changed to the developer donation address or to have donations treated as burns.
At that point over 1,000 BTC had been burned. By the end over 2,000 BTC burned.
Should some of those BTC had gone into a development fund we could pay for things like targeted ads on facebook, taking ads in dailies for large cities and had professional videos and marketing materials produced. We could have payed to make the protocol easier and better to use, today. Unfortunately we have to wait for others to donate their time to produce these tools for free.

JahPowerBit and other Devs are working on tools to make it more accessible to common people but (at least in JahPowerBits case) they are just too busy/overworked to accomplish a lot on this project each week. With a development fund we could have paid these developers to take time off of work and get these tools completed asap. We could have had the tools to ensure ease of use a month ago.

This is one of the drawbacks of not having a decisive head to make these calls. An organization with self-interest in mind would make these kinds of decisions and we would all benefit from it.

What am I saying? I don't know. I'm just bitching  Angry

The current state of counterparty is depressing with this bickering back and forth with bitcoin developers and the stagnant market activity.
All it takes is one person to sell 1000 XCP to tank the price.

How can we relay to people just how amazing counterparty is when all non-technical people care about is the price? If it won't make them money why should they care? These are monumental issues that snowball into larger ones without any clearly defined decisions and budget to counteract them.

No offense to them, but things like the Bitcoin tangible trust are pointless and stupid if there is no one to use them. We have to face the facts that no one wants to use this protocol yet in its current state. No matter how revolutionary it is.
BTT is like that guy who shows up two hours early to the party and just hangs around waiting for someone to talk to.

As it is now, I think we are all just waiting for the protocol to become more user friendly. So it can be promoted and more easily utilized.
full member
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
This has to be an April Fools day joke, right?

I'm guessing so but come to think of it with the hashrate it could be feasible huh?
full member
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com

Haha didn't even saw this until now.. Wink

Serious question: is there any benefit in "burning" coins instead of spending them to miners?



Bitcoin deflation is one
hero member
Activity: 647
Merit: 510
Counterpartying
This has to be an April Fools' Day joke, right?
legendary
Activity: 1106
Merit: 1026

Haha didn't even saw this until now.. Wink

Serious question: is there any benefit in "burning" coins instead of spending them to miners?

legendary
Activity: 1321
Merit: 1007
This is where 80 bytes OP_RETURN will take Bitcoin

legendary
Activity: 1120
Merit: 1160
Peter, could you supply a link to any and all P2SH^2 information?  I'm afraid that what I found (a single short thread on the bitcoin devs mailing list) was not terribly complete (or maybe I'm just lacking on background implementation info).

I do appreciate your taking the time to teach.

That thread is the best resource on what P2SH^2 is; the question isn't so much about implementation, but rather understanding why Bitcoin works and what exactly is the role of mining.
hero member
Activity: 700
Merit: 500
Disclaimer:  I have not looked into the details of how P2SH^2 or even P2SH works yet.

I also think it's not possible to prevent embedding data.  In baddw's scheme, pre-generating dozens of vanity-like addresses for the "alphabet" addresses should be an easy one time brute-force if we limit the number of bits per address.

Yeah, you're basically limited by how much space you have for that dictionary. For instance a 32-bit brute force dictionary, stored as 32-bit seeds, would be 17GiB.

Could you not then embed the data by linking your alphabet addresses to all the vins/vouts of your transactions?  Most of it could just be sending coins back and forth between your own "alphabit" addresses.

For the non-brute force solution, embed your bits into all the transaction values.  ABCD can just be values in vout[1]vout[2]...etc...to your own addresses.

You guys are still all missing a even deeper implication of P2SH^2. I'll give you another hint: Does data need to be stored forever to prove it was published once?

Peter, could you supply a link to any and all P2SH^2 information?  I'm afraid that what I found (a single short thread on the bitcoin devs mailing list) was not terribly complete (or maybe I'm just lacking on background implementation info).

I do appreciate your taking the time to teach.
legendary
Activity: 1120
Merit: 1160
Disclaimer:  I have not looked into the details of how P2SH^2 or even P2SH works yet.

I also think it's not possible to prevent embedding data.  In baddw's scheme, pre-generating dozens of vanity-like addresses for the "alphabet" addresses should be an easy one time brute-force if we limit the number of bits per address.

Yeah, you're basically limited by how much space you have for that dictionary. For instance a 32-bit brute force dictionary, stored as 32-bit seeds, would be 17GiB.

Could you not then embed the data by linking your alphabet addresses to all the vins/vouts of your transactions?  Most of it could just be sending coins back and forth between your own "alphabit" addresses.

For the non-brute force solution, embed your bits into all the transaction values.  ABCD can just be values in vout[1]vout[2]...etc...to your own addresses.

You guys are still all missing a even deeper implication of P2SH^2. I'll give you another hint: Does data need to be stored forever to prove it was published once?
legendary
Activity: 905
Merit: 1012
Didn't know that quote was from you Peter. I would reserve the phrase "side-chain" for things that actually involve chains other than bitcoin at the very least. Anyway the complaint was that the quote had nothing to do with the concept of a side-chain jtimon was talking about.
legendary
Activity: 1120
Merit: 1160
LightedLamp, I don't think that person you are quoting understands what we mean by "side-chain." There would be no storing of hashes via OP_RETURN, and no referencing of external transactions. A side-chain is just another block chain, but one which allows transfer of value back and forth between itself and the bitcoin chain (and other chains too). So you can move coins onto the side-chain, do whatever fancy transactions you want (e.g. distributed markets), and then move back when you are done.

Well if we're not going to call what I was talking about as a side-chain, what term do we want to use for the notion of a chain that consists of hashes embedded in one blockchain, that refer to data that we're not storing on that blockchain? Do you want to reserve the term side-chain for only a specific way of moving value from one to the other? Because from the user's point of view handling that by atomic purchases of shares for coins or whatever doesn't look much different from the SPV proofs model. You also have to ask if a side-chain refers to a specific proof-of-work consensus, or things like proof-of-sacrifice apply as well - and as I argued above, if the "hashes that refer to data stored elsewhere" has any hope of being secure you need actual incentives to publish and thus something like proof-of-sacrifice and a chain-style structure.
legendary
Activity: 905
Merit: 1012
LightedLamp, I don't think that person you are quoting understands what we mean by "side-chain." There would be no storing of hashes via OP_RETURN, and no referencing of external transactions. A side-chain is just another block chain, but one which allows transfer of value back and forth between itself and the bitcoin chain (and other chains too). So you can move coins onto the side-chain, do whatever fancy transactions you want (e.g. distributed markets), and then move back when you are done.
newbie
Activity: 24
Merit: 0
I don't know if this meets all of the requirements stated, but based on a quick skimming of P2SH^2 and your Proof-of-Publication paper, here's a rough idea of an "attack" to store arbitrary data.  This would require a tiny amount of brute-forcing, and it is not dust/fee-efficient, but I think it would work.  I was unable to find the "2.0" discussion.

You missed the part where I said "no-brute-forcing" - I'm talking about something quite different that takes advantage of what P2SH^2 does. However, the rest of your post would work and is actually pretty clever, so sent you a tip all the same.

Hey, thanks man!  I like these games  Grin  Unfortunately I am not very well-read on a lot of this stuff, but I've been convinced for a long time that it's impossible to prevent hiding data in Bitcoin transactions, unless somehow every output address is pre-approved, which is of course impossible without completely wrecking Bitcoin.  The P2SH^2 idea seems to be trying to add a bit of "verification" to output addresses, but even requiring 2 hashes doesn't really change anything.  It makes it a bit harder, but as long as output addresses are essentially arbitrary, there's no way to prevent some attack along these lines from working.

And I didn't "miss" the brute-forcing, I just kind of ignored it because the brute-forcing in this scheme would (unless I'm way off somehow) only require a few milliseconds of computation for a single-byte encoding, as you'd only need to come up with hashes starting with A-Z, a-z, 0-9.

Disclaimer:  I have not looked into the details of how P2SH^2 or even P2SH works yet.

I also think it's not possible to prevent embedding data.  In baddw's scheme, pre-generating dozens of vanity-like addresses for the "alphabet" addresses should be an easy one time brute-force if we limit the number of bits per address.

Could you not then embed the data by linking your alphabet addresses to all the vins/vouts of your transactions?  Most of it could just be sending coins back and forth between your own "alphabit" addresses.

For the non-brute force solution, embed your bits into all the transaction values.  ABCD can just be values in vout[1]vout[2]...etc...to your own addresses.
member
Activity: 111
Merit: 10
Digitizing Valuable Hard Assets with Crypto


Product and Service Updates March 31, 2014
Our mission is to digitize all valuable assets into the Counterparty platform and to build a trustless, yet reputable service that delivers unmatched ability to access asset markets, globally.

Purchasing 1/2 Ounze of Gold with Bitcoin Tangible Trust process and Counterparty community member led_cd/Global_trade Repo:

Proof of Purchase Received:
We have received and published Proof of Purchase from Agora for led_cd's gold. You may review the proof of purchase here: http://bitcointangibletrust.com/assets/

With the confirmation of Proof of Purchase, we used Counterparty send command to deliver to led_cd his new digital gold coin.
You may verify the asset detail here: http://blockscan.com/assetinfo.aspx?q=GLDAGOAAAAAAA

Why use BitcoinTangible Trust?
As we continue to work with new customers, here are some of the reasons why customers say they would like to use this service:

  • Buyers like their digital gold coins attached to their BTC address
  • Buyers want a difficult process to be made easy for purchasing precious metals fast
  • Buyers want to be anonymous and there is HUGE anonymous buyer demand
  • Buyers don't want to worry about details of precious metals storage, insurance, bonding, audits, KYC/AML etc

Thank you Counterparty Devs and the Counterparty Community.

Special thanks to Peter Todd for the congrats over the weekend.
Bitcoin Tangible Trust Team
Cross Posted to Counterparty Forums: https://forums.counterparty.co/index.php/topic,203.0.html
newbie
Activity: 28
Merit: 0
Short answer: you're assuming the data exists to validate at all client-side. Unfortunately that's not something you can assume. If you're just putting hashes of Counterparty data in the blockchain what is a client supposed to do if they can't find the corresponding data? If they assume it doesn't exist then you can be sybil attacked by someone who later reveals the data and changes the consensus out from under you. On the other hand, if you assume it must exist, and wait until you find that data, a trivial attack is to put fake hashes of alleged counterparty data in the blockchain.

You wouldn't have to solve any problem if your chain validated your transactions. You wouldn't need to bloat your chain with open orders like mastercoin and counterparty (if I understand correctly) do.
Colored coins don't put the open orders in the chain, but not all colored aspects of a colored coins transactions are validated.
If your chain validated all you need it to validate, you could even have SPV clients consuming a committed UTXO (something non-hardfork colored coins cannot give you).

I don't know mastercoin and counterparty deeply but I believe they use "accounts" (like ripple.com) instead of inputs/outputs (like bitcoin and freimarkets), which is another design mistake.

Too many efficiency sacrifices only to avoid bootstrapping your own chain like namecoin did when it wanted to support additional features.
If we all bitcoin users want to support these features in the bitcoin chain, there's a better way to do it: a hard fork.
I'm all for this features (asset issuance, p2p trade, ripple-like transitive trades, options, etc) in Bitcoin's main chain myself, but the right way.

You've also failed to read deeply into this thread. Reposting service: free, tips - welcome.

The blockchain itself would be most benefited by the use of OP_RETURN here, but it seems to me at least that there is a disconnect in the logic of why the size was halved among some, pointing to theoretical reasons as justification on why that would be a good idea instead of the *actual real world current uses*. While the optimal solution in your mind for Counterparty and others may be to move to their own side chains and store hashes in the Bitcoin blockchain using OP_RETURN, you have to understand that doing so is highly complex, rife with potential security issues, and that the only evidence supporting this is (as far as I know) essentially a theoretical-type thread on the Bitcoin developers mailing list. This would be a bit like me telling the Bitcoin devs that Bitcoin should move to using GHOST (https://eprint.iacr.org/2013/881.pdf) immediately as it's technically the optimal solution over the longer block times today. While the latter could be argued to be the case, it is a proposal that has not been fully vetted in the real world, and would introduce major protocol-level changes that could cause potential security and usability problems.
Jump to: