Nostr notes by Tom Harding [ARCHIVE]

📅 Original date posted:2022-07-12 📝 Original message:On ...

2023-06-07T23:11:45Z

In reply to nevent1q…kw2c
_________________________

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

📅 Original date posted:2017-03-30 📝 Original ...

2023-06-07T17:58:33Z

In reply to nevent1q…wkfk
_________________________

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

📅 Original date posted:2017-01-27 📝 Original ...

2023-06-07T17:55:38Z

In reply to nevent1q…60dx
_________________________

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

📅 Original date posted:2017-01-25 📝 Original message:On ...

2023-06-07T17:55:37Z

In reply to nevent1q…ucku
_________________________

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

📅 Original date posted:2017-01-24 📝 Original message:On ...

2023-06-07T17:55:37Z

In reply to nevent1q…j3qn
_________________________

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

📅 Original date posted:2016-12-18 📝 Original message:James, ...

2023-06-07T17:54:52Z

In reply to nevent1q…t5h3
_________________________

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

📅 Original date posted:2016-09-19 📝 Original message:On ...

2023-06-07T17:53:23Z

In reply to nevent1q…7xjh
_________________________

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

📅 Original date posted:2016-09-19 📝 Original ...

2023-06-07T17:53:22Z

In reply to nevent1q…rn2k
_________________________

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

📅 Original date posted:2016-05-12 📝 Original message:On May ...

2023-06-07T17:50:33Z

In reply to nevent1q…2avh
_________________________

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

📅 Original date posted:2016-05-11 📝 Original message:On ...

2023-06-07T17:50:32Z

In reply to nevent1q…c34r
_________________________

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

📅 Original date posted:2015-12-21 📝 Original message:On ...

2023-06-07T17:46:17Z

In reply to nevent1q…7xsk
_________________________

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

📅 Original date posted:2015-10-05 📝 Original message:On ...

2023-06-07T17:42:50Z

In reply to nevent1q…ht4c
_________________________

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

📅 Original date posted:2015-10-01 📝 Original message:On ...

2023-06-07T17:41:57Z

In reply to nevent1q…zv8r
_________________________

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

📅 Original date posted:2015-09-30 📝 Original message:On ...

2023-06-07T17:40:11Z

In reply to nevent1q…4tlk
_________________________

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

📅 Original date posted:2015-09-23 📝 Original message:On ...

2023-06-07T17:40:10Z

In reply to nevent1q…wr5s
_________________________

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

📅 Original date posted:2015-08-21 📝 Original message:On ...

2023-06-07T17:37:38Z

In reply to nevent1q…jmgw
_________________________

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

📅 Original date posted:2015-08-24 📝 Original message:On ...

2023-06-07T17:37:35Z

In reply to nevent1q…puzs
_________________________

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

📅 Original date posted:2015-08-21 📝 Original message:On ...

2023-06-07T17:36:22Z

In reply to nevent1q…sn5y
_________________________

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

📅 Original date posted:2015-08-23 📝 Original message:ack no ...

2023-06-07T17:34:58Z

In reply to nevent1q…68pq
_________________________

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

📅 Original date posted:2015-08-11 📝 Original message:On ...

2023-06-07T17:33:53Z

In reply to nevent1q…45tf
_________________________

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

📅 Original date posted:2015-08-06 📝 Original message:On ...

2023-06-07T17:33:22Z

In reply to nevent1q…qrk2
_________________________

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

📅 Original date posted:2015-08-06 📝 Original message:On ...

2023-06-07T17:33:19Z

In reply to nevent1q…vuwg
_________________________

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

📅 Original date posted:2015-08-09 📝 Original message:On Aug ...

2023-06-07T17:33:05Z

In reply to nevent1q…lnal
_________________________

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

📅 Original date posted:2015-08-09 📝 Original message:On ...

2023-06-07T17:33:01Z

In reply to nevent1q…vvl7
_________________________

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

📅 Original date posted:2015-08-06 📝 Original message:On ...

2023-06-07T17:32:34Z

In reply to nevent1q…essl
_________________________

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

📅 Original date posted:2015-08-24 📝 Original message:On ...

2023-06-07T15:49:01Z

In reply to nevent1q…y6wt
_________________________

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

📅 Original date posted:2015-08-23 📝 Original message:On ...

2023-06-07T15:47:58Z

In reply to nevent1q…8ec7
_________________________

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

📅 Original date posted:2015-08-21 📝 Original message:On ...

2023-06-07T15:47:57Z

In reply to nevent1q…v7uq
_________________________

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

📅 Original date posted:2015-08-21 📝 Original message:On ...

2023-06-07T15:47:57Z

In reply to nevent1q…qemf
_________________________

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

📅 Original date posted:2015-08-20 📝 Original message:On ...

2023-06-07T15:47:56Z

In reply to nevent1q…y86h
_________________________

📅 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

📅 Original date posted:2015-08-11 📝 Original message:On ...

2023-06-07T15:45:58Z

In reply to nevent1q…wdxp
_________________________

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

📅 Original date posted:2015-08-06 📝 Original message:On ...

2023-06-07T15:45:28Z

In reply to nevent1q…4tx5
_________________________

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

📅 Original date posted:2015-08-09 📝 Original message:On ...

2023-06-07T15:45:18Z

In reply to nevent1q…k06v
_________________________

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

📅 Original date posted:2015-08-09 📝 Original message:On Aug ...

2023-06-07T15:45:17Z

In reply to nevent1q…6udz
_________________________

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

📅 Original date posted:2015-08-09 📝 Original message:On ...

2023-06-07T15:45:14Z

In reply to nevent1q…lxw4
_________________________

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

