Hello.

I’m Spartacus Rex. The guy who wrote Minima. Paddy Cerri is just the pseudonym I use in the real world, not the digital one.

I’ve been programming since the ZX Spectrum 48K at the ripe old age of nine. Owned almost every computer since then, worked in almost every computer industry since then, and before starting Minima, was a full stack programmer contracting to the highest bidder. To be absolutely clear - gaming is by far the most fun a coder can have. SQL is at the bottom of the stack.

I fell in love with Bitcoin in 2012, and that love affair has never really stopped. Throw BitcoinTalk into the mix, the most opinionated, irreverent, intelligent, conspiratorial, mathematical, programmatic, dumb-ass, frustrating, interesting and diverse group of individuals it has ever been my absolute pleasure to encounter, and there’s no escape.

The first cracks in our relationship started to appear after ‘The Segwit Wars’. It became clear to me then that there were different interested parties. That we were not all on the same page. Not all in the same boat. Miners and Users were two very distinct groups. Not one and the same. At this point some may be thinking “Well DUH! - you didn’t know that already !?’. Nope - it took a good kick in the balls to finally see it.

UASF won!.. Woo hoo.. But it was too late, we had had our first proper argument, and our relationship started to be a little strained. Delving deeper, deeper than I’d maybe gone before, or at least as deep as before but this time eyes wide open, it became clear to me that what I thought Bitcoin was, was not what it was.

I was a bit player, not an equal. I was a User, not a Miner. The mantra started. VERIFY don’t TRUST!... Yes, yes - obviously that is important, but verifying has nothing to do with anti-censorship. Sure - no one is going to stuff an invalid transaction down my nodes’ throat, but my full node has ZERO influence on which valid transactions are actually in the blocks. Only the miners decide that. And that stung. That hurt. That gnawed at the back of my mind.

Bitcoin mining is an industry. Like every other industry on the planet. And like every other industry on the planet, it's susceptible to Economies of Scale. It has nothing to do with clever maths, nothing to do with clever cryptography, nothing to do with the Will of the set of full validating nodes or the other miners. There is only one way that the Bitcoin Mining industry ends.... One miner. And nothing anyone has ranted about since then has convinced me otherwise. The beauty of permissionless PoW mining is exactly the fact that it is so hard to control and regulate, the only way we currently deal with large monopolies.

Bitcoin miners, whether one or many, are clearly strongly incentivised to play fair. Absolutely. But the state level attack is the one to watch out for, not the miner attack. If or When Bitcoin actually threatens the Chinese Yuan or the US Dollar, are these all-powerful institutions just going to sit back and admit defeat? Of course not. This will only matter when it matters. Plenty of viable attacks.

And so.. Minima. Deep down I think the urge is in all of us. All of us Coders anyway. Always has been. As a Coder, how could I not try and write my own version of Bitcoin. My vision of a better version of Bitcoin. Frankly, as a Coder, I would be derelict in my duties if I did not attempt to better Bitcoin. The ultimate programmatic life form. The ultimate piece of code. How can any coder resist ? It’s too much. It’s intoxicating. I didn’t realise how absolute this desire was until I started coding up my own version.

I won’t go into the technical details of Minima, all of that is in the White Paper, and soon the as-yet-unfinished Yellow Paper will explain it in microscopic detail, along with the release of the first test-net and source code. But I wanted to ensure that what I felt was happening to Bitcoin, would never happen to Minima.

Minima was designed by me, for ME. Minima is the cryptocurrency I want to be using. In this regard - I don’t care about anyone else. If it’s not for you, whoopee shit. I won’t be losing any sleep over it. There’s plenty of rubbish out there to choose from. Take your pick.

But Bitcoin. The root of all crypto. My first love. I do lose sleep over that. The anguish is very real. The torment that somehow I am betraying something so wonderful. Because despite the problems I have with Bitcoin, it is wonderful, and brilliant, and has utterly changed the world for the better. My feelings on that will never change. Come what may.

The Minima Team has grown. Our office is full of people. It is no longer just me, down the hole, tap tap tapping away at my keyboard. Others believe too. I have no idea how this story ends. But - it’s truly, madly, deeply, getting exciting now.

