BitThink
Legendary
Offline
Activity: 882
Merit: 1000
|
|
December 18, 2014, 01:30:00 PM |
|
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
Legendary
Offline
Activity: 2002
Merit: 1040
|
|
December 18, 2014, 02:21:59 PM |
|
|
|
|
|
Equality 7-2521
Member
Offline
Activity: 118
Merit: 10
A difference which makes a difference
|
|
December 18, 2014, 02:59:02 PM |
|
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 (OP)
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
December 18, 2014, 03:43:26 PM |
|
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: --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
|
|
December 18, 2014, 03:51:19 PM Last edit: December 18, 2014, 04:03:30 PM by 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
Member
Offline
Activity: 118
Merit: 10
A difference which makes a difference
|
|
December 18, 2014, 10:17:17 PM |
|
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.pdfYes, 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
|
|
December 19, 2014, 04:34:18 AM |
|
|
|
|
|
getts
Newbie
Offline
Activity: 11
Merit: 0
|
|
December 19, 2014, 05:59:31 AM Last edit: December 19, 2014, 06:17:21 AM by 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
Member
Offline
Activity: 150
Merit: 29
Happy mother of 5 children
|
|
December 19, 2014, 07:34:02 AM |
|
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
Legendary
Offline
Activity: 1666
Merit: 1010
he who has the gold makes the rules
|
|
December 19, 2014, 08:17:43 AM |
|
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
|
|
December 19, 2014, 09:03:35 AM |
|
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
Legendary
Offline
Activity: 882
Merit: 1000
|
|
December 19, 2014, 09:21:40 AM |
|
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: --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
Legendary
Offline
Activity: 876
Merit: 1000
Etherscan.io
|
|
December 19, 2014, 01:34:52 PM |
|
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.
|
|
|
|
|
Anotheranonlol
|
|
December 19, 2014, 03:25:23 PM Last edit: December 19, 2014, 05:50:39 PM by Anotheranonlol |
|
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 (OP)
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
December 19, 2014, 04:14:26 PM |
|
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/Generalhttps://gitter.im/CounterpartyXCP/Technical
|
|
|
|
Anotheranonlol
|
|
December 19, 2014, 05:49:57 PM |
|
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/Generalhttps://gitter.im/CounterpartyXCP/TechnicalThanks!
|
|
|
|
|
ElTomeko27
|
|
December 20, 2014, 08:45:32 AM |
|
It's great to see how XCP devs are active.
|
|
|
|
|
|