Wouldn't the RBF need to pay more than the combined total from the separate transactions though ?

If the miner could make make more by adding the 2 separate transactions than the single cut through ?

When there is only one transaction rbf works, since miner makes more. When you are replacing multiple transactions the rbf would need to override the sum of all of them.

Only publishing the final cut-through txn removes any tricky decisions.

yes non interactive is obviously way cool 

..but I guess the point about the interactive centralised version is that it is still safe, it works today, and no changes at all required.

As @Riplin was saying..

You can coordinate the cut through transactions off-chain using a trustless centralised entity - Layer 2 style.

And a decentralised protocol could work @TierNolan but it's also really easy and secure centralised.

So lets say

A -> B -> C -> D

A pays B who pays C who pays D

Cleary the best outcome is A pays D.

A -> D

A,B,C and D could all be members of this 'CutThrough' website.

They perform their 'desired' transaction to another member of the website - but nothing gets posted onto L1.

The Website crunches the numbers and calculates what the most efficient payments are given the set of transactions it has received over a set amount of time ( hours/days ) and then coordinates with those Users to create the appropriate transactions.

The Users would all have to agree, signing something and sharing so that all parties concerned were happy that everyone agreed and then the 'final' transactions are posted.

The incentive and advantage is fees and semi-better privacy. Reduction of fees as less transactions are broadcast. Privacy as no onchain transaction to show it happened - although the entity knows of course.

These fees would be spread over all the users in the cutthrough - so that ad extremis all the users payed less than they would have done. As well as all the benefits already mentioned above to the chain, and speed etc etc.. Win win. And you don't have prior bigger juicier transactions to tempt the miners with as there aren't any.

One solution could be to have a small Eltoo/Lightning channel open to the central entity. Then it could coordinate splitting the fees, and take small amounts from all the concerned parties off chain, and then pay them itself for every L1 transaction.

( This would be different to having a large Eltoo channel since you could be payed and pay a lot with only a tiny initial sum that only needed to cover fees )

At no stage can anyone take anyones money and the worst that can happen is you are delayed before diving back to L1 yourself and completing the transaction as you would anyway have done.

If you could get a 50% reduction in overall transactions.. that's like a blocksize increase x2.. not bad.

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

What about an option where you always route through the smallest-hub routes ?

If 2 routes are available choose the one with the least amount of money on it.  ( These smaller routes would have to re-balance more often to stay relevant. )

You would only use the big hub routes as a last resort - if no other viable cheap enough route was available.

This may require more hops, and may require more fees.

Would you always choose the cheapest route or would you choose the most helpful route to keep the network decentralised ? .. not sure.

I pay the 'higher' fee currently on my BTC transactions, even if time isn't such an issue, so I can see myself choosing the _slightly_ more expensive route, if the money still got there, and it was beneficial to the health of the network.

I'm just going to say it -  It's impossible that there is a fraudulent transaction 1 year behind the top block.

my last attempt..

What about coloured coins ?

You need to colour some BTC, and you need lots of decimal places, to have lots of decimal places on your token.

1 coloured BTC  can represent 10,000 tokens to 4 decimal places. great... ($62 billion spent on just SMS messages last year (all this 2FA), over a trillion sent and they want a token to represent each one.. )

Ok.

I can see most of you think that we will never need more than the 8 we have 'because' .. it's enough. (At least for the next 100 years even at 2% expansion)

I think things are moving much faster than that ?

“Measured in current US dollars, total global wealth rose from USD 117 trillion in 2000 to 317 trillion in mid-2018, a rise of USD 200 trillion, equivalent to roughly 2.5 times global GDP.”

We'll soon have individual trillionaires..

There is zero chance we don't hit quintillions as a 'number' in the next 50 years.

Now - is Bitcoin going to live that long ?

I hear this mythical date in 2140 when we find the last scrap.. but does it have to be.. if only we could keep halving.. for-EVER!

Also - We'll be into mega-sexta-zetillions by then.. OF COURSE WE'LL NEED MORE RESOLUTION!!  (then)

The M2M economy, as I mentioned earlier, works orders of magnitude lower down the real-time trough. They'll be chatting away hundreds of times a second, querying each other for data etc.. the 'yearly' spend per device will be less than $5.. chopped up millions of times. There are 5 billion Sim/WiFi enabled IoT devices launched a year as of today. Trillions to come. These numbers get really big. 

May as well sort this out now.. no ?

Can you fork every time, maybe every 20 years.. add 8 decimal places ? I don't see it. Forks are hard and this is currently a hard fork. Although you could hard-fork a perpetual soft-fork mechanic to do this ..hehe

Is there another scheme that works from day one ?  - You could just add a decimal place automatically every million blocks or so. As hardware improves, it'll be able to handle it.

