The goal is to minimize malleability in the long run, and there are few parts playing together:

  1. wallets, which create transactions with "compliant" or "non-compliant" signatures
  2. nodes, which relay or don't relay transactions with "non-compliant" signatures
  3. miners, which mine or don't mine transactions with "non-compliant" signatures

("compliant" -> low s, "non-compliant" -> high s)

If BIP 62 rule 5 becomes a standard policy (or is enforced), then it would become harder to relay non-compliant transactions, though, the transactions of non-compliant wallets would also be rejected, which is probably not a favorable outcome.

Ideally miners don't mine non-compliant transactions, but assuming they reject all of them right now, at a time when not all wallets create low s values, then the same issue applies: legit transactions are not mined.

The ongoing active mutation of transactions made me wonder, whether targeted mutation could be leveraged - by miners or nodes - to facilitate the process:

By "fixing" non-compliant transactions the issue of dropped or rejected legit transactions would be addressed to some degree, and if primarily non-compliant transactions are mutated, then it could serve as wake up call for wallet software creators (and user's of such wallets), as the sentiment may shift from "let's pitchfork amaclin for messing with our transactions" to "let's create/use better wallets, which don't create bad transactions".

Once that happened, it could be considered to only accept low s signatures, first in form of a standard policy, and at some point it could enforced.

Could you flip your bot and mutate signatures with high s values, to target users with well, "non-compliant" software?

Oh, I see, thanks! This was what I feared.

I assume the issue is mostly one of awareness and the (lack of) seeing the need to take action.

Given that the transformation seems fairly simple, it would probably help to guide the process a bit: publish information about the issue and how to tackle it. A more radical approach and counter messure could be to setup miners/nodes, which actively mutate transactions to comply. Users with non compliant transactions would be affected, which likely causes some confusion (though certainly not more than during the "attack"), but it could help to pin down specific implementations that need to be improved.

I'm curious, why is `SCRIPT_VERIFY_LOW_S` not a standard verification flag?

JoinMarket (warning: experimental, as far as I know) may be used to gain a tiny interest for providing coins for CoinJoins:

https://bitcointalk.org/index.php?topic=919116.msg10096563
https://www.reddit.com/r/joinmarket

To quote:


Some Dice sites allow to deposit coins for the house, where gains (and losses) are shared.

But in general, I share the sentiment: better check these things twice, before giving away the control over your bitcoins.

Great art, very down to the point. Who's that guy on the right? And the magician?

When I started, I was primarily active in the speculations sub-forum. Back then I was also "thinking in USD, and not in BTC".

This has changed.

I'm a perma bull with long term perspective.

At this point I acknowledge that I have no crystal ball, and therefore speculation equals risk to lose precious coins, at least for me.

It really depends on your use case. With the upcoming release it's more and more going to be a tough decision in my opinion.

Do you need a larger community? Use Counterparty. Do you want a stable and fast desktop client or server? Use Omni Core. Do you want bets? Use Counterparty. Do you want crowdsales or bind tokens to arbitrary scripts via pay-to-script-hash? Use the Omni Layer. ... Contracts at some point in the future? ... etc. etc.

There are of course other alternatives, or maybe all this isn't useful to begin with, but I'm mostly comparing apples with apples here.

I'd consider Meni's proposal actually more as an extension: it could be applied on 1 MB blocks, but also on 8 MB blocks. And the mechanism seems to be soft-forkable. (edit: just to clarify: this shouldn't imply I don't consider it as valuable item on the list!)

Hi all,

I operate an API endpoint (api.bitwatch.co), which is used by NewbieCoin to request information about unspent outputs.

It started as backend for tests, and somewhere during the last year other projects began to use the API.

While I won't guarantee any availability of the service, I do care about users, so I just wanted to give you a headsup: please feel free to contact me via PM or other means, if there is an issue or anything else to discuss.

Cheers!

Hey Sabastian, you are probably referring to:

https://github.com/bitcoin/bitcoin/pull/1536

The logic behind Litecoin's solution: lowish outputs are penalized and each lowish output implies a higher transaction fee.

In retrospective it looks like it was superseded by a related solution:

The minimum values of outputs depend on the size of the outputs. It should not be uneconomic to spend outputs, and the larger the size of an output, the higher the minimum value shall be.

In practise: consider you receive a very low amount, let's say 1 satoshi, then it would cost you more to spend that value than it's actually worth. To prevent that the chain fills up with outputs, which probably won't get spent, the "dust" threshold was introduced:

https://github.com/bitcoin/bitcoin/pull/2577

There was recently a discussion on Reddit about the topic, which may provide some more insights:

https://www.reddit.com/r/Bitcoin/comments/3ci25k/the_current_spam_attack_on_bitcoin_is_not/csvtt8l


Output value and transaction fee policies don't break consensus.

Yeah, that's a bit short of information.

Here is some discussion about it, which probably lead to the tweet:

https://docs.google.com/document/d/1idEYEHd0woIFJsIiSGX482R2Q12zcQIXMwOcLquS9g8/

This isn't the case.

T0 uses OpenAssets, see:

- https://www.coinprism.info/asset/AchDKMsBeAfAQPBPzjHV8bB9WbBYJ1oEcp
- https://www.coinprism.info/asset/AJDL3C38AvULMCxDNM5VqBFdGB2uPknopt
- https://www.coinprism.info/asset/AMizaFrvXCNwTWVA6ijfLqxd1jmA1L2oct

Or with their own explorer:

- http://t0.com/asset/AchDKMsBeAfAQPBPzjHV8bB9WbBYJ1oEcp
- http://t0.com/asset/AJDL3C38AvULMCxDNM5VqBFdGB2uPknopt
- http://t0.com/asset/AMizaFrvXCNwTWVA6ijfLqxd1jmA1L2oct

Is there any evidence that people blindly start trusting each other, only because there is some green text?

I'd assume one would carefully read the actual trust ratings and follow the references first, before trading with a stranger.

http://www.bloomberg.com/news/articles/2015-08-04/wall-street-meet-block-368396-the-possible-future-of-finance provides a hint: block 368396.

When looking through that block, there are three notable transactions, with bare multisig encoding:

- https://blockchain.info/tx/adb8129bed9efb0b6ebf4bac8fee2d70ab41fea7a0027b9371c100fa360bb38a
- https://blockchain.info/tx/1c751d4af1fa2385d6df008fede770f365b71c8138b180cc75813e0955d3d0ea
- https://blockchain.info/tx/b7547019ee64f438a05d4458ff879765d984a541a046871d5495d0d0cf92c413

Looks like the Symbiont mainnet testing started at least two days ago.

MaidSafe is higher valuated than all XCP projects combined, based on coinmarketcap.com. And in regards to provided usefulness at the very moment (and volume) Tether is probably worth to mention.

In general I think this is an interesting idea, and in theory, as long as a coin has a mechanism to publish arbitrary messages, in one way or another, it should be possible to port the protocol.

However, I see a practical issue: if the global state is shared across multiple blockchains, then it would be mandatory to continuously keep up with all chains at the same time. Primarily, this has an impact on the resource consumption, like disk space to store the chains, and right now Omni Core requires a full copy of the Bitcoin blockchain, with enabled transaction index.

This is pretty wasteful, given that only a fraction of all (Bitcoin) transactions are Omni/Master transactions. It's one of the things I have in mind for some time, and while Omni Core isn't ready for it yet, the preperations were done during the class C/OP_RETURN integration, to support a no-txindex mode, and ultimately to support block pruning. This would at least tackle the space requirements, even though the additional processing of other chains would still be given, and I don't see an easy solution for it at the moment.

Another question that comes to my mind is the following: how are multiple chains synchronized?

While Omni transactions are unconfirmed, the state is fuzzy, and may change at any moment. Once transactions confirm, their order within a block determines the sequence of actions. But if there are multiple chains, then it basically comes down to the question: which block happend first? Bitcoin block xxxxxx, or XYZ block yyyyyy?

No, this isn't possible. The parent must be processed/mined before the child can.

Please, for your own sake, don't do this.

I'm not aware of any antivirus software that interferes with Bitcoin Core, but the better alternative would probably be to switch to a less hostile antivirus product.

There are no v3 transactions currently, and this seems more like a feature for the future, as sort of stated at the bottom of BIP 62.


v1 transactions remain valid, and the use of v3 appears to be optional, but all v3 transactions must follow the rules of BIP 62:


And this seems to be the relevant part of BIP 66: