Cameron Garnham [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-12-13 to 2017-05-26
💬 Posted a total of 23 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1qhl358d8na8d3euj3aakeu394zx7q6pqc4a8u4p962k9mtrqdrvscchcrk

Profile Code

nprofile1qqsqtlc6rkne7nkcu7fg77mv7gj63r0qdqsv27n72sja9tza43sx3kgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsdm7srp

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1qhl358d8na8d3euj3aakeu394zx7q6pqc4a8u4p962k9mtrqdrvscchcrk

Show more details

Last Notes

2023-06-07 20:01:54

- reply

📅 Original date posted:2017-05-26
📝 Original message:Hello Eric,
Thank you for your question and your time off-list clarifying your position. I’m posting to the list so that a wider audience may benefit.
Original Question: ‘Presumably the "very serious security vulnerability" posed is one of increased centralization of hash power. Would this danger exist without the patent risk?’
I would postulate that if ASICBOOST was originally released without the patent risk, then much of the risk would have been avoided; all of the mining manufactures would have implemented ASICBOOST and had a similar advantage. However, now time has passed and the damage of the patent monopoly exploiting CVE-2017-9230 has been already done. If the ASICBOOST patent was released to the public for free today, while a good thing, it wouldn’t soften the severity of the vulnerability we face today.
The ASICBOOST PATENT provides a miner with a constant-factor advantage. This is a huge problem with zero-sum games, such as mining. In game-theory, a constant factor advantage gives an exponential advantage over the time period maintained.
This explains why the Bitcoin Community initially took very little notice to ASICBOOST: The effects of ASICBOOST stated at virtually nothing, and it took a while for the advantage to been seen over the normal variance of mining. However, it’s influence has been exponentially growing since then: creating an emergency problem that we now face.
The result of ASICBOOST going unchecked is that very quickly from now, surprisingly quickly, the only profitable miners will be the miners who make use of ASICBOOST. This is a grave concern.
I will again reiterate that the virtue-signalling over perceived political motivations is ridiculous in the light what I consider a looming catastrophe, we should be judging by what is real not just perceived.
The catastrophe that I fear is one company (or a single politically connected group) gaining a virtual complete monopoly of Bitcoin Mining. This is more important to me than avoiding chain-splits. Without a well-distributed set of miners Bitcoin isn’t Bitcoin.
Cameron.
PS.
This attack is part of a larger set of licensing attacks, where patens are just one form of licensing attack. These attacks are particularly damaging in competitive markets such as mining. We should be vigilant for other attempts to create state-enforced licensing around mathematical algorithms. ASICBOOST is an illustrative example of what the Bitcoin Community needs to defend against.
> On 26 May 2017, at 11:15 , Eric Voskuil <eric at voskuil.org> wrote:
>
> Signed PGP part
> Hi Cameron,
>
> Presumably the "very serious security vulnerability" posed is one of
> increased centralization of hash power. Would this danger exist
> without the patent risk?
>
> e
>

2023-06-07 20:01:53

- reply

📅 Original date posted:2017-05-26
📝 Original message:Thank you for your reply Andreas,
I can assure you that I have many motivations for activating SegWit.
Before studding ASICBOOST I wanted to activate SegWit as it is a wonderful upgrade for Bitcoin. It seems to me that virtually the entire Bitcoin Ecosystem agrees with me. Except for around 67% of the mining hash-rate who very conspicuously refuse to signal for it’s activation.
So, I started searching for the motivations of such a large amount of the mining hash-rate holding a position that isn’t at-all represented in the wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment: If one assumes that the 67% of the hash rate that refuse to signal for SegWit are using ASICBOOST. The entire picture of this political stalemate became much more understandable.
This only strengthened my resolve to activate SegWit: not only is SegWit great, it partially mitigates a very serious security vulnerability.
This is why I call into question why you would suggest:
“This proposal is unnecessarily conflating two contentious issues and will attract criticism of self serving motivation.”
1. I am not conflating the issues. I would argue that very fact that SegWit has not been activated yet is directly because of CVE-2017-9230.
2. I have no reason to believe that SegWit is contentious, except for the attackers who it would frustrate.
3. I have no negative responses to my endeavours to get ASICBOOST as regarded as a legitimate security vulnerability. This would suggest that it is not contentious in the wider technical community.
If SegWit is NOT contentious within the technical community and it is NOT contentious to regard CVE-2017-9230 as a credible security vulnerability. Then using it as partial security fix for a security vulnerability SHOULD NOT be contentious.
If you believe that SegWit is contentious within the technical community. Or you believe CVE-2017-9230 should not be regarded as a credible security vulnerability. Then I would logically agree with you that we should separate the issues so that we may gain consensus. However, I just don’t see this as the case.
Cameron.
> On 26 May 2017, at 09:52 , Andreas M. Antonopoulos <andreas at antonopoulos.com> wrote:
>
> I rarely post here, out of respect to the mailing list. But since my name was mentioned...
>
> I much prefer Gregory Maxwell's proposal to defuse covert ASICBOOST (only) with a segwit-like commitment to the coinbase which does not obligate miners to signal Segwit or implement Segwit, thus disarming any suspicion that the issue is being exploited only to activate Segwit.
>
> This proposal is unnecessarily conflating two contentious issues and will attract criticism of self serving motivation.
>
> Politicising CVE is damaging to the long term bitcoin development and to its security. Not claiming that is the intent here, but the damage is done by the mere appearance of motive.
>
>
>
> On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Bitcoin-Dev,
>
> CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a severe (3) (4) and actively exploited (5) security vulnerability.
>
> To learn more about this vulnerability please read Jeremy Rubin’s detailed report:
> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>
> Andreas Antonopoulos has an excellent presentation on why asicboost is dangerous:
> https://www.youtube.com/watch?v=t6jJDD2Aj8k
>
> In decisions on the #bitcoin-core-dev IRC channel; It was proposed, without negative feedback, that SegWit be used as a partial-mitigation of CVE-2017-9230.
>
> SegWit partially mitigates asicboost with the common reasonable assumption that any block that doesn’t include a witness commit in it's coinbase transaction was mined using covert asicboost. Making the use of covert asicboost far more conspicuous.
>
> It was also proposed that this partial mitigation should be quickly strengthened via another soft-fork that makes the inclusion of witness commits mandatory, without negative feedback.
>
> The security trade-offs of deploying a partial-mitigation to CVE-2017-9230 quickly vs more slowly but more conservatively is under intense debate. The author of this post has a strong preference to the swiftest viable option.
>
> Cameron.
>
>
> (1) CVE Entry:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
>
> (2) Announcement of CVE to Mailing List:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014416.html
>
> (3) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan Grant:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html
>
> (4) Discussion of ASICBOOST's non-independent PoW calculation by Tier Nolan:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html
>
> (5) Evidence of Active Exploit by Gregory Maxwell:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:01:52

- reply

📅 Original date posted:2017-05-26
📝 Original message:Hello Bitcoin-Dev,
CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a severe (3) (4) and actively exploited (5) security vulnerability.
To learn more about this vulnerability please read Jeremy Rubin’s detailed report:
http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
Andreas Antonopoulos has an excellent presentation on why asicboost is dangerous:
https://www.youtube.com/watch?v=t6jJDD2Aj8k
In decisions on the #bitcoin-core-dev IRC channel; It was proposed, without negative feedback, that SegWit be used as a partial-mitigation of CVE-2017-9230.
SegWit partially mitigates asicboost with the common reasonable assumption that any block that doesn’t include a witness commit in it's coinbase transaction was mined using covert asicboost. Making the use of covert asicboost far more conspicuous.
It was also proposed that this partial mitigation should be quickly strengthened via another soft-fork that makes the inclusion of witness commits mandatory, without negative feedback.
The security trade-offs of deploying a partial-mitigation to CVE-2017-9230 quickly vs more slowly but more conservatively is under intense debate. The author of this post has a strong preference to the swiftest viable option.
Cameron.
(1) CVE Entry:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
(2) Announcement of CVE to Mailing List:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014416.html
(3) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan Grant:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html
(4) Discussion of ASICBOOST's non-independent PoW calculation by Tier Nolan:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html
(5) Evidence of Active Exploit by Gregory Maxwell:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html

2023-06-07 20:01:19

- reply

📅 Original date posted:2017-05-24
📝 Original message:Hello Bitcoin-Dev,
A quick update that CVE-2017-9230 has been assigned for the security vulnerability commonly called ‘ASICBOOST’:
"The Bitcoin Proof-of-Work algorithm does not consider a certain attack methodology related to 80-byte block headers with a variety of initial 64-byte chunks followed by the same 16-byte chunk, multiple candidate root values ending with the same 4 bytes, and calculations involving sqrt numbers. This violates the security assumptions of (1) the choice of input, outside of the dedicated nonce area, fed into the Proof-of-Work function should not change its difficulty to evaluate and (2) every Proof-of-Work function execution should be independent.”
I would like to especially thank the CVE team at Mitre for their suggested description that was more appropriate than my proposed text.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
Cameron.
> Begin forwarded message:
>
> From: <cve-request at mitre.org>
> Subject: Re: [scr-xxxxx] Bitcoin - All
> Date: 24 May 2017 at 18:52:22 GMT+3
> To: <da2ce7 at gmail.com>
> Cc: <cve-request at mitre.org>
>
> Signed PGP part
> > [Suggested description]
> > The Bitcoin Proof-of-Work algorithm does not consider a certain attack
> > methodology related to 80-byte block headers with a variety of initial
> > 64-byte chunks followed by the same 16-byte chunk, multiple candidate
> > root values ending with the same 4 bytes, and calculations involving
> > sqrt numbers. This violates the security assumptions of (1) the choice
> > of input, outside of the dedicated nonce area, fed into the
> > Proof-of-Work function should not change its difficulty to evaluate
> > and (2) every Proof-of-Work function execution should be independent.
> >
> > ------------------------------------------
> >
> > [Additional Information]
> > ASICBOOST, originality promoted as a patented mining optimisation(1).
> > Has under detailed study (2), become regarded as an actively exploited
> > (3), security vulnerability (4), of Bitcoin.
> >
> > The Bitcoin Proof-of-Work Algorithm is dependent on the following two
> > security assumptions that are both broken by 'ASICBOOST':
> > 1. The choice of input, outside of the dedicated nonce area, fed into
> > the Proof-of-Work function should not change it's difficulty to
> > evaluate.
> > 2. Every Proof-of-Work function execution should be independent.
> >
> > 'ASICBOOST' creates a layer-violation where the structure of the input
> > outside of the dedicated nonce area will change the performance of the
> > mining calculations (5). 'ASICBOOST' exploits a vulnerability where
> > the Proof-of-Work function execution is not independent (6).
> >
> > References:
> > (1) Original Whitepaper by Dr. Timo Hanke: https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf
> > (2) Academic Write-up by Jeremy Rubin: http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
> > (3) Evidence of Active Exploit by Gregory Maxwell:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html
> > (4) Discussion to assign a CVE Number, by Cameron Garnham:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014349.html
> > (5) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan Grant:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html
> > (6) Discussion of ASICBOOST's non-independent PoW calculation by Tier Nolan:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html
> >
> > The patent holder of this particular security vulnerability has a dedicated website: https://www.asicboost.com/
> >
> > ------------------------------------------
> >
> > [VulnerabilityType Other]
> > Cryptocurrency Mining Algorithm Weakness
> >
> > ------------------------------------------
> >
> > [Vendor of Product]
> > Bitcoin
> >
> > ------------------------------------------
> >
> > [Affected Product Code Base]
> > Bitcoin - All
> >
> > ------------------------------------------
> >
> > [Affected Component]
> > Bitcoin
> >
> > ------------------------------------------
> >
> > [Attack Type Other]
> > Cryptocurrency Proof-of-Work Algorithm Weakness
> >
> > ------------------------------------------
> >
> > [CVE Impact Other]
> > Creation of Perverse Incentives in a Cryptocurrency
> >
> > ------------------------------------------
> >
> > [Attack Vectors]
> > Bitcoin Mining Unfair Advantage
> > Bitcoin Layer-Violations Creating Perverse System Incentives
> >
> > ------------------------------------------
> >
> > [Reference]
> > https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf
> > http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014349.html
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html
> >
> > ------------------------------------------
> >
> > [Has vendor confirmed or acknowledged the vulnerability?]
> > true
> >
> > ------------------------------------------
> >
> > [Discoverer]
> > Original Discovery: Dr. Timo Hanke and Sergio Lerner. Proof of Active
> > Exploit: Gregory Maxwell. CVE Reporter: Cameron Garnham
>
> Use CVE-2017-9230.
>
>
> --
> CVE Assignment Team
> M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
> [ A PGP key is available for encrypted communications at
> http://cve.mitre.org/cve/request_id.html ]
>

2023-06-07 20:01:18

- reply

📅 Original date posted:2017-05-19
📝 Original message:(message was originally sent off-list by mistake).
Hello Tier,
Thank-you for your insightful reply,
Am I correct that this suggest is that you think it is an optimisation to find some nonces having lower difficulty than other nonces?
I would agree with you if this was limited to a dedicated nonce area of the Bitcoin System.
However, in the case of Bitcoin it is a layer violation that the PoW function difficulty could be affected by the choice the transaction ordering, or the content of the Coinbase Transaction, etc. Possibly giving unnatural and unintended incentives to other parts of the Bitcoin System.
I can see two issues at play here:
1. The choice of input, outside of the dedicated nonce area, fed the PoW function should not change it’s difficulty to evaluate.
2. Every PoW function execution should be independent.
I think that both of these are security assumptions of the Bitcoin PoW function.
I consider ASICBOOST as an attack upon both accounts.
Cameron.
>
> On 18 May 2017, at 17:59 , Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, May 18, 2017 at 2:44 PM, Cameron Garnham via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 1. Significant deviations from the Bitcoin Security Model have been acknowledged as security vulnerabilities.
>
> The Bitcoin Security Model assumes that every input into the Proof-of-Work function should have the same difficulty of producing a desired output.
>
> This isn't really that clear.
>
> Arguably as long as the effort to find a block is proportional to the block difficulty parameter, then it isn't an exploit. It is just an optimisation.
>
> A quantum computer, for example, could find a block with effort proportional to the square root of the difficulty parameter, so that would count as an attack. Though in that case, the fix would likely be to tweak the difficulty parameter update calculation.
>
> A better definition would be something like "when performing work, each hash should be independent".
>
> ASICBOOST does multiple checks in parallel, so would violate that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170519/e0038c2d/attachment-0001.html>

2023-06-07 20:01:17

- reply

📅 Original date posted:2017-05-18
📝 Original message:Hello Bitcoin Development Mailing List,
I wish to explain why the current approach to ‘ASICBOOST’ dose not comply with our established best practices for security vulnerabilities and suggest what I consider to be an approach closer matching established industry best practices.
1. Significant deviations from the Bitcoin Security Model have been acknowledged as security vulnerabilities.
The Bitcoin Security Model assumes that every input into the Proof-of-Work function should have the same difficulty of producing a desired output.
2. General ASIC optimisation cannot be considered a Security Vulnerabilities.
Quickly being able to check inputs is not a vulnerability. However, being able to craft inputs that are significantly easier to check than alternative inputs is a vulnerability.
3. We should assign a CVE to the vulnerability exploited by ‘ASICBOOST’.
‘ASICBOOST’ is an attack on this Bitcoin’s security assumptions and should be considered an exploit of the Bitcoin Proof-of-Work Function.
For a more detailed look at ‘ASICBOOST’, please have a look at this excellent document by Jeremy Rubin:
http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
The Bitcoin Community should be able to track the progress of restoring the quality of the Bitcoin Proof-of-Work function to its original assumptions.
4. Work should be taken to prudently and swiftly restore Bitcoins Security Properties.
I recommend the Bitcoin Community fix this vulnerability with expediency.
Cameron.
PS:
With a soft-fork it probably is possible to completely fix this Proof-of-Work vulnerability.
(Here is my working list of things to do):
1. Include extra data in the Coinbase Transaction, such as the Witness Root.
2. Lock the Version. (Use a space in the Coinbase Transaction for signalling future upgrades).
3. Lock the lower-bits on the Timestamp: Block timestamps only need ~1minute granularity.
4. Make a deterministic ordering of transaction chains within a block. (However, I believe this option is more difficult).
Of course, if we have a hard-fork, we should consider the Proof-of-Work internal merkle structure directly.

2023-06-07 20:00:31

- reply

📅 Original date posted:2017-04-20
📝 Original message:I have taken some time to think about consensus systems in-general; and write up a guide that explores the problems space of changing the rules of such systems.
Hopefully, this guide will clarify the different options available to the Bitcoin Community.
I am posting this to the Bitcoin Development mailing list for review. Possibly a more comprehensive form of this document could be useful as an informative BIP.
** Type of Change **
There are three categories of changes:
S: Addition of a new Rule. (Soft-Fork)
H: Removal of an old Rule. (Hard-Fork)
E: Subverting an old Rule. (“Evil”, Non-Traditional Soft-Fork)
* Addition of a new Rule:
All previous rules in the system remain enforced as originally intended.
There are two sub-categories for the addition of a new rule:
1: New Functionally is added to the system, without effecting old use cases. (Opt-In New Functionality)
2: Functional users of the system must change their behaviour to suit the new rule. (Mandatory New Functionality)
* Removal of an old Rule
Equivalent replacing the entire system with any-new system. All full-users of the system must migrate to the new system.
* Subverting an old Rule
New Functionally is added that explicitly Replaces Old Functionality.
Users must upgrade and migrate to the new Functionally to continue using the system.
** Type of Activation **
There are two types of activations:
U. External Activations. (User Activated)
M. Internal Activations. (Miner Activated, PoS Activated, Internal Governance Model, etc)
It is possible to have more than one Activation Strategy used concurrently.
* External Activations
These Activations are dictated by facts that are not quantifiable from within the System.
Generally, this will be a set-of-users, external to the system, that come to their own agreement to change the system.
* Internal Activations
These activations use some metric from within the system to determine if a proposed change is activated.
Generally, some sort of internal signalling or vetoing process will happen and based upon its results, will dictate the if the change is activated.
** Type of Signalling **
Users within the system with more important roles may wish to (or be forced to) signal or (not) veto about a particular topic. This could be part of the activation strategy (internal activations), or just simply to quantify the support of the upcoming change.
There are two core types of Signalling:
O: Optional
F. Forced
There are two styles of Signalling:
N. Normal Signalling (Opt-In)
V. Veto (Opt-Out)
* Optional Signalling
Orthogonal to the system rules; however, the signalling still may affect other system rules.
* Enforced Signalling
This is a meta-rule change. Normally only temporally enforced upon the system. This rule change doesn’t directly affect the core behaviour of the system; it is just used for meta-purposes in the scope of another rule change.
* Normal Signalling
Passive Behaviour signals no support.
* Veto Signalling
Passive Behaviour signals support.
If I have missed anything or if anything is not clear, please contact me.
PS.
For example, you could call a BIP9 (SegWit) activation as a: “S1MON". And BIP 148 (SegWit) as: “S1UFN”. However this letter code is just for fun. :)
Cameron

2023-06-07 20:00:10

- reply

📅 Original date posted:2017-04-15
📝 Original message:Thank-you for your prompt response,
I believe I must have a different prospective of Bitcoin to you. Ideologically I don’t agree that miners can be passive participants in the Bitcoin Network; and I certainly don’t see them acting as passive participants in the Bitcoin Community now.
The miners are very much political actors. Hence why I fail to take-to-heart your concern "that the proposal will reject the blocks of passive participants”.
With AsicBoost, there are three miner groups: Those who use it (and have legal sanction to do so); Those who use it (without legal sanction); and those who don’t use it. If SegWit didn’t directly affect miners, then one could possibly claim that there could be an ideal passive participant miner in reality. However since your important revelations on AsicBoost: SegWit cannot be a ‘passive’ option for miners.
Hence, I don’t care about orphaning the blocks of of the theoretical "passive participant” miner. As I have no logical reasoning to suggest one could exists; and a large amount of evidence to suggesting one dose not exit.
On BIP 16 vs. BIP 17; I cannot see how BIP 148 similar engineering tradeoffs. Is there any long-term ‘technical debt’ from BIP 148 that I’m unaware of that could be similar to BIP 16?
On the Drama: Well 100M USD p/a can pay for lots of Drama; Hence going back to the first point: The miners are not passive participants when it comes to *any* form of activation of SegWit.
Cameron.
> On 15 Apr 2017, at 10:04 AM, Gregory Maxwell <greg at xiph.org> wrote:
>
> On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham <da2ce7 at gmail.com> wrote:
>> As many may remember, there was quite some controversy about the BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how this was the already “tested and proven to work” solution.
>
> And as a result we ultimately got a clearly inferior solution (520
> byte script limit; 80-bit security; months of orphaned blocks-- and
> two of those were not issues in BIP17). I went along for the cram
> fest on 16 after 12 caught fire, and I was mistaken to do so.
>
> Doubly so because it took years for P2SH to achieve any kind of mass
> deployment due to issues far away from consensus. An extra two months
> spent on some ground-work (including communications and documentation)
> could have pulled forward practical deployment by a year and given
> time to find and fix some of the flaws in the design of P2SH.
>
>> BIP 148 is out (our?) terms of peace. The Bitcoin Community is tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a outlet, and in Maxwell words: “...almost guarantees at a minor level of disruption.”.
>
> It seems I lost a word in my comment: that should have been "almost
> guarantees at _least_ a minor level of disruption". A minor level of
> disruption is the _minimum_ amount of disruption, and for no good
> reason except an unprecedented and unjustified level of haste.
>
> Considering that you did not spare a single word about the specific
> property that I am concerned about-- that the proposal will reject the
> blocks of passive participants, due to avoidable design limitations--
> I can't help but feel that you don't even care to understand the
> concern I was bringing up. :(
>
> How many people barely reviewed the specifics of the proposal simply
> because they want something fast and this proposal does something
> fast?
>
>> tired-to-death of this war and wants a resolution swiftly
>
> By now competitors and opponents to Bitcoin have surely realized that
> they can attack Bitcoin by stirring up drama.
>
> As a result, the only way that we will ever be free from "war" is if
> we choose to not let it impact us as much as possible. We must be
> imperturbable and continue working at the same level of excellence as
> if virtual shells weren't flying overhead-- or otherwise there is an
> incentive to keep them flying 24/7. Internet drama is remarkably cheap
> to generate. "The only thing we have to fear is fear itself".
>
> The alternative is that we hand opponents a ready made formula for
> disruption: astroturf enough drama up that Bitcoiners "sacrifice
> correctness" themselves right off a cliff in a futile attempt to make
> it go away. :)

2023-06-07 20:00:08

- reply

📅 Original date posted:2017-04-15
📝 Original message:Hello,
It is hard for me to come out disagreeing with Maxwell, however in this case I feel I must.
As many may remember, there was quite some controversy about the BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how this was the already “tested and proven to work” solution.
I was one of the man hold-out supporters of BIP17, not for any clear reason (I now have a much better technical understanding of the Bitcoin technical details, as we all do); But because it was the ‘more elegant’ solution. I knew from other fields of engineering that elegant solutions very often better deal with the ‘unknown, unknowns’. I also didn’t agree with Gavin’s ‘the sky is falling’ sense of urgency.
However, of-course the community got behind BIP16, it was activated, fortunately, without any signifiant incident.
I did learn that in Bitcoin there is something more valuable than technical elegance: that is community buy-in. On the technical side, the engineers need to make sure the solutions are viable: however on the community side we need to make sure that the good solutions are adopted in a reasonable timeframe.
It is both my empirical view and heart-felt belief that the wider Bitcoin Community wants SegWit quickly. In this case the sacrifice of some technical elegance and correctness for expediency is prudent!
It is my unfortunate view that Maxwell is missing the political forest for the technical trees. Not only is SegWit a technical solution to technical problems; it has come to represent, by the larger Bitcoin Community, a political solution to the conflict that we are waist-deep in every, single, day.
BIP 148 is out terms of peace. The Bitcoin Community is tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a outlet, and in Maxwell words: “...almost guarantees at a minor level of disruption.”.
I am willing to go through this minor level of disruption, as the daily disruption from the “scaling debate war”; in my personal online life, is far greater.
SegWit is a exceptional feat of engineering, it solves and mitigates so many small and highly subtle issues within Bitcoin; yet still managed to be simple enough successfully reviewed: now the community is clearly calling for a quick activation of the ‘viable’ technical choice.
If you/we are going to provide any engineering solution to activating SegWit, then Swiftness should be the 1st priority after viability.
BIP 148 is both Swift and Viable.
Cameron.
> On 14 Apr 2017, at 10:56 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I do not support the BIP148 UASF for some of the same reasons that I
> do support segwit: Bitcoin is valuable in part because it has high
> security and stability, segwit was carefully designed to support and
> amplify that engineering integrity that people can count on now and
> into the future.
>
> I do not feel the the approach proposed in BIP148 really measures up
> to the standard set by segwit itself, or the existing best practices
> in protocol development in this community.
>
> The primary flaw in BIP148 is that by forcing the activation of the
> existing (non-UASF segwit) nodes it almost guarantees at a minor level
> of disruption.
>
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.
>
> Older nodes will not include segwit spends, and so their blocks will
> not be invalid even if they do not have segwit support. They can
> upgrade to it on their own schedule. The only risk non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it, a risk many miners already
> frequently take with spy-mining.
>
> I do not think it is a horrible proposal: it is better engineered than
> many things that many altcoins do, but just not up to our normal
> standards. I respect the motivations of the authors of BIP 148. If
> your goal is the fastest possible segwit activation then it is very
> useful to exploit the >80% of existing nodes that already support the
> original version of segwit.
>
> But the fastest support should not be our goal, as a community-- there
> is always some reckless altcoin or centralized system that can support
> something faster than we can-- trying to match that would only erode
> our distinguishing value in being well engineered and stable.
>
> "First do no harm." We should use the least disruptive mechanisms
> available, and the BIP148 proposal does not meet that test. To hear
> some people-- non-developers on reddit and such-- a few even see the
> forced orphaning of 148 as a virtue, that it's punitive for
> misbehaving miners. I could not not disagree with that perspective any
> more strongly.
>
> Of course, I do not oppose the general concept of a UASF but
> _generally_ a soft-fork (of any kind) does not need to risk disruption
> of mining, just as segwit's activation does not. UASF are the
> original kind of soft-fork and were the only kind of fork practiced by
> Satoshi. P2SH was activated based on a date, and all prior ones were
> based on times or heights. We introduced miner based activation as
> part of a process of making Bitcoin more stable in the common case
> where the ecosystem is all in harmony. It's kind of weird to see UASF
> portrayed as something new.
>
> It's important the users not be at the mercy of any one part of the
> ecosystem to the extent that we can avoid it-- be it developers,
> exchanges, chat forums, or mining hardware makers. Ultimately the
> rules of Bitcoin work because they're enforced by the users
> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
> something people can count on: the rules aren't easy to just change.
>
> There have been some other UASF proposals that avoid the forced
> disruption-- by just defining a new witness bit and allowing
> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
> think they are vastly superior. They would be slower to deploy, but I
> do not think that is a flaw.
>
> We should have patience. Bitcoin is a system that should last for all
> ages and power mankind for a long time-- ten years from now a couple
> years of dispute will seem like nothing. But the reputation we earn
> for stability and integrity, for being a system of money people can
> count on will mean everything.
>
> If these discussions come up, they'll come up in the form of reminding
> people that Bitcoin isn't easily changed at a whim, even when the
> whims are obviously good, and how that protects it from being managed
> like all the competing systems of money that the world used to use
> were managed. :)
>
> So have patience, don't take short cuts. Segwit is a good improvement
> and we should respect it by knowing that it's good enough to wait for,
> and for however its activated to be done the best way we know how.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:57:54

- reply

📅 Original date posted:2017-03-25
📝 Original message:<pre>
BIP: ???
Layer: Consensus (soft fork)
Title: Strong Anti-Replay via Coinbase Transactions
Author: Cameron Garnham <da2ce7 at gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???
Status: Draft
Type: Standards Track
Created: 2017-03-25
License: BSD-3-Clause
CC0-1.0
</pre>
==Abstract==
This document specifies a soft fork that enables users to make transactions with a strong expectation that such transactions cannot be replayed on a different chain.
Important Note: In the case that an adversary hard-fork, the strong guarantee of non-replayabilty via this BIP may not be supported.
==Definitions==
==Motivation==
In the case of a chain split, it is important to protect users from, potentially significant, loss of funds from transaction replay attacks.
==Specification==
Upon activation of the soft-fork (activation methodology undefined in this proposal), the following new rules become activated on the Bitcoin Network.
New ‘anti-replay’ OpCode. Take an unused NoOp and redefine it as ‘OP_ANTI_REPLAY’.
The script must only have the form:
scriptPubKey: (empty)
scriptSig: OP_ANTI_REPLAY
OP_ANTI_REPLAY has the following specification:
• OP_ANTI_REPLAY outputs must only be created in a coinbase transaction.
• OP_ANTI_REPLAY coinbase outputs must only have the value of 1 Satoshi.
• Transaction must not included more than 1 OP_ANTI_REPLAY input.
• If a OP_ANTI_REPLAY input is included in a transaction, the transaction must also be marked as Opt-In-RBF (BIP 125).
The Bitcoin Network should maintain a total of exactly 100 000 OP_ANTI_REPLAY outputs, with the exception of the the first 99 blocks after activation of this soft fork.
Upon activation of this soft fork. Every blocks coinbase transaction will be required to create exactly 1000 new OP_ANTI_REPLAY outputs, up to the total of 100 000.
If a OP_ANTI_REPLAY is spent in a block, a corresponding new OP_ANTI_REPLAY must be included in the same block.
It is recommend the miners account the size of a OP_ANTI_REPLAY transaction as: transactions size + size of a OP_ANTI_REPLAY output in coinbase.
In the case of an chain split after this BIP has activated, miners should ‘recycle’ all the OP_ANTI_REPLAY outputs via spending and recreating them in new blocks. Renewing the protection to the new chain.
=== Reference implementation ===
To-Be-Implemented
==Backwards Compatibility==
This deployment is compatible with all existing bitcoin software.
Upon activation, all deployed Bitcoin Full Nodes will enforce the anti-replay projections for Bitcoin Users. (Only upgraded nodes will enforce the other OP_ANTI_REPLAY requirements).
==Rationale==
The only know way of guaranteeing that a transaction cannot be replayed is to include an input that cannot exist, by-definition, on the alternative chain. Coinbase transactions are the only transaction type that is know to exhibit this property strongly.
This BIP makes it convenient for wallets to automate the inclusion of new coinbase inputs into transactions that spend potentially repayable transactions. Everything in this BIP could be done manually by close cooperation between the users and miners, however the author thinks that it is preferable to have it well-defined and enforced.
On Opt-In-RBF enforcement: In the case of conflicting spends of OP_ANTI_REPLAY outputs, the higher-fee transaction should take priority. Wallets may select a random OP_ANTI_REPLAY, then check if the competing transaction has a sufficiently low fee to be replaced.
It is expected that every OP_ANTI_REPLAY output will be in the memory pools waiting to be spend; users must compete for this resource.
==Future Questions==
SegWit Compatibility?
==References==
Opt-In-RBF: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.

2023-06-07 19:51:39

- reply

📅 Original date posted:2016-06-28
📝 Original message:There are two different topics mixed up here.
1. Link-level security (secure connection to the node we intended to connect to).
2. Node-level security (aka; don't connect to a 'evil node').
The fist requires link-level encryption and authentication.
The second requires identity authentication.
You described the 'evil node' attack; that indeed needs an identity system to stop. However BIP151 doesn't intend to protect against connecting to evil Bitcoin Nodes.
It is important not to mixup link-level authentication and node-level authentication.
When your client picks random nodes to connect to, you are not considered whom in particular runs them. (Rather that you have a good random sample of the network).
If you manually add a friends node; at this point you wish to have node-level authentication. However, this may (and probably should) happen out-of-band.
Sent from my iPhone
> On 29 Jun 2016, at 01:07, Eric Voskuil <eric at voskuil.org> wrote:
>
> Hi Cameron, good to hear from you!
>
>> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7 at gmail.com> wrote:
>>
>> Unauthenticated link level encryption is wonderful! MITM attacks are overrated; as they require an active attacker.
>
> This is not really the case with Bitcoin. A MITM attack does not require that the attacker find a way to inject traffic into the communication between nodes. Peers will connect to the attacker directly, or accept connections directly from it. Such attacks can be easier than even passive attacks.
>
>> Stopping passive attacks is the low hanging fruit. This should be taken first.
>>
>> Automated and secure peer authentication in a mesh network is a huge topic. One of the unsolved problems in computer science.
>>
>> A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication. Semi-trusted index nodes also is a low hanging fruit for authentication.
>
> It is the implication of widespread authentication that is at issue. Clearly there are ways to implement it using a secure side channels.
>
>> However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct).
>>
>> Sent from my iPhone
>>
>>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> An "out of band key check" is not part of BIP151.
>>>
>>> It has a session ID for this purpose.
>>>
>>>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>>>
>>> One might wonder how you ever use a Bitcoin address, or even why we
>>> might guess these emails from "you" aren't actually coming from the
>>> NSA.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160629/49c7f475/attachment-0001.html>

2023-06-07 19:51:38

- reply

📅 Original date posted:2016-06-28
📝 Original message:Unauthenticated link level encryption is wonderful! MITM attacks are overrated; as they require an active attacker.
Stopping passive attacks is the low hanging fruit. This should be taken first.
Automated and secure peer authentication in a mesh network is a huge topic. One of the unsolved problems in computer science.
A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication. Semi-trusted index nodes also is a low hanging fruit for authentication.
However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct).
Sent from my iPhone
> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> An "out of band key check" is not part of BIP151.
>
> It has a session ID for this purpose.
>
>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>
> One might wonder how you ever use a Bitcoin address, or even why we
> might guess these emails from "you" aren't actually coming from the
> NSA.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160629/436fe397/attachment-0001.html>

