"But vnprc, I pay more than that in lightning transaction fees." Yes you do. This is why we ecash.
on-chain is for large transactions
lightning is for medium transactions
ecash is for microtransactions
You're already running a relay. Build in a cashu mint and amortize those lightning transaction fees away.
Charge 2 sats. Charge 10 sats. Charge 0.1 sats. Once you have built the solution you can do price discovery.
How to run a big relay profitably and solve spam at the same time. Charge 1 sat per note.
Optional free tier requiring a proof of work challenge. It works like this: the relay creates a unique challenge, a random number, and sends it to the client for a response. Client response takes the form of a nonce, another random number. To verify the proof of work, concatenate the challenge and response and hash them. If the hash does not start with enough zero bits, drop it on the ground and close connection. That's a spammer.
If you think about it, bitcoin is just banked proof of work. So by paying a nominal fee in sats you are providing a time-delayed proof of work. It all comes down to proof of work at the end of the day. Spammers can't do it at scale. Users can.
"But vnprc I am a penniless pauper, don't I deserve social media too?" Honestly, no. But you can buy a bitaxe and earn some spending sats that way. Better yet: get an old S9 and heat your home with it. Now you have shitposting money and you are decentralizing hashrate. Congratulations, Harry. You're a bitcoiner.
It's all so tiring. Deprecate the "free" service advertising model. Replace with microtransaction fees and/or proof of work. Spam solved.
I didn't know they still made those. Nice!
best documentation/explainers
- must include diagrams
- see: anything elle mouton puts on her blog https://ellemouton.com/
best usability improvement
- could be static addresses, fixing force closes, removing the need to run a server, etc.
see: josibake silent payments, glozow TRUC transactions, calle cashu
free-est freedom tech
- biggest improvements in censorship resistance, trustlessness, decentralization, etc.
see: bluematt & t-bast BIP353
Nice! What board are you using? Are you working on a new hardware platform or just playing around? I think the next phase of SS evolution is to move to more generic and simplified hardware.
What are we looking at?
They ought to save a lot of money with a much smaller order this time around.
Wow! HRF grants for so many amazing projects! 🤩
Yo nostr:npub128a25achgxk429gwuwy7tgrwh44z5s42js2260cxdstk7tpxv9ds497erh are y'all hosting ATL BitDevs before TABconf? I'm booking my hotel because the group discount is about to expire but no info on satellite events. 🤞 for 10/22 or later but I can adjust my booking if needed.
You doing proof of skate again? I always miss it because I book flights and hotel before it's announced.
Found it! See you there! 😀 https://www.meetup.com/atlantabitdevs/events/302065904/
A lot of misconceptions:
> A well funded actor could severely distrupt bitcoin. Let's say they didnt allow tx into the chain for a year.
They would go bankrupt. Even the US government, the most well funded actor in the world, is going bankrupt all on its own without attacking bitcoin. I don't believe any entity on Earth has the resources to waste on a frivolous attack like this.
> We've yet to agree on the final mempool size... I think we'll only get one shot at it... The problem with any change is that you risk a chain split.
Mempool size defaults are not bound by consensus rules. You can already adjust your own mempool as you see fit by updating bitcoin.conf. Changing the default size is not to be taken lightly, but it's an entirely different category of proposal from consensus changes. There is no practical limit to the number of times we can change this default.
> We have to do a hard fork anyway due to the great consensus cleanup.
We have to hard fork due to the year 2106 bug. GCC is a soft fork change that we don't *need* to merge, although I think it's a very good idea and I would support that proposal if/when it picks up steam. (With one caveat, see below.)
When it comes to block size changes I agree that it may be a good idea far in the future but we have barely scratched the surface in terms of efficiency improvements with the existing ~4.5MB block size. I think we can safely ignore these proposals for a long time to come. Segwit gave us plenty of space to play with. Let's maximize the resources we have before making any change that might compromise decentralization.
I'm personally in favor of a covenant soft fork. I think we can improve blockspace efficiency by orders of magnitude with e.g. GSR, LNHANCE, or similar. But I recently came to the realization that our mining pool centralization problems are too great to risk any consensus change. I oppose any soft fork proposal until we make material progress on mining pool decentralization. This is why I decided to do something about it.
Stay tuned for Hashpools, a new kind of mining pool powered by ecash. I'm obviously biased but I think it's gonna be a big deal. Hoping to publish something in the November timeframe. Catch me at btc++ Berlin or TABconf (assuming my talk is accepted 🤞) to get an early look. If you can't make it, no problem. I will publish on nostr.
Yo nostr:npub128a25achgxk429gwuwy7tgrwh44z5s42js2260cxdstk7tpxv9ds497erh are y'all hosting ATL BitDevs before TABconf? I'm booking my hotel because the group discount is about to expire but no info on satellite events. 🤞 for 10/22 or later but I can adjust my booking if needed.
You doing proof of skate again? I always miss it because I book flights and hotel before it's announced.
If you're thinking about code changes to enforce these groupings the question to definitively answer is always "Does this change produce benefits to the whole network that outweigh the additional code complexity and the security risks it entails?"
In general, I strongly believe that changing the protocol in response to high fee events is a non-starter. We already have a mechanism to solve congestion: the free market. People who get upset about blockchain spam need to lower their time preference.
Are you talking about raising the default?
My uninformed take is that it should be a low priority. The question to answer is how often do suboptimal blocks get mined because the default mempool gets exhausted after a high fee event? I don't watch the blockchain like nostr:npub1m0n0nautpnk0jntmg89kgjucfwygrsppcpf963um5eqkjehqwess7rd0un but I can only recall seeing one event like this on social media in recent memory.
There are easier ways to mitigate this occurrence that don't increase node hardware requirements. For example, it would be relatively easy to stand up a few nodes customized to rebroadcast old transactions at key times and avoid the need to change defaults. I wouldn't be surprised if this service already exists.
I strongly suspect investing our efforts in Sv2 adoption will do more to increase transaction throughput by reducing the number of empty blocks. In the long and medium turn the decreasing block subsidy will help motivate this upgrade.
lol very agile, very dumb. Get this man a rapier!
Ah, the deck is stacked against casters. 🤞 for a fighter next time
wizards are squishy, you need a warrior class to take the hits for you