No.

Glad we've settled that.

You can feel free to ignore payments you don't like and weren't made to your specification. Heck, feel free to define some address format that makes your requirements crystal clear. There is no need to add risky complexity to our already very complex consensus protocol to try to force users to not be stupid.

This will also frontload all fee payments— e.g. you could make a free transaction but instead you're going to have, say, 0.01 BTC in fees by aggregating up two dozen inputs. Since it's reasonable to expect that fees will be higher in the future this is arguably a rational strategy but in the past users have been _very_ spazzy about fees and have been violently angry about them. Do you have any idea how to communicate to people that this strategy is really in their interest?

How do you propose dealing with uncertainty about future reuse? E.g. avoiding the case where you spent all of them but more come?

Not always possible. Where it's not possible ... what strategy do you think it should use?   What if it has a choice between re-linking obvious change with coins sent to a previously used address in a result that produces no change, vs not linking but resulting in more jagged change?

The reference software already does this. I was somewhat unhappy that the coincontrol UI made it possible to achieve other behavior.

It technically takes a majority, but a slim majority is unsafe because the length of a reorg that results from it is unbounded. E.g. if it's 50.001%  they split and maybe the reorg is a day long when the forkers decisively overtake.

We actually can make sure a super-majority of whatever level we think is needed exists in a soft-fork.  The way this works miners indicate their intention to support a particular softfork in their coinbase, and then we can have the softfork activate when, say, 90% of the last 1000 blocks have the indication that they're on-board. Then they'll all switch at once and the change is automatically decisive. The downside is that miners can drag their heels and delay the change.

An example of this is described in BIP 34.

The faux-urgency of speculative ideas is not helpful. Rushing in changes "ASAP" is a danger to the network with probabilities much higher that spontaneous EC weakness.  I've proposed having an alternative non-hidden-subgroup-problem signature algorithm at least as far back as early 2011, and written out some more concrete descriptions, though I'm a bit disinclined to post an implementation where some crap altcoin will just rip it off and claim an advantage over Bitcoin. But, regardless, it's not something we can or should rush into.

In terms of deployment, miners who can't update rapidly to softfork enforcing software could start mining no transactions while they update to reduce their exposure. Even if a full implementation is complicated, a simple one that reduces orphaning is likely not so hard.

I have doubts about the viability of non-essential changes in the future, with sadness and regret. The addition of P2SH happened several years ago, and today many popular wallet implementations— including ones that didn't exist when P2SH was created— do not implement it, so people can still not even start using multikey security to secure their wallets because people could not send them coin (Android wallet, Multibit, Blockchain.info, and Armory are the most notable). The non-deployment of P2SH also inhibits the deployment of a new checksig, because even if you start using a wallet secured by an improved signature scheme the whole world needs to be updated before they can send to you... p2sh was intended to resolve this chicken and egg problem with deploying new wallet security measures, by taking the sender out of the loop when they don't need to be in the loop.

Thats part of the definition of a soft fork. If there is a super-majority of miners enforcing the rule the majority will pull over the old mining nodes, they'll lose some blocks here and there but the consensus will be preserved.

You can. You simply add them.  You write a transaction which looks like an {anyone can spend} to old nodes, but looks like {$XYZ required to spend}. Old nodes are happy, and the transactions are safe to use as soon as a supermajority of miners imposes the new rule.

The nice thing about mnemonic techniques is that you know, with certainty, that they contain enough entropy because you can put a big number in, and get the same number back out again and you're secure assuming that the number was chosen uniformly over a large enough range to satisfy standard cryptographic assumptions.  Given that, you're free to optimize for memorability.

It wouldn't be terribly hard to impose a structural constraint— e.g. split your dictionary into parts of speech and have several permitted sentence schemas pick which dictionaries are used in which position, but it might add a couple words to the length.

Another possibility would be to omit verbs and connective words (a, an, the, etc) from the dictionary and let you type them freely but they're ignored by the algorithm.

No, that does basically nothing but waste network capacity. It's readily apparent in a transaction graph where the funds came from and went.

In further discussion retep realized that the Bob side could also be 2-of-2 in the normal honest case, backed up by hidden spends that used hashlocking.

