Nostr notes by

📅 Original date posted:2017-04-07 📝 Original message:On 6 ...

2023-06-07T17:59:20Z

In reply to nevent1q…u9t4
_________________________

📅 Original date posted:2017-04-07
📝 Original message:On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> Ethically, this situation has some similarities to the DAO fork.
>
>
> Much better analogy:
>
> 1. An ISV make software which makes use of an undocumented OS feature.
> 2. That feature is no longer present in the next OS release.
> 3. ISV suffers losses because its software cannot work under new OS, and
> thus people stop buying it.
>
> I think 99% of programmers would agree that this loss was inflicted by a
> bad decision of ISV, and not by OS vendor changing OS internals. Relying on
> undocumented features is something you do on your own risk.
>

Right. And in this case, code still is law: if the code specifies a version
number field and some miner finds an optimization that only works when the
version number == 1 then it's his own problem once the network upgrades to
version 2. In no way is there anything ethical about blocking the upgrade.

History is not an indicator of the possible values any field can hold in
the future. Limiting your operation to some arbitrary subset is at your own
risk.

Regarding the comparison: I haven't heard anyone even suggest rolling back
the last year of the blockchain to undo the damage already done, any
comparison can end there. If Jonathan wants to persist with this comparison
it would be more like people deciding to stop further funding of the hacked
contract. Yeah, that evil.

--
Jannes Faber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/ea9891e9/attachment.html>;

📅 Original date posted:2016-05-11 📝 Original message:On 11 ...

2023-06-07T17:50:35Z

In reply to nevent1q…5dpn
_________________________

📅 Original date posted:2016-05-11
📝 Original message:On 11 May 2016 at 12:36, Henning Kopp <henning.kopp at uni-ulm.de> wrote:

> On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev
> wrote:
> > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > There is no way to tell from a block if it was mined with AsicBoost or
> > > not. So you don’t know what percentage of the hashrate uses AsicBoost
> at
> > > any point in time. How can you risk forking that percentage out? Note
> that
> > > this would be a GUARANTEED chain fork. Meaning that after you change
> the
> > > block mining algorithm some percentage of hardware will no longer be
> able
> > > to produce valid blocks. That hardware cannot “switch over” to the
> majority
> > > chain even if it wanted to. Hence you are guaranteed to have two
> > > co-existing bitcoin blockchains afterwards.
> > >
> > > Again: this is unlike the hypothetical persistence of two chains after
> a
> > > hardfork that is only contentious but doesn’t change the mining
> algorithm,
> > > the kind of hardfork you are proposing would guarantee the persistence
> of
> > > two chains.
> > >
> >
> > Assuming AsicBoost miners are in the minority, their chain will
> constantly
> > get overtaken. So it will not be one endless hard fork as you claim, but
> > rather AsicBoost blocks will continue to be ignored (orphaned) until they
> > stop making them.
>
> At least until a difficulty adjustment on the AsicBoost chain takes
> place. From that point on, both chains, the AsicBoost one and the
> forked one will grow approximately at the same speed.
>
>
No: you are still assuming AsicBoost miners would reject normal blocks.
They don't now and they would have to specifically code for that as a reply
to AsicBoost being banned. So there won't be two chains at all, only the
main chain with a lot (more than usual) of short (few blocks) forks. Each
forks starts anew, it's not one long fork. Therefore there is no
"difficulty adjustment on the AiscBoost chain".

Now if they do decide to ban non-AsicBoost blocks as a response to being
banned themselves, they're just another altcoin with a different PoW and no
one would have a reason to use them over Bitcoin (apart from maybe selling
those forked coins asap).

You're confused about what "longest" means as well: it's not just the
number of blocks, it's the aggregate difficulty that counts: so AsicBoost
would never become "longer" (more total work) either.

Hope this helps clear things up.

--
Jannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/9f723302/attachment.html>;

📅 Original date posted:2016-05-11 📝 Original message:On 11 ...

2023-06-07T17:50:35Z

In reply to nevent1q…5494
_________________________

