Author

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

legendary
Activity: 1666
Merit: 1010
he who has the gold makes the rules
Surely someone here would be able to tell me if any of the developers for XCP would ever engage in "working for hire" to develop another coin, such as XPY, with the same or similar properties?  I ask this because the founders of XPY have extremely deep pockets and I can't see how or why it would be a conflict since the code is open source.  If not Counterparty developer's coding, it would sure be interesting to know what or whose coding will be utilized.

In full disclosure, I have a ladder of multiple open orders to purchase a sizable amount of XCP at a price below the current market.  This week I invested 200 btc into another coin, XPY, which is claimed to have similar capabilities of Counterparty.   http://www.coindesk.com/gaw-miners-altcoin-launch-sparks-speculative-frenzy/

I would like a candid analysis (from perhaps someone familiar with coding) that could provide the advantages of Counterparty over XPY.  Here is the source code: https://github.com/GAWMiners/paycoin  I am not sure if the "Counterparty" properties have yet been introduced into the code.   I initially got into XPY as a trade, but certainly not committed for the long term until I learn more.

I like Counterparty vs XPY in that there are far fewer coins which should bode well for long term value.  However, beyond this, I need to understand the technical advantages and or disadvantages of one over the other.  

Any input on this will be greatly appreciated and Happy Holidays!

give me 50k and I will write a candid analysis for you.

my btc address is 1GFC6Kc1UiH8m48EPCFpK7j8Cs9hbyyF55

member
Activity: 150
Merit: 29
Happy mother of 5 children
usually you apply the discount at the shopping cart stage, the price is then recalculated at checkout, could be done that way but it's a little cumbersome.

One way to implement a token-based discount is that whoever owns/holds a token gets the discount. Another way (that I had in mind) requires you to transfer it back to the store. In this case it is lot more convenient to transfer both BTC and Counterparty token in the same transaction.
theoritally it's fine to replace the antidust amount sent to the recipipient with any amount larger. However, it's not implemented in the current counterpartyd yet. Maybe later we can customize the amount of BTC we sent in xcp transactions, but I am not sure whether this is really useful.

It actually is implemented, both in the CLI and the API, at a per-transaction level:

Cool, I believe such transactions will be common in the future.

An example is Alice the Musician. She sells her mp3's for 0.05 BTC each. She realizes that she can reward fans who blog about her, write in forums, etc, by giving them a discount token, ALICECOIN. One Alicecoin is backed by a 0.01 BTC discount.

When buying with discount, the buyer transfers 0.04 BTC + 1 ALICECOIN in one transaction.

A huge advantage for Alice is that there are no direct costs with issuing the coin, but the fans who anyway would buy mp3's see a real value in it. Holders of the coin who do not want to buy her music - even with a discount - will try to sell it on the DEX. If she gives away a reasonable amount of coins the market price should be slightly less than 0.01 BTC.
newbie
Activity: 11
Merit: 0
Surely someone here would be able to tell me if any of the developers for XCP would ever engage in "working for hire" to develop another coin, such as XPY, with the same or similar properties?  I ask this because the founders of XPY have extremely deep pockets and I can't see how or why it would be a conflict since the code is open source.  If not Counterparty developer's coding, it would sure be interesting to know what or whose coding will be utilized.

In full disclosure, I have a ladder of multiple open orders to purchase a sizable amount of XCP at a price below the current market.  This week I invested 200 btc into another coin, XPY, which is claimed to have similar capabilities of Counterparty.   http://www.coindesk.com/gaw-miners-altcoin-launch-sparks-speculative-frenzy/

I would like a candid analysis (from perhaps someone familiar with coding) that could provide the advantages of Counterparty over XPY.  Here is the source code: https://github.com/GAWMiners/paycoin  I am not sure if the "Counterparty" properties have yet been introduced into the code.   I initially got into XPY as a trade, but certainly not committed for the long term until I learn more.

I like Counterparty vs XPY in that there are far fewer coins which should bode well for long term value.  However, beyond this, I need to understand the technical advantages and or disadvantages of one over the other.  

Any input on this will be greatly appreciated and Happy Holidays!
hero member
Activity: 647
Merit: 510
Counterpartying
Adam Krellenstein, Co-Founder of Counterparty, talks smart contracts, Ethereum, the SEC and the future.

https://www.youtube.com/watch?v=JxwvDZatBtc#t=23

