Topic: [neㄘcash, ᨇcash, net⚷eys, or viᖚes?] Name AnonyMint's vapor coin? - page 24. (Read 95279 times)
January 22, 2016, 08:20:08 PM
Now you really got my curiosity peaked, what in the world are you talking about Shelby the third??
January 22, 2016, 08:16:06 PM
Your point being?
...
I see that one flew right over your head.
Chess my polish. Chess.
January 22, 2016, 08:15:06 PM
Your point being?
January 22, 2016, 08:13:22 PM
Meta-data:
Wojtek Palczynski CISSP, CRISC, CISA, CGEIT, CISM
Cyber Security Consultant - Governance, Risk Management, Compliance
Toronto, Canada Area
Computer & Network Security
Current
Safe IT Inc.,
Independent
Previous
Sentry Metrics,
ERE Information Security
Education
ISACA
Recommendations 5 people have recommended Wojtek Palczynski
Websites
isc2
ISACA
Summary
I have over 12 years of experience and proven success in Enterprise Threat and Risk Management, Audit, Gap Analysis, Project Management, IT Security Governance and Compliance Reporting. I currently hold the CISSP, CRISC, CGEIT and CISA designations.
With over 12 years of experience in diverse environments such as mining and metals, telecom, capital markets, banking, government and high technology development I have worked in roles ranging from Risk Adviser, managing global SIEM deployments, operations and business management to systems and network architecture design as well as auditing, IT governance and compliance reporting.
I focus on delivering IT security solutions in the realms of SIEM (Security Information and Event Management), Governance, Compliance and Auditing for a diverse range of clients and industries. I have a track record of success in delivering projects on time and budget working on both domestic and international enterprise-class projects.
Specialties: Governance, Risk Management and Compliance Reporting, eDiscovery, Gap Analysis, Penetration Testing and Vulnerability Assessments.
Forensic and IT Control Audits measuring control effectiveness and compliance against the ISO 27001, 27002 and NERC CIP standards, COBIT framework and industry best practices.
Mergers and Acquisitions.
Experience
Cyber Security Consultant - Governance, Risk Management, Compliance Reporting
Safe IT Inc.
January 2003 – Present (13 years 1 month)
Recent Achievements
• Developed a Information Security Merger and Acquisition (M&A) Handbook for one of Canada`s leading Banks. Deliverables included a framework for the initial Due Diligence assessment of potential targets as well as Deep Dive examination of the targets Information Security governance program.
• Performed all Threat Risk Assessments in support of a $300 million acquisition of a large American wealth management institution by one of Canada's leading Banks.
• Global deployment of Log Logic Log Management System (LMS) and integration with Security Information and Event Management System (SIEM) for one of Canada's leading Banks.
• Conducted Maturity Assessments of Key Technology Controls at a major Canadian Banking Institution.
• Managed a global SIEM deployment project which helped implement Governance on a $1.2 Billion contract for a world’s leading Mining Corporation.
• Performed Enterprise Information Security compliance assessments against industry standards such as ISO 27001, ISO 27002, NERC CIP and COBIT, provided recommendations to mitigate the identified control gaps.
• Conducted vulnerability assessments of IT systems using a broad range of tools and technologies, created comprehensive reports based on the results for clients which included recommendations to remediate the vulnerabilities, resulting in proactive improvement of clients network security posture.
Blockchain / Cryptocurrency Technology Consultant
Independent
October 2013 – Present (2 years 4 months)
• Blockchain technology strategy consulting.
• Architectural advice for Blockchain projects.
• Merchant cryptocurrency payment system integration.
• Secure Offline cryptocurrency storage solutions including multi-signature ‘deep freeze’ storage.
• Custom, scalable cryptocurrency mining solutions (SHA-256, Scrypt, Scrypt-N).
• Security / Risk assessments and audits.
• Blockchain investigations.
• Non-technical "Bitcoin 101" style talks to various industries including legal, accounting, financial.
Sentry Metrics
Senior Security Auditor
Sentry Metrics
2005 – 2007 (2 years)
Senior Security Auditor
ERE Information Security
2005 – 2007 (2 years)
Organizations
ISACA - Information Systems Audit and Control Association
Certifications
CISSP Certification (Certified Information System Security Professional)
ISC2
CRISC Certification (Certified in Risk and Information Systems Control)
Information Systems Audit and Control Association (ISACA)
CISA Certification (Certified Information Systems Auditor)
Information Systems Audit and Control Association (ISACA)
CGEIT Certification (Certified in the Governance of Enterprise IT)
Information Systems Audit and Control Association (ISACA)
CISM Certification (Certified Information Security Manager)
Information Systems Audit and Control Association (ISACA)
October 2014 – Present
Education
ISACA
CGEIT
2011 – 2012
ISACA
CRISC
2011 – 2011
ISACA
CISA
2011 – 2011
ISC2
CISSP
2005 – 2005
Mohawk College
Mohawk College
Advanced Network Security and Connectivity, Information Technology
2001 – 2003
Languages
English
Native or bilingual proficiency
Polish
Native or bilingual proficiency
Quote from: http://ca.linkedin.com/in/safeit/
Wojtek Palczynski CISSP, CRISC, CISA, CGEIT, CISM
Cyber Security Consultant - Governance, Risk Management, Compliance
Toronto, Canada Area
Computer & Network Security
Current
Safe IT Inc.,
Independent
Previous
Sentry Metrics,
ERE Information Security
Education
ISACA
Recommendations 5 people have recommended Wojtek Palczynski
Websites
isc2
ISACA
Summary
I have over 12 years of experience and proven success in Enterprise Threat and Risk Management, Audit, Gap Analysis, Project Management, IT Security Governance and Compliance Reporting. I currently hold the CISSP, CRISC, CGEIT and CISA designations.
With over 12 years of experience in diverse environments such as mining and metals, telecom, capital markets, banking, government and high technology development I have worked in roles ranging from Risk Adviser, managing global SIEM deployments, operations and business management to systems and network architecture design as well as auditing, IT governance and compliance reporting.
I focus on delivering IT security solutions in the realms of SIEM (Security Information and Event Management), Governance, Compliance and Auditing for a diverse range of clients and industries. I have a track record of success in delivering projects on time and budget working on both domestic and international enterprise-class projects.
Specialties: Governance, Risk Management and Compliance Reporting, eDiscovery, Gap Analysis, Penetration Testing and Vulnerability Assessments.
Forensic and IT Control Audits measuring control effectiveness and compliance against the ISO 27001, 27002 and NERC CIP standards, COBIT framework and industry best practices.
Mergers and Acquisitions.
Experience
Cyber Security Consultant - Governance, Risk Management, Compliance Reporting
Safe IT Inc.
January 2003 – Present (13 years 1 month)
Recent Achievements
• Developed a Information Security Merger and Acquisition (M&A) Handbook for one of Canada`s leading Banks. Deliverables included a framework for the initial Due Diligence assessment of potential targets as well as Deep Dive examination of the targets Information Security governance program.
• Performed all Threat Risk Assessments in support of a $300 million acquisition of a large American wealth management institution by one of Canada's leading Banks.
• Global deployment of Log Logic Log Management System (LMS) and integration with Security Information and Event Management System (SIEM) for one of Canada's leading Banks.
• Conducted Maturity Assessments of Key Technology Controls at a major Canadian Banking Institution.
• Managed a global SIEM deployment project which helped implement Governance on a $1.2 Billion contract for a world’s leading Mining Corporation.
• Performed Enterprise Information Security compliance assessments against industry standards such as ISO 27001, ISO 27002, NERC CIP and COBIT, provided recommendations to mitigate the identified control gaps.
• Conducted vulnerability assessments of IT systems using a broad range of tools and technologies, created comprehensive reports based on the results for clients which included recommendations to remediate the vulnerabilities, resulting in proactive improvement of clients network security posture.
Blockchain / Cryptocurrency Technology Consultant
Independent
October 2013 – Present (2 years 4 months)
• Blockchain technology strategy consulting.
• Architectural advice for Blockchain projects.
• Merchant cryptocurrency payment system integration.
• Secure Offline cryptocurrency storage solutions including multi-signature ‘deep freeze’ storage.
• Custom, scalable cryptocurrency mining solutions (SHA-256, Scrypt, Scrypt-N).
• Security / Risk assessments and audits.
• Blockchain investigations.
• Non-technical "Bitcoin 101" style talks to various industries including legal, accounting, financial.
Sentry Metrics
Senior Security Auditor
Sentry Metrics
2005 – 2007 (2 years)
Senior Security Auditor
ERE Information Security
2005 – 2007 (2 years)
Organizations
ISACA - Information Systems Audit and Control Association
Certifications
CISSP Certification (Certified Information System Security Professional)
ISC2
CRISC Certification (Certified in Risk and Information Systems Control)
Information Systems Audit and Control Association (ISACA)
CISA Certification (Certified Information Systems Auditor)
Information Systems Audit and Control Association (ISACA)
CGEIT Certification (Certified in the Governance of Enterprise IT)
Information Systems Audit and Control Association (ISACA)
CISM Certification (Certified Information Security Manager)
Information Systems Audit and Control Association (ISACA)
October 2014 – Present
Education
ISACA
CGEIT
2011 – 2012
ISACA
CRISC
2011 – 2011
ISACA
CISA
2011 – 2011
ISC2
CISSP
2005 – 2005
Mohawk College
Mohawk College
Advanced Network Security and Connectivity, Information Technology
2001 – 2003
Languages
English
Native or bilingual proficiency
Polish
Native or bilingual proficiency
January 22, 2016, 08:02:52 PM
Your problem is that you constantly conflate your conjecture with reality and state it as fact.
As I did in 2013 eh:
I finally had a spare moment to contemplate the variables.
A key factor is the block size. If the block size is unlimited (and bandwidth is an insignificant cost), then unless miners have a monopoly they will accept transactions with fees as low as don't constitute a DoS attack, in order to maximize revenue.
In other words, they would have no pricing power at all (a Tragedy of the Commons) and the system would devolve into a partial-monopoly in order to gain pricing power.
A partial-monopoly in this case is enough % of the network hashrate to delay transactions (by that % of blocks) which do not include a sufficient fee.
If we limit block size, then the system doesn't scale.
If we let the Bitcoin foundation decide when to increase block size, then they control the economic market function, i.e. we've centralized Bitcoin.
Let us assume unlimited block size and partial-monopolies. Thus the transaction fee can always be forced higher in order to generate more revenue for the miners. Thus Bitcoin devolves (as coin rewards diminish) to a system that presents spenders with a choice between include a very high transaction fee or accept an ever increasing delay for confirmation. This will exacerbate as coin rewards diminish and volume of transactions increase.
If we instead assume limited block size, then the Bitcoin foundation will set the transaction fees, not the market.
Bitcoin is a broken design.
A key factor is the block size. If the block size is unlimited (and bandwidth is an insignificant cost), then unless miners have a monopoly they will accept transactions with fees as low as don't constitute a DoS attack, in order to maximize revenue.
In other words, they would have no pricing power at all (a Tragedy of the Commons) and the system would devolve into a partial-monopoly in order to gain pricing power.
A partial-monopoly in this case is enough % of the network hashrate to delay transactions (by that % of blocks) which do not include a sufficient fee.
If we limit block size, then the system doesn't scale.
If we let the Bitcoin foundation decide when to increase block size, then they control the economic market function, i.e. we've centralized Bitcoin.
Let us assume unlimited block size and partial-monopolies. Thus the transaction fee can always be forced higher in order to generate more revenue for the miners. Thus Bitcoin devolves (as coin rewards diminish) to a system that presents spenders with a choice between include a very high transaction fee or accept an ever increasing delay for confirmation. This will exacerbate as coin rewards diminish and volume of transactions increase.
If we instead assume limited block size, then the Bitcoin foundation will set the transaction fees, not the market.
Bitcoin is a broken design.
Even a broken clock is right twice a day.
More intellect than a non-sentient rotating clock hand is required to produce the insight above.
I see that one flew right over your head.
January 22, 2016, 07:59:09 PM
Anyway, I am not going to argue with you any further, like I've already stated in another thread.
Me too. I am done. Hopefully I influenced Monero/Aeon to look into Zerocash seriously. Maybe y'all will work with ZC, fork it, ignore it, or what ever. Advance our needs for truly reliable privacy especially in applications where it can be realistically achieved and thus adopted.
January 22, 2016, 07:54:46 PM
Your problem is that you constantly conflate your conjecture with reality and state it as fact.
As I did in 2013 eh:
I finally had a spare moment to contemplate the variables.
A key factor is the block size. If the block size is unlimited (and bandwidth is an insignificant cost), then unless miners have a monopoly they will accept transactions with fees as low as don't constitute a DoS attack, in order to maximize revenue.
In other words, they would have no pricing power at all (a Tragedy of the Commons) and the system would devolve into a partial-monopoly in order to gain pricing power.
A partial-monopoly in this case is enough % of the network hashrate to delay transactions (by that % of blocks) which do not include a sufficient fee.
If we limit block size, then the system doesn't scale.
If we let the Bitcoin foundation decide when to increase block size, then they control the economic market function, i.e. we've centralized Bitcoin.
Let us assume unlimited block size and partial-monopolies. Thus the transaction fee can always be forced higher in order to generate more revenue for the miners. Thus Bitcoin devolves (as coin rewards diminish) to a system that presents spenders with a choice between include a very high transaction fee or accept an ever increasing delay for confirmation. This will exacerbate as coin rewards diminish and volume of transactions increase.
If we instead assume limited block size, then the Bitcoin foundation will set the transaction fees, not the market.
Bitcoin is a broken design.
A key factor is the block size. If the block size is unlimited (and bandwidth is an insignificant cost), then unless miners have a monopoly they will accept transactions with fees as low as don't constitute a DoS attack, in order to maximize revenue.
In other words, they would have no pricing power at all (a Tragedy of the Commons) and the system would devolve into a partial-monopoly in order to gain pricing power.
A partial-monopoly in this case is enough % of the network hashrate to delay transactions (by that % of blocks) which do not include a sufficient fee.
If we limit block size, then the system doesn't scale.
If we let the Bitcoin foundation decide when to increase block size, then they control the economic market function, i.e. we've centralized Bitcoin.
Let us assume unlimited block size and partial-monopolies. Thus the transaction fee can always be forced higher in order to generate more revenue for the miners. Thus Bitcoin devolves (as coin rewards diminish) to a system that presents spenders with a choice between include a very high transaction fee or accept an ever increasing delay for confirmation. This will exacerbate as coin rewards diminish and volume of transactions increase.
If we instead assume limited block size, then the Bitcoin foundation will set the transaction fees, not the market.
Bitcoin is a broken design.
Even a broken clock is right twice a day.
More intellect than a non-sentient rotating clock hand is required to produce the insight above.
January 22, 2016, 07:46:42 PM
Since they are based on Bitcoin's protocol, don't you think it is likely they need IP obfuscation for either the basecoin to basecoin transactions or the basecoin to zerocoin transaction?
My interest is in the zerocoins. The IP obfuscation is claimed to be needed for them also, because ZC doesn't hide your meta-data from externalities (how could it, it is only the block chain and not the entire internet). But it does afaik prevent your meta-data from being correlated with any UTXO because UTXO are entirely obfuscated in a blob in ZC (except for one very unlikely attack mentioned in section 6.4 of the white paper which I think can be foiled/detected). But that claimed need is only because you don't want your payer IP address to be revealed to for example the payee. But the payee is likely to know who you are any way. And other nuanced scenarios like that. And not just IP address but browser cookies, etc, etc. I think externalities meta-data is an insoluble issue. Can never be reliable.
Thus I reason that the more certain markets are those where the corporate server is very much in control of its meta-data footprint and the superior provability of the ZC obfuscation (no publicly detectable UTXO!) wins.
Any way, I don't want to spend too much more time on this, because I am not developing in this area any more (unless something changes in my plans). I wasn't impressed that I was banned from the Zerocash forum about 3 minutes after I posted there, lol.
January 22, 2016, 07:41:17 PM
Please do point out where I am lying. At your leisure. Don't feel compelled to do it immediately if you are busy.
You portrayed me as a liar when I, according to you, incorrectly stated that you have been going on for past months. I earlier stated that your initial assertation that Zerocash does not need IP obfuscation was incorrect. Using the same terminology as you, that makes you a liar as well. Guess it's a matter of how you see it, but I am not going to argue with you about this any further.
Well I think you are still (maybe unknowingly) lying about that IP obfuscation point. Realize I predicated my entire posting about Zerocash to the point of driving corporate adoption of block chain privacy, so in that context I don't think the IP obfuscation that is needed for ZC applies. In fact, I think it is a nonsense point that the white paper makes, because in the scenarios where one can't rely on the fact that the meta-data is not correlated to any UTXO (because there is none in ZC!) then one can't realistically attain reliable anonymity any way. So the entire allegation that ZC needs IP obfuscation is bogus. I stated that in my debate with smooth, but I doubt most readers (maybe not even smooth) got my point.
And this shows that the Zerocash developers may also not understand yet the correct marketing strategy they need to pursue. It is also an example of how marketing and technology assessment go together and can't be done piecemeal.
I am trying to tell you guys I am very expert at doing both. Please continue doubting me. Are we done?
If I you have addressed this earlier, I'll stand corrected on the following point.
Zerocash uses 2 kind of coins, basecoins (which are transparent) and zerocoins (which are anonymous). Users can convert those basecoins to zerocoins, but nothing stops them to make transactions with those basecoins themselves.
From their website:
Quote
Zerocash extends the protocol and software underlying Bitcoin by adding new, privacy-preserving payments. In doing so it forms a new protocol that, while using some of the same technology and software as Bitcoin, is distinct from it. This new protocol has both anonymous coins, dubbed zerocoins, and non-anonymous ones, which, for purposes of disambiguation, we call basecoins. In contrast to Bitcoin's transactions, payment transactions using the Zerocash protocol do not contain any public information about the payment's origin, destination, or amount; instead, the correctness of the transaction is demonstrated via the use of a zero-knowledge proof. Users can convert from basecoins to zerocoins, send zerocoins to other users, and split or merge zerocoins they own in any way that preserves the total value. Users may also convert zerocoins back into basecoins, though in principle this is not necessary: all transactions can be made in terms of zerocoins.
Since they are based on Bitcoin's protocol, don't you think it is likely they need IP obfuscation for either the basecoin to basecoin transactions or the basecoin to zerocoin transaction?
January 22, 2016, 07:35:56 PM
Please do point out where I am lying. At your leisure. Don't feel compelled to do it immediately if you are busy.
You portrayed me as a liar when I, according to you, incorrectly stated that you have been going on for past months. I earlier stated that your initial assertation that Zerocash does not need IP obfuscation was incorrect. Using the same terminology as you, that makes you a liar as well. Guess it's a matter of how you see it, but I am not going to argue with you about this any further.
Well I think you are still (maybe unknowingly) lying about that IP obfuscation point. Realize I predicated my entire posting about Zerocash to the point of driving corporate adoption of block chain privacy, so in that context I don't think the IP obfuscation that is needed for ZC applies. In fact, I think it is a nonsense point that the white paper makes, because in the scenarios where one can't rely on the fact that the meta-data is not correlated to any UTXO (because there is none in ZC!) then one can't realistically attain reliable anonymity any way. So the entire allegation that ZC needs IP obfuscation is bogus. I stated that in my debate with smooth, but I doubt most readers (maybe not even smooth) got my point.
And this shows that the Zerocash developers may also not understand yet the correct marketing strategy they need to pursue.
I got your point, I just disagree with value of it. The Zerocash writers likely do as well, but I can't speak for them.
I do agree with the point that there are corporate use cases that can benefit from limited privacy, such the Liquid sidechain with CT (value hiding only). Whether those are viable long term I don't know.
It is a nuanced issue in some respects, but the bottomline that will come from it all in the end, is that unreliable privacy doesn't get adopted. And so everything will converge over time to the provable End-to-End principled privacy that has no meta-data dependencies.
Any way, that my expert assertion. Feel free to ignore it.
Zerocash is likely very inexperienced on issues that we've been exploring in these forums for the past 2 years. As smart as they are, they are not omniscient.
Edit: trust is an essential issue for humans. Privacy and unreliability is an oxymoronic juxtaposition.
January 22, 2016, 07:31:57 PM
Please do point out where I am lying. At your leisure. Don't feel compelled to do it immediately if you are busy.
You portrayed me as a liar when I, according to you, incorrectly stated that you have been going on for past months. I earlier stated that your initial assertation that Zerocash does not need IP obfuscation was incorrect. Using the same terminology as you, that makes you a liar as well. Guess it's a matter of how you see it, but I am not going to argue with you about this any further.
Well I think you are still (maybe unknowingly) lying about that IP obfuscation point. Realize I predicated my entire posting about Zerocash to the point of driving corporate adoption of block chain privacy, so in that context I don't think the IP obfuscation that is needed for ZC applies. In fact, I think it is a nonsense point that the white paper makes, because in the scenarios where one can't rely on the fact that the meta-data is not correlated to any UTXO (because there is none in ZC!) then one can't realistically attain reliable anonymity any way. So the entire allegation that ZC needs IP obfuscation is bogus. I stated that in my debate with smooth, but I doubt most readers (maybe not even smooth) got my point.
And this shows that the Zerocash developers may also not understand yet the correct marketing strategy they need to pursue.
I got your point, I just disagree with value of it. The Zerocash writers likely do as well, but I can't speak for them.
I do agree with the point that there are corporate use cases that can benefit from limited privacy, such the Liquid sidechain with CT (value hiding only). Whether those are viable long term I don't know.
January 22, 2016, 07:29:55 PM
Please do point out where I am lying. At your leisure. Don't feel compelled to do it immediately if you are busy.
You portrayed me as a liar when I, according to you, incorrectly stated that you have been going on for past months. I earlier stated that your initial assertation that Zerocash does not need IP obfuscation was incorrect. Using the same terminology as you, that makes you a liar as well. Guess it's a matter of how you see it, but I am not going to argue with you about this any further.
Well I think you are still (maybe unknowingly) lying about that IP obfuscation point. Realize I predicated my entire posting about Zerocash to the point of driving corporate adoption of block chain privacy, so in that context I don't think the IP obfuscation that is needed for ZC applies. In fact, I think it is a nonsense point that the white paper makes, because in the scenarios where one can't rely on the fact that the meta-data is not correlated to any UTXO (because there is none in ZC!) then one can't realistically attain reliable anonymity any way. So the entire allegation that ZC needs IP obfuscation is bogus. I stated that in my debate with smooth, but I doubt most readers (maybe not even smooth) got my point.
And this shows that the Zerocash developers may also not understand yet the correct marketing strategy they need to pursue. It is also an example of how marketing and technology assessment go together and can't be done piecemeal.
I am trying to tell you guys I am very expert at doing both. Please continue doubting me. Are we done?
January 22, 2016, 07:24:58 PM
Please do point out where I am lying. At your leisure. Don't feel compelled to do it immediately if you are busy.
You portrayed me as a liar when I, according to you, incorrectly stated that you have been going on for past months. I earlier stated that your initial assertation that Zerocash does not need IP obfuscation was incorrect. Using the same terminology as you, that makes you a liar as well. Guess it's a matter of how you see it, but I am not going to argue with you about this any further.
January 22, 2016, 07:24:51 PM
Your problem is that you constantly conflate your conjecture with reality and state it as fact.
As I did in 2013 eh:
I finally had a spare moment to contemplate the variables.
A key factor is the block size. If the block size is unlimited (and bandwidth is an insignificant cost), then unless miners have a monopoly they will accept transactions with fees as low as don't constitute a DoS attack, in order to maximize revenue.
In other words, they would have no pricing power at all (a Tragedy of the Commons) and the system would devolve into a partial-monopoly in order to gain pricing power.
A partial-monopoly in this case is enough % of the network hashrate to delay transactions (by that % of blocks) which do not include a sufficient fee.
If we limit block size, then the system doesn't scale.
If we let the Bitcoin foundation decide when to increase block size, then they control the economic market function, i.e. we've centralized Bitcoin.
Let us assume unlimited block size and partial-monopolies. Thus the transaction fee can always be forced higher in order to generate more revenue for the miners. Thus Bitcoin devolves (as coin rewards diminish) to a system that presents spenders with a choice between include a very high transaction fee or accept an ever increasing delay for confirmation. This will exacerbate as coin rewards diminish and volume of transactions increase.
If we instead assume limited block size, then the Bitcoin foundation will set the transaction fees, not the market.
Bitcoin is a broken design.
A key factor is the block size. If the block size is unlimited (and bandwidth is an insignificant cost), then unless miners have a monopoly they will accept transactions with fees as low as don't constitute a DoS attack, in order to maximize revenue.
In other words, they would have no pricing power at all (a Tragedy of the Commons) and the system would devolve into a partial-monopoly in order to gain pricing power.
A partial-monopoly in this case is enough % of the network hashrate to delay transactions (by that % of blocks) which do not include a sufficient fee.
If we limit block size, then the system doesn't scale.
If we let the Bitcoin foundation decide when to increase block size, then they control the economic market function, i.e. we've centralized Bitcoin.
Let us assume unlimited block size and partial-monopolies. Thus the transaction fee can always be forced higher in order to generate more revenue for the miners. Thus Bitcoin devolves (as coin rewards diminish) to a system that presents spenders with a choice between include a very high transaction fee or accept an ever increasing delay for confirmation. This will exacerbate as coin rewards diminish and volume of transactions increase.
If we instead assume limited block size, then the Bitcoin foundation will set the transaction fees, not the market.
Bitcoin is a broken design.
Even a broken clock is right twice a day.
January 22, 2016, 07:19:54 PM
Your problem is that you constantly conflate your conjecture with reality and state it as fact.
As I did in 2013 eh:
I finally had a spare moment to contemplate the variables.
A key factor is the block size. If the block size is unlimited (and bandwidth is an insignificant cost), then unless miners have a monopoly they will accept transactions with fees as low as don't constitute a DoS attack, in order to maximize revenue.
In other words, they would have no pricing power at all (a Tragedy of the Commons) and the system would devolve into a partial-monopoly in order to gain pricing power.
A partial-monopoly in this case is enough % of the network hashrate to delay transactions (by that % of blocks) which do not include a sufficient fee.
If we limit block size, then the system doesn't scale.
If we let the Bitcoin foundation decide when to increase block size, then they control the economic market function, i.e. we've centralized Bitcoin.
Let us assume unlimited block size and partial-monopolies. Thus the transaction fee can always be forced higher in order to generate more revenue for the miners. Thus Bitcoin devolves (as coin rewards diminish) to a system that presents spenders with a choice between include a very high transaction fee or accept an ever increasing delay for confirmation. This will exacerbate as coin rewards diminish and volume of transactions increase.
If we instead assume limited block size, then the Bitcoin foundation will set the transaction fees, not the market.
Bitcoin is a broken design.
A key factor is the block size. If the block size is unlimited (and bandwidth is an insignificant cost), then unless miners have a monopoly they will accept transactions with fees as low as don't constitute a DoS attack, in order to maximize revenue.
In other words, they would have no pricing power at all (a Tragedy of the Commons) and the system would devolve into a partial-monopoly in order to gain pricing power.
A partial-monopoly in this case is enough % of the network hashrate to delay transactions (by that % of blocks) which do not include a sufficient fee.
If we limit block size, then the system doesn't scale.
If we let the Bitcoin foundation decide when to increase block size, then they control the economic market function, i.e. we've centralized Bitcoin.
Let us assume unlimited block size and partial-monopolies. Thus the transaction fee can always be forced higher in order to generate more revenue for the miners. Thus Bitcoin devolves (as coin rewards diminish) to a system that presents spenders with a choice between include a very high transaction fee or accept an ever increasing delay for confirmation. This will exacerbate as coin rewards diminish and volume of transactions increase.
If we instead assume limited block size, then the Bitcoin foundation will set the transaction fees, not the market.
Bitcoin is a broken design.
January 22, 2016, 07:15:48 PM
Your ZKT is an idea in your delusional mind. I am flabbergasted that even you would be so bold to claim that some delusion of yours is a competitor to RingCT.
You are entitled to your (incorrect) opinion. And note I didn't censor your post (not even your "blown fuse" trolling with the flagrant ad hominem images and no content), unlike the manipulative Monero threads where they censor everything they don't want readers to read.
Thats right, one can only take so much bullshit, mis-information and un-substantiated claims.
That is what you think facts, suggestions, and feedback are. Amazing concept of open source you have going on there in that Monero/Aeon echo chamber.
Your problem is that you constantly conflate your conjecture with reality and state it as fact.
And please take a step back and when you do that and review your actions you have to admit that the memes are great!!
January 22, 2016, 07:06:32 PM
Your ZKT is an idea in your delusional mind. I am flabbergasted that even you would be so bold to claim that some delusion of yours is a competitor to RingCT.
You are entitled to your (incorrect) opinion. And note I didn't censor your post (not even your "blown fuse" trolling with the flagrant ad hominem images and no content), unlike the manipulative Monero threads where they censor everything they don't want readers to read.
Thats right, one can only take so much bullshit, mis-information and un-substantiated claims.
That is what you think facts, suggestions, and feedback are. Amazing concept of open source you have going on there in that Monero/Aeon echo chamber.
January 22, 2016, 07:05:28 PM
You said for the "past months". That is erroneous.
We had a flareup when I was discussing my ZKT (which was a competitor to Monero's RingCT) back in afair September and now again recently when I started to discuss user adoption and marketing in the Aeon and subsequently the Monero thread.
Your ZKT is just an idea in your boastful delusional mind. I am flabbergasted that even you would be so bold as to claim that some delusion of yours is a competitor to RingCT.
You truly are a legend in your own mind.
OTOH, smooth has been mostly fair, but even he has a limit and it was exceeded. Nevertheless I don't have any ongoing animosity. It is just the nature of the circumstances. Nothing personal.
Thats right, one can only take so much bullshit, mis-information and un-substantiated claims. Yes, even Smooth has a limit. Your words not mine dumbass.
January 22, 2016, 07:01:59 PM
Also, your project became a lot less interesting when you dropped the anonymity feature.
Okay your explanation is accepted. And my apology for being paranoid.
Please do point out where I am lying. At your leisure. Don't feel compelled to do it immediately if you are busy.
January 22, 2016, 06:55:18 PM
[2] Just look at your own post history, every post you make which is Monero related gets copied to a dozen threads.
You said for the "past months". That is erroneous.
We had a flareup when I was discussing my ZKT (which was a competitor to Monero's RingCT) back in afair September and now again recently when I started to discuss user adoption and marketing in the Aeon and subsequently the Monero thread. Actually what brought me to the Monero thread was the post by ArticMine in my thread on Decentralization this month and then I went to the Monero thread to explain why their hubris about fixing the block size economics was mathematically flawed. Then one of your community members posted about Zerocash, and I offered my thoughts and the attacks and venom from your community began in earnest.
Next time stop lying.
And I will never forget how you manipulated me by pretending you wanted to be an angel investor only to get info for Monero and how you manipulated me in the peer review of your very condescending Shen-noether.
I don't have time to read all your posts, but to me it seemed like an on-going process. I might be wrong, I have no time, nor the willingness, to check it. I stand corrected on this point.
And I will never forget how you manipulated me by pretending you wanted to be an angel investor only to get info for Monero and how you manipulated me in the peer review of your very condescending Shen-noether.
You are getting paranoid here. Like I stated earlier, I enjoyed reading your posts, found them insightful, intriguing and learned from them, for which I am grateful. Those were the reasons I wanted to be an angel investor in your project, not to gather information for Monero. Also, your project became a lot less interesting when you dropped the anonymity feature. I also didn't manipulate you into doing peer-review, I appreciated your effort, thanked you for that and stated that the members of the Monero community did so as well.
Next time stop lying.
If you do too
Jump to: