<unnamed>

Public Key

npub1n8ytpf4jzavm7hl9t5zksuefcguu6k3frvztqqc4kgcdkwduqesq0637cg

Profile Code

nprofile1qqsfnj9s56epwkdltlj46ptgwv5uywwdtg53kp9sqv2myvxm8x7qvcqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsq0vkhu

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:43:29 CEST

- 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 19:43:28 CEST

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