Nostr notes by

📅 Original date posted:2017-03-29 📝 Original ...

2023-06-07T17:58:09Z

In reply to nevent1q…jwmz
_________________________

📅 Original date posted:2017-03-29
📝 Original message:>Even when several of the experts involved in the document you refer has my
respect and admiration, I do not agree with some of their conclusions

I'm one of the co-authors of that study. I'd be the first to agree with
your conclusion
and argue that the 4MB size suggested in that paper should not be used
without
compensation for two important changes to the network.

Our recent measurements of the Bitcoin P2P network show that network speeds
have improved tremendously. From February 2016 to February 2017, the average
provisioned bandwidth of a reachable Bitcoin node went up by approximately
70%.
And that's just in the last year.

Further, the emergence of high-speed block relay networks, like Falcon (
http://www.falcon-net.org)
and FIBRE, as well as block compression, e.g. BIP152 and xthin, change the
picture dramatically.

So, the 4MB limit mentioned in our paper should not be used as a protocol
limit today.

Best,
- egs

On Tue, Mar 28, 2017 at 3:36 PM, Juan Garavaglia via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Alphonse,
>
>
>
> Even when several of the experts involved in the document you refer has my
> respect and admiration, I do not agree with some of their conclusions some
> of their estimations are not accurate other changed like Bootstrap Time,
> Cost per Confirmed Transaction they consider a network of 450,000,00 GH and
> today is 3.594.236.966 GH, the energy consumption per GH is old, the cost
> of electricity is wrong even when the document was made and is hard to find
> any parameter used that is valid for an analysis today.
>
>
>
> Again with all respect to the experts involved in that analysis is not
> valid today.
>
>
>
> I tend to believe more in Moore’s law, Butters' Law of Photonics and
> Kryder’s Law all has been verified for many years and support that 32 MB in
> 2020 are possible and equals or less than 1 MB in 2010.
>
>
>
> Again may be is not possible Johnson Lau and LukeJr invested a significant
> amount of time investigating ways to do a safe HF, and may be not possible
> to do a safe HF today but from processing power, bandwidth and storage is
> totally valid and Wang Chung proposal has solid grounds.
>
>
>
> Regards
>
>
>
> Juan
>
>
>
>
>
> *From:* Alphonse Pace [mailto:alp.bitcoin at gmail.com]
> *Sent:* Tuesday, March 28, 2017 2:53 PM
> *To:* Juan Garavaglia <jg at 112bit.com>; Wang Chun <1240902 at gmail.com>
> *Cc:* Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>
> *Subject:* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>
>
>
> Juan,
>
>
>
> I suggest you take a look at this paper: http://fc16.ifca.ai/
> bitcoin/papers/CDE+16.pdf It may help you form opinions based in science
> rather than what appears to be nothing more than a hunch. It shows that
> even 4MB is unsafe. SegWit provides up to this limit.
>
>
>
> 8MB is most definitely not safe today.
>
>
>
> Whether it is unsafe or impossible is the topic, since Wang Chun proposed
> making the block size limit 32MiB.
>
>
>
>
>
> Wang Chun,
>
>
> Can you specify what meeting you are talking about? You seem to have not
> replied on that point. Who were the participants and what was the purpose
> of this meeting?
>
>
>
> -Alphonse
>
>
>
> On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia <jg at 112bit.com> wrote:
>
> Alphonse,
>
>
>
> In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and
> 32MB limit valid in next halving, from network, storage and CPU perspective
> or 1MB was too high in 2010 what is possible or 1MB is to low today.
>
>
>
> If is unsafe or impossible to raise the blocksize is a different topic.
>
>
>
> Regards
>
>
>
> Juan
>
>
>
>
>
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:
> bitcoin-dev-bounces at lists.linuxfoundation.org] *On Behalf Of *Alphonse
> Pace via bitcoin-dev
> *Sent:* Tuesday, March 28, 2017 2:24 PM
> *To:* Wang Chun <1240902 at gmail.com>; Bitcoin Protocol Discussion <
> bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>
>
>
> What meeting are you referring to? Who were the participants?
>
>
>
> Removing the limit but relying on the p2p protocol is not really a true
> 32MiB limit, but a limit of whatever transport methods provide. This can
> lead to differing consensus if alternative layers for relaying are used.
> What you seem to be asking for is an unbound block size (or at least
> determined by whatever miners produce). This has the possibility (and even
> likelihood) of removing many participants from the network, including many
> small miners.
>
>
>
> 32MB in less than 3 years also appears to be far beyond limits of safety
> which are known to exist far sooner, and we cannot expect hardware and
> networking layers to improve by those amounts in that time.
>
>
>
> It also seems like it would be much better to wait until SegWit activates
> in order to truly measure the effects on the network from this increased
> capacity before committing to any additional increases.
>
>
>
> -Alphonse
>
>
>
>
>
>
>
> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I've proposed this hard fork approach last year in Hong Kong Consensus
> but immediately rejected by coredevs at that meeting, after more than
> one year it seems that lots of people haven't heard of it. So I would
> post this here again for comment.
>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>
> Despite spam tx on the network, the block capacity is approaching its
> limit, and we must think ahead. Shall we code a patch right now, to
> remove the block size limit of 1MB, but not activate it until far in
> the future. I would propose to remove the 1MB limit at the next block
> halving in spring 2020, only limit the block size to 32MiB which is
> the maximum size the current p2p protocol allows. This patch must be
> in the immediate next release of Bitcoin Core.
>
> With this patch in core's next release, Bitcoin works just as before,
> no fork will ever occur, until spring 2020. But everyone knows there
> will be a fork scheduled. Third party services, libraries, wallets and
> exchanges will have enough time to prepare for it over the next three
> years.
>
> We don't yet have an agreement on how to increase the block size
> limit. There have been many proposals over the past years, like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> on. These hard fork proposals, with this patch already in Core's
> release, they all become soft fork. We'll have enough time to discuss
> all these proposals and decide which one to go. Take an example, if we
> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
> from 32MiB to 2MB will be a soft fork.
>
> Anyway, we must code something right now, before it becomes too late.
> _______________________________________________
> 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/20170328/5780df70/attachment.html>;

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