2023-06-07 19:35:29

- reply

📅 Original date posted:2015-08-16
📝 Original message:Since it was a game theory analysis. I will not address your other comments.
On 17/8/2015 7:22 AM, Andrew LeCody wrote:
>> 4. Setup a fork of Bitcoin XT that allows people to easily make a
> transaction only on the XT fork (while leaving the original BTC coins
> untouched).
>
> I doubt this is even possible.
Trivial.
There are a few ways: here is my favorite (for the moment).
1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet 'BitcoinXT'
2. Let these spam tx be in BitcoinXT, however not Bitcoin (easily done).
3. Let the forked XT client includes a unspent dust output with any
transaction. Let the this client create 100 dust outputs for other
people to use in the same transaction.
This transaction will only be possible to confirm with Bitcoin XT. -
Leaving your Bitcoin coins untouched.
I particularly like this approach, as it is ironic as the spam is more
cheaply done with larger blocks.
Cam.
A quick political note:
https://en.wikipedia.org/wiki/Abstentionism
Hard forks are not something that is a democratic process. Thus
frustrating a false-democratic process is completely legitimate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/3b5b455b/attachment.sig>

2023-06-07 19:35:28

- reply

📅 Original date posted:2015-08-16
📝 Original message:I think that it is important to note that Bitcoin XT faces a natural
uphill battle.
Since it is possible to setup atomic inter-fork coin trades. I do not
see how Bitcoin XT could possibly win if Satoshi decides to sell 10000
XTBTC for BTC everyday for the first 100 days after the fork.
In many ways Satoshi gets to decide the winning fork just by his huge
economic investment in Bitcoin.
Here is some simple game-theory for non-consensus forks:
1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
string.
2. Encourage all miners to false vote for the Bitcoin XT fork.
- Now people have no-idea what % of the economy Bitcoin XT holds. -
Making it impossible for people to put economic faith behind Bitcoin XT.
3. Setup good Atomic Swap markets.
4. Setup a fork of Bitcoin XT that allows people to easily make a
transaction only on the XT fork (while leaving the original BTC coins
untouched).
This means that the Bitcoin XT fork will be born per-mature. Probably
with only a small % of hashing power behind it (contrary to the almost
100% that falsely claim to support it). It will be embarrassing that for
the goal of larger blocks, XT instead has blocks (before re-adjustment)
every 2h.
The price for XTBTC coins will plummet, Satoshi progressively dumping
his 1M stash over a year or so will make sure that it doesn't recover
either.
I cannot see how Bitcoin XT is but-not in a extremely weak position from
game theory.
I'm sure smarter people than I could come up with even more ways to
disrupt non-consensus forks.
Cam.
On 16/8/2015 6:39 AM, muyuubyou via bitcoin-dev wrote:
> I posted this to /r/BitcoinMarkets but I thought I might post it here as
> well.
>
> ---
> Currently 0 mined blocks have voted for XT.
>
> If it ever gets close to even 50%, many things can happen that would
> reshape the game completely.
>
> For instance:
>
> - Core could start boycotting XT by not relying to them and/or not relying
> from them.
>
> - Core could appropriate the version string of XT, making it impossible to
> know how much they are progressing and a losing bet to actually execute the
> fork.
>
> This kind of node war if the factions were sizeable would make it very
> risky to transact at all - balances in new addresses could end up
> vanishing. Usability of the system would plummet.
>
> Note that any disagreement between the network and the biggest economic
> actors - mainly the exchanges at this point, "wallet services" maybe -
> would mean BTC plummets. Hard. And so would confidence.
>
> It's a risky game to play.
> ---
>
> PS: I consider this attempt at takeover about as foul as it gets. The
> equivalent of repeating a referendum until a yes is obtained: the
> reasonable reaction to this is actively blocking said "referendum". There
> was a fair play alternative which is voting through coinbase scriptSig like
> plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
> Once a majority is obtained in this way, devs have to react or if they
> don't then this sort of foul play would be justified. But this wasn't the
> case.
>
> -----
> 為せば成る
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/2ad9196d/attachment.sig>

