Tom Harding [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-07 to 2023-05-12
💬 Posted a total of 136 messages
📚 Participated in the following categories: Bitcoin-development, BIP draft, bitcoin-dev, BIP-draft, BIP Proposal, patch, Mempool spam
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1msef5qkfwz4t7qacwxz775wgdtlytph78g2g2z903x90874u263sypmwjy

Profile Code

nprofile1qqsdcv56qtyhp24lqwu8rp0028yx4lj9smlr59y9pzhcnzhnl279dgcltmfhu

Author Public Key

npub1msef5qkfwz4t7qacwxz775wgdtlytph78g2g2z903x90874u263sypmwjy

Show more details

Last Notes

2023-06-07 23:21:40

- reply

📅 Original date posted:2023-05-11
🗒️ Summary of this message: Transactions with high fees can be replaced by multiple transactions with lower fees, but they may take longer to be processed.
📝 Original message:On 5/11/23 04:02, vjudeu via bitcoin-dev wrote:
> Every transaction paying "fee > sum" can be replaced by N transactions
> paying "fee <= sum", where the sum of all fees will be the same.
These N transactions will generally have a lower feerate than the
original, and the lowest feerate of the N could be drastically lower
than the original.
As a group, in the current environment (for example), they could take
days or weeks longer to be mined than the original.

2023-06-07 23:21:33

- reply

📅 Original date posted:2023-05-09
🗒️ Summary of this message: A proposal to add a "padding" rule to Bitcoin transactions to prevent dust attacks may not be effective as users can easily evade it.
📝 Original message:On 5/9/23 09:32, Erik Aronesty via bitcoin-dev wrote:
> obviously it's easy enough to evade if every non-economic user simply > keeps enough bitcoin around and sends it back to himself > > so
maybeit's a useless idea? but maybe that's enough of a hassle to stop >
people (it certainly breaks ordinals, since it can never be 1 sat)
Padding the change is not just a hassle, it requires holding extra BTC
in a hot wallet, which has a cost.
Spenders could also get around the rule by paying miners off-network,
but having to do so would be an appropriate penalty for broadcasting a
non-economic transaction.

2023-06-07 23:21:30

- reply

📅 Original date posted:2023-05-09
🗒️ Summary of this message: Rejecting transactions with fees higher than outputs may prevent reasonable transfers. Off-network payments could be penalized to maintain on-chain transactions.
📝 Original message:> And prevent perfectly reasonable transfers of value
Such a transfer can only be reasonable when off-chain value is attached
to the coins. A rule like this is the embodiment of the philosophy that
the Bitcoin network is for onchain-economic transactions.
Parties could get around the rule by paying miners off-network, and that
would be an appropriate penalty for using non-onchain-economic transactions.
On 5/8/23 10:13, Michael Folkson via bitcoin-dev wrote:
> > probably easier just to reject any transaction where the fee is
> higher than the sum of the outputs
>
> And prevent perfectly reasonable transfers of value and attempted
> Lightning channel closes during fee spikes? If I *want* to close my
> Lightning channel during a protracted fee spike where I have to pay an
> onchain transaction fee greater than the amount I am receiving you
> want to stop me doing that? You are impinging on a valid use case as
> well as requiring a consensus rule change.
>
> -- Michael Folkson
> Email: michaelfolkson at protonmail.com <http://protonmail.com/>
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> probably easier just to reject any transaction where the fee is
>> higher than the sum of the outputs
>>
>>
>>
>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi guys,
>>
>> I think everyone on this list knows what has happened to the
>> Bitcoin mempool during the past 96 hours. Due to side projects
>> such as BRC-20 having such a high volume, real bitcoin
>> transactions are being priced out and that is what is causing the
>> massive congestion that has arguable not been seen since December
>> 2017. I do not count the March 2021 congestion because that was
>> only with 1-5sat/vbyte.
>>
>> Such justifiably worthless ("worthless" is not even my word -
>> that's how its creator described them[1]) tokens threaten the
>> smooth and normal use of the Bitcoin network as a peer-to-pear
>> digital currency, as it was intended to be used as.
>>
>> If the volume does not die down over the next few weeks, should
>> we take an action? The bitcoin network is a triumvirate of
>> developers, miners, and users. Considering that miners are
>> largely the entities at fault for allowing the system to be
>> abused like this, the harmony of Bitcoin transactions is being
>> disrupted right now. Although this community has a strong history
>> of not putting its fingers into pies unless absolutely necessary
>> - an example being during the block size wars and Segwit - should
>> similar action be taken now, in the form of i) BIPs and/or ii)
>> commits into the Bitcoin Core codebase, to curtail the loophole
>> in BIP 342 (which defines the validation rules for Taproot
>> scripts) which has allowed these unintended consequences?
>>
>> An alternative would be to enforce this "censorship" at the node
>> level and introduce a run-time option to instantly prune all
>> non-standard Taproot transactions. This will be easier to
>> implement, but won't hit the road until minimum next release.
>>
>> I know that some people will have their criticisms about this,
>> absolutists/libertarians/maximum-freedom advocates, which is
>> fine, but we need to find a solution for this that fits
>> everyone's common ground. We indirectly allowed this to happen,
>> which previously wasn't possible before. So we also have a
>> responsibility to do something to ensure that this kind of
>> congestion can never happen again using Taproot.
>>
>> -Ali
>>
>> ---
>>
>> [1]:
>> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
>> <https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp>
>> _______________________________________________
>> 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/20230509/54e03016/attachment.html>

2023-06-07 23:11:45

- reply

📅 Original date posted:2022-07-12
📝 Original message:On 7/11/22 15:26, Peter Todd via bitcoin-dev wrote:
>
> Anyway, designing protocols for "price go up forever" hopium is a bad idea.
Yet that is the design, and it's a good one. It is equivalent to
relying on bitcoin to steadily grow in utility vs. fiat currencies.
If it fails to do that, there's no point anyway.

2023-06-07 18:19:38

- reply

📅 Original date posted:2019-07-22
📝 Original message:On 7/20/19 10:46 AM, Matt Corallo via bitcoin-dev wrote:
> (less trustful and privacy-violating) alternative
> over the coming years.
The same paper that established the 'privacy-violating' conventional
wisdom presented mitigations which have seen little exploration.
https://eprint.iacr.org/2014/763.pdf
Meanwhile we have custodial LN, the L-BTC altcoin and, today, a massive
push into infrastructure for fully custodial accounts.

2023-06-07 17:59:44

- reply

📅 Original date posted:2017-04-08
📝 Original message:On Apr 7, 2017 12:42, "Gregory Maxwell" <greg at xiph.org> wrote:
On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> A network in which many nodes maintain a transaction index also enables a
> class of light node applications that ask peers to prove existence and
> spentness of TXO's.
Only with the additional commitment structure such as those proposed
by Peter Todd in his stxo/txo commitment designs, e.g.
https://petertodd.org/2016/delayed-txo-commitments
Light nodes are improved by detecting invalid transactions, even before
they are mined.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/18ee4220/attachment.html>

2023-06-07 17:59:43

- reply

📅 Original date posted:2017-04-07
📝 Original message:On Apr 6, 2017 6:31 PM, "Tomas via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Bitcrust just uses a *transaction-index*, where outputs can be looked up
regardless of being spent.
A network in which many nodes maintain a transaction index also enables a
class of light node applications that ask peers to prove existence and
spentness of TXO's.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/fab42b2a/attachment.html>

2023-06-07 17:58:34

- reply

📅 Original date posted:2017-03-30
📝 Original message:On 3/30/2017 9:14 AM, David Vorick wrote:
> On Mar 30, 2017 12:04 PM, "Tom Harding via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Raystonn,
>
> Your logic is very hard to dispute. An important special case is
> small miners.
>
> Small miners use pools exactly because they want smaller, more
> frequent payments.
>
> Rising fees force them to take payments less frequently, and will
> only tend to make more of them give up.
>
> With fees rising superlinearly, this centralizing effect is much
> stronger than the oft-cited worry of small miners joining large
> pools to decrease orphan rates.
>
>
> Miners get paid on average once every ten minutes. The size of fees
> and the number of fee transactions does not change the payout rate.
>
> Further, we are very far from the point (in my appraisal) where fees
> are high enough to block home users from using the network.
>
> Bitcoin has many high-value use cases such as savings. We should not
> throw away the core innovation of monetary sovereignty in pursuit of
> supporting 0.1% of the world's daily transactions.
>
Owners of small mining rigs get paid by pools, generally using regular
transactions that pay regular fees (p2pool is an exception that pays
directly from coinbase). The point is the unintended consequences are
directly at odds with one of the justifications offered for small blocks
- miner centralization.
This is a special case. Raystonn's general point was that high fees
will lead to fewer economic actors overall, and therefore fewer full nodes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/1d2447b2/attachment.html>

2023-06-07 17:58:33

- reply

📅 Original date posted:2017-03-30
📝 Original message:Raystonn,
Your logic is very hard to dispute. An important special case is small
miners.
Small miners use pools exactly because they want smaller, more frequent
payments.
Rising fees force them to take payments less frequently, and will only tend
to make more of them give up.
With fees rising superlinearly, this centralizing effect is much stronger
than the oft-cited worry of small miners joining large pools to decrease
orphan rates.
On Mar 29, 2017 15:01, "Raystonn . via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Low node costs are a good goal for nodes that handle transactions the node
operator can afford. Nobody is going to run a node for a network they do
not use for their own transactions. If transactions have fees that
prohibit use for most economic activity, that means node count will drop
until nodes are generally run by those who settle large amounts. That is
very centralizing.
Raystonn
On 29 Mar 2017 12:14 p.m., Jared Lee Richardson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
In order for any blocksize increase to be agreed upon, more consensus is
needed. The proportion of users believing no blocksize increases are
needed is larger than the hardfork target core wants(95% consensus). The
proportion of users believing in microtransactions for all is also larger
than 5%, and both of those groups may be larger than 10% respectively. I
don't think either the Big-blocks faction nor the low-node-costs faction
have even a simple majority of support. Getting consensus is going to be a
big mess, but it is critical that it is done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/2efe6ad0/attachment.html>

2023-06-07 17:57:51

- reply

📅 Original date posted:2017-03-26
📝 Original message:On 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> With a tightening of the rule set, a hash power minority that has
> not upgraded will not produce a minority branch; instead they will
> simply have any invalid blocks they produce orphaned, serving as a
> wake-up call to upgrade.
>
>
> False. With bip9-based soft-fork-based activation of segwit, miner
> blocks will not be orphaned unless they are intentionally
> segwit-invalid (which they currently are not). If you have told miners
> otherwise, let me know.
>
A reasonable miner automatically checks every transaction seen, to see
if it might be valid with his own outputs substituted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/b69b2b03/attachment-0001.html>