2023-06-07T17:47:02Z

In reply to nevent1q…m3nd
_________________________

📅 Original date posted:2015-12-20
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/9b9bc3ea/attachment-0001.html>;

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

2023-06-07T17:47:01Z

In reply to nevent1q…g93m
_________________________

📅 Original date posted:2015-12-20
📝 Original message:There's quite a bit of confusion in this thread.

Peter is referring to block withholding attacks. Ittay Eyal (as sole
author -- I was not involved in this paper [1]) was the first
to analyze these attacks and to discover a fascinating, paradoxical
result. An attacker pool (A) can take a certain portion of its hashpower,
use it to mine on behalf of victim pool (B), furnish partial proofs of work
to B, but discard any full blocks it discovers. If A picks the amount of
attacking hashpower judiciously, it can make more money using this
attack, than it would if it were to use 100% of its hashpower for its own
mining. This last sentence should sound non-sensical to most of you,
at least, it did to me. Ittay did the math, and his paper can tell you
exactly how much of your hashpower you need to peel off and use
to attack another open pool, and you will come out ahead.

Chris Priest is confusing these attacks with selfish mining, and further,
his characterization of selfish mining is incorrect. Selfish Mining is
guaranteed to yield profits for any pool over 33% (as a result, Nick
Szabo has dubbed this the "34% attack") and it may pay off even
below that point if the attacker is well-positioned in the network;
or it may not, depending on the makeup of the rest of the pools
as well as the network characteristics (the more centralized
and bigger the other pools are, the less likely it is to pay off). There
was a lot of noise in the community when the SM paper came out,
so there are tons of incorrect response narrative out there. By now,
everyone who seems to be Bitcoin competent sees SM as a
concern, and Ethereum has already adopted our fix. I'd have hoped
that a poster to this list would be better informed than to repeat the
claim that "majority will protect Bitcoin" to refute a paper whose title
is "majority is not enough."

Back to Ittay's paradoxical discovery:

We have seen pool-block withholding attacks before; I believe Eligius
caught one case. I don't believe that any miners will deploy strong KYC
measures, and even if they did, I don't believe that these measures
will be effective, at least, as long as the attacker is somewhat savvy.
The problem with these attacks are that statistics favor the attackers.
Is someone really discarding the blocks they find, or are they just
unlucky? This is really hard to tell for small miners. Even with KYC,
one could break up one's servers, register them under different
people's names, and tunnel them through VPNs.

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.

Peter, you allude to a specific suggestion from Luke-Jr. Can you
please describe what it is?

Hope this is useful,
- egs

[1] https://www.cs.cornell.edu/~ie53/publications/btcPoolsSP15.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/5a7c575b/attachment-0001.html>;

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

2023-06-07T17:46:57Z

In reply to nevent1q…qenx
_________________________

📅 Original date posted:2015-12-28
📝 Original message:On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Do you specifically mean selfish mining as defined in Emin Gün
> Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant
> issue in a scenario - one malicious miner with >30% hashing power -
> where you're already very close to the margins anyway; the difference
> between a 50% attack threshold and a 30% attack threshold isn't very
> significant.
>

This is not quite right: we know that selfish mining is a guaranteed win
at 34%. We do not know when exactly it begins to pay off. The more
consolidated and centralized the other mining pools, the less of a threat
it is below 34%; the more decentralized, the more likely it is to pay off
at lower thresholds.

Far more concerning is network propagation effects between large and
> small miners.

On a related note, the Bitcoin-NG paper took a big step towards moving
these kinds of concerns out of the realm of gut-feelings and wavy hands
into science. In particular, it introduced metrics for fairness (i.e.
differential
rate in orphans experienced by small and large miners), hash power
efficiency, as well as consensus delay.

> For that class of issues, if you are in an environemnt
> where selfish mining is possible - a fairly flat, easily DoS/sybil
> attacked network topology - the profitability difference between small
> and large miners even *without* attacks going on is a hugely worrying
> problem.

Indeed, there is a slight, quantifiable benefit to larger pools. Which is
why
we need to be diligent about not letting pools get too big.

> Note though that Eligius is *not* the only pool to have had problems
>
with block withholding, though AFAIK Eligius is the only one who has
> gone on record so far. (as I said in my original post, I'm relaying
> information given to me under condition of confidentiality)
>

I can see why they don't want to go public with this: it means that they
are less profitable than other pools.

It still looks to me like Ittay's discovery is doing exactly the right
thing:
this pool will need to be more careful when signing up new people,
curbing its otherwise steady march towards the 51% boundary.

- egs

- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151228/2e490a2b/attachment.html>;

📅 Original date posted:2015-12-02 📝 Original message:Thanks ...

2023-06-07T17:45:23Z

In reply to nevent1q…nntf
_________________________

📅 Original date posted:2015-12-02
📝 Original message:Thanks Peter for the careful, quantitative work.

I want to bring one additional issue to everyone's consideration, related
to the choice of the Lempel-Ziv family of compressors.

