Nostr notes by

📅 Original date posted:2017-05-26 📝 Original message:I ...

2023-06-07T18:01:53Z

In reply to nevent1q…2sxj
_________________________

📅 Original date posted:2017-05-26
📝 Original message:I rarely post here, out of respect to the mailing list. But since my name
was mentioned...

I much prefer Gregory Maxwell's proposal to defuse covert ASICBOOST (only)
with a segwit-like commitment to the coinbase which does not obligate
miners to signal Segwit or implement Segwit, thus disarming any suspicion
that the issue is being exploited only to activate Segwit.

This proposal is unnecessarily conflating two contentious issues and will
attract criticism of self serving motivation.

Politicising CVE is damaging to the long term bitcoin development and to
its security. Not claiming that is the intent here, but the damage is done
by the mere appearance of motive.

On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

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

📅 Original date posted:2013-11-08 📝 Original ...

2023-06-07T15:09:05Z

In reply to nevent1q…69uu
_________________________

📅 Original date posted:2013-11-08
📝 Original message:Nicholas Weaver is reporting that pools have already started delaying
blocks, something that hints at Selfish Mining, since Nov. 3rd.
https://medium.com/something-like-falling/d321a2ef9317

He dismisses other reasons for delayed block propagation.

Any ideas on whether pools are already mucking around with block delaying
tactics?

I have no idea if this report is accurate or explained by some other issue
in the network, does anyone here have a comment on this?

On Thu, Nov 7, 2013 at 10:28 AM, Daniel Lidstrom <lidstrom83 at gmail.com>wrote:

> Hey Peter, something seems wrong with your above analysis: I think a miner
> would withhold his block not because it leads to a greater probability of
> winning the next one, but because it increases his expected revenue.
>
> Suppose a cabal with fraction q of the total hashing power is n blocks
> ahead on a secret branch of that has mined r_tot coins, and let r_next be
> its next block's reward. If the cabal chooses not to broadcast its secret
> chain until at least the next block, its expected revenue after the next
> block is found is
>
> (1 - (1-q)^(n+1))*(r_tot + r_next)
>
> If it does broadcast, its expected revenue after the next block is found is
>
> r_tot + q * r_next
>
> If the cabal seeks only to maximize immediate revenue, then after a bit of
> algebra we find that it will withhold its chain if
>
> q > 1 - ( 1 + r_tot / r_next )^(-1/n)
>
> So if the cabal has just mined his first block off of the public chain,
> i.e. n = 1, and if the block reward is relatively stable, i.e. r_next =
> r_tot, then it needs q > 50% to profitably withhold, not the 29.2% you
> calculated.
>
> From this formula we can also see that if the miner wins the race and
> withholds again, then he must grow q to compensate for the increase in
> r_tot, and any decrease in n. So generally publication becomes
> increasingly in the cabal's interest, and secret chains will tend not to
> grow too large (intuition tells me that simulations using the above formula
> should bear this out).
>
> This seem correct to you?
>
>
> On Thu, Nov 7, 2013 at 9:14 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> Once the ASIC race calms down because everyone has one, has more or less
>> optimal power supplies, process improvements aren't easily reachable
>> anymore etc then I'd expect people to dissipate from the large pools
>> because eliminating their fees will become the next lowest hanging fruit to
>> squeeze out extra profit. There's no particular reason we need only a
>> handful of pools that control a major fraction of the hashpower.
>>
>> If we end up with a few hundred pools or lots of miners on p2pool, then a
>> lot of these theoretical attacks become not very relevant (I don't think ID
>> sacrifices will be so common or large as to justify a pile of custom mining
>> code+strategies at any point ...)
>>
>>
>> On Thu, Nov 7, 2013 at 2:24 PM, Peter Todd <pete at petertodd.org> wrote:
>>
>>> On Thu, Nov 07, 2013 at 02:56:56PM +1000, Gavin Andresen wrote:
>>> > > P.S: If any large pools want to try this stuff out, give me a shout.
>>> You
>>> > > have my PGP key - confidentiality assured.
>>> > >
>>> >
>>> > If I find out one of the large pools decides to run this 'experiment'
>>> on
>>> > the main network, I will make it my mission to tell people to switch
>>> to a
>>> > more responsible pool.
>>>
>>> I hope they listen.
>>>
>>> A few months ago ASICMiner could have made use of that attack if my
>>> memories of their peak hashing power were correct. They certainely could
>>> have used the selfish miner version, (we need better name for that)
>>> although development costs would eat into profits.
>>>
>>> GHash.IO, 22%, says they're a "private Bitfury ASIC mining pool" - dunno
>>> what they mean by that, but they're involved with CEX.IO who has
>>> physical control of a bunch of hashing power so I guess that means their
>>> model is like ASICMiners. They're a bit short of 30%, but maybe some
>>> behind-the-scenes deals would fix that, and/or lowering the barrier with
>>> reactive block publishing. (a better name)
>>>
>>> > And if you think you can get away with driving up EVERYBODY's orphan
>>> rate
>>> > without anybody noticing, you should think again.
>>>
>>> ...and remember, if you only do the attack a little bit, you still can
>>> earn more profit, and only drive up the orphan rate a little bit. So who
>>> knows, maybe the orphans are real, or maybe they're an attack? ASICMiner
>>> was involved with a bunch of orphans a while back...
>>>
>>> You know what this calls for? A witchhunt!
>>>
>>> BURN THE LARGE POOLS!
>>>
>>> > > P.P.S: If you're mining on a pool with more than, like, 1% hashing
>>> > > power, do the math on varience... Seriously, stop it and go mine on a
>>> > > smaller pool, or better yet, p2pool.
>>> > >
>>> >
>>> > That I agree with.
>>>
>>> Glad to hear.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000007bd936f19e33bc8b8f9bb1f4c013b863ef60a7f5a6a5d2112
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models.
>>> Explore
>>> techniques for threading, error checking, porting, and tuning. Get the
>>> most
>>> from the latest Intel processors and coprocessors. See abstracts and
>>> register
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the
>> most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131108/ce3a2e5b/attachment.html>;

