The merit system is based on Bitcoin, and it tries to reflect some properties of that. You cannot send more than 50 merits once (which refers to the basic block reward we started with), there are "merit fees", equal to 50% of the sent amount, there are "miners" called "merit sources", which can mine coins by just waiting for them to re-appear every 30 days, and so on.

So, why sending zero merits is not possible? Of course, as usual, it doesn't have to be free, and a single merit can be deducted by that action (or maybe some bigger amount, to discourage misuse, but sending single merits is perfectly valid, so it probably shouldn't be much harder than that). But I think it should be possible, unless zero satoshis will be banned from Bitcoin as a sendable amount.

Someone could argue, that meriting a post, and sending a payment, are two different things. But then, in a payment system, sending "zero" also doesn't sound as something, which would make much sense in normal circumstances, and the main use case is to remain compatible with existing system, during making some features (for example: hiding coin amounts). Otherwise, sending zero amount could be easily invalidated by the next soft-fork, but there are technical reasons, to not turn off that feature.

If you are such new sources or know of missing sources, please inform me.

You could catch someone, if he will ever send more than half of what was received, but this is the only way to detect it with 100% certainty.

I thought about it for some time, and I think it should be much harder to detect, if someone is a merit source or not, than it is today. Now, it is trivial to see, who can produce merits out of thin air, and who is just a regular user, without additional permissions like that.

Knowing about merit sources, when users are pseudonymous, is similar to knowing, who mined what, and seeing nicknames in coinbase transactions. However, even if most mining pools put their tags in their blocks, and list all mined blocks on their websites, then still, the system allows mining anonymously, and solo mining is still allowed by the protocol.

In general, I think it should be possible to send merits anonymously. Very often, the act of sending merits, is perceived as the act of agreeing with someone. And sometimes, it is simply not the case, or users don't want it to be perceived in that way.

If we think about the current implementation, someone could achieve things like that, by making an alt account called "mixer", sending some merits there, and then they would be distributed by that mixer. Then, the total cost of meriting someone anonymously, would be two times higher, than sending regular merits, without hiding anything.

So, what do you think about such feature? If merit sources could sacrifice two merits, to allow someone to send a single merit in a similar way, as that user would have this additional merit, if it would be a source, then it could remove the connection between sent/received amounts, and detecting a merit source. If all users could potentially have more sent than received merits in their stats, no matter if they are merit sources or not, then it would no longer be so easy to detect merit sources, and beg them for merits, or try to draw their attention.

I can see a value in going for example to "-10", and having a private history of pending "transactions", which would be visible only to the account owner

This. Regular users could make their own history of "pending transactions", when they will run out of merits. And then, that history could be visible for account owner, and all merit sources. If a source would visit someone's profile, and see, that this person wants to merit some great post, then sources could sacrifice two times more merits, to fill that pending transaction of a non-source user.

What do you think about it? Should it be harder to detect merit sources, than it is today? I know mixers are banned from this forum, but maybe that kind of merit mixers could be beneficial for us?

Code:

02000000000104f621f4aba4d2eea7198d58b6f08a13c2ecc89c21bad6e58af718d6bab9445926000000001716001491b24bf9f5288532960ac687abb035127b1d28a5fdffffffdc5c73297fe9c5bc8a3485311645c6b754fc75ed3fa1e836d121e31e82f3a6f5000000001716001491b24bf9f5288532960ac687abb035127b1d28a5fdffffffb473c4f3e06ac922835f2b054a39d671d847c2bf9d20fa2f65845358a33aedf3000000001716001491b24bf9f5288532960ac687abb035127b1d28a5fdffffffba7c0607b57302404bd49457355fc87c645d001c2af5bfdbb5062884737b19ca010000001716001491b24bf9f5288532960ac687abb035127b1d28a5fdffffff0180b50100000000001976a9141348f140b223a5d954a04a557b13eef49527920188ac02473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802205fe27fe483106c409cbf35dec15a7270dd182448dca878ba3cb483faa6362cc701410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b802473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802202215a83215bc5b7ebceec69cc86a84b9390cf7c9fcc38cf369ff377bbe78acb601410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b802473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802203309eeddd2ac9a54e73879a90b570b6ecad7154e66ed2f029f524b2e960655f401410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b802473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802204794b439c1902d4b9fc93291caa40e4683579845eac642328b1942546f47a5b501410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b800000000

