<unnamed>

Public Key

npub1n8ytpf4jzavm7hl9t5zksuefcguu6k3frvztqqc4kgcdkwduqesq0637cg

Profile Code

nprofile1qqsfnj9s56epwkdltlj46ptgwv5uywwdtg53kp9sqv2myvxm8x7qvcqpzpmhxue69uhkummnw3ezuamfdejsd9rehu

Publishing to

nostr.wine

Last Notes

2023-06-07 17:47:03 UTC

- 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:43:32 UTC

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

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

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

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