Lucas Clemente Vella [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-06-21 to 2018-02-19
💬 Posted a total of 9 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 20:10:58

- reply

📅 Original date posted:2018-02-19
📝 Original message:Theoretically, if the recipient address had already disclosed the
public key (i.e. already spent from that address), or shared it with
you instead of (or alongside with) the address, then you can use
recipient's ECDSA key to encrypt the message with ECC, as both ECDSA
and ECC share the same kind of public/private key pair, according to
the this link: https://crypto.stackexchange.com/questions/14662/using-ecdsa-keys-for-encryption
In practice, I am not sure the nodes would broadcast such non-standard
transaction (but it can be mined, nonetheless).
2018-02-19 6:21 GMT-03:00 Ilan Oh via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org>:
> Hey guys,
>
> Features info,
> I know we can add text to a btc transaction and it is pretty easy,
>
> However is it possible to encrypt the data in a way that only the receiver
> would be able to read it in clear.
> And of course without having to exchange info off the network.
>
> And if not possible on bitcoin would it be possible on a sidechain or on rsk
> or else
>
> I have few ideas of concrete uses of it, I'm sure you guys may also think of
> something interesting,
>
> Thanks,
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Lucas Clemente Vella
lvella at gmail.com

2023-06-07 20:10:18

- reply

📅 Original date posted:2018-01-28
📝 Original message:If the miner wants to force fees up, why would he fill up a block with
placeholder high fee transactions, instead of simply cutting off
transactions paying less fee than he is willing to take? Is there any
evidence someone is doing such a thing for whatever reason?
2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Miners can fill their blocks with transactions paying very high fees at no
> cost because they get the fees back to themselves. They can do this for
> different purposes, like trying to increase the recommended fee. Here I
> propose a backwards-compatible solution to this problem.
>
> The solution would be to reward the fees of the current block to the miner
> of the next block (or X blocks after the current one). That way, if a miner
> floods its own block with very high fee transactions, those fees are no
> longer given back to itself, but to the miner of future blocks which could
> potentially be anyone. Flooding blocks with fake txs is now discouraged.
> However, filling blocks with real transactions paying real fees is still
> encouraged because you could be the one to mine the block that would claim
> this reward.
>
> The way to implement this in a backwards-compatible fashion would be to
> enforce miners to set an anyone-can-spend output in the coinbase
> transaction of the block (by adding this as a rule for verifying new
> blocks). The miner of 100 blocks after the current one can add a secondary
> transaction spending this block's anyone-can-spend coinbase transaction
> (due to the coinbase needing 100 blocks to mature) and thus claiming the
> funds. This way, the block reward of a block X is always transferred to the
> miner of block X+100.
>
> Implementing this would require a soft-fork. Since that secondary
> transaction needs no signature whatsoever, the overhead caused by that
> extra transaction is negligible.
>
> Possible Downside: When the fork is activated, the miners won’t get any
> reward for mining blocks for a period of 100 blocks. They could choose to
> power off the mining equipment for maintenance or to save power over that
> period, so the hashrate could drop temporarily. However, if the hashrate
> drops too much, blocks would take much longer to mine, and miners wouldn’t
> want that either since they want to go through those 100 reward-less blocks
> as soon as possible so they can start getting rewards from mining again.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180128/712c01bf/attachment.html>

2023-06-07 20:08:03

- reply

📅 Original date posted:2017-12-01
📝 Original message:The original altcoin, Namecoin, aimed a building a bitcoin-like, blockchain
based decentralized DNS system. Unfortunately it didn't catch, but it would
be the most logical choice for the name registry database.
2017-11-30 20:20 GMT-02:00 mandar mulherkar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Hello,
>
> I am new, so apologies if this has been asked before.
>
> Here are a few questions to start with -
>
> I was wondering in terms of mass adoption, instead of long wallet
> addresses, maybe there should be a DNS-like decentralized mapping service
> to provide a user at crypto address?
>
> This address translation can happen with confirmations from the network.
> So instead of providing a long string, or a QR code that needs an app, you
> simply type in a human readable address, and the wallet software converts
> it to a wallet address.
>
> Please let me know where I can research this more - if there already is
> literature about this somewhere.
>
> thanks!
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/4f29dac1/attachment.html>

2023-06-07 20:07:03

- reply

📅 Original date posted:2017-10-10
📝 Original message:2017-10-10 11:09 GMT-03:00 Tao Effect via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> When you transfer them back, you get newly minted coins, equivalent to the
> amount you "burned" on the chain you're transferring from — as stated in
> the OP.
>
If you have to change Bitcoin to recognize a transfer from the sidechain
back into Bitcoin, you kill the purpose of the sidechain. You could as well
just change the Bitcoin to implement whatever desirable features the
sidechain would have. The whole idea of sidechains is to keep Bicoin
unchangend, and allow for the voluntary transfer of tokens out of Bitcoin
to the sidechain of your choosing.
--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171010/3979cda4/attachment-0001.html>

2023-06-07 20:06:59

- reply

📅 Original date posted:2017-10-10
📝 Original message:2017-10-09 22:39 GMT-03:00 Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> That is only a one-way peg, not a two-way.
>
> In fact, that is exactly what drivechain does, if one chooses parameters
> for the drivechain that make it impossible for any side-to-main transfer to
> succeed.
>
> One-way pegs have strong first-mover disadvantages.
>
I understand the first-mover disadvantages, but I keep thinking that if the
new chain is Pareto optimal, i.e. is in all aspects at least good as the
original chain, but in some so much better to justify the change, the
initial resistance is an unstable equilibrium. Like a herd of buffaloes
attacking a lion: the first buffalo to attack is in awful disadvantage, but
if a critical mass of the herd follows, the movement succeeds beyond
turning back, and every buffalo benefited, both those who attacked the lion
and those that didn't (because the lion was chased away or killed).
--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171010/533ac1c1/attachment.html>

2023-06-07 20:05:14

- reply

📅 Original date posted:2017-09-01
📝 Original message:> > The current chain is effectively single threaded.
>
> This is not true, since xthin/compactblocks have been introduced we
> completely removed this bottle-neck.
> The transactions will be validated continuously, in parallel and not just
> when a block is found.
>
If I understood correctly, OP was not talking about the process inside a
node being single threaded, but instead that the whole bitcoin distributed
system behaves as single threaded computation. OP seems to be describing a
system closer to what IOTA uses, by distributing among the miners the task
of validating the transactions. Although, without more specific details, it
is hard to judge the benefits.
--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170901/01e7e191/attachment.html>

2023-06-07 20:04:42

- reply

📅 Original date posted:2017-07-21
📝 Original message:2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> [...] But the fact is that if we want to make bitcoins last forever, we
> have the accept unbounded UTXO growth, which is unscalable. So the only
> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
> This proposed solution however does not prevent Bitcoin from lasting
> forever.
>
Unless there is a logical contradiction in this phrasing, the proposed
solution does not improves scalability:
- "Bitcoins lasting forever" implies "unscalable";
- "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
forever";
- Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
In practice, the only Bitcoin lost would be those whose owners forgot about
or has lost the keys, because everyone with a significant amount of
Bitcoins would always shift them around before it loses any luster (I
wouldn't bother to move my Bitcoins every 10 years). I don't know how to
estimate the percentage of UTXO is actually lost/forgotten, but I have the
opinion it isn't worth the hassle.
As a side note, your estimate talks about block size, which is determines
blockchain size, which can be "safely" pruned (if you are not considering
new nodes might want to join the network, in case the full history is
needed to be stored somewhere). But UTXO size, albeit related to the full
blockchain size, is the part that currently can not be safely pruned, so I
don't see the relevance of the analysis.
--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170721/5f4564df/attachment.html>

2023-06-07 20:04:28

- reply

📅 Original date posted:2017-07-13
📝 Original message:2017-07-13 18:58 GMT-03:00 Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> If I understand correctly, my node will accept the incoming tx inputs
> but obviously will not perform any segwit related validation, thus those
> inputs are not fully validated. I don't yet understand how my node
> thinks they are valid at all given that it does not understand P2WPKH
> address format, so either it doesn't need to, or P2WPKH is somehow
> already valid. I know this has all been discussed in the past, so if
> someone can point me towards a document that explains it I'd be happy to
> read that.
>
>From your perspective, the P2WPKH will look like a anyone-can-spend
transaction, thus, valid no matter who is spending. So, you would be
basically leaving the security of segwit transactions to those who actually
are interested in and using them. If your fork becomes popular, it would
decrease the security of Segwit transactions to something akin to the
security model of the Drivechain currently being discussed: only those
particularly interested in that particular sidechain (and segwit witness
could be loosely categorized into a sidechain) will be responsible to
prevent others from stealing funds from the anyone-can-spend transactions.
--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/71992a34/attachment.html>

2023-06-07 20:03:35

- reply

📅 Original date posted:2017-06-21
📝 Original message:Is it too late to propose to freeze Bitcoin protocol as it is today (no
SegWit, no bigger block)?
Hear me out: assume Bitcoin is frozen as it is now: no more forks, no more
change in consensus rules. Call it Bitcoin 1 (BC1). So, how to evolve and
scale Bitcoin?
Use a very conservative sidechain, call it Bitcoin 2 (BC2), tightly
coupled, block per block, with Bitcoin 1 chain. No fancy experimental
changes there: fix the bare minimum to support more general two-way
sidechains, linear scalability transaction verification time and
transaction malleability. Can be one way only if that makes it simple
enough: coins sent to BC2 can never come back to BC1.
Miners choose to mine a BC2 block alongside a BC1 block, and it can be done
for free once a BC1 block is found. There may be BC1 blocks in the chain
whose corresponding BC2 blocks are missing (and that is not a big deal),
but there will be an economic incentive to mine a BC2 block, since
transaction fees on that chain will be collected.
The economic adoption is completely voluntary and independent of anyone
else, doesn't require the strong consensus of SegWit. If it is feasible to
create a simple enough two way sidechain over BC1, good. If not, economic
value of BC1 will always be at least that of BC2, but never lower. BC2 may
have a lower price than BC1 at first, but since it will have every feature
of BC1, plus the possibility of massive scalability and instantaneous
transactions with a lightning network built over BC2 (a practical
economical advantage), it will most likely value over what BC1 could ever
be alone, raising BC1 price with it.
If these predictions are correct, fewer and fewer people will transact BC1,
eventually with blocks mined empty except for the coinbase, which the miner
may choose to send directly to BC2. If I turn out to be wrong, and people
prefer to stick to the old BC1 for some reason, BC2 becomes just another
speculative altcoin. Thus, everyone migrating should be fully conscious
about the risk of immediate devaluation.
The 2 major risks I see that could hamper the adoption are:
- Just plain fear: I find the whole economical incentive scenario of BC2
sound and plausible, just as I found Bitcoin sound and plausible when I
heard about it for the first time. I also fear to put my money in BC2, just
as I did when I heard about Bitcoin. BC2 case is even worse, because I can
safely hold my coins in BC1 until I am sure BC2 is solid, so at first we
may experience only enthusiast adoption;
- Technological inertia: everyone wishing to accept BC2 will have to
implement this payment system as for any other altcoin. Every exchange
supporting both will have to create separated markets for BC1 and BC2.
Remember: both chains must be obviously distinguishable. It is even
desirable that the address format in BC2 to be incompatible with BC1 (maybe
staring with "2" ?).
Finally, due to the present state of affairs, with impending activation of
segwit with a promise to hardfork in 3 months, I believe this proposal is
too late, not to mention the stress, emotions and hard feelings of the
situation will make it go largely ill received or ignored. But since I
genuinely believe this to be the best and most conservative way to go with
Bitcoin, I wrote this anyway.
Please forgive me if something like this was discussed a thousand times
before and you wasted your time reading this.
--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170621/d52291ac/attachment.html>