<unnamed>

Public Key

npub1ghl954l59wm5pnv8j2y0ymmp6dt70kx2037e06wavfut7gjh68hqdgc6pd

Profile Code

nprofile1qqsytlj62l6zhd6qekre9z8jdasax4l8mr98clvha8wky79lyftarmspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsen3nrx

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:10:01 CEST

- reply

📅 Original date posted:2018-01-22
📝 Original message:Along the same lines, I wonder if unrelated people with tx that are not
confirming could cooperate to merge their disparate tx into a CoinJoin tx
with a higher fee rate?
Perhaps they could even replace old tx with economically equivalent summary
transactions?
The mempool seems like nature's accumulator for pre-mining compression
opportunities.
On Mon, Jan 22, 2018 at 1:18 PM, Rhavar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > If you spent your change from transaction A, that would be safe. There'd
> be no way you John could end up with 2 BTC from you then.
>
> Yes, that's what the following paragraph says -- along with it's
> limitations =)
>
> -Ryan
>
>
> -------- Original Message --------
> On January 22, 2018 1:16 PM, Alan Evans <thealanevans at gmail.com> wrote:
>
> > So now I still owe John 1 BTC, however it's not immediately clear if it's
> safe to send to him
>
> If you spent your change from transaction A, that would be safe. There'd
> be no way you John could end up with 2 BTC from you then.
>
> On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> So my half-baked idea is very simple:
>>
>> Allow users to merge multiple unconfirmed transactions, stripping
>> extraneous inputs and change as they go.
>>
>> This is currently not possible because of the bip125 rule:
>> "The replacement transaction pays an absolute fee of at least the sum
>> paid by the original transactions."
>>
>> Because the size of the merged transaction is smaller than the original
>> transactions, unless there is a considerable feerate bump, this rule isn't
>> possible to observe.
>>
>>
>> I my question is: is it possible or reasonable to relax this rule? If
>> this rule was removed in its entirety, does it introduce any DoS vectors?
>> Or can it be changed to allow my use-case?
>>
>>
>> ---
>> Full backstory: I have been trying to use bip125 (Opt-in Full
>> Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I
>> owe John 1 bitcoin, and have promised to pay him immediately: Instead of
>> creating a whole new transaction if I have an in-flight (unconfirmed)
>> transaction, I can follow the rules of bip125 to create a replacement that
>> accomplishes this goal.
>>
>> From a "coin selection" point of view, this was significantly easier than
>> I had anticipated. I was able to encode the rules in my linear model and
>> feed in all my unspent and in-flight transactions and it can solve it
>> without difficulty.
>>
>> However, the real problem is tracking the mess. Consider this sequence of
>> events:
>> 1) I have unconfirmed transaction A
>> 2) I replace it with B, which pays John 1 BTC
>> 3) Transaction A gets confirmed
>>
>> So now I still owe John 1 BTC, however it's not immediately clear if
>> it's safe to send to him without waiting $n transactions. However even
>> for a small $n, this breaks my promise to pay him immediately.
>>
>> One possible solution is to only consider a transaction "replaceable" if
>> it has change, so if the original transaction confirms -- payments can
>> immediately be made that source the change, and provide safety in a reorg.
>>
>> However, this will only work <50% of the time for me (most transactions
>> don't have change) and opens a pandora's box of complexity.
>>
>> There's a few other hacks you can do to make it work in a few more cases,
>> but nothing that is realistic to expect anyone to implement any time soon.
>>
>> However, if there was a straight foward way to merge N unconfirmed
>> transactions, it would be easy get into production, and potentially offer
>> some pretty nice savings for everyone.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/8273b051/attachment.html>

2023-06-07 20:10:00 CEST

- reply

📅 Original date posted:2018-01-28
📝 Original message:As you point out, depending on the mempool, sometimes a miner makes more
fee by including A and B, while other times a miner makes more fee by
including C (the replacement for A and B) and D (a hypothetical transaction
that cannot be fit into a block that contains A and B but can be fit into a
block with C.
So what are we to make of this? Is it better to relay C or better to not
relay C?
Clearly it is better for the miner if they know about C, because knowing
about C costs them nothing, but not knowing about C will sometimes result
in them earning less fees.
Clearly it is better for the people who are creating C for those
transactions to be mined instead of the more expensive A and B transactions.
Everyone else is better off in that more transactions would get included in
blocks.
A concern about burdening full nodes with extra transactions to relay that
may not be more profitable to mine than the transactions they replace is
still rational -- though intuitively it seems like there would be a limit
on how many times an attacker could cheaply reorganize transactions into
something with a higher fee rate.
Perhaps there are also concerns with reconstruction of blocks from compact
blocks, given that miners would have more decisions to make about which tx
to include?
On Sun, Jan 28, 2018 at 12:29 PM, David A. Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, Jan 28, 2018 at 05:43:34PM +0100, Sjors Provoost via bitcoin-dev
> wrote:
> > Peter Todd wrote:
> > > In fact I considered only requiring an increase in fee rate, based on
> the
> > > theory that if absolute fee went down, the transaction must be smaller
> and thus
> > > miners could overall earn more from the additional transactions they
> could fit
> > > into their block. But to do that properly requires considering whether
> or not
> > > that's actually true in the particular state the mempool as a whole
> happens to
> > > be in, so I ditched that idea early on for the much simpler criteria
> of both a
> > > feerate and absolute fee increase.
> >
> > Why would you need to consider the whole mempool?
>
> Imagine a miner is only concerned with creating the next block and his
> mempool currently only has 750,000 vbytes in it. If two 250-vbyte
> transactions each paying a feerate of 100 nanobitcoins per vbyte (50k
> total) are replaced with one 325-vbyte transaction paying a feerate of
> 120 nBTC (39k total), the miner's potential income from mining the next
> block is reduced by 11k nBTC.
>
> Moving away from this easily worked example, the problem can still exist
> even if a miner has enough transactions to fill the next block. For
> replacement consideration only by increased feerate to be guaranteed
> more profitable, one has to assume the mempool contains an effectively
> continuous distribution of feerates. That may one day be true of the
> mempool (it would be good, because it helps keep block production
> regular sans subsidy) but it's often not the case these days.
>
> -Dave
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180128/3c990f38/attachment.html>

2023-06-07 20:09:57 CEST

- reply

📅 Original date posted:2018-01-23
📝 Original message:Another way to limit abuse would be to have the fee *rate* be required to
increase, which is kind of the spirit of RBF, applied to this situation.
That is to say, if you wished to replace transactions A and B with C which
spends the same inputs as A and B, then the following must be true before C
will be relayed:
(Fee_A + Fee_B) / (Weight_A + Weight_B) < Fee_C / Weight_C
On Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Getting back on topic:
>
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth.
>
>
> I think I'm missing something, as I don't really understand this DoS
> vector. Relay bandwidth is already very cheap and easy to use by repeatedly
> fee bumping. And it's not obvious to me that requiring an absolute higher
> fee actually makes such an attack more expensive.
>
> I can see that my "proposed" change would make it cheaper to evict low-fee
> transactions from other node's mempool. Maybe I'm being naive, but I don't
> really see why this would be such a big deal.
>
> But what about a compromise, and require that the absolute fee must be >=
> half the original fees. I know everyone hates magic values, but I think in
> practice it will allow legitimate and useful use of "retroactive
> transaction merging" without much downside.
>
> And really the great thing about "retroactive transaction merging" is just
> how easy it is to implement. In fact, right now it's quite possible to do
> -- but because of the "higher absolute fee" rule the benefits are pretty
> muted (although if you can compress 2 change into 1, that's still likely
> worthwhile)
>
>
>
> -Ryan
>
>
> -------- Original Message --------
> On January 22, 2018 3:00 PM, Peter Todd <pete at petertodd.org> wrote:
>
> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>
> So my half-baked idea is very simple:
> Allow users to merge multiple unconfirmed transactions, stripping
> extraneous inputs and change as they go.
> This is currently not possible because of the bip125 rule:
> "The replacement transaction pays an absolute fee of at least the sum paid
> by the original transactions."
> Because the size of the merged transaction is smaller than the original
> transactions, unless there is a considerable feerate bump, this rule isn't
> possible to observe.
> I my question is: is it possible or reasonable to relax this rule? If this
> rule was removed in its entirety, does it introduce any DoS vectors? Or can
> it be changed to allow my use-case?
>
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth. You'd also be able to push others' txs out of the mempool.
>
>
> ------------------------------
>
> Full backstory: I have been trying to use bip125 (Opt-in Full
> Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I
> owe John 1 bitcoin, and have promised to pay him immediately: Instead of
> creating a whole new transaction if I have an in-flight (unconfirmed)
> transaction, I can follow the rules of bip125 to create a replacement that
> accomplishes this goal.
> From a "coin selection" point of view, this was significantly easier than
> I had anticipated. I was able to encode the rules in my linear model and
> feed in all my unspent and in-flight transactions and it can solve it
> without difficulty.
> However, the real problem is tracking the mess. Consider this sequence of
> events:
>
> 1. I have unconfirmed transaction A
> 2. I replace it with B, which pays John 1 BTC
> 3. Transaction A gets confirmed
>
> So now I still owe John 1 BTC, however it's not immediately clear if
> it's safe to send to him without waiting $n transactions. However even
> for a small $n, this breaks my promise to pay him immediately.
> One possible solution is to only consider a transaction "replaceable" if
> it has change, so if the original transaction confirms -- payments can
> immediately be made that source the change, and provide safety in a reorg.
> However, this will only work <50% of the time for me (most transactions
> don't have change) and opens a pandora's box of complexity.
>
>
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change,
> because
> it's rare for the inputs to exactly math the requested payment.
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180123/bded9fb7/attachment.html>

2023-06-07 20:08:44 CEST

- reply

📅 Original date posted:2017-12-15
📝 Original message:>Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the >correct<
approach. It's tidy, systematic and precise.
The SI system is great, but it's nice if you pick a base unit that is easy
for intuition to comprehend.
It is a fact that I weigh approximately .000,000,000,000,000,000,000,014
Earth masses. If we arrived at rough consensus that this was a cumbersome
way to express the mass of a human, we might then find a group of people
making the superficially sensible proposal that we use SI prefixes and say
I weigh 14 yoctoearths. This would be tidy, systematic and precise, but
that might not be enough to make it the best option. It might be even
better to choose a base unit that human intuition can make sense of, and
THEN add prefixes as needed.
I dislike the name "bits" but I think 100 satoshis does make a nice base
unit. If we cannot crowdsource a more inspiring label we may be stuck with
bits just due to linguistic network effects.
-Ethan
On Fri, Dec 15, 2017 at 1:27 AM, Marcel Jamin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think one could make the argument that the only people who talk
> about and understand 24 bit audio or 256 bit cryptography are the ones
> who can tell the difference very easily.
>
> To me, your example seems to try hard to make the case for a problem
> that won't exist in reality.
>
> Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the
> >correct< approach. It's tidy, systematic and precise. But that won't
> stop people from using something that's easier to deal with as I just
> had to google the µ character again.
>
> Let's also keep in mind that Coinbase has been using "bits" as the
> default for over 2 years now:
> https://blog.coinbase.com/bits-is-the-new-default-and-
> all-new-users-get-100-bits-for-free-9165f757594b
>
> Just from a linguistic standpoint, chances are we'll end up with bits
> anyway. Why fight it? We don't have a SI prefix educational mandate.
>
> Marcel
>
> On 14 December 2017 at 23:01, Natanael <natanael.l at gmail.com> wrote:
> >
> > Reposting /u/BashCo's post on reddit here, for visibility:
> >
> > ---8<---------------------------------------------------------------
> >
> >> Before anyone says 'bits' are too confusing because it's a computer
> >> science term, here's a list of homonyms
> >> [https://en.wikipedia.org/wiki/List_of_true_homonyms] that you use
> every
> >> day. Homonyms are fine because our brains are able to interpret language
> >> based on context, so it's a non-argument.
> >
> >
> > This ignores the fact that there exists multiple meanings of bits *within
> > the same context*, and that beginners likely can't tell them apart.
> >
> > Feel free to try it yourself - talk about Bitcoin "bits" of a particular
> > value with somebody who doesn't understand Bitcoin. Then explain that
> the
> > cryptography uses 256 bit keys. I would be surprised if you could find
> > somebody who would not be confused by that.
> >
> > Let's say a website says a song is 24 bits. Was that 24 bit audio
> resolution
> > or 24 bit price? Somebody writes about 256 bit keys, are that their size
> or
> > value?
> >
> > You guys here can probably tell the difference. Can everybody...? Bits
> will
> > cause confusion, because plenty of people will not be able to tell these
> > apart. They will not know WHEN to apply one definition or the other.
> >
> > https://www.reddit.com/r/bitcoin/comments/24m3nb/_/ch8gua7
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171215/491a9809/attachment.html>

2023-06-07 20:04:52 CEST

- reply

📅 Original date posted:2017-08-21
📝 Original message:A more forgiving option would be to have coins past a certain age evaporate
into mining rewards at some rate, rather than all at once. People might
find this approach easier to stomach as it avoids the "I waited 1 block to
many and all of my coins vanished" scenario.
Another approach would to demand that a certain minimum mining fee be
included that is calculated based on the age of an input like this idea:
https://www.reddit.com/r/Bitcoin/comments/35ilir/prioritizing_utxos_using_a_minimum_mining_fee/
This would result in the coins continuing to exist but not being
economically spendable, and therefore the UTXO information could be
archived.
On Mon, Aug 21, 2017 at 9:35 AM, Thomas Guyot-Sionnest via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 21/07/17 03:59 PM, Lucas Clemente Vella via bitcoin-dev wrote:
> > 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>>:
> >
> > [...] But the fact is that if we want to make bitcoins last forever,
> > we have the accept unbounded UTXO growth, which is unscalable. So
> > the only solution is to limit UTXO growth, meaning bitcoins cannot
> > last forever. This proposed solution however does not prevent
> > Bitcoin from lasting forever.
> >
> >
> > Unless there is a logical contradiction in this phrasing, the proposed
> > solution does not improves scalability:
> > - "Bitcoins lasting forever" implies "unscalable";
> > - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
> > forever";
> > - Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
> >
> > In practice, the only Bitcoin lost would be those whose owners forgot
> > about or has lost the keys, because everyone with a significant amount
> > of Bitcoins would always shift them around before it loses any luster (I
> > wouldn't bother to move my Bitcoins every 10 years). I don't know how to
> > estimate the percentage of UTXO is actually lost/forgotten, but I have
> > the opinion it isn't worth the hassle.
> >
> > As a side note, your estimate talks about block size, which is
> > determines blockchain size, which can be "safely" pruned (if you are not
> > considering new nodes might want to join the network, in case the full
> > history is needed to be stored somewhere). But UTXO size, albeit related
> > to the full blockchain size, is the part that currently can not be
> > safely pruned, so I don't see the relevance of the analysis.
>
> I think if we wanted to burn lost/stale coins a better approach would be
> returning them to miner's as a fee - there will always be lost coins and
> miners will be able to get that additional revenue stream as the mining
> reward halves. I also don't think we need to worry about doing a gradual
> value loss neither, we should just put a limit on UTXO age in block
> count (actually I would round it up to 210k blocks as explained below...).
>
>
> So lets say for example we decide to keep 5 210k blocks "generations"
> (that's over 15 years), then on the first block of the 6th generation
> all UTXO's from the 1st generation are invalidated and returned into a
> "pool".
>
> Given these (values in satoshis):
>
> Pool "P" (invalided UTXO minus total value reclaimed since last halving)
> Leftover blocks "B" (210,000 minus blocks mined since last halving)
>
> Then every mined block can reclaim FLOOR(P/B) satoshi in addition to
> miner's reward and tx fees.
>
> If the last block of a generation does not get the remainder of the pool
> (FLOOR(P/1) == P) it should get carried over.
>
>
> This would ensure we can clear old blocks after a few generations and
> that burnt/lost coins eventually get back in circulation. Also it would
> reduce the reliance of miners on actual TX fees.
>
>
> To avoid excessive miner reward initially, for the first few iterations
> the value of B could be increased (I haven't calculated the UTXO size of
> the first 210k blocks but it could be excessively high...) or the value
> each block can reclaim could be caped (so we would reclaim at an
> artificial capacity until the pool depletes...).
>
>
> Regards,
>
> --
> Thomas
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170821/476f95f6/attachment-0001.html>

2023-06-07 19:52:54 CEST

- reply

📅 Original date posted:2016-08-22
📝 Original message:It would be nice if the detached signer and the normal wallet could both
verify the correctness of generated addresses before you cause coins to be
sent there.
e.g. the hardware wallet could give its master public key to Bitcoin Core
and you can thereafter generate your receiving addresses on Core, with the
option to have the HW wallet validate them.
One of my biggest fears about using any wallet is the "whoops, cosmic ray
flipped a bit while producing receiving address; SFYL!" possibility. For
high value cold storage, I always generate my addresses on two independent
machines using two different pieces of software. Am I nuts for doing that?
With the above scheme, you are pretty well protected from losing money if
your HW wallet is defective. You could still lose it if the HW wallet was
evil of course, but that strikes me as much more likely to be discovered
quickly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160822/2f6378e9/attachment.html>