But I like the notion that the above scheme never needs better hardware.. for when these things are hardwired, on chip.

Anybody see any problems with it though ?

This!


Thank you!


What would happen to fees if the minimum amount on-chain was 1 milli-satoshi/byte ?

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

My use cases for higher decimal precision are required today

My team are working to get IoT devices performing instant Lighting payments in an M2M network of fire sensors, alarm sensors, humidity etc etc.. These devices pay each other as and when they want a reading from any of the other senses. Thousands of sensors thousands of times a day, thousands of locations.

We already need lower than satoshi precision, and the idea of rounding up.. lol.. this is Bitcoin.

Creating coloured coins and tokens will be a 'thing' at some point. L-BTC does it.

If you want to represent 21 million token units with 8 decimal places as a token you can either use 21 million BTC (not going to happen) or use MUCH smaller units.

You would need 16 decimal places to be able to colour 2.1 BTC that represented 21 mill to 8 decimal places.

The coloured tokens can be worth MUCH more than their BTC value.

I can see that most of you think we won't ever need to change the decimal precision.. but there are many use cases! 

1)The token thing.

2)IoT M2M payments (something we are working on) will need machines to be able to pay each other micro amounts. A lot.

3) Better Lightning resolution

4) The invention of the stock markets increased global wealth 1000 fold. Crypto will do the same. These numbers will seem small in the coming years. Global wealth will be measured in Mega-Bucks (Million $$).   
 
5) A catastrophe wipes out almost all coins. You find 0.005 BTC. You need to start an entirely new economy with those funds. 

We're going to need a bigger boat decimal precision.

Lucky Cryddit! ..

I still think extra decimal places are worth it.

What happens when BTC is worth $10 million ?   

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 ?
 

Just noticed this,

https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki

from,

https://twitter.com/JeremyRubin/status/1130580983923654661

Seems similar, although the implementation is different. Some great use cases.

This bit rang..


Nice name..

Every user of Bitcoin, who is online, is connected to every other user.

I can send a message (txn) and he can get it. Push.

This is very powerful. Instead of an IP though, you have a BTC address.

A P2P network that allows you to push messages to other users (bouncing through various nodes) in in effect - the same as the internet itself.

The current design of the internet does not distinguish between different routes across the web.

Is there not a more sustainable design - where the most used, the routes that transfer the most data, pay more for their usage? Those routes would require the largest routers to handle the traffic, BUT would make the most money if users had to pay fractional amounts to transfer data.

Say you try to access BTC://NETFLIX over the current Bitcoin P2P network. Not as a flood fill obviously (which is what BTC normally does) but just for routing purposes. The messages would only be bounced through the required nodes to get to you, no matter how far behind a NAT or firewall you may be. (We're all connected after all)

You or NETFLIX depending on the business model would need to pay for the use of that bandwith. The incentive structure would be there to offer those data routing services.

The LN network - is a P2P network of already P2P connected Bitcoin Nodes.

There is an overlap there, that you could make generic, and let people connect to other nodes for any reason they like, as long as they pay for the bandwidth used on the data hops.

Sorry - I'm rambling. There just seems to be a powerful property of a large scale P2P network like Bitcoins that is being under utilised.

Yes - but I don't want it stored. And the Miners of those file-coins don't get paid just to forward it.

I only want to transfer the file, with proof that the recipient received it, and a mechanism to ensure some payment to the router.

Sharing the file is no problem.. under normal circumstances..  I agree.

But all the current methods, for the 99.99% of cases where neither party has access to an external IP or a NAT routeable address.. etc,  use a centralised intermediary.

Is there a way of delivering the data over a simple p2p network - in a decentralised way - much like LN  (where you are guaranteed payment for your work - hence more likely to offer your services) ?

Thought experiment as much as anything currently usable.. 

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 ?

Decimal Places.

People start at the lowest and work up. Normal non-spam users would linger in the lowest levels. Why not.

What would happen if - just hypothetically - Bitcoin had 16 decimal places and not 8 ?

1 satoshini was 1*10^-16 BTC.. transaction fee priced in satoshini / byte.

I think fees would come down, but not by as much as 8 decimal places.

https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41

Bitcoin Core Fee Estimation Algorithm.

---------

Hmm.. I've skimmed it twice now..

https://zmnscpxj.github.io/bitcoin/unchained.html

Seems on point.

Basically - a federated group runs the onchain multisig contract. If the majority/all agree on the outcome they sign and pay out. All the clever logic is done off chain. It can be anything at all as is not limited by the on-chain script language.

Works today on BTC. Works for any future scripts. All that matters is that those who run the simple multisig contract on-chain are in agreement as to the outcome of the more complex off-chain contract.

If there is an error in the off-chain script, it can be fixed!.. since it is all off chain anyway. They just have to agree.

Quite like it.