Satellite

612 days ago•••

🔖 Title: Announcing Libforesta 🏷️ Categories: bitcoin-dev naddr1qqjrqv3cvcckxetz943rzdfe956xzvmy95uryvrz95ckze338pjrvephxsexxqg5waehxw309aex2mrp0yhxgctdw4eju6t0qy2hwumn8ghj7etyv4hzumn0wd68ytnvv9hxgqguwaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6q3q2llycjh8gg2lhy4aph9c5au8ch5s0km5axrlxrc6e24dnsaqyu0sxpqqqp65w5dnjql ⚠️ Heads up! We've now started linking to replaceable long-form events (NIP-23), which allow for dynamic display of thread details like summaries, authors, and more. If you're unable to see this, your client may not support this feature yet.

612 days ago•••

📅 Original date posted:2023-08-01 🗒️ Summary of this message: Libfloresta is a compact, low-power Bitcoin full node for end users, written in Rust and compatible with low-power devices. It uses libbitcoinconsensus for consensus and is available on GitHub. 📝 Original message: Am i correct in the following interpretations?

- the utreexo bridge peers are the only real bitcoin nodes

- you cant use -only- libfloresta to be a node , you cant mine with it, you cant do normal tx with it

- you are targetting webbrowsers (???? , i'm really confused about the why of this)

On Mon, Jul 31, 2023 at 9:11 PM Davidson Souza via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote:

Hi, list. My name is Davidson, and I’m thrilled to share libfloresta with the Bitcoin devs mailing list!

This is a derivate of a project I’ve been developing for a few months, called Floresta (Portuguese for forest). An Utreexo powered, Fully-Validating Bitcoin Full node with integrated watch-only wallet and Electrum Server, meant to be a compact, simple, and ready to use full node for end users.

After some feedbacks and thoughts, I’ve decided to turn it into a series of reusable libs that can be used in other applications in a straightforward way. The main goal here is low-power devices, like SBC and smartphones, but can be used in any environment. To achieve that, I’m writing the main logic in Rust and will generate bindings to the original code and compiling to WASM, allowing it to run virtually anywhere.

The project is in an early stage, but I’m using it on signet for a while now with no problems. Mainnet support is almost ready, but we need to solve some performance issues with bridge nodes and set some up, so you can have utreexo peers.

The project is available on my GitHub and I wrote an initial blogpost explaining how to use it (in Rust). I’ll write more as the project matures, and I get it running on other platforms. Any feedback is welcome!

Consensus

I know that alternative implementations is a spicy subject in Bitcoin land, but this project does not reimplement the Bitcoin Consensus machine from scratch. I’m using libbitcoinconsenus and plan to use the full libbitcoinkernel in the future. While this doesn’t guarantee consistency, it minimizes misimplementations leading to splits.

I’m also making an extra effort into cross-test against Bitcoin Core to find any inconsistencies before it causes any trouble.

Acknowledges

A special thanks to Vinteum for supporting my work with utreexo and Floresta.

Best regards, Davidson Souza.

---

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/20230801/d3e4d737/attachment-0001.html

668 days ago•••

🔖 Title: Fwd: Wallet Lock, Unlock BIP idea 🏷️ Categories: bitcoin-dev 👥 Authors: • Bastiaan van den Berg ( @Bastiaan van den Berg [ARCHIVE] ) • Scott Morgan ( @Scott Morgan [ARCHIVE] ) 📅 Messages Date Range: 2016-01-13 to 2016-01-14 ✉️ Message Count: 3 📚 Total Characters in Messages: 5385

668 days ago•••

📅 Original date posted:2016-01-13 📝 Original message:Hi All,

Here is a suggestion which is similar to bip-0065, but slightly different. In a nutshell I under stand bip-0065 to do this; Create a transaction adding a lock time, that the recipient user must wait before they can spend the coins.

My proposal is to do this; Create an entry in the blocks to lock entire wallet addresses indefinitely, with a specified unlock period. Later on create / modify an entry in the blocks to acknowledge the wallet is being unlocked. Remove the lock on the wallet after the unlock period has transpired.

I think it is technically feasible since many wallet addresses are in each block at the transaction level. However, it would have huge implications to the entire Bitcion ecosystem, so it would probably need a start date at least a year in the future after it was developed.

bip-0065 would not allow the following; This would allow users holding coins for long periods to monitor the blockchain to see if someone else is unlocking their wallets (which may have been stolen/copied etc), giving them some time to react to a intrusion. Perhaps there should also be a re-lock (during unlock) feature.

My original message is attached.

Cheers, Scott

---------- Forwarded message ---------- From: Scott Morgan Date: Tue, Jan 12, 2016 at 3:35 PM Subject: Wallet Lock, Unlock BIP idea To: bitcoin-dev at lists.linuxfoundation.org

Hi All,

It seems to me that one of the large issues with bitcoin is that they can be stolen like cash. This issue also culminates with the fact that most miners probably need to hold their coins for some time to be profitable due to the large interest in mining. I think it may be possible to reduce some of this theft by adding a BIP to lock and unlock wallets. Here is the basic idea (probably with some holes);

1) Users could 'lock' their wallet specifying a unlock period (i.e. 15 days) The information that a particular wallet is locked would get added to the blocks and confirmed like other transactions. 2) During transaction creation and mining (to be sure a locked wallet isn't drained) the top blocks would be checked to see if the wallet is locked. Locked wallet transactions would not be confirmed. 3) Users would eventually 'unlock' their wallet. This would put a unlocking as of date time in the blocks to specify a wallet is unlocking. Eventually the wallet would not have any lock or unlocking entries in the blocks. 4) The users would wait the unlock period (i.e. 15 days) 5) The Users could then spend their coins.

This would also have some other consequences on the bitcoin system, since anyone could check the transactions to locked wallets to see how many BTC are being held, or are being unlocked soon. This could effect the price of BTC in fiat as supply would change similar to the way mining changes it. Also it will slow transaction creation a little and mining a fair amount. Also locking a wallet might incur a fee.

What are your thoughts, does this idea qualify for a BIP? If so, I would appreciate it if someone takes it and runs with it.

Cheers, Scott

PS A bit about me, I am a Privacy and Java evangelist, so I will not be doing any work on the main bitcoin core. I have been doing a little mining to attempt to help fund my companies (Adligo Inc) open source Java projects Tests4j and Fabricate and hopefully in the future Taxi, Sanctum and Intelligence4j.

Donations are always welcome;

http://www.plumfund.com/crowdfunding/adligoorg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160113/08c2eb43/attachment.html

668 days ago•••

📅 Original date posted:2016-01-14 📝 Original message:You might not be aware, but the wallet supports encrypting. Which then means that when Mr Badguy steals your wallet.dat, he cannot do anything with it without the passphrase. See RPC calls 'encryptwallet' 'walletpassphrase' and 'walletlock'.

Also i'd like to say, that adding a big waving flag in the blockchain to say you are locking/unlocking your wallet might not match good privacy ethics ;)

buZz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160114/1d659519/attachment.html

668 days ago•••

📅 Original date posted:2016-01-14 📝 Original message:Hi Again (buZz),

I am aware of wallet encryption, even if encryptwallet was NOT there you could always copy wallet.dat and use a third party encryption /decryption tool. Also any encryption can be broken, although this may not be profitable. I know a few people who still have problems with intruders taking copper pipe out of buildings in Chicago, which is also unprofitable since commodity prices have crashed. Your right that a big waving flag in the block chain may be a bad idea, I figured there would be a good way to obsfucate the information through some one way encryption. Then anyone could check if wallet '1ABC...' is locked by encrypting the wallet address and comparing it to a list of encrypted wallet addresses, but couldn't easily obtain a list of locked or unlocking wallets. I haven't done any detailed work on implementation though, as I mentioned.

Cheers, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160114/750ce265/attachment.html

hurricanewarn1 at aol.com [ARCHIVE]

668 days ago•••

🔖 Title: AT&T/ISPs making Bitcoin Core near impossible to use as a full node via hidden private dynamic IPs, not by specifically blocking 8333 or Bitcoin as stated in original email 🏷️ Categories: bitcoin-dev 👥 Authors: • Bastiaan van den Berg ( @Bastiaan van den Berg [ARCHIVE] ) • hurricanewarn1 at aol.com ( @hurricanewarn1 at aol.com [ARCHIVE] ) 📅 Messages Date: 2015-09-04 ✉️ Message Count: 2 📚 Total Characters in Messages: 3881

668 days ago•••

📅 Original date posted:2015-09-04 📝 Original message:I sent out an email after 48 hours of dealing with trying to open up my ports for Bitcoin, I was quite frustrated and angry since I had to call like 10 times and I was making zero progress. Most of the AT&T people didn't give me any helpful clues on how to fix the situation. The original email described how there is a firewall in the DVR, and I thought it was blocking the ports. It is true there is a uncontrollable firewall in the DVR, it is false this blocks 8333.

The actual problem is due to AT&T Uverse customers being forced to use a private dynamic IP, the IP is literally hidden from the internet, so it isn't possible to send any requests at it. It will literally ignore pings across all ports. So the solution is to switch to public static IP and make sure you allow incoming traffic.

It's not so simple though, AT&T will not let you have a public static IP without paying. I've had my router reset 10 times today by AT&T (probably automatically) and it comes back with a private dynamic IP. Then I have to reset it to use public IP and that lasts less than an hour. It literally went from open to closed while typing this email... the IP address went from public to private dynamic.

https://i.gyazo.com/3c732687fc3d21acb7d62f6d0e23a346.png

This is making using Bitcoin Core almost impossible. I'm at least getting some synch now but maybe a few days of blocks the entire day, cause I can't sit here all day with the computer and keep fixing it.

The proof is in the pudding, there are 37 nodes using AT&T in the ENTIRE world. AT&T is a massive ISP so this is strong evidence that using Bitcoin Core as a full node on AT&T is extremely difficult and actually just about impossible.

https://i.gyazo.com/90beebe056f5fc338165e8d200536c06.png

The other big ISPs have pathetic numbers also due to the same sort've things that AT&T does, but at least Comcast has 400 nodes. AT&T is much harder to use than any other ISP I've dealt with when it comes to Bitcoin Core.

I apologize for sending out the wrong info the first time, although it is still worth noting the DVR firewall is out of your control, which might be a problem if not now then in the future. In any case AT&T has effectively blocked full nodes for Bitcoin Core via the private subnet, and the disability to change it to public without paying $15 more per month, and buying a $15 connection service so they will give you that info (if you dont pay the connection 'specialists' hang up on you).

It is important to note this is not Bitcoin specific, but effects every program that depends on freely open ports. I don't think AT&T has anything against Bitcoin, it's just their security settings and policies have disabled Bitcoin Core for most customers. Also important to note this isn't a problem specific to AT&T, all the big ISPs are doing similar things. I believe the changes in ISP protocol are the main driving force behind the massive decline in Bitcoin nodes. Another big factor is firewalls, most people can't even remove the firewalls enough to open ports at will. The community needs to educate people on how to use Bitcoin Core when facing these intensifying security measures, or the decline of node numbers will continue.

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150904/ea4a48e8/attachment.html

668 days ago•••

📅 Original date posted:2015-09-04 📝 Original message:On Fri, Sep 4, 2015 at 11:55 AM, Zach G via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote:

It's not so simple though, AT&T will not let you have a public static IP without paying.

Not sure, but, what part of bitcoin development are you addressing in this email?

-- buZz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150904/26c78fef/attachment.html

668 days ago•••

668 days ago•••

📅 Original date posted:2016-01-13 📝 Original message:Hi All,

My original message is attached.

Cheers, Scott

---------- Forwarded message ---------- From: Scott Morgan Date: Tue, Jan 12, 2016 at 3:35 PM Subject: Wallet Lock, Unlock BIP idea To: bitcoin-dev at lists.linuxfoundation.org

Hi All,

What are your thoughts, does this idea qualify for a BIP? If so, I would appreciate it if someone takes it and runs with it.

Cheers, Scott

Donations are always welcome;

668 days ago•••

Also i'd like to say, that adding a big waving flag in the blockchain to say you are locking/unlocking your wallet might not match good privacy ethics ;)

buZz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160114/1d659519/attachment.html