Oscar Lafarga [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 23:01:41

- reply

📅 Original date posted:2021-12-23
📝 Original message:>
> None of this particularly requires CTV, but it does require the type of
> composable and flexible software that I aspire to deliver with Sapio.
Does this imply that there is some kind of Sapio client to be run
alongside a Bitcoin full node similar to how a Lightning node would
operate? If so, are the computation, bandwidth, and liveness requirements
for someone running Sapio contracts more or less comparable to Lightning?
The implementation approach seems pretty interesting overall and reminds me
of concepts like bitcoin bug bounties (https://bitcoinacks.com/ for
example) but perhaps with the potential for more sophisticated
functionality.
Will try to take a closer look at the https://github.com/sapio-lang/sapio
if that seems like a recommended starting point.
Thanks!
On Wed, Dec 22, 2021 at 10:47 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Devs,
>
> Enjoy! https://rubin.io/bitcoin/2021/12/22/advent-25/
>
> I'm really excited about opportunities for capital formation to happen
> natively in Bitcoin. This is actually a really big deal and something (I
> think) to pay close attention to. This is basically like running a little
> company with shareholders inside of Bitcoin, which to me really helps us
> inhabit the "be your own bank" part of Bitcoin. None of this particularly
> requires CTV, but it does require the type of composable and flexible
> software that I aspire to deliver with Sapio.
>
> business matter:
>
> There are two more posts, and they will both be focused on getting this
> stuff out into the wild more. If you particularly have thoughts on BIP-119
> activation I would love to hear them publicly, or at your preference,
> privately.
>
> If you like or dislike BIP-119 and wish to "soft-signal" yes or no
> publicly, you may do so on https://utxos.org/signals by editing the
> appropriate file(s) and making a PR. Alternatively, comment somewhere
> publicly I can link to, send it to me, and I will make the edits.
>
> edit links:
> - for individuals/devs:
> https://github.com/JeremyRubin/utxos.org/edit/master/data/devs.yaml
> - organizations:
> https://github.com/JeremyRubin/utxos.org/edit/master/data/bizs.yaml
> - miners/pools:
> https://github.com/JeremyRubin/utxos.org/edit/master/data/hashratesnapshot.json
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Oscar Lafarga
https://www.setlife.network
<https://www.setdev.io/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211223/1e853899/attachment-0001.html>

2023-06-07 23:01:41

- reply

2023-06-07 18:21:47

- reply

📅 Original date posted:2019-11-23
📝 Original message:Hi MK,
I very much share your interests and curiosities here and actually don't
have an answer on whether it's been tried before.
One of the few things I am imagining is that given the security-focused
nature of the Bitcoin Core software, any vulnerabilities in the way NPM
handles the dependencies of the Electron app would be a very high priority
(see https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)
In NodeJS-land, my sense is that there is a "move fast and break things"
mentality that may have seeped into some practices that may be considered
standard. I have seen some recent developments over the past few years to
address these kinds of issues such as npm-audit (as of Node v6+) but I
would recommend doing some thorough research on this front to make sure
there is a secure dependency management solution in place for such a GUI.
Another comment I'd make is that if we consider the GUI as a layer that is
separate from the protocol layer, this mailing list may not be the best
place to fully discuss this. However I think if anyone here who has been
around longer can contribute info on past attempts at this, it could be
quite productive. This could technically exist as an independent client,
but I guess there's a conversation on whether this new Electron UI would
ever replace the Qt UI, but since it doesn't exist yet it could be far too
early for that.
Thanks,
On Sat, Nov 23, 2019, 2:17 PM M.K. Safi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I’d like to try to rebuild Bitcoin Core GUI using the JavaScript Electron
> framework. My goal is to get a real world understanding of the pros and
> cons of moving from Qt to Electron.
>
> Before I start, I‘d like to know if this has been tried before or if there
> are ongoing efforts in this direction by anyone?
>
> I spent sometime looking into how to implement this. One approach could be
> for Electron to drive the UI by running bitcoind and communicating with it
> through RPC. But I don’t know if such implementation can achieve
> feature-parity with the Qt implementation. Qt has the advantage of direct
> access to Bitcoin Core code.
>
> Anyways, I just wanted to share these ideas before going further with
> them, so please let me know if you have any information on the above!
> --
> Sent from my iPhone
> _______________________________________________
> 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/20191123/9e503a84/attachment-0001.html>

2023-06-07 18:21:47

- reply

2023-06-07 18:19:18

- reply

📅 Original date posted:2019-07-16
📝 Original message:Hi Kenshiro,
I don't think your proposal would require any changes to the Bitcoin Core
implementation. This system you describe seems like it would operate as an
independent addition, rather than an alternative to the Proof of Work
consensus code that runs within Bitcoin now. It introduces security risk in
the selection of block explorer and to the Bitcoin Core release dispatch
system, reducing the trustlessness of the current network. Also, without
the constraints that PoW places on block creation, you increase the vector
space for attacks since it is trivial to spam blocks to node on the network
(see Sybil attack <https://en.wikipedia.org/wiki/Sybil_attack#>).
I believe many other software projects have tried similar checkpointing
schemes that have resulted in hard forks or overall weakened consensus. I
haven't dug too deeply, but I'm not aware of any cases where these schemes
accomplish anything useful to improve the bitcoin network.
Best,
On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
>
> After studying several Proof of Stake implementations I think it's not
> only an eco-friendly (and more ethical) alternative to Proof of Work, but
> correctly implemented could be 100% secure against all 51% history rewrite
> attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra
> improvements are required:
>
>
> - Hardcoded checkpoints: each Bitcoin Core release (each few months)
> should include a hardcoded checkpoint with the hash of the current block
> height in that moment. This simple measure protects the blockchain up to
> the last checkpoint, and prevents any Long-Range attack.
>
>
> - Moving checkpoints: the nodes only allow chain reorgs not deeper than N
> blocks. If N is 10 blocks, then the nodes ignore any hard fork starting at
> any block under nodeBlockHeight - N. This fully protects nodes that are
> online and updated. Nodes that are not fully updated need some extra rule
> to be protected between the last hardcoded checkpoint and the current
> blockchain height. This extra rule could be connecting to a block explorer
> to download the hash of the current block height, or ask some trusted
> source like a friend and enter the hash manually. After being fully
> updated, the user can always check that he is in the correct chain checking
> with a block explorer.
>
>
> Someone could have 99% of the coins and still would be unable to use the
> coins to do any history rewrite attack. The attacker could only slow down
> the network not creating his blocks, or censor transactions in his blocks.
>
>
> What do you think? :)
>
>
> Regards
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Oscar Lafarga
https://www.setlife.network
<https://www.setdev.io/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190716/121a4dae/attachment-0001.html>

2023-06-07 18:19:18

- reply