Emin Gün Sirer [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-07-19 to 2017-03-29
💬 Posted a total of 23 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, BIP Draft
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1k6906yrdzekdkn23mrskcf6up8s2fypqldhnz9gfc44kwsan02zq5xvja6

Profile Code

nprofile1qqstdzhazpk3vmxmf4ga3ctvyawqnc9yjqs0kme3z5yu26m8gweh4pqqpskrr

Author Public Key

npub1k6906yrdzekdkn23mrskcf6up8s2fypqldhnz9gfc44kwsan02zq5xvja6

Show more details

Last Notes

2023-06-07 17:58:09

- reply

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

2023-06-07 17:57:44

- reply

📅 Original date posted:2017-03-24
📝 Original message:Because there's no consensus on the contents of the mempool, this approach
is unsafe and will lead to forks. It also opens a new attack vector where
people can time the flood of new transactions with the discovery of a block
by a competitor, to orphan the block and to fork the chain.
The technical defense against an attacking majority of miners is to change
the PoW, effectively moving the community off into a new altcoin where the
attackers, hopefully, don't have majority hash power.
- egs
Sent from my phone, please compensate for autocorrect errors.
On Mar 24, 2017 9:06 AM, "CANNON via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> blocks, the worst case scenario is a hardfork coin split in which
> the non-compliant chain becomes an alt. However the problem is that
> this malicious miner is very recently threatening to not just simply
> fork, but to kill the valid chain to force economic activity to the
> adversary controlled chain. If we can simply defend against attacks
> to the valid chain, we can prevent the valid chain from dying.
>
> While empty or near empty blocks would generally be protected by
> the incentive of miners to make money. The threat is there if the
> malicious miner with majority control is willing to lose out on
> these transaction fees and block reward if their intention is to
> suppress it to force the majority onto their chain.
>
> Proposal for potential solution Update nodes to ignore empty blocks,
> so this way mined empty blocks cannot be used to DOS attack the
> blockchain. But what about defense from say, blocks that are
> not empty but intentionally only have a couple transactions
> in it? Possible to have nodes not only ignore empty blocks,
> but also blocks that are abnormally small compared to number of
> valid transactions in mempool?
>
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example.
>
> What would be any potentials risks
> and attacks resulting from both having such new rulesets and not
> doing anything?
>
> Lets assume that the first problem of blocking empty or near empty
> blocks has been mitigated with the above proposed solution. How
> likely and possible would it be for a malicious miner with lots of
> mining power to orphan the chain after so many blocks even with
> non empty blocks? Is there a need to mitigate this?
> If so is it possible?
>
> Time is running short I fear. There needs to be discussion on various
> attacks and how they can be guarded against along with various
> other contingency plans.
>
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon at cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
> D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
> V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
> WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
> TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
> S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
> z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
> LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
> 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
> DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
> jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
> Gu3oWoE1ld+BC6At28AD
> =SSuj
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20170324/65f32451/attachment-0001.html>

2023-06-07 17:49:28

- reply

📅 Original date posted:2016-03-02
📝 Original message:> The entire point of the definition of eventually consistency is that your
> computer system is running continously and DO NOT have a final state, and
> therefore you must be able to describe the behavior when your system either
> may give responses to queries across time that are either perfectly
> consistent *or not* perfectly consistent.
>
This is not the definition of eventual consistency. From
https://en.wikipedia.org/wiki/Eventual_consistency:
Eventual consistency is a consistency model used in distributed computing
to achieve high availability that informally guarantees that, if no new
updates are made to a given data item, eventually all accesses to that item
will return the last updated value.
The actual definition makes it quite clear that a system need not have a
final state to be evaluated for its consistency properties. Almost all
practical database systems execute continuously without a final state.
> And Bitcoin by default *does not* ignore the contents of the last X
> blocks. A Bitcoin node being queried about the current blockchain state
> WILL give inconsistent answers when there's block rearrangements = no
> strong consistency.
One could split hairs here by pedantically defining "Bitcoin by default" --
you could refer to just the reference client code and ignore the shim code
in the app that interfaces with the client -- but that'd drag us into a
fruitless email-list-style discussion from which no one would emerge any
wiser. I'll avoid that, and will instead dryly note that the reference
client's listreceivedbyaddress will return the number of confirmations by
default, and every application will then check the confirmations value to
confirm that it exceeds that application's own omega, while
getbalance,getreceivedbyaddress will take a number of confirmations as an
argument, shielding the app from reorgs of the suffix. That is precisely
the point made in the post.
> Not to mention that your definition ignores the nonzero probability of a
> block rearrangement extending beyond your constant omega.
>
The post covers this case. Technically, there is a difference between 0
probability and epsilon probability -- this is the reason why Nakamoto
Consensus was an exciting breakthrough result; the same reason why
Lamport's results regarding a 3f+1 bound on the Byzantine Generals Problem
do not apply to Nakamoto Consensus; and the same reason it took our paper
(Majority is Not Enough) to show that Nakamoto consensus has a similar 33%
bound as Lamport-style consensus when it comes to tolerating Byzantine
actors.
Practically, however, there is little difference between 0 and a value that
exponentially approximates 0, given that we operate on hardware subject to
random errors. The post makes the case that one can pick an omega such that
the probability of your processor mis-executing your code is larger than
the probability of observing a reorganization.
Bitcoin provides a probabilistic, accumulative probability. Not a perfect
> one.
>
Sometimes, non-technical people get confused about the difference between
very very very small probabilities that approximate 0 and 0. For instance,
some people get very worried about hash collisions, on which Bitcoin relies
for its correctness, whose probability also drops exponentially but is not
exactly 0. Your overall point seems to be an analogous concern that
Bitcoin's exponentially dropping probability of reorganization isn't quite
a "perfect" 0. If so, I agree and the original post made this quite clear.
Though I hope we can avoid that kind of discussion on this particular list.
- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160302/30a4a945/attachment-0001.html>

2023-06-07 17:49:27

- reply

📅 Original date posted:2016-03-01
📝 Original message:There seems to be a perception out there that Bitcoin is eventually
consistent. I wrote this post to describe why this perception is completely
false.
Bitcoin Guarantees Strong, not Eventual, Consistency
http://hackingdistributed.com/2016/03/01/bitcoin-guarantees-strong-not-eventual-consistency/
I hope we can lay this bad meme to rest. Bitcoin provides a strong
guarantee.
- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160301/939e3925/attachment.html>

2023-06-07 17:49:20

- reply

📅 Original date posted:2016-02-26
📝 Original message:At the 3rd Bitcoin Workshop being held in conjunction with the Financial
Cryptography Conference in Barbados, my group will be presenting a new idea
for improving Bitcoin wallet security and deterring thefts today.
The write-up is here:
http://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults/
The paper with the nitty gritty details is here:
http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
The core idea:
Our paper describes a way to create vaults, special accounts whose keys can
be neutralized if they fall into the hands of attackers. Vaults are
Bitcoin’s decentralized version of you calling your bank to report a stolen
credit card -- it renders the attacker’s transactions null and void. And
here’s the interesting part: in so doing, vaults demotivate key theft in
the first place. An attacker who knows that he will not be able to get away
with theft is less likely to attack in the first place, compared to current
Bitcoin attackers who are guaranteed that their hacking efforts will be
handsomely rewarded.
Operationally, the idea is simple. You send your money to a vault address
that you yourself create. Every vault address has a vault key and a
recovery key. When spending money from the vault address with the
corresponding vault key, you must wait for a predefined amount of time
(called the unvaulting period) that you established at the time you created
the vault -- say, 24 hours. When all goes well, your vault funds are
unlocked after the unvaulting period and you can move them to a standard
address and subsequently spend them in the usual way. Now, in case Harry
the Hacker gets a hold of your vault key, you have 24 hours to revert any
transaction issued by Harry, using the recovery key. His theft,
essentially, gets undone, and the funds are diverted unilaterally to their
rightful owner. It’s like an “undo” facility that the modern banking world
relies on, but for Bitcoin.
The technical trick relies on a single new opcode, CheckOutputVerify, that
checks the shape of a redeem transaction. Note that fungibility is not
affected, as the restrictions are at the discretion of the coin owner alone
and can only be placed by the coin owner ahead of time.
We suspect that this modest change could actually be a game-changer for
bitcoin security: clients and keys are notoriously hard to secure, and a
facility that allows you to possibly recover, and if not, permanently keep
the hacker from acquiring your funds, could greatly deter Bitcoin thefts.
As always, comments and suggestions are welcome.
- egs, Ittay Eyal and Malte Moeser.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160226/391038e4/attachment.html>

2023-06-07 17:47:29

- reply

📅 Original date posted:2015-12-30
📝 Original message:On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd <pete at petertodd.org> wrote:
> Note how transaction malleability can quickly sabotage naive notions of
> this idea.
>
Bitcoin-United relies on a notion of transaction equivalence that doesn't
involve the transaction hash at all, so it should be immune to malleability
issues and compatible with segwit.
>From the post, two transactions are equal if they "consume the same inputs
and result in the same outputs, not counting the miner fee. Simple
pay-to-pubkey-hash and pay-to-script-hash transactions are straightforward.
Multikey transactions are evaluated for equivalency by their inputs and
outputs, so it is allowable for a 2-out-of-3 payment to be signed by one
set of two keys on Dum and another set of two keys on Dee, as long as the
transaction consumes the same coins and produces the same outputs. Not that
we'll ever encounter such a case, but making this point helps pedagogically
with getting across the notion of transaction equivalence. What counts are
the consumed inputs and the destination and amounts of the outputs."
But you're right, if a naive implementation were to just use the
transaction hash, the result would be a mess.
- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/1672f2d0/attachment.html>

2023-06-07 17:47:28

- reply

📅 Original date posted:2015-12-30
📝 Original message:Ittay Eyal and I just put together a writeup that we're informally calling
Bitcoin-United for preserving the value of coins following a permanent fork:
http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/
Half of the core idea is to eliminate double-spends (where someone spends a
UTXO on chain A and the same UTXO on chain B, at separate merchants) by
placing transactions from A on chain B, and by taking the intersection of
transactions on chain A and chain B when considering whether a payment has
been received.
The other half of the core idea is to enable minting of new coins and
collection of mining fees on both chains, while preserving the 21M maximum.
This is achieved by creating a one-to-one correspondence between coins on
one chain with coins on the other.
Given the level of the audience here, I'm keeping the description quite
terse. Much more detail and discussion is at the link above, as well as the
assumptions that need to hold for Bitcoin-United.
The high bit is that, with a few modest assumptions, it is possible to
create a cohesive coin in the aftermath of a fork, even if the core devs
are split, and even if one of the forks is (in the worst case) completely
non-cooperative. Bitcoin-United is a trick to create a cohesive coin even
when there is no consensus at the lowest level.
Bitcoin-United opens up a lot of new, mostly game-theoretic questions: what
happens to native clients who prefer A or B? What will happen to the value
of native-A or native-B coins? And so on.
We're actively working on these questions and more, but we wanted to share
the Bitcoin-United idea, mainly to receive feedback, and partly to provide
some hope about future consensus to the community. It turns out that it is
possible to craft consensus at the network level even when there isn't one
at the developer level.
Happy New Year, and may 2016 be united,
- egs & ittay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/4b322fe8/attachment.html>

2023-06-07 17:47:10

- reply

📅 Original date posted:2015-12-27
📝 Original message:>Another option for how to deal with block withholding attacks: Give the
miner who finds the block a bonus.
...
>This must have been proposed before, right? Anyone know of a good analysis
of the game theory math?
Yes, Section 8.D. in Ittay's paper discusses this countermeasure, as well
as a few others:
https://www.cs.cornell.edu/~ie53/publications/btcPoolsSP15.pdf
- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/02893426/attachment.html>

2023-06-07 17:47:10

- reply

📅 Original date posted:2015-12-20
📝 Original message:Initial reactions aren't always accurate, people's views change, and
science has its insurmountable way of convincing people. Gavin [1]
and others [2] now cite selfish mining as a concern in the block size
debate, and more importantly, the paper has been peer-reviewed,
cited, and even built-upon [3].
Let's elevate the discussion, shall we?
[1] Here's Gavin concerned about selfish mining:
http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
[2] Here's Adam:
http://bitcoin-development.narkive.com/mvI8Wpjp/dynamic-limit-to-the-block-size-bip-draft-discussion
[3] This is a very nice extension of our work:
Ayelet Sapirshtein, Yonatan Sompolinsky, Aviv Zohar:
http://arxiv.org/abs/1507.06183
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/35641b59/attachment-0001.html>

2023-06-07 17:47:02

- reply

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

2023-06-07 17:47:01

- reply

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

2023-06-07 17:46:57

- reply

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

2023-06-07 17:46:06

- reply

📅 Original date posted:2015-12-12
📝 Original message:.,
,
/.
, /,
,.
/ ,
..
,,, . // ., .
_. ... .. ._.
, _
,
,
,
, , ... _ _.
,.
. ,., _.
., , ..
,
,,
._
. .
_
.
,
, , , /..,,
/ ,
. .
_
.,. _.. ,
,
.. _
..
,.,, _
, _
,
///
. ,
/ . ,.
,
,.,
. ,
, ., ,. ._ , ,,,//
, ,
.
,
,
. . ,
, // .
, ,
/
_,.
, . ,, .
..
/,/ .
.
. .,,_//
,,
., .
. /_. ,
/
.
/
.._
.
,, / .
. _ ,
, ,
/ , _ .,
, ,,, .. ,
,
/.,.
/. /
. ,/ ,
. . /,
/,
._
,/.
_
.,
,//
, .,,, , , , ,
,
,. ,.,. .
, . ,. ., ,
/ _
.
/
,.,. ,
,._
,,
, _ _ ,
,
. ,, , _
_..,
,
// ,
__ /
!;"$'''. b
__
On Sat, Dec 12, 2015, 3:01 PM Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback <luke.durback at gmail.com>
> wrote:
> >>If it's voting for something consensus, you will need something special.
> If
> >> it's not consensus (ie external) thw voting doesn't have to hit the
> chain at
> >> all.
> >
> > I had in mind voting for something that can't be trusted if done
> externally:
> > Perhaps BIPs for instance. People would somehow "mark" their BTC as
> being
> > "For Proposition X" (as opposed to all other propositions) and the vote
> > would be canceled as soon as the BTC is spent again.
> >
> > Unfortunately, I've spent the past 2 days trying to find a design that
> would
> > allow this (I don't think my original suggestion made sense in the
> context
> > of how transactions work), and I haven't gotten much yet.
>
> Well, as said, if it's for consensus, you will need to adapt the
> system in a special way anyway, but I still don't see why turing
> completeness is required.
> This type of idea is not new. Since miners can censor votes (and
> that's undetectable for consensus), several solutions have been
> proposed, time lock the votes, for example.
>
> >>But each scriptSig is only executed once with its corresponding
> >> scriptPubKey. Are you proposing we change that?
> >
> > Sorry, I didn't understand Bitcoin's transaction model well enough when I
> > first made the proposal. If Turing Pseudo-Completeness is possible with
> > Bitcoin, then I understand now that it could not require you to execute a
> > script more than once. My current thought is that recursion can be
> > accomplished via checking if the next output's scriptPubKey is identical
> in
> > every way to the current scriptPubKey. Unfortunately, a lot more is
> needed
> > than just recursion in order to do on-chain BTC voting the way I have in
> > mind. I'll keep working on this.
>
> What you call "recursion" seems similar to what we usually call
> "covenants", see
>
> https://bitcointalk.org/index.php?topic=278122.0
>
> Although the thread says "an amusingly bad idea", I think it's
> actually a great idea and there's some use cases that are very hard to
> support without covenants.
> Again, no Turing completeness required for this.
>
> > On Fri, Dec 11, 2015 at 10:36 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> >>
> >>
> >> On Dec 10, 2015 7:36 AM, "Luke Durback" <luke.durback at gmail.com> wrote:
> >> >
> >> > Tomorrow, I'll work on writing a way to do voting on proposals with
> BTC
> >> > used as voting shares (This will be difficult as I do not know
> FORTH). That
> >> > seems like a fairly simple, useful example that will require loops and
> >> > reused functions. I'll add a fee that goes to the creator.
> >>
> >> If it's voting for something consensus, you will need something special.
> >> If it's not consensus (ie external) thw voting doesn't have to hit the
> chain
> >> at all.
> >> I don't see how "loops and reused functions" are needed in the scripting
> >> language for this use case, but I'm probably missing some details.
> Please,
> >> the more concrete you make your example, the easiest it will be for me
> to
> >> understand.
> >>
> >> > IMO, if you write a complicated system of scripts that's used
> >> > frequently, it makes sense to charge a fee for its usage.
> >>
> >> But each scriptSig is only executed once with its corresponding
> >> scriptPubKey. Are you proposing we change that?
> >>
> >> > A decentralized exchange between colored coins, for instance might
> take
> >> > a small fee on each trade.
> >>
> >> I've been researching the topic of decentralized exchange from before
> the
> >> term "colored coins" was first used (now there's multiple designs and
> >> implementations); contributed to and reviewed many designs: none of them
> >> (colored coins or not) required turing completeness.
> >> I'm sorry, but what you are saying here is too vague for me to
> concretely
> >> be able to refute the low level "needs" you claim your use cases to
> have.
> >>
> >> > On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev"
> >> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> > > This, combined with the ability to make new transactions arbitrarily
> >> > > would allow a function to pay its creator.
> >> >
> >> > I don't understand what you mean by "a function" in this context, I
> >> > assume you mean a scriptSig, but then "paying its creator" doesn't
> make much
> >> > sense to me .
> >> >
> >> > Could you provide some high level examples of the use cases you would
> >> > like to support with this?
> >
> >
> _______________________________________________
> 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/20151212/a45f8dbe/attachment-0001.html>

2023-06-07 17:45:23

- reply

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

2023-06-07 17:44:46

- reply

📅 Original date posted:2015-11-13
📝 Original message:By now, we have seen quite a few proposals for the block size increase.
It's hard not to notice that there are potentially infinitely many
functions for future block size increases. One could, for instance, double
every N years for any rational number N, one could increase linearly, one
could double initially then increase linearly, one could ask the miners to
vote on the size, one could couple the block size increase to halvings,
etc. Without judging any of these proposals on the table, one can see that
there are countless alternative functions one could imagine creating.
I'd like to ask a question that is one notch higher: Can we enunciate what
grand goals a truly perfect function would achieve? That is, if we could
look into the future and know all the improvements to come in network
access technologies, see the expansion of the Bitcoin network across the
globe, and precisely know the placement and provisioning of all future
nodes, what metrics would we care about as we craft a function to fit what
is to come?
To be clear, I'd like to avoid discussing any specific block size increase
function. That's very much the tangible (non-meta) block size debate, and
everyone has their opinion and best good-faith attempt at what that
function should look like. I've purposefully stayed out of that issue,
because there are too many options and no metrics for evaluating proposals.
Instead, I'm asking to see if there is some agreement on how to evaluate a
good proposal. So, the meta-question: if we were looking at the best
possible function, how would we know? If we have N BIPs to choose from,
what criteria do we look for?
To illustrate, a possible meta goal might be: "increase the block size,
while ensuring that large miners never have an advantage over small miners
that [they did not have in the preceding 6 months, in 2012, pick your time
frame, or else specify the advantage in an absolute fashion]." Or "increase
block size as much as possible, subject to the constraint that 90% of the
nodes on the network are no more than 1 minute behind one of the tails of
the blockchain 99% of the time." Or "do not increase the blocksize until at
least date X." Or "the increase function should be monotonic." And it's
quite OK (and probably likely) to have a combination of these kinds of
metrics and constraints.
For disclosure, I personally do not have a horse in the block size debate,
besides wanting to see Bitcoin evolve and get more widely adopted. I ask
because as an academic, I'd like to understand if we can use various
simulation and analytic techniques to examine the proposals. A second
reason is that it is very easy to have a proliferation of block size
increase proposals, and good engineering would ask that we define the
meta-criteria first and then pick. To do that, we need some criteria for
judging proposals other than gut feeling.
Of course, even with meta-criteria in hand, there will be room for lots of
disagreement because we do not actually know the future and reasonable
people can disagree on how things will evolve. I think this is good because
it makes it easier to agree on meta-criteria than on an actual, specific
function for increasing the block size.
It looks like some specific meta-level criteria would help more at this
point than new proposals all exploring a different variants of block size
increase schedules.
Best,
- egs
P.S. This message is an off-shoot of this blog post:
http://hackingdistributed.com/2015/11/13/suggestion-for-the-blocksize-debate/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/7a88aa6c/attachment.html>

2023-06-07 17:44:19

- reply

📅 Original date posted:2015-11-09
📝 Original message:Hi everyone,
Thanks to everyone for a very friendly and scientifically-oriented
discussion. We have collated all the issues that have been raised related
to NG, and placed them in context, here:
http://hackingdistributed.com/2015/11/09/bitcoin-ng-followup/
Overall, NG has a unique insight: turning the block creation process upside
down can provide many benefits. Most notably, throughput can go as high as
the network will allow, providing scalability benefits that increase as the
network improves. There are many other side benefits, including fast
confirmations that are stronger than 0-conf in Core, and come much more
quickly than Core's 1-confirmations. And there are ancillary benefits as
well, such as resilience to fluctuations in mining power, and healthier
incentives for participants to ferry transactions. We believe that a fresh
new permission-less blockchain protocol, designed today, would end up
looking more like NG than Core. Of course, if NG could possibly be layered
on top of Bitcoin, that would be the ultimate combination.
Many thanks for an interesting discussion, and as always, we're happy to
hear constructive suggestions and feedback,
- egs
On Wed, Oct 14, 2015 at 2:02 PM, Emin Gün Sirer <el33th4x0r at gmail.com>
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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151109/df19652c/attachment.html>

2023-06-07 17:43:30

- reply

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

2023-06-07 17:43:27

- reply

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

2023-06-07 15:35:30

- reply

📅 Original date posted:2015-05-20
📝 Original message:Hi everyone,
Given the recent discussions on projects that use the Bitcoin blockchain to
record factoids, people on this list might be interested in the Virtual
Notary project. Virtual Notary is essentially an online witness (aka
attestor) to online factoids. It can provide:
* proof of Bitcoin funds (without revealing public addresses or fund
location on the blockchain)
* proof of Bitcoin address ownership
* proof of Tweet
* proof of real estate value
* proof of DNS ownership
* proof of existence
* proof of web page contents
* proof of weather conditions
The factoids can be recorded on the blockchain (if you pay for the
transaction with Bitcoin or PayPal), or they can be part of a free
attestation chain that we maintain. The website provides a permanent URL to
the factoids it generates; it also provides an X.509 certificate that you
can download and keep safe in perpetuity, independent of the website.
The link to the website is here:
http://virtual-notary.org
The link to the writeup describing the various factoids and their use cases
is here:
http://hackingdistributed.com/2013/06/20/virtual-notary-intro/
We are actively looking for people who are interested in developing the
service further. Specifically, if you have suggestions for how to extend
the service, for new proof/factoid types, or for how to build a business
case around the core idea, please let us know.
Best,
- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150520/995e8043/attachment.html>

2023-06-07 15:24:10

- reply

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

2023-06-07 15:24:09

- reply

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

2023-06-07 15:24:05

- reply

📅 Original date posted:2014-07-18
📝 Original message:My apologies for posting to the wrong thread.
On Fri, Jul 18, 2014 at 5:51 PM, Emin Gün Sirer <el33th4x0r at gmail.com>
wrote:
> 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 6:44 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
>> Yes. That, and several other things. If you can figure out how to
>> propagate a block without re-propagating all the transactions everyone
>> already has, you address the large-blocks-slower-to-relay problem, and
>> additionally create an incentive for miners to mine blocks consisting
>> of publicly broadcast transactions (versus a bunch of secret ones
>> mined with secret agreements).
>>
>> Democratizing transaction selection takes a bit of power away from the
>> miners and gives it back to the network at large. GBT is another
>> piece of that puzzle.
>>
>>
>> On Fri, Jul 18, 2014 at 6:43 AM, Mike Hearn <mike at plan99.net> wrote:
>> > Oops, sorry, I see the subject line changed. This is what I get for
>> working
>> > down the thread list top to bottom :)
>> >
>> > I think the best path forward now is to finish off getblocktemplate
>> support
>> > in the various tools so it's possible to pool for payout purposes
>> without
>> > giving up control of block creation modulo the coinbase. Combined with
>> the
>> > recent sipa performance enhancing goodness, it would hopefully persuade
>> some
>> > non-trivial chunk of hashpower to go back to running their own node and
>> > start the process of turning pools merely into payout trackers rather
>> than
>> > block selectors.
>> >
>> >
>> > On Fri, Jul 18, 2014 at 12:41 PM, Mike Hearn <mike at plan99.net> wrote:
>> >>
>> >> Jeff, I think the message you're replying to got clipped.
>> >>
>> >> Satoshi's only comment AFAIK on the topic of GPU mining was to wish
>> for a
>> >> gentlemen's agreement to postpone it as long as possible, to help make
>> sure
>> >> the distribution of coins was as even as possible. Indeed this predated
>> >> pooled mining.
>> >>
>> >
>>
>>
>>
>> --
>> 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/b1619afb/attachment.html>

2023-06-07 15:24:04

- reply

📅 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 6:44 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Yes. That, and several other things. If you can figure out how to
> propagate a block without re-propagating all the transactions everyone
> already has, you address the large-blocks-slower-to-relay problem, and
> additionally create an incentive for miners to mine blocks consisting
> of publicly broadcast transactions (versus a bunch of secret ones
> mined with secret agreements).
>
> Democratizing transaction selection takes a bit of power away from the
> miners and gives it back to the network at large. GBT is another
> piece of that puzzle.
>
>
> On Fri, Jul 18, 2014 at 6:43 AM, Mike Hearn <mike at plan99.net> wrote:
> > Oops, sorry, I see the subject line changed. This is what I get for
> working
> > down the thread list top to bottom :)
> >
> > I think the best path forward now is to finish off getblocktemplate
> support
> > in the various tools so it's possible to pool for payout purposes without
> > giving up control of block creation modulo the coinbase. Combined with
> the
> > recent sipa performance enhancing goodness, it would hopefully persuade
> some
> > non-trivial chunk of hashpower to go back to running their own node and
> > start the process of turning pools merely into payout trackers rather
> than
> > block selectors.
> >
> >
> > On Fri, Jul 18, 2014 at 12:41 PM, Mike Hearn <mike at plan99.net> wrote:
> >>
> >> Jeff, I think the message you're replying to got clipped.
> >>
> >> Satoshi's only comment AFAIK on the topic of GPU mining was to wish for
> a
> >> gentlemen's agreement to postpone it as long as possible, to help make
> sure
> >> the distribution of coins was as even as possible. Indeed this predated
> >> pooled mining.
> >>
> >
>
>
>
> --
> 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/e0c8569d/attachment.html>