Leandro Coutinho [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-02-25 to 2017-08-27
💬 Posted a total of 5 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:05:01

- reply

📅 Original date posted:2017-08-27
📝 Original message:>>> 5) The problem with node pruning is that it is not standardized, and
for a new node to enter the network and to verify the data, it needs to
download all data and prune it by itself. This will drastically lower the
information needed by the full nodes by getting rid of the junk. Currently
we are around 140GB, that number is getting bigger exponentially, by the
number of users and transactions created. It could reach a Terrabyte sooner
than expected, we need to act now.
To have to download all blockchain for then prune is a big drawback.
So I thought about the concept of "trusted" nodes, where you could choose
some nodes to connect and from which block you want to download. Of course
they would do this by their own risk, but there are ways to minimize the
risk, like:
- check the latest blocks (hashes) if they match what you find in some
sites, like blockchain.info
- download and compare the utxo from all (some) the nodes you are
connected
Currently utxo size is around 2GB and we cant know how fast it will grow (?)
Em 26/08/2017 19:39, "Adam Tamir Shem-Tov via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> escreveu:
Thank you Thomas for your response.
1) Implement solution is impossible... I have given a solution in part II.
By adding a Genesis Account which will be the new sender.
2)Keeping older blocks: Yes as I said 10 older blocks should be kept, that
should suffice. I am not locked on that number, if you think there is a
reason to keep more than that, it is open to debate.
3) Why 1000? To be honest, that number came off the top of my head. These
are minor details, the concept must first be accepted, then we can work on
the minor details.
4)Finally it's not just the addresses and balance you need to save... I
think the Idea of the Genesis Account, solves this issue.
5) The problem with node pruning is that it is not standardized, and for a
new node to enter the network and to verify the data, it needs to download
all data and prune it by itself. This will drastically lower the
information needed by the full nodes by getting rid of the junk. Currently
we are around 140GB, that number is getting bigger exponentially, by the
number of users and transactions created. It could reach a Terrabyte sooner
than expected, we need to act now.
On your second email:
When I say account: I mean private-public key.
The way bitcoin works, as I understand it, is that the funds are verified
by showing that they have an origin, this "origin" needs to provide a
signature, otherwise the transaction won't be accepted.
If I am proposing to remove all intermediate origins, then the funds become
untraceable and hence unverifiable. To fix that, a new transaction needs to
replace old ones. A simplified version: If there was a transaction chain
A->B->C->D, and I wish to show only A->D, only a transaction like that
never actually occurred, it would be impossible to say that it did without
having A's private key, in order to sign this transaction. In order to
create this transaction, I need A's private key. And if I wish this to be
publicly implemented I need this key to be public, so that any node
creating this Exodus Block can sign with it. Hence the Genesis Account. And
yes, it is not really an account.
On 27 August 2017 at 00:31, Thomas Guyot-Sionnest <dermoth at aei.ca> wrote:
> Pruning is already implemented in the nodes... Once enabled only unspent
> inputs and most recent blocks are kept. IIRC there was also a proposal to
> include UTXO in some blocks for SPV clients to use, but that would be
> additional to the blockchain data.
>
> Implementing your solution is impossible because there is no way to
> determine authenticity of the blockchain mid way. The proof that a block
> hash leads to the genesis block is also a proof of all the work that's been
> spent on it (the years of hashing). At the very least we'd have to keep all
> blocks until a hard-coded checkpoint in the code, which also means that as
> nodes upgrades and prune more blocks older nodes will have difficulty
> syncing the blockchain.
>
> Finally it's not just the addresses and balance you need to save, but also
> each unspent output block number, tx position and script that are required
> for validation on input. That's a lot of data that you're suggesting to
> save every 1000 blocks (and why 1000?), and as said earlier it doesn't even
> guarantee you can drop older blocks. I'm not even going into the details of
> making it work (hard fork, large block sync/verification issues, possible
> attack vectors opened by this...)
>
> What is wrong with the current implementation of node pruning that you are
> trying to solve?
>
> --
> Thomas
>
> On 26/08/17 03:21 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote:
>
> Solving the Scalability issue for bitcoin 
>
> I have this idea to solve the scalability problem I wish to make public.
>
> If I am wrong I hope to be corrected, and if I am right we will all gain
> by it. 
>
> Currently each block is being hashed, and in its contents are the hash of
> the block preceding it, this goes back to the genesis block.
>
> 
>
> What if we decide, for example, we decide to combine and prune the
> blockchain in its entirety every 999 blocks to one block (Genesis block not
> included in count).
>
> 
>
> How would this work?: Once block 1000 has been created, the network would
> be waiting for a special "pruned block", and until this block was created
> and verified, block 1001 would not be accepted by any nodes.
>
> This pruned block would prune everything from block 2 to block 1000,
> leaving only the genesis block. Blocks 2 through 1000, would be calculated,
> to create a summed up transaction of all transactions which occurred in
> these 999 blocks.
>
> 
>
> And its hash pointer would be the Genesis block.
>
> This block would now be verified by the full nodes, which if accepted
> would then be willing to accept a new block (block 1001, not including the
> pruned block in the count).
>
> 
>
> The new block 1001, would use as its hash pointer the pruned block as its
> reference. And the count would begin again to the next 1000. The next
> pruned block would be created, its hash pointer will be referenced to the
> Genesis Block. And so on..
>
> 
>
> In this way the ledger will always be a maximum of 1000 blocks.
>
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170827/fbd32ac1/attachment-0001.html>

