Alex Mizrahi [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 17:59:22

- reply

📅 Original date posted:2017-04-06
📝 Original message:> Agreed! There's no benefit to Bitcoin for having it - one way or the other
> miners are going to destroy ~12BTC/block worth of energy. Meanwhile it
> appears
> to have lead to something like a year of stupid political bullshit based
> on a
> secret advantage - there's no reason to invite a repeat of this episode.
But is it even possible to completely remove ASICBOOST optimization
possibility?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/f18699ac/attachment.html>

2023-06-07 17:59:20

- reply

📅 Original date posted:2017-04-06
📝 Original message:> Ethically, this situation has some similarities to the DAO fork.
There are no similarities.
The DAO fork was against the principles of cryptocurrencies: a change of
the ledger done in violation of pre-agreed rules. The whole point of
cryptocurrency is to avoid shit like that. (E.g. a central banker changing
ledger as he wants.)
Greg's proposal is in line with the principles of cryptocurrencies:
PoW-based cryptocurrency can work only if there is a competition between
miners, which requires all miners to have equal access to the technology.
The notion that Bitmain is entitled to future profits is completely
ridiculous. Every investment has a risk, and doing unusual stuff which
boosts your profits is associated with increased risk. Developers just need
to make sure all miners are on equal grounds, as that's the whole point of
the protocol. If Bitmain loses their profits because of that it's really
just Bitmain's problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/622850e0/attachment.html>

2023-06-07 17:59:20

- reply

📅 Original date posted:2017-04-06
📝 Original message:> Ethically, this situation has some similarities to the DAO fork.
Much better analogy:
1. An ISV make software which makes use of an undocumented OS feature.
2. That feature is no longer present in the next OS release.
3. ISV suffers losses because its software cannot work under new OS, and
thus people stop buying it.
I think 99% of programmers would agree that this loss was inflicted by a
bad decision of ISV, and not by OS vendor changing OS internals. Relying on
undocumented features is something you do on your own risk.
I think it is ethically unambiguous to everyone who isn't on Bitmain's
payroll.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/5645efed/attachment.html>

2023-06-07 17:52:08

- reply

📅 Original date posted:2016-08-02
📝 Original message:>
> I would love to see an RFC-style standard "multiple-colored-coin-protocol"
> written by reps from all of the major protocols and that meta-merges the
> features of these implementations
>
We actually tried to do that in 2014-2015, but that effort have failed...
Nobody was really interested in collaboration, each company only cared
about it's own product.
Especially Colu, they asked everyone for requirements, and then developed a
new protocol completely on their own without taking anyone's input.
I'm not sure that merging the protocols makes sense, as some protocols
value simplicity, and a combined protocol cannot have this feature.
I don't think there is much interest in a merged colored coin protocol now.
Colu is moving away from colored coins, as far as I can tell.
CoinSpark is now doing MultiChain closed-source private blockchain.
CoinPrism also seems to be largely disinterested in colored coins.
We (ChromaWay) won't mind replacing EPOBC with something better, our
software could always support multiple different kernels so adding a new
protocol isn't a big deal for us.
So if somebody is interested in a new protocol please ping me.
One of ideas I have is to decouple input-output mapping/multiplexing from
coloring.
So one layer will describe a mapping, e.g. "Inputs 0 and 1 should go into
outputs 0, 1 and 2".
In this case it will be possible to create more advanced protocols (e.g.
with support for 'smart contracts' and whatnot) while also keeping them
compatible with old ones to some extent, e.g. a wallet can safely engage in
p2ptrade or CoinJoin transactions without understanding all protocols used
in a transaction.
> - in collaboration with feedback from core developers that understand the
> direction the protocol will be taking and the issues to avoid.
>
Core developers generally dislike things like colored coins, so I doubt
they are going to help.
Blockstream is developing a sidechain with user-defined assets, so I guess
they see it as the preferred way of doing things:
https://elementsproject.org/elements/asset-issuance/
> As it stands, investors have to install multiple wallets to deal with
> these varying implementations.
>
Actually this can be solved without making a new "merged protocol": one can
just implement a wallet which supports multiple protocols.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160802/2da95a58/attachment.html>

2023-06-07 15:35:58

- reply

📅 Original date posted:2015-05-31
📝 Original message:> That orphan rate increase will go to whoever is producing the 20MB blocks,
> NOT you.
>
This depends on how miners are connected.
E.g. suppose there are three miners, A and B have fast connectivity between
then, and C has a slow network.
Suppose that A miners a block and B receives it in 1 second. C receives it
in 6 seconds.
This means that blocks mined by C during these ~5 seconds will be orphaned
because B gets A's block first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150531/500f47c7/attachment.html>

2023-06-07 15:35:58

- reply

📅 Original date posted:2015-05-31
📝 Original message:>
> Yes, if you are on a slow network then you are at a (slight) disadvantage.
> So?
>
Chun mentioned that his pool is on a slow network, and thus bigger blocks
give it an disadvantage. (Orphan rate is proportional to block size.)
You said that no, on contrary those who make big blocks have a disadvantage.
And now you say that yes, this disadvantage exist.
Did you just lie to Chun?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/28766322/attachment.html>

2023-06-07 15:33:45

- reply

📅 Original date posted:2015-05-30
📝 Original message:> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
>
> Do you anticipate linear growth?
>
It's safe to say that absolutely nobody can predict the actual growth with
any degree of an accuracy.
I believe that linear growth compares very favorably to other alternatives:
1. Exponential growth: Linear growth is better at modelling diminishing
returns, that is, risk that it grows too much is much smaller. At the same
time initially it will grow faster than reasonable exponential models.
E.g. linear year-over-year relative growth: 100% 50% 33% 25% ...10%
While exponential one which gives the same result in 10 years:
25% 25% ... 25%
This is on the same scale, but exponential starts slower than we want at
start (1.25 MB will be too little for 2016 as we already see fully filled 1
MB blocks), but goes a bit too fast in the long term. It's highly unlikely
we'll see bandwidth growing 10x each 10 years in the long term.
2. Single step increase: an obvious advantage is that linear growth gives
us time to adapt to near realities, time to change something if there is an
unwanted effects, etc. At the same a single step is not a long-term
solution.
While a slow-but-steady growth might be.
3. Adaptive solutions (e.g. limit depends on the last N blocks or something
of that nature):
The problem with them is that they are rather complex, and also:
3.1. prone to manipulation: somebody might try to push the limit if it
will favor him in future
3.2. possibility of a positive feedback loop.
3.3. possibility of an unhealthy game-theoretic dynamics
The main problem is that we do not understand game theoretic aspects of
bitcoin mining in presence of various real-world factors such as block
propagation delays. Thus we can't design a proper adaptive solution.
There is no perfect solution to this problem as we cannot predict the
future and our understanding is limited.
But among the 5 alternatives (linear, exponential, single step, adaptive,
no limit), linear seems to be the best option at this point as it's both
quite safe and doesn't stunt growth too much.
> bitcoin is really really small right now, any sign of real adoption could
make it grow 100x or even more in a matter of weeks.
This is certainly possible, but the thing is:
1) this can't be predicted;
2) this will be a serious problem for many bitcoind installations;
3) it's not necessarily a healthy thing, perhaps it will grow 100x in a
matter of weeks, and then will go to zero in matter of weeks as well.
So I don't think that sudden growth spurts is something we should take into
account on the planning stage. If anything we'd like to prevent them from
happening, slow growth is usually better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150531/7511ce61/attachment.html>