📅 Original date posted:2013-06-06 📝 Original message:Is ...

2023-06-07T15:02:43Z

In reply to nevent1q…0d4g
_________________________

📅 Original date posted:2013-06-06
📝 Original message:Is there any consideration given to the fact that bitcoin can operate as a
platform for many other services, if it is able to be neutral to payload,
as long as the fee is paid for the transaction size?

Unless I have misunderstood this discussion, it seems to me that this is a
bit like saying in 1990 "IP Is only for email, the majority of users want
email, we shouldn't allow video, voice or images". Ooops, there goes the
web.

Is it possible to solve this by solving the issue of provably un-spendable
outputs without foreclosing on the possibility of other types of
transaction payloads (ie, not money), that would open the possibility for a
myriad of layered apps above? For example, hashes of content that is
external to bitcoin, that people want to pay to have timestamped in the
blockchain, as provably unspendable outputs.

The social compact is to accept transaction for fee. I think it is a major
mistake to make decisions that discriminate on the content of the
transaction, saying that some uses are not appropriate. If the fee is paid
and it covers the size of the transaction, why would it matter if it is not
a payment?

I could be totally misreading this thread, too, so please allow me some
slack if I have!

On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr <luke at dashjr.org> wrote:

> On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
> > scriptPubKey: <data> OP_TRUE
> >
> > ...
> > Along with that change anyone-can-spend outputs should be make
> IsStandard()
> > so they will be relayed.
>
> Data does not belong in the blockchain. People running nodes have all
> implicitly agreed to store the blocks for financial purposes, and storing
> data
> is a violation of that social contract. Proof-of-stake may be arguably
> financial, but I'm sure there must be a way to do it without spamming
> people
> against their consent.
>
> > The alternative is sacrifices to unspendable outputs, which is very
> > undesirable compared to sending the money to miners to further
> > strengthen the security of the network.
>
> The alternative is to make other standard outputs unable to store data as
> well.
>
> Luke
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130606/89394efb/attachment.html>;