Cliffs: https://www.youtube.com/watch?v=JxwvDZatBtc&feature=youtu.be&t=24m11s
member
Activity: 118
Merit: 10
A difference which makes a difference
One way to implement a token-based discount is that whoever owns/holds a token gets the discount. Another way (that I had in mind) requires you to transfer it back to the store. In this case it is lot more convenient to transfer both BTC and Counterparty token in the same transaction.

You're right, although not requiring the asset be sent back to the issuer would seem to be a weaker option. Asssuming ownership of the discount token is checked based on the identical address sending BTC (and the store doesn't implement any limits on validity period of the discount coupons), the owner of that address could  keep replaying the discount or proxy offering the discount service to others without the token (sort of like cardsharing in the sattelite world ), right? there would seemingly be less incentive for many people to own the discount token themselves . Agreed that it is more convenient to send both in the same tx.

 You could have a scenario where you're dealing with store value coupons rather than simply discounts. Either they permit you to buy a specific product/service at the store or they permit a certain dollar spending credit at the store/service, in that way you may never require btc at checkout time.

Does anyone have the time or skills required to follow all the burnt BTC at the 1CounterpartyXXXXXXXXXXXXXXXUWLpVr address back through the history of the blockchain to see when they were mined?

It would be nice to visualize the timespan over which the POW period of Counterparty occurred. Afterall, you can't have Proof of Burn without Proof of Work (in this case).

You mean the time the transactions in the counterparty burn were 'mined;, or the original mining of the coins that were sent to counterparty?

if the former, it was simply defined in the protocol and you can see from any block explorer- first XCP was possible to be mined from block 278310, although the first earned in mainnet was in block 278319 (http://btc.blockr.io/tx/info/685623401c3f5e9d2eaaf0657a50454e56a270ee7630d409e98d3bc257560098), last XCP was possible to burn at block 283810, and people were burning right until the end (indeed after the end too)

if you would like to trace the origin of the coins sent to take part in the PoB you can use a method like one described in the paper below

http://143.225.81.37/www.mobilab.unina.it/tesi/Giuseppe_Galano_A_Visual_Interactive_Realtime_EXplorer_for_Bitcoin.pdf


Yes, I mean the former. What is the ultimate origin of the Burnt Bitcoins? Thanks for the advice but I have not the time nor the skill to accomplish such a task. Hopefully someone else might be enticed to take it on.
hero member
Activity: 588
Merit: 504
One way to implement a token-based discount is that whoever owns/holds a token gets the discount. Another way (that I had in mind) requires you to transfer it back to the store. In this case it is lot more convenient to transfer both BTC and Counterparty token in the same transaction.

You're right, although not requiring the asset be sent back to the issuer would seem to be a weaker option. Asssuming ownership of the discount token is checked based on the identical address sending BTC (and the store doesn't implement any limits on validity period of the discount coupons), the owner of that address could  keep replaying the discount or proxy offering the discount service to others without the token (sort of like cardsharing in the sattelite world ), right? there would seemingly be less incentive for many people to own the discount token themselves . Agreed that it is more convenient to send both in the same tx.

 You could have a scenario where you're dealing with store value coupons rather than simply discounts. Either they permit you to buy a specific product/service at the store or they permit a certain dollar spending credit at the store/service, in that way you may never require btc at checkout time.

Does anyone have the time or skills required to follow all the burnt BTC at the 1CounterpartyXXXXXXXXXXXXXXXUWLpVr address back through the history of the blockchain to see when they were mined?

It would be nice to visualize the timespan over which the POW period of Counterparty occurred. Afterall, you can't have Proof of Burn without Proof of Work (in this case).

You mean the time the transactions in the counterparty burn were 'mined;, or the original mining of the coins that were sent to counterparty?