2023-06-07 17:57:19

- reply

📅 Original date posted:2017-03-16
📝 Original message:On 3/15/2017 5:25 PM, bfd at cock.lu wrote:
> compact fraud proofs in Bitcoin aren't possible
> In the white paper SPV clients have the same security as fully
> validating nodes
In addition to not existing, if compact fraud proofs did exist, trying
to ensure they are seen by SPV clients has the same problems as BIP37.
> in the implementation of BIP37 they have absolutely no security except
> the vague hope that they are not being lied to, and that the chain
> with the most work they are seeing is actually valid, both are very
> weak assumptions.
Since real money is involved, the near total absence of documented fraud
along these lines belies the strong language.
> During the validationless mining failure around the BIP66 activation
> miners produced 6 invalid blocks in a chain, and many more invalid
> blocks in isolated bursts for a period lasting several months. Due to
> the instability of the network you are completely unreasonable to
> accept anything except multiple confirmations
This affected all users, not just SPV.

2023-06-07 17:57:18

- reply

📅 Original date posted:2017-03-15
📝 Original message:Agreed.
In contrast, BIP37 as used today is totally decentralized, and can me
made much more secure, private, and scalable -- without giving up the
utility of unconfirmed transactions.
Please don't read into this statement a belief that all the coffees
should go on the chain, or that the security or privacy of BIP37 compare
favorably to any other particular thing.
https://docs.google.com/presentation/d/13MzUo2iIH9JBW29TgtPMoaMXxeEdanWDfi6SlfO-LlA
On 1/5/2017 6:04 PM, bfd--- via bitcoin-dev wrote:
> You might as well replace Bitcoin with a system where these parties
> sign transactions and skip mining altogether, it would have the same
> properties and be significantly more effient.
>
>
> On 2017-01-04 23:06, Chris Priest wrote:
>> On 1/3/17, Jonas Schnelli via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> There are plenty, more sane options. If you can't run your own
>>> full-node
>>> as a merchant (trivial), maybe co-use a wallet-service with centralized
>>> verification (maybe use two of them), I guess Copay would be one of
>>> those wallets (as an example). Use them in watch-only mode.
>>
>> The best way is to connect to the mempool of each miner and check to
>> see if they have your txid in their mempool.
>>
>> https://www.antpool.com/api/is_in_mempool?txid=334847bb...
>> https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
>> https://bw.com/api/is_in_mempool?txid=334847bb...
>> https://bitfury.com/api/is_in_mempool?txid=334847bb...
>> https://btcc.com/api/is_in_mempool?txid=334847bb...
>>
>> If each of these services return "True", and you know those services
>> so not engage in RBF, then you can assume with great confidence that
>> your transaction will be in the next block, or in a block very soon.
>> If any one of those services return "False", then you must assume that
>> it is possible that there is a double spend floating around, and that
>> you should wait to see if that tx gets confirmed. The problem is that
>> not every pool runs such a service to check the contents of their
>> mempool...
>>
>> This is an example of mining centralization increasing the security of
>> zero confirm. If more people mined, this method will not work as well
>> because it would require you to call the API of hundreds of different
>> potential block creators.
>

2023-06-07 17:55:51

- reply

📅 Original date posted:2017-01-29
📝 Original message:On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote:
> a world of nodes in large datacenters is a world where it's very easy
> to force the few Bitcoin nodes remaining to follow AML/KYC rules
If that's true, why haven't we already seen AML/KYC required of mining
pools? That would be comparatively trivial.

2023-06-07 17:55:44

- reply

📅 Original date posted:2017-01-26
📝 Original message:Even more to the point, new post- fork coins are fork-specific. The
longer both forks persist, the more transactions become unavoidably
fork-specific through the mixing in of these coins. Any attempt to
maximize replay will become less effective with time.
The rationality of actors in this situation essentially defines the
limited solution that is possible. Upgraded software can create
transactions guaranteed not to execute to one fork or the other, or that
is not prevented from execution on either fork. I see no downside to
this, and the advantage is that markets can be much less chaotic. In
fact exchanges will be much better off if they require that post-fork
trading, deposits and withdrawals are exclusively chain-specific, which
will also result in well determined prices for the two currencies.
None of this precludes the possibility of further forks on either side,
and the difficulty consideration alone suggests a likely counter-fork by
(part of) the existing network.
On 1/26/2017 1:20 AM, Johnson Lau via bitcoin-dev wrote:
> Not to mention that mining is a random process, and the hashing power is going up and down.

2023-06-07 17:55:38

- reply

📅 Original date posted:2017-01-27
📝 Original message:Johnson,
It's actually clear from your original post - you treat "all zeros" in a
special way - as the equivalent of all ones. The semantics match the
impression I got originally. Sorry we got sidetracked.

2023-06-07 17:55:37

- reply

📅 Original date posted:2017-01-25
📝 Original message:On 1/24/2017 8:03 PM, Johnson Lau wrote:
> it seems they are not the same: yours is opt-out, while mine is opt-in.
I missed this. So in fact you propose a self-defeating requirement on
the new network, which would force unmodified yet otherwise compatible
systems to change to support the new network at all. This is unlikely to
be included in new network designs.
I suggest that the opt-out bits proposal comes from a more realistic
position that would actually make sense for everyone.

2023-06-07 17:55:37

- reply

📅 Original date posted:2017-01-24
📝 Original message:On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote:
> 9. If the network characteristic byte is non-zero, and the existing
> network characteristic bit is set, the masked version is used to
> determine whether a transaction should be mined or relayed (policy change)
Johnson,
Your proposal supports 8 opt-out bits compatible with may earlier
description:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html.
If the existing network really wants to play along, it should execute a
soft fork as soon as possible to support its own hard-fork opt-out bit
("network characteristic bit"). It is totally inadequate for a new
network to rely on non-standardness in the existing network to prevent
replay there. Instead, in the absence of a supported opt-out bit in the
existing network, a responsible new network would allow something that
is invalid in the existing network, for transactions where replay to the
existing network is undesirable.
It is an overreach for your BIP to suggest specific changes to be
included in the new network, such as the specific O(n^2) fix you
suggest. This is a matter for the new network itself.

2023-06-07 17:54:52

- reply

📅 Original date posted:2016-12-18
📝 Original message:James,
I share your conviction that miners are the natural gatekeepers of the
maximum block size.
The trouble I see with Block75 is that linear growth won't work forever.
Also, by reading actual and not miners' preferred max blocksize, this
proposal is sensitive to randomness in block timing and tx rate, and so
incentivizes miners to manipulate their block content unnaturally in
either the up or down direction to influence the calculation.
The EB/AD scheme of Bitcoin Unlimited recognizes implementation of the
max blocksize by miners, who publish their preferred max blocksize. But
it expects forks of unpredictable (probably short) length as network
behavior evolves.
BIP100, which also recognizes miner implementation of the max blocksize,
but has a change support threshold, and like Block75 defines the timing
of max blocksize increases, looks superior to me.
On 12/18/2016 1:53 PM, James MacWhyte via bitcoin-dev wrote:
> Hi All,
>
> I'm coming late to the party. I like the Block75 proposal.
>
> Multiple people have said miners would/could stuff blocks with
> insincere transactions to increase the block size, but it was never
> adequately explained what they would gain from this. If there aren't
> enough legitimate transactions to fill up the block, where do you plan
> to earn extra income once the block is bigger?
>
> Miners would be incentivized to include as many legitimate
> transactions as possible, but if propagation time is as big an issue
> as some of you have said it is, miners would also be incentivized to
> keep their blocks small enough to propagate. So why not give them the
> choice? Once the block size gets too big to propagate effectively,
> miners would be naturally incentivized to limit how much data they put
> in each block, finding the perfect balance.
>
> In my opinion, none of the downsides presented so far have been a good
> argument. Risk of a 51% attack is not unique to this proposal, saying
> "we could also do that with hardcoded limits" doesn't actually point
> out any problem with this proposal, and miners already have the
> ability to add or withhold transactions from their blocks.
>
> We trust our miners to serve us by acting in their own best interests,
> and this proposal simply gives them more options for doing that. If
> anyone can make a strong argument against that would earn top marks in
> a high school debate class, I'd love to hear it!
>
> James
>

2023-06-07 17:53:23

- reply

📅 Original date posted:2016-09-19
📝 Original message:On 9/19/2016 10:56 AM, Peter Todd wrote:
> I should state that assumption more clearly.
Glad to get you thinking, and I need to change my suggestion. The
catch-up formula is not applicable because it doesn't limit how long the
dishonest miners have to catch up.
Instead you want the probability that the honest miners can build a
chain N blocks long before the dishonest miners do the same, which is
CDF[Erlang(N, q) - Erlang(N, 1 - q), 0]
I have some apparatus for doing this numerically without simulation if
you're interested.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160919/8277554b/attachment.sig>

2023-06-07 17:53:22

- reply

📅 Original date posted:2016-09-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/17/2016 9:20 PM, Peter Todd via bitcoin-dev wrote:
> The probability that all N blocks are found by dishonest miners is q^N,
That's the probability that dishonest miners find N blocks in a row
immediately. What you want is the probability that they can build a
chain N blocks long, taking the random-walk into account.
So use Satoshi's formula from bitcoin.pdf, section 11. The results are
remarkably different. In particular, q=.5 is totally insecure, since
for any N, both factions are guaranteed to eventually possess a chain of
length N anchored at x at some point during the wild reorg melee.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJX4A60AAoJEG/AI00/Ca/qLmEP/0fg+XJQNexTTrS/aPqcIY00
KStPNIruJD4QA9zgyx4K3fCst85/L9rsmv/9Xo6tyn8oneAMjjVY57mTG3smhiXA
Qfu9/tG0AHneRxEpRNDA/x4IwCrr1xACOaO26gEqs9zVIszIVQq4z3Vc54gj39VD
9Jpc0653RVqHhJFT4ozZkAzg2CcPMHOxi45ufBtScaJO2AwtcLvtVYaC1BE9itDM
wDdAS175jq+LlV20Igaf/s4Cc9G3LWnrNqzVCPBr/ua4U60ZO+r3nLr9gYtYNR0H
37xgktNZA8D/YI8gjYZ5p11bIqCs4lRyI5LP3Rvh/+5zQu4hdi25HMoUMys/lw4c
ABuUVLaCa2r7pH7QczUx4jWJslaHlZ4M6tMUJ7bGZpVcPmA8FOk0j+DLTfUmYVYi
Eqc5cf2Z+PEc9kBmvsxQ351WjT7fq3OtZCcMH5dhpGv4NMuVBwQ38Dh3Pz8rhBPe
pIXMUPkmdWdczjoACpjOHbhYffCI7zCvsypydnImF7FReohWPFSKdaeoSHxotHzb
cy2EWZS2IM009qY3+jF1j3uj4bJfPSlgLgfUE23Bmvsp9PJi9W+FARbKJKxr6HaB
vvMg6rMfU8uWElQqz19ixI55PUDmtugwXccyWvhcr0ueN1P6fpNxF36Q9zwS6/+D
4orUC+rp1yNTeddvaYDv
=HS6r
-----END PGP SIGNATURE-----

