Yes, yo dolla will do no good here. Sats only.

With that being said, there are a variety of factors involved that impact cost, such as the need for a cellular radio, post/wall mount, do you already have an LND node setup, and wiring costs of your unique install location.

Also, the system setup is a bit manual at this time, so you'd need to be comfortable navigating through these instructions: https://github.com/AndySchroder/DistributedCharge/blob/master/docs/SystemSetup.md .

You can contact me if you'd like to discuss any specifics: http://andyschroder.com/contact/ .

Sorry, was going to post some pictures of my workspace after I got it setup, but then forgot.

Those interested should just plan on doing some proof of work and coming to one of the monthly meetups we have there. See https://www.meetup.com/cincinnati-bitcoin/ .

Working on a variety of things, but lately have been honing in on making the EV application more stable and mature.

Yes, it uses HOLD invoices.

There is a limit to how long they can be held, so once it gets close to the end if you haven't consumed much energy, I have to settle the deposit even if you haven't unplugged the charge cable. The time is long enough that you should have moved your car by then so it also serves as a penalty for not moving your car and allowing me to generate revenue from someone else.

If you unplugged the charge cable but haven't moved your car, I don't have a way to detect that, so you can pay the exact invoice and get the deposit returned and I no longer have a way to penalize you for taking up the space, but that is a risk I have to take.

If you unplugged the car and left without paying the exact invoice, someone else can use the credit that is still there from the deposit until the time expires.

My take:

1. Drop all of the shitcoins and focus on lightning. Don't confuse users with a bunch of junk that is just going to go away.
2. Allow renewal of eSIM. Having to buy a new eSIM and re-install it all the time is a total waste and does not allow machine to machine use cases.
3. Provide an API for automated purchase, usage check, and top up so that users can automate the entire processes in their own dedicated "always on" applications.
4. Provide local services that actually have low latency. Most all eSIM providers I've tested route the connection through Warsaw, Poland which adds hundreds of milliseconds of latency for most users across the world.
5. Offer very low bitrate plans for machine to machine applications that just need to communicate small amounts quickly and reliably.

That's an error I commonly see from LND in SN's dev env when paying from the same lightning node that I'm paying to.

Are you sending to a lightning node or another 3rd party wallet?

you're talking about https://github.com/lightningnetwork/lnd/issues/7419

I rented a workspace there so that I can have a place to show off all my different demos in a consistent place. More info coming later on all that.

It was April 1st.

Do you know what day it is?

Here you can find a bike for generating energy: http://andyschroder.com/DistributedCharge/news/2024-11-09-BIKE/ .

Just trying to be honest. Would love for someone to scrutinize it from a technical perspective. See https://github.com/AndySchroder/bitcoin-submittx/blob/efa47eb1ac436cbb4fccbff64567ea1c52fe6352/bitcoin-submittx#L152-L156 for where I try to enable TOR stream isolation. A link is referenced that suggests that is how I should do it.

Not sure that docker is really needed to resolve this.

The way to test stream isolation would be to have several nodes that you control as test nodes, then use this tool with the --nodes option and explicitly connect to them, then monitor their logs and see where they saw connections from and make sure they don't come from the same IP. The problem is that bitcoin-submittx makes such short lived connections it will be a bit trickier to test.

I have not setup this test case yet, so maybe a better comment would have been that I haven't tested it, rather than I don't know how to.

what do you do for a sub sub space? user.subsubspace.subspace@space? the syntax just seems weird.

with this syntax, is there a way to distinguish between a subspace that was delegated via the spaces protocol or inside a zonefile that has been attached to the space?

So, for this protocol, as long as people agree on a genesis block number and a set of consensus rules, the bitcoin blockchain is just used as a timestamping system for all transactions submitted? Is there anything else besides these 3 things that glue the trust in the system together? What else could cause a chain split in the spaces protocol?

OK, so it seems like the transaction is not really done off chain, but instead, all metadata for the transaction is just not necessarily stored on chain?

for example, in the early days of spaces protocol, there won't be tons of subspaces per space, so if a subspace wants to be delegated, they aren't going to want to wait days or weeks for the space owner to have more transactions to aggregate delegation of, so each subspace transaction is practically going to require a single on chain transaction if there is no others to aggregate with?

i guess I'm trying to understand if this has a similar paradigm as zkcoins and taproot assets?

can they delegate it back to the space owner without waiting for expiration?

so is there a genesis block hash or something in the start of the spaces chain?

is it really an off chain transaction then if there needs to be a zk receipt placed on chain? or, is it really that you get a benefit in that all off chain transactions can be aggregated into a single on chain?

once they go on chain, can they go back off chain?