2023-06-07 17:47:16

- reply

2023-06-07 17:47:15

- reply

2023-06-07 17:34:09

- reply

📅 Original date posted:2015-05-29
📝 Original message:First off, I am glad that the idea of dynamic block size adjustment is
gaining some attention, in particular the model that I proposed.
I wanted to take some time and explain some of the philosophy of how,
and why, I proposed this this particular model.
When Bitcoin was first made, there was a 32MB block size limit; this
was quickly found to be open to spam (and potentially DOS, as the code
was not-at-all optimized to support large blocks), and was reduced to
1MB, this was a quick fix that was never intended to last; at some
point the network should come to an understanding, a consensus if you
will, of what (and how much) belongs in a block.
The core point of this is that miners have always, and will always;
hold the power, to decide what goes into blocks; this implicitly,
obviously, includes how large blocks are. Miners are able to come any
sort of agreement they wish, providing the bitcoin clients accept
their blocks as valid.
Say if Satoshi never decided to place the 1MB block limit: It would be
up to the miners to decide what they consider a ‘reasonable’ block is.
However, they would need to find some way to communicate this and
reach an agreement; some protocol. They, say, could have done this
informally on what is now the bitcointalk forum, or used Twitter.
However, what they really need is indeed a "consensus protocol". Some
simple terms to define what is acceptable and what is not.
Hence, the proposal introducing a consensus protocol for block sizes;
instead of just having a hard limit (enforced by everyone), instead,
we have a constant factor above the average block size over a fixed
intervals that is soft-forked by only the miners. (The next simplest
mathematical construct).
This proposal is entirely a soft-fork and may be implemented without
changing any client code what so ever. In-fact, it could be
implemented by only a simple 51% majority of miners, with-or-without
gaining the wider community consensus. (Assuming that the 1MB block
size rule still applies).
The nice thing about this is that it really is impossible to stop,
for-example, if pre-relaying of block headers is implemented; the
miners could always soft-fork to include the block-size in the
coinbase. The only reason that the miners have not done this yet, is
that there has not yet been a strong will to increase transaction fees.
If we assume the miners will operate in a way to collectively maximize
profit; then we can assume they will not try to maximize utility of
the network (having as many transactions as possible), rather have as
few transactions as the total economy can support the cost. Meaning
that limiting to much smaller blocks will probably be much more
profitable than having large blocks.
Since there is no requirement for the clients to know about the block
size consensus protocol, this truly can be a
‘bi-directional-soft-fork’, in that the miners can choose to change
the rules at any time, with only a simple 51% majority. Therefore, any
parameters that we pick are always up for debate.
Why the 1.5x over 2016 blocks? - Using some game theory, and
deduction: I wished to pick the type of agreement that would be
natural for the miners to come to (selfishly).
First, Why 1.5x, this means that only a super-majority of miners can
easily increase the block size. – There is no natural incentive for
miners to produce large blocks that have very few fees.
Second, Why 2016 blocks for adjusting the average: Miners HATE
unpredictability, for shorter time periods the miner will need to have
infrastructure ready to support potentially much larger block almost
immediately. 2016 blocks is a period that the miners are already well
used to, meaning that it will take slightly less than a month for
blocks of double size to be permitted.
This entire infrastructure can be implemented without needing to
update any clients; once implemented, tested, solid, and well accepted
by the (mining) community then we can revisit increasing the 1M hard
limit. (If we still have demand for it, maybe the average block size
will reduce to say, 100KB).
Cam.
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>
> While being in the Bitcoin community for a long time, I haven't
> been so directly involved in the development. However I wish to
> suggest a different pre-hard-fork soft-fork approach:
>
>
> Set a 'block size cap' in the similar same way as we set
> difficulty.
>
> Every 2016 blocks take the average size of the blocks and multiply
> the size by 1.5x, rejecting blocks that are larger than this size,
> for the next 2016 period.
>
> I would of-course suggest that we keep the limits at min 100kb and
> max (initially) 990kb (not 1mb on purpose, as this should become
> the new limit), rounding up to the nearest 10kb.
>
> A: we don't have pressure at the 1mb limit, (we reduce the limit in
> a flexible manner to 990kb).
>
> B: we can upgrade the network to XYZ hard-limit, then slowly raze
> the soft-limit after being sure the network, as-a-whole is ready.
>
> If we on-day remove the block-size limit, this rule will stop a
> rouge miner from making 10mb, or 100mb blocks, or 1gb blocks.
>
> This could be implemented by the miners without breaking any of
> the clients, and would tend to produce a better dynamic fee
> pressure.
>
>
> This will give the mechanics to the miners to create consensus to
> agree what block-sizes they believe are best for the network, and
> allows the block-sizes to dynamically grow in response to larger
> demand.
>
>
>
> On 5/8/2015 10:35 AM, Pieter Wuille wrote:
>> On May 7, 2015 3:08 PM, "Roy Badami" <roy at gnomon.org.uk> wrote:
>>>
>>> On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
>>>> I would not modify my node if the change introduced a
>>>> perpetual 100 BTC subsidy per block, even if 99% of miners
>>>> went along with it.
>>>
>>> Surely, in that scenario Bitcoin is dead. If the fork you
>>> prefer has only 1% of the hash power it is trivially vulnerably
>>> not just to a 51% attack but to a 501% attack, not to mention
>>> the fact that you'd only be getting one block every 16 hours.
>>
>> Yes, indeed, Bitcoin would be dead if this actually happens. But
>> that is still where the power lies: before anyone (miners or
>> others) would think about trying such a change, they would need
>> to convince people and be sure they will effectively modify
>> their code.
>>
>>
>>
>> ----------------------------------------------------------------------
>
>>
- --------
>>
>>
> One dashboard for servers and applications across
> Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable
>> Insights Deep dive visibility with transaction tracing using APM
>> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
>
> iF4EAREIAAYFAlVMKZYACgkQBJ8cMDO159aTiQEApTITEBrhE1DRbj/w+GncNeqB
> 0hGvmIBa1z0hGww0kaMBAOhxjn/K5leRJgdt1fKhNEDKKHdeCOIX3QRgry90D3NO
> =p0+H -----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150530/f41e56f7/attachment.sig>