The private key is equal to one. However, for 3JvL6Ymt8MVWiCNHC7oWU6nLeHNJKLZGLN it is possible to sweep coins, but for 33q2i3GDkpHFAXnD3UdBsKhxzg7pvwAqtN it cannot be done. Why?

Now, card games are usually played by using centralized websites, where all players trust some server. It seems that things could be done differently, in more decentralized way.

First, each player generate HD wallet master private key. That should remain secret forever and that will be used later to prove ownership of the cards. Next, each player generate master public key. That key is used to determine the order of the cards in player's deck. In this way, it is guaranteed by ECDSA that the player cannot simply put cards in any chosen order. Of course, it is possible to generate master private key many times in advance to get some first cards in selected order, but it will work only in single player games and will be quite limited to few cards. Also, in single player games, simply using private key, public key and address without HD wallet is sufficient.

However, if there are at least two players, then all outcomes should depend on other player's behaviour. Both players can make their moves in some local blockchain. Mining will not be needed here, because cheating attempts are impossible once master addresses of all players are settled. If anyone will cheat, then it will be proven during the game (if someone will pick for example more Aces than are present in any deck) or in the end, where someone will provide non-matching public key. It will be also clearly visible, who and when cheated.

Before making the first move, both players generate their master private keys, master public keys and reveal master addresses, just to make sure that nobody will change its deck during the game. Since then, assuming that all players will keep their private keys secret, there is no way of creating a valid local chain without other player's cooperation.

The trick is: each player will know its public key (so the order of the cards), but the second player will decide, which card should be picked. And because this decision will be based on some address generated by upfront-agreed derivation path, the second player cannot really choose any card, the only possible way is just revealing some child address that was settled upfront by revealing master address for HD wallet.

In short:

master private key = ownership of the deck
master public key = revealed deck
master address = hidden deck
child public key = part of the proof that the second player's next move was ok
child address = base for the second player's next move

Because everything is deterministic, nobody will change any card. In the end, when one of the player wins, both of them should reveal their master public keys. In this way both players can verify that the whole game was honest and that nobody passed some random hashes or modified keys. It will be also trivial to see who and when cheated if there were any such cases. Thoughts?

Doing everything on-chain is not scalable. But doing everything off-chain means it is usually centralized, because you have to deposit coins somewhere, then play without touching any real coins, and then finally withdraw it from somewhere. There are lots of gambling sites and almost all of them already implemented "provably fair" mechanism to show to the user that all bets are honest. However, from time to time these sites are not protected enough from being down for a while, and some of them are just scams created to steal coins from users by allowing all deposits but no withdraws, so I started wondering if there is a pure P2P solution for trustless betting by making transactions that can scale properly.

First of all, at least three on-chain transactions are needed to make it. One that deposit casino and player coins to two separated 2-of-2 multisig outputs and two separate transactions that withdraw each of these coins to some address selected by the casino and the player respectively. These two transactions can be prepared and signed upfront, because Segwit allows us to attach signatures without changing transaction inputs' hashes. These two transactions have to use some timelock, set for example to two weeks, one month or more time in the future (it depends how long the casino and the player would like to freeze their coins for betting, but it should be quite long time and quite high amount to scale properly). At first, these two transactions should be signed by both parties and kept by each of them to allow getting the funds in case the other party will be gone in the future.

