JahPowerBit, developer of BootleXCP and pyrpcwallet, will join Counterparty full-time.
https://www.counterparty.co/fulltime-developer-counterparty/
Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 360. (Read 1277015 times)
March 24, 2014, 12:06:18 PM
March 24, 2014, 11:35:25 AM
Whitelisting particular upper layer protocols is ridiculous. Bitcoin should be a proper protocol, not a committee run closed network that you need to file an application with to get access to. Bitcoin the protocol should be absolutely neutral, and no group of developers, no matter how important and respected, should be in a position to determine which transaction types are permitted.
The real problem here is that Bitcoin is still unfinished, and needs to change, and the only way that we know of to change a protocol is to centralize around a group of developers, who can make serious mistakes like backtracking on their stated intention to standardize 80 byte OP_RETURN transactions.
Until we find a solution to this problem of centralized development, we need to do whatever we can to steer the core developers to supporting upper layer protocols like Counterparty and Mastercoin. ULPs are the future of Bitcoin. The greatest potential of bitcoin, as a unit of currency, is to be the currency used to pay transaction fees for the world's peer-to-peer digital transactions, and that can only happen if ULPs are built on top of BTC.
The real problem here is that Bitcoin is still unfinished, and needs to change, and the only way that we know of to change a protocol is to centralize around a group of developers, who can make serious mistakes like backtracking on their stated intention to standardize 80 byte OP_RETURN transactions.
Until we find a solution to this problem of centralized development, we need to do whatever we can to steer the core developers to supporting upper layer protocols like Counterparty and Mastercoin. ULPs are the future of Bitcoin. The greatest potential of bitcoin, as a unit of currency, is to be the currency used to pay transaction fees for the world's peer-to-peer digital transactions, and that can only happen if ULPs are built on top of BTC.
Absolutely agree. Great post. Let's hope they listen to the community on this one.
March 24, 2014, 11:32:20 AM
If we could get, just even 1 greedy guinea pig less posting here, then, this is totally founded.
You either support your investment, like you are doing, or you should just keep quiet. Having his ass between 2 chairs is just a terrible situation, we don't need to know in this thread about the greedy guinea pigs' dilemma and / or lacusek of grey cells.
You either support your investment, like you are doing, or you should just keep quiet. Having his ass between 2 chairs is just a terrible situation, we don't need to know in this thread about the greedy guinea pigs' dilemma and / or lacusek of grey cells.
If you're going to troll you should at least do it in such a way that people don't know who you are - and if they don't already, I for one, have few qualms about making it known.
Who is he? she?
Nice Try.
March 24, 2014, 11:15:37 AM
If we could get, just even 1 greedy guinea pig less posting here, then, this is totally founded.
You either support your investment, like you are doing, or you should just keep quiet. Having his ass between 2 chairs is just a terrible situation, we don't need to know in this thread about the greedy guinea pigs' dilemma and / or lacusek of grey cells.
You either support your investment, like you are doing, or you should just keep quiet. Having his ass between 2 chairs is just a terrible situation, we don't need to know in this thread about the greedy guinea pigs' dilemma and / or lacusek of grey cells.
If you're going to troll you should at least do it in such a way that people don't know who you are - and if they don't already, I for one, have few qualms about making it known.
Who is he? she?
March 24, 2014, 10:49:48 AM
If we could get, just even 1 greedy guinea pig less posting here, then, this is totally founded.
You either support your investment, like you are doing, or you should just keep quiet. Having his ass between 2 chairs is just a terrible situation, we don't need to know in this thread about the greedy guinea pigs' dilemma and / or lacusek of grey cells.
You either support your investment, like you are doing, or you should just keep quiet. Having his ass between 2 chairs is just a terrible situation, we don't need to know in this thread about the greedy guinea pigs' dilemma and / or lacusek of grey cells.
If you're going to troll you should at least do it in such a way that people don't know who you are - and if they don't already, I for one, have few qualms about making it known.
March 24, 2014, 08:38:02 AM
Hey guys,
so to my understanding the reason for the idea of making multisig transactions non-standard was the high amount of unspent outputs that were created by data-storage transactions. I want to put this into some perspective:
(https://i.imgur.com/c9mpd8h.png)
I did not evaluate how many unspent outputs were created by all multisig outputs, because I'm unable to do so efficiently, but here are some observations nevertheless:
Out of 35.508.561 multisig outputs ever seen on the blockchain XCP and MSC account for 5.192 multisig outputs. That's about 0.000146 %.
Out of 9.819.223 unspent outputs at the very moment (RPC: gettxoutsetinfo) the amount of unspent XCP and MSC multisig outputs is 3.226. That's about 0.000329 %.
In the case one wants to run some tests on this data: multisig-usage.rar (format: "txid vout rawtxhex" -- file size is about 8 MB, but be aware that multisig-all-full.txt is over 1.4 GB unpacked!)
Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead.
so to my understanding the reason for the idea of making multisig transactions non-standard was the high amount of unspent outputs that were created by data-storage transactions. I want to put this into some perspective:
(https://i.imgur.com/c9mpd8h.png)
I did not evaluate how many unspent outputs were created by all multisig outputs, because I'm unable to do so efficiently, but here are some observations nevertheless:
Out of 35.508.561 multisig outputs ever seen on the blockchain XCP and MSC account for 5.192 multisig outputs. That's about 0.000146 %.
Out of 9.819.223 unspent outputs at the very moment (RPC: gettxoutsetinfo) the amount of unspent XCP and MSC multisig outputs is 3.226. That's about 0.000329 %.
In the case one wants to run some tests on this data: multisig-usage.rar (format: "txid vout rawtxhex" -- file size is about 8 MB, but be aware that multisig-all-full.txt is over 1.4 GB unpacked!)
Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead.
Thank you for the intelligent analysis dexX7. The numbers are pretty stark when you "see" them.
March 24, 2014, 07:57:12 AM
Great Job Canton on the XCP paper wallet design and halfcab123 on the video. Will be keeping track of the progress of both.
+1. It's great to see these things coming together. This kind of community initiative is what will separate Counterparty from other projects.
March 24, 2014, 07:49:26 AM
Great Job Canton on the XCP paper wallet design and halfcab123 on the video. Will be keeping track of the progress of both.
March 24, 2014, 07:26:46 AM
@LED_LCD, @CityGlut @Community
Video Update: Things are going well!
Video Update: Things are going well!
Looking very professional!
+1000 and 1 thank you
March 24, 2014, 07:19:12 AM
@LED_LCD, @CityGlut @Community
Video Update: Things are going well!
Video Update: Things are going well!
Looking very professional!
March 24, 2014, 07:00:43 AM
@LED_LCD, @CityGlut @Community
Video Update: Things are going well!
(James) @LED_LCD, was kind enough to converse with me and bounce some ideas between us, as well as give me a very in-depth look at the technical side of Counterparty and what it's strengths are. Special Thanks to James for an hour long Skype call!
Got all the storyboarding done on Saturday, and was able to film all evening and all morning until sunrise on Sunday-Monday (early morning). We have tons of great shots for A Roll and B Roll, will be collecting 1080p filler shots today and tomorrow, getting some screen capture video of Counterwallet, as well as matching up alternate angles and mic audio, pruning some things in post production and should have a finished product by Thursday, but Sunday evening at the very latest. Thanks to everyone who gave us support!
The grand plan is to maintain a Youtube Channel, followed by a blog, and expand this initiative into a full-blown marketing campaign. Oh and TheMightyX, don't worry this isn't "boring" interview style, I definitely heeded your suggestion and you'll see! Plus, if you are worried about the style of commercial. We will be making different types! Possibilities endless!
Video Update: Things are going well!
(James) @LED_LCD, was kind enough to converse with me and bounce some ideas between us, as well as give me a very in-depth look at the technical side of Counterparty and what it's strengths are. Special Thanks to James for an hour long Skype call!
Got all the storyboarding done on Saturday, and was able to film all evening and all morning until sunrise on Sunday-Monday (early morning). We have tons of great shots for A Roll and B Roll, will be collecting 1080p filler shots today and tomorrow, getting some screen capture video of Counterwallet, as well as matching up alternate angles and mic audio, pruning some things in post production and should have a finished product by Thursday, but Sunday evening at the very latest. Thanks to everyone who gave us support!
The grand plan is to maintain a Youtube Channel, followed by a blog, and expand this initiative into a full-blown marketing campaign.
Oh and TheMightyX, don't worry this isn't "boring" interview style, I definitely heeded your suggestion and you'll see! Plus, if you are worried about the style of commercial. We will be making different types! Possibilities endless! March 24, 2014, 06:00:06 AM
Hopefully Ether or whatever will [...] control their community
?! March 24, 2014, 05:57:28 AM
It is probabaly not necessary to move away from Bitcoin. But...
I agree with the benefits in XCP value increase due to differerentiating our project from others. Moving to a POS chain could help to form a unique value propostition and set us apart from Mastercoin, Cromawallet, (Opentransactions).
And as far as I understand it POS would enhance the security by making it vastly independent from the network hash rate.
I agree with the benefits in XCP value increase due to differerentiating our project from others. Moving to a POS chain could help to form a unique value propostition and set us apart from Mastercoin, Cromawallet, (Opentransactions).
And as far as I understand it POS would enhance the security by making it vastly independent from the network hash rate.
March 24, 2014, 05:49:46 AM
Even with multisig neither Counterparty or Mastecoin need to be contributing to the UTXO set: just have one of the pubkeys be valid, with a secret key known to the user, and have their wallet software spend that txout the next time it needs to spend some money.
Well yes. That's why I don't understand the "utxo bloat" argument - at least not completely. Assuming each multisig recipient is counted as utxo and say for each redeemed XCP/MSC transaction a new one is spawned, then one could say the total amount of utxo is indeed increased due to the one or two additional multisig recipients. But a) is this the case? (I assume yes) and b) is this the case, if pubkeys are created in a way that they do not form a valid ECDSA point? Anything with a length between 33 and 65 byte seems to be accepted as recipient.
Redeeming multisig outputs is fun, by the way!
If you don't get it completely, like 99% of the people on this thread, just let the big boys discuss about it, and keep it quiet instead of adding your uneducated 2 cents. Anyone else than PP, Xnova discussing with the core devs is just noise and adding more crap to the already existing confusion.
You are very precious, aren't you? Why are you even here? I thought you had dumped all and went to get some Ether.
Having 200 non technical people trying to protect their 2 burnt BTC insulting the BTC devs and adding their irrelevant 2 cents is the way to go, definitely.
Back to reality, no one from the core devs has been consulted, and they can get rid of the 'XCP parasite' in one commit if they want.
It was an interesting project, with talented devs, but the greed and overall retardness of the so called 'community' on top of the terrible lack of communication in general was the last nail in the coffin.
Time to dump until the news spreads, and move to something else. Thanks for the five folds profit. Hopefully Ether or whatever will make things right, control their community, and have a clear communication with all people involved.
Back to reality, no one from the core devs has been consulted, and they can get rid of the 'XCP parasite' in one commit if they want.
It was an interesting project, with talented devs, but the greed and overall retardness of the so called 'community' on top of the terrible lack of communication in general was the last nail in the coffin.
Time to dump until the news spreads, and move to something else. Thanks for the five folds profit. Hopefully Ether or whatever will make things right, control their community, and have a clear communication with all people involved.
March 24, 2014, 05:29:56 AM
Whitelisting particular upper layer protocols is ridiculous. Bitcoin should be a proper protocol, not a committee run closed network that you need to file an application with to get access to. Bitcoin the protocol should be absolutely neutral, and no group of developers, no matter how important and respected, should be in a position to determine which transaction types are permitted.
The real problem here is that Bitcoin is still unfinished, and needs to change, and the only way that we know of to change a protocol is to centralize around a group of developers, who can make serious mistakes like backtracking on their stated intention to standardize 80 byte OP_RETURN transactions.
Until we find a solution to this problem of centralized development, we need to do whatever we can to steer the core developers to supporting upper layer protocols like Counterparty and Mastercoin. ULPs are the future of Bitcoin. The greatest potential of bitcoin, as a unit of currency, is to be the currency used to pay transaction fees for the world's peer-to-peer digital transactions, and that can only happen if ULPs are built on top of BTC.
The real problem here is that Bitcoin is still unfinished, and needs to change, and the only way that we know of to change a protocol is to centralize around a group of developers, who can make serious mistakes like backtracking on their stated intention to standardize 80 byte OP_RETURN transactions.
Until we find a solution to this problem of centralized development, we need to do whatever we can to steer the core developers to supporting upper layer protocols like Counterparty and Mastercoin. ULPs are the future of Bitcoin. The greatest potential of bitcoin, as a unit of currency, is to be the currency used to pay transaction fees for the world's peer-to-peer digital transactions, and that can only happen if ULPs are built on top of BTC.
March 24, 2014, 04:21:29 AM
Even with multisig neither Counterparty or Mastecoin need to be contributing to the UTXO set: just have one of the pubkeys be valid, with a secret key known to the user, and have their wallet software spend that txout the next time it needs to spend some money.
Well yes. That's why I don't understand the "utxo bloat" argument - at least not completely. Assuming each multisig recipient is counted as utxo and say for each redeemed XCP/MSC transaction a new one is spawned, then one could say the total amount of utxo is indeed increased due to the one or two additional multisig recipients. But a) is this the case? (I assume yes) and b) is this the case, if pubkeys are created in a way that they do not form a valid ECDSA point? Anything with a length between 33 and 65 byte seems to be accepted as recipient.
Redeeming multisig outputs is fun, by the way!
March 24, 2014, 03:55:06 AM
Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead.
Even with multisig neither Counterparty or Mastecoin need to be contributing to the UTXO set: just have one of the pubkeys be valid, with a secret key known to the user, and have their wallet software spend that txout the next time it needs to spend some money.
You're transactions will be cheaper overall too. Again, this is another reason why you want to do an arbitrary encoding strategy. I'm rather solidly booked for the next two weeks, but we can talk about implementing that later as an upgrade.
March 24, 2014, 03:34:20 AM
Hey guys,
so to my understanding the reason for the idea of making multisig transactions non-standard was the high amount of unspent outputs that were created by data-storage transactions. I want to put this into some perspective:
(https://i.imgur.com/c9mpd8h.png)
I did not evaluate how many unspent outputs were created by all multisig outputs, because I'm unable to do so efficiently, but here are some observations nevertheless:
Out of 35.508.561 multisig outputs ever seen on the blockchain XCP and MSC account for 5.192 multisig outputs. That's about 0.000146 %.
Out of 9.819.223 unspent outputs at the very moment (RPC: gettxoutsetinfo) the amount of unspent XCP and MSC multisig outputs is 3.226. That's about 0.000329 %.
In the case one wants to run some tests on this data: multisig-usage.rar (format: "txid vout rawtxhex" -- file size is about 8 MB, but be aware that multisig-all-full.txt is over 1.4 GB unpacked!)
Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead.
so to my understanding the reason for the idea of making multisig transactions non-standard was the high amount of unspent outputs that were created by data-storage transactions. I want to put this into some perspective:
(https://i.imgur.com/c9mpd8h.png)
I did not evaluate how many unspent outputs were created by all multisig outputs, because I'm unable to do so efficiently, but here are some observations nevertheless:
Out of 35.508.561 multisig outputs ever seen on the blockchain XCP and MSC account for 5.192 multisig outputs. That's about 0.000146 %.
Out of 9.819.223 unspent outputs at the very moment (RPC: gettxoutsetinfo) the amount of unspent XCP and MSC multisig outputs is 3.226. That's about 0.000329 %.
In the case one wants to run some tests on this data: multisig-usage.rar (format: "txid vout rawtxhex" -- file size is about 8 MB, but be aware that multisig-all-full.txt is over 1.4 GB unpacked!)
Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead.
March 24, 2014, 03:20:01 AM
About the OP_RETURN 40 vs 80. Pardon me if this proposal is noobish, but what about using 2 (or more) parallel transactions (broadcasted at the same time) each within the current 40 limit with different payloads. Then the CP parser would combine them afterwards.
Double the transactions fees ? No guarantee they are confirmed at the same time or even the same block ?
March 24, 2014, 03:18:32 AM
About the OP_RETURN 40 vs 80. Pardon me if this proposal is noobish, but what about using 2 (or more) parallel transactions (broadcasted at the same time) each within the current 40 limit with different payloads. Then the CP parser would combine them afterwards.
Jump to: