<unnamed>

Public Key

npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f

Profile Code

nprofile1qqsykwrqxsy0t0sqyzgjzr5xnfx2sm7z4g0l6zr3qd4qv6qx3mnzdmspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dspv6lhz

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:20:06 CEST

- reply

📅 Original date posted:2019-08-07
📝 Original message:Seems to be comparable to the proposed "Tick Method" from 2013:
https://bitcointalk.org/index.php?topic=307211.msg3308565#msg3308565
However I remember that someone told me the tick method had a flaw..
On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Does revaulting vault up with the same keys, or new ones?
>
> Are they new derivation paths on the same key?
>
> Would love some expanded explanation on how you’re proposing this would
> work.
>
> Thanks,
> Dustin
>
> On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> One of the biggest problems with the vault scheme (besides all of the
>> setup data that has to be stored for a long time) is an attacker that
>> silently steals the hot wallet private key and waits for the vault's
>> owner to make a delayed-spend transaction to initiate a withdrawal
>> from the vault. If the user was unaware of the theft of the key, then
>> the attacker could steal the funds after the delay period.
>>
>> To mitigate this, it is important to choose a stipend or withdrawal
>> amount per withdrawal period like x% of the funds. This limits the
>> total stolen funds to x% because once the funds are stolen the user
>> would know their hot key is compromised, and the user would know to
>> instead use one of the other clawback paths during all of the future
>> withdrawal delay periods instead of letting the delay timeout all the
>> way to the (stolen) default/hot key.
>>
>> The reason why a loss limiter is the way to go is because there's
>> currently no way (that I am aware of, without an upgrade) to force an
>> attacker to reveal his key on the blockchain while also forcing the
>> attacker to use a timelock before the key can spend the coins. I am
>> curious about what the smallest least invasive soft-fork would be for
>> enabling this kind of timelock. There are so many covenant proposals
>> at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,
>> ....). Or there's crazy things like a fork that enables a transaction
>> mode where the (timelock...) script of the first output is
>> automatically prefixed to any of the other scripts on any of the other
>> outputs when an input tries to spend in the future. A thief could add
>> his key to a new output on the transaction and try to spend (just like
>> a user would with a fresh/rotated key), but the OP_CSV would be
>> automatically added to his script to implement the public observation
>> delay window.
>>
>> Also, there was other previous work that I was only informed about
>> today after posting my proposal, so I should mention these as related
>> work:
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html
>>
>> https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better
>> https://www.youtube.com/watch?v=diNxp3ZTquo
>> https://bitcointalk.org/index.php?topic=5111656
>>
>> - Bryan
>> http://heybryan.org/
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/20190807/881ebc3d/attachment.html>

2023-06-07 20:05:55 CEST

- reply

