Leo Wandersleb [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-23 to 2021-02-28
💬 Posted a total of 7 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:29:14

- reply

📅 Original date posted:2021-02-28
📝 Original message:Only headers need to be downloaded sequentially so downloading relevant blocks
from one node is totally possible with gaps in between.
On 2/27/21 4:10 AM, Igor Cota via bitcoin-dev wrote:
> Hi Keagan,
>
> I had a very similar idea. The only difference being for the node to decide on
> a range of blocks to keep beforehand, rather than making the decision
> block-by-block like you suggest.
>
> I felt the other nodes would be better served by ranges due to the sequential
> nature of IBD. Perhaps this would be computationally lighter as well.
>
> I also encourage you to read Ryosuke Abe's paper [1] that proposes a DHT
> scheme to solve this same problem.
>
> Cheers,
> Igor
>
> [1] https://arxiv.org/abs/1902.02174
>
> On Fri, 26 Feb 2021 at 21:57, Keagan McClelland via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi all,
>
> I've been thinking for quite some time about the problem of pruned nodes
> and ongoing storage costs for full nodes. One of the things that strikes
> me as odd is that we only really have two settings.
>
> A. Prune everything except the most recent blocks, down to the cache size
> B. Keep everything since genesis
>
> From my observations and conversations with various folks in the
> community, they would like to be able to run a "partially" pruned node to
> help bear the load of bootstrapping other nodes and helping with data
> redundancy in the network, but would prefer to not dedicate hundreds of
> Gigabytes of storage space to the cause.
>
> This led me to the idea that a node could randomly prune some of the
> blocks from history if it passed some predicate. A rough sketch of this
> would look as follows.
>
> 1. At node startup, it would generate a random seed, this would be unique
> to the node but not necessary that it be cryptographically secure.
> 2. In the node configuration it would also carry a "threshold" expressed
> as some percentage of blocks it wanted to keep.
> 3. As IBD occurs, based off of the threshold, the block hash, and the
> node's unique seed, the node would either decide to prune the data or keep
> it. The uniqueness of the node's hash should ensure that no block is
> systematically overrepresented in the set of nodes choosing this storage
> scheme.
> 4. Once the node's IBD is complete it would advertise this as a peer
> service, advertising its seed and threshold, so that nodes could
> deterministically deduce which of its peers had which blocks.
>
> The goals are to increase data redundancy in a way that more uniformly
> shares the load across nodes, alleviating some of the pressure of full
> archive nodes on the IBD problem. I am working on a draft BIP for this
> proposal but figured I would submit it as a high level idea in case anyone
> had any feedback on the initial design before I go into specification
> levels of detail.
>
> If you have thoughts on
>
> A. The protocol design itself
> B. The barriers to put this kind of functionality into Core
>
> I would love to hear from you,
>
> Cheers,
> Keagan
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> --
> *Igor Cota*
> Codex Apertus d.o.o.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:19:56

- reply

📅 Original date posted:2019-08-06
📝 Original message:On 8/6/19 10:27 PM, Chris Belcher via bitcoin-dev wrote:
> I think this is absolutely wrong, because sybil attackers give up some
> fee income. Here is a worked example:
>
> Let's say the sybil attacker is operating the top 5 most valuable maker
> bots. If this attacker has X coins they would split them equally into 5,
> so each maker has X/5 coins and their bond is worth (X^5)^2 = X^2/25,
> with a total of 5 bots the fee income would be proportional to 5*X^2/25
> = X^2/5. However if an honest maker had X coins they could create a
> single bond which would be worth simply X^2 with a fee income
> proportional to X^2. So the honest maker has a fee income higher by a
> factor of 5 than the sybil attacker. The sybil attacker must take a 5x
> hit to their fee income in order to sybil attack. This is the crucial
> effect of the V^2 term.
>
> The V^2 term is important, it just has the downside of incentivizing
> renting of coins. If we can make that impossible then the problem would
> go away.
To show how this argument is wrong, think about the market being split between
100 makers, each making 1% of the fees. By your argument, by colluding, they
could make far more than 100% of the fees.
Every cartel of makers pooling their bonds beating the odds can't be the goal.
And again, bonds are just a cost of business. If a $10/month in bonds (paid to a
guy to sign with his UTXOs or interest for BTCs lent or ...) leaves me with zero
fees, a $100/month with $1k in fees and $10k/month with $40k in fees, then there
might be a $1000/month barrier to entry for this market but there are enough
people with $10k available to enter the market and drive the fees (earned per
maker) down such that the barrier to entry increases even further. In the end,
only the holders of the 20 biggest bonds will get meaningful business and the
rest will lose their investment or just not bother being makers. And the sibyl
attackers again are the ones that put up the necessary funds with most ease of
them all.

2023-06-07 18:19:55

- reply

📅 Original date posted:2019-08-05
📝 Original message:On 8/6/19 7:04 AM, Chris Belcher via bitcoin-dev wrote:
> However, there _is_ a cost to being a sybil attacker. If we define
> honest makers as entities who run just one maker bot, and dishonest
> makers as entities who run multiple maker bots, then we can say that
> running a dishonest maker operation requires a sacrifice of fee income,
> because someone doing that would earn more money if they ran an honest
> maker instead. This happens because of the quadratic V^2 term in the
> formula calculating the fidelity bond value, which provides this
> incentive for lumping together fidelity bonds. This V^2 is probably the
> most important part for privacy.
As established above, there will emerge a market to lock coins, so these locks
will be readily available without having to buy them. Even with V^2 there is no
reason to amass more coins beyond a certain point. Running the biggest 5 V^2
scores should be pretty solid to get in on many coin joins.
> Another way is to require the bond signature proofs to involve the
> one-time taker identifier, and so be different every time. This
> basically requires fidelity bond privkeys to be online in hot wallets,
> and so should massively increase the difficulty of renting TXOs because
> the maker and the TXO owner need to be in constant real-time communication.
Requiring the bond to reside on a hot wallet would be a massive disadvantage.
No matter how you look at the whole problem of sibyl attacks, the honest maker
will have operational costs and gain fees and the sibyl attacker will have the
same plus profit from the deanonymization. As long as makers hunt marginal
profits, the sibyl attacker having the higher margin from deanonymization will
always win. The fidelity bonds would make this even worse, as increased
complexity and entry cost would not favor more makers but less even before the
centralization incentive mentioned above (V^2). To say that old holders have
bitcoins laying around that they can use for such bonds is a fallacy as they
could just as well rent them out on a bonds market.
How about turning this upside down and shift the incentives from being taker to
being maker by introducing a mandatory fee? If each join costs 1% per maker,
people would initially gasp and reject to update to that version but those who
do, will do to become makers, increasing the maker count massively and
eventually most people in frequent need of joining will also become makers to
offset the costs of being takers.
With these changed rules again the sibyl attackers would still have their
competitive edge and would flood the market with even more cheap offers but now
everybody would have an incentive to do the same and as makers have to have the
UTXOs, it's not free to sibyl attack already.
LW

2023-06-07 17:55:07

- reply

📅 Original date posted:2017-01-04
📝 Original message:On 01/04/2017 12:06 AM, adiabat via bitcoin-dev wrote:
> Also, if you're running a light client, and storing the filters the way you
> store block headers, there's really no reason to go all the way back to height
> 0. You can start grabbing headers at some point a while ago, before your set
> of keys was generated. I think it'd be very worth it even with GB-scale disk
> usage.
The really great benefit of having this index is that you could implement rather
efficient cold wallet spending once the wallet has the full index.
With Mycelium you can currently spend funds from a paper wallet or a BIP39
sentence but at the cost of sharing all addresses with our servers. Schildbach
would share addresses with random full nodes for hours or days to find funds of
a new private key with unknown creation date. With CBF it would still be a
matter of maybe minutes on a phone to identify relevant blocks and download
these but it would be very feasible to implement a private, cold storage
spending feature.
Also the index could be further partitioned by P2PKH, P2PK, P2SH, … This would
lead to a very minor privacy leak for a reasonable reduction in index size.
--
Leo Wandersleb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170104/0accaaba/attachment.sig>

2023-06-07 17:52:04

- reply

📅 Original date posted:2016-07-28
📝 Original message:gmaxwell just made me aware of this mail thread [0]. Some days ago I had
independently and naively started implementing "something similar" [1].
My version totally ignored the commitment and signing part but I'm pretty sure
that 12GB is overkill. My code is currently broken and I have no time to work on
it much but I thought it might be helpful to chime in.
At this point in time the difference between 80GB and 3GB (as my current 1.5GB
of only outputs would suggest if I had covered the inputs) or even 12GB makes
the difference of being able to store it on a phone, vs. not being able to. 80GB
"compressed" to 3GB is not that bad at all. Unfortunately, with segWit this will
be worse, with the higher transaction count per MB.
Regards,
Leo
[0]
https://www.reddit.com/r/Bitcoin/comments/4v28jl/how_have_fungiblity_problems_affected_you_in/d5ux6aq
[1] https://github.com/Giszmo/TransactionFinder
On 05/11/2016 10:29 PM, Bob McElrath via bitcoin-dev wrote:
> Eerrrr....let me revise that last paragraph. That's 12 *GB* of filters at
> today's block height (at fixed false-positive rate 1e-6. Compared to block
> headers only which are about 33 MB today. So this proposal is not really
> compatible with such a wallet being "light"...
>
> Damn units...
>
> Bob McElrath via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
>> I like this idea, but let's run some numbers...
>>
>> bfd--- via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
>>> A Bloom Filter Digest is deterministically created of every block
>> Bloom filters completely obfuscate the required size of the filter for a desired
>> false-positive rate. But, an optimal filter is linear in the number of elements
>> it contains for fixed false-positive rate, and logarithmic in the false-positive
>> rate. (This comment applies to a RLL encoded Bloom filter Greg mentioned, but
>> that's not the only way) That is for N elements and false positive rate
>> \epsilon:
>>
>> filter size = - N \log_2 \epsilon
>>
>> Given that the data that would be put into this particular filter is *already*
>> hashed, it makes more sense and is faster to use a Cuckoo[1] filter, choosing a
>> fixed false-positive rate, given expected wallet sizes. For Bloom filters,
>> multiply the above formula by 1.44.
>>
>> To prevent light clients from downloading more blocks than necessary, the
>> false-positive rate should be roughly less than 1/(block height). If we take
>> the false positive rate to be 1e-6 for today's block height ~ 410000, this is
>> about 20 bits per element. So for todays block's, this is a 30kb filter, for a
>> 3% increase in block size, if blocks commit to the filter. Thus the required
>> size of the filter commitment is roughly:
>>
>> filter size = N \log_2 H
>>
>> where H is the block height. If bitcoin had these filters from the beginning, a
>> light client today would have to download about 12MB of data in filters. My
>> personal SPV wallet is using 31MB currently. It's not clear this is a bandwidth
>> win, though it's definitely a win for computing load on full nodes.
>>
>>
>> [1] https://www.cs.cmu.edu/~dga/papers/cuckoo-conext2014.pdf
>>
>> --
>> Cheers, Bob McElrath
>>
>> "For every complex problem, there is a solution that is simple, neat, and wrong."
>> -- H. L. Mencken
>>
>>
>>
>> !DSPAM:5733934b206851108912031!
>
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> !DSPAM:5733934b206851108912031!
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and wrong."
> -- H. L. Mencken
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160728/17064a1c/attachment.sig>

2023-06-07 17:34:34

- reply

📅 Original date posted:2015-08-10
📝 Original message:On 08/10/2015 05:39 AM, Thomas Zander via bitcoin-dev wrote:
> On Monday 10. August 2015 07.57.30 Rune K. Svendsen via bitcoin-dev wrote:
>> What Lightning does is raise the value of a transaction on the block chain.
>> Imagine you're a Lightning node, and in order to collect your fees, that
>> you've earned over the past month, you have to settle on the blockchain. If
>> you've earned, say, 0.5 BTC in fees, you can attach a huge 0.005 BTC fee to
>> the Bitcoin settlement transaction. The miners earn a larger fee, and you
>> make sure your transaction gets into the blockchain quickly, and you can
>> afford to pay this fee because you've made much more on the Lightning
>> transactions you've routed.
> I don't buy that argument, you are saying a company will give away profits
> because of... what? It can?
>
> The reason of it being faster makes no sense, as your example the channel has
> been open for a month then he really doesn't care it takes 1, 10 or 50 blocks
> before his transaction is included. What is 5 hours wait on a month of profit?
>
I guess the assumption here is a full-block scenario where users of LN would be
willing to pay 100 times the fees users of crude transactions would be willing
to pay for the same limited space in the blockchain, simply because LN would
group 100 real world payments into 1 crude transaction.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/0fee3843/attachment.sig>

2023-06-07 15:46:32

- reply

2023-06-07 15:43:20

- reply

📅 Original date posted:2015-07-23
📝 Original message:Thank you a lot for doing this test!
Two questions:
1) A node is typically connected to many nodes that would all in parallel
download said block. In your test you measured how fast new blocks that
presumably are being uploaded in parallel to all those other nodes are being
uploaded? Or did you download blocks while those nodes were basically idle?
2) What is your percentage of the very slow connections?
On 07/23/2015 11:19 AM, slurms--- via bitcoin-dev wrote:
> On this day, the Bitcoin network was crawled and reachable nodes surveyed to find their maximum throughput in order to determine if it can safely support a faster block rate. Specifically this is an attempt to prove or disprove the common statement that 1MB blocks were only suitable slower internet connections in 2009 when Bitcoin launched, and that connection speeds have improved to the point of obviously supporting larger blocks.
>
>
> The testing methodology is as follows:
>
> * Nodes were randomly selected from a peers.dat, 5% of the reachable nodes in the network were contacted.
>
> * A random selection of blocks was downloaded from each peer.
>
> * There is some bias towards higher connection speeds, very slow connections (<30KB/s) timed out in order to run the test at a reasonable rate.
>
> * The connecting node was in Amsterdam with a 1GB NIC.
>
>
> Results:
>
> * 37% of connected nodes failed to upload blocks faster than 1MB/s.
>
> * 16% of connected nodes uploaded blocks faster than 10MB/s.
>
> * Raw data, one line per connected node, kilobytes per second http://pastebin.com/raw.php?i=6b4NuiVQ
>
>
> This does not support the theory that the network has the available bandwidth for increased block sizes, as in its current state 37% of nodes would fail to upload a 20MB block to a single peer in under 20 seconds (referencing a number quoted by Gavin). If the bar for suitability is placed at taking only 1% of the block time (6 seconds) to upload one block to one peer, then 69% of the network fails for 20MB blocks. For comparison, only 10% fail this metric for 1MB blocks.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/042b0879/attachment-0001.sig>