pull down to refresh
For the record since you inadvertently pinged me by linking a post where I shared a link, BIP-110 is at best pointless. However, it targeting op_if is what changed my opinion from sleeping through this argument to being actively against it.
This person demonstrates how to find a transaction they made where they made a hex encoded tiff file and embedded it into their transaction without using any of the methods BIP-110 is targeting. I suspect a ready and easy to use tool capable of this will be launched on BIP-110 activation day out of spite.
Additionally, the constant use of "but you have to be technical to do that so I don't care about the concern" from being able to use op_if, to being able to embed a hex encoded tiff image in a transaction is very frustrating. We can make it easy, easily.
I am once again asking for a list of all of the different ways we have thought of solving this problem, and ordering them from most support, to least support, and holding onto them until we see a 6 block deep reorg. Once that happens, we activate and ignore the fuck out of the opposition, because the opposition will be on a chain that reorgs 6 blocks deep at that point XD
the chain is for institutions
There's literally not enough Bitcoin for mass sovereign usage
CTV is retarded, all it does is delegation (centralization)
Are you not advocating for centralization? For non-sovereign usage?
I'm aware of the shitcoiner things people will do with CTV, I just think its worth addressing those attacks socially because the actual benefit is so good.
This line:
which allows the deferral of costs at best.
Is the point that I was getting at. deferring high tide (big amount of people making transactions at once) into low tide (a time like now)
Ack on the space heater mining tho. I just find entertaining these posts worthwhile because you gotta have alternate plans for when the ideal doesn't work out.
Have...you not been around very long?
Listen, we have months of VERY high fees, and times like this of almost no fees.
You have to solve both sides of the problem simultaneously, because only solving for one side, makes the other side worse.
So what I'm saying is, if people during the times when fees are VERY high, could instead be enabled to wait (which you can only really do by making waiting itself unnecessary), until these lower tides for their transaction to go through, the stress on both sides, high tide and low tide (high fee and low fee) can be solved at the same time.
If this makes Lightning more "efficient"... I'm not sure we need that
And it does, but there was also this idea about making a chain on on-chain transactions that don't wait to be mined because you've already committed to a limited set of possible spending paths, so the user is less worried about getting their transaction mined "right now"
However, having said all of that, I had a thought last night.
Mutually Assured Destruction Transactions could be a thing today and would kinda have the same affect. Only kinda. Don't know how you'd make a chain of CPFP transactions will still being able to maintain your MAD capability until it gets mined.
But do you get the idea? Transactions over more blocks vs more transactions in a block. Consistent fees included in blocks vs one block with a lot of fees.
op_ctv would be nice. Could spread out more lightning open and close actions across a lot more blocks.
We should make a list of what our options are for this problem, with tail emissions being the most nuclear option, rank them by intensity and viability, and then just sit around until it becomes a problem.
If it then does become a problem, we then UASF each option.
Unfortunately, it takes waiting for it to be a problem for a unilateral soft fork (even hard fork) to work out for this problem specifically I believe. Otherwise the other chain that might URSF could get away with paying for security in block subsidy and win by being the default.
Interesting that a Chinese tradition ended up in Kenya. Also interesting that the government really didn't take kindly to that tradition.
Yeah web3 and defi is pretty frowned upon for social and technical reasons, but its alright if you right your post people will shout at you exactly why you're wrong lol.
The best way to find the answer to something is to be wrong on the internet afterall.
I'll shill my own article: #1035320
But the comment section of that post ended up being a spat about how longer posts will never get readers to read the whole thing because readers attention span is too cooked.
Meanwhile I write documentation for how to install a shiny new ML toy on an OS hardly anyone else uses: 2000 sats right off the bat. So idk anymore. Just write a post about something you're smart on, and if you're not smart on something lurk or get smart on something you enjoy learning about then write a post about what you learned.
Thank you so much for posting this. When I read the Ark proposal, the very first thing I thought of was using it to open many lightning channels. I'm very happy to see an actual write-up about this that goes beyond a "nice thought"
I'll be posting a Request for Comment. At this rate maybe a couple of RFCs. It'll be a stacker news post (as well as in the NIP repo), but I'll ping you when its ready.
I have a Delay Tolerant design bias so I personally want less rounds lol.
There's some nonsense I'm cooking up that may be best described as:
But I'm going to try to make it as not cursed as I can think of lol.
This is probably the hard, but right way. Although I would assume at the cost of more rounds. Can you send me some documentation you'd recommend I look into?
Ack means acknowledged. Since its winning, some more details about how it might work.
The main note is posted by the proposer of the event. The event proposer can specify a threshold of signers for the event to be valid. The note will not show in unspecified user's feed until it reaches the threshold of signatures from specified npubs.
Specified npubs will get a notification similar to if they had been tagged. They will then co-sign the event in a way that I would imagine to be similar to reacting to a note.
This kind would have a timeout so that clients and relays know they can safely discard a note that does not reach its threshold.
If a note does not specify npubs, then anyone can co-sign
tsk man you're just gonna list some high paying job and then throw some 30 year mortgage on it and call it a day.
The point is not that 60% of people could get a place to live if they just moved, the point is honestly that needing to pay off a home for 30 years is nuts to begin with (Now 50).
AND
That the job market is not big enough for a significant percent of people regardless of where they moved (because they'd each be competing for each other's jobs) would not be able to afford a home. Its a systemic problem.
And dammit, even if everyone could be getting a remote job, just why live in the US? You'd save so much money living somewhere else.
Man a tool that gave people a somewhat automated estimation of income to living expenses per region would be really freaking nice.
Maybe then you could give me an example of a job near an area with what you would consider an affordable home.
ps: Alaska is probably the only exception because you can just live in the wilderness and build a home and if you live there long enough uncontested you just own it lel
But I am absolutely for attacking NFTs on Bitcoin at the social level and given solutions that would actually work, the technical level.
For example, if your gripe is that we should have block size less than 4MB, reduce block size, if your idea is to make a present day tx size, be capable of benefitting 10 or more users (thereby reducing tx cost and thereby more easily outcompeting with spam on the fee market) look into solutions that enable coinpools. I personally like playing with ideas that help people "wait" on their transaction longer in a way where the user doesn't feel like they're waiting somehow. The actual "how to do this" is a bit up in the air right now, but its something of active interest to me.