📅 Original date posted:2016-05-11
📝 Original message:On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> There is no way to tell from a block if it was mined with AsicBoost or
> not. So you don’t know what percentage of the hashrate uses AsicBoost at
> any point in time. How can you risk forking that percentage out? Note that
> this would be a GUARANTEED chain fork. Meaning that after you change the
> block mining algorithm some percentage of hardware will no longer be able
> to produce valid blocks. That hardware cannot “switch over” to the majority
> chain even if it wanted to. Hence you are guaranteed to have two
> co-existing bitcoin blockchains afterwards.
>
> Again: this is unlike the hypothetical persistence of two chains after a
> hardfork that is only contentious but doesn’t change the mining algorithm,
> the kind of hardfork you are proposing would guarantee the persistence of
> two chains.
>

Assuming AsicBoost miners are in the minority, their chain will constantly
get overtaken. So it will not be one endless hard fork as you claim, but
rather AsicBoost blocks will continue to be ignored (orphaned) until they
stop making them.

That hardware cannot “switch over” to the majority chain even if it wanted
> to.
>

They will in fact continually "switch over" to the majority, they just are
unable to extend that majority chain themselves.

--
Jannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/97d6a71f/attachment.html>;

📅 Original date posted:2016-02-07 📝 Original message:On 6 ...

2023-06-07T17:48:47Z

In reply to nevent1q…6ahg
_________________________

📅 Original date posted:2016-02-07
📝 Original message:On 6 Feb 2016 4:41 p.m., "Gavin Andresen via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up. As I said,
I surveyed several of the biggest infrastructure providers and the btcd
lead developer and they all agree "28 days is plenty of time."

28 days doesn't sound like enough for exchanges and others holding 3rd
party coins. They will have to start untangling the Bitcoins from
classiccoins immediately, while pausing all withdrawals. They *must* be
able to send their customers both coins as separate withdrawals. If not,
that amounts to theft of their customers funds.

(Note that the above describes the honest exchanges. Imagine the dishonest
ones that simply steal the classiccoins from their customers and sell them
for their own profit.)

The only other option is guaranteeing customers both coins in one
transaction, which they can't.

Surely you can't expect small entities to start putting in massive man
hours into this even before the hard fork has been triggered? Or even big
entities to have all that implemented and tested within *20* working days?

--
Jannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/1c6a2ee5/attachment.html>;

📅 Original date posted:2015-12-25 📝 Original message:On 25 ...

2023-06-07T17:47:05Z

In reply to nevent1q…0x34
_________________________

📅 Original date posted:2015-12-25
📝 Original message:On 25 Dec 2015 12:15 p.m., "Ittay" <ittay.eyal at cornell.edu> wrote:

> As for masquerading as multiple small pools -- that's a very good point,
with a surprising answer: it doesn't really matter. An attacker attacks all
parts of the open pool proportionally to their size, and the result is
basically identical to that of attacking a single large pool.

While true, that's only relevant to the indiscriminate attacker! The
vigilante attacker that wants to hurt only pools that are too large,
doesn't even know that there's a need to attack as all of them seem small.

That's what i was saying.

>
> On Mon, Dec 21, 2015 at 1:39 PM, Jannes Faber via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> If you're saying a block withholding attack is a nice weapon to have to
dissuade large pools, isn't that easily defeated by large pools simply
masquerading as multiple small pools? As, for all we know, ghash may have
done?
>>
>> If you don't know who to attack there's no point in having the weapon.
While that weapon is still dangerous in the hands of others that are
indiscriminate, like the solo miners example of Peter Todd.
>>
>> Sorry if i misunderstood your point.
>>
>>
>> --
>> Jannes
>>
>> On 20 December 2015 at 18:00, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete at petertodd.org> wrote:
>>>>
>>>> There are a number of techniques that can be used to detect block
>>>> withholding attacks that you are not aware of. These techniques usually
>>>> have the characteristic that if known they can be avoided, so obviously
>>>> those who know about them are highly reluctant to reveal what exactly
>>>> they are. I personally know about some of them and have been asked to
>>>> keep that information secret, which I will.
>>>
>>>
>>> Indeed, there are lots of weak measures that one could employ against
>>> an uninformed attacker. As I mentioned before, these are unlikely to be
>>> effective against a savvy attacker, and this is a good thing.
>>>
>>>>
>>>> In the context of KYC, this techniques would likely hold up in court,
>>>> which means that if this stuff becomes a more serious problem it's
>>>> perfectly viable for large, well-resourced, pools to prevent block
>>>> withholding attacks, in part by removing anonymity of hashing power.
>>>> This would not be a positive development for the ecosystem.
>>>
>>>
>>> KYC has a particular financial-regulation connotation in Bitcoin
circles,
>>> of which I'm sure you're aware, and which you're using as a spectre.
>>> You don't mean government-regulated-KYC a la FINCEN and Bitcoin
>>> exchanges like Coinbase, you are just referring to a pool operator
>>> demanding to know that its customer is not coming from its competitors'
>>> data centers.
>>>
>>> And your prediction doesn't seem well-motivated or properly justified.
>>> There are tons of conditionals in your prediction, starting with the
premise
>>> that every single open pool would implement some notion of identity
>>> checking. I don't believe that will happen. Instead, we will have the
bigger
>>> pools become more suspicious of signing up new hash power, which is a
>>> good thing. And we will have small groups of people who have some reason
>>> for trusting each other (e.g. they know each other from IRC,
conferences,
>>> etc) band together into small pools. These are fantastic outcomes for
>>> decentralization.
>>>
>>>> Secondly, DRM tech can also easily be used to prevent block withholding
>>>> attacks by attesting to the honest of the hashing power. This is being
>>>> discussed in the industry, and again, this isn't a positive development
>>>> for the ecosystem.
>>>
>>>
>>> DRM is a terrible application. Once again, I see that you're trying to
use those
>>> three letters as a spectre as well, knowing that most people hate DRM,
but
>>> keep in mind that DRM is just an application -- it's like pointing to
Adobe Flash
>>> to taint all browser plugins.
>>>
>>> The tech behind DRM is called "attestation," and it provides a
technical
>>> capability not possible by any other means. In essence, attestation can
ensure that
>>> a remote node is indeed running the code that it purports to be
running. Since
>>> most problems in computer security and distributed systems stem from not
>>> knowing what protocol the attacker is going to follow, attestation is
the only
>>> technology we have that lets us step around this limitation.
>>>
>>> It can ensure, for instance,
>>> - that a node purporting to be Bitcoin Core (vLatest) is indeed
running an
>>> unadulterated, latest version of Bitcoin Core
>>> - that a node claiming that it does not harvest IP addresses from SPV
>>> clients indeed does not harvest IP addresses.
>>> - that a cloud hashing outfit that rented out X terahashes to a user
did
>>> indeed rent out X terahashes to that particular user,
>>> - that a miner operating on behalf of some pool P will not misbehave
and
>>> discard perfectly good blocks
>>> and so forth. All of these would be great for the ecosystem. Just
getting rid
>>> of the cloudhashing scams would put an end to a lot of heartache.
>>>
>>>> > Keep in mind that when an open pool gets big, like GHash did and
>>>> > two other pools did before them, the only thing at our disposal used
>>>> > to be to yell at people about centralization until they left the big
>>>> > pools and reformed into smaller groups. Not only was such yelling
>>>> > kind of desperate looking, it wasn't incredibly effective, either.
>>>> > We had no protocol mechanisms that put pressure on big pools to
>>>> > stop signing up people. Ittay's discovery changed that: pools that
>>>> > get to be very big by indiscriminately signing up miners are likely
to
>>>> > be infiltrated and their profitability will drop. And Peter's post is
>>>> > evidence that this is, indeed, happening as predicted. This is a
>>>> > good outcome, it puts pressure on the big pools to not grow.
>>>>
>>>> GHash.io was not a pure pool - they owned and operated a significant
>>>> amount of physical hashing power, and it's not at all clear that their
%
>>>> of the network actually went down following that 51% debacle.
>>>
>>>
>>> Right, it's not clear at all that yelling at people has much effect. As
much
>>> fun as I had going to that meeting with GHash in London to ask them to
>>> back down off of the 51% boundary, I am pretty sure that yelling at
large
>>> open pools will not scale. We needed better mechanisms for keeping pools
>>> in check.
>>>
>>> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
>>> time when we should count our blessings, not work actively to render
>>> them inoperable.
>>>
>>>> Currently a significant % of the hashing power - possibly a majority -
>>>> is in the form of large hashing installations whose owners
individually,
>>>> and definitely in trusting groups, have enough hashing power to solo
>>>> mine. Eyal's results indicate those miners have incentives to attack
>>>> pools, and additionally they have the incentive of killing off pools to
>>>> make it difficult for new competition to get established, yet they
>>>> themselves are not vulnerable to that attack.
>>>
>>>
>>> There are indeed solo miners out there who can attack the big open
>>> pools. The loss of the biggest open pools would not be a bad outcome.
>>> Pools >25% pose a danger, and the home miner doesn't need a pool
>>> >25% for protection against variance.
>>>
>>>> > Peter, you allude to a specific suggestion from Luke-Jr. Can you
>>>> > please describe what it is?
>>>>
>>>> Basically you have the pool pick a secret k for each share, and commit
>>>> to H(k) in the share. Additionally the share commits to a target
divider
>>>> D. The PoW validity rule is then changed from H(block header) < T, to
be
>>>> H(block header) < T * D && H(H(block header) + k) < max_int / D
>>>
>>>
>>> Thanks, this requires a change to the Bitcoin PoW. Good luck with that!
>>>
>>> Once again, this suggestion would make the GHash-at-51% situation
>>> possible again. Working extra hard to re-enable those painful days
>>> sounds like a terrible idea.
>>>
>>> - egs
>>>
>>>
>>> _______________________________________________
>>> 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/20151225/352db21d/attachment-0001.html>;