2023-06-07 17:33:38

- reply

📅 Original date posted:2015-05-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
While being in the Bitcoin community for a long time, I haven't been
so directly involved in the development. However I wish to suggest a
different pre-hard-fork soft-fork approach:
Set a 'block size cap' in the similar same way as we set difficulty.
Every 2016 blocks take the average size of the blocks and multiply the
size by 1.5x, rejecting blocks that are larger than this size, for the
next 2016 period.
I would of-course suggest that we keep the limits at min 100kb and max
(initially) 990kb (not 1mb on purpose, as this should become the new
limit), rounding up to the nearest 10kb.
A: we don't have pressure at the 1mb limit, (we reduce the limit in a
flexible manner to 990kb).
B: we can upgrade the network to XYZ hard-limit, then slowly raze the
soft-limit after being sure the network, as-a-whole is ready.
If we on-day remove the block-size limit, this rule will stop a rouge
miner from making 10mb, or 100mb blocks, or 1gb blocks.
This could be implemented by the miners without breaking any of the
clients, and would tend to produce a better dynamic fee pressure.
This will give the mechanics to the miners to create consensus to
agree what block-sizes they believe are best for the network, and
allows the block-sizes to dynamically grow in response to larger demand.
On 5/8/2015 10:35 AM, Pieter Wuille wrote:
> On May 7, 2015 3:08 PM, "Roy Badami" <roy at gnomon.org.uk> wrote:
>>
>> On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
>>> I would not modify my node if the change introduced a perpetual
>>> 100 BTC subsidy per block, even if 99% of miners went along
>>> with it.
>>
>> Surely, in that scenario Bitcoin is dead. If the fork you prefer
>> has only 1% of the hash power it is trivially vulnerably not just
>> to a 51% attack but to a 501% attack, not to mention the fact
>> that you'd only be getting one block every 16 hours.
>
> Yes, indeed, Bitcoin would be dead if this actually happens. But
> that is still where the power lies: before anyone (miners or
> others) would think about trying such a change, they would need to
> convince people and be sure they will effectively modify their
> code.
>
>
>
> ----------------------------------------------------------------------
- --------
>
>
One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable
> Insights Deep dive visibility with transaction tracing using APM
> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlVMKZYACgkQBJ8cMDO159aTiQEApTITEBrhE1DRbj/w+GncNeqB
0hGvmIBa1z0hGww0kaMBAOhxjn/K5leRJgdt1fKhNEDKKHdeCOIX3QRgry90D3NO
=p0+H
-----END PGP SIGNATURE-----