📅 Original date posted:2017-09-22
📝 Original message:The policy seems good with the exception of this paragraph:
* Bitcoin devs will disclose vulnerabilities publically after 99% of the
bitcoin network has upgraded [7], and fixes have been released for
at least 12 months.
99% upgrade may never be reached. Some nodes cannot even be categorized. I
suggest a number close to 95%.
If the 95% of network has upgraded, it means we're pretty secure from the
point of view of consensus. It is supposed that from the time the fix has
been released, all other alt-coins will also have released their fixes.
Remember we must also incentivize security researchers to do the hard and
silent research work. Most of them do not hold Bitcoins. They do research
because of other interests, including getting public acknowledgment for
their findings. They'll be frustrated if they have to wait 2 years.
I propose this paragraph to replace the previous one:
* Bitcoin devs will disclose vulnerabilities publically after 95% of the
bitcoin network has upgraded [7], and fixes have been released for
at least 6 months.
Also I suggest we track vulnerabilities with standard CVE codes. IS there
any drawback of this?
regards
On Thu, Sep 21, 2017 at 11:00 PM, Nathan Wilcox via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> [inline responses]
>
>
> On Thu, Sep 14, 2017 at 2:27 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote:
>> > It would be a good starting point if the current policy could be
>> > clarified, so everyone is on the same page, and there is no confusion.
>>
>> Collecting various commentary from here and reddit, I think current de
>> facto policy is something like:
>>
>> * Vulnerabilities should be reported via security at bitcoincore.org [0]
>>
>> * A critical issue (that can be exploited immediately or is already
>> being exploited causing large harm) will be dealt with by:
>> * a released patch ASAP
>> * wide notification of the need to upgrade (or to disable affected
>> systems)
>> * minimal disclosure of the actual problem, to delay attacks
>> [1] [2]
>>
>> * A non-critical vulnerability (because it is difficult or expensive to
>> exploit) will be dealt with by:
>> * patch and review undertaken in the ordinary flow of development
>> * backport of a fix or workaround from master to the current
>> released version [2]
>>
>> * Devs will attempt to ensure that publication of the fix does not
>> reveal the nature of the vulnerability by providing the proposed fix
>> to experienced devs who have not been informed of the vulnerability,
>> telling them that it fixes a vulnerability, and asking them to identify
>> the vulnerability. [2]
>>
>> * Devs may recommend other bitcoin implementations adopt vulnerability
>> fixes prior to the fix being released and widely deployed, if they
>> can do so without revealing the vulnerability; eg, if the fix has
>> significant performance benefits that would justify its inclusion. [3]
>>
>> * Prior to a vulnerability becoming public, devs will generally recommend
>> to friendly altcoin devs that they should catch up with fixes. But this
>> is only after the fixes are widely deployed in the bitcoin network. [4]
>>
>> * Devs will generally not notify altcoin developers who have behaved
>> in a hostile manner (eg, using vulnerabilities to attack others, or
>> who violate embargoes). [5]
>>
>> * Bitcoin devs won't disclose vulnerability details until >80% of bitcoin
>> nodes have deployed the fixes. Vulnerability discovers are encouraged
>> and requested to follow the same policy. [1] [6]
>>
>> Those seem like pretty good policies to me, for what it's worth.
>>
>>
> I advocate a policy like this, except I propose two modifications:
>
> - Point 4 should include *zero or more* altcoin developers, such that
> those altcoins also deploy mitigations as early as Bitcoin. (Call this
> "early altcoin disclosure".)
>
> - Disclose of vulnerabilities, by social convention, always explicitly
> names which altcoin developers were included in my proposed Early Altcoin
> Disclosure and Point 6.
>
> The rationale is that the policy should allow closer coordination with
> altcoins. If the goal is minimizing economic damage, including altcoins
> earlier may be the better trade-off between inclusiveness and secrecy. At
> the same time, the policy doesn't establish *which* altcoins, which is a
> tricky choice. However it *does* require disclosure of those relationships,
> which provides a form of feedback on the system.
>
> Imagine if altcoin X is compromised, and later disclosure occurs that
> reveals that altcoin X was not contacted early, then this *might* indicate
> leaks, maliciousness in the Bitcoin mitigation organization, or it *might*
> be coincidence or dumb luck. In the other case, if the Bitcoin disclosure
> reveals that X was indeed contacted early, then it probably indicates
> incompetence of the altoin X.
>
> Finally, notice that this kind of loose early disclosure policy can be
> symmetric. For example, Zcash developers may choose to disclose
> vulnerabilities they discover which affect Bitcoin to Bitcoin developers
> *before* Zcash releases fixes, or before those fixes are widely adopted in
> Zcash. We actually have a policy of doing this, since it's obvious that if
> our mitigation process leaks and that's used to attack Bitcoin the
> potential economic damage is very large.
>
>
>
>> I haven't seen anything that indicates bitcoin devs will *ever* encourage
>> public disclosure of vulnerabilities (as opposed to tolerating other
>> people publishing them [6]). So I'm guessing current de facto policy is
>> more along the lines of:
>>
>> * Where possible, Bitcoin devs will never disclose vulnerabilities
>> publically while affected code may still be in use (including by
>> altcoins).
>>
>> rather than something like:
>>
>> * Bitcoin devs will disclose vulnerabilities publically after 99% of the
>> bitcoin network has upgraded [7], and fixes have been released for
>> at least 12 months.
>>
>>
> I advocate for something like the latter case. I'd like to see a timeout
> on disclosure. There's an endless tail of alt-coins that could be affected,
> and no guarantee all will vigilantly upgrade. Meanwhile, deciding which of
> them to disclose to confidentially versus which should just receive hints
> to apply new patches is tricky and political.
>
> Having a global timeout is a reasonable stop-gap. I consider the cost of
> never disclosing, publicly, a known vulnerbility to be very high, even if
> the fix is ubiquitously deployed, because it's a loss of security
> knowledge, a precious public good.
>
>
>>
>> Instinctively, I'd say documenting this policy (or whatever it actually
>> is) would be good, and having all vulnerabilities get publically released
>> eventually would also be good; that's certainly the more "open source"
>> approach. But arguing the other side:
>>
>> - documenting security policy gives attackers a better handle on where
>> to find weak points; this may be more harm than there is benefit to
>> improving legitimate users' understanding of and confidence in the
>> development process
>>
>>
> Publishing a policy *might* increase organizational vulnerability, but so
> might *not publishing* a policy. It seems fairly neutral to me on
> vulnerability impact, whereas the benefit is good for users and developers.
>
>
>
>> - the main benefit of public vulnerability disclosure is a better
>> working relationship with security researchers and perhaps better
>> understanding of what sort of bugs happen in practice in general;
>> but if most of your security research is effectively in house [6],
>> maybe those benefits aren't as great as the harm done by revealing
>> even old vulnerabilities to attackers
>>
>>
> Publishing after a reasonable timeout has many benefits. Many security
> researchers learn from vulnerability disclosures across many disciplines
> and industries. Future protocol designers of things potentially unrelated
> to blockchain altogether may also learn important lessons.
>
>
> If the first of those arguments holds, well, hopefully this message has
>> egregious errors that no one will correct, or it will quickly get lost
>> in this list's archives...
>>
>> Cheers,
>> aj
>>
>>
> regards,
> Nathan Wilcox
> Zcash
>
>
>> [0] http://bitcoincore.org/en/contact
>> referenced from .github/ISSUE_TEMPLATE.md in git
>>
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -September/014986.html
>>
>> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -September/014990.html
>>
>> [3] https://www.reddit.com/r/btc/comments/6zf1qo/peter_todd_nice
>> ly_pulled_away_attention_from_jjs/dmxcw70/
>>
>> [4] https://www.reddit.com/r/btc/comments/6z827o/chris_jeffrey_j
>> j_discloses_bitcoin_attack_vector/dmxdg83/
>>
>> [5] https://www.reddit.com/r/btc/comments/6zb3lp/maxwell_admits_
>> core_sat_on_vulnerability/dmv4y7g/
>>
>> [6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -September/014991.html
>>
>> [7] Per http://luke.dashjr.org/programs/bitcoin/files/charts/branche
>> s.html
>> it seems like 1.7% of the network is running known-vulnerable versions
>> 0.8 and 0.9; but only 0.37% are running 0.10 or 0.11, so that might
>> argue
>> revealing any vulnerabilities fixed since 0.12.0 would be fine...
>> (bitnodes.21.co doesn't seem to break down anything earlier than
>> 0.12)
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> 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/20170922/cdd9e559/attachment.html>

2023-06-07 20:05:53 CEST

- reply

📅 Original date posted:2017-09-12
📝 Original message:Historically people have published vulnerabilities in Bitcoin only after
>80% of the nodes have upgraded. This seems to be the general (but not
publicly stated) policy. If you're a core developer and you know better,
please correct me.
This means that:
- a critical vulnerability, like a remote code execution, will be patched
immediately (without disclosing the actual problem) and all participants
will be notified asap. This is no different from any other open source
project. An example of this case was the OpenSSL Heartbleed vulnerability
that affected Bitcoin.
- a non-critical vulnerability, either because miners only can exploit it
or because it requires vast resources to pull, may require a wait of years
before publication, after a vulnerability was found and reported. This is
because the "natural" node upgrade rate is slow.
It also implies that some times a researcher works hard to investigate a
vulnerability and later he finds out it was previously reported. It also
means that the researcher cannot report to alt-coins which have a different
policy.
This policy has nothing to do with a loyalty to Bitcoin Core (or in fact,
the two or so developers that actually receive the e-mails to
security at bitcoincore.org).
This is a policy that has simply proven to work to protect Bitcoiners. It
began long long ago.
On Tue, Sep 12, 2017 at 12:37 AM, Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote:
> > I don't think I know the right answer here, but I will point out two
> things
> > that make this a little more complicated.
> > 1 - There are lots of altcoin developers and while I'm sure the majority
> would
> > greatly appreciate the disclosure and would behave responsibly with the
> > information, I don't know where you draw the line on who you tell and
> who you
> > don't.
>
> If you can't pick even a small group that's trustworthy (top five by
> market cap as a start [0]? or just major bitcoin wallets / exchanges /
> alt node implementations?), then it still seems better to (eventually)
> disclose publically than keep it unrevealed and let it be a potential
> advantage for attackers against people who haven't upgraded for other
> reasons?
>
> I find it hard to imagine bitcoin's still obscure enough that people
> aren't tracking git commit logs to use them as inspiration for attacks
> on bitcoin users and businesses; at best I would have thought it'd
> only be a few months of development time between a fix being proposed
> as a PR or committed to master and black hats having the ability to
> exploit it in users who are running older nodes. (Or for that matter,
> being able to be exploited by otherwise legitimate bitcoin businesses
> with an agenda to push, a strong financial motive behind that agenda,
> and a legal team that says they'll get away with it)
>
> > 2- Unlike other software, I'm not sure good security for bitcoin is
> defined by
> > constant upgrading. Obviously upgrading has an important benefit, but
> one of
> > the security considerations for Bitcoin is knowing that your definition
> of the
> > money hasn't changed. Much harder to know that if you change software.
>
> Isn't that just an argument for putting more effort into backporting
> fixes/workarounds? (I don't see how you do that without essentially
> publically disclosing which patches have a security impact -- "oh,
> gosh, this patch gets a backport, I wonder if maybe it has security
> implications...")
>
> (In so far as bitcoin is a consensus system, there can sometimes be a
> positive network effect, where having other people upgrade can help your
> security, even if you don't upgrade; "herd immunity" if you will. That
> way a new release going out to other people helps keep you safe, even
> while you continue to maintain the same definition of money by not
> upgrading at all)
>
> If altcoin maintainers are inconvenienced by tracking bitcoin-core
> updates, that would be an argument for them to contribute back to their
> upstream to make their own job easier; either helping with backports,
> or perhaps contributing to patches like PR#8994 might help.
>
> All of those things seem like they'd help not just altcoins but bitcoin
> investors/traders too, so it's not even a trade-off between classes of
> bitcoin core users. And if in the end various altcoins aren't able to
> keep up with security fixes, that's probably valuable information to
> provide to the market...
>
> Cheers,
> aj
>
> [0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin?
> I've no idea which of those might have trustworthy devs to work with,
> but surely at least a couple do?
>
> _______________________________________________
> 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/20170912/78a88c9e/attachment-0001.html>

2023-06-07 20:05:39 CEST

- reply

📅 Original date posted:2017-09-22
📝 Original message:If the variable size increase is only a few bytes, then three possibilities
arise:
- one should allow signatures to be zero padded (to reach the maximum size)
and abandon strict DER encoding
- one should allow spare witness stack elements (to pad the size to match
the maximum size) and remove the cleanstack rule. But this is tricky
because empty stack elements must be counted as 1 byte.
- signers must loop the generation of signatures until the signature
generated is of its maximum size.
On Fri, Sep 22, 2017 at 6:39 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> You generally know the witness size to within a few bytes right before
> signing. Why would you not? You know the size of ECDSA signatures. You can
> be told the size of a hash preimage by the other party. It takes some
> contriving to come up with a scheme where one party has variable-length
> signatures of their chosing
>
> > On Sep 22, 2017, at 2:32 PM, Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
> >
> > But generally before one signs a transaction one does not know the
> signature size (which may be variable). One can only estimate the maximum
> size.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170922/2f36b74f/attachment-0001.html>

2023-06-07 20:04:04 CEST

- reply

📅 Original date posted:2017-07-10
📝 Original message:Thank you for all your comments. I will improve the BIP based on the
technical suggestions received.
On the subjective/political side that has slipped into this discussion.
Skip this part if not interested in politics.
Regarding the timeline, its certainly rather short, but also is the UASF
BIP 148 ultimatum.
If Bitcoin were a democracy and we had somehow a way to securely perform a
referendum, then this will solve easily. But neither is true. At least now.
More than 80% of the miners and many users are willing to go in the
Segwit2x direction. With the support and great talent of the Bitcoin Core
developers, Segwit2x activation will not cause any major disruptions.
Without Core, there will be a temporary split. Both sides will have to
hard-fork.
I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
own vision, is not so bad.
On Sat, Jul 8, 2017 at 6:19 PM, Brian Hoffman <brian at ob1.io> wrote:
> I don't feel threatened by investors. You're full of shit btcdrak.
>
> Proofread your emails. You just declared support for segwit2x.
>
> On Jul 8, 2017, at 9:28 AM, Btc Drak via bitcoin-dev <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
> I am utterly appalled by this proposal both technically, ethically, and by
> the process which it has adopted. Hard forks require consensus from the
> entire ecosystem in order to prevent a fork, funds loss, confusion and harm
> to the robust guarantees of the Bitcoin system has thus far displayed.
>
> I know this is a draft, but you are seeking reviews of a proposal that has
> just a few weeks remaining before deployment (where "technical review" is
> pointless because the is not actually open <https://pastebin.com/kktB1kaw> unless
> you are an approved member
> <https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),
> making it totally unworkable and irresponsible. For example, exactly how
> are other implementations supposed to adopt the BIP in such a short
> timeframe? For all the talk of how important "alternative implementations"
> are, how does this rash and rushed action promote an ecosystem of multiple
> implementors? By encouraging fast upgrades, you are actually centralizing
> the ecosystem even further.
>
> The linked coded doesn't uniquely identify itself on the network by
> user-agent, something all distinct implementations have done to date.
>
> The draft BIP text looks like an afterthought and doesn't actually specify
> the proposal in enough detail to implement from the text. By contrast for
> example, BIP141 has a level of detail which allowed others to implement
> segwit without looking at any reference code (which consequently results to
> more confidence and testing of the specification all round). The Bitcoin
> system has a market cap of over $40bn supported by a robust and reliable
> network and your proposal is an offence to all Bitcoin has achieved because
> due to it's the strong foundations.
>
> I cannot not support this proposal in the current form and timeline, nor
> do I support the coercion that has been used behind closed doors to try and
> gain more support (not limited to, but including approaching company
> investors to twist arms and veiled threats of blacklisting companies from
> further funding/collaboration).
>
> I think the best you can hope for this hard fork proposal is for it to be
> quietly ignored.
>
>
>
> On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello,
>>
>> Here is a BIP that matches the reference code that the Segwit2x group has
>> built and published a week ago.
>>
>> This BIP and code satisfies the requests of a large part of the Bitcoin
>> community for a moderate increase in the Bitcoin non-witness block space
>> coupled with the activation of Segwit.
>>
>> You can find the BIP draft in the following link:
>>
>> https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-
>> draft-sergiolerner-segwit2x.mediawiki
>>
>> Reference source was kindly provided by the Segwit2x group.
>>
>> Best regards,
>> Sergio.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> 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/20170710/a72aad85/attachment-0001.html>

2023-06-07 20:04:03 CEST

- reply

📅 Original date posted:2017-07-13
📝 Original message:Well, 40 bytes reduction per input is excessive too :)
But 30 bytes reduction will do fine.
On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
> Some responses..
>
>>
>> The proposal adds another gratuitous limit to the system: A maximum
>> transaction size where none existed before, yet this limit is almost
>> certainly too small to prevent actual DOS attacks while it is also
>> technically larger than any transaction that can be included today
>> (the largest possible transaction today is 1mb minus the block
>> overheads). The maximum resource usage for maliciously crafted 1MB
>> transaction is enormous and permitting two of them greatly exacerbates
>> the existing vulnerability.
>>
>>
> I think that limiting the maximum transaction size may not be the best
> possible solution to the N^2 hashing problem, yet it is not a bad start.
>
> There are several viable soft-forking solutions to it:
>
> 1- Soft-fork to perform periodic reductions in the maximum non-segwit
> checksigs per input (down to 20)
> 2- Soft-fork to perform periodic reductions in the number of non-segwit
> checksigs per transaction. (down to 5K)
> 3- Soft-fork to perform periodic reductions in the amount of data hashed
> by non-segwit checksigs.
>
> Regardless which one one picks, the soft-fork can be deployed with enough
> time in advance to reduce the exposure. The risk is still low. Four years
> have passed since I reported this vulnerability and yet nobody has
> exploited it. The attack is highly anti-economical, yet every discussion
> about the block size ends up citing this vulnerability.
>
> ,
>
>> > Assuming the current transaction pattern is replicated in a 2 MB
>> plain-sized block that is 100% filled with transactions, then the
>> witness-serialized block would occupy 3.6 MB
>>
>> But in a worst case the result would be 8MB, which this document fails
>> to mention.
>>
>
> I will mention this worst case in the BIP.
>
> Even if artificially filling the witness space up to 8 MB is
> anti-economical, Segwit exacerbates this problem because each witness byte
> costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper
> than before. I think the guilt lies more in Segwit discount factor than in
> the plain block size increase.
> I would remove the discount factor altogether, and add a fixed (40 bytes)
> discount for each input with respect to outputs (not for certain input
> types), to incentivize the cleaning of the UTXO set. A discount for inputs
> cannot be used to bloat an unlimited number of blocks, because for each
> input the attacker needs to first create an output (without discount).
> There is no need to incentivize removing the signatures from blocks,
> because there is already an incentive to do so to save disk space.
>
>
>>
>> > Deploy a modified BIP91 to activate Segwit. The only modification is
>> that the signal "segsignal" is replaced by "segwit2x".
>>
>> This means that BIP-91 and your proposal are indistinguishable on the
>> network, because the string "segsignal" is merely a variable name used
>> in the software.
>>
>> No, it is exposed to the rpc mining interface (getblocktemplate). It must
> be redefined, even if it's not a consensus change.
>
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/23535924/attachment.html>

2023-06-07 20:04:03 CEST

- reply

📅 Original date posted:2017-07-13
📝 Original message:Some responses..
>
> The proposal adds another gratuitous limit to the system: A maximum
> transaction size where none existed before, yet this limit is almost
> certainly too small to prevent actual DOS attacks while it is also
> technically larger than any transaction that can be included today
> (the largest possible transaction today is 1mb minus the block
> overheads). The maximum resource usage for maliciously crafted 1MB
> transaction is enormous and permitting two of them greatly exacerbates
> the existing vulnerability.
>
>
I think that limiting the maximum transaction size may not be the best
possible solution to the N^2 hashing problem, yet it is not a bad start.
There are several viable soft-forking solutions to it:
1- Soft-fork to perform periodic reductions in the maximum non-segwit
checksigs per input (down to 20)
2- Soft-fork to perform periodic reductions in the number of non-segwit
checksigs per transaction. (down to 5K)
3- Soft-fork to perform periodic reductions in the amount of data hashed by
non-segwit checksigs.
Regardless which one one picks, the soft-fork can be deployed with enough
time in advance to reduce the exposure. The risk is still low. Four years
have passed since I reported this vulnerability and yet nobody has
exploited it. The attack is highly anti-economical, yet every discussion
about the block size ends up citing this vulnerability.
,
> > Assuming the current transaction pattern is replicated in a 2 MB
> plain-sized block that is 100% filled with transactions, then the
> witness-serialized block would occupy 3.6 MB
>
> But in a worst case the result would be 8MB, which this document fails
> to mention.
>
I will mention this worst case in the BIP.
Even if artificially filling the witness space up to 8 MB is
anti-economical, Segwit exacerbates this problem because each witness byte
costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper
than before. I think the guilt lies more in Segwit discount factor than in
the plain block size increase.
I would remove the discount factor altogether, and add a fixed (40 bytes)
discount for each input with respect to outputs (not for certain input
types), to incentivize the cleaning of the UTXO set. A discount for inputs
cannot be used to bloat an unlimited number of blocks, because for each
input the attacker needs to first create an output (without discount).
There is no need to incentivize removing the signatures from blocks,
because there is already an incentive to do so to save disk space.
>
> > Deploy a modified BIP91 to activate Segwit. The only modification is
> that the signal "segsignal" is replaced by "segwit2x".
>
> This means that BIP-91 and your proposal are indistinguishable on the
> network, because the string "segsignal" is merely a variable name used
> in the software.
>
> No, it is exposed to the rpc mining interface (getblocktemplate). It must
be redefined, even if it's not a consensus change.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/94c52265/attachment.html>

2023-06-07 20:04:01 CEST

- reply

📅 Original date posted:2017-07-07
📝 Original message:Hello,
Here is a BIP that matches the reference code that the Segwit2x group has
built and published a week ago.
This BIP and code satisfies the requests of a large part of the Bitcoin
community for a moderate increase in the Bitcoin non-witness block space
coupled with the activation of Segwit.
You can find the BIP draft in the following link:
https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki
Reference source was kindly provided by the Segwit2x group.
Best regards,
Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170707/d7d45d57/attachment.html>

2023-06-07 20:03:31 CEST

- reply

📅 Original date posted:2017-06-27
📝 Original message:Currently the only implementation that fulfills the requirements of the NYA
agreement is the segwit2x/btc1 implementation, which is being finalized
this week.
Segwit2mb does not fulfill the NYA agreement.
I'm asking now the segwit2x development team when a BIP will be ready so
that Core has the opportunity to evaluate the technical proposal.
On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Well, this Saturday's "Chinese roundtable" statement from a bunch of
> miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the
> coinbase as support for "the New York consensus SegWit2x program btc1 (
> https://github.com/btc1)", whose code includes the (accelerated
> 336-block) BIP 91 change. So, other facts or interpretations could come to
> light, but until they do we should probably assume that's what the "NYA"
> (which just broke 80% over the last 24h) means.
>
>
> On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> 80% have set "NYA" in their coinbase string. We have no idea what that
>> means. People are equating it to BIP 91 -- but BIP 91 did not exist at
>> the time of the New York agreement, and differs from the actual text
>> of the NYA in substantive ways. The "Segwit2MB" that existed at the
>> time of the NYA, and which was explicitly referenced by the text is
>> the proposal by Sergio Demian Lerner that was made to this mailing
>> list on 31 March. The text of the NYA grants no authority for
>> upgrading this proposal while remaining compliant with the agreement.
>> This is without even considering the fact that in the days after the
>> NYA there was disagreement among those who signed it as to what it
>> meant.
>>
>> I feel it is a very dangerous and unwarranted assumption people are
>> making that what we are seeing now is either 80% support for BIP-91 or
>> for the code in the btc1 repo.
>>
>> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <erik at q32.com> wrote:
>> > # Jacob Eliosoff:
>> >
>> >> will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
>> split.
>> >
>> > Correct. There are 2 short activation periods in BIP91 either of which
>> > would avoid a split.
>> >
>> > # Gregory Maxwell:
>> >
>> >> unclear to me _exactly_ what it would need to implement to be
>> consistent.
>> >
>> > This is the relevant pull req to core:
>> >
>> > https://github.com/bitcoin/bitcoin/pull/10444
>> >
>> > Seems OK. It's technically running now on testnet5. I think it (or a
>> > -bip148 option) should be merged as soon as feasible.
>> >
>> >> previously debunked "XT" and "Classic" hysteria.
>> >
>> > apples vs oranges, imo. segwit is not a contentious feature. the
>> > "bundling" in segwit2x is, but that's not the issue here. the issue
>> is we
>> > are indirectly requiring miners that strongly support segwit to install
>> > consensus protocol changes outside of bitcoin's standard reference.
>> 80% of
>> > them have signaled they will do so. these are uncharted waters.
>> >
>> >
>> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> I could be wrong, but the latest BIP91 implementation (also included in
>> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This
>> has
>> >> been updated at
>> >> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So
>> if 80%
>> >> of hashpower is actually running that code and signaling on bit 4 by
>> July 25
>> >> or so, then those 80+% will start orphaning non-bit-1 blocks before
>> Aug 1,
>> >> and we avoid a split.
>> >>
>> >> There may still be a few non-bit-1 blocks that get orphaned after Aug
>> 1,
>> >> because they're mined by old BIP141 nodes. But it seems like very few
>> >> miners won't be signaling either Segwit2x *or* BIP141 by then...
>> >>
>> >> Make sense?
>> >>
>> >>
>> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <
>> mark at friedenbach.org>
>> >> wrote:
>> >>>
>> >>> Why do you say activation by August 1st is likely? That would require
>> an
>> >>> entire difficulty adjustment period with >=95% bit1 signaling. That
>> seems a
>> >>> tall order to organize in the scant few weeks remaining.
>> >>>
>> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
>> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> If segwit is activated before Aug 1, as now seems likely, there will
>> be
>> >>> no split that day. But if activation is via Segwit2x (also likely),
>> and at
>> >>> least some nodes do & some don't follow through with the HF 3mo later
>> >>> (again, likely), agreed w/ Greg that *then* we'll see a split -
>> probably in
>> >>> Sep/Oct. How those two chains will match up and how the split will
>> play out
>> >>> is anyone's guess...
>> >>>
>> >>>
>> >>>
>> >>> On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev"
>> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> > Ironically, it looks like most of the segwit2x signaling miners are
>> >>> > faking it (because they're not signaling segwit which it requires).
>> >>> > It'll be unfortunate if some aren't faking it and start orphaning
>> >>> > their own blocks because they are failing to signal segwit.
>> >>>
>> >>> Well, they're doing some kind of "pre-signaling" in the coinbase at
>> the
>> >>> moment, because the segwit2x project is still in alpha-phase
>> according to
>> >>> the timeline. They're just showing commitment.
>> >>> I'm sure they will begin signaling on version bit 4/BIP91 as well as
>> >>> actually running a segwit2x node when the time comes.
>> >>>
>> >>>
>> >>> > As far as prevent a chain split goes, all those things
>> >>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit--
>> so I
>> >>> > don't think that holds.
>> >>>
>> >>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x
>> (or
>> >>> BIP148) node, because they wouldn't have the new consensus rule of
>> requiring
>> >>> all blocks to signal for segwit.
>> >>> I don't believe there would be any long lasting chainsplit though
>> >>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3
>> blocks if we
>> >>> get unlucky.
>> >>>
>> >>> Hampus
>> >>>
>> >>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev
>> >>> <bitcoin-dev at lists.linuxfoundation.org>:
>> >>>>
>> >>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>> > Because a large percentage of miners are indifferent, right now
>> miners
>> >>>> > have
>> >>>> > to choose between BIP148 and Segwit2x if they want to activate
>> Segwit.
>> >>>>
>> >>>> Miners can simply continuing signaling segwit, which will leave them
>> >>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>> >>>> what "segwit2x" is since they keep changing the actual definition and
>> >>>> do not have a specification; but last I saw the near-term behavior
>> the
>> >>>> same as BIP91 but with a radically reduced activation window, so the
>> >>>> story would be the same there in the near term).
>> >>>>
>> >>>> Ironically, it looks like most of the segwit2x signaling miners are
>> >>>> faking it (because they're not signaling segwit which it requires).
>> >>>> It'll be unfortunate if some aren't faking it and start orphaning
>> >>>> their own blocks because they are failing to signal segwit.
>> >>>>
>> >>>> I don't think the rejection of segwit2x from Bitcoin's developers
>> >>>> could be any more resolute than what we've already seen:
>> >>>> https://en.bitcoin.it/wiki/Segwit_support
>> >>>>
>> >>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>> > I think it is very naïve to assume that any shift would be
>> temporary.
>> >>>> > We have a hard enough time getting miners to proactively upgrade to
>> >>>> > recent versions of the reference bitcoin daemon. If miners
>> interpret
>> >>>> > the situation as being forced to run non-reference software in
>> order
>> >>>> > to prevent a chain split because a lack of support from Bitcoin
>> Core,
>> >>>> > that could be a one-way street.
>> >>>>
>> >>>> I think this is somewhat naive and sounds a lot like the repeat of
>> the
>> >>>> previously debunked "XT" and "Classic" hysteria.
>> >>>>
>> >>>> There is a reason that segwit2x is pretty much unanimously rejected
>> by
>> >>>> the technical community. And just like with XT/Classic/Unlimited
>> >>>> you'll continue to see a strong correlation with people who are
>> >>>> unwilling and unable to keep updating the software at an acceptable
>> >>>> level of quality-- esp. because the very founding on their fork is
>> >>>> predicated on discarding those properties.
>> >>>>
>> >>>> If miners want to go off and create an altcoin-- welp, thats
>> something
>> >>>> they can always do, and nothing about that will force anyone to go
>> >>>> along with it.
>> >>>>
>> >>>> As far as prevent a chain split goes, all those things
>> >>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so
>> I
>> >>>> don't think that holds.
>> >>>> _______________________________________________
>> >>>> bitcoin-dev mailing list
>> >>>> bitcoin-dev at lists.linuxfoundation.org
>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> bitcoin-dev mailing list
>> >>> bitcoin-dev at lists.linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> bitcoin-dev mailing list
>> >>> bitcoin-dev at lists.linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >
>>
>
>
> _______________________________________________
> 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/20170627/3642debc/attachment.html>

2023-06-07 20:00:57 CEST

- reply

📅 Original date posted:2017-05-09
📝 Original message:Thanks Johnson and Hampus for the clarifications.
However, I would rather do the opposite: soft-fork to 50% now, and
soft-fork again to 75% discount later if needed, because it doesn't affect
the max transactions/second.
Segwit as it is today should be activated. However if it is not before
November, then for the next Segwit attempt I would choose a more
conservative 50% discount.
On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
>
> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >
> > So it seems the 75% discount has been chosen with the idea that in the
> future the current transaction pattern will shift towards multisigs. This
> is not a bad idea, as it's the only direction Bitcoin can scale without a
> HF.
> > But it's a bad idea if we end up doing, for example, a 2X blocksize
> increase HF in the future. In that case it's much better to use a 50%
> witness discount, and do not make scaling risky by making the worse case
> block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
> >
>
> As we could change any parameter in a hardfork, I don’t think this has any
> relation with the current BIP141 proposal. We could just use 75% in a
> softfork, and change that to a different value (or completely redefine the
> definition of weight) with a hardfork later.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/e01b3062/attachment-0001.html>

2023-06-07 20:00:56 CEST

- reply

📅 Original date posted:2017-05-09
📝 Original message:This [1] article says the current discount prevents witness spam. Witness
spam is free space in the witness part of the block that can be filled by
miners to create bigger blocks with almost no cost for the benefit a
cluster of miners with low latency, increasing centralization.
The 75% discount does not prevent it, but on the contrary leaves a lot of
extra witness space for spam.
If the maximum block weight is set to 2.7M, each byte of non-witness block
costs 1.7, and each byte of witness costs 1, then a normal filled block
would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4
Mbyte block. The worst case would be the average case, and the transaction
rate would be the maximum possible.
The current 75% discount can only achieve more transactions per second if
the type of transactions change. Therefore the current 75% discount only
makes the block size worst case worse (4 Mbytes when it should be 2.7
Mbytes).
80% of all inputs/outputs are P2PKH. The only way to make use of the extra
witness
space If most P2PKH transactions are replaced by multisigs (typically for
LN).
So it seems the 75% discount has been chosen with the idea that in the
future the current transaction pattern will shift towards multisigs. This
is not a bad idea, as it's the only direction Bitcoin can scale without a
HF.
But it's a bad idea if we end up doing, for example, a 2X blocksize
increase HF in the future. In that case it's much better to use a 50%
witness discount, and do not make scaling risky by making the worse case
block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
I've uploaded the code here:
https://github.com/SergioDemianLerner/SegwitStats
[1] https://segwit.org/why-a-discount-factor-of-4-why-not-
2-or-8-bbcebe91721e.
On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Sergio,
>
> I'm not sure what the data you present has to do with the discount. A 75%
> discount prevents witness spam precisely because it is 75%, nothing more.
> The current usage simply gives a guideline on how much capacity is gained
> through a particular discount. With the data you show, it would imply that
> those blocks, with SegWit used where possible, would result in blocks of
> ~1.8MB.
>
>
>
> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have processed 1000 blocks starting from Block #461653.
>>
>> I computed several metrics, including the supposed size of witness data
>> and non-witness data (onchain), assuming all P2SH inputs/outputs are
>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
>>
>> This takes into account that other types of transactions will not be
>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
>> take into account that LN transactions may affect the current state,
>> increasing the segwit/nosegwit ratio.
>>
>> Among a lot of information, I've got the following real world results...
>>
>> acMainChainSpace =352608924
>> acSegwitSpace =599400403
>> Ratio segwit/nosegwit=1.6999
>>
>> This implies that the 75% that discount is not the best option to prevent
>> witness spam in a block of 4 MB, as stated in
>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e
>> .
>>
>> The non-witness data weight factor should not be 4 but 2.35. The closest
>> integer value is 2, which leads to a 50% witness discount.
>>
>> The Bitcoinj source code is available for anyone to review. I encourage
>> anyone to re-compute this with another utility to cross-check. Maybe
>> Antoine Le Calvez (p2sh.info) would like to double-check.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> 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/20170509/38a4f95e/attachment.html>

2023-06-07 20:00:55 CEST

- reply

📅 Original date posted:2017-05-08
📝 Original message:I have processed 1000 blocks starting from Block #461653.
I computed several metrics, including the supposed size of witness data and
non-witness data (onchain), assuming all P2SH inputs/outputs are converted
to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
This takes into account that other types of transactions will not be
modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
take into account that LN transactions may affect the current state,
increasing the segwit/nosegwit ratio.
Among a lot of information, I've got the following real world results...
acMainChainSpace =352608924
acSegwitSpace =599400403
Ratio segwit/nosegwit=1.6999
This implies that the 75% that discount is not the best option to prevent
witness spam in a block of 4 MB, as stated in
https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
The non-witness data weight factor should not be 4 but 2.35. The closest
integer value is 2, which leads to a 50% witness discount.
The Bitcoinj source code is available for anyone to review. I encourage
anyone to re-compute this with another utility to cross-check. Maybe
Antoine Le Calvez (p2sh.info) would like to double-check.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170508/aaeb7ba1/attachment.html>

2023-06-07 19:53:54 CEST

- reply

📅 Original date posted:2016-10-14
📝 Original message:I read the DPL v1.1 and I find it dangerous for Bitcoin users. Current
users may be confident they are protected but in fact they are not, as the
future generations of users can be attacked, making Bitcoin technology
fully proprietary and less valuable.
If you read the DPL v1.1 you will see that companies that join DPL can
enforce their patents against anyone who has chosen not to join the DPL.
(http://defensivepatentlicense.org/content/defensive-patent-license)
So basically most users of Bitcoin could be currently under threat of being
sued by Bitcoin companies and individuals that joined DPL in the same way
they might be under threat by the remaining companies. And even if they
joined DPL, they may be asked to pay royalties for the use of the
inventions prior joining DPL.
DPL changes nothing for most individuals that cannot and will not hire
patent attorneys to advise them on what the DPL benefits are and what
rights they are resigning. Remember that patten attorneys fees may be
prohibitive for individuals in under-developed countries.
Also DPL is revocable by the signers (with only a 180-day notice), so if
Bitcoin Core ends up using ANY DPL covered patent, the company owning the
patent can later force all new Bitcoin users to pay royalties.
Because Bitcoin user base grows all the time with new individuals, the sole
existence of DPL licensed patents in Bitcoin represents a danger to Bitcoin
future almost the same as the existence of non-DPL license patents.
If you're publishing all your ideas and code (public disclosure), you
cannot later go and file a patent in most of the world except the US, where
you have a 1 year grace period. So we need to do something specific to
prevent the publishers filing a US patent.
What we need much more than DPL, we need that every BIP and proposal to the
Bitcoin mailing list contains a note that grants all Bitcoin users a
worldwide, royalty-free, no-charge, non-exclusive, irrevocable license for
the content of the e-mail or BIP.
I'm not a lawyer and this is not an advise of any kind. Please check
yourself the DPL v1.1 and get your own idea. I'm speaking on behalf of
myself, and not any company.
(http://defensivepatentlicense.org/content/defensive-patent-license)
Best regards,
Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161014/095eb988/attachment.html>

2023-06-07 19:53:41 CEST

- reply

📅 Original date posted:2016-10-02
📝 Original message:Since ScalingBitcoin is close, I think this is a good moment to publish our
proposal on drivechains. This BIP proposed the drivechain we'd like to use
in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented
in Bitcoin. Until that happens, we're using a federated approach.
I'm sure that adding risk-less Bitcoin extensibility through
sidechains/drivechains is what we all want, but it's of maximum importance
to decide which technology will leads us there.
We hope this work can also be the base of all other new 2-way-pegged
blockchains that can take Bitcoin the currency to new niches and test new
use cases, but cannot yet be realized because of current
limitations/protections.
The full BIP plus a reference implementation can be found here:
BIP (draft):
https://github.com/rootstock/bips/blob/master/BIP-R10.md
Code & Test cases:
https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
(Note: Code is still unaudited)
As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked opcode
that counts acks and nacks tags in coinbase fields, and push the resulting
totals in the script stack.
The system was designed with the following properties in mind:
1. Interoperability with scripting system
2. Zero risk of invalidating a block
3. No additional computation during blockchain management and
re-organization
4. No change in Bitcoin security model
5. Bounded computation of poll results
6. Strong protection from DoS attacks
7. Minimum block space consumption
8. Zero risk of cross-secondary chain invalidation
Please see the BIP draft for a more-detailed explanation on how we achieve
these goals.
I'll be in ScalingBitcoin in less than a week and I'll be available to
discuss the design rationale, improvements, changes and ideas any of you
may have.
Truly yours,
Sergio Demian Lerner
Bitcoiner and RSK co-founder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/b654e8f3/attachment.html>

2023-06-07 19:50:30 CEST

- reply

📅 Original date posted:2016-05-11
📝 Original message:On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
>
>
> You can find it here:
> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
>
> Basically, the idea is to put in the first 64 bytes a 4 byte hash of the
> second 64-byte chunk. That design also allows increased nonce space in the
> first 64 bytes.
>
> My mistake here. I didn't recalled correctly my own idea. The idea is to
include in the second 64-byte chunk a 4-byte hash of the first chunk, not
the opposite.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/b0e9c92b/attachment.html>

2023-06-07 19:50:29 CEST

- reply

📅 Original date posted:2016-05-10
📝 Original message:Your idea of moving the Merkle root to the second chunk does not work.
The AsicBoost can change the version bits and it does not need to find a
collision.
(However *Spondoolies patent *only mentions Merkle collisions:
https://patentscope.wipo.int/search/docservicepdf_pct/id00000032873338/PAMPH/WO2016046820.pdf
)
Back in 2014 I designed a ASIC-compatible block header that prevents
AsicBoost in all its forms.
You can find it here:
https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
Basically, the idea is to put in the first 64 bytes a 4 byte hash of the
second 64-byte chunk. That design also allows increased nonce space in the
first 64 bytes.
But it you want to do a simpler change, you can more easily use the first
32 bits of the Parent Block Hash (now currently zero) to store the first 4
bytes of the SHA256 of the last 16 bytes of the header. That way to "tie"
the two header chunks. It's a minimal change (but a hard-fork)
But some ASIC companies already have cores that are better (on power, cost,
rate, temperature, etc.) than competing companies ASICs. Why do you think a
10% improvement from AsicBoost is different from many of other improvements
they already have (secretly) added? Maybe we (?) should only allow ASICs
that have a 100% open source designs?
If we change the protocol then the message to the ecosystem is that ASIC
optimizations should be kept secret. It is fair to change the protocol
because we don't like that certain ASIC manufacturer has better chips, if
the chips are sold in the market and anyone can buy them? And what about
using approximate adders (30% improvement), or dual rail asynchronous
adders (also more than 10% improvement) ? How do we repair those?
Disclaimer: I have stake in AsicBoost, but I'm not sure about this.
On Tue, May 10, 2016 at 5:27 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The various chunks in the double SHA256 are
>
> Chunk 1: 64 bytes
> version
> previous_block_digest
> merkle_root[31:4]
>
> Chunk 2: 64 bytes
> merkle_root[3:0]
> nonce
> timestamp
> target
>
> Chunk 3: 64 bytes
> digest from first sha pass
>
> Their improvement requires that all data in Chunk 2 is identical except
> for the nonce. With 4 bytes, the birthday paradox means collisions can be
> found reasonable easily.
>
> If hard forks are allowed, then moving more of the merkle root into the
> 2nd chunk would make things harder. The timestamp and target could be
> moved into chunk 1. This increases the merkle root to 12 bytes in the 2nd
> chunk. Finding collisions would be made much more difficult.
>
> If ASIC limitations mean that the nonce must stay where it is, this would
> mean that the merkle root would be split into two pieces.
>
> On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> As part of the hard-fork proposed in the HK agreement(1) we'd like to
>> make the
>> patented AsicBoost optimisation useless, and hopefully make further
>> similar
>> optimizations useless as well.
>>
>> What's the best way to do this? Ideally this would be SPV compatible, but
>> if it
>> requires changes from SPV clients that's ok too. Also the fix this should
>> be
>> compatible with existing mining hardware.
>>
>>
>> 1)
>> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>>
>> 2)
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> 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/20160510/e98fa60e/attachment-0001.html>

2023-06-07 19:43:29 CEST

- reply

📅 Original date posted:2015-10-14
📝 Original message:I'm reading it.
First comment: since a Bitcoin block time is only greater than the median
of the last 11 blocks, a miner could choose the key block time in order to
generate about 400 miniblocks, instead of the average 60 blocks. Not very
bad, but should be taken into account.
On Wed, Oct 14, 2015 at 3:02 PM, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi everyone,
>
> We just released the whitepaper describing Bitcoin-NG, a new technique for
> addressing some of the scalability challenges faced by Bitcoin.
> Surprisingly, Bitcoin-NG can simultaneously increase throughput while
> reducing latency, and do so without impacting Bitcoin's open architecture
> or changing its trust model. This post illustrates the core technique:
> http://hackingdistributed.com/2015/10/14/bitcoin-ng/
> while the whitepaper has all the nitty gritty details:
> http://arxiv.org/abs/1510.02037
>
> Fitting NG on top of the current Bitcoin blockchain is future work that we
> think is quite possible. NG is compatible with both Bitcoin as is, as well
> as Blockstream-like sidechains, and we currently are not planning to
> compete commercially with either technology -- we see NG as being
> complementary to both efforts. This is pure science, published and shared
> with the community to advance the state of blockchains and to help them
> reach throughputs and latencies required of cutting edge fintech
> applications. Perhaps it can be adopted, or perhaps it can provide the
> spark of inspiration for someone else to come up with even better solutions.
>
> We would be delighted to hear your feedback.
> - Ittay Eyal and E. Gün Sirer.
>
>
> _______________________________________________
> 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/20151014/7b921e1f/attachment-0001.html>

2023-06-07 19:42:37 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:Some of the people on this mailing list are blindly discussing the
technicalities of a soft/hard fork without realizing that is not Mike's
main intention. At least I perceive (and maybe others too) something else
is happening.
Let me try to clarify: the discussion has nothing to do with technical
arguments. I generally like more hard forks than soft forks (but I won't
explain why because this is not a technical thread), but for CLTV this is
quite irrelevant (but I won't explain why..), and I want CLTV to be
deployed asap.
Mike's intention is to criticize the informal governance model of Bitcoin
Core development and he has strategically pushed the discussion to a
dead-end where the group either:
1) ignores him, which is against the established criteria that all
technical objections coming from anyone must be addressed until that person
agrees, so that a change can be uncontroversial. If the group moves forward
with the change, then the "uncontroversial" criteria is violated and then
credibility is lost. So a new governance model would be required for which
the change is within the established rules.
2) respond to his technical objections one after the other, on never ending
threads, bringing the project to a standstill.
As I don't want 2) to happen, then 1) must happen, which is what Mike
wants. I have nothing for or against Mike personally. I just think Mike
Hearn has won this battle. But having a more formal decision making process
may not be too bad for Bitcoin, maybe it can actually be good.
Best regards
from a non-developer to my dearest developer friends,
Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/4d07e31d/attachment.html>

2023-06-07 19:38:20 CEST

- reply

📅 Original date posted:2015-08-27
📝 Original message:Guys,
I strongly think the original prabhat e-mail is a parody.
And I find very funny that important people have responded.
But maybe I'm wrong!
*:)*
El jue., 27 ago. 2015 a las 11:04, Chris Pacia via bitcoin-dev (<
bitcoin-dev at lists.linuxfoundation.org>) escribió:
>
>
> On 08/27/2015 09:39 AM, prabhat via bitcoin-dev wrote:
>
> Fine point.
>
> So where is the solution? What to do?
>
>
> How about nothing.
> _______________________________________________
> 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/20150827/cba7d874/attachment.html>

2023-06-07 19:35:43 CEST

- reply

📅 Original date posted:2015-08-18
📝 Original message:Just to add some superfluous and unessential spice to this discussion,
there were two Satoshi users originally registered in sourceforge, one
registered very soon after the other. So I say Satoshi were at least two
people, so it may be the case that one Satoshi re-appeared, but the other
did not.
Ore maybe one Satoshi is for Bitcoin XT, and the other Satoshi is against
it.
Satoshi wars!
On Tue, Aug 18, 2015 at 5:59 PM, Anon Moto via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> And this is how the powers that be compromise bitcoin. They can't stop
> TCP/IP, but they sure can take over the development team. It's a good thing
> that no one from the CIA has had any conversations with anyone from the
> bitcoin development team. Phew...
>
>
> On Tue, Aug 18, 2015 at 11:57 AM, Oliver Egginger via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Am 18.08.2015 um 11:15 schrieb Warren Togami Jr.:
>> > I honestly don't understand your position, but I get the sense that you
>> > are suggesting Satoshi wouldn't be welcome to return if he wanted to be
>> > active in development again?
>>
>> Who am I? Personally I have zero objection if the creator steps in. I
>> think he would be highly welcome by the most people. At first I had the
>> impression that the email was a fake, but maybe I was wrong. At the
>> moment I think: Maybe it's even the best if we do not know exactly
>> whether it was Satoshi or not.
>>
>> Unanimity is mission critical for Bitcoin and must be an absolute
>> priority. If not the vast majority is in favor for a fork, then the fork
>> should be avoided until a consensus is found. Even if it takes until the
>> cows come home.
>>
>> But it is very likely now that it will come to a fork. No matter which
>> site will win, this will produce a lot of humiliated people at the end.
>> That's not good and leads to bitterness on both sites.
>>
>> - oliver
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> 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/20150818/8de0e558/attachment.html>

2023-06-07 17:47:26 CEST

- reply

2023-06-07 17:45:27 CEST

- reply

📅 Original date posted:2015-08-06
📝 Original message:Is there any up to date documentation about TheBlueMatt relay network
including what kind of block compression it is currently doing? (apart from
the source code)
Regards, Sergio.
On Wed, Aug 5, 2015 at 7:14 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 5, 2015 at 9:19 PM, Arnoud Kouwenhoven - Pukaki Corp
> <arnoud at pukaki.bz> wrote:
> > Thanks for this (direct) feedback. It would make sense that if blocks
> can be
> > submitted using ~5kb packets, that no further optimizations would be
> needed
> > at this point. I will look into the relay network transmission protocol
> to
> > understand how it works!
> >
> > I hear that you are saying that this network solves speed of transmission
> > and thereby (technical) block size issues. Presumably it would solve
> speed
> > of block validation too by prevalidating transactions.
>
>
> Correct. Bitcoin Core has cached validation for many years now... if
> not for that and other optimizations, things would be really broken
> right now. :)
>
> > Assuming this is all
> > true, and I have no reason to doubt that at this point, I do not
> understand
> > why there is any discussion at all about the (technical) impact of large
> > blocks, why there are large numbers of miners building on invalid blocks
> > (SPV mining, https://bitcoin.org/en/alert/2015-07-04-spv-mining), or why
> > there is any discussion about the speed of block validation (cpu
> processing
> > time to verify blocks and transactions in blocks being a limitation).
>
> I'm also mystified by a lot of the large block discussion, much of it
> is completely divorced from the technology as deployed; much less what
> we-- in industry-- know to be possible. I don't blame you or anyone in
> particular on this; it's a new area and we don't yet know what we need
> to know to know what we need to know; or to the extent that we do it
> hasn't had time to get effectively communicated.
>
> The technical/security implications of larger blocks are related to
> other things than propagation time, if you assume people are using the
> available efficient relay protocol (or better).
>
> SPV mining is a bit of a misnomer (If I coined the term, I'm sorry).
> What these parties are actually doing is blinding mining on top of
> other pools' stratum work. You can think of it as sub-pooling with
> hopping onto whatever pool has the highest block (I'll call it VFSSP
> in this post-- validation free stratum subpooling). It's very easy to
> implement, and there are other considerations.
>
> It was initially deployed at a time when a single pool in Europe has
> amassed more than half of the hashrate. This pool had propagation
> problems and a very high orphan rate, it may have (perhaps
> unintentionally) been performing a selfish mining attack; mining off
> their stratum work was an easy fix which massively cut down the orphan
> rates for anyone who did it. This was before the relay network
> protocol existed (the fact that all the hashpower was consolidating on
> a single pool was a major motivation for creating it).
>
> VFSSP also cuts through a number of practical issues miners have had:
> Miners that run their own bitcoin nodes in far away colocation
> (>100ms) due to local bandwidth or connectivity issues (censored
> internet); relay network hubs not being anywhere near by due to
> strange internet routing (e.g. japan to china going via the US for ...
> reasons...); the CreateNewBlock() function being very slow and
> unoptimized, etc. There are many other things like this-- and VFSSP
> avoids them causing delays even when you don't understand them or know
> about them. So even when they're easily fixed the VFSSP is a more
> general workaround.
>
> Mining operations are also usually operated in a largely fire and
> forget manner. There is a long history in (esp pooled) mining where
> someone sets up an operation and then hardly maintains it after the
> fact... so some of the use of VFSSP appears to just be inertia-- we
> have better solutions now, but they they work to deploy and changing
> things involves risk (which is heightened by a lack of good
> monitoring-- participants learn they are too latent by observing
> orphaned blocks at a cost of 25 BTC each).
>
> One of the frustrating things about incentives in this space is that
> bad outcomes are possible even when they're not necessary. E.g. if a
> miner can lower their orphan rate by deploying a new protocol (or
> simply fixing some faulty hardware in their infrastructure, like
> Bitcoin nodes running on cheap VPSes with remote storage) OR they can
> lower their orphan rate by pointing their hashpower at a free
> centeralized pool, they're likely to do the latter because it takes
> less effort.
> _______________________________________________
> 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/20150806/0321960d/attachment.html>