Ordering is a free parameter, and can be a deterministic function. Other than the topological constrain for spending the order of transactions in a block is completely arbitrary and without effect. Nothing about _ordering_ promotes censorship and centralization.

Synchronization might well punish those with inconsistent policies; but mining centralization prevents brought about by slow propagation prevents their existence completely.

There are ways to mostly eliminate inconsistency costs using more advanced (pre-forwarding schemes).

If a block is mostly ordered as expected, but not quite; then the amount of information needed to transmit the difference is small in any case; there is no need to strongly bind the consensus rules to this.

You're asking about account "" but you imported the address in account "1GkktBuJ6Pr51WEJe5ZzyNvMYaMDFjwyDk".

The empty quotes were not optional, the account name field is missing in your example of trying it.

I am boggling at people making a big deal about this.

Exchanges and such getting priority handling is nothing new: MTGox was doing it in 2011 (giving hosting to eligius in exchange for priority handling); and many other miners do as well. I understand F2Pool even has a paid access API. Being able to directly prioritize transactions is one of the reasons to participate in mining.

If you google 'gmaxwell out of band fees' you'll find many examples of me pointing out this-- e.g. making sure that fee estimation code isn't confused by it.

This doesn't change anything about fee market behavior: a fee is a fee regardless of how you pay it, including if its paid with service or in-kind.  They'll be less need for this sort of thing once RBF is deployed with 0.12, because there will be a uniform mechanism for everyone to revise their fees.

Prioritizing transactions is also a maintained, documented and supported feature in Bitcoin Core, and has been for years:


prioritisetransaction <txid> <priority delta> <fee delta>
Accepts the transaction into mined blocks at a higher (or lower) priority

Arguments:
1. "txid"       (string, required) The transaction id.
2. priority delta (numeric, required) The priority to add or subtract.
                  The transaction selection algorithm considers the tx as it would have a higher priority.
                  (priority of a transaction is calculated: coinage * value_in_satoshis / txsize)
3. fee delta      (numeric, required) The fee value (in satoshis) to add (or subtract, if negative).
                  The fee is not actually paid, only the algorithm for selecting transactions into a block
                  considers the transaction as it would have paid a higher (or lower) fee.

Result
true              (boolean) Returns true

Examples:
> bitcoin-cli prioritisetransaction "txid" 0.0 10000
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "prioritisetransaction", "params": ["txid", 0.0, 10000] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


So effectively people are making a fuss about a miner using a feature of Bitcoin Core thats been around forever in entirely the expected way.  Weird.

What?  Miners have taken payments for prioritizing transactions for eons. MTGox was doing the same thing in _2011_ (it gave hosting to eligius in exchange for prioritizing transactions).  F2Pool apparently has an API that you can pay access too.

Google 'gmaxwell out of band fees' and you can find lots of posts where I'm schooling people about this possibility (and actuality)-- including pushing for fee estimator designs that don't get confused by it.

There is nothing all that interesting about it, in this case: In Bitcoin, a fee is pretty much a fee regardless of its paid in or out of band.

We even have a supported, documented, and maintained facility in Bitcoin Core for doing this, and have for years, written by the same people you seem to expect to be surprised by it:

prioritisetransaction <txid> <priority delta> <fee delta>
Accepts the transaction into mined blocks at a higher (or lower) priority

Arguments:
1. "txid"       (string, required) The transaction id.
2. priority delta (numeric, required) The priority to add or subtract.
                  The transaction selection algorithm considers the tx as it would have a higher priority.
                  (priority of a transaction is calculated: coinage * value_in_satoshis / txsize)
3. fee delta      (numeric, required) The fee value (in satoshis) to add (or subtract, if negative).
                  The fee is not actually paid, only the algorithm for selecting transactions into a block
                  considers the transaction as it would have paid a higher (or lower) fee.

Result
true              (boolean) Returns true

Examples:
> bitcoin-cli prioritisetransaction "txid" 0.0 10000
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "prioritisetransaction", "params": ["txid", 0.0, 10000] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


That it's surprising to /you/ only shows you weren't paying attention.    And maybe a little bit of desperation to infer something else to support an otherwise unsupportable position?   "Bitcoin Miner uses standard Bitcoin Core feature, Better drink my XT!"

In any case-- I suggest you stop thinking in terms of finding ways to "force" people to do things; it's unbecoming.

