Moral Agent [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-07-26 to 2019-03-10
💬 Posted a total of 19 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1ghl954l59wm5pnv8j2y0ymmp6dt70kx2037e06wavfut7gjh68hqdgc6pd

Profile Code

nprofile1qqsytlj62l6zhd6qekre9z8jdasax4l8mr98clvha8wky79lyftarmsh2a42t

Author Public Key

npub1ghl954l59wm5pnv8j2y0ymmp6dt70kx2037e06wavfut7gjh68hqdgc6pd

Show more details

Last Notes

2023-06-07 18:16:49

- reply

📅 Original date posted:2019-03-10
📝 Original message:>Lock in a blockheight to get rid of it 10 years in the future.
And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to
the soft fork activation standard, with weight penalties as appropriate, so
there would be no difficulty spending them before the cutoff?
On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
> ------------------------------
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org <
> bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Matt Corallo
> via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 7:14 AM
> *To:* Sjors Provoost
> *Cc:* Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
> Aside from the complexity issues here, note that for a user to be
> adversely affect, they probably have to have pre-signed lock-timed
> transactions. Otherwise, in the crazy case that such a user exists, they
> should have no problem claiming the funds before activation of a soft-fork
> (and just switching to the swgwit equivalent, or some other equivalent
> scheme). Thus, adding additional restrictions like tx size limits will
> equally break txn.
>
> > On Mar 8, 2019, at 14:12, Sjors Provoost <sjors at sprovoost.nl> wrote:
> >
> >
> >> (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in Bitcoin
> today, and (3) lots of effort has gone into attempting to find practical
> use-cases for OP_CODESEPARATOR's specific construction, with no successes
> as of yet. I strongly, strongly disagree that the highly-unlikely remote
> possibility that someone created something before which could be rendered
> unspendable is sufficient reason to not fix a vulnerability in Bitcoin
> today.
> >>
> >>> I suggest an alternative whereby the execution of OP_CODESEPARATOR
> increases the transactions weight suitably as to temper the vulnerability
> caused by it. Alternatively there could be some sort of limit (maybe 1) on
> the maximum number of OP_CODESEPARATORs allowed to be executed per script,
> but that would require an argument as to why exceeding that limit isn't
> reasonable.
> >>
> >> You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of this
> argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined
> is rather difficult in any case.
> >
> > Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
> >
> > What if such a transaction:
> >
> > 1. must have one input; and
> > 2. must be smaller than 400 vbytes; and
> > 3. must spend from a UTXO older than fork activation
> >
> > Adding such a contextual check seems rather painful, perhaps comparable
> to nLockTime. Anything more specific than the above, e.g. counting the
> number of OP_CODESEPARATOR calls, seems like guess work.
> >
> > Transaction weight currently doesn't consider OP codes, it only
> considers if bytes are part of the witness. Changing that to something more
> akin to Ethereums gas pricing sounds too complicated to even consider.
> >
> >
> > I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
> >
> > Sjors
> >
>
> _______________________________________________
> 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/20190310/a82ceff6/attachment-0001.html>

2023-06-07 18:15:11

- reply

📅 Original date posted:2018-11-08
📝 Original message:>The problem will be to come up with an address authentication
procedure that will be convenient for users and widely supported, as a
result.
You could locally hash the destination address and from the hash derive a
BIP39 style list of 12 words for visual comparison. I would advise against
using color or graphics -- the brain is too good at "snapping" to an
expected perception when it is running in graphics mode instead of symbolic
mode.
On Thu, Nov 8, 2018 at 4:41 AM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Copying addresses to the clipboard should be discouraged, rather than
> > supported.
>
> Do you know any reasonably convenient mechanism for end user to
> transfer an address from, say, a web page to the wallet address
> input field ?
>
> The clipboard is just a low-hanging fruit for malware, anyway. It just
> the most easy point to replace an address. If the computer is
> compromized, malware can edit the web page in the memory of the browser
> process, for example. If it shown as QR code, malware can decode,
> detect that it is an address, and replace the image of QR code.
>
> I think that the only way to protect from this is to add some form of
> authentication for an address - 2fa (transfer checksum via second
> channel), visual fingerprints for addresses, that will are hard to
> detect (and hence, replace) for malware, signing the destination address
> with the key of an address that is already known and checking the
> signature, etc.
>
> The problem will be to come up with an address authentication procedure
> that will be convenient for users and widely supported, as a result.
> _______________________________________________
> 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/20181108/2123a8e6/attachment.html>

2023-06-07 18:14:23

- reply

📅 Original date posted:2018-09-14
📝 Original message:Thank you, and my apologies. I should have sent that link just to you and
not put everyone on cc.
On Fri, Sep 14, 2018 at 1:30 PM Andrew <onelineproof at gmail.com> wrote:
> (reposting to whole list instead of just him) @Moral Agent:
> Interesting proposal though it introduces some elements
> of proof of stake so it would be more controversial in my view. Also,
> something needs to be explained about how this would not create an
> attack where difficulty is frequently dropping by 25%, and suddenly we
> find ourselves with a very low difficulty and PoW attacks can easily
> happen. I need to analyse your proposal more, but I prefer to discuss
> it on your blog instead of here just to limit the side topics and
> focus only on my proposal.
>
> No one has yet given me a good reason for why not to support my proposal...
>
> On Fri, Sep 14, 2018 at 2:49 PM, Moral Agent <ethan.scruples at gmail.com>
> wrote:
> > You might be interested in an idea I wrote about that is in a similar
> spirit
> > here:
> >
> >
> https://medium.com/coinmonks/taming-large-miners-with-helper-blocks-6ae67ac242f6
> >
> > From the article:
> >
> > When a block is solved, it randomly selects one satoshi from the utxo set
> > and gives whomever controls that satoshi the power to generate a “Helper
> > Block”. The Helper Block commits to a subset of transactions for
> inclusion
> > in the next block. A miner can accept the Helper Block by including the
> > suggested transactions and giving the associated transaction fees to a
> > payment address specified in the Helper Block. Miners who do not use a
> > Helper Block must satisfy a 25% higher difficulty.
> >
> > On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> I discussed this more at bitcointalk:
> >> https://bitcointalk.org/index.php?topic=4998410.0
> >>
> >> The attacks I'm interested in preventing are not only selfish mining
> >> and collusion, but also more subtle attacks like block withholding,
> >> and in general anything that aims to drive out the competition in
> >> order to increase hashrate fraction. I also scrapped the idea of
> >> changing the block subsidies, and I am only focuses on fees.
> >>
> >> You can read more about the motivation and details in the bitcointalk
> >> thread, but my proposal in short would be to add the concept of
> >> "reserve fees". When a user makes a transaction, for each txout
> >> script, they can add parameters that specify the fraction of the total
> >> fee that is held in "reserve" and the time it is held in "reserve"
> >> (can set a limit of 2016 blocks). This "reserve" part of the fee will
> >> be paid to miners if the hashrate rises. So if hashrate is currently h
> >> and peak hashrate (from past year) is p, then for each period (1 day),
> >> a new hashrate is calculated h1, and if h1 > h, then the fraction
> >> (h1-h)/p from the reserve fees created in the past 2016 blocks will be
> >> released to miners for that period (spread out over the 144 blocks in
> >> that period). And this will keep happening as long as hashrate keeps
> >> rising, until the "contract" expires, and the leftover part can be
> >> used by the owner of the unspent output, but it can only be used for
> >> paying fees, not as inputs for future transactions (to save on block
> >> space).
> >>
> >> This should incentivize miners to not drive out the competition, since
> >> if they do, there will be less of these reserve fees given to miners.
> >> Yes in the end the miners will get all the fees, but with rising
> >> hashrate they get an unconditional subsidy that does not require
> >> transactions, thus more space for transactions with fees.
> >>
> >> I can make a formal BIP and pull request, but I need to know if there
> >> is interest in this. Now fees don't play such a large part of the
> >> block reward, but they will get more important, and this change
> >> wouldn't force anything (would be voluntary by each user), just miners
> >> have to agree to it with a soft fork (so they don't spend from the
> >> anyone-can-spend outputs used for reserve fees). Resource requirements
> >> for validation are quite small I believe.
> >>
> >> On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof at gmail.com> wrote:
> >> > As I understand, selfish mining is an attack where miners collude to
> >> > mine at a lower hashrate then with all miners working independently.
> >> > What are the current strategies used to prevent this and what are the
> >> > future plans?
> >> >
> >> > One idea I have is to let the block reward get "modulated" according
> >> > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
> >> > consisting of 144 blocks, h is the hashrate of the last 144 block (1
> >> > day) period, and r is the base subsidy (12.5 BTC currently). You can
> >> > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
> >> > peak you get the full reward. Otherwise you get less, down to a min of
> >> > 0.5 r.
> >> >
> >> > If miners were to collude to mine at a lower than peak hashrate, then
> >> > they may be able to do it profitably for 144 blocks, but after that,
> >> > the reward would get modulated and it wouldn't be so much in their
> >> > interest to continue mining at the lower hashrate.
> >> >
> >> > What flaws are there with this? I know it could be controversial due
> >> > to easier mining present for early miners, so maybe it would have to
> >> > be done in combination with a new more dynamic difficulty adjustment
> >> > algorithm. But I don't see how hashrate can continue rising
> >> > indefinitely, so a solution should be made for selfish mining.
> >> >
> >> > Also when subsidies stop and a fee market is needed, I guess a portion
> >> > of the fees can be withheld for later if hashrate is not at peak.
> >> >
> >> >
> >> > --
> >> > PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
> >>
> >>
> >>
> >> --
> >> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180914/c57899e8/attachment.html>

2023-06-07 18:14:20

- reply

📅 Original date posted:2018-09-14
📝 Original message:You might be interested in an idea I wrote about that is in a similar
spirit here:
https://medium.com/coinmonks/taming-large-miners-with-helper-blocks-6ae67ac242f6
>From the article:
When a block is solved, it randomly selects one satoshi from the utxo set
and gives whomever controls that satoshi the power to generate a “Helper
Block”. The Helper Block commits to a subset of transactions for inclusion
in the next block. A miner can accept the Helper Block by including the
suggested transactions and giving the associated transaction fees to a
payment address specified in the Helper Block. Miners who do not use a
Helper Block must satisfy a 25% higher difficulty.
On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I discussed this more at bitcointalk:
> https://bitcointalk.org/index.php?topic=4998410.0
>
> The attacks I'm interested in preventing are not only selfish mining
> and collusion, but also more subtle attacks like block withholding,
> and in general anything that aims to drive out the competition in
> order to increase hashrate fraction. I also scrapped the idea of
> changing the block subsidies, and I am only focuses on fees.
>
> You can read more about the motivation and details in the bitcointalk
> thread, but my proposal in short would be to add the concept of
> "reserve fees". When a user makes a transaction, for each txout
> script, they can add parameters that specify the fraction of the total
> fee that is held in "reserve" and the time it is held in "reserve"
> (can set a limit of 2016 blocks). This "reserve" part of the fee will
> be paid to miners if the hashrate rises. So if hashrate is currently h
> and peak hashrate (from past year) is p, then for each period (1 day),
> a new hashrate is calculated h1, and if h1 > h, then the fraction
> (h1-h)/p from the reserve fees created in the past 2016 blocks will be
> released to miners for that period (spread out over the 144 blocks in
> that period). And this will keep happening as long as hashrate keeps
> rising, until the "contract" expires, and the leftover part can be
> used by the owner of the unspent output, but it can only be used for
> paying fees, not as inputs for future transactions (to save on block
> space).
>
> This should incentivize miners to not drive out the competition, since
> if they do, there will be less of these reserve fees given to miners.
> Yes in the end the miners will get all the fees, but with rising
> hashrate they get an unconditional subsidy that does not require
> transactions, thus more space for transactions with fees.
>
> I can make a formal BIP and pull request, but I need to know if there
> is interest in this. Now fees don't play such a large part of the
> block reward, but they will get more important, and this change
> wouldn't force anything (would be voluntary by each user), just miners
> have to agree to it with a soft fork (so they don't spend from the
> anyone-can-spend outputs used for reserve fees). Resource requirements
> for validation are quite small I believe.
>
> On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof at gmail.com> wrote:
> > As I understand, selfish mining is an attack where miners collude to
> > mine at a lower hashrate then with all miners working independently.
> > What are the current strategies used to prevent this and what are the
> > future plans?
> >
> > One idea I have is to let the block reward get "modulated" according
> > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
> > consisting of 144 blocks, h is the hashrate of the last 144 block (1
> > day) period, and r is the base subsidy (12.5 BTC currently). You can
> > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
> > peak you get the full reward. Otherwise you get less, down to a min of
> > 0.5 r.
> >
> > If miners were to collude to mine at a lower than peak hashrate, then
> > they may be able to do it profitably for 144 blocks, but after that,
> > the reward would get modulated and it wouldn't be so much in their
> > interest to continue mining at the lower hashrate.
> >
> > What flaws are there with this? I know it could be controversial due
> > to easier mining present for early miners, so maybe it would have to
> > be done in combination with a new more dynamic difficulty adjustment
> > algorithm. But I don't see how hashrate can continue rising
> > indefinitely, so a solution should be made for selfish mining.
> >
> > Also when subsidies stop and a fee market is needed, I guess a portion
> > of the fees can be withheld for later if hashrate is not at peak.
> >
> >
> > --
> > PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
>
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
> _______________________________________________
> 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/20180914/22e64f75/attachment-0001.html>

2023-06-07 18:10:01

- 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 18:10:00

- 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 18:09:57

- 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 18:08:44

- 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 18:07:15

- reply

📅 Original date posted:2017-10-30
📝 Original message:Or like keyart:
https://pthree.org/2014/04/18/the-drunken-bishop-for-openpgp-keys/
Images would definitely be quicker to verify by a human, but I don't think
humans can RELIABLY verify anything close to 25 bytes through an image.
Our visual processing system is designed wrong for this purpose, since it
subconsciously "corrects" visual input to whatever we expect to see.
It isn't enough to say that any small change produces a "significantly"
different image. What you need is for it to be (practically) impossible to
construct an image that looks similar but is wrong, which is a far higher
standard. For example, any change to a private key renders a significantly
different address -- but it is possible for an attacker to grind their way
to a similar-looking address.
I would recommend displaying 16 words in a 4 x 4 grid, but otherwise with
no visual distractions.
For example, don't provide an image next to the words as a help. Don't use
colors to differentiate two different sets of 16 words. What will happen is
people will see a pattern that triggers a sensation of familiarity, and
they will not carefully verify all of the words -- which is what security
requires.
For higher security keys, you could grind an address with enough zeros at
the beginning to be expressed by fewer words. For example, you could grind
to an address that could be fully expressed with a 12 word (4 x 3) grid
that would be easier for a human to verify reliably.
On Mon, Oct 30, 2017 at 12:15 PM, Danny Thorpe <danny.thorpe at gmail.com>
wrote:
> Humans are very visually oriented, recognizing differences in images more
> easily than differences in text.
>
> What about generating an image based on the bytes of an address, using
> something like identicon, used by gravatar? Any small change to the text
> input produces a significantly different image.
>
> -Danny
>
> On Oct 30, 2017 7:43 AM, "Moral Agent via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> If you are going to rely on human verification of addresses, the best way
>> might be map it to words.
>>
>> For example, with a 6000 word list, a 25 byte address (with a checksum)
>> could be mapped to 16 words like this:
>>
>> vocally acquire removed unfounded
>> euphemism sanctuary sectional driving
>> entree freckles aloof vertebrae
>> scribble surround prelaw effort
>>
>> In my opinion, that is much faster to verify than this:
>>
>> 13gQFTYHuAcfnZjXo2NFsy1E8JGSLwXHCZ
>>
>> or
>>
>> bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
>>
>> Although I really do love Bech32.
>>
>> On Mon, Oct 30, 2017 at 9:13 AM, shiva sitamraju via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
>>> in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is
>>> 62 bytes ! This is very very long. This will create lot of usability
>>> problems in
>>>
>>> - Blockexplorers (atleast user should be visually able to compare in a
>>> transaction having multiple outputs which one his address)
>>> - Mobiles
>>> - Payment terminals
>>>
>>> From my limited understanding, the purpose of inventing a bitcoin
>>> address format is for usability and ease of identification (versus a ECDSA
>>> public key), While I get the error/checksum capabilities Bech32 brings, any
>>> user would prefer a 20 byte address with a checksum over an address that
>>> would wrap several lines !!
>>>
>>>
>>> On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
>>> thompson.benedictjames at gmail.com> wrote:
>>>
>>>> Checking the first few bytes of a Bitcoin Address should not be
>>>> considered sufficient for ensuring that it is correct as it takes less than
>>>> a second to generate a 3 character vanity address that matches the first 3
>>>> characters of an address.
>>>>
>>>> On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> When I copy and paste bitcoin address, I double check the first few
>>>>> bytes, to make sure I copied the correct one. This is to make sure some
>>>>> rogue software is not changing the address, or I incorrectly pasted the
>>>>> wrong address.
>>>>>
>>>>>
>>>>> With Bech32 address, its seems like in this department we are taking
>>>>> as step in the backward direction. With the traditional address, I could
>>>>> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
>>>>> and compare which is likely to be same anyway. Note that most users will
>>>>> only compare the first few bytes only (since addresses themselves are very
>>>>> long and will overflow in a mobile text box).
>>>>>
>>>>> Is there anyway to make the Bech32 addresses format more visually
>>>>> distinct (atleast the first few bytes) ?
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20171030/8f52182e/attachment-0001.html>

2023-06-07 18:07:14

- reply

📅 Original date posted:2017-10-30
📝 Original message:If you are going to rely on human verification of addresses, the best way
might be map it to words.
For example, with a 6000 word list, a 25 byte address (with a checksum)
could be mapped to 16 words like this:
vocally acquire removed unfounded
euphemism sanctuary sectional driving
entree freckles aloof vertebrae
scribble surround prelaw effort
In my opinion, that is much faster to verify than this:
13gQFTYHuAcfnZjXo2NFsy1E8JGSLwXHCZ
or
bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
Although I really do love Bech32.
On Mon, Oct 30, 2017 at 9:13 AM, shiva sitamraju via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
> in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is 62
> bytes ! This is very very long. This will create lot of usability problems
> in
>
> - Blockexplorers (atleast user should be visually able to compare in a
> transaction having multiple outputs which one his address)
> - Mobiles
> - Payment terminals
>
> From my limited understanding, the purpose of inventing a bitcoin address
> format is for usability and ease of identification (versus a ECDSA public
> key), While I get the error/checksum capabilities Bech32 brings, any user
> would prefer a 20 byte address with a checksum over an address that would
> wrap several lines !!
>
>
> On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
> thompson.benedictjames at gmail.com> wrote:
>
>> Checking the first few bytes of a Bitcoin Address should not be
>> considered sufficient for ensuring that it is correct as it takes less than
>> a second to generate a 3 character vanity address that matches the first 3
>> characters of an address.
>>
>> On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi,
>>>
>>> When I copy and paste bitcoin address, I double check the first few
>>> bytes, to make sure I copied the correct one. This is to make sure some
>>> rogue software is not changing the address, or I incorrectly pasted the
>>> wrong address.
>>>
>>>
>>> With Bech32 address, its seems like in this department we are taking as
>>> step in the backward direction. With the traditional address, I could
>>> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
>>> and compare which is likely to be same anyway. Note that most users will
>>> only compare the first few bytes only (since addresses themselves are very
>>> long and will overflow in a mobile text box).
>>>
>>> Is there anyway to make the Bech32 addresses format more visually
>>> distinct (atleast the first few bytes) ?
>>> _______________________________________________
>>> 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/20171030/612c7b18/attachment.html>

2023-06-07 18:06:57

- reply

📅 Original date posted:2017-10-11
📝 Original message:>Instead of there being one altcoin fighting to take hashpower from
bitcoin, there’d now be 2
Yes, there would be 2. One of which would (in the scenario we are
discussing) be producing blocks excruciatingly slowly but be the same in
all other aspects.
>changing the difficulty adjustment algorithm doesn’t solve the underlying
issue—hashpower not being aligned with users’ (or even its owners’)
interests
I disagree. Changing the difficulty adjustment algorithm could improve the
functionality of a chain, which could be an important prerequisite to using
and trading the tokens on the chain. This property could help keep the
price of the token high, which is what pressures hashpower to align with
user interests.
>And so yes, *if* this incentive problem can’t be solved, and the unaltered
bitcoin chain dies from disuse after suffering a hashpower attack,
especially a centrally and/or purposefully instigated one, then bitcoin
would be failed a failed project.
IF the incentive problem could not be resolved then Bitcoin would be a
failed project.
But here is a bit of good news.
Bitcoin has developers!
And those developers can publish a contingency plan!
And that contingency plan can be an emergency hard fork to a different
retarget algorithm.
And that emergency hard fork can gain consensus if it is broadly preferred
over the status quo.
If 90% of the hash power follows NYA, blocks are going to take 100 minutes
until difficulty adjusts after 4.5 months.
That is quite a handicap, even for a honey badger. Emergency hard fork
carries a risk, but depending on the scenario in November, it could be a
risk worth taking.
One more thing. If miners think they are going to succeed in starving the
legacy chain to death, they might be more likely to try. If they get a
credible signal that the legacy chain will react by changing the retarget
function and thereby be more likely to survive, they might feel less
committed to a strategy of starving the legacy chain. This could be
especially true if they are giving up profit for what they fervently hope
will be a short period of time.
On Wed, Oct 11, 2017 at 12:08 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> You phrase the question as if “deploying a hard fork to bitcoin” would
> protect the bitcoin chain from the attack. But that’s not what happens. If
> you are hard forking from the perspective of deployed nodes, you are an
> different ledger, regardless of circumstance or who did it. Instead of
> there being one altcoin fighting to take hashpower from bitcoin, there’d
> now be 2. It is not at all obvious to me that this would be a better
> outcome.
>
> If that isn’t reason enough, changing the difficulty adjustment algorithm
> doesn’t solve the underlying issue—hashpower not being aligned with users’
> (or even its owners’) interests. Propose a fix to the underlying cause and
> that might be worth considering, if it passes peer review. But without that
> you’d just be making the state of affairs arguably worse.
>
> And so yes, *if* this incentive problem can’t be solved, and the unaltered
> bitcoin chain dies from disuse after suffering a hashpower attack,
> especially a centrally and/or purposefully instigated one, then bitcoin
> would be failed a failed project.
>
> The thesis (and value proposition) of bitcoin is that a particular
> category of economic incentives can be used to solve the problem of
> creating a secure trustess ledger. If those incentives failed, then he
> thesis of bitcoin would have been experimentally falsified, yes. Maybe the
> incentives can be made better to save the project, but we’d have to fix the
> source of the problem not the symptoms.
>
> On Oct 10, 2017, at 6:44 PM, Ben Kloester <benkloester at gmail.com> wrote:
>
> Mark, this seems an awful lot like an answer of "no", to my question "Is
> there a contingency plan in the case that the incumbent chain following the
> Bitcoin Core consensus rules comes under 51% attack?" - is this a correct
> interpretation?
>
> In fact, beyond a no, it seems like a "no, and I disagree with the idea of
> creating one".
>
> So if Bitcoin comes under successful 51%, the project, in your vision, has
> simply failed?
>
> *Ben Kloester*
>
> On 10 October 2017 at 13:19, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The problem of fast acting but non vulnerable difficulty adjustment
>> algorithms is interesting. I would certainly like to see this space further
>> explored, and even have some ideas myself.
>>
>> However without commenting on the technical merits of this specific
>> proposal, I think it must be said upfront that the stated goal is not good.
>> The largest technical concern (ignoring governance) over B2X is that it is
>> a rushed, poorly reviewed hard fork. Hard forks should not be rushed, and
>> they should receive more than the usual level of expert and community
>> review.
>>
>> I’m that light, doing an even more rushed hard fork on an even newer idea
>> with even less review would be hypocritical at best. I would suggest
>> reframing as a hardfork wishlist research problem for the next properly
>> planned hard fork, if one occurs. You might also find the hardfork research
>> group a more accommodating venue for this discussion:
>>
>> https://bitcoinhardforkresearch.github.io/
>>
>> On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Sorry, my previous email did not have the plain text I intended.
>>
>> Background:
>>
>> The bitcoin difficulty algorithm does not seem to be a good one. If there
>> is a fork due to miners seeking maximum profit without due regard to
>> security, users, and nodes, the "better" coin could end up being the
>> minority chain. If 90% of hashrate is really going to at least initially
>> go
>> towards using SegWit2x, BTC would face 10x delays in confirmations
>> until the next difficulty adjustment, negatively affecting its price
>> relative
>> to BTC1, causing further delays from even more miner abandonment
>> (until the next adjustment). The 10% miners remaining on BTC do not
>> inevitably lose by staying to endure 10x delays because they have 10x
>> less competition, and the same situation applies to BTC1 miners. If the
>> prices are the same and stable, all seems well for everyone, other things
>> aside. But if the BTC price does not fall to reflect the decreased
>> hashrate,
>> he situation seems to be a big problem for both coins: BTC1 miners will
>> jump back to BTC when the difficulty adjustment occurs, initiating a
>> potentially never-ending oscillation between the two coins, potentially
>> worse than what BCH is experiencing. They will not issue coins too fast
>> like BCH because that is a side effect of the asymmetry in BCH's rise and
>> fall algorithm.
>>
>> Solution:
>>
>> Hard fork to implement a new difficulty algorithm that uses a simple
>> rolling
>> average with a much smaller window. Many small coins have done this as
>> a way to stop big miners from coming on and then suddenly leaving,
>> leaving
>> constant miners stuck with a high difficulty for the rest of a (long)
>> averaging
>> window. Even better, adjust the reward based on recent solvetimes to
>> motivate more mining (or less) if the solvetimes are too slow (or too
>> fast).
>> This will keep keep coin issuance rate perfectly on schedule with real
>> time.
>>
>> I recommend the following for Bitcoin, as fast, simple, and better than
>> any
>> other difficulty algorithm I'm aware of. This is the result of a lot of
>> work the
>> past year.
>>
>> === Begin difficulty algorithm ===
>> # Zawy v6 difficulty algorithm (modified for bitcoin)
>> # Unmodified Zawy v6 for alt coins:
>> # http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-
>> zawy-v1b.html
>> # All my failed attempts at something better:
>> # https://github.com/seredat/karbowanec/commit/231db5270acb2e6
>> 73a641a1800be910ce345668a
>> #
>> # Keep negative solvetimes to correct bad timestamps.
>> # Do not be tempted to use:
>> # next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
>> # ST= Solvetime, TS = timestamp
>>
>> # set constants until next hard fork:
>>
>> T=600; # coin's TargetSolvetime
>> N=30; # Averaging window. Smoother than N=15, faster response than N=60.
>> X=5;
>> limit = X^(2/N); # limit rise and fall in case of timestamp manipulation
>> adjust = 1/(1+0.67/N); # keeps avg solvetime on track
>>
>> # begin difficulty algorithm
>>
>> avg_ST=0; avg_D=0;
>> for ( i=height; i > height-N; i--) { # go through N most recent blocks
>> avg_ST += (TS[i] - TS[i-1]) / N;
>> avg_D += D[i]/N;
>> }
>> avg_ST = T*limit if avg_ST > T*limit;
>> avg_ST = T/limit if avg_ST < T/limit;
>>
>> next_D = avg_D * T / avg_ST * adjust;
>>
>> # Tim Olsen suggested changing reward to protect against hash attacks.
>> # Karbowanek coin suggested something similar.
>> # I could not find anything better than the simplest idea below.
>> # It was a great surprise that coin issuance rate came out perfect.
>> # BaseReward = coins per block
>>
>> next_reward = BaseReward * avg_ST / T;
>>
>> ======= end algo ====
>>
>> Due to the limit and keeping negative solvetimes in a true average,
>> timestamp errors resulting in negative solvetimes are corrected in the
>> next
>> block. Otherwise, one would need to do like Zcash and cause a 5-block
>> delay in the response by resorting to the median of past 11 blocks (MPT)
>> as the most recent timestamp, offsetting the timestamps from their
>> corresponding difficulties by 5 blocks. (it does not cause an averaging
>> problem, but it does cause a 5-block delay in the response.)
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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/20171011/c9ac3993/attachment-0001.html>

2023-06-07 18:04:52

- 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 18:04:42

- reply

📅 Original date posted:2017-07-21
📝 Original message:If we have a problem with a UTXO set that is too large, seems like maybe
the fair way to approach it is to enforce a limit on the growth of the UTXO
set.
Miners would eventually be forced to generate blocks that are UTXO neutral
and would factor that into their algorithm for prioritizing transactions.
Users who wish to generate a lot of outputs would need to find a buddy with
lots of inputs to consolidate and create a tumble-bit with them. A market
would spring up that would charge people for creating UTXOs and pay them
for disposing of UTXOs.
On Fri, Jul 21, 2017 at 3:59 PM, Lucas Clemente Vella via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
> 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.
>
> --
> Lucas Clemente Vella
> lvella at gmail.com
>
> _______________________________________________
> 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/20170721/6e75b99b/attachment.html>

2023-06-07 18:03:24

- reply

📅 Original date posted:2017-06-19
📝 Original message:Here is the text of a post to reddit from Feb 2017, discussing a similar
idea, and wondering if it could reduce the incentive to delay broadcast of
solved blocks:
# How an anchored Proof of Stake Sidechain can help the Bitcoin main chain
# Steps:
1. Soft fork Bitcoin to enable side chains
2. Create a side chain that is secured with Proof of Stake. Call blocks on
this chain "POS-blocks." The original chain is made of "POW-blocks."
3. Side chain mints one POS-block after each POW-block on the main chain,
and contains the hash of the POW-block, and the hash of the previous
POS-block. See diagram [here.](https://s32.postimg.org/916n9zxlx/Pos_Sf1.png
)
4. Side chain Minters must make a deposit in order to mint. If they mint an
invalid POS-block, they lose the deposit.
5. Side chain blocks are small enough to broadcast and validate quickly
(e.g. 100 - 300 KB).
6. Soft fork a new rule into Bitcoin that encourages POW-blocks to include
the hash of the prior POS-block. Specifically, penalize POW-blocks which do
not point to the prior POS-block by doubling the difficulty necessary for
them to be valid. Call POW-blocks which do not point to the prior POS-block
but are valid because of their very high POW "hard blocks."
In the following diagram POW2 and POW4 are valid because they point to the
prior POS-block and also satisfy the difficulty requirement. POW3 does not
point to the prior POS-bock, but is valid anyway because it contains proof
of work at twice the normal difficulty.
https://s27.postimg.org/6hc0b8ejn/Pos_Sf2.png
# Advantages:
1. Allow people who do not control ASICs to influence which transactions
happen.
2. Allow people who do not control ASICs to influence which chain gets
extended.
3. Reduce the incentive to selfish mine. Once a miner discovers a block,
they should broadcast it immediately in the hopes that a Minter will build
on it, because that is the most likely way their block will not go stale.
Miners will also immediately start trying to build a hard block. (Maybe
statistics could tell us what is the proper range for the Hardness
Multiplier. I guessed 2 would be good.)
4. Reduces the effective block interval while reducing the incidence of
stale blocks, empty blocks and SPV mining. After a POW-block is mined, it
is immediately broadcast to the network, seeking a qualified Minter to
extend it. Minters have a deposit, which they will lose if they mint an
invalid block. Pointing to the hash of an invalid POW-block would produce
an invalid minted block, so Minters have a strong incentive to completely
validate the POW-block before they mint on top of it. After validating,
they mint a block and broadcast it. While the Minter is validating the
previous POW-block, competing miners also have time to fully validate the
previous POW-block. By the time the Miners receive the POS-block, they know
what transactions they can and cannot include in their own block, because
the Minter only processes transactions on the side chain. There is less
reason to mine empty blocks, because there is adequate time to update the
mempool before mining the next soft block begins, and because hard blocks
take a long time to produce. The risks involved with mining on an
un-validated POS-block can be made small by the fact that there is a
deposit that will be destroyed if the POS-block is invalid. POS-blocks can
be validated quickly because they are small.
Here is a gantt chart of the schedule described above:
https://s22.postimg.org/hvnkyac5d/Pos_Sf3.png
5. Unlike a pure POS system, a cabal of early Stake holders cannot cheaply
hatch an alternate history. Much less imperative for nodes to go to a
trusted peer and ask whether the chain they are being fed is legitimate.
6. After step 6 above, the side chain would have essentially the same
security characteristics as the main chain, and could be used
interchangeably.
7. No hard fork required, and this soft fork could be deployed even if the
miners do not consent to it. Some hybrid POS system would be my
recommendation as preferable to simply changing POW algorithms in the face
of miners abusing their power.
8. Users can opt into the POS sidechain, and it can fully prove itself in
production before there is any attempt to anchor the main chain back to it.
Even if consensus cannot be obtained to execute step 6, the mere existence
of such a chain could deter tomfoolery on the part of POW miners, lest they
galvanize the community into throwing the switch.
Original reddit post here:
https://www.reddit.com/r/Bitcoin/comments/5vy4qc/how_an_anchored_proof_of_stake_sidechain_can_help/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170619/a77f0079/attachment.html>

2023-06-07 18:03:03

- reply

📅 Original date posted:2017-06-23
📝 Original message:>Miners who are able to deal with the bandwidth caused by drivechain coffee
transactions will profit from these transactions, whereas smaller and more
geographically distributed miners will not. Those miners will, in turn,
build faster ASICs and buy more electricity and drive out smaller players.
I think you are conflating 3 different (though overlapping) groups:
1. Block header generators. These need 'good internet' meaning very low
latency, reasonable bandwidth, good place in network (e.g. FIBRE or mining
backbone). They need reliable computers with enough RAM and CPU to validate
prior blocks promptly and immediately assemble new blocks.
2. Hashers. These need cheap electricity, access to economical uses of
waste heat, cheap mining hardware. e.g. IOT electric water heater.
3. ASIC manufacturers. These need lots of capital, etc.
It might be helpful to keep these three groups distinct in your mind and
conversation, and to use the protocol as a crowbar to pry them into
separate people, or at a minimum make it economically possible to
participate in one role without needing to participate in the other two. If
different, geographically and politically dispersed groups are helping
perform these functions, it aids decentralization.
On Fri, Jun 23, 2017 at 10:19 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > They would certainly not be cheap, because they are relatively more
> expensive due to the extra depreciation cost.
>
> This depends on how long you expect to keep money on a side chain and how
> many transactions you plan on doing. Inflation is a great way of paying
> PoS / PoB miners - that cannot introduce issues with consolidation. If
> you design the inflation schedule correctly, it should be balance
> transaction costs *precisely*. Indeed, you can calculate the exact amount
> of inflation needed to guarantee that a side chain is always exactly 10
> times cheaper than bitcoin.
>
> >As I posted to bitcoin-discuss last week, I support UTXO commitments for
> sidechains.
>
> Indeed, I think side chain nodes should always be fast-synced from 6 month
> old commitments and thus be ephemeral, cheap, and *never *appropriate for
> long term storage. This would provide the best possible incentive
> structure to keep the main chain secure, paid for with high clearing fees,
> etc.
>
> > I don't think that blind merged mining messes with the main chain's
> incentive structure
>
> The critical issue is that we cannot introduce protocol changes that
> *further *incentivize geographical and institutional consolidation.
> Miners who are able to deal with the bandwidth caused by drivechain coffee
> transactions will profit from these transactions, whereas smaller and more
> geographically distributed miners will not. Those miners will, in turn,
> build faster ASICs and buy more electricity and drive out smaller players.
> I think this is *abundantly *clear, and is the primary motivation
> behind preserving block size limits.
>
> If this premise is false (which it may be), or is skewed so as to damage
> bitcoin as a whole (could be as well), then that needs to be demonstrated
> *first*.
>
> The lightning model does the opposite of this. Miners watch fees
> increase and coming from an *orthoganal* protocol that cannot cause further
> centralization.
>
> One problem is that the main chain also *must* grow in response to
> bandwidth, or the disadvantages of using the main chain will weaken
> financial support and hashrate securing it. I believe this is also true,
> and that a "balancing act" will be Bitcoin's norm until we adopt something
> like BIP103 - which provides a steady and appropriate growth.
>
>
>
>
>
> On Thu, Jun 22, 2017 at 4:30 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>
>> Responses inline.
>>
>> On 6/22/2017 9:45 AM, Erik Aronesty wrote:
>>
>> Users would tolerate depreciation because the intention is to have a
>> cheap way of transacting using a two-way pegged chain that isn't controlled
>> by miners. Who cares about some minor depreciation when the purpose of the
>> chain is to do cheap secure transactions forever?
>>
>>
>> Thus far you've claimed that these transactions would be "cheap", "[not]
>> controlled by miners", and "secure".
>>
>> They would certainly not be cheap, because they are relatively more
>> expensive due to the extra depreciation cost.
>>
>> I also doubt that they would be free of control by miners. 51% hashrate
>> can always filter out any message they want from anywhere.
>>
>> For the same reason, I don't understand why they would be any more or
>> less secure.
>>
>> So I think your way is just a more expensive way of accomplishing
>> basically the same result.
>>
>>
>> Add in UTXO commitments and you've got a system that is cheap and
>> secure-enough for transfer. storage and accumulation of a ledger... before
>> moving in to the main chain.
>>
>>
>> As I posted to bitcoin-discuss last week, I support UTXO commitments for
>> sidechains.
>>
>> Seems better to me than messing with the main chain's incentive structure
>> via merged mining.
>>
>>
>> I don't think that blind merged mining messes with the main chain's
>> incentive structure. Miners are free to ignore the sidechain (and yet still
>> get paid the same as other miners), as are all mainchain users.
>>
>> Paul
>>
>>
>> On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc <truthcoin at gmail.com> wrote:
>>
>>> Hi Erik,
>>>
>>> I don't think that your design is competitive. Why would users tolerate
>>> a depreciation of X% per year, when there are alternatives which do not
>>> require such depreciation? It seems to me that none would.
>>>
>>> Paul
>>>
>>> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>>>
>>> - a proof-of-burn sidechain is the ultimate two-way peg. you have to
>>> burn bitcoin *or* side-chain tokens to mine the side chain. the size of
>>> the burn is the degree of security. i actually wrote code to do
>>> randomized blind burns where you have a poisson distribution
>>> (non-deterministic selected burn). there is no way to game it... it's
>>> very similar to algorand - but it uses burns instead of staking
>>>
>>> - you can then have a secure sidechain that issues a mining reward in
>>> sidechain tokens, which can be aggrregated and redeemed for bitcoins. the
>>> result of this is that any bitcoins held in the sidechain depreciate in
>>> value at a rate of X% per year. this deflation rate pays for increased
>>> security
>>>
>>> - logically this functions like an alt coin, with high inflation and
>>> cheap transactions. but the altcoin is pegged to bitcoin's price because
>>> of the pool of unredeemed bitcoins held within the side chain.
>>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin at gmail.com>
>>> wrote:
>>>
>>>> Hi Erik,
>>>>
>>>> As you know:
>>>>
>>>> 1. If a sidechain is merged mined it basically grows out of the
>>>> existing Bitcoin mining network. If it has a different PoW algorithm it is
>>>> a new mining network.
>>>> 2. The security (ie, hashrate) of any mining network would be
>>>> determined by the total economic value of the block. In Bitcoin this is
>>>> (subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens it
>>>> would only be (tx_fees)*price.
>>>>
>>>> Unfortunately the two have a nasty correlation which can lead to a
>>>> disastrous self-fulfilling prophecy: users will avoid a network that is too
>>>> insecure; and if users avoid using a network, they will stop paying txn
>>>> fees and so the quantity (tx_fees)*price falls toward zero, erasing the
>>>> network's security. So it is quite problematic and I recommend just biting
>>>> the bullet and going with merged mining instead.
>>>>
>>>> And, the point may be moot. Bitcoin miners may decide that, given their
>>>> expertise in seeking out cheap sources of power/cooling, they might as well
>>>> mine both/all chains. So your suggestion may not achieve your desired
>>>> result (and would, meanwhile, consume more of the economy's resources --
>>>> some of these would not contribute even to a higher hashrate).
>>>>
>>>> Paul
>>>>
>>>>
>>>>
>>>>
>>>> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>>>
>>>> It would be nice to be able to enforce that a drivechain *not* have the
>>>> same POW as bitcoin.
>>>>
>>>> I suspect this is the only way to be sure that a drivechain doesn't
>>>> destabilize the main chain and push more power to miners that already have
>>>> too much power.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> 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/20170623/1d48aca3/attachment-0001.html>

2023-06-07 17:52:54

- 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>

2023-06-07 17:52:01

- reply

📅 Original date posted:2016-07-28
📝 Original message:If there is concern about the
block-with-valid-header-but-invalid-transactions-spam-attack, I have a
strategy using sync flags that may drastically reduce the problem.
Sync flags documented here:
https://github.com/moral-agent/sync_flags/blob/master/README.md)
The strategy to defeat the above attack is illustrated here:
https://s32.postimg.org/e94tqdqat/sync_flag_invalid_block.png
The key is to relax the requirement that a flag commit to a completely
valid block. The flag is valid if it commits to a valid block header, even
if the block body is invalid.
>From the perspective of an individual miner, they can safely commence
mining a flag the moment they obtain (or discover) a valid block header.
As soon as the spam is discovered, miners can choose to either abandon the
flag and return to mining on the previous block, or they can continue
mining on the flag.
It's difficult for me to game out which of these strategies would be
preferable. My first thought is that the miners should have the incentive
to mine whichever option has the fewest miners, which should result in a
50/50 split.
However, the miners who continue mining the flag have a chance of ending up
in a situation where they mine the flag before anyone mines a valid block.
If this happens, it is sub-optimal for them. They can start mining for the
next valid block but if someone else broadcasts a valid block header they
will be in the same pickle that miners under the current protocol are: they
must either keep mining for a valid block, or SPV mine the newly arrived
block while they do validation. The third option, of mining a flag, is not
available to them, because the flag has already been mined for this cycle.
As a result of the above, it may be most rational for miners to (upon
learning that they are mining a flag on top of an invalid block) split
their hashpower unevenly between the flag and continuing to mine for a
valid block. The hashpower split reflects their estimates of the cost of
the above negative outcome. I think the split would be pretty close to
50/50, but deviations from 50/50 would not necessarily be bad. For example,
if they split 52/48, with more hashpower toward finding the valid block
instead of the flag, then that decreases the likelyhood that the flag will
be discovered before the next valid block, which is good for all of the
miners. So it's a nice positive feedback.
*****
This approach mostly neutralizes the harm done by the (currently very rare)
invalid block spam attack. As a kind of amazing side effect, the work done
to produce the spam is incorporated into the blockchain cumulative Proof of
Work, and the spammer is not paid for this contribution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160728/cd41259c/attachment.html>

2023-06-07 17:52:00

- reply

📅 Original date posted:2016-07-27
📝 Original message:I made a repo to be a home for sync_flags here:
https://github.com/moral-agent/sync_flags
If you see any personally identifying information, please be a good sport
and let me know. I'm a nobody, but I'd still prefer not to get doxxed.
Two changes to the proposal (see repo for explanations)
1. Sync flags now would have the same difficulty as blocks.
2. Blocks now donate to 5 sync flags instead of 1
I also added comments about selfish mining and invalid block spam.
Response to replies:
tomz at freedommail.ch: What is the advantage over optimistic mining?
1. Sync flags can be somewhat smaller than block headers.
2. Sync flags improve variance by doubling the number of chances to win
3. Sync flags can be distinguished from normal blocks, so SPV clients can
ignore them as confirmations.
4. Sync flags reward all miners equally. Optimistic blocks have to be empty
unless you mined the previous block, which damages decentralization.
5. Sync flags result in fewer empty blocks, smoothing out resource usage
6. Sync flags make transaction stuffing by miners either obvious or costly
7. Sync flags give miners something to do while they wait for attractive
transactions to appear.
erik at q32.com: Flags will be selfish mined.
I agree that flags would likely be selfish mined. I have modified the
proposal to say that flags have the same POW target as blocks, so the
selfish mining vulnerability should be equal to the current protocol.
martijn.meijering at mevs.nl: Why expect more selfish mining?
Because flags had small POW relative to blocks. After you find a block, why
not hide it while you take a crack at the flag?
tier.nolan at gmail.com: Effect is same as mandatory empty blocks.
Not quite the same:
1. Sync flags can be somewhat smaller than block headers.
2. Sync flags can be distinguished from normal blocks, so SPV clients can
ignore them as confirmations.
3. Sync flags make transaction stuffing by miners either obvious or costly
4. No one pays for empty blocks, except for the block subsidy. Some miners
may choose to only mine the non-empty blocks, resulting in
hashpower-for-rent to make mischief or hashpower that oscillates, creating
a situation where empty blocks take longer to mine than full blocks.
nickodell at gmail.com: Payout mechanism incompatible with certain mining pools
Hopefully some kind of smart contract structure could be implemented as you
suggested.
On Tue, Jul 26, 2016 at 6:03 PM, Nick ODell <nickodell at gmail.com> wrote:
> Moral,
>
> Mining the sync flag isn't compatible with the payout structure of non
> hot-wallet pools like Eligius or decentralized pools like p2pool.
> Those need the ability to split a reward among multiple parties.
> Instead of giving an address to send the funds to, you could include
> the hash of the transaction allowed to spend the sync flag output.
> You'd have to zero the previous outpoint of the transaction before
> hashing, since you don't know what the hash of the coinbase ten blocks
> from now will be.
>
>
> On Tue, Jul 26, 2016 at 6:47 AM, Moral Agent via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I posted this to /r/bitcoin yesterday but it got minimal comments. One
> uses
> > suggested I try the mailing list so here it is:
> >
> > The idea presented here could have the following benefits:
> >
> > 1. Improve mining decentralization
> > 2. Reduce variance in mining profitability
> > 3. Reduce or eliminate SPV mined blocks
> > 4. Reduce or eliminate empty blocks, smoothing out resource usage
> > 5. Reduce or eliminate the latency bottleneck on throughput
> > 6. Make transaction stuffing by miners be either obvious or costly
> > 7. Gives miners something to do while they wait for attractive
> transactions
> > to appear
> > 8. Can be easily done with a soft fork
> >
> > #Basic idea:
> >
> > Ideally, all miners would begin hashing the next block at exactly the
> same
> > time. Miners with a head start are more profitable, and the techniques
> that
> > help miners receive and validate blocks quickly create centralization
> > pressure.
> >
> > What if there was something that acted like the starting flag at a race,
> > which could suddenly wave and cause all of the miners to simultaneously
> > begin hashing the next block?
> >
> > #Implementation:
> >
> > Let a sync flag be a message consisting of:
> >
> > 1. Hash of the previous block.
> > 2. Bitcoin address
> > 3. Nonce
> >
> > This tiny message could propagate through the network at maximum speed.
> If
> > miners had to include the hash of this flag in the next block, then all
> > miners wait for this flag, and when it suddenly spread through the
> network,
> > all miners could simultaneously begin hashing the next block.
> >
> > The sync flag should not be produced too quickly. You want to give
> everyone
> > enough time to be ready to hash the next block. Let's say that the hash
> of
> > the sync flag is a proof of work that is targeted for 2 minutes.
> >
> > To fund this proof of work, the protocol is modified to demand that the
> > block produced 10 blocks after the sync flag must allocate 25% of the
> block
> > reward to the address published by the sync flag. In this way, sync flags
> > are produced in 2 minutes, and blocks are produced in 8 minutes, with 10
> > minutes total.
> >
> >
> > Illustration 1: https://s32.postimg.org/wzg0hs8lx/sync_flag.png)
> >
> > Illustration 2: https://s32.postimg.org/vc5y9yz4l/sync_flag2.png
> >
> >
> > #Explanation of reasons:
> >
> > **Improve mining decentralization**
> >
> > One factor driving centralization is the imperative miners have to
> achieve
> > low latency in receiving and validating blocks. To achieve low latency,
> it
> > helps a lot if you have expensive low-latency internet connections,
> curated
> > network topologies, and large pools that have a plausible chance of
> finding
> > consecutive blocks. If miners are expected (or forced) to validate a
> block
> > prior to mining on top of it, the rational end game would be to outsource
> > the validation step to a trusted third party specialist who can choose
> > optimal locations on the globe to serve their (multiple?) mining pool
> > clients. These are all less decentralized than the mining situation
> Satoshi
> > and others imagined.
> >
> > **Reduce variance in mining revenue**
> >
> > Currently, there are about 144 opportunities per day for a pool or solo
> > miner to see any revenue at all. With sync flags, that number doubles to
> > 288. Sync flags are only worth 25% of what a block is worth, but this
> still
> > represents a significant reduction in variance. This variance is one
> factor
> > causing solo miners to group into pools, and large pools to be more
> > attractive than small pools.
> >
> > **Reduce or eliminate SPV mined blocks**
> >
> > One way miners have sought to make
> > full-block-transmission-and-validation-latency irrelevant has been
> through
> > "SPV" mining or "Head-first" mining. There is some evidence that these
> > techniques may be widely used, and that badgering the miners about it is
> an
> > ineffective strategy to stop them.
> >
> > In SPV mining, a miner would simply accept any block header that shows
> the
> > correct proof of work. All other validation is entrusted to other miners.
> > This practice is quite dangerous as the SPV miners can wander off on some
> > invalid chain, taking SPV nodes with them. If this occurs during a soft
> > fork, these blind miners can also fool unupgraded fully validating nodes
> > into following them.
> >
> > "Head-first" mining means that miners start hashing as soon as they
> receive
> > the block header with the correct POW, but they simultaneously validate
> the
> > block, and abandon it if is not valid. I consider this to be pretty
> safe, as
> > it strictly limits the length of an invalid chain that can result from
> > mining without validating. However, "Head-first" mining can plausibly
> > generate 2 or 3 confirmations of an invalid block. It would be nice if
> such
> > confirmations did not happen.
> >
> > The sync flag technique is similar to head-first mining, but rather than
> > hashing the next block while they wait for transmission and validation of
> > the prior block, they hash the sync flag. Nodes can differentiate between
> > sync flags and blocks, and can ignore sync flags when counting
> > confirmations.
> >
> > **Reduce or eliminate empty blocks, smoothing out resource usage**
> >
> > Empty blocks are another consequence of SPV or Headfirst mining, because
> the
> > miner cannot safely include any transactions in the block they are
> hashing
> > until they have validated the prior block. By delaying the start of
> hashing
> > the next block until after validation, miners would not have this reason
> to
> > mine empty blocks.
> >
> > **Reduce or eliminate the latency bottleneck on throughput**
> >
> > Centralization pressure due to latency issues has been a major
> preoccupation
> > over the last year. If latency mattered much less, it could represent a
> > scalability improvement that could enable higher throughput.
> >
> > **Make transaction stuffing by miners be either obvious or costly**
> >
> > Currently, the entire block reward goes to the miner who mines it. One
> > unfortunate consequence of this is that it does not cost the miner
> anything
> > to covertly stuff the block with transactions. These transactions would
> pay
> > fees and be indistinguishable from ordinary transactions, but the fees
> are
> > paid by the miner and then immediately returned to the miner.
> >
> > With sync flags, the miner must share these transaction fees with the
> > address contained in the sync flag 10 blocks prior. This means that if
> the
> > miner gives the transactions a normal looking fee, they will incur a cost
> > that will be paid to the sync flag. If the miner wants to avoid this,
> they
> > must give their stuffing transactions a zero fee, which provides evidence
> > that they are stuffing.
> >
> > Also, when miners stuff with transactions using a zero fee, they cannot
> > manipulate the perception of how much fee it takes to get into a block.
> >
> > Note that miners could still try to covertly stuff blocks that will pay a
> > sync flag that they themselves created. if this is a big concern, it can
> be
> > addressed by forcing blocks to pay multiple sync flags.
> >
> > **Gives miners something to do while they wait for attractive
> transactions
> > to appear**
> >
> > From the Montreal scaling workshop last year, we have [this
> > talk](
> https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf
> )
> > which worried that as the block subsidy reduced and transactions became a
> > more important fraction of miner revenue, it would be rational for
> miners to
> > turn off their mining equipment for a "gap" phase after a block is
> found, to
> > allow time to pass as more lucrative transactions entered the mempool.
> >
> > I don't know whether this will actually happen. The presence of a
> suitable
> > backlog of transactions would help prevent this dynamic from emerging.
> But
> > if such idling behavior was the optima mining strategy, it could create a
> > serious vulnerability. Idle hands are the devil's workshop as the saying
> > goes, and idle miners represent a pool of inert hashpower that is
> available
> > to rent for all kinds of destabilizing purposes. It would be better to
> put
> > those miners to profitable work mining a sync flag while they wait.
> >
> > Also, this creates a more efficient price discovery mechanism for
> > transactions, because you allow transactions paying high fees time to
> arrive
> > to the marketplace, rather than take whatever anyone is offering because
> all
> > the "good" transactions got gobbled up in the prior block.
> >
> > **Can be easily done with a soft fork**
> >
> > Although a hard fork would be more efficient, sync flags could be easily
> > implemented using a soft fork by introducing the following rule:
> >
> > Every block must include a transaction which pays 25% of the block
> reward to
> > the address given by the 10th previous sync flag, and commits to the
> hash of
> > the 1st previous sync flag.
> >
> > _______________________________________________
> > 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/20160727/6ccd1a29/attachment-0001.html>

2023-06-07 17:51:58

- reply

📅 Original date posted:2016-07-26
📝 Original message:I posted this to /r/bitcoin yesterday but it got minimal comments. One uses
suggested I try the mailing list so here it is:
The idea presented here could have the following benefits:
1. Improve mining decentralization
2. Reduce variance in mining profitability
3. Reduce or eliminate SPV mined blocks
4. Reduce or eliminate empty blocks, smoothing out resource usage
5. Reduce or eliminate the latency bottleneck on throughput
6. Make transaction stuffing by miners be either obvious or costly
7. Gives miners something to do while they wait for attractive transactions
to appear
8. Can be easily done with a soft fork
#Basic idea:
Ideally, all miners would begin hashing the next block at exactly the same
time. Miners with a head start are more profitable, and the techniques that
help miners receive and validate blocks quickly create centralization
pressure.
What if there was something that acted like the starting flag at a race,
which could suddenly wave and cause all of the miners to simultaneously
begin hashing the next block?
#Implementation:
Let a sync flag be a message consisting of:
1. Hash of the previous block.
2. Bitcoin address
3. Nonce
This tiny message could propagate through the network at maximum speed. If
miners had to include the hash of this flag in the next block, then all
miners wait for this flag, and when it suddenly spread through the network,
all miners could simultaneously begin hashing the next block.
The sync flag should not be produced too quickly. You want to give everyone
enough time to be ready to hash the next block. Let's say that the hash of
the sync flag is a proof of work that is targeted for 2 minutes.
To fund this proof of work, the protocol is modified to demand that the
block produced 10 blocks after the sync flag must allocate 25% of the block
reward to the address published by the sync flag. In this way, sync flags
are produced in 2 minutes, and blocks are produced in 8 minutes, with 10
minutes total.
Illustration 1: https://s32.postimg.org/wzg0hs8lx/sync_flag.png)
Illustration 2: https://s32.postimg.org/vc5y9yz4l/sync_flag2.png
#Explanation of reasons:
**Improve mining decentralization**
One factor driving centralization is the imperative miners have to achieve
low latency in receiving and validating blocks. To achieve low latency, it
helps a lot if you have expensive low-latency internet connections, curated
network topologies, and large pools that have a plausible chance of finding
consecutive blocks. If miners are expected (or forced) to validate a block
prior to mining on top of it, the rational end game would be to outsource
the validation step to a trusted third party specialist who can choose
optimal locations on the globe to serve their (multiple?) mining pool
clients. These are all less decentralized than the mining situation Satoshi
and others imagined.
**Reduce variance in mining revenue**
Currently, there are about 144 opportunities per day for a pool or solo
miner to see any revenue at all. With sync flags, that number doubles to
288. Sync flags are only worth 25% of what a block is worth, but this still
represents a significant reduction in variance. This variance is one factor
causing solo miners to group into pools, and large pools to be more
attractive than small pools.
**Reduce or eliminate SPV mined blocks**
One way miners have sought to make
full-block-transmission-and-validation-latency irrelevant has been through
"SPV" mining or "Head-first" mining. There is some evidence that these
techniques may be widely used, and that badgering the miners about it is an
ineffective strategy to stop them.
In SPV mining, a miner would simply accept any block header that shows the
correct proof of work. All other validation is entrusted to other miners.
This practice is quite dangerous as the SPV miners can wander off on some
invalid chain, taking SPV nodes with them. If this occurs during a soft
fork, these blind miners can also fool unupgraded fully validating nodes
into following them.
"Head-first" mining means that miners start hashing as soon as they receive
the block header with the correct POW, but they simultaneously validate the
block, and abandon it if is not valid. I consider this to be pretty safe,
as it strictly limits the length of an invalid chain that can result from
mining without validating. However, "Head-first" mining can plausibly
generate 2 or 3 confirmations of an invalid block. It would be nice if such
confirmations did not happen.
The sync flag technique is similar to head-first mining, but rather than
hashing the next block while they wait for transmission and validation of
the prior block, they hash the sync flag. Nodes can differentiate between
sync flags and blocks, and can ignore sync flags when counting
confirmations.
**Reduce or eliminate empty blocks, smoothing out resource usage**
Empty blocks are another consequence of SPV or Headfirst mining, because
the miner cannot safely include any transactions in the block they are
hashing until they have validated the prior block. By delaying the start of
hashing the next block until after validation, miners would not have this
reason to mine empty blocks.
**Reduce or eliminate the latency bottleneck on throughput**
Centralization pressure due to latency issues has been a major
preoccupation over the last year. If latency mattered much less, it could
represent a scalability improvement that could enable higher throughput.
**Make transaction stuffing by miners be either obvious or costly**
Currently, the entire block reward goes to the miner who mines it. One
unfortunate consequence of this is that it does not cost the miner anything
to covertly stuff the block with transactions. These transactions would pay
fees and be indistinguishable from ordinary transactions, but the fees are
paid by the miner and then immediately returned to the miner.
With sync flags, the miner must share these transaction fees with the
address contained in the sync flag 10 blocks prior. This means that if the
miner gives the transactions a normal looking fee, they will incur a cost
that will be paid to the sync flag. If the miner wants to avoid this, they
must give their stuffing transactions a zero fee, which provides evidence
that they are stuffing.
Also, when miners stuff with transactions using a zero fee, they cannot
manipulate the perception of how much fee it takes to get into a block.
Note that miners could still try to covertly stuff blocks that will pay a
sync flag that they themselves created. if this is a big concern, it can be
addressed by forcing blocks to pay multiple sync flags.
**Gives miners something to do while they wait for attractive transactions
to appear**
>From the Montreal scaling workshop last year, we have [this talk](
https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf)
which worried that as the block subsidy reduced and transactions became a
more important fraction of miner revenue, it would be rational for miners
to turn off their mining equipment for a "gap" phase after a block is
found, to allow time to pass as more lucrative transactions entered the
mempool.
I don't know whether this will actually happen. The presence of a suitable
backlog of transactions would help prevent this dynamic from emerging. But
if such idling behavior was the optima mining strategy, it could create a
serious vulnerability. Idle hands are the devil's workshop as the saying
goes, and idle miners represent a pool of inert hashpower that is available
to rent for all kinds of destabilizing purposes. It would be better to put
those miners to profitable work mining a sync flag while they wait.
Also, this creates a more efficient price discovery mechanism for
transactions, because you allow transactions paying high fees time to
arrive to the marketplace, rather than take whatever anyone is offering
because all the "good" transactions got gobbled up in the prior block.
**Can be easily done with a soft fork**
Although a hard fork would be more efficient, sync flags could be easily
implemented using a soft fork by introducing the following rule:
Every block must include a transaction which pays 25% of the block reward
to the address given by the 10th previous sync flag, and commits to the
hash of the 1st previous sync flag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160726/28026960/attachment.html>