2023-06-07 17:25:26

- reply

📅 Original date posted:2014-08-20
📝 Original message:We should aim to use perfect forward secrecy between all nodes by default.
This forces the attacker to do a MITM attack that is far more expensive on
the large scale.
I don't see why this is seen as so controversial. It is relatively cheap
to implement on our side, and has a dramatic increase of cost for any
attackers.
Cam.
On 20/08/2014 5:49 am, "Un Ix" <slashdevnull at hotmail.com> wrote:
> Excuse the ignorance, but there is something I’m not getting in this
> discussion.
>
> Given it’s a published protocol, with available source code running on an
> open P2P network, why would any messages between nodes benefit from being
> encrypted? Surely all the data being processed by the network is known to
> any persistent client node(s)?
>
> Seems like that solution is orthogonal to the root problem, where
> attackers could monitor the network and deduce IP addresses by e.g. mapping
> senders of transactions.
>
> *From:* Peter Todd <pete at petertodd.org>
> *Sent:* ‎Wednesday‎, ‎August‎ ‎20‎, ‎2014 ‎9‎:‎28‎ ‎AM
> *To:* William Yager <will.yager at gmail.com>,
> bitcoin-development at lists.sourceforge.net
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 19 August 2014 21:19:43 GMT-04:00, William Yager <will.yager at gmail.com>
> wrote:
> >On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd <pete at petertodd.org> wrote:
> >> In any case, my suggestion of enabling hidden service support by
> >default
> >> adds both encryption and reasonably good authentication.
> >
> >
> >Enabling hidden service support by default would introduce an insanely
> >huge
> >attack surface.
>
> Hence my suggestion of separating that surface by using the standalone Tor
> binary, which runs under a different user to the Bitcoin Core binary.
>
> >And you're conflating two different things; using Tor is valuable to
> >Bitcoin because it would provide some anonymity. The encryption aspect
> >is
> >pretty much useless for us.
>
> First of all, without encryption we're leaking significant amounts of
> information to any passive attacker trying to trace the origin of Bitcoin
> transactions, a significant privacy risk.
>
> Secondly the upcoming v0.10's fee estimation implementation is quite
> vulnerable to Sybil attacks. Authentication and encryption are needed to
> make it secure from ISP-level targeting to ensure that your view of the
> network is representative. Tor support used in parallel with native
> connection is ideal here, as neither the Tor network nor your ISP alone can
> Sybil attack you. It's notable that Bitcoinj has already implemented Tor
> support for these same reasons.
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQFQBAEBCAA6BQJT8/mSMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRZjCAC4PSpQ68qgtFMR77xf
> zXZLr/iMKX6yyJwXRj+vGi+0Ng/sv9NlYjYnDeflom37WlpGo/sCOFcVWImhnS2d
> kUFoUH92iXwRuEt/SN/LrHghkLWOxtVu9wa49eS/piGZFF3JWllk82MgdBZ6vjNw
> B6WuInEIurK+h8rUbAi2HjFkxVN0K0SsrFt/P0tHj10ABcMealBRoJh2Jx7fLNdS
> uTKddqeLyThEpLGNti3k+lhwQ2dA5RUBq6q3GUS/hWvTHRnU+viGMJSYv62LXRN5
> t87BXRY/R9UBpnudf3TIlPtOuIWcv2LhlXVjvbDDQqwJkvB3Qf4ejE3RZ28S5IUr
> OBQH
> =Gy7X
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140820/633971c4/attachment.html>

