That will work but disabling p2p listening would be better (also not allow inbound but will be more secure).

Yes it would. maxuploadtarget only restricts fetching historical blocks, it won't restrict anything about you sending transactions.

Yes, enable pruning. You can set the pruning limit so high that nothing actually gets pruned, but you'll still signal yourself as pruned to the network. An option should probably get added to do this more directly, you should open a feature request for a "-nodelimited=1" option.

What you signal is mostly moot however, if you're not even listening for connections from outside.

You can set an amount of upload limit per day very low with -maxuploadtarget.

You can also reduce your maximum connection count, which will reduce traffic a lot.


You can also run a pruned node, which will cause you to not serve historical blocks at all.  This is the best.  I'm not sure if there is a flag to set node-limited while still actually having all the blocks... there should be. (perhaps setting pruning with an absurdly high pruning limit is sufficient).


There are plenty of nodes on the network serving historical blocks, it's not particularly selfish to not do so. 

It doesn't. Segwit style signing is only used for segwit style outputs.  Old style outputs are spent using the old means.

If you want to fund development yourself, great!

If you ever see someone trying to change bitcoin's consensus rules to literally stuff money into their pockets,  I hope you reject their efforts with all due vigour.  That kind of funding proposal is extremely centralizing.

Scammers gonna scam.  The fact that scamming has been reliably profitable in this ecosystem is no reason for Bitcoin to duplicate it.
 

If it's connected to an old non-segwit peer it'll send that peer a stripped block. All blocks it receives are the complete blocks, and of course any it sends to modern nodes are complete too.

There aren't that many pre-segwit nodes on the network anymore since segwit has been out for something very close to four years now. E.g. my node at home has 45 peers right now and every one of them is node_witness.

That's why I say they should batch in the first place.

That was all I had to offer. I think the right way to solve that isn't to write code for it, it's to write (or steal) a logic-relation engine.

In particular handling all the cases were an earlier partial payment confirms, and then making sure that your follwup payment conflicts with the earlier complete payments (either by being a child of the partial or more directly) ... just a gnarly mess.

For most people the best advise right now is batch in the first place.

Without signature aggregation there wouldn't be much savings unless there was cut-through going on, but there isn't much of that naturally because wallets don't normally spend unconfirmed outputs by third parties.

It some cases senders have failed to batch and could batch on replacement, but the solution there is ... batching in the first place.

This is a graph of bnExtraNonce not block.nNonce.  It gets incremented when blocks are found and when transactions arrive (which also causes common slope) but it is not reset when blocks are found. At difficulty 1 those shared causes of incrementing should be the primary driver of extranonce incrementing.

Right.

This is specific to disk stored distinguished points stored for tame entries used to generically accelerate many different executions.

The idea is that sometimes distinguished points are closely spaced on a walk, and sometimes far apart. Given a constant amount of storage you would prefer to store widely spaced distinguished points over closely spaced ones.  You can't know the actual spacing, since you don't know what the walk looked like before your start-- but you could track how far you walked and store that.

Your outlet is a NEMA 6-20.

I'm personally not a huge fan of NEMA 6-15/6-20, and prefer the locking kind... but that's what you've got, so you'll need to match your PDU up to that.

It's more common to find PDUs with L6-20 than 6-20 so you might need to get an adaptor or swap out the plug or outlet (it's pretty easy to swap out an outlet, assuming it was wired up correctly in the first place... turn off the breaker, unscrew it.. move the wires over...).

I haven't seen this paper discussed here: https://cr.yp.to/dlog/cuberoot-20120919.pdf

There are a number of good points in it but particularly the point of generating *better* distinguished points by preferentially keeping ones that have longer walk lengths is interesting.

This doesn't really have anything to do with taproot.  Taproot isn't a way to have additional outputs on transactions, each taproot output is still just a single output.

Coinbase transactions can already have multiple outputs, and miners can collaborate to create blocks that pay each other directly rather than the the value going to one party.  P2Pool is an example of this, unfortunately it was undermined by Bitmain which produced mining hardware which wouldn't work with p2pool or anything like it.

Perhaps someone should make a franky1 free CSW thread.  I'm pretty sure everyone except franky1 would prefer it at this point, otherwise the conversation has just become totally boring and repetitive.

Lets imagine you have a place to VPN to that you trust and we ignore the fact that this destination is effectively a centralized ISP and that the logical party to operate a VPN endpoint for you is an intelligence agency.  Ok.   You can VPN to that place over a mesh or over a centralized ISP and then you get the same security and privacy properties as if you VPNed to it over some mesh.

You get the bonus property that any clown with a rpi cant totally shut down your network connectivity as they currently could with the mesh.

What B.A.T.M.A.N. does is has every participant periodically announce themselves, and then each peer that hears them repeats the announcement. Each node remembers the best source for a particular host they've heard of and sends traffic for it in that general direction.

The announcements have a hop count and a sequence number to prevent loops and repetitions of the announcements. 

There is absolutely no security at all, except by totally limiting access to the media (e.g. by encrypting all packets and not making the network accessible to the public).

