Limiting yourself will not increase your income when other miners undercut you-- they will take the transactions you reject, undercut your price, and be more profitable than you, then the difficulty will adjust and they will be making a profit and you will be making a loss and either have to adopt their practices or exit the business.

Yes it is-- the circuit it implements is universal, meaning that it can emulate any other circuit.  But it's built exactly like a mining asic is, mining asics just are more optimized for that task and don't waste space for parts that aren't needed.

The term ASIC is a comparison to early "integrated circuits"-- devices that had many semiconductor parts integrated into a single chip, but still exposed them to the outside world as generic parts. An application specific part builds the application (like "computer cpu") into it to achieve much higher levels of integration.

And hardforks tend to break nlocktimed transactoins, potentially forever destroying their funds...

It's really inadvisable to use locktimes set in the far future.  Though everyone working on the Bitcoin project works hard to not invalidate existing transactions, we don't know what new challenges the future may bring-- and the Bitcoin of 2110 might well not accept a signed transaction drafted today.

For your example it's far better to just store the private key needed to spend the funds.. you'll need that anyways in any case... (unless he intends to just give his funds to miners in the far future...)

Yep. (and if it did-- what would you run it on, your CPU is an asic too!)

https://download.wpsoftware.net/bitcoin/asic-faq.pdf


Then I just have one node and pretend to be thousands of nodes. You've just reinvented mining but in a cumbersome way, and failed to benefit the system.

Reasonable thinking but you are far too unambitious.

The understanding you need is that a transaction is like an idea. It can be expressed in many languages.  We happen to use  a particular one today to send them over the network and store on disk which is not as efficient as it could be.  We
actually use another one to handle transactions in memory that is about half as efficient as the current format you know-- but faster to work with.

Nodes could use a different language to store the transactions they use on disk or send over the P2P wire; as theymos notes-- it's not even a softfork-- This has been recommended many times in the past when people show up trying to use zlib compression on transactions (which doesn't work very well, mostly just exploiting key reuse.)-- and it influenced my thinking about how weight is computed in segwit.

There is a more concrete design that was published a bit back http://people.xiph.org/~greg/compacted_txn.txt

And Sipa has taken that design, improved it, made it more generic and has been implementing it so we can benchmark it. Hopefully there will be a patch up soon.

The result is 20% or more savings on basically all transactions, 30% on some more inefficient kinds. ... and it applies to the whole history, back to day one.

Not quite-- NODE_NETWORK exists, and is absolutely required for outbound connections (e.g. doesn't even get the bypass for draws; also the 40 count isn't 40 connection attempts, it's 40 results from addrman (which could be connection attempts or rejected for other reasons)).

In whatever release that comes out after segwit is required NODE_WITNESS will become required just like NODE_NETWORK is.   The purpose of outbound connections is to make sure you aren't partitioned and can obtain blocks, they're for your own benefit. Inbound connections are for the benefit of others.

It's not acceptable for the network topology to suddenly change when segwit activates--  can you imagine that? drop all your current connections and then form new ones hoping that the network can make a non-partitioned graph?-- that would be irresponsible.  Instead, it changes its connection preference at install time, so if there were any issues they could be addressed while the user is paying attention.

If you addnode a non-witness peer, it will be accepted just fine. Any inbound non-witness peers are accepted fine. If it's not able to get connected to witness peers it'll connect out to up to 4 of them so to avoid being partitioned if there are no witness peers available. It isn't "blacklisting" in any form-- my own 0.13.1 nodes have 82 out of 118 and  71 out of 113 peers which are not 0.13.1. (and in the latter group one of those 71 is an outbound connection to a 0.12.1 peer, FWIW).

None of it impedes the ability of non-segwit nodes to operate.  This was discussed in several public meetings and documented. I'm not aware of any problems resulting from it, besides the usual giving Kano something to howl abusively about.   When Bitcoin XT merged "xthin" it incorporated something far more aggressive (an absolute prohibition on outbound connections to non-xthin peers, even if addnoded, even if the node was partitioned)-- yet as far as I can tell there has been narry a complaint from Kano about it.

That sounds like foolish wallet construction, IMO.  Don't do that.  A wallet should use segwit (in which case all newly generated addresses should be segwit) or it shouldn't (in which case none of it is).

As far as bare P2WPKH outputs, indeed-- those could be used for change, but they're more identifiable which is pretty ugly.

You're mistaken. Pre-BIP9 softforks had an extra stage where the new feature was enforced in blocks that claimed it, but wasn't required overall. 95% was still mandatory to require the change on the network. Bip9 eliminated that step because it added complexity without adding any obvious value.   This behavior is set by the change itself, or-- rather-- BIP9 which is a meta-proposal for how changes like this should be done.

Correct.  Segwit is active on testnet-- so you can freely test out your mining there. If you could use some hashpower for testing, I can direct some to you.

I bounced your message past Cory Fields, who has been helping others with segwit integration and he pointed out that it wasn't clear from your message if you'd end up duplicating the OP_RETURN-- the default_witness_commitment contains the OP_RETURN + magic already.  Otherwise it sounds correct.

An extra connection is reserved for short lived 'feeler' connections which the node uses to explore the network.

If any any point miners find that blocks are being orphaned because they are too slow to propagate then the rational, natural, and previously observed behavior is that miners will simply centralize since doing so eliminates that cost. Because the effect of orphaning can be made arbitrarily small (by centralization or other means), your proposed effect cannot constitute a long term effective control on resource utilization.

Says someone who wants to rewrite the network rules in a way radically unlike and incompatible with the state that Bitcoin's creator left it.

No. Not reliably, but you can use the script in contrib/linearize to get a linearized copy.

You shouldn't generally assume that you can parse Bitcoin's internal datastructures, they're not a supported interface and may change from version to version.

There are more than two possible states, invalid or valid. Transactions can also be 'non-standard' meaning nodes will not create, relay, or mine them. But if they happen to (somehow) show up in a block, they'll accept them.  In effect, a non-standard transaction is one doing something that a node knows it doesn't fully understand, but still doesn't break the rules... so it won't facilitate it but it also won't reject it.

The community developed softforks in modern times take the form of only making things invalid which were already non-standard. So no transactions by users who do not upgrade will be made invalid.

Not so-- even if 90% (or 99%!) of the hashrate were to start violating the softfork, the nodes that understand it would view it like they view any other hardfork: They'd just ignore their blocks, and to them it would be precisely equal to the miners shutting off.


In community developed softforks nodes _know_ when rules have activated that they don't understand, and they complain to the user loudly: Picture.  If a user wanted to set up their node to just shut off when such a warning happened they could.  The nodes also continue to validate all the things they always validated, anti-inflation, anti-doublespending, locktimes, etc.. even for the new transactions.  Plus the non-upgraded user won't be getting any payments that themselves use the new rules, because their wallet doesn't generate addresses that use them.

So in a softfork: Everyone gets a choice to upgrade or not and can choose _WHEN_ they upgrade... e.g. at a time when its convient to them. If they use software which is customized or no longer maintained, they can still 'upgrade' it by simply sticking it behind a stock upgraded node.  If they'd like to shut off at activation time until they get a chance to upgrade, they can do that too.  If like most people, the changes aren't immediately relevant to them-- they don't need to worry about them... and can just upgrade when they get around to refreshing their systems.  In a softfork there need be no actual split of the chain (there wasn't in the last one, for example).