if the former, it was simply defined in the protocol and you can see from any block explorer- first XCP was possible to be mined from block 278310, although the first earned in mainnet was in block 278319 (http://btc.blockr.io/tx/info/685623401c3f5e9d2eaaf0657a50454e56a270ee7630d409e98d3bc257560098), last XCP was possible to burn at block 283810, and people were burning right until the end (indeed after the end too)

if you would like to trace the origin of the coins sent to take part in the PoB you can use a method like one described in the paper below

http://143.225.81.37/www.mobilab.unina.it/tesi/Giuseppe_Galano_A_Visual_Interactive_Realtime_EXplorer_for_Bitcoin.pdf
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
usually you apply the discount at the shopping cart stage, the price is then recalculated at checkout, could be done that way but it's a little cumbersome.

One way to implement a token-based discount is that whoever owns/holds a token gets the discount. Another way (that I had in mind) requires you to transfer it back to the store. In this case it is lot more convenient to transfer both BTC and Counterparty token in the same transaction.
theoritally it's fine to replace the antidust amount sent to the recipipient with any amount larger. However, it's not implemented in the current counterpartyd yet. Maybe later we can customize the amount of BTC we sent in xcp transactions, but I am not sure whether this is really useful.

It actually is implemented, both in the CLI and the API, at a per-transaction level:

Code:
--regular-dust-size REGULAR_DUST_SIZE
                        value for dust Pay‐to‐Pubkey‐Hash outputs, in BTC
--multisig-dust-size MULTISIG_DUST_SIZE
                        for dust OP_CHECKMULTISIG outputs, in BTC

It's useful if you're making a *lot* of (similar) transactions, and want to lower your costs as much as possible. The default fee and dust values are very generous, because they have to work well in all circumstances.
member
Activity: 118
Merit: 10
A difference which makes a difference
Does anyone have the time or skills required to follow all the burnt BTC at the 1CounterpartyXXXXXXXXXXXXXXXUWLpVr address back through the history of the blockchain to see when they were mined?

It would be nice to visualize the timespan over which the POW period of Counterparty occurred. Afterall, you can't have Proof of Burn without Proof of Work (in this case).
legendary
Activity: 882
Merit: 1000
usually you apply the discount at the shopping cart stage, the price is then recalculated at checkout, could be done that way but it's a little cumbersome.

One way to implement a token-based discount is that whoever owns/holds a token gets the discount. Another way (that I had in mind) requires you to transfer it back to the store. In this case it is lot more convenient to transfer both BTC and Counterparty token in the same transaction.
theoritally it's fine to replace the antidust amount sent to the recipipient with any amount larger. However, it's not implemented in the current counterpartyd yet. Maybe later we can customize the amount of BTC we sent in xcp transactions, but I am not sure whether this is really useful.
member
Activity: 150
Merit: 29
Happy mother of 5 children
usually you apply the discount at the shopping cart stage, the price is then recalculated at checkout, could be done that way but it's a little cumbersome.

One way to implement a token-based discount is that whoever owns/holds a token gets the discount. Another way (that I had in mind) requires you to transfer it back to the store. In this case it is lot more convenient to transfer both BTC and Counterparty token in the same transaction.
hero member
Activity: 588
Merit: 504
Not sure if this any of these have been posted before, I had just noticed them browsing github

Auction platform that works with counterparty assets:

Smart Contracting As A Service platform (alpha stage):

Ruby gem for communicating with a Counterparty (Bitcoin / XCP) API server:

When you transfer a Counterparty Asset, you send a dust-amount of BTC as well.

Is it possible to transfer any amount (>= dust limit) of BTC in a Counterparty transaction?

For example, an electronics store sells a TV for 1 BTC. However, if you have a discount token, you'll get the TV for 0.9 BTC + 1 discount token. Can the 0.9 BTC + token be transferred in one transaction?

usually you apply the discount at the shopping cart stage, the price is then recalculated at checkout, could be done that way but it's a little cumbersome. (Especially if the user doesn't pay in the end) I think it is possible though. see: https://wiki.counterparty.io/w/Sendmany
Maybe there has been some newer developments on that front though or a more appropriate way
member
Activity: 150
Merit: 29
Happy mother of 5 children
When you transfer a Counterparty Asset, you send a dust-amount of BTC as well.

Is it possible to transfer any amount (>= dust limit) of BTC in a Counterparty transaction?

For example, an electronics store sells a TV for 1 BTC. However, if you have a discount token, you'll get the TV for 0.9 BTC + 1 discount token. Can the 0.9 BTC + token be transferred in one transaction?
hero member
Activity: 588
Merit: 504
I like this idea but the guarantor role is problematic since you are still centralizing an important function. Look at what happened with Mintpal recently, which was I think one of the more respected exchanges. Anyone using the fiat tokens still runs the risk of the guarantor going bust.

I've been thinking a lot about how you could demonstrate that the guarantor keeps the cash on hand but it is a harder problem than it seems. Insurance would be prohibitively expensive, you could keep the cash reserves at a bank but again there is the issue of providing what you are holding at any given moment. Also if the guarantor has access to the bank accounts there is always a chance of malfeasance. Don’t get me wrong, I like the idea and I’m sure it can be implemented at some point but it is hard to come up with a business model that makes sense and could work.  