If someone with access to the network wants to impersonate another party and receive almost all of their traffic all they have to do is start generating announcements for them.  They can selectively mitm, impersonate, or block access to any other party on the mesh.

If you are using some L3 IP security on top of the mesh (like a VPN) then they can't impersonate but they can trivially deny access.

So as they stand right now, these protocols do not work for public networks except to the extent that no one wants to bother attacking them.  A lot of the time that is probably true --- but centralized ISPs are also secure so long as no one wants to bother attacking.

It looks like the Freifunk firmware is still actively maintained-- https://github.com/ffbsee/ffbsee-firmware/commits/master   thanks-- thats the sort of thing I was looking for when I asked before.  There was a lot of excitement about meshes around 2013-2015 and there are a lot of dead webpages now.

I can't figure out what, concretely, davef is asking for.

Would you prefer a spec which changes from time to time to falsely claim that it is final?  You would prefer that the spec not change even when demands mean the implementation must, so then the spec will just not match?   Or would you prefer the BIP have never been written in the first place, saving an epic boatload of time for the authors? Something else?


I don't intend to snark either, but your generalized complaint is totally opaque to me-- to the point that I can't even discuss it with you because I just can't tell what you expect.

Yes, I read the entire paper.


For  simplicity,  we  focus  on  the  attack against curves with j-invariant equal to 0 (i.e.,A= 0), but the attack also generalizes to the curves with non zero j-invariant. Indeed,  in  that  case,  the  faulty  curve  becomes  supersingular  according  to  Proposition  1,  and  hence  the  MOV  attack of  Proposition  2  applies


And they give attack costs about other curves. If an attacker can fault your computation, you're pretty screwed regardless of what curve you use unless countermeasures are implemented. I bet in a lot of implementations a well timed fault can cause them to just print the secret key.

Fault attacks remain completely irrelevant to this thread.

Jean_Luc,

Could be of interest to you:

https://github.com/bitcoin-core/secp256k1/pull/767


Not applicable to this thread. It's about fault attacks, where you cause a glitch in a cpu while signing to make it miscompute and leak a key. They demonstrate a particular form of this against several curves.

I don't think their countermeasure advice is all that great.  Sure, storing G as x/y is cheap and stops this particular approach (except in ecdh) so everyone should do that and effectively everything does, but if an attacker can cause skipped instructions there probably are a bunch of other ways to attack.  Better to verify after signing, like bitcoin core does.

Unfortunately people can disrupt stuff at no direct gain to themselves.

It's like, you want to give away shitty ICO tokens. You want them mostly to go to your own people, but you also want to allow a bit of the public to participate in order to build a base of invested promoters and also as air cover to hide and justify your self-issuance.

So you tell people they can have some free coins if they send you a video of them smashing a happy-meal toy.

Someone might ask how the issuers benefit from smashing toys? Are they planning on cornering the toy market? No: They don't benefit-- it was just a limited supply thing that they could get an early jump on because they set the rules.  And now all the later participants will be invested because they did work to get the 'free' tokens.

The fact that it creates an external harm such as depriving toy collectors of accesses to toys-- or in our case making it hard to get testnet coins for actual testing-- is irrelevant to the people making these decisions.

One of the reasons that externalities are often hated in public policy is that they're often extremely asymmetric: You save $10 disposing of toxic waste by dumping it and create pollution that will cost someone else $1 million to remedy.

If people working on Bitcoin can't easily get testnet coins in the future after this they'll just switch to a new testnet.  For now, there is regtest which is better than testnet for most applications so it isn't super urgent.

The bigger harm from this is just the annoyance of people showing up everywhere begging for testnet coins and the negative feelings created in donors and faucet operators that their charity was exploited so someone could make a quick buck.


Yeah, report any testnet begging that doesn't have a clear description that convinces you that it isn't just someone trying to get them for profit purposes. Like if someone says, "hey, trying to test [link to their program] and could use 0.001 TBTC and some users to try it out with me" then sure, that's not a problem, and you don't need to report it... though if it sounds like they don't know about regtest, it may be useful to tell them about it.

What you're describing is currently only true in the land of spherical cows.

The reality of mesh technology is that it's extremely challenging and as a result underdeveloped.

E.g. up thread I asked for examples, and the primary example is a lora mesh that achieves extremely low bandwidth SMS like messaging.

It's really cool, but it's not "fast internet".

No one has even really started to answer questions like how you can handle malicious mesh nodes in a way that doesn't compromise performance or just require all nodes to be approved.

I've certainly been a networking expert (e.g. my CV would support that claim).  I'd be totally happy to see mesh projects that delivered the properties that you're claiming, but I haven't seen them.  Please -- feel free to find examples. I'd be happy to discuss them.

You're not making a case for your own expertise by calling satellite slow. For a natural broadcast usage like Bitcoin it can be exceptionally efficient.  For example, the cumulative directtv video bandwidth is multiple gigabit/s per second--  available to every location over entire entire landmasses with costs like femto-cents-per-megabyte-per-potential-user.  No other technology is even comparable for broadcast use.   It doesn't do all things well, but it's still a very powerful technology.