Bring it on.

..

minima.global

Decimal Places.

How many is enough ? Is it ever enough ? (have mentioned this before - can't find the post)

Currently BTC has 8. Clearly not enough. Soon-ish 1 sat will be 1 cent.  Need to be able to chop it up less than that for micro-transactions.   

One solution, add 8 more at the next fork - but I think this is Hard-Fork territory (unless you limit the processing of these higher precision amounts to ONLY segwit) ?

But that may not last forever.. then what - another fork ?

Is there a solution we can fork that works today and always ? A scalable solution to decimal precision ?

------------

Current transaction validity  :
 
1) Make sure the sum of the inputs is greater than or equal to the sum of the outputs.

2) Check Input Script validity.

3) etc..


Make 2 changes.

1) Represent all numbers in their significant digit format to 16 significant digits. NOT as single satoshis, as a floating point number.

2) Make sure all inputs and outputs in any single transaction are in the same overlapping 16 significant digit range.

What does this mean ?

This means you can have a transaction that has milli-satoshis as long as the largest number in the transaction is less than 999 BTC.
You can have billi-satoshis as long as the largest number in the transaction is less than 99 BTC.

But you can go much lower.. you could be using 10^-50 units as long as all the inputs and outputs were in the same sliding scale of magnitude. All the maths is ALWAYS computed to 16 significant digits, it's just the exponent that changes.

Now there is no limit to how many decimal places you can use, BUT you can't mix a million BTC and 1x10^-50 BTC.. You would need to use multiple transactions to group together similar size outputs, until they were large enough to be mixed with larger values, or vice versa when trying to spend smaller amounts.

Issues :

1) Fees  : may have to be handled separately, like CT. The very small BTC units may represent a coloured coin or token, so although individual values may be small the overall value of the transaction may be large.

2) Fungibility : You now cannot mix outputs with values more than 10¹⁶ apart. You can't add a quadrillionth of a satoshi and 1 million BTC  in the same transaction. Can in 2 transactions. Does this matter ?
 

Bob wants to send Alice a 1k file.

He is not connected to Alice and must go through Carol.

Carol says she will forward it for some BTC.

Similar to LN but for Data.

--------------------

1)simplest insecure way :

Bob gives the file to Carol. Carol gives it to Alice. Alice signs a message saying she has received it, gives it to Carol. Carol gives the signed message to Bob. Bob pays Carol.

No way for Carol to pretend she has given the file to Alice. No way for Carol to ensure Bob pays her at the end or Alice signs message.  Not good.


2) Ramp it up..

Bob gives the file to Carol. Carol gives the hash of the file to Alice. Alice creates a transaction that pays out to Carol, if she provides an input that hashes to the hash of the file. Carol collects the BTC by publishing the 1k file and spending the txn.

Again - not great. Alice pays, though Bob could pre-pay her, and Alice does not know if the file is the original file Bob actually tried to send her..  AND the whole (could be encrypted) file is published on chain. What if the file was 1 MB? (do it 1000 times for 1K.. only works off-chain)

3) Bob signs the hash of the file. Give the file + signature to Carol. Then same as 2..

4).. Some kind of data HTLC ?


All these methods are unsatisfactory..


It must be off-chain compatible (for a success - with drop down to on-chain on cheat ? May not be worth the fee..).

It must be compatible with multiple hops.


How to lock up data, share it, and guarantee payment on successful delivery.. I see it as very similar to LN.. but a little different..


Anyone have any ideas ?

This trick requires upgrades to the current Bitcoin scripting language. I'm pretty sure it can all be done right now on Liquid.

You need CHECKOUPUTVERIFY and some covenant logic.
The ability to check Merkle Proofs - the branches of the tree pointing to some root.
And bit-wise operations for checking and setting bits. We'll be using Bram Cohen's bitfields, and indicate spent output with a single bit.

When we get that..
 
Here's how :

You're an exchange and you need to pay 1024 people as they want to withdraw. You have each of their addresses.

Instead of creating a transaction that sends the right amount to each participant..