📅 Original date posted:2015-08-06 📝 Original message:On ...

2023-06-07T15:44:52Z

In reply to nevent1q…7mju
_________________________

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

📅 Original date posted:2015-07-30 📝 Original message:On ...

2023-06-07T15:44:09Z

In reply to nevent1q…yavx
_________________________

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

📅 Original date posted:2015-07-30 📝 Original message:Yes. ...

2023-06-07T15:44:08Z

In reply to nevent1q…zd9x
_________________________

📅 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).
>

📅 Original date posted:2015-07-30 📝 Original message:On ...

2023-06-07T15:44:08Z

In reply to nevent1q…k9v2
_________________________

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

📅 Original date posted:2015-07-22 📝 Original message:On ...

2023-06-07T15:43:05Z

In reply to nevent1q…dtwx
_________________________

📅 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

📅 Original date posted:2015-07-28 📝 Original message:Jorge, ...

2023-06-07T15:43:03Z

In reply to nevent1q…t0d2
_________________________

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

📅 Original date posted:2015-07-24 📝 Original message:On ...

2023-06-07T15:43:02Z

In reply to nevent1q…v6u6
_________________________

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

📅 Original date posted:2015-07-24 📝 Original message:On ...

2023-06-07T15:43:01Z

In reply to nevent1q…0zu8
_________________________

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

📅 Original date posted:2015-07-23 📝 Original message:On ...

2023-06-07T15:42:51Z

In reply to nevent1q…wx65
_________________________

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

📅 Original date posted:2015-07-22 📝 Original message:On ...

2023-06-07T15:42:31Z

In reply to nevent1q…5d0s
_________________________

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

📅 Original date posted:2015-07-15 📝 Original message:You ...

2023-06-07T15:42:20Z

In reply to nevent1q…yxx6
_________________________

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

📅 Original date posted:2015-07-15 📝 Original message:On ...

2023-06-07T15:42:18Z

In reply to nevent1q…3dfa
_________________________

📅 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

📅 Original date posted:2015-07-14 📝 Original ...

2023-06-07T15:42:18Z

In reply to nevent1q…6tnk
_________________________

📅 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?)

📅 Original date posted:2015-07-09 📝 Original ...

2023-06-07T15:41:49Z

In reply to nevent1q…p60h
_________________________

📅 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

📅 Original date posted:2015-06-29 📝 Original message:On ...

2023-06-07T15:41:00Z

In reply to nevent1q…8gky
_________________________

📅 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*.

📅 Original date posted:2015-06-26 📝 Original message:On ...

2023-06-07T15:40:28Z

In reply to nevent1q…fzcj
_________________________

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

📅 Original date posted:2015-06-26 📝 Original message:Venzen ...

2023-06-07T15:40:28Z

In reply to nevent1q…fg4m
_________________________

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

📅 Original date posted:2015-06-21 📝 Original message:On ...

2023-06-07T15:39:11Z

In reply to nevent1q…rqme
_________________________

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

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.

📅 Original date posted:2015-06-06 📝 Original message:On Jun ...

2023-06-07T15:36:49Z

In reply to nevent1q…6m2y
_________________________

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

📅 Original date posted:2015-05-14 📝 Original message:A ...

2023-06-07T15:35:18Z

In reply to nevent1q…anqk
_________________________

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

📅 Original date posted:2015-05-07 📝 Original message:On ...

2023-06-07T15:33:18Z

In reply to nevent1q…p54j
_________________________

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

📅 Original date posted:2015-05-08 📝 Original message:On ...

2023-06-07T15:33:18Z

In reply to nevent1q…e3j7
_________________________

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

📅 Original date posted:2015-05-06 📝 Original message:On ...

2023-06-07T15:33:03Z

In reply to nevent1q…tdad
_________________________

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

📅 Original date posted:2015-03-26 📝 Original message:On ...

2023-06-07T15:32:14Z

In reply to nevent1q…ev62
_________________________

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

📅 Original date posted:2015-03-26 📝 Original message:On ...

2023-06-07T15:32:14Z

In reply to nevent1q…j6zh
_________________________

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

📅 Original date posted:2015-03-25 📝 Original message:On ...

2023-06-07T15:32:13Z

In reply to nevent1q…94cd
_________________________

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

📅 Original date posted:2015-03-26 📝 Original message:On ...

2023-06-07T15:32:13Z

In reply to nevent1q…gpqy
_________________________

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

📅 Original date posted:2015-03-24 📝 Original message:The ...

2023-06-07T15:32:12Z

In reply to nevent1q…38n7
_________________________

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

📅 Original date posted:2015-02-12 📝 Original message:On ...

2023-06-07T15:30:12Z

In reply to nevent1q…zxx2
_________________________

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

📅 Original date posted:2014-10-27 📝 Original ...

2023-06-07T15:26:58Z

In reply to nevent1q…d33u
_________________________

📅 Original date posted:2014-10-27
📝 Original message:Greetings Bitcoin Dev,

This is a proposal to improve the ability of bitcoin users to rely on
unconfirmed transactions. It can be adopted incrementally, with no hard
or soft fork required.

https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md

Your thoughtful feedback would be very much appreciated.

It is not yet implemented anywhere.

Cheers,
Tom Harding
CA, USA

📅 Original date posted:2014-05-03 📝 Original message:This ...

2023-06-07T15:20:56Z

In reply to nevent1q…6a87
_________________________

📅 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

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T15:19:49Z

In reply to nevent1q…uv9m
_________________________

📅 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

📅 Original date posted:2014-04-07 📝 Original message:On ...

2023-06-07T15:17:35Z

In reply to nevent1q…mfmy
_________________________

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