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

nprofile1qqsdcv56qtyhp24lqwu8rp0028yx4lj9smlr59y9pzhcnzhnl279dgcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsz04274

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1msef5qkfwz4t7qacwxz775wgdtlytph78g2g2z903x90874u263sypmwjy

Show more details

Last Notes

2023-06-08 01:11:45 CEST

- 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 19:55:38 CEST

- 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 19:55:37 CEST

- 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 19:55:37 CEST

- 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 19:54:52 CEST

- 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 19:53:23 CEST

- 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 19:53:22 CEST

- 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 19:50:33 CEST

- 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 19:50:32 CEST

- 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 19:42:50 CEST

- 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 19:40:11 CEST

- 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 19:40:10 CEST

- 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 19:37:38 CEST

- 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 19:37:35 CEST

- 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 19:36:22 CEST

- 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 19:34:58 CEST

- 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 19:33:53 CEST

- 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 19:33:05 CEST

- 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 19:33:01 CEST

- 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 19:32:34 CEST

- 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:49:01 CEST

- reply

2023-06-07 17:47:58 CEST

- 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:47:57 CEST

- reply

2023-06-07 17:45:58 CEST

- reply

2023-06-07 17:45:28 CEST

- 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:45:17 CEST

- reply

2023-06-07 17:45:14 CEST

- reply

2023-06-07 17:44:09 CEST

- 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 17:44:08 CEST

- 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 17:44:08 CEST

- 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 17:43:05 CEST

- 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 17:43:03 CEST

- 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 17:43:02 CEST

- 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 17:43:01 CEST

- 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 17:42:51 CEST

- 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 17:42:31 CEST

- 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 17:42:20 CEST

- 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 17:42:18 CEST

- 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 17:41:49 CEST

- 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 17:41:00 CEST

- 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 17:40:28 CEST

- 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 17:40:28 CEST

- 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 17:39:11 CEST

- 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 17:36:49 CEST

- reply

📅 Original date posted:2015-06-06
📝 Original message:On Jun 6, 2015 8:05 AM, "Kalle Rosenbaum" <kalle at rosenbaum.se> wrote:
> I'm open to changes here.
I suggest:
- Don't include any real outputs. They are redundant because the txid is
already referenced.
- Start the proof script, which should be invalid, with a magic constant
and include space for future expansion. This makes PoP's easy to identify
and extend.
- "Proof of Potential"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/d5ea22a1/attachment.html>

2023-06-07 17:35:18 CEST

- reply

📅 Original date posted:2015-05-14
📝 Original message:A recent post, which I cannot find after much effort, made an excellent
point.
If capacity grows, fewer individuals would be able to run full nodes.
Those individuals, like many already, would have to give up running a
full-node wallet :(
That sounds bad, until you consider that the alternative is running a
full node on the bitcoin 'settlement network', while massive numbers of
people *give up any hope of directly owning bitcoin at all*.
If today's global payments are 100Ktps, and move to the Lightning
Network, they will have to be consolidated by a factor of 25000:1 to fit
into bitcoin's current 4tps capacity as a settlement network. You
executing a personal transaction on that network will be about as likely
as you personally conducting a $100 SWIFT transfer to yourself today.
For current holders, just selling or spending will get very expensive!
Forcing block capacity to stay small, so that individuals can run full
nodes, is precisely what will force bitcoin to become a backbone that is
too expensive for individuals to use. I can't avoid the conclusion that
Bitcoin has to scale, and we might as well be thinking about how.
There may be a an escape window. As current trends continue toward a
landscape of billions of SPV wallets, it may still be possible for
individuals collectively to make up the majority of the network, if more
parts of the network itself rely on SPV-level security.
With SPV-level security, it might be possible to implement a scalable
DHT-type network of nodes that collectively store and index the
exhaustive and fast-growing corpus of transaction history, up to and
including currently unconfirmed transactions. Each individual node
could host a slice of the transaction set with a configurable size,
let's say down to a few GB today.
Such a network would have the desirable property of being run by the
community. Most transactions would be submitted to it, and like today's
network, it would disseminate blocks (which would be rapidly torn apart
and digested). Therefore miners and other full nodes would depend on
it, which is rather critical as those nodes grow closer to data-center
proportions.

2023-06-07 17:33:18 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:On 5/7/2015 12:54 PM, Jeff Garzik wrote:
> In the short term, blocks are bursty, with some on 1 minute intervals,
> some with 60 minute intervals. This does not change with larger blocks.
>
I'm pretty sure Alan meant that blocks are already filling up after long
inter-block intervals.
>
> 2) Where do you want to go? Should bitcoin scale up to handle all the
> world's coffees?
Alan was very clear. Right now, he wants to go exactly where Gavin's
concrete proposal suggests.