2023-06-07 18:00:20

- reply

📅 Original date posted:2017-04-21
📝 Original message:Maybe it already exists ...
#9484 <https://github.com/bitcoin/bitcoin/pull/9484> 812714f
<https://github.com/bitcoin/bitcoin/commit/812714f> Introduce assumevalid
setting to skip validation presumed valid scripts (gmaxwell)
https://github.com/bitcoin/bitcoin/pull/9484
..., but ...
It would be very interesting if a new node could decide to be a pruned node:
- it would need to trust one or more peers for the initial blockchain
download, because the blocks downloaded would not be validated
- it would decide a time from when to get the blocks, like a week before
- once a day a routine would run that would prune blocks older than the
chosen time
"
*The unspent transaction outputs (which is the only essential piece ofdata
necessary for validation) are already kept in a separate database,so
technically removing old blocks is perfectly possible.*" Pieter Wuille
https://bitcoin.stackexchange.com/questions/11170/why-is-pruning-not-considered-already-at-the-moment
On Fri, Apr 21, 2017 at 10:35 AM, David Kaufman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Danny,
>
> On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe wrote:
> >
> > 1TB HDD is now available for under $40 USD. How is the 100GB storage
> > requirement preventing anyone from setting up full nodes?
>
> Yeah, but that's because most people (well, using myself as the
> "target market" anyway) are upgrading to SSD's for the faster boot and
> response times. Modern consumer OS's run incredibly slow on
> non-ssd drives! And since the vast majority of consumer laptops sold
> today fall into the $400 to $700 range, a 200 - 500gb SSD is about the
> most storage upgrade people can afford.
>
> And so I think David's premise, that having to devote only 30GB to
> running a full node instead of 100, would remove a major obstacle that
> prevents many more people running full bitcoin nodes.
>
> My only suggestion is, does it scale? I mean, if the bitcoin network
> volume grows exponentially and in 2 years the blockchain is 500GB, can
> the "small node" be adjusted down from one fifth of the blockchain to
> just one-tenth, or one twentieth? Can different smalInesses
> interoperate? Can I choose to store a small node with 20 - 30% of the
> blockchain, while others chose to share just 5% or 10% of it? Can I run
> "less small" node today that's 50GB?
>
> Can the default install be a "small node" that requires about 30GB of
> storage (if that is indeed the sweet spot for enticing many more users to
> bringing nodes online), but allow the user at install time, to choose *how*
> small? To, say, drag a slider anywhere up and down the range from
> 10GB to 100GB?
>
> If not, then it will have to be revisited constantly as the blockchain
> grows, and disk storage prices drop. I suspect the blockchain will
> grow in size, at some point in the not too distant future, much faster
> than storage prices drop, so making small, smaller and smallest nodes
> that can be configured to store more or less of it will be necessary
> to motivate most users to run nodes at all. But when that happens,
> there is likely to be exponentially *more* people using bitcoin, too!
> So an exponentially growing number of users running (smaller and
> smaller) nodes would take up the slack.
>
> Then, the blockchain would begin to look a lot more like a bittorrent,
> right? ;-) but -- happily -- one that you never need to download fully.
>
> -dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170421/a959f172/attachment.html>

2023-06-07 17:58:43

- reply