This turns the protocol in to a full on transaction teleportation which in the common case looks like really boring 2of2 escrows and not special at all, though it results in a three layer protocol where you have the common cases, plus a layer of time based refunds, and a layer of hash-locked cheating escapes, and now probably needs a proper state diagram.

The net/net is that alice can pay bob via carol, in a way that shows no direct connection between alice and bob to the public (unless someone cheats), and which no one can rip of anyone else, and where the public transactions in the no-cheating case look somewhat normal (they're 2-of-2 escrows).

I suggest calling this an "airgapped payment".   The minimum things we need to turn on in script to make this useful would also be very handy for improved security for cross chain payments.... on the order of no more than 400 bytes plus the size of a regular transaction, assuming the block size is not increased.

This is pretty viable... and though I don't think additions to script are that exciting (because people hardly use what we have. ) ... the use-cases enabling hash tree verification would enable are pretty interesting for such a simple change.

However, I had previously showed how to use hash-locking to do cross-chain trades without this functionality, and I believe I can do the same to this protocol:

Here is a hash-locked version of an air-gapped payment protocol which would work today.

Alice wants to pay Bob without a publicly visible connection between them, or even without Bob learning anything about Alice's coins.

Carol offers to help, but Alice and Bob do not trust Carol and Carol does not trust Alice or Bob. In fact they all don't trust each other. At all. (I mean, look around Bitcoin talk, would you trust anyone here?)

Bob picks a secret value X and computes its hash H(X)=HX tells the hash to Alice and Carol.

Alice puts funds into an escrow which can be redeemed:

• By Alice + Carol (normal)
• By Carol if Carol provides HX, X, Q  such that HX==H(X)  and H(HX+Q) == value specified in the escrow payment.

Before announcing this transaction, Alice has carol write her a nlocktimed alice+carol refund, so if Carol is a dead-beat Alice will get her funds back eventually.

Alice tells carol Q. And Carol is convinced that she can redeem this transaction without Alice's help if only she also knew X.

After that escrow payment is confirmed Carol then pays to Bob with a hash-locked transaction which can be redeemed:

• Bob + Carol (refund)
• Bob + he must provide X such that H(X) == the prior disclosed HX

Like above, Carol has Bob help him write a nlocktimed refund before she announces this transaction.

Tada. Bob redeems it and discloses X.

If Alice doesn't do the release, Carol will redeem via disclosing Q, which will link the transactions because then anyone can look for all the signature+hash transactions and find the HX+Q one.  Otherwise no one learns the correspondence, not even Bob, since he doesn't know Q.

Take a look at the script opcode list. Without the splice operators you have no way to construct the verification of a SPV proof of a transaction. (or to test a transaction to see if its the right one, though that part at least could be circumvented by just requiring the contracted transaction to end up exactly in the blockchain, it doesn't save you from having to verify a spv proof).

I'd avoid ever using the world "balance". Nothing in the system itself keeps any kind of balance or checks any kinds of balance. Txouts are created and consumed (calling them 'coins' is a common convention).

I'd describe what you're asking for is a way to create a transaction which can be redeemed by the agreement of  Alice and M,  OR Alice after N weeks, or M alone, if M provides proof of a particular coin being created in the chain.

"millionaires problem" is just comparing integers. Not exactly whats wanted there (requires the millionaires to be honest!)... SMP could be used, sure, but requires the particpants to be online, has horrible performance (I'm imagining days to verify a SPV proof) and ultimately, SMP systems depend on cryptographic assumptions not dissimilar to ECC... if your SMP implementation fails the other parties may learn your private key.

Simple signmessages are easy and have a simple security story which is not obviously any worse.

Uh. NTP is pretty much completely insecure in practice. And if you have free control of time you can inflate bitcoin randomly.  At the same time, nodes don't really need precise time.

Compared to pay-to-address by 1 byte per spent txout, but that data is completely predictable, so you can define a more efficient serialization of block data to disk that eliminates that overhead (or at least reduces it to ~ -log2(probability transaction is P2SH) bits).

Likewise, in the pay-to-pubkey case (where you lose the hash protection of the pubkey), sufficiently smart serialization also leaves the size the same.

Given sufficiently smart storage it pretty much can't fail to reduce size, since some txouts will never be spent... though the the fact that P2SH is limited to HASH160 is kinda lame.

Certainly if I were to redo the system it would be P2SH only (with some hashtype flag for forwards compatibility)

This is just a classic "timezone wrong" issue, I would bet.

It doesn't matter if your computer shows the "correct" hour. You must have both your timezone correct and the right time for Bitcoin to work without squawking.

The base58 encodings have a type parameter which specifies the data-type:

chainparams.cpp:        base58Prefixes[PUBKEY_ADDRESS] = list_of(0);
chainparams.cpp:        base58Prefixes[SCRIPT_ADDRESS] = list_of(5);
chainparams.cpp:        base58Prefixes[SECRET_KEY] =     list_of(128);
chainparams.cpp:        base58Prefixes[EXT_PUBLIC_KEY] = list_of(0x04)(0x88)(0xB2)(0x1E);
chainparams.cpp:        base58Prefixes[EXT_SECRET_KEY] = list_of(0x04)(0x88)(0xAD)(0xE4);

All BIP32 keys are used 'compressed'.

I'm not sure what value having a second type coding would have, but it's late and so perhaps I'm confused. Why should we have additional overhead to have types inside our typed data? As an aside I'm generally not generally thrilled with size sniffing for type determination, as it tends to be brittle.

Yea, I think it (probably) was me. We actually use this in our sign-message stuff.

The downside (beyond the fact that we don't do it now) is that it's somewhat slower than basic validation, obviously this is mostly irrelevant for sign-message... but its a potentially interesting tradeoff in Bitcoin.  Though the size reduction of using a hash over an X-coordinate only ('compressed') pubkey is not really significant. (though I have some preference for the hashed form because symmetric cryptographic seems to be less brittle generally).

It wouldn't be technically hard to add to Bitcoin, however, as it would just be a soft-forking change to add a new checksig operator that was usable for this.

There are much more interesting (and similarly) easy cryptographic ideas out there than this.   But really we're hardly even using a fraction of Bitcoin's potential. Many of the popular wallet programs can't even send to P2SH addresses. In light of the absence of technical innovation, in practice, in our community any further protocol additions would be a hard sell right now.

You do not need the public key to verify the signature. The address, signature, and message are sufficient.

Yea, but who cares if they "keep" payments of 1 satoshi? Even thousands of them add up to nothing.

The advantage of coinjoining them up and giving them to miners, as Peter's tool does, is that it also thwarts attempts to reduce privacy (paying exhausted addresses tiny amounts in order to produce extra linkage)... and giving the coin to miners is the most incentive possible for miners to accept the transaction (short of actually paying extra to get it mined).

It's probably not something you'd want to use for "dust" at the scale of 0.01 BTC to (say) 0.0001 BTC. I posted a tool (now probably bitrotted) for general defragmenting last year:  https://people.xiph.org/~greg/groomer.py  basically it aggregates up outputs while trying to avoid reducing your privacy.

It might be interesting to combine the ideas in peter's tool:  For very tiny coins, give them away to miners, for larger ones aggregate them up and return them to yourself.

They may, BC.i runs nodes that do this. I've seen other aggressive connectors in the past, and surveillance is one of the possible explanations for them but for most of them it's impossible to know for sure.

There are more benign explanations though. For example, some people erroneously believe that connecting to large numbers of nodes is in their interest— e.g. they're miners and they think it will improve their block propagation, in fact because the relaying is sequential it generally tends to hurt your block propagation to do this... and they go around addnode=ing hundreds of nodes.

I've spent a fair amount of time trying to figure out how the network can discourage this kind of behavior and don't have any great general solutions.  So far the best I can do is prevent mass-connectors from DOSing the whole network. For anti-spying the best I can suggest right now is moving your nodes behind tor.

FWIW, these are also the same nodes which have been triggering the incorrect time warnings.

That should get a new thread, if retep has time to follow up on it. Thanks. (I will be deleting my post once it's not needed to keep this thread from going offtopic)