2023-06-07 17:33:18 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:On 5/7/2015 7:09 PM, Jeff Garzik wrote:
>
> G proposed 20MB blocks, AFAIK - 140 tps
> A proposed 100MB blocks - 700 tps
> For ref,
> Paypal is around 115 tps
> VISA is around 2000 tps (perhaps 4000 tps peak)
>
> I ask again: where do we want to go? This is the existential
> question behind block size.
>
> Are we trying to build a system that can handle Paypal volumes? VISA
> volumes?
>
> It's not a snarky or sarcastic question: Are we building a system to
> handle all the world's coffees? Is bitcoin's main chain and network -
> Layer 1 - going to receive direct connections from 500m mobile phones,
> broadcasting transactions?
>
> We must answer these questions to inform the change being discussed
> today, in order to decide what makes the most sense as a new limit.
> Any responsible project of this magnitude must have a better story
> than "zomg 1MB, therefore I picked 20MB out of a hat" Must be able to
> answer /why/ the new limit was picked.
>
> As G notes, changing the block size is simply kicking the can down the
> road:
> http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
> Necessarily one must ask, today, what happens when we get to the end
> of that newly paved road.
>
>
Accepting that outcomes are less knowable further into the future is not
the same as failing to consider the future at all. A responsible
project can't have a movie-plot roadmap. It needs to give weight to
multiple possible future outcomes.
http://en.wikipedia.org/wiki/Decision_tree
One way or another, the challenge is to decide what to do next. Beyond
that, it's future decisions all the way down.
Alan argues that 7 tps is a couple orders of magnitude too low for any
meaningful commercial activity to occur, and too low to be the final
solution, even with higher layers. I agree. I also agree with you,
that we don't really know how to accomplish 700tps right now.
What we do know is if we want to bump the limit in the short term, we
ought to start now, and until there's a better alternative root to the
decision tree, it just might be time to get moving.

2023-06-07 17:33:03 CEST

- reply

📅 Original date posted:2015-05-06
📝 Original message:On 5/6/2015 3:12 PM, Matt Corallo wrote:
> Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively
> consistently full or very nearly full.
I think it's way too early to even consider a future era when the fiat
value of the block reward is no longer the biggest-by-far mining incentive.
Creating fee pressure means driving some people to choose something
else, not bitcoin. "Too many people using bitcoin" is nowhere on the
list of problems today. It's reckless to tinker with adoption in hopes
of spurring innovation on speculation, while a "can kick" is available.
Adoption is currently at miniscule, test-flight, relatively
insignificant levels when compared to global commerce. As Gavin
discussed in the article, under "Block size and miner fees… again," the
best way to maximize miner incentives is to focus on doing things that
are likely to increase adoption, which, in our fiat-dominated world,
lead to a justifiably increased exchange rate.
Any innovation attractive enough to relieve the block size pressure will
do so just as well without artificial stimulus.
Thanks for kicking off the discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150506/259707d3/attachment.html>

2023-06-07 17:32:14 CEST

- reply