Exchanges can give you API's to display the funds stored on the account, they can also give you API to generate vouchers, I suppose someone could generate 1000 $1 vouchers or store 1000$ in their accountt and lock an asset on CounterParty to 1000 units with each unit representing a dollar and also demonstrate they control the exchange account storing the fiat. they could create an external portal where users send one of those $1 tokens back to themselves (the issuer) when they wished to cash out and $1 would be sent to their exchange account. Assuming the issuer had some sort of trust- perhaps an established WoT rating and the buyers also had enough confidence in the exchange to not go dark one day... Obviously that would be a really amateurish roundabout method. The only advantage their really would be ability to trade fiat-backed tokens in small batches on the dex rather than on centralised exchanges. Definitaly not suitable for anything bigger than a really small scale deployment

As an aside, anyone out there who could create a simple early temple - (https://earlytemple.com:8181/) style contracting scheme on CounterParty
Please PM .




legendary
Activity: 1666
Merit: 1010
he who has the gold makes the rules
Just checked out http://pay.blockscan.com/

Amazing work, mtbitcoin! Even in tech preview stage it's looking extremely polished.

It seems something like this makes it possible for any entity who decides to act as their own voucher issuer on the CounterParty network, (offering discounts/coupons or memberships) a very low barrier to entry to accepting those vouchers on their sites. They can also be trustlessly traded amongst users via the decentralised exchange without risk of hacks/forgery. Just a coupon marketplace alone could be a big thing, Gyft was fairly recently acquired for just shy of $100 million

If only an exchange would step up to vend fiat -> fiat represented CounterParty asset in a guarantor role, then you could store (and trade) USD, EUR, GBP, CNY etc on the CounterParty network, similar to ripple gateways, navigate to a site and pay out in the fiat currency with the payment invoice, all whilst retaining ownership of your own private keys and without being exposed to the volatility of BTC. Seems like the technology is in place but the regulatory work is the real headache.. massive potential with this technology though  Smiley



I like this idea but the guarantor role is problematic since you are still centralizing an important function. Look at what happened with Mintpal recently, which was I think one of the more respected exchanges. Anyone using the fiat tokens still runs the risk of the guarantor going bust.

I've been thinking a lot about how you could demonstrate that the guarantor keeps the cash on hand but it is a harder problem than it seems. Insurance would be prohibitively expensive, you could keep the cash reserves at a bank but again there is the issue of providing what you are holding at any given moment. Also if the guarantor has access to the bank accounts there is always a chance of malfeasance. Don’t get me wrong, I like the idea and I’m sure it can be implemented at some point but it is hard to come up with a business model that makes sense and could work.  


forget about fiat... i only use it because i can't buy food with bitcoins or some other crypto just yet.

full member
Activity: 121
Merit: 100
Counterparty General Manager
Any chance you could add paypal as a membership fee payment option?

Yes, if there's a need I don't see why not.
full member
Activity: 121
Merit: 100
Counterparty General Manager
Hi all, two new posts from Counterparty:
Counterparty Community Update, Dec 17: Improved Release Process, Foundation News & More - http://counterparty.io/news/counterparty-community-update-dec-17/
Notes From The First Counterparty Foundation Board Meeting: http://counterpartyfoundation.org/notes-from-the-first-counterparty-foundation-board-meeting/
hero member
Activity: 703
Merit: 500
anywhere to trade asset name in XCP?
I have some assets.
hero member
Activity: 703
Merit: 500
hero member
Activity: 588
Merit: 504
Just checked out http://pay.blockscan.com/

Amazing work, mtbitcoin! Even in tech preview stage it's looking extremely polished.

It seems something like this makes it possible for any entity who decides to act as their own voucher issuer on the CounterParty network, (offering discounts/coupons or memberships) a very low barrier to entry to accepting those vouchers on their sites. They can also be trustlessly traded amongst users via the decentralised exchange without risk of hacks/forgery. Just a coupon marketplace alone could be a big thing, Gyft was fairly recently acquired for just shy of $100 million

If only an exchange would step up to vend fiat -> fiat represented CounterParty asset in a guarantor role, then you could store (and trade) USD, EUR, GBP, CNY etc on the CounterParty network, similar to ripple gateways, navigate to a site and pay out in the fiat currency with the payment invoice, all whilst retaining ownership of your own private keys and without being exposed to the volatility of BTC. Seems like the technology is in place but the regulatory work is the real headache.. massive potential with this technology though  Smiley

Jump to: