Ittay [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 17:47:03

- reply

📅 Original date posted:2015-12-25
📝 Original message:Treating the pool block withholding attack as a weapon has bad
connotations, and I don't think anyone directly condones such an attack.
Nevertheless, the mere possibility of the attack could drive miners away
from those overly-large open pools.
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.
All that being said -- it's not great to rely on the potential of attacks
and on threats against the honest large pools out there (including GHash,
which, afaik, did nothing more wrong than being successful).
Best,
Ittay
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/54346fe1/attachment.html>

2023-06-07 17:44:18

- reply

📅 Original date posted:2015-11-06
📝 Original message:On Tue, Oct 27, 2015 at 10:08 PM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> Oops, just realized I never responded to this...
>
> On 10/15/15 15:09, Ittay wrote:
> > Thanks, Matt. Response inline.
> >
> > On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo <lf-lists at mattcorallo.com
> > <mailto:lf-lists at mattcorallo.com>> wrote:
> >
> > That conversation missed a second issue. Namely that there is no way
> > to punish people if there is a double spend in a micro block that
> > happens in key block which reorg'd away the first transaction. eg
> > one miner mines a transaction in a micro block, another miner
> > (either by not having seen the first yet, or being malicious -
> > potentially the same miner) mines a key block which reorgs away the
> > first micro block and then, in their first micro block, mines a
> > double spend. This can happen at any time, so you end up having to
> > fall back to regular full blocks for confirmation times :(.
> >
> >
> > If NG is to be used efficiently, microblocks are going to be very
> > frequent, and so such forks should occur at almost every key-block
> > publication. Short reorgs as you described are the norm. A user should
> > wait before accepting a transaction to make sure there was no key-block
> > she missed. The wait time is chosen according to the network propagation
> > delay (+as much slack as the user feels necessary). This is similar to
> > the situation in Bitcoin when you receive a block. To be confident that
> > you have one confirmation you should wait for the propagation time of
> > the network to make sure there is no branch you missed.
>
> I think you're overstating how short the wait times can be. They need to
> be much longer than the network propagation delay.
>
> > As for the malicious case: the attacker has to win the key-block, have
> > the to-be-inverted transaction in the previous epoch, and withhold his
> > key-block for a while. That being said, indeed our fraud proof scheme
> > doesn't catch such an event, as it is indistinguishable from benign
> > behavior.
>
> The attacker does not need to withold their keyblock at all. All the
> attacker does is, for every transaction they ever send, after it is
> included in a microblock, set their hashpower to start mining a keyblock
> immediately prior to this microblock. When they find a keyblock, they
> immediately announce it and start creating microblocks, the first of
> which double-spends the previous transaction. If they dont win the key
> block, oh well, their payment went through normally and they couldn't
> double-spend.
>
> In chatting with Glenn about this, we roughly agreed that the
> confirmation time for microblocks possibly doesn't need to be a full
> key-block, but it needs to be a reasonable period after which such an
> attacker would lose more in fees than the value of their double-spend
> (ie because the key-block afterwards gets 20% more in fees than the
> key-block before hand). In any case, the game theory here starts to get
> rather complicated and it doesn't make me want to suggest accepting
> microblocks as confirmations is safe.
>
Yes, an attacker can continuously try to do this, losing all (and only)
fees.
They will succeed every time they mine a block after the to-be-double-spent
transaction is placed by the current leader. So a microblock + delay is
stronger
than a zero-confirmation transaction, but not as strong as a first-block
confirmation.
A game theory analysis is indeed difficult here, mainly since the
assumptions
are not entirely clear. We are working towards this, starting with
formalizing
the attacker's incentive structure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151106/c5d8d279/attachment.html>

2023-06-07 17:43:32

- reply

📅 Original date posted:2015-10-15
📝 Original message:Hi Odinn,
I guess to answer we should separate pure-NG from
the hypothetical overlay-NG that runs on top of Bitcoin.
For pure NG one still has to set a transaction bandwidth
limit due to bandwidth and storage limitations of
the individual clients. This rate can be arbitrarily high
with NG without compromising protocol security.
With overlay NG you cannot run above Bitcoin's
bandwidth because all clients must agree on the ledger,
so different clients cannot run at different rates. You
could do two things:
1. Significantly reduce observed latency (time to first
confirmation). Users get better confidence as more
miners adopt NG.
2. Increase the bandwidth once everyone is on
board.
As for privacy - I don't see why NG would change things.
Such privacy schemes are only concerned with the
transaction DAG. NG does not touch this structure. Am
I missing something?
Thanks,
Ittay
On Thu, Oct 15, 2015 at 4:48 AM, odinn <odinn.cyberguerrilla at riseup.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> So, there could not be, for example, a user decision to activate it?
> (versus not activate it)? I'm wondering if something about this can
> be boiled down to allowing the user to make a choice on the matter
> (turn it on and off). In Bitcoin-NG, the protocol as follows (as
> described in a general overview of it): every 10 minutes, NG elects a
> 'leader,' who then vets future transactions as soon as they happen. NG
> approach supposedly can run as fast as the network will allow.
>
> If this is the case, and if NG functions without major hiccup,
> shouldn't a user (of Core, for example) be able to be given the option
> to choose between:
>
> (a) being limited by the blocksize and block interval, or
> (b) running out as fast as the network will allow (NG)?
>
> The other questions I had pertained to privacy. How would this scheme
> affect users who would be trying to do things like stealth or
> confidential transactions?
>
> Matt Corallo:
> > Huh? No... This is not a Bitcoin Core issue, it is a Bitcoin
> > protocol one and should be discussed here, not on github. I really
> > appreciate Ittay and Emin's efforts in this space and their
> > willingness to work with the Bitcoin community on it! It seems it
> > still needs some tuning, but seems like if the pool-mining issues
> > were resolved it could make block relay times irrelevant, at
> > least.
> >
> > Matt
> >
> > On October 14, 2015 3:21:19 PM PDT, odinn via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote: This (Bitcoin-NG in
> > concept) could be done as a (issue and pull request process) to
> > Bitcoin Core itself, amirite? It seems like it would provide an
> > interesting issue to open and have healthy discussion on both
> > mailing list and github, adding the caveat that it would be at the
> > user's option. Thus if something like Bitcoin-NG did come to be it
> > would be something more like a feature that the user could
> > activate / deactivate from within Core. I assume it would be
> > default off, but with the option to utilize. Code would thus be
> > available to others as well. I am not saying yea or nay on it,
> > just that it seems like this could be done.
> >
> > Some notes:
> >
> > Once a node generates a key block it becomes the leader. As a
> > leader, the node is allowed to generate microblocks at a set
> > rate smaller than a prede >ned maximum. A microblock in
> > Bitcoin-NG contains ledger entries and a header. The header
> > contains the reference to the previous block, the current
> > GMT time, a cryptographic hash of its ledger entries, and
> > a cryptographic signature of the header. The signature uses
> > the private key that matches the public key in the latest key
> > block in the chain. For a microblock to be valid, all its entries
> > must be valid according to the specification of the state machine,
> > and the signature has to be valid. However, the microblocks, it is
> > said, don't affect the weight of the chain, because they do not
> > contain proof of work. It is assumed by the authors of this model
> > that this situation is critical for maintaining incentives here.
> >
> > The questions that then begin to emerge to me are how is this
> > information managed and protected? The headers, thus containing
> > reference(s) to previous block(s), current GMT time(s),
> > cryptographic hash(es) of ledger entries, and cryptographic
> > signature(s) of the headers, so forth, and other information. Can
> > the Bitcoin-NG scheme be designed or implemented in a manner which
> > supports Stealth sends, Confidential Transactions, or similar
> > privacy measures? Or is this something which cannot be answered at
> > this time?
> >
> > Emin Gün Sirer via bitcoin-dev:
> >>>>> So it seems to me that all I need to do is figure out who
> >>>>> the current
> >>>> leader is,
> >>>>> and DDoS him off the network to shut Bitcoin-NG down.
> >>>>
> >>>> Good point. If NG is layered on top of Bitcoin, we'd retain
> >>>> all of Bitcoin as is. This would confer all the benefits of
> >>>> Bitcoin's retrospective blocks, as well as add the ability to
> >>>> mint microblocks with low latency in between. And despite the
> >>>> phrase "the leader," the actual leader in NG is a key, not a
> >>>> specific node. That makes it possible to deter DDoS attacks
> >>>> by dynamically migrating where in the network the leader is
> >>>> operating in response to an attack. Finally, DDoS attacks
> >>>> against miners are already possible, but they seem rare, and
> >>>> I suspect it's at least partly because of the success of Matt
> >>>> Corallo's high speed bitcoin relay network. Similar defenses
> >>>> can apply here.
> >>>>
> >>>> - egs
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath
> >>>> <bob at mcelrath.org> wrote:
> >>>>
> >>>>> So it seems to me that all I need to do is figure out who
> >>>>> the current leader is, and DDoS him off the network to
> >>>>> shut Bitcoin-NG down.
> >>>>>
> >>>>> This is a significant advantage to bitcoin's ex-post-facto
> >>>>> blocks: no one knows where the next one will come from.
> >>>>> The only way to shut the network down is to shut all nodes
> >>>>> down.
> >>>>>
> >>>>> Emin Gün Sirer via bitcoin-dev
> >>>>> [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.
> >>>>>>
> >>>>>> !DSPAM:561e98cd301391127216946!
> >>>>>
> >>>>>> _______________________________________________
> >>>>>> bitcoin-dev mailing list
> >>>>>> bitcoin-dev at lists.linuxfoundation.org
> >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> !DSPAM:561e98cd301391127216946!
> >>>>>
> >>>>> -- Cheers, Bob McElrath
> >>>>>
> >>>>> "For every complex problem, there is a solution that is
> >>>>> simple, neat, and wrong." -- H. L. Mencken
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________ 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
> >
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCgAGBQJWH2hSAAoJEGxwq/inSG8CztwH/3kaBDCpci0WMjw9gEUybI+R
> 320i/cbPHHFO0eEJgWOK0mpYXYiEyoZULRjvHBjTNTS7wUVNmKsnmZDx1n9X9OCS
> hQc9yoSZejoulA0f/Sys++N5ku9KPYN9EFnHpmgTtV7OW7aD8L66PCtiAOhNy7WD
> T75eXjQvhWCCId1C3lvIzB6X1qTdK1gGMjNHzv49FP6RJDXa7RB7ceKrHwrXQ8J/
> kbQvwOjfmGbfDZb0tSvlNKT05s4CWW6TzsUdkg5QfMs16r6b1TAz55LLj7bonTNG
> muFhywfBo0oLG0NbTTQTW0pmq9TF8iy8HV/4Z48Yu8bwrZ7UA1+Q7ghV3AFPHyE=
> =x4Ek
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151015/d5d9c001/attachment-0001.html>

2023-06-07 17:43:29

- reply

📅 Original date posted:2015-10-14
📝 Original message:On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath <bob at mcelrath.org> wrote:
> So it seems to me that all I need to do is figure out who the current
> leader is,
> and DDoS him off the network to shut Bitcoin-NG down.
>
> This is a significant advantage to bitcoin's ex-post-facto blocks: no one
> knows
> where the next one will come from. The only way to shut the network down
> is to
> shut all nodes down.
>
That's an interesting point, but such an attack is difficult to pull off.
Miners
often run multiple well connected nodes, allowing them to propagate their
generated blocks from multiple vantage points.
Best,
Ittay
>
> Emin Gün Sirer via bitcoin-dev [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.
> >
> > !DSPAM:561e98cd301391127216946!
>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > !DSPAM:561e98cd301391127216946!
>
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and
> wrong."
> -- H. L. Mencken
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/82c897aa/attachment.html>

2023-06-07 17:43:28

- reply

📅 Original date posted:2015-10-15
📝 Original message:Thanks, Matt. Response inline.
On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> That conversation missed a second issue. Namely that there is no way to
> punish people if there is a double spend in a micro block that happens in
> key block which reorg'd away the first transaction. eg one miner mines a
> transaction in a micro block, another miner (either by not having seen the
> first yet, or being malicious - potentially the same miner) mines a key
> block which reorgs away the first micro block and then, in their first
> micro block, mines a double spend. This can happen at any time, so you end
> up having to fall back to regular full blocks for confirmation times :(.
>
If NG is to be used efficiently, microblocks are going to be very frequent,
and so such forks should occur at almost every key-block publication. Short
reorgs as you described are the norm. A user should wait before accepting a
transaction to make sure there was no key-block she missed. The wait time
is chosen according to the network propagation delay (+as much slack as the
user feels necessary). This is similar to the situation in Bitcoin when you
receive a block. To be confident that you have one confirmation you should
wait for the propagation time of the network to make sure there is no
branch you missed.
As for the malicious case: the attacker has to win the key-block, have the
to-be-inverted transaction in the previous epoch, and withhold his
key-block for a while. That being said, indeed our fraud proof scheme
doesn't catch such an event, as it is indistinguishable from benign
behavior.
> Also, Greg Slepak brought up a good point on twitter at
> https://twitter.com/taoeffect/status/654358023138209792. Noting that this
> model means users could no longer pick transactions in a mining pool which
> was set up in such a way (it could be tweaked to do so with separate
> rewards and pubkeys, but now the user can commit fraud at a much lower cost
> - their own pool reward, not the block's total reward).
>
Agreed x3: This is a good point, it is correct, and the tweak is dangerous.
Do you perceive this as a significant practical issue?
>
> On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure at gmail.com> wrote:
>>
>>> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > while the whitepaper has all the nitty gritty details:
>>> > http://arxiv.org/abs/1510.02037
>>>
>>> Taking reward compensation back by fraud proofs is not enough to fix
>>> the problems associated with double spending (such as, everyone has to
>>> wait for the "real" confirmations instead of the "possibly
>>> double-spend" confirmations). Some of this was discussed in -wizards
>>> recently:
>>> http://gnusha.org/bitcoin-wizards/2015-09-19.log
>>
>>
>> Fraud proof removes all the attacker's revenue. It's like the attacker
>> sacrifices an entire block for double spending in the current system. I
>> think Luke-Jr got it right at that discussion.
>>
>> Best,
>> Ittay
>>
>> ------------------------------
>>
>> 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/20151015/784e0876/attachment.html>

2023-06-07 17:43:27

- reply

📅 Original date posted:2015-10-14
📝 Original message:On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure at gmail.com> wrote:
> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > while the whitepaper has all the nitty gritty details:
> > http://arxiv.org/abs/1510.02037
>
> Taking reward compensation back by fraud proofs is not enough to fix
> the problems associated with double spending (such as, everyone has to
> wait for the "real" confirmations instead of the "possibly
> double-spend" confirmations). Some of this was discussed in -wizards
> recently:
> http://gnusha.org/bitcoin-wizards/2015-09-19.log
Fraud proof removes all the attacker's revenue. It's like the attacker
sacrifices an entire block for double spending in the current system. I
think Luke-Jr got it right at that discussion.
Best,
Ittay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/0630ba8f/attachment.html>

2023-06-07 15:30:04

- reply

📅 Original date posted:2015-02-12
📝 Original message:A similar idea was proposed by Sirer and me as a part of two-phase proof of
work (2P-PoW) [1]. In 2P-PoW the first phase is Bitcoin's standard PoW and
the second phase requires the signature. This way Bitcoin doesn't lose its
mining power (read: security) in one day, but rather it is possible to
gradually switch from the current PoW to the signature-based one, slowly
phasing out the existing hardware and mining datacenters.
For a more general view of nonoutsourceable puzzles you can check out
Miller et al.'s paper [2].
Ittay
[1]
http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/
[2] https://cs.umd.edu/~amiller/nonoutsourceable.pdf
------------------------------
>
> Message: 2
> Date: Wed, 11 Feb 2015 08:54:15 +0000
> From: Hector Chu <hectorchu at gmail.com>
> Subject: [Bitcoin-development] Proposal: Requiring a miner's signature
> in the block header
> To: bitcoin-development at lists.sourceforge.net
> Message-ID:
> <
> CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> A proposal for stemming the tide of mining centralisation -- Requiring a
> miner's signature in the block header (the whole of which is hashed), and
> paying out coinbase to the miner's public key.
>
> Please comment on whether this idea is feasible, has been thought of
> before,
> etc., etc. Thank you.
>
> Motivation
> ----------
>
> Mining is centralising to a handful of pool operators. This is bad for a
> number of political reasons, which we won't go into right now. But I have
> always believed that some years down the line, they could hold the users
> hostage and change the rules to suit themselves. For instance by
> eliminating
> the halving of the block reward.
>
> Solution
> --------
>
> Currently the block header is formed by the pool operator and distributed
> for
> hashing by the pooled miners. It is possible to divide the work among the
> miners as the only thing that is used to search the hash space is by
> changing
> a nonce or two.
>
> I propose that we require each miner to sign the block header prior to
> hashing. The signature will be included in the data that is hashed.
> Further,
> the coinbase for the block must only pay out to the public key counterpart
> of
> the private key used to sign the block header.
>
> A valid block will therefore have a signature in the block header that is
> verified by the public key being paid by the coinbase transaction.
>
> Ramifications
> -------------
>
> Work can no longer be divided among the pooled miners as before, without
> sharing the pool's private key amongst all of them. If the pool does try to
> take this route, then any of the miners may redeem the coinbase when it
> matures. Therefore, all miners will use their own key pair.
>
> This will make it difficult to form a cooperating pool of miners who may
> not
> trust each other, as the block rewards will be controlled by disparate
> parties
> and not by the pool operator. Only a tight clique of trusted miners would
> be
> able to form their own private pool in such an environment.
>
> Attacks
> -------
>
> Pooled hashpower, instead of earning bitcoins legitimately may try to break
> the system instead. They may try a double-spending attack, but in order to
> leverage the pool to its full potential the pool operator would again have
> to
> share their private key with the whole pool. Due to the increased
> cooperation
> and coordination required for an attack, the probability of a 51% attack is
> much reduced.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Wed, 11 Feb 2015 10:25:27 +0100
> From: Natanael <natanael.l at gmail.com>
> Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's
> signature in the block header
> To: Hector Chu <hectorchu at gmail.com>
> Cc: bitcoin-development at lists.sourceforge.net
> Message-ID:
> <CAAt2M1_qj0r03=
> Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Den 11 feb 2015 09:55 skrev "Hector Chu" <hectorchu at gmail.com>:
> >
> > A proposal for stemming the tide of mining centralisation -- Requiring a
> > miner's signature in the block header (the whole of which is hashed), and
> > paying out coinbase to the miner's public key.
> >
> > Please comment on whether this idea is feasible, has been thought of
> before,
> > etc., etc. Thank you.
> >
> > Motivation
> > ----------
> >
> > Mining is centralising to a handful of pool operators. This is bad for a
> > number of political reasons, which we won't go into right now. But I have
> > always believed that some years down the line, they could hold the users
> > hostage and change the rules to suit themselves. For instance by
> eliminating
> > the halving of the block reward.
>
> [...]
>
> > I propose that we require each miner to sign the block header prior to
> > hashing. The signature will be included in the data that is hashed.
> Further,
> > the coinbase for the block must only pay out to the public key
> counterpart of
> > the private key used to sign the block header.
>
> [...]
>
> > This will make it difficult to form a cooperating pool of miners who may
> not
> > trust each other, as the block rewards will be controlled by disparate
> parties
> > and not by the pool operator. Only a tight clique of trusted miners would
> be
> > able to form their own private pool in such an environment.
>
> People already trust things like cloud mining, so your solution with
> increasing technical trust requirements won't help. But you will however
> break P2Pool instead.
>
> Also, note that threshold signatures (group signatures) could probably be
> used by an actual distrusting pool's miners. There are already a proof of
> concept for this implemented with secp256k1 that works with Bitcoin clients
> silently. This wouldn't prevent such a pool from working.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/518ed3b1/attachment.html>

2023-06-07 15:20:45

- reply

📅 Original date posted:2014-05-05
📝 Original message:As far as I understand, the incentives Sergio suggests would work. So
we can assume that the pruned uncle blocks would still win their creators
at least partial revenue.
As for selfish mining - I'm not sure how GHOST affects it. I don't think it
does. The selfish miners just care about heaviest subtree rather than
longest chain. DECOR changes revenue collection significantly, so it
certainly affects selfish mining. I believe it changes the threshold at
which
selfish mining is profitable, but doesn't deter selfish mining completely:
Selfish miners can still cause others to reduce their revenue by having
them work on older blocks.
Ittay
On Mon, May 5, 2014 at 3:45 PM, Sergio Lerner <sergiolerner at certimix.com>wrote:
>
> On 02/05/2014 10:56 a.m., Joseph Bonneau wrote:
> > This is an interesting idea Sergio. I have two concerns:
> >
> > You mention "50% of the block reward" going to the uncle block. Does
> > this mean the parent gets 1, and the uncle 0.5, or both get 0.5? In
> > the first interpretation (which I assumed was the design), mining is
> > no longer a zero-sum game and this could have lots of unforeseen
> > implications. For example, selfish mining might be more profitable,
> > since you're less disincentivized to avoid conflicts.
> The second interpretation is the correct one.
> > In the second interpretation, there's pressure to have the next miner
> > ignore the uncle to not share the reward. This would encourage
> > kickback-style attacks and advantage large mining pools because they
> > can mine on their own blocks and ignore colliding uncles.
> Including an uncle can be done at any time before a coinbase matures
> (100 blocks) (of course the term "uncle" is misleading in those cases) .
> So, for example, the uncle can be included 50 blocks afterward. So it's
> very difficult that a miner prevents other miners from including the
> uncle and taking the reward given by uncle inclusion.
>
> Same ineffective attack:
> A big miner could try to bribe all other miners not to include the
> uncle, but this would be terribly costly. Suppose that I mine a block
> ignoring an uncle Z and then I publish this message: "Every miner from
> block number X to block number Y that does not include this uncle Z will
> be given Q Bitcoins". How much would Q be? Since by including the uncle
> the miner gets 5 BTC of reward (in the example case where block reward
> is 50 BTC), then each bribery payment would have to be higher than 5
> BTC, totaling 500 BTC ! much more than the 25 BTC the miner will loose
> by including the uncle.
>
> Just by sending a transaction with a lot of fees that depends on my
> block does not prevent subsequent miners from including the supposedly
> banned uncle.
>
> Then, I think there are no kickback-style attacks.
>
> >
> > Also, I think this came up in the Princeton meet-up, but it's not
> > ideal to just hash the blocks to decide the "winner" because this lets
> > you know in advance your block's likelihood of winning a collision by
> > looking at how high or low its hash is, in which case you can publish
> > a weak block right away or withhold a strong one and do selfish
> > mining. A better approach to break ties between blocks A and B is to
> > see if H(A||B) < H(B||A). That way neither block holder can find out
> > in advance if their block is likely to win a collision.
> >
> In the DECOR protocol, I think selfish miners cannot get any advantage,
> because the blocks that loose the latency race will come back as uncles
> and get their reward share anyway. Maybe Ittay Eyal and Emin Gun Sirer
> can say more about this...
>
> Best regards, Sergio.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140505/4662568e/attachment.html>

2023-06-07 15:08:55

- reply

📅 Original date posted:2013-11-05
📝 Original message:On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> I think it's a stretch to say 'y' is 0 with good connectivity. Even the
> best connected mining pools today are concerned with this 'y' factor.
>
Check out the following paper for the effect a single node can have on
propagation, and on the relation between block size and propagation speed.
This strongly supports our assumption.
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
>
> Here's a probably very dumb idea... to throw out one possible "solution"...
>
> You want a way to fake-out the 'selfish miner' into disclosing their
> blocks -- how can your force their hand to prevent them from accumulating
> longer private chains?
>
> What if you propagate (and relay) an encrypted block header which honest
> miners will timestamp when they receive it, then 10 seconds later propagate
> the decryption key to unblind it. But here's the catch - maybe the
> decryption results in junk, maybe it results a new longer block. If it's a
> real block then it gets priority based on when the ciphertext was received
> instead of when the decryption key was received. Now 'selfish miner' can't
> race the network anymore, because they are always in state 0' and can't
> tell if they are up against a ghost, or a real competing block. If they
> wait for the decryption key to check, it's too late, and they are
> guaranteed to lose unless they can out-race the network, e.g. back at
> t=50%. Of course there would need to be some way to anti-DDoS this which
> allows for some amount of these fake-outs without letting them get out of
> hand.
>
That's a dangerous way to go, opening the door to DoS attacks, as you
mention. Besides, it makes a simple algorithm complicated, and doing such
changes may lead to different vulnerabilities that are difficult to cover.
Best,
Ittay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131105/96e0df01/attachment.html>

2023-06-07 15:08:53

- reply

📅 Original date posted:2013-11-05
📝 Original message:That sounds like selfish mining, and the magic number is 25%. That's the
minimal pool size.
Today the threshold is 0% with good connectivity.
If I misunderstood your point, please elaborate.
Ittay
On Tue, Nov 5, 2013 at 12:05 PM, Peter Todd <pete at petertodd.org> wrote:
> On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
> > Hello,
> >
> > Please see below our BIP for raising the selfish mining threshold.
> > Looking forward to your comments.
>
> <snip>
>
> > 2. No new vulnerabilities introduced:
> > Currently the choice among equal-length chains is done arbitrarily,
> > depending on network topology. This arbitrariness is a source of
> > vulnerability. We replace it with explicit randomness, which is at the
> > control of the protocol. The change does not introduce executions that
> were
> > not possible with the old protocol.
>
> Credit goes to Gregory Maxwell for pointing this out, but the random
> choice solution does in fact introduce a vulnerability in that it
> creates incentives for pools over a certain size to withhold blocks
> rather than immediately broadcasting all blocks found.
>
> The problem is that when the pool eventually choses to reveal the block
> they mined, 50% of the hashing power switches, thus splitting the
> network. Like the original attack this can be to their benefit. For
> pools over a certain size this strategy is profitable even without
> investing in a low-latency network; Maxwell or someone else can chime in
> with the details for deriving that threshold.
>
> I won't get a chance to for a few hours, but someone should do the
> analysis on a deterministic switching scheme.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000005e25ca9b9fe62bdd6e8a2b4527ad61753dd2113c268bec707
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131105/b28e776d/attachment.html>

2023-06-07 15:08:50

- reply

📅 Original date posted:2013-11-05
📝 Original message:On Tue, Nov 5, 2013 at 12:14 PM, Peter Todd <pete at petertodd.org> wrote:
> On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
> > On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
>
> Oh, and I don't want to give the wrong impression: there's no need to
> rush to get this problem fixed. Even if someone wanted to launch an
> attack right now, with a fair amount of resources, there's a lot of
> counter-measures based on human intervention that can definitely stop
> the attack in the short-term
The attack can be easily hidden. And be sure that before today, today,
and after today, very smart people are at their computer planning attacks
on Bitcoin. Exploits must be published and fixed FAST.
Nevertheless, I agree that, as you say, we must not rush it. Look at the
BIP, find if we missed anything, and let's discuss it.
> In addition, keep in mind
> that this attack is very easy to detect, so if one is actually launched
> we will know immediately and can start taking direct counter-measures at
> that time.
>
Not really. Please see the discussion section in our paper.
> That Gregory Maxwell so quickly identified a flaw in this proposed
> solution suggests we should proceed carefully.
>
There is no flaw. You were just reiterating that the solution does not give
us the 51% percent security you thought you had before. We showed that
we're not getting this back, I'm afraid.
Best,
Ittay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131105/8c0bd106/attachment.html>

2023-06-07 15:08:49

- reply

📅 Original date posted:2013-11-05
📝 Original message:Hello,
Please see below our BIP for raising the selfish mining threshold.
Looking forward to your comments.
Best,
Ittay
---
Bitcoin Improvement Proposal
Owners: Ittay Eyal and Emin Gun Sirer
We suggest a change in the propagation and mining algorithm for chains of
the same difficulty, to raise the threshold on Selfish Mining attacks.
* Current situation:
When a miner is notified of a new chain of the same difficulty as the one
it is mining on, it will ignore it.
* Background:
The selfish mining attack and its implications were described in detail in
the following research paper:
http://arxiv.org/abs/1311.0243v1
* Proposal:
To thwart selfish mining attacks launched by less than 25% of the mining
power, we propose the following change to the protocol:
When a miner learns of more than one chain of the same difficulty, it
should propagate all of them, and choose one of them to mine on uniformly
at random among all chains of the same difficulty.
When hearing of a chain of maximal difficulty that it did not know of
before:
1. Add it to a local list of maximal difficulty chains.
2. Propagate it to its neighbors.
3. Choose a branch uniformly at random from the local list, and mine on it.
* Example:
t0: learn of chain A of difficulty x.
propagate A to neighbors.
start mining on A.
t1: learn of chain B of difficulty x.
propagate B to neighbors.
toss a coin between A and B; if B wins, switch to mining on B.
t2: learn of chain C of difficulty x.
propagate C to neighbors.
toss a 3 faced coin among A, B, and C; switch to mining on the winning
chain.
* Concerns and answers:
1. No harm to miners when all are honest.
Mining blocks is a random Poisson process, which is memoryless. Having
mined on the block in the past does not provide an advantage in locating a
solution in the future. Therefore, a miner is not harmed by switching the
chain on which it mines.
2. No new vulnerabilities introduced:
Currently the choice among equal-length chains is done arbitrarily,
depending on network topology. This arbitrariness is a source of
vulnerability. We replace it with explicit randomness, which is at the
control of the protocol. The change does not introduce executions that were
not possible with the old protocol.
3. Complete backward compatibility:
Any subset of the miners can switch to the proposed protocol.
4. Progressive improvement:
Each miner that adopts the change raises the threshold a little bit. The
threshold will reach 25% with universal adoption.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131105/6602a128/attachment.html>