rhavar at protonmail.com [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-02-12 to 2022-08-25
💬 Posted a total of 28 messages
📚 Participated in the following categories: bitcoin-dev, PROPOSAL
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:13:03

- reply

📅 Original date posted:2022-08-24
📝 Original message:I'd strongly suggest not using CSV. Especially for a standard. I've worked with it as an interchange format many a times, and it's always been a clusterfuck.
Right off the bat, you have stuff like "The fields may be quoted, but this is unnecessary as the first comma in the line will always be the delimiter" which invariably leads to some implementations doing it, some implementations not doing it, and others that are intolerant of the other way.
And you have also made the classic mistake of not strictly defining escape rules. So everyone will pick their own (e.g. some will \, escape commas, others will not cause it's quoted and escape quotes, and others will assume no escaping is required since its the last column in a csv).
Over time it morphs into its own mini-monster that introduces so much pain.
On a similar note, allowing alternatives (like: txid>index vs txid:index) provides no benefit, but creates additional work for implementations (who quite likely only test formats they produce) and future incompatibilities.
I know everyone loves to hate on it, but really (line-separated?) json is the way to go.
{ "tx": "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎", "label": "wow, such label" }
{ "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b", "txout": 4, "label": "omg this is so easy to parse" }
{ "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b", "txin": 0, "label": "wow this is going to be extensible as well" }
-Ryan
------- Original Message -------
On Wednesday, August 24th, 2022 at 2:18 AM, Craig Raw via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I would like to propose a BIP that specifies a format for the export and import of labels from a wallet. While transferring access to funds across wallet applications has been made simple through standards such as BIP39, wallet labels remain siloed and difficult to extract despite their value, particularly in a privacy context.
>
> The proposed format is a simple two column CSV file, with the reference to a transaction, address, input or output in the first column, and the label in the second column. CSV was chosen for its wide accessibility, especially to users without specific technical expertise. Similarly, the CSV file may be compressed using the ZIP format, and optionally encrypted using AES.
>
> The full text of the BIP can be found at https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki and also copied below.
>
> Feedback is appreciated.
>
> Thanks,
> Craig Raw
>
> ---
>
> <pre>
> BIP: wallet-labels
> Layer: Applications
> Title: Wallet Labels Export Format
> Author: Craig Raw <craig at sparrowwallet.com>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels
> Status: Draft
> Type: Informational
> Created: 2022-08-23
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This document specifies a format for the export of labels that may be attached to the transactions, addresses, input and outputs in a wallet.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> The export and import of funds across different Bitcoin wallet applications is well defined through standards such as BIP39, BIP32, BIP44 etc.
> These standards are well supported and allow users to move easily between different wallets.
> There is, however, no defined standard to transfer any labels the user may have applied to the transactions, addresses, inputs or outputs in their wallet.
> The UTXO model that Bitcoin uses makes these labels particularly valuable as they may indicate the source of funds, whether received externally or as a result of change from a prior transaction.
> In both cases, care must be taken when spending to avoid undesirable leaks of private information.
> Labels provide valuable guidance in this regard, and have even become mandatory when spending in several Bitcoin wallets.
> Allowing users to export their labels in a standardized way ensures that they do not experience lock-in to a particular wallet application.
> In addition, by using common formats, this BIP seeks to make manual or bulk management of labels accessible to users without specific technical expertise.
>
> ==Specification==
>
> In order to make the import and export of labels as widely accessible as possible, this BIP uses the comma separated values (CSV) format, which is widely supported by consumer, business, and scientific applications.
> Although the technical specification of CSV in RFC4180 is not always followed, the application of the format in this BIP is simple enough that compatibility should not present a problem.
> Moreover, the simplicity and forgiving nature of CSV (over for example JSON) lends itself well to bulk label editing using spreadsheet and text editing tools.
>
> A CSV export of labels from a wallet must be a UTF-8 encoded text file, containing one record per line, with records containing two fields delimited by a comma.
> The fields may be quoted, but this is unnecessary, as the first comma in the line will always be the delimiter.
> The first line in the file is a header, and should be ignored on import.
> Thereafter, each line represents a record that refers to a label applied in the wallet.
> The order in which these records appear is not defined.
>
> The first field in the record contains a reference to the transaction, address, input or output in the wallet.
> This is specified as one of the following:
> * Transaction ID (<tt>txid</tt>)
> * Address
> * Input (rendered as <tt>txid<index</tt>)
> * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
>
> The second field contains the label applied to the reference.
> Exporting applications may omit records with no labels or labels of zero length.
> Files exported should use the <tt>.csv</tt> file extension.
>
> In order to reduce file size while retaining wide accessibility, the CSV file may be compressed using the ZIP file format, using the <tt>.zip</tt> file extension.
> This <tt>.zip</tt> file may optionally be encrypted using either AES-128 or AES-256 encryption, which is supported by numerous applications including Winzip and 7-zip.
> In order to ensure that weak encryption does not proliferate, importers following this standard must refuse to import <tt>.zip</tt> files encrypted with the weaker Zip 2.0 standard.
> The textual representation of the wallet's extended public key (as defined by BIP32, with an <tt>xpub</tt> header) should be used as the password.
>
> ==Importing==
>
> When importing, a naive algorithm may simply match against any reference, but it is possible to disambiguate between transactions, addresses, inputs and outputs.
> For example in the following pseudocode:
> <pre>
> if reference length < 64
> Set address label
> else if reference length == 64
> Set transaction label
> else if reference contains '<'
> Set input label
> else
> Set output label
> </pre>
>
> Importing applications may truncate labels if necessary.
>
> ==Test Vectors==
>
> The following fragment represents a wallet label export:
> <pre>
> Reference,Label
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction
> 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎<0,Input
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎>0,Output
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output (alternative)
> </pre>
>
> ==Reference Implementation==
>
> TBD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220824/f1fcaed1/attachment-0001.html>

2023-06-07 18:18:32

- reply

📅 Original date posted:2019-06-10
📝 Original message:What about this? We store a RBU ("relay bandwidth used") with each transaction in the mempool. Where RBU is defined as the size of the transaction + RBU of all transactions it has evicted.
For a replacement to be valid: The feerate must be higher than what it's evicting, and the fee must be greater than minRelayFee*RBU.
-Ryan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, June 9, 2019 7:07 AM, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
>
> > Matt Corallo lf-lists at mattcorallo.com writes:
> >
> > > 2. wrt rule 4, I'd like to see a calculation of worst-case free
> > > relay. I think we're already not in a great place, but maybe it's
> > > worth it or maybe there is some other way to reduce this cost
> > > (intuitively it looks like this proposal could make things very,
> > > very, very bad).
> > >
> >
> > I think you can currently create a tx at 1 sat/byte, have it
> > propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand
> > times before your transaction gets mined.
>
> Yes, the current incremental relay fee in Bitcoin Core is 0.00001000
> BTC/KvB.
>
> > If that's true, I don't think this proposal makes it worse.
>
> Here's a scenario that I think shows it being at least 20x worse.
>
> Let's imagine that you create two transactions:
>
> tx0: A very small transaction (~100 vbytes) that's just 1-in, 1-out.
> At the minimum relay fee, this costs 0.00000100 BTC
>
> tx1: A child of that transaction that's very large (~100,000 vbytes,
> or almost 400,000 bytes using special scripts that allow witness
> stuffing). At the minimum relay fee, this costs 0.00100000 BTC
>
> Under the current rules, if an attacker wants to fee-bump tx0 by the
> minimum incremental fee (a trivial amount, ~0.00000100 BTC), the
> attacker's replacement also needs to pay for the eviction of the huge
> child tx1 by that same incremental fee (~0.00100000).
>
> Thus the replacement would cost the attacker a minimum of about
> 0.00100100 (~1 mBTC) for the original transactions and 0.00100100 for
> the replacement (about 2 mBTC total).
>
> The attacker could then spend another 1 mBTC re-attaching the child and
> yet another 1 mBTC bumping again, incuring about a 2 mBTC cost per
> replacement round. At writing, 2 mBTC is about $14.00 USD---an amount
> that's probably enough to deter most attacks at scale.
>
> Under the new proposed rule 6, Mallory's replacement cost would be the
> amount to get the small tx0 to near the top of the mempool (say
> 0.00100000 BTC/KvB, so 0.00010000 BTC total). Because this would evict
> the expensive child, it would actually reduce the original amount paid
> by the attacker by 90% compared to the previous section's example where
> using RBF increased the original costs by 100%.
>
> The 0.1 mBTC cost of this attack is about $0.70 USD today for the
> roughly the same data relay use as one round of the currently possible
> attack. In short, if I haven't misplaced a decimal point or made some
> other mistake, I think the proposed rule 6 would result in approximately
> a 95% reduction in the cost paid by an attacker for wasting 400,000
> bytes of bandwidth per node (x60,000 nodes = 24 GB across all nodes, not
> counting INV overhead).
>
> Although the attacker might only get one replacement per block per
> transaction pair out of this version of the attack, they could execute
> the attack many times in parallel using different tranaction pairs. If
> this is combined with the treadmill leapfrogging Russell O'Connor
> described elsewhere in this thread, the attack could possibly be
> repeated multiple times per block per transaction pair at only slightly
> increased cost (to pay the increasing next-block transaction fees).
>
> > > > 3. wrt rule 5, I'd like to see benchmarks, it's probably a pretty
> > > > nasty DoS attack, but it may also be the case that is (a) not worse
> > > > than other fundamental issues or (b) sufficiently expensive.
> > > >
> >
> > I thought we still meet rule 5 in practice since bitcoind will never
> > even accept a tree of unconfirmed txs which is > 100 txs? That would
> > still stand, it's just that we'd still consider a replacement.
>
> Although the BIP125 limit is 100, Bitcoin Core's current default is 25.[1]
> (When RBF was implemented in Bitcoin Core, transaction ancestry was only
> tracked for purposes of ensuring valid transaction ordering within
> blocks; later when CPFP was implemented, ancestry was additionally used
> to calculate each transaction's package fee---the value of it and all
> its unconfirmed ancestors. This requires more computation to update
> the mempool metadata when the ancestry graph changes.)
>
> Again, I'd be thinking here of something similar to O'Connor's
> treadmilling attack where replacements can push each other out of the
> top mempool and so create enough churn for a CPU exhaustion attack.
>
> > > > Obviously there is also a ton more client-side knowledge required
> > > > and complexity to RBF decisions here than other previous, more
> > > > narrowly-targeted proposals.
> > > > I'd say from the lightning side it's as simple as a normal RBF policy
> > > > until you get within a few blocks of a deadline, then you increase the
> > > > fees until it's well within reach of the next block.
>
> It's already hard for wallet software to determine whether or not its
> transactions have successfully been relayed. This proposal requires LN
> wallets not only be able to guess where the next-block feerate boundary
> is in other nodes' individual mempools (now and in the future for the
> time it takes the transaction to propagate to ~100% of miners), but it
> possibly requires that under the condition that the LN wallet can't
> guess too low because it might not get another chance for relay in the
> limited time available before contract expiration.
>
> On top of that, there's O'Connor's suggestion to increase treadmilling
> costs by only allowing bumps if they're in the top-half of the
> next-block mempool.
>
> Considered that way, I worry that these constraints produce a recipe for
> paying extremely high feerates. If that's an actual risk, is that
> actually significantly better than dealing with the existing transaction
> pinning issue where one needs to pay a high total fee in order to evict
> a bunch of junk descendents? Paying lots of fees may not be the optimal
> solution to the problem of having to pay lots of fees. :-)
>
> -Dave
>
> [1] Excerpt from bitcoind -help-debug :
>
> -limitancestorcount=<n>
>
> Do not accept transactions if number of in-mempool ancestors is <n> or
>
> more (default: 25)
>
>
> -limitdescendantcount=<n>
>
> Do not accept transactions if any ancestor would have <n> or more
>
> in-mempool descendants (default: 25)
>
>
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:18:31

- reply

📅 Original date posted:2019-06-02
📝 Original message:+1
>From an incentive-compatible point of view, miners should be accepting transactions that increase the amount of fees that can achieved with 4M weight of transactions, so it seems like a pretty sane plan.
One common problem I've run into with RBF is since you're using RBF you probably want to low ball fees. With good coin selection (*cough* coinsayer.com *cough*), it'll use that opportunity to consolidate inputs. But now let's say fees suddenly spike (pretty common), you might want to fee bump your now stuck transaction. But now that fees are high, it doesn't make sense to be consolidating so ideally you'd just replace it with a much smaller transaction (that pays higher fee rate).
So if anything, I think your proposal doesn't go far enough. I think even in "non-emergency" cases, we could get away with removing the requirement to increase the absolute fee (as long as the fee rate is increased); which also makes it incentive compatible if you assume a reasonable fee-market.
I realize it does open potential DoS vectors, but they seem reasonably small.
-Ryan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, June 1, 2019 9:41 PM, Rusty Russell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I want to propose a modification to rules 3, 4 and 5 of BIP 125:
>
> To remind you of BIP 125:
> 3. The replacement transaction pays an absolute fee of at least the sum
> paid by the original transactions.
>
> 4. The replacement transaction must also pay for its own bandwidth at
> or above the rate set by the node's minimum relay fee setting.
>
> 5. The number of original transactions to be replaced and their
> descendant transactions which will be evicted from the mempool must not
> exceed a total of 100 transactions.
>
> The new "emergency RBF" rule:
>
> 6. If the original transaction was not in the first 4,000,000 weight
> units of the fee-ordered mempool and the replacement transaction is,
> rules 3, 4 and 5 do not apply.
>
> This means:
>
> 1. RBF can be used in adversarial conditions, such as lightning
> unilateral closes where the adversary has another valid transaction
> and can use it to block yours. This is a problem when we allow
> differential fees between the two current lightning transactions
> (aka "Bring Your Own Fees").
>
> 2. RBF can be used without knowing about miner's mempools, or that the
> above problem is occurring. One simply gets close to the required
> maximum height for lightning timeout, and bids to get into the next
> block.
>
> 3. This proposal does not open any significant new ability to RBF spam,
> since it can (usually) only be used once. IIUC bitcoind won't
> accept more that 100 descendents of an unconfirmed tx anyway.
>
> 4. This proposal makes RBF miner-incentive compatible. Currently the
> protocol tells miners they shouldn't accept the highest bidding tx
> for the good of the network. This conflict is particularly sharp
> in the case where the replacement tx would be immediately minable,
> which this proposal addresses.
>
> Unfortunately I haven't found time to code this up in bitcoin, but if
> there's positive response I can try.
>
> Thanks for reading!
> Rusty.
>
>
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:16:05

- reply

📅 Original date posted:2019-01-30
📝 Original message:On Tuesday, January 29, 2019 6:06 PM, James MacWhyte <keatonatron at gmail.com> wrote:
> I'm not convinced this is a valid concern, at least not valid enough to add extra complications to the process.
Signing a transaction is something a wallet needs to be able to do anyway AND at the final-step. And actually a signed transaction is _simpler_ because it's more standard and way format to send and validate.
> The sender could still refuse to sign the final transaction after they see the recipient's in-/outputs; "show me yours and I'll show you mine" isn't much of a spy deterrent, and nothing here prevents a DOS attack.
If the sender refuses to sign the final transaction, the receiver just propagates the template transaction which pays the receiver! So it's a pretty weak attack.
The only real attack is that the sender could double-spend the template-transaction before it's propagated, but the cost of doing this isn't free, as at the very least you need to pay the transaction fees of creating a double spend. It's not an amazingly good defence, but it's good enough that it's unlikely to get abused (and an attacker would only learn a single utxo of the receiver) .
> As an implementor, I would suggest keeping the protocol as simple as possible. By dropping the signing in the first step, the recipient doesn't need to maintain the ability to lookup and verify unspent outputs.
Being able to verify a transaction tends to be pretty simple in practice. (e.g. `testmempoolaccept` in bitcoin core's wallet) but if it's really hard for a receiver to do, it can easily just not do it... (and assume the template transaction is valid even if it's not).
But I suspect this actually complicates the job for the receiver, because now you have to deal with transaction malleability as they can now give you an invalid transaction, you sign it and then they malleate into a valid transaction with a different txid. So if you're tracking the transaction by txid, you'll get really confused...).
> It also would enforce the increased privacy, which the sender obviously wants if they are going down this path
I guess that's a valid concern. A sender might want to make a payment, but *only* if it can be done via a bustapay, while the current spec doesn't support that.
But there's no way that justifies removing the protection for receivers. Without some _basic_ protection, every company that takes bustapayments will just get constantly attacked by a simple costless `wget` that leaks their wallet utxos...
The only viable way I can see, would be the sender pays the first part of his invoice in lightning. And then pays the rest with a bustapay. Now the anti-spy thing is the fact the first part of the invoice was already paid.
But with so many moving parts, no one is ever going to implement that :P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190130/dbe00339/attachment.html>

2023-06-07 18:15:03

- reply

📅 Original date posted:2018-10-21
📝 Original message:On Sunday, October 21, 2018 2:54 PM, Pavol Rusnak <stick at satoshilabs.com> wrote:
> Your solution in the second part of the email does not solve the problem you indicated in the first part of your email.
Sorry, I'm not quite sure what parts you are referring to. I assume you might mean my first paragraph, so I'll try explain myself a bit clearer how this makes it harder to find wallet boundaries.
Right now you can generally tell if a transaction is using bip69 or not (as long as you account for the probability that it's randomly sorted to accidentally be bip69). And generally wallets are consistent if they use bip69 or not.
This can often make it massively easier to detect what is change and not. Let's say I'm clustering a wallet and know they're using a wallet that always uses bip69, and I'm looking at a transaction in that cluster and trying to guess which is the change and which is not. There's a lot of things you can use to assign a probability. The most obvious thing is looking at the amount of significant-digits of the output amounts (if they vary a lot, change tends to be the one with more), but a much more powerful one is looking at how the outputs are spent (and if they end up spend-linking back into the original cluster).
So let's say that the transaction output is spent by a non-bip69 transaction -- I right away know that it's going to (almost certainly) be a different wallet (e.g. the destination).
My (shower-thoughty) "solution" fixes this problem, because an outside observer has no way of knowing if a transaction is using deterministic sorting or not, so can not use this information to establish wallet boundaries.
--
On somewhat of a tangent I was actually fortunate enough to have someone with access to the biggest(?) bitcoin analysis service help me with a few experiments. While I was genuinely taken aback by how accurate some of their analysis can be, I also found it pretty easy to trick -- implying it relies heavily on some fragile heuristics.
I don't like to be alarmist, but I worry a lot about the fungibility of bitcoin when we have such effective blockchain analysis and a *LOT* of the ecosystem using a centralized analytics service. And in fact, we're already starting to see some minor effects of this (e.g. people already know that if they gamble their funds, they'll probably have trouble using an exchange later). And I don't think we're too far from the point where any "unidentified" bitcoin is instantly flagged as "suspicious" (and for instance, requires more explaining for by exchanges) potentially seriously harming bitcoin fungibility and it's value determined also by it's history.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181022/6473e67a/attachment.html>

2023-06-07 18:15:03

- reply

📅 Original date posted:2018-10-21
📝 Original message:Right now it's just *way* too easy to spot the boundaries between different wallets. There's a lot of things that contribute to that, but the one that concerns me the most is the way wallets sort transaction inputs and outputs.
Some wallets and protocols (especially HW wallets) have a strong preference for deterministic sorting (i.e. using bip69), while other wallets have a lot of objections to this.
I'm not sure I fully understand the objections, but I think they can be summarized as "during the transition period there will be a lot of privacy loss" and "if in the future someone wants to use bitcoin in a way that's not compatible with bip69 their transactions will stick out heavily".
I wonder if this impasse could be solved with deterministic sorting, but based on a semi-secret. Like `sortingSecret = hmac(walletSeed, "sortingSecret")` and then there's a standardized sort order based on the sortingSecret. e.g. sort inputs/output by the `hash(data || sortingSecret)`. Wallets could come up with their own way of computing (or storing) the "sortingSecret" but from there it's standardized.
I has the advantages of deterministic sorting (as long as you know the sortingSecret) you can verify it's done correctly and externally looks totally randomized.
Am I missing something, or could this be the way forward?
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181021/0c512d27/attachment.html>

2023-06-07 18:10:44

- reply

📅 Original date posted:2018-02-12
📝 Original message:> This lead me to ponder whether the intuitive metric of satoshi/byte is, in fact, game
>theory optimal. Possibly over the short term it is, but over a longer period, those
> wishing to increase the longevity of proof of work in general might wish to consider
> more progressive fee approaches.
The constraining factor for blocks is the max-block weight. So miners are already optimizing for the right thing (creating a block that gives the most immediate reward). If miners want to start a cartel-like behavior of charging more for more value-transfer it would be incredibly harmful and even likely promote centralization (the cartel would likely not look kindly on any miner who doesn't follow their rules, and perhaps start orphaning their blocks).
Now I guess in theory you could add consensus rules that apply restrictions on the amount of "value transfer" in a block, such that miners are motivated to charge more for high-value transactions. However there's going to be almost 0 appetite from anyone to want to do anything like this, and the amount of unintended and harmful side effects would be profound. (Personally, I'd lose any interest in bitcoin if such a change was ever instated)
-Ryan

-------- Original Message --------
On February 12, 2018 12:23 PM, Melvin Carvalho via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>On 21 December 2017 at 22:30, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
>>I asked adam back at hcpp how the block chain would be secured in the long term, once the reward goes away. The base idea has always been that fees would replace the block reward.
>>At that time fees were approximately 10% of the block reward, but have now reached 45%, with 50% potentially being crossed soon
>>
>>https://fork.lol/reward/feepct
>>
>>While this bodes well for the long term security of the coin, I think there is some legitimate concern that the fee per tx is prohibitive for some use cases, at this point in the adoption curve.
>>
>>Observations of segwit adoption show around 10% at this point
>>
>>http://segwit.party/charts/
>>
>>Watching the mempool shows that the congestion is at a peak, though it's quite possible this will come down over the long weekend. I wonder if this is of concern to some.
>>
>>https://dedi.jochen-hoenicke.de/queue/more/#24h
>>
>>I thought these data points may be of interest and are mainly FYI. Though if further discussion is deemed appropriate, it would be interesting to hear thoughts.
>>
>Just following up on this, for no other reason than I've had my eyes glued to these stats the last few weeks. I'll share a few more stats links.
>Mempool has come down significantly, as have fees. Tho, of course, this could spike any time.
>
>https://bitinfocharts.com/bitcoin/
>Typically fees are :
>
> $2.06 on tx $543 (median) # 0.38%
> $3.47 on tx $75,000 (mean) # 0.005%
>Aside: An observation on this. High value transactors seems to be getting a much better deal, than the mean. This lead me to ponder whether the intuitive metric of satoshi/byte is, in fact, game theory optimal. Possibly over the short term it is, but over a longer period, those wishing to increase the longevity of proof of work in general might wish to consider more progressive fee approaches. Naively, it might be possible to imagine some kind of gaussian distribution that picks tx according to a blended combination of sats/byte and %transacted. Perhaps something for miners and fee estimation algorithms to develop over time.
>Segwit adoption has increased, and anecdotal evidence shows that trend to continue. The release of 0.16 will I think also have a positive effect.
>Finally, I came across this wonderful site that shows lightning network adoption on mainnet
>
>http://shabang.io/
>LN is increasing well. Some blocks are not far off 1% lightning funding, which I think bodes well. I'll go out on a limb and predict that over 1% of btc tx will be lightning based by year end.
>Since such posts are not strictly development, I'll keep them to a minimum. However, I hope these stats provide useful data points for project evolution.
>
>