📅 Original date posted:2015-03-26
📝 Original message:On 3/26/2015 1:42 PM, Gregory Maxwell wrote:
> Which is why a simpler, safer, client enforced behavior is probably
> preferable. Someone who wants to go hack their client to make a
> payment that isn't according to the payee will have to live with the
> results, esp. as we can't prevent that in a strong sense.
I should have been clearer that the motivation for address expiration is
to reduce the rate of increase of the massive pile of bitcoin addresses
out there which have to be monitored forever for future payments. It
could make a significant dent if something like this worked, and were
used by default someday.
Address expiration is not an enhancement to the payment experience and
it doesn't stop sender from doing something weird. Hacking a new
address for the recipient would be just as weird as hacking their client
IMHO.

2023-06-07 17:32:14 CEST

- reply

📅 Original date posted:2015-03-26
📝 Original message:On 3/26/2015 2:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh at thinlink.com> wrote:
>> I should have been clearer that the motivation for address expiration is to
>> reduce the rate of increase of the massive pile of bitcoin addresses out
>> there which have to be monitored forever for future payments. It could make
>> a significant dent if something like this worked, and were used by default
>> someday.
> Great, that can be accomplished by simply encoding an expiration into
> the address people are using and specifying that clients enforce it.
Another way to look at it: is the benefit of the bitcoin network
providing this service sufficiently greater than the cost?
The main cost is that a reorganization has a chance of invalidating a
payment made at or just before expiration (if the payment isn't early
enough in the new chain). Would that increase recommended confirmations
above their current levels, which are centered around the possibility of
a malicious double-spend? Unclear to me.

2023-06-07 17:32:13 CEST

- reply

📅 Original date posted:2015-03-25
📝 Original message:On 3/25/2015 9:34 AM, Gregory Maxwell wrote:
>
>> address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366
> Assuming the sender is not an uncooperative idiot, you can simply
> include expiration information and the sender can refuse to send after
> that time.
Is this assuming payment protocol? A major benefit of address
expiration, if it works, would be that it works without requiring
payment protocol.
> If the sender is an uncooperative idiot, they can always change your
> target and send anyways.
Are you suggesting there is no implementation of address expiration that
wouldn't allow the string to be trivially changed by the sender?
>> Block containing tx invalid if a prior confirmed tx has paid address
> Requires a unprunable verification state.
I don't understand, explanation would be appreciated.

2023-06-07 17:32:13 CEST

- reply

📅 Original date posted:2015-03-26
📝 Original message:On 3/25/2015 12:22 PM, Gregory Maxwell wrote:
>
> Verification with duplicate elimination requires O(N) storage (with N
> being the length of the history), since you need to track all the
> duplicates to reject.
>
I addressed that by limiting the duplicate check to an X-block segment.
X is hard-coded in this simple scheme (X=144 => "1-day addresses").
You could picture a selectable expiration duration too.

2023-06-07 17:32:12 CEST

- reply

📅 Original date posted:2015-03-24
📝 Original message:The idea of limited-lifetime addresses was discussed on 2014-07-15 in
http://thread.gmane.org/gmane.comp.bitcoin.devel/5837
It appears that a limited-lifetime address, such as the fanciful
address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366
where 349366 is the last valid block for a transaction paying this
address, could be made reuse-proof with bounded resource requirements,
if for locktime'd tx paying address, the following were enforced by
consensus:
- Expiration
Block containing tx invalid at height > 349366
- Finality
Block containing tx invalid if (349366 - locktime) > X
(X is the address validity duration in blocks)
- Uniqueness
Block containing tx invalid if a prior confirmed tx has paid address
Just an an idea, obviously not a concrete proposal.

2023-06-07 17:30:12 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:On 2/12/2015 6:25 AM, Tamas Blummer wrote:
>
> Miner will see a mixed picture and will struggle to act “honestly” on
> a statistical measure.
The statistics come from the aggregate actions of all nodes, especially
those miners who watch p2p transactions and assemble blocks.
Any one node makes deterministic decisions based on its own observation
-- just like today's valid/invalid decision based on whether a blocktime
is within the next 2 hours or not.
The idea is that miners will exclude respends because they put the block
at risk of being forked off, with no offsetting payback. The design
point is to make sure this is sufficiently unlikely to happen
accidentally, or via some attack vector.

2023-06-07 17:20:56 CEST