📅 Original date posted:2017-04-01
📝 Original message:One interesting thing to do is to compare how much does it cost to maintain
a bank check account and how much does it cost to run a full node.
It seems that it is about 120USD/year in USA:
http://m.huffpost.com/us/entry/6219730
A 4TB hard drive ~=115USD
https://www.amazon.com/gp/aw/d/B01LQQH86A/ref=mp_s_a_1_4
And it has a warranty of 3 years.
As your calculation shows, it will take more than 19 years to reach 4TB
with a 4MB blocksize.
Em 29/03/2017 12:35, "Johnson Lau via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> escreveu:
On 29 Mar 2017, at 14:24, Emin Gün Sirer via bitcoin-dev <bitcoin-dev at lists.
linuxfoundation.org> wrote:
>Even when several of the experts involved in the document you refer has my
respect and admiration, I do not agree with some of their conclusions
I'm one of the co-authors of that study. I'd be the first to agree with
your conclusion
and argue that the 4MB size suggested in that paper should not be used
without
compensation for two important changes to the network.
Our recent measurements of the Bitcoin P2P network show that network speeds
have improved tremendously. From February 2016 to February 2017, the average
provisioned bandwidth of a reachable Bitcoin node went up by approximately
70%.
And that's just in the last year.
4 * 144 * 30 = 17.3GB per month, or 207GB per year. Full node
initialisation will become prohibitive for most users until a shortcut is
made (e.g. witness pruning and UTXO commitment but these are not trust-free)
Further, the emergence of high-speed block relay networks, like Falcon (
http://www.falcon-net.org)
and FIBRE, as well as block compression, e.g. BIP152 and xthin, change the
picture dramatically.
Also as the co-author of the selfish mining paper, you should know all
these technology assume big miners being benevolent.
So, the 4MB limit mentioned in our paper should not be used as a protocol
limit today.
Best,
- egs
On Tue, Mar 28, 2017 at 3:36 PM, Juan Garavaglia via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Alphonse,
>
>
>
> Even when several of the experts involved in the document you refer has my
> respect and admiration, I do not agree with some of their conclusions some
> of their estimations are not accurate other changed like Bootstrap Time,
> Cost per Confirmed Transaction they consider a network of 450,000,00 GH and
> today is 3.594.236.966 GH, the energy consumption per GH is old, the cost
> of electricity is wrong even when the document was made and is hard to find
> any parameter used that is valid for an analysis today.
>
>
>
> Again with all respect to the experts involved in that analysis is not
> valid today.
>
>
>
> I tend to believe more in Moore’s law, Butters' Law of Photonics and
> Kryder’s Law all has been verified for many years and support that 32 MB in
> 2020 are possible and equals or less than 1 MB in 2010.
>
>
>
> Again may be is not possible Johnson Lau and LukeJr invested a significant
> amount of time investigating ways to do a safe HF, and may be not possible
> to do a safe HF today but from processing power, bandwidth and storage is
> totally valid and Wang Chung proposal has solid grounds.
>
>
>
> Regards
>
>
>
> Juan
>
>
>
>
>
> *From:* Alphonse Pace [mailto:alp.bitcoin at gmail.com]
> *Sent:* Tuesday, March 28, 2017 2:53 PM
> *To:* Juan Garavaglia <jg at 112bit.com>; Wang Chun <1240902 at gmail.com>
> *Cc:* Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>
> *Subject:* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>
>
>
> Juan,
>
>
>
> I suggest you take a look at this paper: http://fc16.ifca.ai/bit
> coin/papers/CDE+16.pdf It may help you form opinions based in science
> rather than what appears to be nothing more than a hunch. It shows that
> even 4MB is unsafe. SegWit provides up to this limit.
>
>
>
> 8MB is most definitely not safe today.
>
>
>
> Whether it is unsafe or impossible is the topic, since Wang Chun proposed
> making the block size limit 32MiB.
>
>
>
>
>
> Wang Chun,
>
>
> Can you specify what meeting you are talking about? You seem to have not
> replied on that point. Who were the participants and what was the purpose
> of this meeting?
>
>
>
> -Alphonse
>
>
>
> On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia <jg at 112bit.com> wrote:
>
> Alphonse,
>
>
>
> In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and
> 32MB limit valid in next halving, from network, storage and CPU perspective
> or 1MB was too high in 2010 what is possible or 1MB is to low today.
>
>
>
> If is unsafe or impossible to raise the blocksize is a different topic.
>
>
>
> Regards
>
>
>
> Juan
>
>
>
>
>
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:
> bitcoin-dev-bounces at lists.linuxfoundation.org] *On Behalf Of *Alphonse
> Pace via bitcoin-dev
> *Sent:* Tuesday, March 28, 2017 2:24 PM
> *To:* Wang Chun <1240902 at gmail.com>; Bitcoin Protocol Discussion <
> bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>
>
>
> What meeting are you referring to? Who were the participants?
>
>
>
> Removing the limit but relying on the p2p protocol is not really a true
> 32MiB limit, but a limit of whatever transport methods provide. This can
> lead to differing consensus if alternative layers for relaying are used.
> What you seem to be asking for is an unbound block size (or at least
> determined by whatever miners produce). This has the possibility (and even
> likelihood) of removing many participants from the network, including many
> small miners.
>
>
>
> 32MB in less than 3 years also appears to be far beyond limits of safety
> which are known to exist far sooner, and we cannot expect hardware and
> networking layers to improve by those amounts in that time.
>
>
>
> It also seems like it would be much better to wait until SegWit activates
> in order to truly measure the effects on the network from this increased
> capacity before committing to any additional increases.
>
>
>
> -Alphonse
>
>
>
>
>
>
>
> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I've proposed this hard fork approach last year in Hong Kong Consensus
> but immediately rejected by coredevs at that meeting, after more than
> one year it seems that lots of people haven't heard of it. So I would
> post this here again for comment.
>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>
> Despite spam tx on the network, the block capacity is approaching its
> limit, and we must think ahead. Shall we code a patch right now, to
> remove the block size limit of 1MB, but not activate it until far in
> the future. I would propose to remove the 1MB limit at the next block
> halving in spring 2020, only limit the block size to 32MiB which is
> the maximum size the current p2p protocol allows. This patch must be
> in the immediate next release of Bitcoin Core.
>
> With this patch in core's next release, Bitcoin works just as before,
> no fork will ever occur, until spring 2020. But everyone knows there
> will be a fork scheduled. Third party services, libraries, wallets and
> exchanges will have enough time to prepare for it over the next three
> years.
>
> We don't yet have an agreement on how to increase the block size
> limit. There have been many proposals over the past years, like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> on. These hard fork proposals, with this patch already in Core's
> release, they all become soft fork. We'll have enough time to discuss
> all these proposals and decide which one to go. Take an example, if we
> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
> from 32MiB to 2MB will be a soft fork.
>
> Anyway, we must code something right now, before it becomes too late.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/f0a4a59e/attachment-0001.html>