Create a hash tree that has Hash ( Index Amount Address ) as the leaf nodes. Get the root of the tree. This will create proofs per leaf of 10 hashes + 10 boolean left/right values (to descend the tree - to it's root). The Index value goes from 0-1023. It's a perfect binary tree. 2^10=1024.

Give each leaf node proof to each user. This does not reveal the other outputs.

Now create a covenant script.

Send the complete funds for all 1024 participants to this one address.

Anyone of the 1024 can present their proof as an input, and the correct signature, when trying to spend their exact allotted amount. The covenant script ensures there is an output of the new correct lower amount to the same address in the outputs.

How do we know the user has not spent before ? We store it in a bitfield. 1024 Bits is 128Bytes. So there is a 128 byte value passed from covenant to covenant, similar to the way eltoo does it, and you check the bit value from INDEX in the proof to see if you can spend. Once you do spend that bit is set to 1, the 128 byte value updated and passed on, and the next check will fail. This is nice as the address for the script does not change, even though it's functioning does.

This way 1024 separate users have access to the same transaction output. Saving quite a bit of space.

Once we get SIGHASH_NOINPUT we should be able to spend outputs from one transaction as inputs to another transaction in the same block and multiple users can call the script simultaneously (they won't specify a coinid just the script).

Lots of other use cases.. (Off-ramping from a sidechain)

If a Semi-Full Bitcoin node only stored the complete UTXO, the last months worth of Blocks in full,  and the rest ONLY as block headers, how bad could it be ? You'd still have a complete record of the POW & User Balances, and the last months of data complete. (I believe the coin CryptoNite does something similar)

I know - if you don't have the whole chain, haven't verified every transaction since genesis - you cannot independently be sure that the whole chain is valid.  But is this actually a serious threat ?

A 51% attack could in theory print money - but that would need to go on for over a month (much more than a month actually at 51% only) and is easily recogniseable. I just don't see it.

Are we saying there is even the remotest chance that a block from a month ago has any txn errors ? With all the users that are currently running bitcoin having somehow _missed_ it ? So why do I need to download and verify it ?

I note that ETH is having a hard time at the moment as this is exactly what they have done, since their chain is so large.

As far as a pruned node is concerned - there is no loss in security from pruning data that they have verified themselves. Once a node is up to date, it just has to keep up, whilst pruning aggressively, and not lose any security.

Connecting to a network of these kinds of nodes absolutely does not have the _same_ security as a full blown Bitcoin node, but it's not far off. And if it meant that many more people ran semi-full nodes, I think it could be a bonus.

A user would only need to log on once a month minimum to catch up - before data was discarded. Seems squarely within the realms of possibility.

(I know you can do this already with Bitcoin - I am wondering if pruned nodes was the default install, and the majority of the nodes on the network used this, could the network  still thrive)

[zero fee]

Bitcoin uses fees as a way of preventing unlimited txns being sent by malicious parties to clog up the network.

Recently - quite a few coins out there are pushing a zero fee system. (IOTA, NANO, EOS etc..)

If a peer-2-peer crypto network doesn't require fees, say they have no miners - or have miners who are paid by other means, how is SPAM reduced ?

I am trying to list / break-down all the different methods..

1) HASHCASH - You ask the sender of transactions to do some POW work. So they have to spend some time and effort before sending the transaction, and invariably cannot proceed indefinitely.

2) Blacklist known malicious IPs.

3) Restrict the number of transactions any node will accept from any peer it is connected to - although how to distinguish the legit from the SPAM txns ? Does it matter ? maybe just restricting is enough.

4) Bit cheeky - But the sender could _burn_ some funds - the transaction outputs would be slightly less than the inputs. This is not strictly a fee as no user receives it, but is a cost that is passed on to the user. This would make spamming much more expensive.

5) Reputation systems.

6) ?

Any input - cheers! 

Peter Todd's MMR ( https://petertodd.org/2016/delayed-txo-commitments ) allows near limitless storage of values in a merkle hash tree.

In SQL terms. you get INSERT and UPDATE. but no SELECT or DELETE. You must keep track of the MMR proofs, that show your entry is valid ( your version of SELECT).

Keeping track of spent outputs normally involves storing the outputs in an ever growing un-pruneable accumulator. ZCash is the most prominent coin that uses something like this.