2023-06-07 17:53:15

- reply

📅 Original date posted:2016-09-02
📝 Original message:On 9/1/2016 9:40 PM, Johnson Lau via bitcoin-dev wrote:
> This BIP will be deployed by "version bits" BIP9 using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1.
>
This fix has value outside of segwit. Why bundle the two together?
Shouldn't miners have to opportunity to vote on them independently?

2023-06-07 17:52:06

- reply

📅 Original date posted:2016-07-31
📝 Original message:Your thoughts are sought on this simple proposal to allow transaction
authors to restrict execution to fewer than all blockchain forks where
the transaction would otherwise be valid.
Proposal
Node implementations select a bit from among the upper 8 bits of the
transaction version space to enforce as a hard fork opt-out bit.
To specify that a transaction NOT be mined by nodes that enforce a
particular bit, authors set that bit in the transaction version.
Opt-out is enforced by consensus among nodes enforcing each bit.
An implementation will relay, process and mine transactions that opt out
of other blockchain forks; just not those that opt out of its own fork.
Notes
Example: Via soft fork, all implementations may begin enforcing hard
fork opt-out bit 30. Post soft fork, setting this bit would make a
transaction invalid, unless a fork emerges that has stopped enforcing
bit 30.
Example: BIP109 implementations may stop enforcing bit 30 and begin
enforcing bit 28 when the BIP109 hard fork is activated for a chain they
are tracking.
Enforcing more than one hard fork opt-out bit would imply that an
implementation is actively participating in building more than one
blockchain fork, and therefore providing a way to opt out of each.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160731/7b1a2154/attachment.sig>

2023-06-07 17:50:33

- reply

📅 Original date posted:2016-05-12
📝 Original message:On May 11, 2016 7:33 PM, "Peter Todd" <pete at petertodd.org> wrote:
> The optimisation has been independently discovered two or three times
(Spondoolies and maybe Bitmain).
The idea that a precedent can be set, whereby those who seek or are awarded
mining optimization patents risk retaliatory consensus changes, is very
unrealistic, and such a precedent would actually encode a dependency on the
insane patent systems of the world into the protocol development process.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/3698300a/attachment-0001.html>

2023-06-07 17:50:32

- reply

📅 Original date posted:2016-05-11
📝 Original message:On 5/10/2016 2:43 PM, Sergio Demian Lerner via bitcoin-dev wrote:
>
> If we change the protocol then the message to the ecosystem is that
> ASIC optimizations should be kept secret.
Further to that point, if THIS optimization had been kept secret, nobody
would be talking about doing anything, as with countless other
optimizations.

2023-06-07 17:46:17

- reply