2023-06-07 15:33:44

- reply

📅 Original date posted:2015-05-30
📝 Original message:> Why 2 MB ?
>
Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
Why not grow it by 1 MB per year?
This is a safer option, I don't think that anybody claims that 2 MB blocks
will be a problem.
And in 10 years when we get to 10 MB we'll get more evidence as to whether
network can handle 10 MB blocks.
So this might be a solution which would satisfy both sides:
* people who are concerned about block size growth will have an
opportunity to stop it before it grows too much (e.g. with a soft fork),
* while people who want bigger blocks will get an equivalent of 25% per
year growth within the first 10 years, which isn't bad, is it?
So far I haven't heard any valid arguments against linear growth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150531/29b010f3/attachment.html>

2023-06-07 15:33:22

- reply

📅 Original date posted:2015-05-07
📝 Original message:Just to add to the noise, did you consider linear growth?
Unlike exponential growth, it approximates diminishing returns (i.e. tech
advances become slower with time). And unlike single step, it will give
people time to adapt to new realities.
E.g. 2 MB in 2016, 3 MB in 2017 and so on.
So in 20 years we'll get to 20 MB which "ought to be enough for anybody".
But if miners will find 20 MB blocks too overwhelming, they can limit it
through soft work, based on actual data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/8308767e/attachment.html>

2023-06-07 15:27:05

- reply