2023-06-07 17:56:46

- reply

📅 Original date posted:2017-02-25
📝 Original message:If people split their bitcoins in multiple addresses, then maybe there
would be no need to worry(?), because the computational cost would be
higher than what the attacker would get.
>From Google:
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
*Here are some numbers that give a sense of how large scale this
computation was: *
- *Nine quintillion (9,223,372,036,854,775,808) SHA1 computations in
total*
- *6,500 years of CPU computation to complete the attack first phase*
- *110 years of GPU computation to complete the second phase*
https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
Richest address: 124,178 BTC ($142,853,079 USD)
On Sat, Feb 25, 2017 at 6:40 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Feb 25, 2017 at 03:34:33PM -0600, Steve Davis wrote:
> > Yea, well. I don’t think it is ethical to post instructions without an
> associated remediation (BIP) if you don’t see the potential attack.
>
> I can't agree with you at all there: we're still at the point where the
> computational costs of such attacks limit their real-world impact, which is
> exactly when you want the *maximum* exposure to what they are and what the
> risks are, so that people develop mitigations.
>
> Keeping details secret tends to keep the attacks out of public view, which
> might be a good trade-off in a situation where the attacks are immediately
> practical and the need to deploy a fix is well understood. But we're in the
> exact opposite situation.
>
> > I was rather hoping that we could have a fuller discussion of what the
> best practical response would be to such an issue?
>
> Deploying segwit's 256-bit digests is a response that's already fully
> coded and
> ready to deploy, with the one exception of a new address format. That
> address
> format is being actively worked on, and could be deployed relatively
> quickly if
> needed.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/3c3e4b53/attachment.html>

2023-06-07 17:56:41

- reply

📅 Original date posted:2017-02-25
📝 Original message:Google recommeds "migrate to safer cryptographic hashes such as SHA-256 and
SHA-3"
It does not mention RIPEMD-160
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1
Em 25/02/2017 10:47, "Steve Davis via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> escreveu:
> On Feb 24, 2017, at 7:01 PM, Peter Todd <pete at petertodd.org> wrote:
>
> On Fri, Feb 24, 2017 at 05:49:36PM -0600, Steve Davis via bitcoin-dev
wrote:
>> If the 20 byte SHA1 is now considered insecure (with good reason), what
about RIPEMD-160 which is the foundation of Bitcoin addresses?
>
> SHA1 is insecure because the SHA1 algorithm is insecure, not because
160bits isn't enough.
>
> AFAIK there aren't any known weaknesses in RIPEMD160,
…so far. I wonder how long that vacation will last?
> but it also hasn't been
> as closely studied as more common hash algorithms.
...but we can be sure that it will be, since the dollar value held in
existing utxos continues to increase...
> That said, Bitcoin uses
> RIPEMD160(SHA256(msg)), which may make creating collisions harder if an
attack
> is found than if it used RIPEMD160 alone.
Does that offer any greater protection? That’s not so clear to me as the
outputs (at least for p2pkh) only verify the public key against the final
20 byte hash. Specifically, in the first (notional) case the challenge
would be to find a private key that has a public key that hashes to the
final hash. In the second (realistic) case, you merely need to add the
sha256 hash into the problem, which doesn’t seem to me to increase the
difficulty by any significant amount?
/s
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/30468d23/attachment.html>