Meanwhile hardforks are almost certain to split the chain even if just accidentally. They force users to upgrade at a particular time, and there is no easy upgrade: if your software is unmaintained you are just out of luck. They also carry more long term risk politically, they can effectively redefine the system-- assign ownership of coins to other parties--.  There is no relatively safe do nothing opportunity-- which punishes people using alternative implementations. Look how far behind xt/classic have been on prior softforks: only implementing them months after they were deployed. A frequent cadence of hardforks would make one many development teams completely infeasible.

So in any case, I think it is clearly the case that what you propose is strictly inferior. If you'd like your node to shut down when upgrades happen, set that up-- but basically no one wants that. Losing the ability to 'upgrade' customized systems by putting them behind upgraded gateways is a massive loss of flexibility and increase in cost/risk... especially since you can't control the timing of a hardfork and can't roll it back if your deployment goes poorly.

There is never any proof, short of the person transacting saying "it's a spam attack".

What we do have is an interesting change in transaction behavior reflected in the UTXO set: https://blockchain.info/charts/utxo-count?timespan=60days which coincides with the flood of higher fee transactions starting and stopping.

Completely unnecessary. You announce all involved transactions yourself, you can make connections wherever you want, and then you can delay your broadcasts by the round trip time on each of these connections. The end result is indistinguishable from accomplices wherever you want them, but you need only a single host.

The only reason to be geographically spread would be to exploit things like true internet partitioning events.

On testnet? infinity?

That answer is confused.  Locked transactions cannot be relayed until they're about to become mineable. After they are mineable they hang around just as long as any other transaction, their persistence is not reduced.


The "story" doesn't make a lot of sense, however. If someone is going to give 1000 BTC  a year later with no opportunity to take it back, then that is the same as handing over the funds now.  All of locktime, cltv, and CSV make sense only if there are cases where the transfer would potentially be changed but is otherwise guaranteed.

Let me make it make sense:

For example, your rich uncle says he will pay you 1000 BTC if you get married and stay married for a year.  You don't believe him since he didn't get rich by being generous or trustworthy.   So he sends 1000 BTC to a 2 of 3 multsig, with him, you, and the editor of your local paper as signers. Additionally, he writes a transaction spending that payment and paying you directly, locktimed a year from now, and he signs it and gives it to you.  You sign it, so the only think keeping it from being valid is the locktime, and stick a few copies in safe places.  You go and get married, confident that your uncle will not have an easy time cheating you.

Now, at any point from between now and a year from now you might get divorced and then you can sign a txn giving the funds back, or-- assuming you don't co-operate he can go to the newspaper editor with evidence of your divorce, and get the funds back.

Otherwise, in a year, you can take that locktimed transaction and send it to the network-- with no further cooperation from anyone else.  That surprise forklift accident that got your uncle AND the newspaper editor will be no problem for you, their help is no longer required.

In this case the locktime was quite useful-- and there was no reason to send it to the network until the lock was already mature... which is exactly what the network expects.

If the network didn't work this way, people could make locked transactions that wouldn't be good for 100 years, use the network for free forwarding and storage.. then double spend the coins before the lock became mature to avoid paying any fees.  Fortunately, there are no interesting protocols that I've encountered where this is an issue.

The poll text doesn't really jive with the message text.

What does Bitcoin's creator have anything to do with this? For all we know all of Satoshi's coins are happily in regular circulation.

The poll asks, "Is it morally justified to destroy Satoshi's bitcoins to prevent market crash?"

but the text of the message makes it clear the real subject is:

"If ECC is cryptographically broken, is it okay to have a finite deadline for all coins to move to non-ECC keys in order to prevent millions of coins from being stolen including long lost coins?"


These are pretty distinctive discussions... in particular, targeting a specific person is quite different from targeting vulnerable keys generally. And "to destroy" sure doesn't sound like something with ample opportunity to move them first.