Alex Mizrahi [ARCHIVE]

⚠️ 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.

Public Key

npub1swfeusu3ua9trup00qcnrgc2yndksyvgku4epk5tec7u4fmrez6qxpul5t

Profile Code

nprofile1qqsg8yu7gwg7wj437qhhsvf35v9zfkmgzxytw2usm29uu0w25a3u3dqhzl5mp

Author Public Key

npub1swfeusu3ua9trup00qcnrgc2yndksyvgku4epk5tec7u4fmrez6qxpul5t

Show more details

Last Notes

2023-06-07 17:59:29

- reply

📅 Original date posted:2017-04-07
📝 Original message:> Can you please not forget to supply us more details on the claims made
> regarding the reverse engineering of the Asic chip?
>
> It is absolutely crucial that we get these independently verified ASAP.
>
Bitmain confirmed that their chips support ASICBOOST and it can be used for
mining:
https://blog.bitmain.com/en/regarding-recent-allegations-smear-campaigns/
They claim that they don't use it on mainnet, but that claim cannot be
verified. it is possible to do covert ASICBOOST in a 100% covert manner.
(It can be done without "transaction reordering" so it's not worth
analyzing blocks etc.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/b6eb9b2e/attachment-0001.html>

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 17:51:15

- reply

📅 Original date posted:2016-06-23
📝 Original message:>
> The point I'm making is simply that to be useful, when you close a seal you
> have to be able to close it over some data, in particular, another seal.
> That's
> the key thing that makes the idea a useful construct for smart contacts,
> value
> transfer/currency systems, etc.
>
OK, your second post ("Closed Seal Sets and Truth Lists for Better Privacy
and Censorship Resistance") seems to clarify that this data is one of
arguments to the condition function.
Frankly this stuff is rather hard to follow. (Or maybe I'm dumb.)
Now I don't get scability properties. Let's consider a simplest scenario
where Alice creates some token, sends it to Bob, who sends it to Claire. So
now Claire needs to get both a proof that Alice sent it to Bob and that Bob
sent it to Claire, right? So Claire needs to verify 2 proofs, and for a
chain of N transfers one would need to verify N proofs, right?
And how it works in general:
1. Alice creates a token. To do that she constructs an unique expression
which checks her signature and signs a message "This token has such and
such meaning and its ownership originally associated with seal <hash of the
expression>" with her PGP key.
2. To transfer this token to Bob, she asks Bob for his auth expression and
sends a seal oracle a message (Alice_expression (Bob_expression .
signature)) where signatures is constructed in such a way that it evaluates
as true. Oracle stores this in a map: Alice_expression -> (Bob_expression .
signatures)
3. Bob sends token to Claire in a same way: (Bob_expression
(Claire_expression . signature))
4. Now Claire asks if Alice_expression->(Bob_expression . _) and
Bob_expression->(Claire_expression . _) are in oracle's map. She might
trust the oracle to verify signatures, but oracle doesn't understand token
semantics. Thus she needs to check if these entries were added.
If I understand correctly, Alice_expression->(Bob_expression . _) record
can be communicated in just 3 * size_of_hash_digest bytes.
So this seems to have rather bad scalability even with trusted oracles, am
I missing something?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/2ebbc3c3/attachment-0001.html>

2023-06-07 17:51:14

- reply

📅 Original date posted:2016-06-20
📝 Original message:> All practical single-use seals will be associated with some kind of
> condition,
> such as a pubkey, or deterministic expression, that needs to be satisfied
> for
> the seal to be closed.
I think it would be useful to classify systems w.r.t. what data is
available to condition.
I imagine it might be useful if status of other seals is available.
> Secondly, the contents of the proof will be able to
> commit to new data, such as the transaction spending the output associated
> with
> the seal.
>
So basically a "condition" returns that "new data", right?
If it commits to a data in a recognizable way, then it's practically a
function which yields a tuple (valid, new_data).
If an oracle doesn't care about data then you can convert it to a predicate
using a simple projection.
But from point of view of a client, it is a function which returns a tuple.
It might help if you describe a type of the condition function.
Some related work on UTXO-based smart contracts:
1. Typecoin described in the paper
"Peer-to-peer Affine Commitment using Bitcoin" Karl Crary and Michael J.
Sullivan Carnegie Mellon University PLDI ’15, Portland June 17, 2015
I don't see the paper in open access and I've lost my copy, but there are
slides: https://www.msully.net/stuff/typecoin-slides.pdf
The paper is written by programming language researchers, and thus use
fairly complex constructs.
The idea is to use the language of linear logic, but it's actually
implemented using type-oriented programming.
So, basically, they associate logical propositions with transaction
outputs. Transactions proof that output-propositions logically follow from
input-propositions.
The paper first describes as a colored coin kind of a system, where color
values are propositions/types.
But in the implementation part it became more like a metacoin, as it uses a
complete transaction history.
A setup with a trusted server is also mentioned.
The interesting thing about Typecoin is that a contract language is based
on logic, which makes it powerful and -- I guess -- analyzable. However,
the paper doesn't mention any performance details, and I guess it's not
good.
Another problem is that it looks very unusual to people who aren't used to
type-oriented programming.
2. Generic coins
Seeing how much Typecoin people had to struggle to describe a Bitcoin-style
system I decided to describe a generalized Bitcoin-style system, so it can
be easily referenced in research. Sadly all I got so far is a draft of an
introduction/definition sections:
https://github.com/chromaway/ngcccbase/wiki/gc
In the first section I described a transaction graph model which is
supposed to be general enough to describe any kind of a transaction graph
system with explicit dependencies and no "spooky action at distance". As it
turns out, any such system can be defined in terms of few predicate
functions, however, using these functions directly might be very
inefficient.
The next section introduces a coin-based model. A coin-based system can be
described using a single function called coin kernel which is applied to a
transaction and a list of input coinstates.
It is then described how to go from a coin-based model to a
transaction-graph model.
The reverse should also be possible if we add additional restrictions on a
transaction-graph model, it's probably enough to define that coin can be
spent only once. (Partial coin spends were described in Freimarkets.)
There is a fairly shitty prototype in Haskell:
https://github.com/baldmaster/ColorCoin
3. flexichains
This is a prototype done by me more recently, the interesting thing about
it is that it unifies account-based and UTXO-based models in a single model.
We first introduce a notion of record. A record can be of an arbitrary
type, the only restriction is that it must have a key which must be unique
within a system.
Then transaction model can be introduced using two function:
txDependencies returns a list of keys of records transaction depends on
applyTx takes a transaction and a list of records it depends on and
returns either a list of records or an error.
A list of records includes
* new records which are created by a transaction
* updated records will have the same key but different content
A simple account-based system can be implement using tuples (pubkey,
balance, last_update) as records.
In an UTXO-based system records are transaction output, and they should
include a spent flag. (Obviously, records with spent flag can be pruned.)
A system with custom smart contracts can be implemented by adding some sort
of a function or bytecode to records.
A Haskell prototype is here:
https://bitbucket.org/chromawallet/flexichains/src/21059080bed6?at=develop
(It's kinda broken and incomplete, though.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/a4d13078/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:34:53

- reply

📅 Original date posted:2015-05-13
📝 Original message:Let's consider a concrete example:
1. User wants to accept Bitcoin payments, as his customers want this.
2. He downloads a recent version of Bitcoin Core, checks hashes and so on.
(Maybe even builds from source.)
3. Let's it to sync for several hours or days.
4. After wallet is synced, he gives his address to customer.
5. Customer pays.
6. User waits 10 confirmations and ships the goods. (Suppose it's something
very expensive.)
7. Some time later, user wants to convert some of his bitcoins to dollars.
He sends his bitcoins to an exchange but they never arrive.
He tries to investigate, and after some time discovers that his router (or
his ISP's router) was hijacked. His Bitcoin node couldn't connect to any of
the legitimate nodes, and thus got a complete fake chain from the attacker.
Bitcoins he received were totally fake.
Bitcoin Core did a shitty job and confirmed some fake transactions.
User doesn't care that *if *his network was not impaired, Bitcoin Core *would
have *worked properly.
The main duty of Bitcoin Core is to check whether transactions are
confirmed, and if it can be fooled by a simple router hack, then it does
its job poorly.
If you don't see it being a problem, you should't be allowed to develop
anything security-related.
If a node is connected to 99 dishonest nodes and 1 honest node, it can
> still sync with the main network.
>
Yes, it is good against Sybil attack, but not good against a network-level
attack.
Attack on user's routers is a very realistic, plausible attack.
Imagine if SSL could be hacked by hacking a router, would people still use
it?
Fucking no.
> A 3 month reversal would be devastating, so the checkpoint isn't adding
> much extra security.
>
WIthout checkpoints an attacker could prepare a fork for $10.
With checkpoints, it would cost him at least $1000, but more likely upwards
of $100000.
That's quite a difference, no?
I do not care what do you think about the reasons why checkpoints were
added, but it is a fact that they make the attack scenario I describe above
hard to impossible.
Without checkpoints, you could perform this attack using a laptop.
With checkpoints, you need access to significant amounts of mining ASICs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/1683d04a/attachment.html>

2023-06-07 15:34:52

- reply

📅 Original date posted:2015-05-13
📝 Original message:> With POW, a new node only needs to know the genesis block (and network
> rules) to fully determine which of two chains is the strongest.
>
But this matters if a new node has access to the globally strongest chain.
If attacker is able to block connections to legitimate nodes, a new node
will happily accept attacker's chain.
So PoW, by itself, doesn't give strong security guarantees. This problem is
so fundamental people avoid talking about it.
In practice, Bitcoin already embraces "weak subjectivity" e.g. in form of
checkpoints embedded into the source code. So it's hard to take PoW purists
seriously.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/39177196/attachment.html>

2023-06-07 15:33:57

- reply

📅 Original date posted:2015-05-08
📝 Original message:Adaptive schedules, i.e. those where block size limit depends not only on
block height, but on other parameters as well, are surely attractive in the
sense that the system can adapt to the actual use, but they also open a
possibility of a manipulation.
E.g. one of mining companies might try to bankrupt other companies by
making mining non-profitable. To do that they will accept transactions with
ridiculously low fees (e.g. 1 satoshi per transaction). Of course, they
will suffer losees themselves, but the they might be able to survive that
if they have access to financial resources. (E.g. companies backed by banks
and such will have an advantage).
Once competitors close down their mining operations, they can drive fees
upwards.
So if you don't want to open room for manipulation (which is very hard to
analyze), it is better to have a block size hard limit which depends only
on block height.
On top of that there might be a soft limit which is enforced by the
majority of miners.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/e290f012/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:30:20

- reply

📅 Original date posted:2015-02-12
📝 Original message:> Your "scorched earth" plan is aptly named, as it's guaranteed to make
> unconfirmed payments useless.
>
"Scorched earth" makes no sense by itself. However, it can be a part of a
bigger picture. Imagine an insurance service which will make sure that
merchants are compensated for every scorched-earth or double-spend
transaction, as long they pay 0.1% premium from their revenue.
Merchants won't really care how it works as long as it does. All they know
is that they need to use a particular open-source wallet, and they will
receive a payment no matter what.
You won't need a TTP to process each payment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/9d43299e/attachment.html>

2023-06-07 15:30:13

- reply

📅 Original date posted:2015-02-12
📝 Original message:> "The approach" is how Bitcoin has always worked.
>
Mike, you're making "it worked before, and thus it will work in future"
kind of an argument.
It is an extremely shitty kind of an argument. And it can be used to
justify any kind of bullshit.
E.g. any scamcoin which haven't yet collapsed will work forever.
As I mentioned, it depends on scale. Highly sophisticated attacks are only
feasible when scale is sufficiently big.
I.e. when you have millions of dollars transacted each day it is one thing,
but if you process billions of dollars, it becomes a whole another matter.
The best way to profit from zero-confirmation payment disruption is through
derivatives: short-sell Bitcoin while performing this attack. But this kind
of an attack depends on a number of conditions:
1. highly liquid and reliable derivative market
2. sufficiently stable exchange rate
3. significant attack impact: lots of merchants relying on
zero-confirmation payments, and lots of customers paying this way
4. significant amounts of capital available to the attacker
These conditions are not yet met, and were never met in the Bitcoin's
history so far.
This is why I wrote "5 years from now", I believe that we might reach those
conditions around that time.
Direct impact of an attack might actually be low (but even if it is just
0.1%, 0.1% of 1 billion is 10 million, which isn't bad), but attacker might
profit from the panic it causes.
Note that I'm talking about situation where Bitcoin-aware PoS solutions are
deployed on a big scale, so cost of upgrade might be huge.
So anyway, in my opinion, it is actually great that Bitcoin is still
relatively small: we have an opportunity to analyze and improve things.
But you seem to be hostile to people who do that (and who do not share your
opinion), which is kinda uncool.
Also, you do not bother to back your intuition with rigorous reasoning,
while also attacking people who offer alternatives with non-rigorous
slipper-slope kind of arguments. Which is doubly uncool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/c39d4998/attachment.html>

2023-06-07 15:30:11

- reply

📅 Original date posted:2015-02-12
📝 Original message:> Yes, like any P2P network Bitcoin cannot work if a sufficiently large
> number of miners decide to attack it.
>
1. They won't be attacking Bitcoin, they will attack merchants who accept
payments with 0 confirmations. This attack has nothing to do with Bitcoin
consensus mechanism (as Bitcoin protocol doesn't provide a consensus over
mempool contents), thus it is not an attack on Bitcoin.
2. In the example I used, having 10% of hashpower is enough to offer 10%
success rate. Would you mind having 1 out of 10 hamburgers for free? If a
system can be attacked by a tiny fraction, it is a shitty system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/a6b9081f/attachment.html>

2023-06-07 15:30:11

- reply

📅 Original date posted:2015-02-12
📝 Original message:> Miners are *not* incentivised to earn the most money in the next block
> possible. They are incentivised to maximise their return on investment.
>
This would be right if you assume that all Bitcoin miners act as a single
entity. In that case it is true that that entity's goal is to maximize
overall ROI.
But each miner makes decisions on his own. Are you familiar with a concept
of Nash equilibrium, prisoner's dilemma, etc?
The fact that nobody is using this kind of a behavior right now doesn't
mean that we can rely on it.
For example, Peercoin was horribly broken in 6 months after its release
(e.g. people reported that they are able to generate 50 consecutive blocks
simply by bringing a cold wallet online) and yet nobody bothered to exploit
it, and it managed to acquire non-negligible "market cap".
So we have an empiric evidence that proof-of-stake miners are motivated to
keep network secure. So, maybe, we should switch to proof-of-stake, if it
was demonstrated that it is secure?
There are good reasons to not switch to proof-of-stake. Particularly, the
kind which is used in Peercoin is not game-theoretically sound. So even if
it works right now, it can fail in a big way once attackers will really get
around to it. An attack requires significant knowledge, effort and,
possibly, capital, so it might be only feasible on a certain scale.
So, well, anyway, suppose Peter Todd is the only person interested in
maintaining replace-by-fee patches right now, and you can talk him into
abandoning them.
OK, perhaps zero-confirmation payments will be de-facto secure for a couple
of years. And thus a lot of merchants will rely on zero-confirmation
payments protected by nothing but a belief in honest miners, as it is damn
convenient.
But, let's say, 5 years from now, some faction of miners who own
soon-to-be-obsolete equipment will decide to boost their profits with a
replace-by-fee pool and a corresponding wallet. They can market it as "1 of
10 hamburgers are free" if they have 10% of the total hashpower.
So would you take a responsibility for pushing the approach which isn't
game-theoretically sound?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/b4b4de32/attachment.html>

2023-06-07 15:30:08

- reply

📅 Original date posted:2015-02-12
📝 Original message:> To remain useful as border router, the replace-by-fee patched core should
> only relay double spend if it actually replaces an earlier transaction, as
> otherwise the replace logic that is according to your commit more than just
> fee comparison, would have to be replicated in the proprietary stack and
> mempool might get out of sync with that of the border router.
>
Why don't you use getrawmempool RPC call to synchronize mempool contents?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/d898c0e1/attachment.html>

2023-06-07 15:27:53

- reply

📅 Original date posted:2014-12-12
📝 Original message:> I think what Gareth was getting at was that with client-side validation
> there can be no concept of a soft-fork. And how certain are you that the
> consensus rules will never change?
>
Yes, it is true that you can't do a soft-fork, but you can do a hard-fork.
Using scheduled updates: client simply stops working at a certain block,
and user is required to download an update.
In Bitcoin we can operate with some assurance that hard-forks will almost
> never happen, exactly because extensions are more likely to occur via
> soft-fork mechanisms. In such a case, old non-updated clients will still
> generate a correct view of the ledger state. But this is not so with client
> side validation!
>
You assume that an ability to operate with zero maintenance is very
important, but is this a case?
There was a plenty of critical bugs in bitcoind, and in many cases people
were strongly encouraged to upgrade to a new version.
So, you urge people to keep their clients up-to-date, but at the same time
claim that keeping very old versions is critically important.
How does this make sense? Is this an exercise at double-think?
An alternative to this is to make updates mandatory. You will no longer
need to maintain compatibility with version 0.1 (which is impossible) and
you can also evolve consensus rules over time.
It looks like people make a cargo cult out of Bitcoin's emergent
properties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141212/7dd1f4ef/attachment.html>

2023-06-07 15:27:51

- reply

📅 Original date posted:2014-12-12
📝 Original message:>
> "Secure" and "client side validation" don't really belong in the same
> sentence, do they?
>
Well, client-side validation is mathematically secure, while SPV is
economically secure.
I.e. it is secure if you make several assumptions about economics of the
whole thing.
In my opinion the former is transfinitely more secure than the later.
But it's more of a philosophical question, sure.
The good thing about PoW-based consensus is that it is robust against
version inconsistencies and various accidents of this nature up to a
certain degree. But you hardly can depend on that:
You know, The Great Fork of 2013 was resolved through human intervention,
Bitcoin nodes were not smart enough to detect that something is going awry
on their own.
Naive proof-of-publication is very fragile in that respect, but you can
easily bring back robustness.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141212/76a5cbeb/attachment.html>

2023-06-07 15:27:46

- reply

📅 Original date posted:2014-12-16
📝 Original message:> The goal is to have an opportunity cost to breaking the rules.
>
You could as well have said "The goal is to implement it in a specific way
I want it to be implemented."
This makes zero sense.
You aren't even trying to compare properties of different possible
implementations, you just outright reject the alternatives.
So the thing is, relying on opportunity cost is rather problematic.
1. can't work when system isn't heavily used (you'll have to rely on the
honesty of miners instead)
2. chicken-and-egg: system is not secure until it is heavily used, and it
isn't heavily used until it is secure
3. finally, if the expected profit from attack is higher than the
opportunity cost of it, it just makes no sense
Let's put 1 and 2 aside. For the start, you need to prove that attack
cannot yield profits which are higher than honest mining.
The problem with it is that the total amount of money is much higher than
the amount of money which is being transacted in a short time frame. And it
is much higher than what fees might yield within a reasonable time frame.
So if there is a way to attack the whole (with a profit proportional to the
whole), you won't be able to rely on opportunity cost to prevent the attack.
Usually at this point people say "we assume that miners aren't going to
collude, otherwise even Bitcoin is not secure".
Well, this is BS. The fact that a pool can acquire more than 50% of total
hashpower was successfully demonstrated by ghash.io.
But the thing is, Bitcoin doesn't offer one a good way to attack the whole,
as there are powerful factors which will work against the attacker.
But this is not the case with sidechains (or any merged-mined chains, for
that matter).
And once you have a clear incentive, collusion is much more likely.
> Proof of Burn is a real cost for following the rules.
>
So what? As long as cost is less than revenue, it is OK.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141216/ec335df8/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>

2023-06-07 15:27:00

- reply

📅 Original date posted:2014-10-28
📝 Original message:> This thread is, in my opinion, a waste of time. It's yet again
> another perennial bikeshedding proposal brought up many times since at
> least 2011, suggesting random changes for
> non-existing(/not-yet-existing) issues.
>
> There is a lot more complexity to the system than the subsidy schedule.
>
Well, the main question is what makes Bitcoin secure.
It is secured by proofs of work which are produced by miners.
Miners have economic incentives to play by the rules; in simple terms, that
is more profitable than performing attacks.
So the question is, why and when it works? It would be nice to know the
boundaries, no?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/33741ecb/attachment.html>

2023-06-07 15:26:48

- reply

📅 Original date posted:2014-10-25
📝 Original message:> For the sake of argument, lets assume that somehow (quite unlikely)
Why is it unlikely? Do you believe that the cost of electricity cannot be
higher than expected mining revenue?
Or do you expect miners to keep mining when it costs them money?
> half the mining equipment gets shut off.
> The amount of hashes/second is such that it is currently, lets just say,
> quite
> secure against any takeover.
>
The equipment won't be simply turned off, it will be up for grabs.
Please check this web sites:
https://nicehash.com/
https://www.multipool.us/
One can use them in the same way he uses normal mining pools, and they
switch between different chains.
Say, multipool.us can switch between BTC and PPC (Peercoin).
Mining BTC will be less profitable after a halving, so a miner who is
willing to maximize his profits might use multipool to auto-switch to
something more profitable.
Which might be attack-on-Bitcoin.
E.g. if 60% of bitcoin's total hashrate is available via "multipools", one
can try to pull of a double-spending attack.
> Your document makes a long series of assumptions about how this can turn
> out
> bad with each individually is implausible, together are just fiction.
>
It sounds like you failed to grasp even basics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141025/2daacf00/attachment.html>

2023-06-07 15:26:46

- reply

📅 Original date posted:2014-10-25
📝 Original message:> The hashpower market is maturing in the direction of
> financial instruments, where the owner of the hashpower is not
> necessarily the one receiving income. These are becoming tradeable
instruments,
Meni Rosenfeld issued tradeable mining bonds back in 2012:
https://bitcointalk.org/index.php?topic=65569.0
So this is hardly new stuff. But it definitely won't help.
The contract specifies how many bitcoins bondholder would get depending on
difficulty and other factors.
But, usually, bondholder doesn't care (and cannot check) where these
bitcoins come from.
Thus the owner of the mining equipment can temporarily turn off that
equipment off, and instead buy them on the market, as he needs to spend
less money than he would spend on electricity. Then he can pocket the
difference.
> Simplistic models cannot predict what hashpower does in the face of
> business-to-business medium- and long-term contracts.
>
Ah, yes, let's forget game theory, business people know it better!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141025/4ce59ce0/attachment.html>

2023-06-07 15:26:46

- reply

📅 Original date posted:2014-10-25
📝 Original message:> We had a halving, and it was a non-event.
> Is there some reason to believe next time will be different?
>
Yes.
When the market is rapidly growing, margins can be relatively high because
of limited amounts of capital being invested, or introduction of more
efficient technologies.
However, we should expect market to become more mature with time, and a
mature market will result in lower margins.
The halving can do much more damage when margins are relatively small.
Besides that, there is a difference in ecosystem maturity:
1. Back in 2012, miners weren't so focused on profits, as Bitcoin was
highly experimental: some were mining for the hell of it (it was a novelty
thing back then), others wanted to secure the network, others did it
because it was hard to obtain bitcoins by other means. But now miners are
mostly profit-motivated: they buy expensive dedicated mining equipment and
want to maximize profits. As you might know, at one point ghash.io reached
50% hashrate, and miners didn't care about it enough to switch to a
different pool.
2. Back in 2012, we didn't have multipools. Multipools automatically
switches between mining different alt-chains to maximize miners' profits.
Miners who use multipools do not care how their hashrate is used as long as
they profit off it.
Particularly, check https://nicehash.com/ -- you can easily buy hashrate to
attack a smaller alt-coin, for example.
If the halving will result in a significant hashrate drop (and we did
observe hashrate drop in 2012, although it wasn't that big), it might be
possible to buy enough hashpower to attack Bitcoin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141025/d828d84e/attachment.html>

2023-06-07 15:26:17

- reply

📅 Original date posted:2014-10-06
📝 Original message:I've heard about this idea from TierNolan. Here's some quick an dirty
analysis:
Suppose the last known block claimed a large tx fee of L. A miner who owns
1/N of the total hashrate needs to choose between two strategies:
1. Mine on top of that block and win usual reward R with probability 1/N.
2. Mine on top of the previous block, trying to make two blocks in a row,
might get reward L with probability 1/N^2.
Thus for the first strategy expected payoff is R/N, and for the second the
expected pay-off is L/N^2.
Second strategy is viable if R/N < L/N^2,
R < L/N.
Now suppose the miner who claimed the unusually large reward will share it
with the next miner, for example, using coinbase output with OP_TRUE. If
that shared reward Rs is higher than L/N^2, then the next miner will be
better off mining on top of that block.
This doesn't require protocol changes(*) and can be simply incorporated
into a piece of code which decides what to do when a transaction with
unusually large fee appears. (I.e. it will automatically share the fee, and
others will recognize that). And if the biggest miner has 25% of all
hashrate, sharing 25% of your loot doesn't sound that bad.
(*) Except one problem: coinbase maturity rules won't allow one to share
the fee with the next miner.
So some protocol changes are required. But changes which affect coinbase
maturity and sharing are probably going to be simpler and smaller than what
Sergio have proposed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141006/44b0b2bc/attachment.html>

2023-06-07 15:24:40

- reply

📅 Original date posted:2014-08-05
📝 Original message:>
> A distinction there is that they can only become invalid via a
> conflict— replaced by another transaction authored by the prior
> signers. If no other transaction could be created (e.g. you're a
> multisigner and won't sign it again) then there is no such risk.
You need to check transaction's dependencies up to a certain depth to know
whether it is safe:
If one of inputs depends on transaction which is signed by parties with
unknown trustworthiness, then it isn't safe.
> It now introduces chance events ("act of god") into the mix where they
> they didn't exist before.
You need to check transaction's dependencies up to a certain depth to know
whether it is safe:
If one of inputs depends on transaction time-locked script (or other
unrecognized script), then it isn't safe.
Situation is identical, you might need several extra lines of code.
I think it would matter only if we had deterministic, reliable mempool and
reorganization behavior. But it's not something we can depend on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140805/bd7de220/attachment.html>

2023-06-07 15:20:12

- reply

📅 Original date posted:2014-04-25
📝 Original message:It is also useful for betting: an oracle will associate a hash with each
possible outcome, and when outcome is know, it will reveal a corresponding
preimage which will unlock the transaction.
This approach has several advantages over approach with multi-sig script:
1. oracle doesn't need to be involved in each specific transaction
2. resolution is same for everyone who makes a bet on a specific event
outcome
3. no need for two-way communication
4. no need for a special protocol: oracle might publish unlocking preimage
on a web page, and participants will manually enter it into their clients
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/d8b04816/attachment.html>

2023-06-07 15:20:02

- reply

📅 Original date posted:2014-04-28
📝 Original message:>
> I can't remember who I saw discussing this idea. Might have been Vitalik
> Buterin?
>
Yes, he described it in an article a couple of months ago:
http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/
but it is an old idea.
For example, I've mentioned punishment of this kind in discussion about
PPCoin when it was released in 2012, and, I think, it was described in
Etlase2's Decrit design.
Also, I and Iddo did some research on pure proof-of-stake, and it seems to
be feasible, in the sense that there are no obvious problems like "nothing
is actually at stake". (Unfortunately I can't refer to it now as it isn't
published yet.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140428/4d1fdaa3/attachment.html>

2023-06-07 15:19:50

- reply

📅 Original date posted:2014-04-23
📝 Original message:>
> These sorts of proposals are all just ways of saying block chains kind of
> suck and we should go back to using trusted third parties.
>
No.
Different approaches have different trade-offs, and thus different areas of
applicability.
Proof-of-work's inherent disadvantage is that it takes some time until
transaction becomes practically irreversible. On the other hand, it has
advantages like neutrality, censorship-resistance, high degree of security,
etc.
TTP can be very efficient, but doesn't have advantages mentioned above.
It is possible to combine several different approaches into one hybrid
systems. For example, classic Bitcoin PoW blockchain can be used for
settlements, large transactions, savings and so on. While TTP-based payment
system will be used for small-value transaction like buying coffee.
In this case you get benefits of both approaches. Censorship-resistance is
irrelevant when one buys a cup of coffee with his pocket money, isn't it?
For some reason, instead of considering these hybrid solutions (which can
also address scalability problems), you want to make PoW-based system more
complex to be applicable for real-time transaction too.
This will, likely, weaken advantages provided by PoW, and also it won't
provide any hard guarantees, and, if implemented, will undermine
development of alternative solutions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/e3509046/attachment.html>

2023-06-07 15:19:33

- reply

📅 Original date posted:2014-04-23
📝 Original message:> And it still would. Non-collusive miners cast votes based on the outcome
> of their own attempts to double spend.
>
Individually rational strategy is to vote for coinbase reallocation on
every block.
Yes, in that case nobody will get reward. It is similar to prisoner's
dilemma: equilibrium has worst pay-off.
In practice that would mean that simple game-theoretic models are no longer
applicable, as they lead to absurd results.
> I'm using it in the same sense Satoshi used it. Honest miners work to
> prevent double spends. That's the entire justification for their existence.
> Miners that are deliberately trying to double spend are worse than useless.
>
Miners work to get rewards.
It absolutely doesn't matter whether they are deliberately trying to
double-spend or not: they won't be able to double-spend without a collusion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/94b5255c/attachment.html>

2023-06-07 15:19:32

- reply

📅 Original date posted:2014-04-23
📝 Original message:This is outright ridiculous.
Zero-confirmation double-spending is a small problem, and possible
solutions are known. (E.g. trusted third party + multi-sig addresses for
small-value transactions.)
On the other hand, protocol changes like described above might have
game-theoretical implications which are non-trivial and hard to understand.
The above approach works as long as the majority of hashpower is honest,
> defined to mean, working to stop double spending. This is the same security
> property as described in the white paper, thus this introduces no new
> security assumptions.
>
No. Bitcoin should work if miners are merely individually rational, i.e.
they try to maximize their pay-offs without colluding with others.
I guess word "honest" might have different meanings, that can be a source
of confusing.
1. Honest -- not trying to destroy bitcoin
2. Honest -- following rules which are not required by the protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/65999bd2/attachment.html>

2023-06-07 15:18:26

- reply

📅 Original date posted:2014-04-09
📝 Original message:>
> 1) It's more private. Bloom filters gives away quite accurate statistical
> information about what coins you own to whom ever you happen to be
> connected too. An attacker can easily use this to deanonymize you even if
> you don't reuse addresses; Tor does not help much against this attack.
>
There is also an option to download everything, but do only a very basic
surface validation (without keeping track of UTXOs).
You do not need a full node for that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/120496bf/attachment.html>