Do not be confused: The fact that most of the dozens of developers choose to collaborate to build a stronger and better Bitcoin implementation than we could build alone does not make development non-distributed.

The process is Bitcoin is one that amplify the independence of developers generally, even beyond the level of open source software, -- including down to the fact that multiple developers must collaborate to produce releases (so we do not just end up with only one or two person who knows how), that any user can produce the same binaries that we do, that we do not have an auto-update process, and so on.  Many more complex features begin life in developers personal forks (which exist, though most don't make releases from them intended for the public (although Luke-Jr has for years)). Our software licensing enables developers to go off and do their own thing based on the codebase, even if the original authors strongly disagree with them.

When you say stuff like this, given the permissive open source software and development process what you're effectively saying is that developers should cooperate less and instead expend their efforts on more duplicated work.

I don't think that is a way to make Bitcoin successful. But I can think of a few parties that would benefit from that outcome...

There are ways to harden against these attacks-- e.g. require expensive POW on connect by the initiating party; but they have their own costs. (and are only somewhat helpful here, since botnets also tend to have a lot of cpu power)

Sending an invalid signature immediately get you kicked, Even with a botnet (or over tor) this significantly rate limits the behavior, even without the POW.

We don't consider this kind of attack a tier 1 denial of service because this, also because virtually any host that could be attacked this way could be attacked via a bandwidth exhaustion attack. There used to be variations of this were you could achieve many failed verifies per connection; but we eliminated those.

There is a widely deployed countermeasure, in any case: Do not accept inbound connections on high value nodes. Instead, run a couple public nodes, in place you don't care about, addnode those. For this particular attack you can also continue connecting out to random nodes (though there are other attacks which make it preferable to not do that and to only connect out to trusted and semitrusted nodes).

I believe that we'll eventually implement POW on connect, though more for other kinds of resource exhaustion attacks...

Wikipedia has a list of generic attacks: https://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction#Security_characteristics

I thought I'd leave a note for posterity related to the reoccurring scheme of using mid-state compression to avoid sending coinbase transactions; as it seems to get reinvented from time to time.  This has been discussed several times scattered about in various places, and I thought it useful to put the folklore understanding in one place.

In Bitcoin today various schemes like P2Pool or UTXO set commitments are suggested that require adding some mandatory data to a coinbase transaction.  To prove the mandatory data is present you must then transmit the whole coinbase transaction.  Coinbase transactions can be large, e.g. in p2pool and Eligius like pools that pay directly or for other reasons. In theory, a coinbase transaction can be upto the size of the whole block.

The reoccurring optimization is to put your mandatory data at the end of the coinbase transaction, and then send a sha256 midstate. The receiver can then complete the hashing with the mandatory data and verify agreement.

I personally think this design is inadvisable because it peels back the black box of the already fragile merkle-damgård construction and may open some novel prefix-extension attacks that no one has thought to check sha2 for... but if it is done, implementations _must_ be very careful to avoid complications from serialization capture. E.g. if you require your last commitment to be a free standing output "OP_RETURN PUSH(data)" someone can instead make their final output "OP_RETURN [other stuff] PUSH__8+4+data+size", and then that output will consume the appended commitment, and then it's possible to send a misleading midstate proof, that would be parsed differently by a midstate only client and implementations that work with the whole coinbase transaction; opening up the avenue to attacks.

Another way of saying it is that due to the use of variable length fields the transaction serialization cannot be read backwards, and so no application using midstate compression-- which inherently hides the front of transaction-- can have any dependency on the serialized structure beyond "ends with these bytes"..

For commitment applications, these problems can be avoided like p2pool does by making your rule be specific to the last N bytes of the transaction (your commitment + nlocktime), regardless of what comes before them (e.g. embedded in another output is fine)... but I  still think it's best to avoid this construction entirely.

We have a new design, a logical refinement from the earlier one, which is substantially better and also solves some additional problems.  Note for the future: things written before BIP _XXX_ will only be somewhat applicable to the segwitness created by the BIP.

Tracing funds is incompatible with "cash", and somewhat incompatible with the definition of money (fungiblity).

Orphaning is a net benefit for those who hold more hashpower, as miners do not orphan themselves.

0.10.4 binaries were just waiting on more confirming builds, the software is done and released.

As to why it exists;  we don't believe that you should be forced to take the latest/greatest software just to keep up with rule changes on the network or critical security fixes. You may have customization that require forward porting; or you may have a high effort verification process before accepting a major release.  You may choose to only accept new versions after carefully reviewing them.  We do not wish to discourage people from reviewing carefully..

So for critical bug-fixes fixes and new network behavior we make an effort to support older versions. We don't generally promote them, however-- if you need them, you'll know it.

I take it that is an attempted barb against the block relay network protocol, but I don't really get it--  Block relay network protocol is completely open, anyone can run it. Anyone can run their own servers, anyone can connect to the existing public servers.  And lots of people do, including even non-miners (not to mention small miners).

Bringing more efficient relay to the ordinary Bitcoin protocol is a reasonable goal-- absolutely, but it takes time to develop a good protocol for it;   There have been something like 4 major revisions of the relay network protocol since the last major release of Bitcoin Core; supporting the protocol as an external gateway allows rapid development and much better safety and security since bugs in the relay network client cannot easily break your node. We've learned a lot too, like a simple protocol gets almost all of the benefit, that TCP behavior matters a lot more than smaller optimizations, that even with moderate compression hashing becomes the bottleneck, etc. Meanwhile, there hasn't been much development for other schemes. (And much of what has been developed turned out to be much less efficient than the block relay network protocol).

More protocols for transmitting the bitcoin consensus also increases the robustness of the system: if someone finds an attack to jam block broadcast via the classical protocol, blocks can still get through via the alternative protocol(s).

Also, relay efficiency itself is just one of MANY sources of delay in consensus; and we've been busily at work on the others in Bitcoin Core. Dropping or diminishing that work just to re-implement the still-in-flux protocol of the relay network client wouldn't be a good use of resources. Beyond that: If you disagree and think that particular piece is more urgently important then why aren't you doing it?

Right, also secure as the message hash; the cryptographic assumptions are stronger: all of AES, the HMAC, and the discrete log must upload their security properties. Also as secure as the ECIES implementation (which has been widely implemented incorrectly in the past; e.g. electrum once shipped a broken 'ecies').

The way ECC is used for ECIES is also very different than the way ECC is used for signing; and so it has different avenues for implementation vulnerabilities.

For ECIES, the decrypting side does a variable base multiply with their secret and a point specified by the attacker (As opposed to the fixed base multiply with a secret generated by the signer, in signing).  This means that its more vulnerable to various implementation flaw and side-channel attacks.  For example, if an implementation doesn't verify the curve equation, and will print out error-ed decryptions (or any distinguisher between a small number of possible wrong decryptions) I can send in ephemeral keys which are not on the curve but are instead in a small subgroup, and with a small number of queries recover your private key.  No analogous attack can exist for signing.   Now, it's stupid for an implementation to have this kind of bug (not checking curve membership), but many real ones produced by professional have had it (including things like the Java ECC code); and especially around the bitcoin space we see a _lot_ of ECC code written by single authors as their first cryptography project being published for third party use without any meaningful peer review.

I bet that most people reading this would be surprised to learn that given a minor buggy decryption implementation if I can learn a few bits from a relatively small number of failed decryptions with select bad ephemeral keys that I could recover the private key... and because of that many people won't think to avoid having those kinds of implementation bugs or avoid leaking any information about the session key in the case of failure.

Beyond that, just ECIES alone doesn't result in good encryption software. What happens when the message is bigger than comfortably fits in ram?  Applying a HMAC naively results in having to decrypt the whole thing in ram before you can output any of it. yadda yadda,

Finally, no matter how expert the construction of the cryptosystem or it's implementation mistakes are made, new things are discovered.  One could instead keep your bitcoin keys for bitcoins, and sign a separate public key if you want to show that things are related. Doing so is strictly safer, also happens to not hurt bitcoin fungibility (by forcing people into reusing addresses), and leaves you with the option to use widely reviewed cryptographic tools for message encryption that were specifically designed for that purpose.

This is simply untrue, and I believe I've corrected it elsewhere.  Please stop repeating it.

No different from having to commit to input values for fee computation inflation avoidance though agreement or size for size limits though.  And the commitments are small, e.g. could be sent in just a couple bytes. They don't even need to be sent to a full node that has the data already.  (though it's better to do so, so the block hash can be checked before looking up the inputs)

Happy?

Old news, and there is nothing for people to do about it yet. Making noise about it now will only slow deployment, because you'll expend people's attention when there is no action for them to take.

Perhaps would have been more useful to hold off commenting on the merge until the release, which will be in a couple days.