2023-06-07 17:11:48

- reply

📅 Original date posted:2014-01-17
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
One of the possible words that haven't been proposed is 'personal' where
bitcoin addressed are commonly incorrectly called public address.
Maybe 'personal account' or even 'personal address' would imply that the
balance on such an account shouldn't be assumed to be public knowledge.
Cam.
On 17/01/2014 5:59 pm, Drak wrote:
> That could also work. Still, didn't we want to ditch the word address?
> Could be a privacy key...
>
> On 17 Jan 2014 09:15, "Mike Hearn" <mike at plan99.net
> <mailto:mike at plan99.net>> wrote:
>
> I must say, this shed is mighty fine looking. It'd be a great place
> to store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"? As
> Peter notes, that's what people actually like and want. The problem
> with stealth is it's got strong connotations with American military
> hardware and perhaps thieves sneaking around in the night:
>
> https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak at zikula.org
> <mailto:drak at zikula.org>> wrote:
>
> Peter I agree with you about "reusable addresses", but aren't
> we also trying to get away from the word "address" entirely?
> How about calling it a "payment key" or "reusable payment key"
> instead? using "stealth" is just asking for bad press imo.
>
>
> On 16 January 2014 21:28, Peter Todd <pete at petertodd.org
> <mailto:pete at petertodd.org>> wrote:
>
> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
> > Might I propose "reusable address".
> >
> > I think that describes it best to any non-programmer, and
> even more
> > so encourages wallets to present options as 'one time use' vs
> > 'reusable'.
> >
> > It definitely packs a marketing punch which could help drive
> > adoption. The feature is only useful if/when broadly adopted.
>
> I'm very against the name "reusable addresses" and strongly
> belive we
> should stick with the name stealth addresses.
>
> You gotta look at it from the perspective of a user; lets
> take standard
> pay-to-pubkey-hash addresses: I can tell my wallet to pay
> one as many
> times as I want and everything works just great. I also can
> enter the
> address on blockchain.info <http://blockchain.info>'s search
> box, and every transaction related
> to the address, and the balance of it, pops up immediately.
>
> What is that telling me? A: Addresses starting with "1" are
> reusable. B:
> Transactions associated with them appear to be public knowledge.
>
> Now I upgrade my wallet software and it says I now have a
> "reusable"
> address. My reaction is "Huh? Normal addresses are reusable,
> what's
> special about this weird reusable address thing that my
> buddy Bob's
> wallet software couldn't pay." I might even try to enter in
> a "reusable"
> address in blockchain.info <http://blockchain.info>, which
> won't work, and I'll just figure
> "must be some new unsupported thing" and move on with my life.
>
> On the other hand, suppose my wallet says I now have
> "stealth address"
> support. I'm going to think "Huh, stealth? I guess that
> means privacy
> right? I like privacy." If I try searching for a stealth
> address on
> blockchain.info <http://blockchain.info>, when it doesn't
> work I might think twig on "Oh right!
> It said stealth addresses are private, so maybe the
> transactions are
> hidden?" I might also think "Maybe this is like
> stealth/incognito mode
> in my browser? So like, there's no history being kept for
> others to
> see?" Regardless, I'm going to be thinking "well I hear
> scary stuff
> about Bitcoin privacy, and this stealth thing sounds like
> it's gonna
> help, so I should learn more about that"
>
> Finally keep in mind that stealth addresses have had a tonne
> of very
> fast, and very wide reaching PR. The name is in the public
> conciousness
> already, and trying to change it now just because of vague bad
> associations is going to throw away the momentum of that
> good PR and
> slow down adoption. Last night I was at the Toronto Bitcoin
> Meetup and I
> based on conversations there with people there, technical and
> non-technical, almost everyone had heard about them and
> almost everyone
> seemed to understand the basic idea of why they were a good
> thing. That
> just wouldn't have happened with a name that tried to hide
> what stealth
> addresses were for, and by changing the name now we risk
> people not
> making the connection when wallet software gets upgraded to
> support
> them.
>
> --
> 'peter'[:-1]@petertodd.org <http://petertodd.org>
> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In
> Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In
> Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREKAAYFAlLZj5cACgkQBJ8cMDO159YxKQEAh8QHHgMaL1IVvfYROU0yKG89
Ap1byTpAvt/+O5chTGQBAK4K+DfUOOkaMvUmssWIVsLQ56xKxsuzZiIJXF2yPI0g
=fcYD
-----END PGP SIGNATURE-----

