pull down to refresh

@hynek
267,923 sats stacked
stacking since: #7075longest cowboy streak: 62
bio
254 items
by
for
10 sats \ 2 replies \ @hynek OP 6 Jun \ parent \ on: Is it time to relay even transactions with fee rate lower than 1 sat/vB? bitcoin
Yes, but you are talking about fee rate. Fee is not in fractions of sats
  • By fee I mean sum_of_outputs-sum_of_inputs
  • By fee rate I mean fee/tx_vsize
202 sats \ 0 replies \ @hynek OP 6 Jun \ parent \ on: Is it time to relay even transactions with fee rate lower than 1 sat/vB? bitcoin
Exactly. And this could even help with the security budget because on-chain might become even more accessible. It's kind of free money for miners actually.
0 sats \ 0 replies \ @hynek OP 5 Jun \ parent \ on: Is it time to relay even transactions with fee rate lower than 1 sat/vB? bitcoin
Good joke :-)
But the idea doesn't introduce fractional sats. It's very delicate change than any node runner can do.
104 sats \ 2 replies \ @hynek OP 5 Jun \ parent \ on: Is it time to relay even transactions with fee rate lower than 1 sat/vB? bitcoin
This doesn't help with scaling. But it could bring more granularity to fee market and keep it public.
I don't see the problem with the fraction. You still send whole amounts of sats. Fee rate is only a tool to compare the absolute fees. So in the example above, you could relay simple transaction (141 vB) for 2 sat →  0,014 sat/vB
Is it time to relay even transactions with fee rate lower than 1 sat/vB?
2668 sats \ 18 comments \ @hynek 5 Jun bitcoin
Your wealth is fading silently
226 sats \ 1 comment \ @hynek 31 May bitcoin
0 sats \ 1 reply \ @hynek OP 13 Feb \ parent \ on: Channel Factories fueled by Cashu bitcoin
Trust is used mainly to build the network.
0 sats \ 0 replies \ @hynek OP 13 Feb \ parent \ on: Channel Factories fueled by Cashu bitcoin
It's just theoretical concept as of now. And yes it is already quite complex. But it can start simply and than evolve step by step.
Channel Factories fueled by Cashu
1344 sats \ 6 comments \ @hynek 13 Feb bitcoin
28 sats \ 1 reply \ @hynek 2 Feb \ parent \ on: Merchant Adoption in the US AskSN
And bitcoiners need to go full in bitcoin even before that. Otherwise they fall in Gresham's law fallacy
10 sats \ 2 replies \ @hynek 2 Feb \ on: Merchant Adoption in the US AskSN
I think there needs to be demand from paying bitcoiners first
0 sats \ 0 replies \ @hynek 28 Jan \ parent \ on: How to Acquire No KYC Bitcoin bitcoin_beginners
Fair. It requires local community
0 sats \ 0 replies \ @hynek OP 9 Jan \ parent \ on: Save on-chain fees by merging transactions builders
You are paying for data stored. Which is basically inputs, outputs, and headers.
Please have a look on the schema above. Output B (of original TX) is the same as input B (of CPFP TX). When you remove them you save on fees. Both are redundant. And you don't need even the second TX header since it will be one transaction now.
0 sats \ 2 replies \ @hynek OP 9 Jan \ parent \ on: Save on-chain fees by merging transactions builders
Yes. It's CPFP - ancestors and descendant merged into one transaction... And all your pending transactions too..
16 sats \ 4 replies \ @hynek OP 9 Jan \ parent \ on: Save on-chain fees by merging transactions builders
Fee rate has to be increased a bit to motivate nodes to broadcast the new transaction. But total fee can be still lower. See the schema where I'm removing B output, B input, and one header. Or the example from app print-screen is real case where I save 16% even with increased fee rate.
The bigger fees the bigger saving...
120 sats \ 0 replies \ @hynek OP 9 Jan \ parent \ on: Save on-chain fees by merging transactions builders
Thanks, Payjoin is cool. Here is the difference, that users don't need to actively communicate, but mempool is used as a "marketplace" or communication platform → which is not optimal but sometimes might be handy.
And just like Payjoin this is creating aliby for chain analysis...