AFAIK, Armory does not use the same compact signature format that other bitcoin software uses, it's only compatible with itself.
 

"Unknown" is the good part of the network, the part that isn't centralized all to hell and a tremendous liability. It includes me and many other knowledgeable miners who care about decentralization and not just finding the quickest way to make mining fast.

These system are, in my view, largely misguided.  Except for the ones that intend to replace Bitcoin with their own currency for the asset to have any value at all there must be a trusted custodian (e.g. business owner, etc). Once you have one of those they could simply take care of tracking the assets (in a public blockchain if you like) with just highly efficient timestamping against bitcoin as needed.  Atomic trades with bitcoin in and out of these systems are perfectly possible using simple hash locked cross chain escrow transactions.

The shove everything in the blockchain modality here seems like a mixture of failed imagination and understanding coupled with either a desire to externalize operating costs on the very scarce public network capacity or a lack of understanding of the costs involved at all.

Regardless, their plans are rather dangerous— for them at least— because when transaction pressure in the future makes their little micro-transaction trades infeasible they may have a rather  difficult time unwinding the situation that they've created.  Bitcoin is a digital cryptocurrency, thats what the users of it signed up for— and if other uses turn out to be parasitic and interfere with Bitcoin's intended usage  the users of these systems should not expect the Bitcoin side to be the side which must compromise.

As an aside from the CoinJoin discussion, it occurred to me that another transaction size optimization is possible with CoinJoin like transactions.

Say there is a collection of related unconfirmed transactions:
(u signifies an unconfirmed output)


             / uI     
A -> uB -> uH  - uJ
       /
     C

D -> uE -\
          uK -> uL       
F -> uG -/


The authors of the earliest unconfirmed transactions could write replacements for their transactions:


A->ul/uj
    /   
   C
 D   
  \   
F->uL 


This transformation is lossless with respect to the final coin ownership, but the intermediate transactions were cut-through. This works even if the original coin ending up in the final outputs came from multiple parties, as they can coinjoin to preserve the final outcome.

Because the replacements are atomic and consume the original inputs this transformation is safe, assuming people in the middle can handle any accounting complications that arise. (E.g. figuring out that their payment really was completed). So you'd want to have a way of signaling "I permit you to conflict this transaction with one that pays its children, if you can figure out how".

Nlocktime could be set in the mild future in order to create time for these kinds of arrangements to be found, and if blocks are found to fast— no harm, the cutthrough doesn't have to happen all the time.

Because people don't currently spend unconfirmed inputs I expect this wouldn't get much compression now, but in the future it might have quite an impact.

Dos attacks on systems which don't require flag day updates are categorically different from cryptographic breaks. I fear the approach you are advocating would result in us getting nothing at all. (but, I certainly would welcome it if someone wanted to actually work on it!)

You're missing my point.  If you detect them disrupting the protocol the participants blacklist that input and never participate with it again (ideally the protocol would be such that they got proof of the disruption that they could show to others). But since success consumes the input you don't have a problem with long term identity linking. Yes, simultaneous is a possible but even in the worst case a given input could only be used to jam each group of users once. If recovering from a jamming is just a few packet round trip times and signature operations to redo the mix, this isn't so bad.

In any case, I've probably given you enough of my thoughts on this. Go out and code. Practice trumps theory.  As I said in my initial post, I suspect that it might be better to just start out with very weak dos protection and then adapt to the actual threats rather than trying to predict all possible threats in advance. Unlike a global consensus system there is no great harm in evolving this technology.

You don't reuse your inputs if the transaction completes successfully. Basically having an available (potentially aged) input of sufficient size that has not been used to jam the mix is a scarce resource that would limit attackers. The network already rate-limits people's ability to create new outputs as part of its own dos protection. This isn't the greatest anti-DoS possible, though you could add PoW to it too if you wanted, but in the lightweight schemes the harm of jamming the mix is very low, so the protection doesn't have to be especially great.

Ah okay, yes the anti-dos pseudonym tracking is why I had suggested the method of using the input coin itself as the identity.

A specialized for doing a meet in the middle auction (e.g. a few comparison operations and an arithmetic average) is a whole other of magnitude less complex than running a complete transaction processing program in it. Going and figuring out where the state of the art is in that space has been on my todo list.

Every participants has a key for a homomorphic encryption scheme (which can be decrypted or encrypted in arbitrary order). Each party encrypts their signature with everyones key, the signatures are grouped up and passed around, with each peer permuting their order and applying a re-encryption operation. At the end they all decrypt in sequence and you get a mixed output. The downside is that people can silently jam the mix by replacing or corrupting data during reencryption. To prevent this you need to do cut and choose (e.g. mix 10000 times, commit to all of them, one gets picked as the real mix output and you reveal the rest) and that takes a lot of bandwidth.