📅 Original date posted:2015-12-21
📝 Original message:On 12/20/2015 3:34 AM, Jeff Garzik via bitcoin-dev wrote:
> Ideally we should start having wallets generate those proofs now, and
> then introduce the max-age as a second step as a planned hard fork a
> couple years down the line.
>
> However,
> 1) There is also the open question of "grandfathered" UTXOs - for
> those wallets generated in 2009, buried in a landfill and then dug out
> 10 years ago
>
> 2) This reverses the useful minimization attribute of HD wallets -
> "just backup the seed"
Also, a change (#6550) has been merged to bitcoin core that removes
merkle branches from the wallet, and if pruning gets turned on (possible
in 0.12 with #6057), it would become quite a bit more difficult to spend
older coins under a change like this.
As a solution I would favor not removing wallet merkle branches.

2023-06-07 17:44:55

- reply

📅 Original date posted:2015-11-17
📝 Original message:On Nov 17, 2015 5:54 AM, "Tamas Blummer via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Isolating storage from the rest of consensus code is technically
desirable, but implementations using different storage will be unlikely
bug-for-bug compatible,
> hence able to split the network.
The problem with unknown bugs is you don't know how serious they are. A
serious bug could itself be devastating.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151117/39c94d1d/attachment.html>

2023-06-07 17:42:50

- reply

📅 Original date posted:2015-10-05
📝 Original message:On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
> In this case, I don't even believe we have any regulator contributors
> that disagree.
Since Gavin Andresen chose you to be one of 4 people who decides whose
contributions are accepted to the Core project, shouldn't you recuse
yourself from referencing "regular contributor" as some kind of bar to
an opinion being worthy?
You don't want to be accused of squelching a person's opinions by
nacking or sitting on commits, then turning around and branding those
opinions as worthless because they are not from a "regular contributor."
Do you?

2023-06-07 17:41:57

- reply

📅 Original date posted:2015-10-01
📝 Original message:On 9/30/2015 10:58 AM, Jorge Timón via bitcoin-dev wrote:
> I don't think we need to wait for you to understand the advantages of
> softforks to move forward with BIP65, just like we didn't need to wait
> for every developer and user to understand BIP66 to deploy it.
What a bad example. BIP66 deployment failed, and was rescued by
centralized intervention.

2023-06-07 17:40:46

- reply

📅 Original date posted:2015-09-19
📝 Original message:On 9/17/2015 8:27 PM, jl2012 via bitcoin-dev wrote:
> However, requiring 100 block maturity will unfortunately make the
> system much less appealing since the recipient may not like it.
The maturity requirement can be dropped if the expiration height is more
that 100 blocks after inclusion height.

2023-06-07 17:40:11

- reply

📅 Original date posted:2015-09-30
📝 Original message:On 9/29/2015 7:05 PM, Rusty Russell wrote:
> Tom Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> writes:
>> With a simple delay, you can have the embarrassing situation where
>> support falls off during the delay period and there is far below
>> threshold support just moments prior to enforcement, but enforcement
>> happens anyway.
> Yeah, but Gavin's right. If you can't account for all the corner cases,
> all you can do is keep it simple and well defined.
>
At least you changed the BIP to make it possible to see a fall off in
support, even though nothing is done about it.

2023-06-07 17:40:10

- reply

📅 Original date posted:2015-09-23
📝 Original message:On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:
> '''Success: Activation Delay'''
> The consensus rules related to ''locked-in'' soft fork will be enforced in
> the second retarget period; ie. there is a one retarget period in
> which the remaining 5% can upgrade. At the that activation block and
> after, the bit B may be reused for a different soft fork.
>
Rather than a simple one-period delay, should there be a one-period
"burn-in" to show sustained support of the threshold? During this
period, support must continuously remain above the threshold. Any lapse
resets to inactivated state.
With a simple delay, you can have the embarrassing situation where
support falls off during the delay period and there is far below
threshold support just moments prior to enforcement, but enforcement
happens anyway.
BIP 101 has this problem too.

2023-06-07 17:39:53

- reply

📅 Original date posted:2015-09-09
📝 Original message:Well let's see. All else being equal, if everybody uses difficulty to
buy big blocks during retarget interval 0, blocks and therefore money
issuance is slower during that interval. Then, the retargeting causes
it to be faster during interval 1. Subsidy got shifted from the
calendar period corresponding to interval 0, to interval 1.
If you change the reward, you can lower the time-frame of the effect to
the order of a single block interval, but there is still an effect.
These schemes do not avoid the need for a hard cap, and there are new
rules for the size of the allowed adjustment, in addition to the main
rule relating difficulty to block size. So it seems they generally have
more complexity than the other blocksize schemes being considered.
On 9/9/2015 11:59 AM, Warren Togami Jr. via bitcoin-dev wrote:
> Does it really change the schedule when the next difficulty retarget
> readjusts to an average of 10 minutes again?
>
> On Tue, Sep 8, 2015 at 8:27 PM, Tom Harding via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
> There is another concern regarding "flexcap" that was not discussed.
>
> A change to difficulty in response to anything BUT observed block
> production rate unavoidably changes the money supply schedule, unless
> you also change the reward, and in that case you've still changed the
> timing even if not the average rate.
>
>
>
> _______________________________________________
> 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/20150909/6df72c5a/attachment.html>

2023-06-07 17:39:52

- reply

📅 Original date posted:2015-09-09
📝 Original message:There is another concern regarding "flexcap" that was not discussed.
A change to difficulty in response to anything BUT observed block
production rate unavoidably changes the money supply schedule, unless
you also change the reward, and in that case you've still changed the
timing even if not the average rate.
On 8/14/2015 8:14 AM, Jakob Rönnbäck via bitcoin-dev wrote:
> Ah, there we go. I should have dug deeper into the mailing list
>
> Thanks
>
> /jakob
>
>> 14 aug 2015 kl. 17:03 skrev Adam Back <adam at cypherspace.org>:
>>
>> There is a proposal that relates to this, see the flexcap proposal by
>> Greg Maxwell & Mark Friedenbach, it was discussed on the list back in
>> May:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html
>>
>> and http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.html
>>
>> Adam
>

2023-06-07 17:39:28

- reply

📅 Original date posted:2015-09-03
📝 Original message:On 9/2/2015 9:05 PM, Jeff Garzik via bitcoin-dev wrote:
> Schemes proposing to pay with difficulty / hashpower to change block
> size should be avoided. The miners incentive has always been fairly
> straightforward - it is rational to deploy new hashpower as soon as
> you can get it online. Introducing the concepts of (a) requiring
> out-of-band collusion to change block size and/or (b) requiring miners
> to have idle hashpower on hand to change block size are both
> unrealistic and potentially corrosive. That potentially makes the
> block size - and therefore fee market - too close, too sensitive to
> the wild vagaries of the mining chip market.
>
> Pay-to-future-miner has neutral, forward looking incentives worth
> researching.
>
Another market dependency is even more direct.
Blocksize that can be bought with either difficulty or bitcoin has
incentives whose strength (though not direction) is subject to the
exchange rate. Hence those incentives are subject to the whims of fiat
holders, who can push the exchange rate around.

2023-06-07 17:38:14

- reply

📅 Original date posted:2015-08-30
📝 Original message:On 8/30/2015 9:54 AM, Peter R wrote:
> Like Daniele pointed out, the greedy algorithm assumed in the paper is
> asymptotically optimal in such a case.
I'm convinced.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150830/3336d174/attachment.html>

2023-06-07 17:37:38

- reply

📅 Original date posted:2015-08-21
📝 Original message:On 8/20/2015 11:07 PM, Peter Todd via bitcoin-dev wrote:
> I run a number of high speed nodes and while I don't have historical
> logs handy over time, I've noticed a drop from about %5-%10 SPV
> clients at any one time tocloser to %1
Just checked mine and found 20.4% bitcoinj connections.

2023-06-07 17:37:35

- reply

📅 Original date posted:2015-08-24
📝 Original message:On 8/21/2015 3:06 PM, Peter Todd via bitcoin-dev wrote:
> On Fri, Aug 21, 2015 at 05:55:58PM +0000, Matt Corallo wrote:
>> Anyone have the best reference for the DoS issues?
> Well actually, we can reference the DoS attacks that Bitcoin XT nodes
> are undergoing right now - part of the attack is repeated Bloom filter
> requests to soak up disk IO bandwidth.
So, to summarize, someone is attacking Mike Hearn's bitcoin fork.
Therefore, now is the perfect time to write a BIP and author changes
that begin the process of dropping support for the most broadly
successful class of wallets, which Mike Hearn's SPV client library enables.

2023-06-07 17:36:24

- reply

📅 Original date posted:2015-08-23
📝 Original message:On 8/21/2015 5:01 PM, Peter Todd wrote:
>
>> I checked the scenario where only the radio is on, and found the car
>> does not crash.
> Incidentally, what's your acceptable revenue difference between a small
> (1% hashing power) and large (%30 hashing power) miner, all else being
> equal? (remember that we shouldn't preclude variance reduction
> techniques such as p2pool and pooled-solo mode)
>
> Equally, what kind of attacks on miners do you think we need to be able to
> resist? E.g. DoS attacks, hacking, etc.
>
None of this is in the scope of Pieter's simulation.
If you think that casts doubt on my conclusions, then it casts doubt on
his original conclusions as well.

2023-06-07 17:36:22

- reply

📅 Original date posted:2015-08-21
📝 Original message:On 8/20/2015 5:37 PM, Peter Todd wrote:
> On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote: >> I found that small miners were not at all disadvantaged by large
blocks. >> > > You used 20% as the size of the large miner, with all the
small miners > having good connectivity with each other. > > That is
*not* the scenario we're worried about. The math behind the > issue is
that the a miner needs to get their blocks to at least 33% of > hashing
power, but more than that is unnecessary and only helps their >
competition; you simulated 20%, which is under that threshold. Equally,
> why are you assuming the small miner group is well connected to each >
other? > > You probably didn't get any replies because your experiment
is obviously > wrong and misguided, and we're all busy. >
I gave the small miners collectively the same hashrate as the large
miners in the original test. I made them well-connected because
everyone was well-connected intra-partition in the original test.
I just varied one thing: the size of the miners. This is a principle of
experiment design, in science.
Next you'll probably claim that second-order and cross-term effects
dominate. Maybe you can find the time to prove it.

2023-06-07 17:36:22

- reply

📅 Original date posted:2015-08-21
📝 Original message:On 8/21/2015 3:21 PM, Peter Todd wrote:
> To use a car analogy, Pieter Wuille has shown that the brake cylinders
> have a fatigue problem, and if used in stop-and-go traffic regularly
> they'll fail during heavy braking, potentially killing someone. You've
> countered with a study of highway driving, showing that if the car is
> only used on the highway the brakes have no issues, claiming that the
> car design is perfectly safe.
No. If we must play the analogy game, it was found that the car crashes
when the brakes are bad (minority hash power partitioned) the radio is
on (partitioned miners had small individual hashrate).
I checked the scenario where only the radio is on, and found the car
does not crash.

2023-06-07 17:36:21

- reply

📅 Original date posted:2015-08-20
📝 Original message:On 8/20/2015 3:23 AM, Milly Bitcoin via bitcoin-dev wrote:
>> For the 73th time or so this month on this list:
>>
>> The maximum block size consensus rule limits mining centralization
>> (which is currently pretty bad).
>
> Instead of posting all these messages with bald claims why don't you
> work on a decentralization metric which you can point to? (instead of
> trying to claim people don't understand things which is clearly not
> the case, You are just attacking people you don't agree with).
Pieter built a nice simulation tool and posted some results.
I tweaked the parameters and ran the tool in a way that tested ONLY for
hashrate centralization effects, and did not conflate these with network
partitioning effects.
I found that small miners were not at all disadvantaged by large blocks.
The only person who commented on this result agreed with me. He also
complimented Pieter's insight (which is entirely appropriate since
Pieter did the hard work of creating the tool).
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html

2023-06-07 17:35:06

- reply

📅 Original date posted:2015-08-14
📝 Original message:Nobody mentioned exchange rates. Those matter to miners too.
Does it make sense for George Soros and every other rich person /
institution to have the power to move difficulty, even pin it to min or
max, just by buying or selling piles of BTC to swing the exchange rate?
On 8/14/2015 8:03 AM, Adam Back via bitcoin-dev wrote:
> There is a proposal that relates to this, see the flexcap proposal by
> Greg Maxwell & Mark Friedenbach, it was discussed on the list back in
> May:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html
>
> and http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.html
>
> Adam
>
> On 14 August 2015 at 15:48, Jakob Rönnbäck
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> 14 aug 2015 kl. 16:20 skrev Anthony Towns <aj at erisian.com.au>:
>>
>> On 14 August 2015 at 11:59, Jakob Rönnbäck
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> What if one were to adjust the difficulty (for individual blocks)
>>> depending on the relative size to the average block size of the previous
>>> difficulty period? (I apologize if i’m not using the correct terms, I’m not
>>> a real programmer, and I’ve only recently started to subscribe to the
>>> mailing list)
>>
>> That would mean that as usage grew, blocksize could increase, but
>> confirmation times would also increase (though presumably less than
>> linearly). That seems like a loss?
>>
>>
>> Would that really be the case though? If it takes 5% to find a block, but it
>> contains 5% more transactions would that not mean it’s the same? That would
>> argue against the change if not for the fact that the blocks will be bigger
>> for the next difficulty period.
>>
>> If you also let the increase in confirmation time (due to miners finding
>> harder blocks rather than a reduction in hashpower) then get reflected back
>> as decreased difficulty, it'd probably be simpler to just dynamically adjust
>> the max blocksize wouldn't it?
>>
>>
>> I guess that could make the difficulty fluctuate a bit depending on the
>> amount of transactions and the fees being paid. Would it really matter in
>> the long run though? Since it’s the same amount of miners, doesn’t that just
>> mean it’s just the number that is lower, not the actual investment needed to
>> mine the blocks? Not sure if this would open up some forms of attacks on the
>> system for someone willing to lose money though…
>>
>>
>> Very good feedback though, thanks a lot :)
>>
>> /jakob
>>
>> _______________________________________________
>> 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

2023-06-07 17:34:58

- reply

📅 Original date posted:2015-08-23
📝 Original message:ack no inversion. This can actually allow more direct preservation of
existing semantics.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html
On 8/19/2015 9:21 AM, Mark Friedenbach via bitcoin-dev wrote:
> I am indifferent on this issue (the bit inversion), but so far only
> Jorge has spoken up. I opted for this detail during implementation in
> order to preserve existing semantics, even if those semantics are not
> commonly used. This was the conservative choice, driven in part
> because I didn't want the proposal to be held up by the other side
> saying "this is confusing because it changes how sequence numbers
> work! it used to count up but now it counts down!"
>
> I can see both sides and as I said I'm indifferent, so I went with the
> conservative choice of not messing with existing semantics. However if
> there is strong preferences from _multiple_ people on this matter it
> is not too late to change. If anyone feels strongly about this, please
> speak up.
>
> On Wed, Aug 19, 2015 at 3:37 AM, Jorge Timón
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I repeated my nit on https://github.com/bitcoin/bips/pull/179
>
>
> On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> > Please note there is now a PR for this BIP[1] and also a pull
> request for
> > the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
> >
> > [1] https://github.com/bitcoin/bips/pull/179
> > [2] https://github.com/bitcoin/bitcoin/pull/6564
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150823/2d124f71/attachment.html>

2023-06-07 17:33:53

- reply

📅 Original date posted:2015-08-11
📝 Original message:On 8/11/2015 2:23 PM, Adam Back via bitcoin-dev wrote:
> I dont think Bitcoin being cheaper is the main characteristic of
> Bitcoin. I think the interesting thing is trustlessness - being able
> to transact without relying on third parties.
>
That rules out Lightning Network.
Lightning relies on third parties all over the place. Many things must
be done right, and on-time by N intermediate third parties (subject to
business pressures and regulation) or your payment will not work.
Lightning hubs can't steal your money. Yay! But banks stealing your
payment money is not a problem with today's payment systems. Some real
problems with those systems are:
- Limited ACCESS to payment systems
- High FEES
- Transaction AMOUNT restrictions
- FRAUD due to weak technology
- CURRENCY conversions
Plain old bitcoin solves all of these problems.
Bitcoin does have challenges. THROUGHPUT and TIME-TO-RELIABILITY are
critical ones. DECENTRALIZATION and PRIVACY must not be degraded.
These challenges can be met and exceeded.

2023-06-07 17:33:22

- reply

📅 Original date posted:2015-08-06
📝 Original message:On 8/5/2015 4:24 PM, Jorge Timón via bitcoin-dev wrote:
> Miner A is able to process 100 M tx/block while miner B is only able
> to process 10 M tx/block.
>
B needs to sell ASICs and buy 90 M tx worth of CPU.
Or, if you cap blocksize at 10 M tx, than A needs to sell the exact same
amount of CPU and buy the exact same amount of ASICs.
Either way, Miner A ends up with the ASIC cost equivalent of 90 M tx
worth of CPU in additional hashing advantage over B. The centralization
has nothing to do with block size. It has to do with Miner A having
more money than Miner B.
Alternatively, you might need to add a few more crazy assumptions.

2023-06-07 17:33:19

- reply

📅 Original date posted:2015-08-06
📝 Original message:On 8/6/2015 10:16 AM, Sergio Demian Lerner via bitcoin-dev wrote:
> Is there any up to date documentation about TheBlueMatt relay network
> including what kind of block compression it is currently doing? (apart
> from the source code)
>
Another question.
Did the "relay network" relay
0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99, the
BTC Nuggets block that was invalid post-softfork? If so,
- Is there reason to believe that by so doing, it contributed to the
growth of the 2015-07-04 fork?
- Will the relay network at least validate block version numbers in the
future?

2023-06-07 17:33:07

- reply

📅 Original date posted:2015-08-09
📝 Original message:On 8/9/2015 2:45 PM, Hector Chu wrote:
> Tom, my understanding is that the money that is debited from a payment
> hub is simultaneously credited from either another payment hub or the
> person making the payment, so that the net funds flow at a payment hub
> always sums to zero.
That describes the steady-state dynamics. I refer to the hub funding
required to initiate and maintain the ability to receive payments.
If Bob opens a channel at his hub, doesn't use it for spending, and
Alice sends 1 BTC to the channel, her payment can only be applied if the
hub has funded the channel with at least 1 BTC.
Yes, the hub receives an offsetting payment (from Alice, ultimately) in
another channel. But to make this work, it must subject 1 BTC to shared
control with Bob and forfeit the use of that money for other purposes
(opportunity cost) while the channel is open. The opportunity cost is
likened to gold lease rates in the LN paper. I would be surprised if
the rates charged to consumers for BTC credit aren't much closer to
today's BTC borrowing rates. We'll see.
Burying this cost in general fees might not work very well, because
different Bobs may want different maximum payment amounts, and channels
open for different lengths of time.

2023-06-07 17:33:05

- reply

📅 Original date posted:2015-08-09
📝 Original message:On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
> On the contrary the funds were advanced by the hub on the creation of the
channel. There is no credit involved.
That's a chuckle.
As I said, nothing requires the hub to advance anything, and if it does,
Bob can expect to pay for it.
We'll see whether hubs assess a fee for depositing funds, whether the fee
depends on the amount deposited, and whether it depends on the amount of
time it stays there.
I predict "all of the above." There is a name for these kinds of fees. Can
you guess it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/51dc9af8/attachment.html>

2023-06-07 17:33:01

- reply

📅 Original date posted:2015-08-09
📝 Original message:On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
> Don't turn Bitcoin into something uninteresting, please.
Consider how Bob will receive money using the Lightning Network.
Bob receives a payment by applying a contract to his local payment
channel, increasing the amount payable to him when the channel is closed.
There are two possible sources of funding for Bob's increased claim.
They can appear alone, or in combination:
Funding Source (1)
A deposit from Bob's payment hub
Bob can receive funds, if his payment hub has made a deposit to the
channel. Another name for this is "credit".
This credit has no default risk: Bob cannot just take payment hub's
deposit. But neither can Bob receive money, unless payment hub has
advanced it to the channel (or (2) below applies). Nothing requires the
payment hub to do this.
This is a 3rd-party dependency totally absent with plain old bitcoin.
It will come with a fee and, in an important way, it is worse than the
current banking system. If a bank will not even open an account for Bob
today, why would a payment hub lock up hard bitcoin to allow Bob to be
paid through a Poon-Dryja channel?
Funding Source (2)
Bob's previous spends
If Bob has previously spent from the channel, decreasing his claim on
its funds (which he could have deposited himself), that claim can be
re-increased.
To avoid needing credit (1), Bob has an incentive to consolidate
spending and income in the same payment channel, just as with today's
banks. This is at odds with the idea that Bob will have accounts with
many payment hubs. It is an incentive for centralization.
With Lightning Network, Bob will need a powerful middleman to send and
receive money effectively. *That* is uninteresting to me.

2023-06-07 17:32:50

- reply

📅 Original date posted:2015-08-05
📝 Original message:On 8/5/2015 3:44 PM, Dave Hudson via bitcoin-dev wrote:
> I do suspect that if we were to model this more accurately we might be
> able to infer the "typical" propagation characteristics by measuring
> the deviation from the expected distribution.
The paper models propagation using a single time value that is a
function of block size. Modeling the propagation distribution (which is
totally separate from the poisson model of block production) would add a
lot of complexity and my guess is the outcome would be little changed.
>> On 5 Aug 2015, at 15:15, Peter R <peter_r at gmx.com> wrote:
>> Although a miner may not orphan his own block, by building on his own block he may now orphan two blocks in a row. At some point, his solution or solutions must be communicated to his peers.
Why complicate the analysis by assuming that a miner who finds two
blocks sequentially does not publish the first, or that other miners
would orphan miner's first block unless both were very quick? In
general you don't consider anything beyond 1 block in the future, which
seems fine.
>>> I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts.
>> It will be interesting to see. I suspect that the main result that "a healthy fee market exists" will still hold (assuming of course that a single miner with >50% of the hash power isn't acting maliciously). Whether miners with larger value of h/H have a profit advantage, I'm not sure (but that was outside the scope of the paper anyways).
Correcting for non-orphaning of one's own blocks could be as simple as
adding a factor (1 - h/H) to equation 4, which it appears would leave
hashpower as an independent variable in the results. But at worst, the
discussion can be considered to apply directly only to low-hashpower
miners right now.
Overall, the paper does not predict big changes to per/kb fees or spam
costs for the kinds of block sizes being discussed for the immediate
future (8MB). But it does conclude that these fees will rise, not fall,
with bigger blocks.
Also it is welcome that this paper actually mentions the bitcoin
exchange rate as a factor in relation to block size (it points out that
a spam attack is much more expensive in fiat terms today than it was
years ago).

2023-06-07 17:32:34

- reply

📅 Original date posted:2015-08-06
📝 Original message:On 8/6/2015 7:53 AM, Pieter Wuille via bitcoin-dev wrote:
>
> So if we would have 8 MB blocks, and there is a sudden influx of users
> (or settlement systems, who serve much more users) who want to pay
> high fees (let's say 20 transactions per second) making the block
> chain inaccessible for low fee transactions, and unreliable for medium
> fee transactions (for any value of low, medium, and high), would you
> be ok with that?
Gavin has answered this question in the clearest way possible -- in
tested C++ code, which increases capacity only on a precise schedule for
20 years, then stops increasing.

2023-06-07 17:32:09

- reply

📅 Original date posted:2015-08-01
📝 Original message:On 8/1/2015 1:45 PM, Pieter Wuille via bitcoin-dev wrote:
>
> Regarding "reasonable", I have a theory. What if we would have had 8
> MB blocks from the start? My guess is that some more people would have
> decided to run their high-transaction-rate use cases on chain, that
> we'd regularly see 4-6 MB blocks,
You've proposed scaling the cap based on technology growth. There's
still a cap to stop bad things from happening.
Once that is done, why worry so much about whether the uses are
efficient? Let people work in the space created. Let them figure out
how to make good things happen in the application space.

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-30
📝 Original message:On 7/30/2015 8:03 AM, Максим Божко via bitcoin-dev wrote:
> I propose to implement dynamic block size limit. Its short summary is
> here in doc:
>
> https://docs.google.com/document/d/1ixt0loN7LOF6M_2HXvV0D-3ZCayvcfj0rzVm-h-6ONg/edit
>
>
A dynamic limit based on recent block sizes has been discussed, but with
all the traffic on the list, finding the discussions is bound to be
difficult.
I think the main reason this kind of thing hasn't gotten traction is
that it would allow miners alone to chart the course of block sizes.
Miners are likely to have more powerful equipment than everybody else,
and with the current network design, that could reduce the population of
nodes able to keep up, with no limit in the loss of decentralization.

2023-06-07 15:44:09

- reply

📅 Original date posted:2015-07-30
📝 Original message:On 7/30/2015 11:14 AM, Jorge Timón wrote:
> The blocksize limit (your "production quota") is necessary for
> decentralization, not for having a functioning fee market.
> If we can agree that hitting the limit will JUST cause higher fees and
> not bitcoin to fail, puppies to die or the sky to turn purple I think
> that's a great step forward in this debate.
It's interesting how people see things differently. I think your first
statement above represents a great step forward in the debate. Unlike
Adam Back, you state that a block size limit is not necessary to create
a functioning fee market.
As to your second statement, unfortunately for immediate harmonious
relations, I was merely separating out the elevated fee market concern,
not at all saying it is the only or even the biggest concern with
limited capacity. Alan Reiner, Ryan X. Charles and others have
eloquently explained how restrictive a 1MB limit is, even with "layer 2".
What's missing from the decentralization dialog is a quantitative
measure of decentralization.
Why not slam users with higher fees now, if we accept that they may be
necessary someday? For the same reasons you don't ask a child, age 5, to
work in a factory.

2023-06-07 15:44:08

- reply

📅 Original date posted:2015-07-30
📝 Original message:Yes. So far, the transaction count factor has completely dominated the
per-tx fee factor. This fact should be of great interest to miners.
On 7/30/2015 7:25 AM, Dave Hudson wrote:
>
>> On 30 Jul 2015, at 06:14, Tom Harding via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Another empirical fact also needs explaining. Why have average fees *as
>> measured in BTC* risen during the times of highest public interest in
>> bitcoin? This happened without block size pressure, and it is not an
>> exchange rate effect -- these are raw BTC fees:
>>
>> https://blockchain.info/charts/transaction-fees?timespan=all&daysAverageString=7
>
> I've not published any new figures for about 8 months (will try to do
> that this weekend), but the thing that that chart doesn't show is
> what's actually happening to fees per transaction. Here's a chart that
> does: http://hashingit.com/analysis/35-the-future-of-bitcoin-transaction-fees
>
> The data is also taken from blockchain.info so it's apples-for-apples.
> It shows that far from a fees going up they spent 3 years dropping. I
> just ran a new chart and the decline in fees continued until about 8
> weeks when the "stress tests" first occurred. Even so, they're still
> below the level from the end of 2013. By comparison the total
> transaction volume is up about 2.4x to 2.5x (don't have the exact number).
>
>> ... more evidence that conclusively refutes the conjecture that a
>> production quota is necessary for a "functioning fee market." A
>> production quota merely pushes up fees. We have a functioning market,
>> and so far, it shows that wider bitcoin usage is even more effective
>> than a quota at pushing up fees.
>
> I think it's equally easy to argue (from the same data) that wider
> adoption has actually caused wallet users to become much more
> effective at fee selection. Miners (as expected, assuming that they
> hadn't formed a cartel) have continued to accept whatever fees are
> available, no matter how small. Only where there has been an element
> of scarcity have we actually seen miners do anything but take whatever
> is offered.
>
> Clearly history is not an accurate indicator of what might happen in
> the future, but it seems difficult to argue that there has been any
> sort of fee market emerge to date (other than as a result of scarcity
> during the stress tests).
>

2023-06-07 15:44:08

- reply

📅 Original date posted:2015-07-30
📝 Original message:On 7/29/2015 9:48 PM, Ryan Butler via bitcoin-dev wrote:
>
> I shouldn't have said unlimited, i should have said a greater
> blocksize limit such as 8mb.
>
> Anyways, why is that the assumption? If a miner can do so, and do so
> profitably, isn't that just competition? Isn't that what we want? If
> a miner can mine low transaction fees at a profit then don't they
> deserve to have their spot? Surely if they do so unprofitably they
> quickly find themselves out of business? Besides, if a miner mines
> low fee transactions by breaking rank, how does this affect another
> miner EXCEPT for the additional blocksize load. I would maintain this
> is just competition amongst miners gentlemen. And it's a good thing.
>
> Right now things are distorted because most income comes from the
> coinbase, but as transaction fees start to constitute the majority of
> income this idea seems to have more importance.
>
You're completely correct Ryan.
There has been a well functioning fee market since 2011. Average fees
have never been zero, despite low-fee transactions being mined, and
despite no block size pressure until September 2014.
Another empirical fact also needs explaining. Why have average fees *as
measured in BTC* risen during the times of highest public interest in
bitcoin? This happened without block size pressure, and it is not an
exchange rate effect -- these are raw BTC fees:
https://blockchain.info/charts/transaction-fees?timespan=all&daysAverageString=7
... more evidence that conclusively refutes the conjecture that a
production quota is necessary for a "functioning fee market." A
production quota merely pushes up fees. We have a functioning market,
and so far, it shows that wider bitcoin usage is even more effective
than a quota at pushing up fees.
> On Jul 29, 2015 11:00 PM, "Adam Back" <adam at cypherspace.org
> <mailto:adam at cypherspace.org>> wrote:
>
>
> The assumption is that wont work because any miner can break ranks and
> do so profitably, so to expect otherwise is to expect oligopoly
> behaviour which is the sort of antithesis of a decentralised mining
> system. It's in fact a similar argument as to why decentralisation of
> mining provides policy neutrality: some miner somewhere with some
> hashrate will process your transaction even if some other miners are
> by policy deciding not to mine it. It is also similar reason why free
> transactions are processed today - policies vary and this is good for
> ensuring many types of transaction get processed.
>

2023-06-07 15:43:05

- reply

📅 Original date posted:2015-07-22
📝 Original message:On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote:
> It would be irresponsible and dangerous to the network and thus the
> users of the software to risk forks, or to take a leading role in
> pushing dramatic changes.
Count me among those who see allowing bitcoin to become
space-constrained, without technical reason, as a dramatic change.
Especially when the reasons cited in support are
- Various species of vaporware
- Amateurish economic thinking surrounding fees
- "We don't support it because not everyone supports it because we
don't support it because ..." infinite descent

2023-06-07 15:43:03

- reply

📅 Original date posted:2015-07-28
📝 Original message:Jorge,
We obviously disagree fundamentally on the role of societal adoption, in
the system that Satoshi designed.
Adoption is well ahead of Satoshi's schedule, and the measure of this is
the exchange rate. It is at once an imperfect measure, and one of the
most perfect markets that has ever existed.
As long as hardware, electric power, and bandwidth are priced in fiat
currency, the exchange rate is a critical variable to security,
capacity, and other metrics of network health.
It's not inconsistent that you consider the exchange rate irrelevant.
In fact it explains why you believe that Satoshi's timetable for
transitioning to fee incentives can be summarily tossed aside and
replaced with something you think is better.
Here's an English saying I just invented. A bunch of geniuses can do a
lot more damage than one fool.

2023-06-07 15:43:02

- reply

📅 Original date posted:2015-07-24
📝 Original message:On 7/24/2015 2:24 AM, Jorge Timón wrote:
> Regarding "increasing the exchange rate" it would be really nice to
> just push a button and double bitcoin's price just before the next
> subsidy halving, but unfortunately that's something out of our control.
Jorge, right now, from the activity on github, you are working at least
as hard as anyone else, probably harder. Why? Why, if not to make
bitcoin more valuable?
Even apart from the convenience/curse of real-time exchange markets,
just with an abstract definition of "value," isn't that exactly what a
developer can influence, if not "control?"
Isn't figuring out ways to increase the value of bitcoin what we are doing?

2023-06-07 15:43:01

- reply

📅 Original date posted:2015-07-24
📝 Original message:On 7/23/2015 10:51 AM, Jorge Timón wrote:
> We know perfectly well that the system will need to eventually be
> sustained by fees.
Fee revenue can rise just as easily without increased BTC fee rates.
Two avenues that are just as effective: increased exchange rate,
increased number of fee-paying transactions. Neither of these avenues
benefits from increased "fee pressure" (scarcity of block space).
> I just disagree that changing a constant is a "scaling solution".
>
Nobody here thinks that. Even on Reddit, not very many people seem to
think that.

2023-06-07 15:42:51

- reply

📅 Original date posted:2015-07-23
📝 Original message:On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
> If the user expectation is that a price would never arise because
> supply is going to be increased ad infinitum and they will always be
> able to send fast in-chain bitcoin transactions for free, just like
> breath air (an abundant resource) for free, then we should change that
> expectation as soon as possible.
No. We should accept that reality may change, and we should promote
understanding of that fact.
We should not artificially manipulate the market "as soon as possible,"
since we ourselves don't know much at all about how the market will
unfold in the future.
> the criteria for the consensus block size should be purely based on
> technological capacity (propagation benchmarking, etc) and
> centralization concerns
Right, purely these. There is no place for artificially manipulating
expectations.
> they will simply advance the front and start another battle, because
> their true hidden faction is the "not ever side". Please, Jeff, Gavin,
> Mike, show me that I'm wrong on this point. Please, answer my question
> this time. If "not now", then when?
Bitcoin has all the hash power. The merkle root has effectively
infinite capacity. We should be asking HOW to scale the supporting
information propagation system appropriately, not WHEN to limit the
capacity of the primary time-stamping machine.
We haven't tried yet. I can't answer for the people you asked, but
personally I haven't thought much about when we should declare failure.

2023-06-07 15:42:31

- reply

📅 Original date posted:2015-07-22
📝 Original message:On 7/21/2015 6:58 AM, Peter Todd via bitcoin-dev wrote:
> Re: BIP #'s, we explicitly have a policy of allocating them for stupid
> ideas, to avoid having to be gatekeepers. Ironically that makes it
> harder to get a BIP # if you know what you're doing, because Gregory
> Maxwell will argue against you in private and delay actually
> allocating one if he knows you should know better. :)
Kalle asked for a BIP# for his PoP standardization proposal one month
ago. Should he have known better?

2023-06-07 15:42:20

- reply

📅 Original date posted:2015-07-15
📝 Original message:You perform a valuable service with your demonstration, but you
neglected to include the txid's to show that you actually did it.
Your advice is must-follow for anyone relying on an unconfirmed tx: it
must pay a good fee and be highly relayable/minable.
On 7/14/2015 8:29 PM, simongreen--- via bitcoin-dev wrote:
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc.
> anything that miners don't always accept.

2023-06-07 15:42:19

- reply

📅 Original date posted:2015-07-16
📝 Original message:On 7/16/2015 2:38 AM, Thomas Zander via bitcoin-dev wrote:
> On Wednesday 15. July 2015 16.15.24 Tom Harding via bitcoin-dev wrote:
>> On 7/15/2015 12:18 PM, Thomas Zander via bitcoin-dev wrote:
>>> On Tuesday 14. July 2015 17.24.23 Tom Harding via bitcoin-dev wrote:
>>>> Rule 2: A transaction and its dependents are evicted on its 2-hour
>>>> anniversary, whether space is required or not
>>> Instead of 2 hours, why not a number of blocks?
>> So users/wallets can know when they should rebroadcast and consider
>> increasing the fee.
>>
>>
>> Using 12 blocks, there is a 5% chance he has to wait 3 hours.*
>>
>> Using 120 minutes, there is only a .23% chance that fewer than 4 blocks
>> have occurred.**
> Using the good old saying; results in the past are no indication of the
> future.
> I see a logic error in your thinking.
>
> Your assumption that time is a better indicator is false. Naturally time
> itself is universal, but blocks are known by wallets too. Its just as good.
>
> This assumption of yours leans heavily on block mining times, and that is
> not guaranteed in the future. Imagine one day half the miners dropping and
> blocks take much longer for a week or so. Your assumptions just broke the
> mempool.
>
It's not a question of right vs. wrong. Either method has consequences
for user expectations and behavior.
With fixed-block mempool expiration, the expiration time is variable.
User can get an alert, but at an unpredictable time.
With fixed-timeout, the likelihood of expiration is more variable
(expiration occurrence is unpredictable regardless), but any expiration
will occur at the timeout.

2023-06-07 15:42:18

- reply

📅 Original date posted:2015-07-15
📝 Original message:On 7/15/2015 12:18 PM, Thomas Zander via bitcoin-dev wrote:
> On Tuesday 14. July 2015 17.24.23 Tom Harding via bitcoin-dev wrote:
>> Rule 2: A transaction and its dependents are evicted on its 2-hour
>> anniversary, whether space is required or not
> Instead of 2 hours, why not a number of blocks?
So users/wallets can know when they should rebroadcast and consider
increasing the fee.
Using 12 blocks, there is a 5% chance he has to wait 3 hours.*
Using 120 minutes, there is only a .23% chance that fewer than 4 blocks
have occurred.**
*
Table[{x, 1 - CDF[ErlangDistribution[12, 1/10], x]}, {x, 0, 240, 10}]
//N //TableForm
0. 1.
10. 1.
20. 0.999999
30. 0.999929
40. 0.999085
50. 0.994547
60. 0.979908
70. 0.94665
80. 0.888076
90. 0.803008
100. 0.696776
110. 0.579267
120. 0.461597
130. 0.353165
140. 0.26004
150. 0.184752
160. 0.126993
170. 0.0846691
180. 0.0548874
190. 0.0346726
200. 0.0213868
210. 0.0129048
220. 0.00762994
230. 0.00442702
240. 0.00252413
**
Table[{x, CDF[PoissonDistribution[1/10 * 120], x]}, {x, 0, 20}] //N
//TableForm
0. 6.14421*10^-6
1. 0.0000798748
2. 0.000522258
3. 0.00229179
4. 0.00760039
5. 0.020341
6. 0.0458223
7. 0.0895045
8. 0.155028
9. 0.242392
10. 0.347229
11. 0.461597
12. 0.575965
13. 0.681536
14. 0.772025
15. 0.844416
16. 0.898709
17. 0.937034
18. 0.962584
19. 0.97872
20. 0.988402

2023-06-07 15:42:18

- reply

📅 Original date posted:2015-07-14
📝 Original message:Spammers out there are being very disrepectful of my fullnode resources
these days! I'm making some changes. In case others are interested,
here's a description:
There is now a maximum size for the memory pool. Space is allocated
with a pretty simple rule. For each tx, I calculate MY COST of
continuing to hold it in the mempool. I measure the cost to me by
"expected byte stay":
expectedByteStay = sizeBytes * expectedBlocksToConfirm(feeRate)
Rule 1: When there's not enough space for a new tx, I try to make space
by evicting txes with expectedByteStay higher than tx.
I'm NOT worrying about
- Fees
EXCEPT via their effect on confirmation time
- Coin age
You already made money on your old coins. Pay up.
- CPFP
Child's expectedBlocksToConfirm is max'ed with its
parent, then parent expectedByteStay is ADDED to child's
- Replacement
You'll get another chance in 2 hours (see below).
Rule 2: A transaction and its dependents are evicted on its 2-hour
anniversary, whether space is required or not
The latest expectedBlocksToConfirm(feeRate) table is applied to the
entire mempool periodically.
What do you think? I'll let you know how it works out. I'm putting a
lot of faith in the new fee estimation (particularly its size
independence). Another possibility is clog-ups by transactions that
look like they'll confirm next block, but don't because of factors other
than fees (other people's blacklists?)

2023-06-07 15:41:50

- reply

📅 Original date posted:2015-07-09
📝 Original message:>> On 6/28/2015 9:32 AM, Raystonn . wrote:
>>> Write coalescing works fine when you have multiple writes headed to
>>> the same (contiguous) location. Will lightning be useful when we
>>> have more unique transactions being sent to different addresses, and
>>> not just multiple transactions between the same sender and address?
>>> I have doubts.
> On 6/28/2015 10:29 AM, Gavin Andresen wrote:
>> Don't get me wrong, I think the Lightning Network is a fantastic idea
>> and a great experiment and will likely be used for all sorts of great
>> payment innovations (micropayments for bandwidth maybe, or maybe
>> paying workers by the hour instead of at the end of the month). But I
>> don't think it is a scaling solution for the types of payments the
>> Bitcoin network is handling today.
On 6/28/2015 11:58 AM, Adam Back wrote:
> Lightning allows Bitcoin to scale even without a block-size increase,
> and therefore considerably impacts any calculation of how much
> block-size is required. In this light you appear to have been
> attempting to push through a change without even understanding the
> alternatives or greater ecosystem.
Lightning Network (LN) does not "allow Bitcoin to scale". LN is a
bitcoin application. The properties of LN are dependent on bitcoin, but
they are distinct from bitcoin.
In particular, an under-appreciated aspect of LN is that in order for
your interactions to be consolidated and consume less blockchain space,
you must give up significant control of the money you send AND the money
you receive.
If either sender or receiver wants to record a transaction in the
blockchain immediately, there is no space savings versus bitcoin. More
blockchain space is actually, used, due to LN overhead.
If both sender and receiver are willing to delay recording in the
blockchain, then the situation is analogous to using banks. Sender's
hub pays from sender channel, to receiver channel at receiver's hub.
Neither side fully relinquishes custody of the money in their multisig
payment hub channels -- this is an improvement on traditional bank
accounts -- BUT...
- Sender is required to lock funds under his hub's signature - this is
well discussed
- Less well discussed: *to achieve any consolidation at all, receiver
must ALSO be willing to lock received funds under his hub's signature*
I'll put it another way. LN only "solves" the scaling problem if
receiver's hub has pre-commited sufficient funds to cover the receipts,
AND if receiver endures for a period of time -- directly related to the
scaling factor -- being unable to spend money received UNLESS his
payment hub signs off on his spend instructions.

2023-06-07 15:41:49

- reply

📅 Original date posted:2015-07-09
📝 Original message:Replace-by-anything can only work if conflicts are relayed, so the
solution is not to act against the peer.
Alex Morcos offered a suggestion on IRC -- track recently-rejected
txid's and don't getdata them. The idea sounds good to me.
On 7/9/2015 4:55 PM, Matt Whitlock wrote:
> I'm presently running my full node with Peter Todd's full replace-by-fee patch set [1]. I am seeing a LOT of messages in the log about replacement transactions being rejected due to their paying less in fees than the transactions they would replace. I understand that this could happen legitimately from time to time, due to my node's receiving a replacing transaction prior to receiving the replaced transaction; however, due to the ongoing spam attack, I am seeing a steady stream of these rejection messages, dozens per second at times. I am wondering if each replacement rejection ought to penalize the peer who relayed the offending transaction, and if the penalty builds up enough, then the peer could be temporarily banned, similar to how other "misbehaving" peers are treated.
>
> [1] https://github.com/petertodd/bitcoin/commits/replace-by-fee-v0.10.2
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:41:44

- reply

📅 Original date posted:2015-07-05
📝 Original message:Never mind that last bit. I overlooked that the other inputs can
independently make the tx non-final.
On 7/5/2015 12:50 PM, Tom Harding wrote:
>
> It would also allow an explicit relative locktime of 0, which would
> help applications avoid accidentally finalizing the whole transaction
> when they only meant to not impose a relative locktime on one input.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150705/d3c22ca9/attachment.html>

2023-06-07 15:41:44

- reply

📅 Original date posted:2015-07-05
📝 Original message:Or you could flip the definition of your activation bit. That would
avoid the inversion and put relative locktimes outside the realm of both
the MAX_INT and MAX_INT - 1 values.
It would also allow an explicit relative locktime of 0, which would help
applications avoid accidentally finalizing the whole transaction when
they only meant to not impose a relative locktime on one input.
On 7/5/2015 10:07 AM, Mark Friedenbach wrote:
> Note that you can put 0 in the sequence number field and it would work
> just as expected under the old rules. I will perhaps suggest instead
> that Bitcoin Core post-0.11 switch to doing this instead for that case.
>
> On Sun, Jul 5, 2015 at 8:00 AM, Tom Harding <tomh at thinlink.com
> <mailto:tomh at thinlink.com>> wrote:
>
> BIP 68 uses nSequence to specify relative locktime, but nSequence also
> continues to condition the transaction-level locktime.
>
> This dual effect will prevent a transaction from having an effective
> nLocktime without also requiring at least one of its inputs to be
> mined
> at least one block (or one second) ahead of its parent.
>
> The fix is to shift the semantics so that nSequence = MAX_INT - 1
> specifies 0 relative locktime, rather than 1. This change will also
> preserve the semantics of transactions that have already been created
> with the specific nSequence value MAX_INT - 1 (for example all
> transactions created by the bitcoin core wallet starting in 0.11).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto: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/20150705/c0628db2/attachment.html>

2023-06-07 15:41:43

- reply

📅 Original date posted:2015-07-05
📝 Original message:Since you're removing a working capability, you should be the one to
prove it is unneeded.
But the simple example is the case where the input is also locked.
On 7/5/2015 9:17 AM, Mark Friedenbach wrote:
>
> Can you construct an example? Are there use cases where there is a
> need for an enforced lock time in a transaction with inputs that are
> not confirmed at the time the lock time expires?
>
> On Jul 5, 2015 8:00 AM, "Tom Harding" <tomh at thinlink.com
> <mailto:tomh at thinlink.com>> wrote:
>
> BIP 68 uses nSequence to specify relative locktime, but nSequence also
> continues to condition the transaction-level locktime.
>
> This dual effect will prevent a transaction from having an effective
> nLocktime without also requiring at least one of its inputs to be
> mined
> at least one block (or one second) ahead of its parent.
>
> The fix is to shift the semantics so that nSequence = MAX_INT - 1
> specifies 0 relative locktime, rather than 1. This change will also
> preserve the semantics of transactions that have already been created
> with the specific nSequence value MAX_INT - 1 (for example all
> transactions created by the bitcoin core wallet starting in 0.11).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto: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/20150705/7e1dd1b2/attachment.html>

2023-06-07 15:41:42

- reply

📅 Original date posted:2015-07-05
📝 Original message:BIP 68 uses nSequence to specify relative locktime, but nSequence also
continues to condition the transaction-level locktime.
This dual effect will prevent a transaction from having an effective
nLocktime without also requiring at least one of its inputs to be mined
at least one block (or one second) ahead of its parent.
The fix is to shift the semantics so that nSequence = MAX_INT - 1
specifies 0 relative locktime, rather than 1. This change will also
preserve the semantics of transactions that have already been created
with the specific nSequence value MAX_INT - 1 (for example all
transactions created by the bitcoin core wallet starting in 0.11).

2023-06-07 15:41:20

- reply

📅 Original date posted:2015-06-30
📝 Original message:On 6/30/2015 12:54 PM, Adam Back wrote:
> Secondly on the interests and incentives - miners also play an
> important part of the ecosystem and have gone through some lean times,
> they may not be overjoyed to hear a plan to just whack the block-size
> up to 8MB. While it's true (within some limits) that miners could
> collectively keep blocks smaller, there is the ongoing reality that
> someone else can take break ranks and take any fee however de minimis
> fee if there is a huge excess of space relative to current demand and
> drive fees to zero for a few years. A major thing even preserving
> fees is wallet defaults, which could be overridden(plus protocol
> velocity/fee limits).
Let's pretend it is late 2012.
Nobody has ever violated the soft limit of 500KB/block.
Block reward is about to be cut in half.
Fees are right where they are today.
1 BTC = about $15.
It's a good thing nothing was done in 2012 to try to boost fees out of
concern for miner profits.
Nor should we today. The 16X rise in the economic value¹ of the block
reward since that time covers the entire .5X effect of the halving
itself, plus three additional halvings. There is far less reason today
to worry on miners' behalf about fees than there was in late 2012.
Running out of ways to grow does threaten miner profit, and therefore
security, growth. So let's hope all the scaling ideas work.
> I'm not sure if anyone has a clear picture of what limits are imposed
> by hash-rate even today.
From the all-blocksizes plot, it's clear visually that the 750K soft
limit, and another less common soft limit at 900K, are being imposed,
but broken more and more frequently as demand outpaces them.
These soft limits serve no purpose, other than to delay transactions. A
750KB block is followed by another 750KB or larger block just as
frequently as you would expect from the actual block time distribution,
which recently (prior to spam now underway) had a rate of a full 1MB
block being needed every 104 minutes (in an earlier post I gave a
relation which is very stable, given the stable average transaction size).
___________________
¹Someday, if bitcoin is wildly successful, exchange rates vs. obsolete
currencies won't be meaningful. If that happens, increases in the
economic value of bitcoin will likely be measured by decreases in the
general price level of all goods and services.

2023-06-07 15:41:13

- reply

📅 Original date posted:2015-06-29
📝 Original message:On 6/29/2015 5:51 PM, Natanael wrote:
> What you ask to see implemented will trivially fall to a sybil attack.
> It isn't securable. It is running on the honor system exclusively. It
> will be attacked, it will fail, losses will be had, the attackers will
> walk away with embarrassingly large sums.
Oh please. Checking that a node does relay something is not much
different than banning it for relaying garbage.
It just happens to require that you have two nodes and coordinate them
somehow. I didn't offer a complete design, don't claim magical
properties, and certainly didn't mean to imply that nodes passing a test
could be trusted (as you suggest with your "accountable parties").

2023-06-07 15:41:13

- reply

📅 Original date posted:2015-06-29
📝 Original message:On 6/28/2015 10:07 PM, Peter Todd wrote:
> Worryingly large payment providers have shown
> willingness(4) to consider extreme measures such as entering into legal
> contracts directly with large miners to ensure their transactions get mined.
> This is a significant centralization risk and it is not practical or even
> possible for small miners to enter into these contracts, leading to a situation
> where moving your hashing power to a larger pool will result in higher profits
> from hashing power contracts; if these payment providers secure a majority of
> hashing power with these contracts inevitably there will be a temptation to
> kick non-compliant miners off the network entirely with a 51% attack.
>
Your incomprehensible meddling with successful usage patterns threatens
to have unintended consequences directly in opposition to your own
stated goal of decentralization. And yet you persist.
As we deliberately break things and turn the P2P network into a
completely unpredictable hodge-podge of relay policies, we should expect
many more participants to bypass the P2P network entirely.
Many of the pieces are already in place.
If we wanted the P2P network to have more predicable behavior, it would
be possible for nodes to provide incentives to their neighbors. For
example, if you had a pair of nodes, you could test your peers to see
that they actually do relay "standard" transactions. This would have
emergent usability benefits for the P2P network as a whole.

2023-06-07 15:41:13

- reply

📅 Original date posted:2015-06-29
📝 Original message:On 6/29/2015 6:10 PM, Natanael wrote:
> you have no reason to care
Of course I do. I'll boot them and replace them with somebody who will
relay the items I send them. I'm not here to send things into a black
hole taking up one of my connection slots.

2023-06-07 15:41:00

- reply

📅 Original date posted:2015-06-29
📝 Original message:On 6/28/2015 3:07 PM, Adam Back wrote:
> We dont know what that limit is but people have been imagining 1,000
> or 10,000 transactions per anchor transaction. Basically users would
> park Bitcoins a on a hub channel instead of the blockchain.
This re-introduces a solved problem (solved by bitcoin better than
anything else) - worrying whether your "payment hub" actually connects
to whom you wish to pay.
There will be enormous network effects and centralization pressure in
the payment-hub space. A few entities, maybe single entity, should be
expected to quickly corner the market and own the whole thing.
This concept is far too untested to justify amateur economic meddling in
the bitcoin fee market by setting a restrictive hard cap below technical
feasibility.
I can guess exactly who would want to keep bitcoin from improving:
*those who hope to be the future payment hub oligarchs*.

2023-06-07 15:40:28

- reply

📅 Original date posted:2015-06-26
📝 Original message:On 6/26/2015 7:09 AM, Pieter Wuille wrote:
> Furthermore, systems that compete with Bitcoin in this space already
> offer orders of magnitude more capacity than we can reasonably achieve
> with any blockchain technology at this point.
"Reasonably achievable" is a guideline that would keep bitcoin out of
trouble caused by either too little, or too much, declared capacity.
This matches Gavin's thinking, though you may differ on the numbers.
> it seems silly to make a huge increase at once...
Unless it is reasonably achievable. Leave the rest to the free market.

2023-06-07 15:40:28

- reply

📅 Original date posted:2015-06-26
📝 Original message:Venzen --
The market for block space is not at all the same as the market for bitcoin.
The centralization risk that is discussed in relation to the market for
block space arises from the resources (network, storage, processor...)
required to run a full node. That is a consideration in determining the
actual (as opposed to declared) capacity of the system.
The 1MB cap was not indexed to increasing resource availability to begin
with, so one way to determine the size of any initial hard cap increase
would be to estimate the change in resource availability since that time.

2023-06-07 15:40:24

- reply

📅 Original date posted:2015-06-25
📝 Original message:On 6/24/2015 8:00 PM, Raystonn wrote:
>
> > Consensus-code changes are unanimous. They must be.
>
> Excellent. Now we are getting to some actual written rules. How about
> updating the BIP process documentation with this? Everyone should be
> able to read the rules of the coin they are buying.
>
> One moment though. Can you tell me how this particular rule came to
> be? The creator of Bitcoin violated this rule many times. So it must
> have been adopted after his departure. What process was followed to
> adopt this new rule? Was there consensus for it at the time? A huge
> portion of the user community is under the impression that Satoshi's
> written plans, some of which violate this new rule, will be
> implemented. So there certainly would not be consensus for this rule
> today.
>
Great question; very fair. I, for one, eagerly await Mark's answer.
I hope nobody forgot to tell adversaries totally outside the open source
ecosystem what the rules for hard forking changes are.
The Chinese miners have it right - we have to work together. If you
want to see who's trying, look at who has written a concrete BIP/code
vs. who hasn't; who has made changes in response to feedback, and who
hasn't.

2023-06-07 15:39:11

- reply

📅 Original date posted:2015-06-21
📝 Original message:On 6/20/2015 5:54 PM, Eric Lombrozo wrote:
> Perhaps it isn’t prudent to push out changes to the relay policy that make these exploits even easier right now - but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient so that we have more room for changes on things like relay policy without significant disruption to the network.
>
There's no need to worry about causing more problems by relaying
double-spends. After a year of watching, it's clear that already only
20% of hash power strictly obeys first-seen.
http://i.imgur.com/0bYXrjn.png
It may be surprising that
- The period of ambiguity is very short - just 2 seconds
(this makes sense, given the .5s median propagation time)
- Fast double-spends between 2 and 15 seconds are less successful
- The steady-state 80% respend success rate is reached after just 15
seconds
The >30s data point includes txes that were respent after a long time,
sometimes months. Those longer-term respends are to be expected, as
people reclaim stuck txes.
Paying attention to double-spends is an opportunity for wallets and
merchants . With 140 Bitcoin XT nodes online, you're probably already
receiving them. Most wallets, including vanilla core, don't even alert
when a double-spend of a wallet transaction appears in a block - even
though there may still be time to withhold delivery of the goods/services.
If FSS RBF gains miner share, fewer successful zero-conf double-spends
will occur. Only radical twisted logic finds that to be an undesirable
result.

2023-06-07 15:38:50

- reply

📅 Original date posted:2015-06-19
📝 Original message:On 6/19/2015 6:43 AM, Mike Hearn wrote:
> No surprise, the position of Blockstream employees is that hard forks
> must never happen and that everyone's ordinary transactions should go
> via some new network that doesn't yet exist.
If my company were working on spiffy new ideas that required a hard fork
to implement, I'd be rather dismayed to see the blocksize hard fork
happen *before those ideas were ready*.
Because then I'd eventually have to convince people that those ideas
were worth a hard fork all on their own. It would be much easier to
convince people to roll them in with the already necessary blocksize
hard fork, if that event could be delayed.
As far as I know, Blockstream representatives have never said that
waiting for other changes to be ready is a reason to delay the blocksize
hard fork. So if this were the real reason, it would suggest they have
been hiding their true motives for making such a fuss about the
blocksize issue.
I've got no evidence at all to support thoughts like this... just the
paranoid mindset that seems to infect a person who gets involved in
bitcoin. But the question is every bit as valid as Adam's query into
your motives.

2023-06-07 15:37:25

- reply

📅 Original date posted:2015-06-18
📝 Original message:On 06/12/2015 06:51 PM, Pieter Wuille wrote:
>> However, it does very clearly show the effects of
>> larger blocks on centralization pressure of the system.
On 6/14/2015 10:45 AM, Jonas Nick wrote:
> This means that your scenario is not the result of a cartel but the result of a long-term network partition.
>
Pieter, to Jonas' point, in your scenario the big miners are all part of
the majority partition, so "centralization pressure" (pressure to merge
with a big miner) cannot be separated from "pressure to be connected to
the majority partition".
I ran your simulation with a large (20%) miner in a 20% minority
partition, and 16 small (5%) miners in a majority 80% partition, well
connected. The starting point was your recent update, which had a more
realistic "slow link" speed of 100 Mbit/s (making all of the effects
smaller).
To summarize the results across both your run and mine:
** Making small blocks when others are making big ones -> BAD
** As above, and fees are enormous -> VERY BAD
** Being separated by a slow link from majority hash power -> BAD
** Being a small miner with blocksize=20MB -> *NOT BAD*
Configuration:
* Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 80.000000% hashrate, blocksize 1000000.000000
* Expected average block size: 4800000.000000
* Average fee per block: 0.250000
* Fee per byte: 0.0000000521
Result:
* Miner group 0: 20.404704% income (factor 1.020235 with hashrate)
* Miner group 1: 79.595296% income (factor 0.994941 with hashrate)
Configuration:
* Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 80.000000% hashrate, blocksize 20000000.000000
* Expected average block size: 20000000.000000
* Average fee per block: 0.250000
* Fee per byte: 0.0000000125
Result:
* Miner group 0: 19.864232% income (factor 0.993212 with hashrate)
* Miner group 1: 80.135768% income (factor 1.001697 with hashrate)
Configuration:
* Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 80.000000% hashrate, blocksize 1000000.000000
* Expected average block size: 4800000.000000
* Average fee per block: 25.000000
* Fee per byte: 0.0000052083
Result:
* Miner group 0: 51.316895% income (factor 2.565845 with hashrate)
* Miner group 1: 48.683105% income (factor 0.608539 with hashrate)
Configuration:
* Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 80.000000% hashrate, blocksize 20000000.000000
* Expected average block size: 20000000.000000
* Average fee per block: 25.000000
* Fee per byte: 0.0000012500
Result:
* Miner group 0: 19.865943% income (factor 0.993297 with hashrate)
* Miner group 1: 80.134057% income (factor 1.001676 with hashrate)