While I'm not familiar with every single compression engine tested, the
Lempel-Ziv family of compressors are generally based on "compression
tables." Essentially, they assign a short unique number to every new
subsequence they encounter, and when they re-encounter a sequence like "ab"
in "abcdfdcdabcdfabcdf" they replace it with that short integer (say, in
this case, 9-bit constant 256). So this example sequence may turn into
"abcdfd<258 for cd><256 for ab><258 for cd>f<261 for abc><259 for df>"
which is slightly shorter than the original (I'm doing this off the top of
my head so the counts may be off, but it's meant to be illustrative). Note
that the sequence "abc" got added into the table only after it was
encountered twice in the input.

This is nice and generic and works well for English text where certain
letter sequences (e.g. "it" "th" "the" "this" "are" "there" etc) are
repeated often, but it is nowhere as compact as it could possibly be for
mostly binary data -- there are opportunities for much better compression,
made possible by the structured reuse of certain byte sequences in the
Bitcoin wire protocol.

On a Bitcoin wire connection, we might see several related transactions
reorganizing cash in a set of addresses, and therefore, several reuses of a
20-byte address. Or we might see a 200-byte transaction get transmitted,
followed by the same transaction, repeated in a block. Ideally, we'd learn
the sequence that may be repeated later on, all at once (e.g. a Bitcoin
address or a transaction), and replace it with a short number, referring
back to the long sequence. In the example above, if we knew that "abcdf"
was a UNIT that would likely be repeated, we would put it into the
compression table as a whole, instead of relying on repetition to get it
into the table one extra byte at a time. That may let us compress the
original sequence down to "abcdfd<257 for cd><256 for abcdf><256 for
abcdf>" from the get go.

Yet the LZ variants I know of will need to see a 200-byte sequence repeated
**199 times** in order to develop a single, reusable, 200-byte long
subsequence in the compression table.

So, a Bitcoin-specific compressor can perhaps do significantly better, but
is it a good idea? Let's argue both sides.

Cons:

On the one hand, Bitcoin-specific compressors will be closely tied to the
contents of messages, which might make it difficult to change the wire
format later on -- changes to the wire format may need corresponding
changes to the compressor. If the compressor cannot be implemented
cleanly, then the protocol-agnostic, off-the-shelf compressors have a
maintainability edge, which comes at the expense of the compression ratio.

Another argument is that compression algorithms of any kind should be
tested thoroughly before inclusion, and brand new code may lack the
maturity required. While this argument has some merit, all outputs are
verified separately later on during processing, so
compression/decompression errors can potentially be detected. If the
compressor/decompressor can be structured in a way that isolates bitcoind
from failure (e.g. as a separate process for starters), this concern can be
remedied.

Pros:

The nature of LZ compressors leads me to believe that much higher
compression ratios are possible by building a custom, Bitcoin-aware
compressor. If I had to guess, I would venture that compression ratios of
2X or more are possible in some cases. In some sense, the "O(1) block
propagation" idea that Gavin proposed a while ago can be seen as extreme
example of a Bitcoin-specific compressor, albeit one that constrains the
order of transactions in a block.

Compression can buy us some additional throughput at zero cost, modulo code
complexity.
Given the amount of acrimonious debate over the block size we have all had
to endure, it seems
criminal to leave potentially free improvements on the table. Even if the
resulting code is
deemed too complex to include in the production client right now, it would
be good to understand
the potential for improvement.

How to Do It

If we want to compress Bitcoin, a programming challenge/contest would be
one of the best ways to find the best possible, Bitcoin-specific
compressor. This is the kind of self-contained exercise that bright young
hackers love to tackle. It'd bring in new programmers into the ecosystem,
and many of us would love to discover the limits of compressibility for
Bitcoin bits on a wire. And the results would be interesting even if the
final compression engine is not enabled by default, or not even merged.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151202/32591f84/attachment.html>;

📅 Original date posted:2015-10-14 📝 Original message:>So ...

2023-06-07T17:43:30Z

In reply to nevent1q…24s7
_________________________

📅 Original date posted:2015-10-14
📝 Original message:>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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/4aef9442/attachment.html>;

📅 Original date posted:2015-10-14 📝 Original message:Hi ...

2023-06-07T17:43:27Z

In reply to nevent1q…rjed
_________________________

📅 Original date posted:2015-10-14
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/e2ca2035/attachment.html>;

📅 Original date posted:2014-07-19 📝 Original message:> ...

2023-06-07T15:24:10Z

In reply to nevent1q…0a0a
_________________________

📅 Original date posted:2014-07-19
📝 Original message:> Most things I've seen working in this space are attempting to minimize
> the data transfered. At least for the miner-interested case the round
> complexity is much more important because a single RTT is enough to
> basically send the whole block on a lot of very relevant paths.

Agreed. Yaron's scheme is magical because it is non-interactive. I send you
a packet of O(expected-delta) and you immediately figure out the delta
without further back and forth communication, each requiring an RTT.

> I know much better is possible (see up-thread where I linked to an old
> proposal to use forward error correction to transfer with low data
> transfer (but not optimal) and negligible probability of needing a
> round-trip, with a tradeoff for more overhead for lower roundtrip
> probability).

FEC schemes are both fairly complex, because the set is constantly
changing, and (if i understand your suggestion correctly) they add
additional metadata overhead (albeit mostly during tx propagation). Set
reconciliation is near optimal.

In any case, I have no horse here (I think changing the client so it's
multithreaded is the best way to go), but Yaron's work is pretty cool and
may be applicable.

- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140718/d7cb8d29/attachment.html>;

📅 Original date posted:2014-07-18 📝 Original message:I ...

2023-06-07T15:24:09Z

In reply to nevent1q…whmy
_________________________

📅 Original date posted:2014-07-18
📝 Original message:I thought I'd chime in and point out some research results that might help.
Even if they don't, there is a cool underlying technique that some of you
might find interesting.

The problem being tackled here is very similar to "set reconciliation,"
where
peer A thinks that the set of transactions that should be in the block is
S_A,
and peer B has actually included set S_B, and S_A and S_B are expected
to not differ much. Ideally, one would like the communication complexity
between A and B to be O(delta), not O(S_B) as it is right now. And ideally,
one would like B to send a single message to A, and for A to figure out the
difference between the two sets, without any lengthy back and forth
communication. In essence, I would like to give you some magical packet
that is pretty small and communicates just the delta between what you and
I know.

This paper from Cornell describes a scheme for achieving this:
Yaron Minsky, Ari Trachtenberg, Richard Zippel: Set reconciliation with
nearly optimal communication complexity. IEEE Transactions on Information
Theory 49(9): 2213-2218 (2003)
http://ipsit.bu.edu/documents/ieee-it3-web.pdf

Those of you looking for a TL;DR should read the intro and then skip to
page 8 for the example. The underlying trick is very cool, comes from the
peer-to-peer/gossip literature, and it is underused. It'd be really cool if
it
could be applied to this problem to reduce the size of the packets.

This approach has three benefits over the Bloom filter approach (if I
understand the Bloom filter idea correctly):

(1) Bloom filters require packets that are still O(S_A),

(2) Bloom filters are probabilistic, so require extra complications
when there is a hash collision. In the worst case, A might get confused
about which transaction B actually included, which would lead to a
fork. (I am not sure if I followed the Bloom filter idea fully -- this may
not happen with the proposal, but it's a possibility with a naive Bloom
filter implementation)

(3) Bloom filters are interactive, so when A detects that B has included
some transactions that A does not know about, it has to send a message
to figure out what those transactions are.

Set reconciliation is O(delta), non-probabilistic, and non-interactive. The
naive version requires that one have some idea of the size of the delta,
but I think the paper has some discussion of how to handle the delta
estimate.

I have not gone through the full exercise of actually applying this trick to
the Bitcoin p2p protocol yet, but wanted to draw your attention to it.
If someone is interested in applying this stuff to Bitcoin, I'd be happy
to communicate further off list.

- egs

On Fri, Jul 18, 2014 at 12:55 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:

> Related: We must handle some legitimate miner-privately-mined cases,
> such as miner payout TXs (outside coinbase) or side chain conditional
> TXs[1].
>
> [1] https://bitcointalk.org/index.php?topic=676703.msg7682680#msg7682680
>
> On Fri, Jul 18, 2014 at 3:51 PM, Kaz Wesley <keziahw at gmail.com> wrote:
> > I've updated the gist, and added an additional proposal that I think
> > meshes well:
> >
> https://gist.github.com/kazcw/43c97d3924326beca87d#ultra-fast-block-validation
> >
> > sparseblocks + UFBV would tighten the new-block process to this (when
> > txes have been received in advance):
> > - receive block (~2kB for 1000 tx)
> > - check whether block contains txes known to belong to conflict-sets,
> > and if so whether more than one tx from a single conflict-set has been
> > included (a few operations on very small sets)
> > - relay block (~2kB)
> >
> > The benefits of these changes only occur when the transactions have
> > been seen in advance, but incentivizing ahead-of-block transaction
> > propogation is a plus, as Jeff mentioned; working on a block without
> > first ensuring peers have its transactions would be very expensive
> > from a miner's point of view.
> >
> >
> ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise? Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> 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/20140718/2142ffc0/attachment.html>;