As an aside— I hope the cryptowizardy for the decenteralized versions of this aren't scaring people off. Part of the merit of CoinJoin as an idea is that there are braindead simple ways of using these ideas that don't require cryptomagic and are only somewhat compromised compared to what you can do with maximal magic.  I personally find the magic very exciting, but I find actual systems that people can use even _more_ exciting.  I hope people will work at this space from both ends.

I don't see any reason to hand your private key over to the SMPC, the point of this thread is that our transaction design is already such that users can separately sign a transaction. You could use SMPC to build the transaction to sign, and then everyone signs.  This would be less brittle, e.g. sybils don't get your private key they can only jam the process or get a user unfairly banned. OH you say that at the end.

I don't follow why you think you need signature privacy at the end? You could use a homorphic mix, or just use SMPC to do the combine (e.g. two phases)... but the signatures only show ownership of an input, and the input side is normally not considered as private.

I'm not aware of any general production scale implementations of SMPC, it would be very exciting for a lot of things— are you aware of any system that could be realistically tasked with signing bitcoin transactions with commodity hardware separated by consumer internet connections?

Another potentially useful idea I had in this space is CoinJoin software for doing matching charitable contributions.

E.g. you announce "I'll pay ~1 BTC to the EFF if 10 other people do too" and form a joint transaction with a single output. This may be fun, socially beneficial, and improve user privacy because even 1 TX output transactions couldn't be assumed to reveal common ownership of the input keys. Likewise, common donation outputs could be used to receive jagged change ediges in other kinds of join transactions which would otherwise be data revealing.

The bounty address is now up and already has 12.19262795 BTC assigned to it.

Somehow these end up in some reference client wallets, and then they rebroadcast them.

It's been observed a number of times, but a cause has not been determined.

The purpose of the replay bounty is to make sure that a replaying oracle gets publicly disclosed. I would normally expect that to be coupled with a fidelity bond as well.

Fair enough— for whatever it's worth, I'm no fan of them either. If nothing else they really create a hard time for people reasoning about the security model of Bitcoin: There are a lot of people who have a hard time getting how the POW consensus works and then they hear about the checkpoints and say "Ah ha! this is how its secure!", after all people are familiar with centralized security so this is just a lot easier to understand.

The big damage from that comes because we're then subjected to a non-stop stream of IDEAS and IMPROVEMENTS from people who's understanding of the security model was broken by the mere existence of checkpoints, even though checkpoints do nothing relative to consensus. These people propose things which depend on a centralized security model and don't have the benefit of the checkpoints being set thousands of block in the past so they are never a practical influence on the consensus, and don't spend the mental cycles trying to fit their ideas into the real, primarily zero trust, Bitcoin security model. As a cautionary sign of where that could be going: There altcoins which user developer controlled checkpoints broadcast to checkpoint blocks in real time, and more altcoins being added that do this... as if this were an acceptable way to construct a decentralized cryptocurrency!

When headers first syncing is merged, just by adding a "must be this tall" minimum sum difficulty check we'll be able to remove checkpoints for all DOS purposes, and we'll also be able to remove them for syncing acceleration (using random sampling for ECDSA in the deeply burried chain).

Checkpoints as a cognitive security blanket against doomsday reorgs will likely stay, but we could update them less frequently, with a more regimented process, and perhaps change how nodes respond to them (e.g. a conflicting chain becoming longer making all nodes go into a safemode where they regard everything new as unconfirmed, process no transactions, and discourage any new blocks that process transactions allowing for a public resolution of the "impossible event", rather than directly coercing the consensus).

Yup, I just mentally corrected TierNolan's proposal to match ones made by many people before— have a minimum total chain work checkpoint (e.g. any valid chain will have at least 2^70 work by height XXX). That allows the same protection from spamming as the current stuff.

Uhhhhhh. Or just run with the checkpoints=0 command-line/config option.

It would lock the BTC using that (set of) oracles in limbo, but not all BTC or even all CoinWitness BTC.

In general: the best is having no points of failure,  but failing that it's better to have many things required to fail (M of N), ecosystem diversity (so one set of M of N failing only hurts a fraction of the users), and good fallbacks (like timeouts, indeed).  One tricky part of things like timeouts is that they can create incentives for producing failures where none existed before.

E.g. if after a timeout anyone with a valid transcript showing them as the last owner can redeem the coin then there would be an incentive for someone who previously held a coin to attack the oracles and cause a timeout, allowing them to attempt to race to obtain the coin.