Then, the player and the casino can safely sign the first transaction and broadcast it on-chain. When it will get at least one confirmation, the game can be started. Each party has its own 2-of-2 multisig input that provides liquidity. If casino wins, then the user signs a transaction spending the first multisig output that gives the casino more coins and just change numbers in both outputs. If player wins, then casino does the same in favor of the player, but with the second multisig output. In this way, both parties receive transactions related to separate 2-of-2 multisig outputs and in this way no watchtower is ever needed, and the whole system is safe as long as the final transaction will be broadcasted before timeout from the first transaction will expire.

Because each party will sign only transactions giving other party more coins, there will be no reason (or possibility) to publish the old state of the channel (except publishing the first transaction). The timelock (and the other party signature) in the first transaction is only needed, because in other case there will be no way to get the coins from both outputs back if the other party will be gone. But since both parties will know about it upfront, both of them will be prepared for it and withdraw the latest transaction (that will always be the most profitable for them) before the timelock expiration (especially if it will be quite long, it should give them enough time to get it confirmed cheaply when the mempool will be almost empty). And if some party will be gone, it will be no worse than in bidirectional LN channels.

Now we are mining using "winner takes all" scheme. Every miner have to mine in pool or create the whole block alone with all transactions. But instead, we could use taproot on coinbase outputs and produce blocks a bit differently. First, miners could create merkle trees having all non-coinbase transactions and one coinbase with taproot output created by first miner. There could be many such trees available in the network and all of these trees would compete trying to produce lowest hashes, highest total block rewards, etc.

In this way each miner could choose some tree, validate it, and then start working on it. Each miner could attach to coinbase transaction having taproot output. This coinbase transaction would be built by all miners and when going down the tree, the difficulty would be halved each time. For example we could have something like this:

Code:

target: 00000000ffffff00...0
coinbase: address having 50.00 coins with BlockHash < 00000000ffffff00...0

But it would be P2SH coinbase taproot output, so it could as well contain something like this:

Code:

target: 00000000ffffff00...0
coinbase: TapRoot having 50.00 coins with BlockHash < 00000000ffffff00...0
          address having 25.00 coins with TapBranchHash < 00000001fffffe00...0
          address having 25.00 coins with TapBranchHash < 00000001fffffe00...0

When validating the whole block hash, everything would be the same. Just checking if block hash is lower than difficulty is enough and works fine. But when attaching to coinbase, any miner would have a chance to add something. All that this miner would have to do is just adding next address in coinbase output, produce tap branch hash lower than halved difficulty (number of halvings would depend on how deep in the whole taproot tree this miner would add something) and produce the whole block hash lower than it currently is. If it would be lower than the target, this block could be added to the blockchain and broadcasted to all miners.

Now we have all signatures for all inputs. Nowadays, for every input a signature should be calculated separately and included in transaction. I think about ways to compress it and include only one signature for all of those inputs. Valid transaction require publishing all public keys, so including all of them is necessary (except for P2PK transactions). We cannot compress the keys, but we can still try to compress all of those signatures.

Any public key is simply privateKey*basePoint. Thus, having two public keys we can now add these two points and have "shared public key": (privKeyA*basePoint)+(privKeyB*basePoint)=(privKeyA+privKeyB)*basePoint. In this way we can join as many public keys as we want (without revealing private keys), creating one public key for all of those inputs.

Then, we need a valid signature matching this key and it will be enough to validate it. Assuming common-input-ownership heuristic it may be a good way of merging all inputs into single output owned by the same entity, but I am still thinking about doing it in a secure way without knowing all private keys.

All participants can safely choose any "K" values for their signatures and calculate "signature public key" from it. They can safely share these keys between each other and sum it into one point, because extracting "K" from public key is as difficult as extracting any other private key from any other public key. They can also calculate "r" by taking "x" value of this key modulo "n".

Is calculating "s" possible without knowing all "K" values and all private keys? Or do you have other ideas how to compress signatures?