<unnamed>

Public Key

npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f

Profile Code

nprofile1qqsykwrqxsy0t0sqyzgjzr5xnfx2sm7z4g0l6zr3qd4qv6qx3mnzdmspzpmhxue69uhkummnw3ezuamfdejsjapwwa

Publishing to

nostr.wine

Last Notes

2023-06-07 18:20:06 UTC

- 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 18:05:55 UTC

- 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 18:05:53 UTC

- 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 18:05:39 UTC

- reply

📅 Original date posted:2017-09-22
📝 Original message:>
> There are other solutions to this problem that could have been taken
> instead, such as committing to the number of items or maximum size of
> the stack as part of the sighash data, but cleanstack was the approach
> taken.
The lack of signed maximum segwit stack size was one of the objections to
segwit I presented last year. This together with the unlimited segwit stack
size.
However, committing to the maximum stack size (in bytes) for an input is
tricky. The only place where this could be packed is in sequence_no, with a
soft-fork. E.g. when transaction version is 2 and and only when lock_time
is zero.
For transactions with locktime >0, we could soft-fork so transactions add a
last zero-satoshi output whose scriptPub contains OP_RETURN and followed by
N VarInts, containing the maximum stack size of each input.
Normally, for a 400 byte, 2-input transaction, this will add 11 bytes, or a
2.5% overhead.
> Arguably for a future script version upgrade one of these other
> approaches should be taken to allow for shorter tail-call scripts.
>
> Mark
>
> * Well, almost any. You could end the script with DEPTH EQUAL and that
> is a compact way of ensuring the stack is clean (assuming the script
> finished with just "true" on the stack). Nobody does this however
> and burning two witness bytes of every redeem script going forward
> as a protective measure seems like an unnecessary ask.
> _______________________________________________
> 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/cc607dfd/attachment-0001.html>

2023-06-07 18:05:39 UTC

- reply

📅 Original date posted:2017-09-22
📝 Original message: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.
On Fri, Sep 22, 2017 at 6:11 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
>
> On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
>
>
>>
>> There are other solutions to this problem that could have been taken
>> instead, such as committing to the number of items or maximum size of
>> the stack as part of the sighash data, but cleanstack was the approach
>> taken.
>
>
> The lack of signed maximum segwit stack size was one of the objections to
> segwit I presented last year. This together with the unlimited segwit stack
> size.
>
> However, committing to the maximum stack size (in bytes) for an input is
> tricky. The only place where this could be packed is in sequence_no, with a
> soft-fork. E.g. when transaction version is 2 and and only when lock_time
> is zero.
>
> For transactions with locktime >0, we could soft-fork so transactions add
> a last zero-satoshi output whose scriptPub contains OP_RETURN and followed
> by N VarInts, containing the maximum stack size of each input.
> Normally, for a 400 byte, 2-input transaction, this will add 11 bytes, or
> a 2.5% overhead.
>
>
> There’s no need to put it in the transaction itself. You put it in the
> witness and it is either committed to as part of the witness (in which case
> it has to hold for all possible spend paths), or at spend time by including
> it in the data signed by CHECKSIG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170922/87c83dee/attachment.html>

2023-06-07 18:05:39 UTC

- 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 18:04:04 UTC

- 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 18:04:03 UTC

- 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 18:04:03 UTC

- 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 18:04:01 UTC

- 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 18:00:59 UTC

- reply

📅 Original date posted:2017-05-09
📝 Original message:Let n be the non-segwit bytes. Let the seg/noseg ratio be 1.7.
Segwit with 75% discount: (let WITNESS_SCALE_FACTOR=4)
n*WITNESS_SCALE_FACTOR+n*1.7 = 4,000,000
Then n=4,000,000 / 5.7 = 701K
Average block size = 701K*(1+1.7)=1.8 Mbytes
Maximum block size = 4 MBytes
Segwit with 50% discount + 2MB HF: (let WITNESS_SCALE_FACTOR=2)
n*2+n*1.7 = 4,000,000
n = 4,000,000/ 3.7 = 1.08M
Average block size = 1.08M*(1+1.7)=2.9 Mbytes
Maximum block size = 4 MBytes
The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum
block size is the same.
On Tue, May 9, 2017 at 3:58 PM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
>
>>
>> You suggested "If the maximum block weight is set to 2.7M, each byte of
>> non-witness block costs 1.7", but these numbers dont work out - setting
>> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
>> fork), not 2.7MB.
>
>
> Yes. In a soft-fork is true.
> I was thinking about what a HF could do to optimize the balance, and I
> forgot I was in the context of a SF.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/4a3d4465/attachment-0001.html>

2023-06-07 18:00:58 UTC

- reply

📅 Original date posted:2017-05-09
📝 Original message:>
>
>
> You suggested "If the maximum block weight is set to 2.7M, each byte of
> non-witness block costs 1.7", but these numbers dont work out - setting
> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
> fork), not 2.7MB.
Yes. In a soft-fork is true.
I was thinking about what a HF could do to optimize the balance, and I
forgot I was in the context of a SF.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/473e88df/attachment.html>

2023-06-07 18:00:57 UTC

- 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 18:00:56 UTC

- 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 18:00:55 UTC

- 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 17:53:54 UTC

- 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 17:53:43 UTC

- reply

📅 Original date posted:2016-10-02
📝 Original message:I'm not a lawyer, and my knowledge on patents is limited. I guess RSK WILL
endorse DPL or will make the required actions to make sure the things
developed by RSK remain free and open. This was not a priority until now,
but coding was. For me, coding always is the priority.
I will discuss prioritizing this with the team. Remember it took several
years to BlockStream to decide for DPL and not just publish everything as
they were doing. I suppose the decision it was not a simple one, involving
lawyers advise and all. I guess DPL needs to actually patent the things in
order to open them later, and patenting has a very high cost.
Give us time to decide which open source strategy is the best and cheaper
for RSK. At this point I can assert that RSK has not filed any patent not
is planing to. This proposal is not encumbered by any patents, and
drivechains is actually not RSK's idea, but Paul Sztorc's.
On Sun, Oct 2, 2016 at 2:11 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sun, Oct 02, 2016 at 02:00:01PM -0300, Sergio Demian Lerner wrote:
> > Peter, are you really going to try to down vote a decent free and
> > open-source proposal that benefits all the Bitcoin community including
> > you and your future children because a personal attack to me without any
> > logic or basis?
>
> I've suggested a way that you can rectify this situation so we can
> continue to
> collaborate: Have Rootstock adopt a legally binding patent pledge/license.
> I'd
> suggest you do as Blockstream has done and at minimum adopt the Defensive
> Patent License (DPL); I personally will be doing so in the next week or
> two for
> my own consulting company (I'm discussing exactly how to do so with my
> lawyer
> right now).
>
> If Rootstock is not planning on getting any patents for offensive purposes,
> then there is no issue with doing so - the DPL in particular is designed
> in a
> minimally intrusive way.
>
> Please fix this issue so we can in fact continue to collaborate to improve
> Bitcoin.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/d3052c9d/attachment.html>

2023-06-07 17:53:43 UTC

- reply

📅 Original date posted:2016-10-02
📝 Original message:On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> But I would argue that in this scenario, the only way it
>> would become invalid is the equivalent of a double-spend... and therefore
>> it
>> may be acceptable in relation to this argument.
>>
>
> The values returned by OP_COUNT_ACKS vary in their exact value depending
> on which block this transaction ends up in. While the proposed use of this
> operation is somewhat less objectionable (although still objectionable to
> me), nothing stops users from using OP_EQUALVERIFY and and causing their
> transaction fluctuate between acceptable and unacceptable, with no party
> doing anything like a double spend. This is a major problem with the
> proposal.
>
Transactions that redeem an output containing (or referencing by means of
P2WSH) an OP_COUNT_ACKS are not broadcast by the network. That means that
the network cannot be DoS attacked by flooding with a transaction that will
not verify due to being too late.
The only parties that can include the redeem transaction are the miners
themselves.
Therefore I see no problem that an OP_COUNT_ACKS scriptSig transaction is
invalidated after the liveness times expires.
If there is no expiration, then polls can last forever and the system fails
to provide DoS protection for block validation since active polls can
accumulate forever.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/c6349d29/attachment-0001.html>

2023-06-07 17:53:41 UTC

- reply

📅 Original date posted:2016-10-02
📝 Original message:Peter, are you really going to try to down vote a decent free and
open-source proposal that benefits all the Bitcoin community including
you and your future children because a personal attack to me without any
logic or basis?
Is that the way you collaborate to improving Bitcoin?
I just can't believe it.
Let's open another thread elsewhere to discuss hardware and software
patents, and that particular one, if you wish, this is NOT the place.
On Sun, Oct 2, 2016 at 1:17 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sun, Oct 02, 2016 at 12:49:08PM -0300, Sergio Demian Lerner via
> bitcoin-dev wrote:
>
> I think your history of patenting(1) Bitcoin consensus relevant technology
> is
> sufficient by itself to be extremely dubious of any proposals coming from
> you
> or your colleagues; patents on Bitcoin consensus technology are a serious
> threat to decentralization. Personally, I'm NACKing this proposal on that
> basis
> alone.
>
> You need to rectify this dangerous and unethical behavior in a convincing,
> legally binding way. I'd suggest looking into Blockstream's patent pledges
> as a
> way forward:
>
> https://www.blockstream.com/about/patent_pledge/
>
> I see no reason to have any further discussion of your proposal until this
> is
> rectified.
>
> 1) "AsicBoost is a patent-pending method to improve the efficiency and
> cost of Bitcoin mining by approximately 20%"
> http://www.asicboost.com/single-post/2016/03/24/AsicBoost-Press-Release
>
> > 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
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/67b00718/attachment.html>

2023-06-07 17:53:41 UTC

- 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 17:50:34 UTC

- reply

📅 Original date posted:2016-05-10
📝 Original message:On Tue, May 10, 2016 at 3: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.
>
>
> You say that you want to make patented optimization useless, but you point
to a link that doesn't say anything about ASIC improvements or patents,
which means that you have been planning to change the protocol rules with
some miners (but not all the community).
All changes to the protocol should be discussed in public here. If you want
to make "further similar optimizations useless as well" then maybe you
should propose a switch to EquiHash.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/a24f3b78/attachment.html>

2023-06-07 17:50:30 UTC

- 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 17:50:29 UTC

- 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 17:43:29 UTC

- 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 17:42:37 UTC

- 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 17:38:20 UTC

- 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 17:35:43 UTC

- 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:33:18 UTC

- 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>

2023-06-07 15:47:26 UTC

- reply

2023-06-07 15:45:27 UTC

- reply