- reply

📅 Original date posted:2014-05-03
📝 Original message:This idea was suggested by "Joe" on 2011-02-14
https://bitcointalk.org/index.php?topic=3441.msg48484#msg48484 . It
deserves another look.
Nodes today make a judgment regarding which of several conflicting
spends to accept, and which is a double-spend. But there is no
incorporation of these collective judgments into the blockchain. So
today, it's the wild west, right up until the next block. To address this:
- Using its own clock, node associates a timestamp with every
transaction upon first seeing its tx hash (at inv, in a block, or when
created)
- Node relays respend attempts (subject to anti-DOS rules, see github
PR #3883)
- Eventually, node adds a consensus rule:
Do not accept blocks containing a transaction tx2 where
- tx2 respends an output spent by another locally accepted
transaction tx1, and
- timestamp(tx2) - timestamp(tx1) > T
What is T?
According to http://bitcoinstats.com/network/propagation/ recent tx
propagation has a median of 1.3 seconds. If double-spender introduces
both transactions from the same node, assuming propagation times
distributed exponentially with median 1.3 seconds, the above consensus
rule with reject threshold T = 7.4 seconds would result in
mis-identification of the second-spend by less than 1% of nodes.*
If tx1 and tx2 are introduced in mutually time-distant parts of the
network, a population of nodes in between would be able to accept either
transaction, as they can today. But the attacker still has to introduce
them at close to the same time, or the majority of the network will
confirm the one introduced earlier.
Merchant is watching also, and these dynamics mean he will not have to
watch for very long to gain confidence if he was going to get
double-spent, he would have learned it by now. The consensus rule also
makes mining a never-broadcast double-spend quite difficult, because the
network assigns it very late timestamps. Miner has to get lucky and
find the block very quickly. In other words, it converges to a Finney
attack.
This would be the first consensus rule that anticipated less than 100%
agreement. But the parameters could be chosen so that it was still
extremely conservative. Joe also suggested a fail-safe condition: drop
this rule if block has 6 confirmations, to prevent a fork in unusual
network circumstances.
We can't move toward this, or any, solution without more data. Today,
the network is not transparent to double-spend attempts, so we mostly
have to guess what the quantitative effects would be. The first step is
to share the data broadly by relaying first double-spend attempts as in
github PR #3883.
*Calcs:
For Exp(lambda), median ln(2)/lambda = 1.3 ==> lambda = .533
Laplace(0,1/lambda) < .01 ==> T = 7.34 seconds

2023-06-07 17:19:49 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:On 4/23/2014 2:23 PM, Tier Nolan wrote:
> An interesting experiment would be a transaction "proof of
> publication" chain.
What if a transaction could simply point back to an earlier transaction,
forming a chain? Not a separately mined blockchain, just a way to
establish an official publication (execution) order. Double spends would
be immediately actionable with such a sequence. Transactions in a block
could eventually be required to be connected in such a chain. Miners
would have to keep or reject a whole mempool chain, since they lack the
keys to change the sequence. They would have to prune a whole tx
subchain to insert a double spend (and this would still require private
keys to the double spend utxo's).
This idea seemed promising, until I realized that with the collision
rebasing required, it would barely scale to today's transaction rate.
Something that scales to 10,000's of transactions per second, and really
without limit, is needed.
Anyway, I wrote it up here:
https://github.com/dgenr8/out-there/blob/master/tx-chains.md

2023-06-07 17:17:35 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:On 4/7/2014 7:05 AM, Mike Hearn wrote:
> Some days I wonder if Bitcoin will be killed off by people who just
> refuse to use it properly before it ever gets a chance to shine. The
> general public doesn't distinguish between "Bitcoin users" who deposit
> with a third party and the real Bitcoin users who don't.
>
A Mt-Gox-scale incident was inevitable and there are probably more hard
lessons in the future. But it has made bitcoin much better already.
I'm referring to things like malleability fixes, cleaning house at the
foundation, and public education (hard as the lesson was). A lot more
people than before understand the distinction you're making, and they
are sharing the lesson.