[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[BitThink]

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.

[ssmc2]

https://www.cryptocoinsnews.com/gems-cryptocurrency-social-network-utilize-telegram-messaging-app-android/

Gems to integrate with Telegram messenger. Cool stuff. 

[Equality 7-2521]

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).

[PhantomPhreak]

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.

[Anotheranonlol]

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

[Equality 7-2521]

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.

[Matt Y]

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

[getts]

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!

[Jpja]

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.

[prophetx]

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

[ElTomeko27]

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!

Heh if You invested 200 btc into XPY...I wish You good luck

[BitThink]

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.

Oops, sorry about my mistake. I see now, these parameters are provided for users to lower the fees in the first place, but certainly can be used to increase the amount so that BTC transfer and counterparty transfer can live together in one transaction. Great.

[mtbitcoin]

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.

I find the proposal very interesting and it definitely adds to the list of another use case for tokens.

[pankogulo]

Counterparty Development Update #7: Improved Release Process, New Counterparty WIki & More http://counterparty.io/news/counterparty-development-update-7/

[Anotheranonlol]

Counterparty Development Update #7: Improved Release Process, New Counterparty WIki & More http://counterparty.io/news/counterparty-development-update-7/

Nice update. I wouldn't mind taking some time to try and contribute to the new wiki

on that note, has CounterParty got a community or dev chat slick/hipchat etc? I can see old references to a skype group but no idea how to get to it, irc seems pretty dead and they both seem like shitty ways to do group collab

[PhantomPhreak]

Counterparty Development Update #7: Improved Release Process, New Counterparty WIki & More http://counterparty.io/news/counterparty-development-update-7/

Thanks for the update. I wouldn't mind taking some time to try and contribute to the new wiki

on that note, has CounterParty got a community or dev chat slick/hipchat etc? I can see old references to a skype group but no idea how to get to it, irc seems pretty dead and they both seem like shitty ways to do group collab

People have been using Skype, but I've just created two Gitter rooms for people to use:

https://gitter.im/CounterpartyXCP/General
https://gitter.im/CounterpartyXCP/Technical

[Anotheranonlol]

Counterparty Development Update #7: Improved Release Process, New Counterparty WIki & More http://counterparty.io/news/counterparty-development-update-7/

Thanks for the update. I wouldn't mind taking some time to try and contribute to the new wiki

on that note, has CounterParty got a community or dev chat slick/hipchat etc? I can see old references to a skype group but no idea how to get to it, irc seems pretty dead and they both seem like shitty ways to do group collab

People have been using Skype, but I've just created two Gitter rooms for people to use:

https://gitter.im/CounterpartyXCP/General
https://gitter.im/CounterpartyXCP/Technical

Thanks!

[pankogulo]

New counterpartyd Release: v9.49.2 (non-mandatory). Release Notes at https://github.com/CounterpartyXCP/counterpartyd/releases

[ElTomeko27]

It's great to see how XCP devs are active.

[Anotheranonlol]

Interesting reading below re: Reddit notes

https://twitter.com/ryanxcharles/status/546030260685254656
http://www.reddit.com/r/redditnotes/comments/2pqp2o/post_all_of_your_reddit_notes_questions_here/cn011ei?context=3
http://www.reddit.com/r/SubredditDrama/comments/2ptevw/reddit_announces_reddit_notes_gives_very_little/cn00cnr?context=3
http://www.reddit.com/r/Bitcoin/comments/2pt4kl/reddit_announces_reddit_notes_aka_reddit_bitcoin/cmzv4na?context=3

I was curious about what exactly "Counterparty is awesome and is the right tool for a lot of projects, but there are a few reasons that make it less than ideal for reddit.. " entailed (technically speaking, CounterParty seemed to be a decent fit for such a deployment, and is pretty mature as far as these things go) The rationale seemingly boils down to 'purist' ideological biases moreso than specific technical concerns

http://www.reddit.com/r/blog/comments/2owj55/welcome_drew_ryan_mike_daniel_joe_dave_david/cmrzqtu?context=3

Regardless It's exciting to see larger entities recognising the possibility of low friction, open blockchain based asset ownership tech