📅 Original date posted:2014-11-03
📝 Original message:> For those following this thread, we have now written a paper
> describing the side-chains, 2-way pegs and compact SPV proofs.
> (With additional authors Andrew Poelstra & Andrew Miller).
>
> http://blockstream.com/sidechains.pdf
Haven't seen any material discussion of this paper in this mailing list, so
I'll start.
(Otherwise, I've seen Peter Todd's reaction on reddit.)
This paper fails to demonstrate that sidechains are anything more than a
wishful thinking.
It can be distilled down to this:
"We want such and such features, hence we'll use DMMS, the same thing
Bitcoin uses, thus it will be secure!"
Um, no.
Alt-coins also use DMMS, but aren't as secure as Bitcoin.
So DMMS does not work by itself, it is a mechanism to secure a blockchain
using economic incentives.
The sidechains paper does not mention this, as far as I can tell.
In my opinion, this is not acceptable. If you're making a proposal, you
need to describe what conditions are required for it to work.
Authors are clearly aware of the problem and mention it in section 6
"Future directions" 6.1. "Hashpower attack resistance".
The problem is they do not make it clear that the proposal just makes no
sense until this is solved.
In the discussions on reddit I've noticed that pretty much everybody
believes that release of sidechains paper implies that the proposal is
complete and now we are just waiting the implementation.
It doesn't help that the paper itself tries to sweep the problem under the
rug and has misleading statements.
Particularly, I'm talking about section "4.2. Fraudulent transfers":
"Reorganisations of arbitrary depth are in principle possible, which could
allow an attacker to
completely transfer coins between sidechains before causing a
reorganisation longer than the contest
period on the sending chain to undo its half of the transfer. ... If the
attacker is allowed to return the transferred coins to the original
chain, he would increase the number of coins in his possession at the
expense of other users of the sidechain.
Before discussing how to handle this, we observe that this risk can be made
arbitrarily small by
simply increasing the contest period for transfers."
Wow, really? Is this risk stochastic?
The first sentence implies that attacker is able to cause a reorganization
of an arbitrary depth, but the rest of the section implies that
reorganizations are a naturally occurring phenomenon.
All in all, I find this paper really disappointing. It's going to be
influential (9 co-authors, many of which are regarded as Bitcoin core
developers, must be good!) and hyped, and thus might focus research on an
area which is fundamentally flawed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141103/d46df6bb/attachment.html>

2023-06-07 15:27:05

- reply

📅 Original date posted:2014-11-03
📝 Original message:> From the introduction "[...]Because signers prove computational work,
> rather than proving secret knowledge as
> is typical for digital signatures, we refer to them as miners. To
> achieve stable consensus on the
> blockchain history, economic incentives are provided where miners are
> rewarded with fees and
> subsidies in the form of coins that are valuable only if the miners
> form a shared valid history,
> incentivising them to behave honestly.[...]"
>
This isn't applicable in case of sidechains: anybody with sufficient
hashpower will be able to unlock a locked coin on the parent chain by
producing an SPV proof.
"Only if the miners form a shared valid history" isn't a requirement here,
as miner will get bitcoins which aren't in any way connect to sidechain he
have wrecked. Thus there is no incentive to behave honestly.
Thus sidechains, in principle, reward their miners
>
with the same Bitcoin will use in the future: only transaction fees.
> Since some people claim that won't be enough
Whether it is enough depends on a variety of factors, including existence
of other chains miner can mine.
You cannot assume that it is the same situation as with a simple
single-chain model.
E.g. imagine 1000 BTC were moved to a sidechain. Miners can keep mining
bitcoins as usual, and in parallel work on an SPV proof to claim these 1000
BTC. (I assume that merged-mining is allowed.)
In this case the amount of fees which miners could collect by honest mining
on the sidechain is irrelevant, as long as it is smaller than 1000 BTC.
This is quite different from attacks which can be performed on vanilla
Bitcoin (see below), so I don't think you can say that the security model
is the same.
Also says "Given our assumption that p > q, the probability drops
>
exponentially as the number of blocks the
> attacker has to catch up with increases."
>
Yes, but that doesn't apply to reorganizations which attacker might cause
intentionally.
Hence I think it was disingenuous to include these two very different
treats into one section:
it sounds like you claim that attacker-induced reorganizations are
unlikely, while it isn't the case.
So the longer the contest period is, the harder it is to succeed with
> a fraudulent transfer.
>
Yes, but "harder" isn't same as "unlikely".
Another problem with this section is that it only mentions reorganizations.
But a fraudulent transfer can happen without a reorganization, as an
attacker can produce an SPV proof which is totally fake. So this is not
similar to double-spending, attacker doesn't need to own coins to perform
an attack.
> I hope this clarifies our assumptions.
>
Yep, thanks. It looks like you assume that sidechain security will be
similar to Bitcoin security in the long term.
Now quite the assumptions I've been looking for, but OK...
I'm sorry for the harsh tone, but I just find it hilarious that people who
explained that proof-of-stake is not going to work because an attacker
might collect everybody's past signing keys to rewrite the whole history
(I'm referring to this: https://download.wpsoftware.net/bitcoin/pos.pdf )
didn't bother to mention that miners can collude to wreck a sidechain and
get an awesome reward, basically for free.
something something the mote in thy brother's eye something something
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141103/2331a54d/attachment.html>