One possibility, borrowing from my whimsical CoinCovenants thread,  would be to have the CoinWitness program designed to enforce that a timeout recovery pays the output to another a scriptpubkey which can either be redeemed by you after a second timeout OR can be redeemed by another timeout recovery which presents a _longer_ transcript.  In this case a timeout unwind would be very likely to go to the person with the longest transcript and that might mostly remove the attack incentive the timeout creates. E.g. if you try to cheat and present a truncated transcript in order to steal some coins, before the coins are finally released to you someone with a longer transcript comes along and takes them back.

So there is some risk balancing required...  My thinking here is that no single solution will be best for everyone and all uses, but we don't have to commit to a single usage, there can be diversity.

You miss one major way in which the "alt" can be less secure:  it can just be used by fewer users. Bitcoin's main lack of scalability comes from its global scope. Fewer users is a reduction in security, but many transactions— low value ones, for example— don't need all the security Bitcoin provides... Bitcoin's security needs to be good enough for the entire Bitcoin economy.

In any case, I just gave two distinct examples to make the point that I wasn't proposing a specific off-chain scheme, but a mechanism under which almost any cryptographically provable one could be bound to Bitcoin in a way that didn't create counterparty risk at the interface. You can think of an enormous number of possible alternatives with different security/scaling tradeoffs.

Not yet, just from an implementation perspective, AFAIK, but the work is very parallel so it may be pretty GPU agreeable. Certainly special hardware could be designed which accelerated the field operations and made the work much faster.

Then you pick among them like normal, the point there is to close of the denial of service attack without undermining the consensus algorithm with an element of centralization.

The forum is overrun with the hate of the day with various "hardware"(/vaporware) vendors, it has become hard to discuss anything else. Many of the participants are behaving like animals.

I'm sensitive to the risk of suppressing complaints. There have been many scam hardware "vendors" of various degrees. People should be able to communicate about the risks, seek recourse, etc.   At the same time, these complaints have reached an intensity where they are self defeating.  If you tell me vendor X is a scam I don't know if its because they are or because you're crazy, because you're a shill for another vendor, because you're a shill for them trying to make the complainers look crazy, if you're a miner trying to scare people out of mining, etc.  As a warning this information is no longer very helpful.

I have multiple people I know (and have met in person and know not to be socks) begging me to do something about the sad state of this subforum.  But I'm at a loss... how do we defeat troll culture when it's taking the form of "concern troll" about concerns we should be careful to preserve? And how can we do it without making me and miningbuddy censors who have to vet every single post?

Does anyone have any great ideas?

IgorMcScammer is looking forward to this bright future where he starts up a bunch of mining pools that gobble people's money to automatically receive traffic.

I prefer to just make it moot:  The primary useful function of pools is collecting common payments to help people average out the risk of mining. This doesn't require the pool to be a source of centralization risk for the Bitcoin network.

You ask a local bitcoind for a getblocktemplate, you ask a far away pool for a coinbase transaction.  You combine the two.  You mine that. You send shares back to the pool. The pool credits you based on work that pays coinbases they authored. With that in effect, from the perspective of the security of the Bitcoin network we don't really care if there is only one pool (though the mining ecosystem would still benefit from there being multiple pools in order to keep fees for this service down).

Doing this would remove the externalized cost of additional centralization risk from pooled mining. It's compatible with all payout regimes, doesn't require a second distributed network (like p2pool does) to decide payouts, etc.

Having your choice of a handful of very large pools to deletgate all your influence to is not decenteralization— "A choice of masters is not freedom". Even if no pool is a majority attackers-of-bitcoin can hack multiple pools, and even a pool with only 20% hashpower can still successfully reorg two-deep transactions 20% of the times they try.

When pooling decides network state, pooling and decentralization are fundamentally opposed:  Mining is decenteralized only so long as no one (group of) miner(s) is reliably deciding the next block, but pooling doesn't make your income stable unless your pool is somewhat reliably producing blocks. This conflict can be resolved by separating centralizing for payment with centralizing the network consensus.

(Personally I'm quite happy on P2pool now that it has been tuned up to work well with Avalon... but some people, especially smaller miners, prefer different pay out schemes than P2pool can accommodate. Some payout schemes, like PPS fundamentally require centralization of payout... but that doesn't mean we need to centralize anything else)

I wish people would stop asking this question, it gets a lot of bad and incomplete answers — as it is here.

The most actually-useful consequence of these things is avoiding some trivial DOS attacks. For example, someone produces an alternative chain of 1MB diff 1 blocks, you'd normally save them just in case that chain ultimately got ahead. ... and thus run everyone out of disk space.  This can be avoided in other ways, but in the reference software checkpoints (and some rules which calculate how high in diff a block must be to ever be part of a longer chain) are how this is currently avoided.

Please search the forum, this has been asked many many times before.