2023-06-07 13:39:14

- reply

📅 Original date posted:2013-03-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I think that the course of action is quite simple:
1. Upgrade all the clients to implement the lock limits. (in code,
not at the DB exception layer). A bit of research is needed to work
out exactly what these limits are so we can maximise the number of
transactions.
2. Fix the DB layer, and test that all the clients can support 1MB blocks.
3. Once we are confident that the network supports 1MB blocks, set a
date where the lock limits are removed.
For me, everyone signed up to bitcoin thinking that there was a 1MB /
block limit. The lock limits were unexpected, and could be considered
extremely uncontroversial to remove.
The discussion of larger blocks (i.e. > 1MB ), that I happen to
disagree with, is not relevant to the discussion of the removal of
the lock limits.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlFBF0QACgkQBJ8cMDO159aWbwEAs8Ldt8hRpzjS4HdrH3U9Jnaq
MWhifXqkJuVC0TVCz3EBAOAfSogdSS7rJvtfV8FqTIox1ek/xJxuHvZdonUnQN1K
=I5Cf
-----END PGP SIGNATURE-----

2023-06-07 12:26:29

- reply

📅 Original date posted:2012-07-29
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I'm not a vendor, however I have a code-signing key for windows; I could
sign the windows installer and binary.
On 30/07/2012 3:15 AM, Luke-Jr wrote:
> On Sunday, July 29, 2012 10:17:51 AM Mike Hearn wrote:
>> I guess Gavin would be the final signer.
>
> Considering that Gavin is not interested in participating in any way in the
> stable versions, I would prefer to see someone else responsible for OS-vendor
> signing.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAlAV8ZYACgkQBJ8cMDO159ZNVgD+KsQUlNcTDSmTGaHvLbAw0Cxy
OCDfnsFbaiLoX2xWP3MBAOnN/QvcYY8f2WzMfI+N1PfnydRYGxlkA2JZ2Nrtnxcv
=qeUe
-----END PGP SIGNATURE-----