-------------------------------

I present a way of checking whether a special value is valid as it has never been used.


1) The user creates a public/private key.

2) User sends a special transaction to the network, which includes his public key, requesting a value/address.

3) The network adds that transaction to a block, and then creates an value/address that is equal to Hash ( Public Key | Block Hash | Transaction_num_in_block ).

4) The network adds this Globally Unique address to the MMR, and it is currently unused. Every entry into this MMR is always unique.

5) When the user wishes to use this value (could be an output), he provides the MMR proof and a signature for the original Public key (using his private key), and the MMR is then updated to show that this value is used ( output is spent ).  

6) You will NEVER get 2 MMR values with the same value, so once you have used it, you can never re-use it, and all you can do is request another value/address, which will always be different. You can't add the same value again.


That's it. You only need to store the MMR, and you can use that to make sure no one ever uses the same address/value twice.

[edit]
To be more informative - An MMR Database is 1 32 byte hash. They are very tiny.

( ..and at most to initialise an MMR you need the tree peaks, which for 2²⁵⁶ values is 8K )

I did have a thread about this about 2-3 years ago..  can't find it..

You have a Dual Coin chain. One is the currency, and one is the mining tokens.

You buy/sell mining tokens on chain with the currency and those give you the right to mine blocks, more mining tokens, more blocks you find. Block fees are paid in the currency.

The issues with POS that this fixes..