📅 Original date posted:2015-12-21 📝 Original message:If ...

2023-06-07T17:47:03Z

In reply to nevent1q…j5v7
_________________________

📅 Original date posted:2015-12-21
📝 Original message:If you're saying a block withholding attack is a nice weapon to have to
dissuade large pools, isn't that easily defeated by large pools simply
masquerading as multiple small pools? As, for all we know, ghash may have
done?

If you don't know who to attack there's no point in having the weapon.
While that weapon is still dangerous in the hands of others that are
indiscriminate, like the solo miners example of Peter Todd.

Sorry if i misunderstood your point.

--
Jannes

On 20 December 2015 at 18:00, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete at petertodd.org> wrote:
>
>> There are a number of techniques that can be used to detect block
>> withholding attacks that you are not aware of. These techniques usually
>> have the characteristic that if known they can be avoided, so obviously
>> those who know about them are highly reluctant to reveal what exactly
>> they are. I personally know about some of them and have been asked to
>> keep that information secret, which I will.
>>
>
> Indeed, there are lots of weak measures that one could employ against
> an uninformed attacker. As I mentioned before, these are unlikely to be
> effective against a savvy attacker, and this is a good thing.
>
>
>> In the context of KYC, this techniques would likely hold up in court,
>> which means that if this stuff becomes a more serious problem it's
>> perfectly viable for large, well-resourced, pools to prevent block
>> withholding attacks, in part by removing anonymity of hashing power.
>> This would not be a positive development for the ecosystem.
>>
>
> KYC has a particular financial-regulation connotation in Bitcoin circles,
> of which I'm sure you're aware, and which you're using as a spectre.
> You don't mean government-regulated-KYC a la FINCEN and Bitcoin
> exchanges like Coinbase, you are just referring to a pool operator
> demanding to know that its customer is not coming from its competitors'
> data centers.
>
> And your prediction doesn't seem well-motivated or properly justified.
> There are tons of conditionals in your prediction, starting with the
> premise
> that every single open pool would implement some notion of identity
> checking. I don't believe that will happen. Instead, we will have the
> bigger
> pools become more suspicious of signing up new hash power, which is a
> good thing. And we will have small groups of people who have some reason
> for trusting each other (e.g. they know each other from IRC, conferences,
> etc) band together into small pools. These are fantastic outcomes for
> decentralization.
>
> Secondly, DRM tech can also easily be used to prevent block withholding
>> attacks by attesting to the honest of the hashing power. This is being
>> discussed in the industry, and again, this isn't a positive development
>> for the ecosystem.
>>
>
> DRM is a terrible application. Once again, I see that you're trying to use
> those
> three letters as a spectre as well, knowing that most people hate DRM, but
> keep in mind that DRM is just an application -- it's like pointing to
> Adobe Flash
> to taint all browser plugins.
>
> The tech behind DRM is called "attestation," and it provides a technical
> capability not possible by any other means. In essence, attestation can
> ensure that
> a remote node is indeed running the code that it purports to be running.
> Since
> most problems in computer security and distributed systems stem from not
> knowing what protocol the attacker is going to follow, attestation is the
> only
> technology we have that lets us step around this limitation.
>
> It can ensure, for instance,
> - that a node purporting to be Bitcoin Core (vLatest) is indeed running
> an
> unadulterated, latest version of Bitcoin Core
> - that a node claiming that it does not harvest IP addresses from SPV
> clients indeed does not harvest IP addresses.
> - that a cloud hashing outfit that rented out X terahashes to a user did
> indeed rent out X terahashes to that particular user,
> - that a miner operating on behalf of some pool P will not misbehave and
> discard perfectly good blocks
> and so forth. All of these would be great for the ecosystem. Just getting
> rid
> of the cloudhashing scams would put an end to a lot of heartache.
>
> > Keep in mind that when an open pool gets big, like GHash did and
>> > two other pools did before them, the only thing at our disposal used
>> > to be to yell at people about centralization until they left the big
>> > pools and reformed into smaller groups. Not only was such yelling
>> > kind of desperate looking, it wasn't incredibly effective, either.
>> > We had no protocol mechanisms that put pressure on big pools to
>> > stop signing up people. Ittay's discovery changed that: pools that
>> > get to be very big by indiscriminately signing up miners are likely to
>> > be infiltrated and their profitability will drop. And Peter's post is
>> > evidence that this is, indeed, happening as predicted. This is a
>> > good outcome, it puts pressure on the big pools to not grow.
>>
>> GHash.io was not a pure pool - they owned and operated a significant
>> amount of physical hashing power, and it's not at all clear that their %
>> of the network actually went down following that 51% debacle.
>>
>
> Right, it's not clear at all that yelling at people has much effect. As
> much
> fun as I had going to that meeting with GHash in London to ask them to
> back down off of the 51% boundary, I am pretty sure that yelling at large
> open pools will not scale. We needed better mechanisms for keeping pools
> in check.
>
> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
> time when we should count our blessings, not work actively to render
> them inoperable.
>
> Currently a significant % of the hashing power - possibly a majority -
>> is in the form of large hashing installations whose owners individually,
>> and definitely in trusting groups, have enough hashing power to solo
>> mine. Eyal's results indicate those miners have incentives to attack
>> pools, and additionally they have the incentive of killing off pools to
>> make it difficult for new competition to get established, yet they
>> themselves are not vulnerable to that attack.
>>
>
> There are indeed solo miners out there who can attack the big open
> pools. The loss of the biggest open pools would not be a bad outcome.
> Pools >25% pose a danger, and the home miner doesn't need a pool
> >25% for protection against variance.
>
> > Peter, you allude to a specific suggestion from Luke-Jr. Can you
>> > please describe what it is?
>>
>> Basically you have the pool pick a secret k for each share, and commit
>> to H(k) in the share. Additionally the share commits to a target divider
>> D. The PoW validity rule is then changed from H(block header) < T, to be
>> H(block header) < T * D && H(H(block header) + k) < max_int / D
>>
>
> Thanks, this requires a change to the Bitcoin PoW. Good luck with that!
>
> Once again, this suggestion would make the GHash-at-51% situation
> possible again. Working extra hard to re-enable those painful days
> sounds like a terrible idea.
>
> - egs
>
>
> _______________________________________________
> 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/20151221/bf51d088/attachment.html>;

📅 Original date posted:2015-06-12 📝 Original ...

2023-06-07T15:37:27Z

In reply to nevent1q…n6s5
_________________________

📅 Original date posted:2015-06-12
📝 Original message:I'm imagining in Peter's proposal it's not the transaction votes that are
counted but only the votes in the blocks? So miners get to vote but they
risk losing money by having to exclude counter voting transactions. But
garbage transactions are no problem at all.

Note that users that want to cast a vote "pay" for that by increased
confirmation time (on average, hopefully slightly depending on the trend).

On Fri, Jun 12, 2015, 20:27 Matt Whitlock <bip at mattwhitlock.name> wrote:

> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
> > Peter it's not clear to me that your described protocol is free of miner
> > influence over the vote, by artificially generating transactions which
> they
> > claim in their own blocks
>
> Miners could fill their blocks with garbage transactions that agree with
> their vote, but this wouldn't bring them any real income, as they'd be
> paying their own money as fees to themselves. To get real income, miners
> would have to vote in accordance with real users.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150612/57d6fac0/attachment.html>;