2023-06-07 05:00:18

- reply

📅 Original date posted:2012-01-31
📝 Original message:On 1/02/2012 00:12, Gavin Andresen wrote:
> RE: BIP 21 versus BIP 20: I like BIP 21; simpler is better.
>
> RE: signing and dating URIs: good ideas. I think we should agree
> that there is consensus around BIP 21 and then after there is some
> experience with signing/dating URIs you should write follow-up BIPs .
>
If we had a self signed URI, we could just pay directly to the public
key (or calculate the bitcoin address from it). It
would no longer require a bitcoin address in the URI.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x33B5E7D6.asc
Type: application/pgp-keys
Size: 2647 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120201/05727153/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x33B5E7D6.asc
Type: application/pgp-keys
Size: 2646 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120201/05727153/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 283 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120201/05727153/attachment.sig>

2023-06-07 04:56:21

- reply

📅 Original date posted:2012-01-17
📝 Original message:I think that bitcoin.org should remain apolitical. However maybe it
would be good if the blackout to take effect on bitcointalk.org if
theymos and Sirius believes it is appropriate.
Bitcoin.org should provide bitcoin.
On 17/01/2012 11:59 AM, slush wrote:
> > I agree Bitcoin should avoid making any bold political stands.
>
> I agree on this. Please don't turn Bitcoin project/homepage into some
> political agitation. Not everybody care about political attitude of
> main project developers.
>
> slush
>
> On Tue, Jan 17, 2012 at 1:46 AM, Alan Reiner <etotheipi at gmail.com
> <mailto:etotheipi at gmail.com>> wrote:
>
> You guys are representing both extremes of the issue. In response
> to Jeff and Luke-Jr, I don't see how this is /just any other
> poltical issue/. It strikes at the heart of everything Bitcoin is
> about. Barring Bitcoin-specific legislation, I don't see how any
> legislation could be more relevant to Bitcoin and the community
> around it.
>
> On the other hand, Bitcoin is still a non-entity, and shouldn't
> get in the business of making statements. A central voice for
> Bitcoin gives the impression that it is actually centralized, and
> one that has opinions. Plus I wouldn't be surprised if some,
> heavily-invested Bitcoin users were of the opinion that
> SOPA/PIPA/whatever could be a huge profit for themselves: once
> SOPA kicks in and businesses around the world start getting cut
> off for legit or illegitimate purposes, a lot of them could
> potentially switch to Bitcoin to keep their business going. That
> could be a huge boon for Bitcoin. You may not agree it's worth
> the tradeoff, but people are selfish and may not actually
> understand or even care about SOPA legislation itself.
>
> I think it's /not inappropriate/ for something to be mentioned on
> the website about Bitcoin's philosophy being threatened by SOPA,
> but I agree Bitcoin should avoid making any bold political
> stands. Users could be reminded that SOPA affects yet another
> thing they care about, but it might be better to avoid it
> altogether. If any response is made, it should be a very light one.
>
> -Alan
>
>
>
> On 01/16/2012 07:30 PM, Amir Taaki wrote:
>> Bunk argument. This is an issue that affects bitcoin directly.
>>
>> Wikipedia has far more need to remain neutral and apolitical than bitcoin ever does- you've read Satoshi's politically charged whitepaper or seen the genesis block quote.
>>
>> http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action
>>
>> The Wikipedia community decided on a full and global blackout. Bitcoin should do the same in unison with the rest of the web- sites like Reddit, 4chan and Wikipedia.
>>
>> It's funny / almost comical how you consign this to being just another issue or case of moral alarm. Sad.
>>
>>
>>
>> ----- Original Message -----
>> From: Jeff Garzik<jgarzik at exmulti.com> <mailto:jgarzik at exmulti.com>
>> To: Amir Taaki<zgenjix at yahoo.com> <mailto:zgenjix at yahoo.com>
>> Cc:"bitcoin-development at lists.sourceforge.net" <mailto:bitcoin-development at lists.sourceforge.net> <bitcoin-development at lists.sourceforge.net> <mailto:bitcoin-development at lists.sourceforge.net>
>> Sent: Sunday, January 15, 2012 10:37 PM
>> Subject: Re: [Bitcoin-development]bitcoin.org <http://bitcoin.org> SOPA/PIPA blackout
>>
>> On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki<zgenjix at yahoo.com> <mailto:zgenjix at yahoo.com> wrote:
>>> How is this not the most important world issue right now?
>>>
>>> EVERYTHING is under threat. Go nuclear to show our nerd-rage.
>>>
>>> Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy.
>> There are always issues that raise ire and moral outrage. I would
>> rather thatbitcoin.org <http://bitcoin.org> stay apolitical -- our users will appreciate
>> this in the long run.
>>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft
> developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
> MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120117/b2a27c23/attachment.html>

2023-06-07 04:48:43

- reply

📅 Original date posted:2011-12-13
🗒️ Summary of this message: Namecoin is a secure, unique human-rememberable string system that can use the same private keys as Bitcoin, making it a convenient option for end-users.
📝 Original message:Namecoin makes sense; as we can use the same private keys to spend the
namecoin as spending the bitcoins.
Namecoin happens to be the only secure guaranteed global unique human
rememberable string system that exists.
I suggest that sending bitcoins to a namecoin name is the way to go...
It makes even more sense since namecoin started merged mining.
On 13 December 2011 08:03, Cameron Garnham <da2ce7 at gmail.com> wrote:
>
> Sent from my Windows Phone
> De: Amir Taaki
> Enviado: 13/12/2011 0:43
> Para: bitcoin-development at lists.sourceforge.net
> Asunto: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> > I'm confused about the problem we're trying to solve.
>
> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on
> the wall a picture of their QR code and a bitcoin address. I don't own
> a mobile phone so the QR code is
> useless. Then I remembered FirstBits, went to my terminal and typed
> 1brmlab. I got their bitcoin address from the website and copied that,
> then opened my terminal and pasted that in to send 1 BTC.
>
> And
> these proposals for Namecoin, would make bitcoin implementations
> dependent on unproven technology. HTTPS/DNSSEC have been around a long
> time and are responsible for many mission critical systems. There's a
> lot of momentum behind those projects. Namecoin by contrast, could die
> tomorrow. And it isn't a big deal that they're centralised. This is a
> convenience for end users and does not affect the core system much.
>
> tl;dr: usability
>
>
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Cameron Garnham:
email: da2ce7 at gmail.com
website: http://da2ce7.blogspot.com
telephone: +61405227831
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111213/4f763e8f/attachment.html>