1) All those who own mining token WILL mine (or be penalised if they fail to find a block when it's their turn), so you will have ~100% staking power, rather than the usual 15-20% you get on a POS coin. Small holders of POS don't mine, and as they make up a majority (or should), this leads to low percentage of stake holders mining - thus making attacks cheaper. (I know exchanges have most of the coins anyway, but at some point this shouldn't be the case)

2) Decoupling mining power and stake.. means you don't end up with any entity having an unassailable lead, as a 51% POS holder has. You don't need to be the top stake holder to be the top miner - or vice versa.

You still have nothing at stake.

The lure of low energy consensus is strong, and I do hope that someday someone fixes the NAS issue. (Reverse Stellar Based Check-Point Holes?)

[inverse hash]

..I'm working on something.

The inverse hash is the MAX_HASH_VALUE - the hash value. So the lower the hash of the block, the more difficult the block, the more you add to the total.

I'm wondering what the sum of the inverse-hashes of the blocks, as opposed to the sum of the difficulty of the blocks, would give you ?

You would still need to find a nonce that satisfies the block difficulty, as usual, but after that the lower your hash, the more your block is worth.

The chain with the most hash-rate would on average still have the highest sum of inverse-hashes.

Any ideas what would happen?

( It just seems that some of the POW available is being left unused.. )

If every on-chain transaction, or most, was a CoinSwap, and they all used Confidential Transactions.. 

You could send any amount, via somebody else (within reason as you need to find someone who has that amount), without it being traceable, as the inputs/outputs are CT. You are no longer stuck having to send the same amounts.. same as CoinJoin+CT but with a far greater anonymity set, and yet you only have to find 1 other participant

This means that no-one would actually ever send money directly to anyone else, it would always go via somebody else. And you can't tell which transactions are linked.

Would you count that as Anonymous ? .. only the 2 people involved in the coinswap would know..

( I'm working on something and this popped up.. made me think )

Bi-directional Payment Channels allow 2 parties to send each other Bitcoins off-chain, backwards and forwards, up to the amount initially sent by both parties, forever.

This is what allows the Lightning Network to operate. And is very cool.

The problem is that each user has to lock up a certain amount of funds in the channel, and so cannot start up another channel with another user using those coins EVEN if he's not using them directly.

What if you could start up a Trinary Channel, with 3 users ?

This would look very similar to a Bi-Directional channel, but the initial MultiSig setup transaction, would be 3of3.

Then, instead of there only being 2 publishable transactions, there would be 3. One for each participant, and the HTLC would require BOTH secrets from the other 2 users to unlock. Again, all users would have to agree to update the channel, and no user could run off with a previous transaction, without allowing the other 2 to steal their coins. And as a last resort everyone can publish their latest transaction to collect what is owed them.

This way your coins can cover a much larger group of users, since each user would have access to the total amount, rather than chopped up little bits.

And you could obviously go higher. 4of4, 5of5..

(searched but saw no mention of this paper.. I must have missed the original if it was mentioned)

https://bitcoinmagazine.com/articles/new-scaling-layer-could-make-payment-channels-ten-times-more-effective/

Wow.. They've only gone and bloody fixed it.

A Lightning Network..  for the Lightning Network.

Basically it's a Layer inbetween the mainnet and Lightning that is used to create and rebalance funding channels (ALL OFF CHAIN!).

So that 90% of txns that create payment channels no longer need to be created on the mainnet (96% if we have Schnorr Sigs). That can be done in this middle layer.

It's.. Awesome.

The one big gripe people have about Lightning is the fact you have to create a lot of payment channels on-chain (and ergo pay the BIG fees), but with this, you don't have to. You just have to be a part of one of the groups that is in this middle layer. Then you can create channels to anyone in any of the connected large groups, completely off-chain. And they can all be rebalanced.

Boom

Ok.. So Bitcoin (..and Ethereum) have hit the proverbial scaling wall. Both are running rather slooowwww.. and expensive.

No other coin has faced this level of traffic yet, but any large coin will eventually have EXACTLY the same issues.I have read almost EVERY white paper out there. No one has come up with THE solution. They all say - yeah we can handle 1000 txn/s.. but they just make the blocks bigger or the traffic demands greater. They are not in my mind million txn/s solutions.

BTC has tried to come up with a solution which doesn't involve giving over ALL control to a few miners. It is called OFF_CHAIN txns. This can scale to a million txn/s.

You will recognise it as 'The Lightning Network'.

That's what needs to happen now.

If FaceBook started up a lightning hub, so that any facebook user could send Bitcoins instantly to any other facebook user (trustlessly I might add)... then..

Boom. All your base are belong to us.

lets hope in 2018 - BTC - Rides the Lightning !

Then that's it. 1 Million $$ bitcoin.

I honestly never thought this day would or even could come so soon, but now I'm not so sure.

With 8 decimal places, if BTC hits 1 million, 1 satoshi is 1cent.. So we can't do sub-cent micro txns. An area Lightning Networks will utterly transform and finally make possible. You could be paying fractions every time you turn a light on. Maaaany use cases.

Since a 'fork' takes, well, at least a couple of years to pull off, and since 5 years from now 'may' be too late, I guess this may have to be thought about for the very next fork (dare I mention it) ?

Wow.. Is that a possibility ?

Is there a plan yet - I'm sure there are many options.. Is there a preferred current best guess ? (Just go float->double ? )

Can it be done with a soft fork ? Sounds pretty hard-forkish to me, but they can do amazing things now SegWit's activated.

 

https://www.forbes.com/sites/ktorpey/2017/11/30/2017-was-the-year-when-everyone-finally-learned-bitcoin-isnt-controlled-by-miners/

It's not the miners.

 

Bi-directional payment channels allow the lightning network to work.

At some point one side of a channel may be empty and all the funds belong to just one of the channel owners. This means the other party cannot send extra funds on this channel, and must either multi-hop the funds, or close the current channel and open a new one with new funds. It also means that this channel cannot be used in other multi-hop payments in both directions, restricting available options.

Say for instance I had some funds in a channel with StarBucks. Paid for my coffee every morning.

Although this is a bi-directional channel most of the traffic, if not all, would be one way. When I had sent all the funds available to me, that channel would be pretty useless for me, but could still be used to send multi hop funds one way for other parties.

It would be in StarBucks interest to refill that channel, off-chain of course, so that my payment experience with them would be uninterrupted and seamless. It would also be good for me, as I would not have to publish an expensive on-chain BTC txn to settle up. And good for the LN network as the channel could be used in other multi-hop payments in both directions again.

....

What if there were 3 channels, which circled back to me. There could be more, but they must create a circle where the same 'side' of every channel has more funds.

In this extreme case all the participants of the path are completely bottom-heavy in funds, the number in the brackets.

Spartacus[0]   -> StarBucks[10]
StarBucks[0]   -> Epicurus[10]
Epicurus[0]     -> Spartacus[10]

In total :
Spartacus has 10
StarBucks had 10
Epicurus has 10

And now you perform a txn that sends 5 each on their respective channels. this is zero sum since every sender is also a receiver.

Spartacus sends 5 to Epicurus
Epicurus sends 5 to StarBucks
StarBucks send 5 to Spartacus

(This is why all the channels must be bottom heavy, as only one top heavy link in the chain can prevent it from working)

So the new channel positions are

Spartacus[5]   -> StarBucks[5]
StarBucks[5]   -> Epicurus[5]
Epicurus[5]     -> Spartacus[5]

In total :
Spartacus has 10
StarBucks had 10
Epicurus has 10 .. all good.

Now the channel is back to being fully useful again.

I am not 100% sure if this sequence of off-chain txns can be performed atomically (securely) ? Your basically sending a payment to yourself on a special route. So you would know the hash of the hash lock contract at the start. I don't think it screws with anything ?

( Or is this something that is being considered already ? Did look but could not find this specifically.. )

[more]

[..just re-read my post - I'm a bit out there.. been up all night.. forgive me..]

I'm sensing something..

Something in the crypto sphere.

Something in Bitcoin-Landia.

As we approach 'The Reckoning'.. and a resolution to this stalemate is achieved.

People of all walks of life asking me about Bitcoin. but in a good - how do I get in how do I use - sort of a way.

Maybe the fight it has taken to get here has made the prize seem all the larger - but there is very real sense of excitement about where crypto could lead in the future. From, well, everyone.

..

And more important than $10k/BTC (6 months tops).. Is the fact that all this 'Crypto-Anarchy' .. is working. (Anarchy - No Rulers, Not no Rules)

The Old Financial Order is crumbling around us fat & bloated & corrupt whilst a completely functioning anarchic-finance-system has sprung up along side. And lo and behold - people can't get enough of it.

More than ever - the old guard seem irrelevant and out of touch. The crypto sphere is literally where anything exciting and innovative is happening.

There's a storm coming.. and a new order.

http://www.coindesk.com/research-flaws-scaling-proposal-bitcoin-unlimited-emergent-consensus/

Addicted to Bitcoins ?

Of course..

...

Addicted to BitcoinTalk.. !?

..Didn't see that one coming..

I'm on about '1 check every 10 minutes' 15hrs a day, 7 days a week, ... 5 years and counting..

..

I find it comes in waves.. sometimes you become a post monster, for a few weeks you're chatting away (arguing like mad).. and then you chill out, and lurk for a while.. before diving back in again..

..

Of ALL my addictions.. this is my favourite.. 

Thanks All!

(Maths + Money + Code .. who could ask for more.)

Soo.. the users want one thing, the miners want another.. What to do ?

The block difficulty. That's the problem.

If the UASF goes ahead and the miners reject it, the users will be stuck on a chain that they have no hope of creating a block on, since the difficulty is so high.

Would it be possible to make it exponentially easier to create a block, if one has not been found for, let's say, 1 hour ? (This would affect the actual miners as well, and make a block gap of greater than 1 hour 'basically' impossible.)

If all the users started mining themselves, on their full nodes, their combined hash rate would still be insignificant in comparison to the actual miners.. BUT.. who cares!.. As long as they can create at least a block an hour, and then for the difficulty to re-target, let's say, every day.. the Users would have a fully functioning chain after 24 hrs. Albeit, with a low hash rate.

Not only would they be able to function, they'd be making A LOT of money as they mined their chain.

As soon as the miners realised that all the action was on that chain they would join in, start making money again, and the difficulty would go back up..

Assuming the miners wouldn't ATTACK that chain (maybe the POW algo could be changed very slightly in this particular case to prevent ASIC attacks.. don't know), and destroy it.. Is the block-difficulty-exponential-simplifier possible, or are there too many issues ? (Mining complications etc..)

I think, as with my previous post on the OP_CHECKVERSIONBIT https://bitcointalk.org/index.php?topic=1931519.0 , this would give A LOT of power back to the users.. Who wouldn't feel like they were 2nd class actors in the play, since in fact, they are the real and only stars of the show..