Re: [bitcoin-dev] tx max fee

[Tom Harding via bitcoin-dev]

On 5/11/23 04:02, vjudeu via bitcoin-dev wrote:
Every transaction paying "fee > sum" can be replaced by N transactions 
paying "fee <= sum", where the sum of all fees will be the same.



These N transactions will generally have a lower feerate than the 
original, and the lowest feerate of the N could be drastically lower 
than the original.


As a group, in the current environment (for example), they could take 
days or weeks longer to be mined than the original.



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Tom Harding via bitcoin-dev]

On 5/9/23 09:32, Erik Aronesty via bitcoin-dev wrote:

obviously it's easy enough to evade if every non-economic user simply  > keeps enough bitcoin around and sends it back to himself > > so 
maybeit's a useless idea? but maybe that's enough of a hassle to stop > 
people (it certainly breaks ordinals, since it can never be 1 sat)


Padding the change is not just a hassle, it requires holding extra BTC 
in a hot wallet, which has a cost.


Spenders could also get around the rule by paying miners off-network, 
but having to do so would be an appropriate penalty for broadcasting a 
non-economic transaction.



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Tom Harding via bitcoin-dev]

And prevent perfectly reasonable transfers of value



Such a transfer can only be reasonable when off-chain value is attached 
to the coins.  A rule like this is the embodiment of the philosophy that 
the Bitcoin network is for onchain-economic transactions.


Parties could get around the rule by paying miners off-network, and that 
would be an appropriate penalty for using non-onchain-economic transactions.




On 5/8/23 10:13, Michael Folkson via bitcoin-dev wrote:
> probably easier just to reject any transaction where the fee is 
higher than the sum of the outputs


And prevent perfectly reasonable transfers of value and attempted 
Lightning channel closes during fee spikes? If I *want*​ to close my 
Lightning channel during a protracted fee spike where I have to pay an 
onchain transaction fee greater than the amount I am receiving you 
want to stop me doing that? You are impinging on a valid use case as 
well as requiring a consensus rule change.


-- Michael Folkson
Email: michaelfolkson at protonmail.com 
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

--- Original Message ---
On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev 
 wrote:


probably easier just to reject any transaction where the fee is 
higher than the sum of the outputs




On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev 
 wrote:


Hi guys,

I think everyone on this list knows what has happened to the
Bitcoin mempool during the past 96 hours. Due to side projects
such as BRC-20 having such a high volume, real bitcoin
transactions are being priced out and that is what is causing the
massive congestion that has arguable not been seen since December
2017. I do not count the March 2021 congestion because that was
only with 1-5sat/vbyte.

Such justifiably worthless ("worthless" is not even my word -
that's how its creator described them[1]) tokens threaten the
smooth and normal use of the Bitcoin network as a peer-to-pear
digital currency, as it was intended to be used as.

If the volume does not die down over the next few weeks, should
we take an action? The bitcoin network is a triumvirate of
developers, miners, and users. Considering that miners are
largely the entities at fault for allowing the system to be
abused like this, the harmony of Bitcoin transactions is being
disrupted right now. Although this community has a strong history
of not putting its fingers into pies unless absolutely necessary
- an example being during the block size wars and Segwit - should
similar action be taken now, in the form of i) BIPs and/or ii)
commits into the Bitcoin Core codebase, to curtail the loophole
in BIP 342 (which defines the validation rules for Taproot
scripts) which has allowed these unintended consequences?

An alternative would be to enforce this "censorship" at the node
level and introduce a run-time option to instantly prune all
non-standard Taproot transactions. This will be easier to
implement, but won't hit the road until minimum next release.

I know that some people will have their criticisms about this,
absolutists/libertarians/maximum-freedom advocates, which is
fine, but we need to find a solution for this that fits
everyone's common ground. We indirectly allowed this to happen,
which previously wasn't possible before. So we also have a
responsibility to do something to ensure that this kind of
congestion can never happen again using Taproot.

-Ali

---

[1]:

https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[Tom Harding via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Tom Harding via bitcoin-dev]

On 7/20/19 10:46 AM, Matt Corallo via bitcoin-dev wrote:

(less trustful and privacy-violating) alternative
over the coming years.


The same paper that established the 'privacy-violating' conventional 
wisdom presented mitigations which have seen little exploration. 
https://eprint.iacr.org/2014/763.pdf


Meanwhile we have custodial LN, the L-BTC altcoin and, today, a massive 
push into infrastructure for fully custodial accounts.



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Using a storage engine without UTXO-index

[Tom Harding via bitcoin-dev]

On Apr 7, 2017 12:42, "Gregory Maxwell"  wrote:

On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev
 wrote:
> A network in which many nodes maintain a transaction index also enables a
> class of light node applications that ask peers to prove existence and
> spentness of TXO's.

Only with the additional commitment structure such as those proposed
by Peter Todd in his stxo/txo commitment designs, e.g.
https://petertodd.org/2016/delayed-txo-commitments


Light nodes are improved by detecting invalid transactions, even before
they are mined.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Using a storage engine without UTXO-index

[Tom Harding via bitcoin-dev]

On Apr 6, 2017 6:31 PM, "Tomas via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:


Bitcrust just uses a *transaction-index*, where outputs can be looked up
regardless of being spent.



A network in which many nodes maintain a transaction index also enables a
class of light node applications that ask peers to prove existence and
spentness of TXO's.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] High fees / centralization

[Tom Harding via bitcoin-dev]

On 3/30/2017 9:14 AM, David Vorick wrote:
> On Mar 30, 2017 12:04 PM, "Tom Harding via bitcoin-dev"
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> Raystonn, 
>
> Your logic is very hard to dispute. An important special case is
> small miners.
>
> Small miners use pools exactly because they want smaller, more
> frequent payments.
>
> Rising fees force them to take payments less frequently, and will
> only tend to make more of them give up.
>
> With fees rising superlinearly, this centralizing effect is much
> stronger than the oft-cited worry of small miners joining large
> pools to decrease orphan rates.
>
>
> Miners get paid on average once every ten minutes. The size of fees
> and the number of fee transactions does not change the payout rate.
>
> Further, we are very far from the point (in my appraisal) where fees
> are high enough to block home users from using the network.
>
> Bitcoin has many high-value use cases such as savings. We should not
> throw away the core innovation of monetary sovereignty in pursuit of
> supporting 0.1% of the world's daily transactions.
>

Owners of small mining rigs get paid by pools, generally using regular
transactions that pay regular fees (p2pool is an exception that pays
directly from coinbase).  The point is the unintended consequences are
directly at odds with one of the justifications offered for small blocks
- miner centralization.

This is a special case.  Raystonn's general point was that high fees
will lead to fewer economic actors overall, and therefore fewer full nodes.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] High fees / centralization

[Tom Harding via bitcoin-dev]

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@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@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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Tom Harding via bitcoin-dev]

On 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev
>  > wrote:
>
> With a tightening of the rule set, a hash power minority that has
> not upgraded will not produce a minority branch; instead they will
> simply have any invalid blocks they produce orphaned, serving as a
> wake-up call to upgrade.
>
>
> False. With bip9-based soft-fork-based activation of segwit, miner
> blocks will not be orphaned unless they are intentionally
> segwit-invalid (which they currently are not). If you have told miners
> otherwise, let me know.
>

A reasonable miner automatically checks every transaction seen, to see
if it might be valid with his own outputs substituted.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

[Tom Harding via bitcoin-dev]

On 3/15/2017 5:25 PM, b...@cock.lu wrote:
> compact fraud proofs in Bitcoin aren't possible
> In the white paper SPV clients have the same security as fully
> validating nodes

In addition to not existing, if compact fraud proofs did exist, trying
to ensure they are seen by SPV clients has the same problems as BIP37.


> in the implementation of BIP37 they have absolutely no security except
> the vague hope that they are not being lied to, and that the chain
> with the most work they are seeing is actually valid, both are very
> weak assumptions.

Since real money is involved, the near total absence of documented fraud
along these lines belies the strong language.


> During the validationless mining failure around the BIP66 activation
> miners produced 6 invalid blocks in a chain, and many more invalid
> blocks in isolated bursts for a period lasting several months. Due to
> the instability of the network you are completely unreasonable to
> accept anything except multiple confirmations

This affected all users, not just SPV.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

[Tom Harding via bitcoin-dev]

Agreed.

In contrast, BIP37 as used today is totally decentralized, and can me 
made much more secure, private, and scalable -- without giving up the 
utility of unconfirmed transactions.


Please don't read into this statement a belief that all the coffees 
should go on the chain, or that the security or privacy of BIP37 compare 
favorably to any other particular thing.


https://docs.google.com/presentation/d/13MzUo2iIH9JBW29TgtPMoaMXxeEdanWDfi6SlfO-LlA



On 1/5/2017 6:04 PM, bfd--- via bitcoin-dev wrote:

You might as well replace Bitcoin with a system where these parties
sign transactions and skip mining altogether, it would have the same
properties and be significantly more effient.


On 2017-01-04 23:06, Chris Priest wrote:

On 1/3/17, Jonas Schnelli via bitcoin-dev
 wrote:


There are plenty, more sane options. If you can't run your own 
full-node

as a merchant (trivial), maybe co-use a wallet-service with centralized
verification (maybe use two of them), I guess Copay would be one of
those wallets (as an example). Use them in watch-only mode.


The best way is to connect to the mempool of each miner and check to
see if they have your txid in their mempool.

https://www.antpool.com/api/is_in_mempool?txid=334847bb...
https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
https://bw.com/api/is_in_mempool?txid=334847bb...
https://bitfury.com/api/is_in_mempool?txid=334847bb...
https://btcc.com/api/is_in_mempool?txid=334847bb...

If each of these services return "True", and you know those services
so not engage in RBF, then you can assume with great confidence that
your transaction will be in the next block, or in a block very soon.
If any one of those services return "False", then you must assume that
it is possible that there is a double spend floating around, and that
you should wait to see if that tx gets confirmed. The problem is that
not every pool runs such a service to check the contents of their
mempool...

This is an example of mining centralization increasing the security of
zero confirm. If more people mined, this method will not work as well
because it would require you to call the API of hundreds of different
potential block creators.




___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Three hardfork-related BIPs

[Tom Harding via bitcoin-dev]

On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote:
> a world of nodes in large datacenters is a world where it's very easy
> to force the few Bitcoin nodes remaining to follow AML/KYC rules

If that's true, why haven't we already seen AML/KYC required of mining
pools?  That would be comparatively trivial.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

[Tom Harding via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

[Tom Harding via bitcoin-dev]

Even more to the point, new post- fork coins are fork-specific.  The 
longer both forks persist, the more transactions become unavoidably 
fork-specific through the mixing in of these coins.  Any attempt to 
maximize replay will become less effective with time.


The rationality of actors in this situation essentially defines the 
limited solution that is possible.  Upgraded software can create 
transactions guaranteed not to execute to one fork or the other, or that 
is not prevented from execution on either fork.  I see no downside to 
this, and the advantage is that markets can be much less chaotic.  In 
fact exchanges will be much better off if they require that post-fork 
trading, deposits and withdrawals are exclusively chain-specific, which 
will also result in well determined prices for the two currencies.


None of this precludes the possibility of further forks on either side, 
and the difficulty consideration alone suggests a likely counter-fork by 
(part of) the existing network.



On 1/26/2017 1:20 AM, Johnson Lau via bitcoin-dev wrote:

Not to mention that mining is a random process, and the hashing power is going 
up and down.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)

[Tom Harding via bitcoin-dev]

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
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Interpreting nTime for the purpose of Bitcoin-attested timestamps

[Tom Harding via bitcoin-dev]

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.




signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Interpreting nTime for the purpose of Bitcoin-attested timestamps

[Tom Harding via bitcoin-dev]

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New BIP: Dealing with dummy stack element malleability

[Tom Harding via bitcoin-dev]

On 9/1/2016 9:40 PM, Johnson Lau via bitcoin-dev wrote:
> This BIP will be deployed by "version bits" BIP9 using the same parameters 
> for BIP141 and BIP143, with the name "segwit" and using bit 1.
>

This fix has value outside of segwit.  Why bundle the two together? 
Shouldn't miners have to opportunity to vote on them independently?


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposal: Hard fork opt-out bits

[Tom Harding via bitcoin-dev]

Your thoughts are sought on this simple proposal to allow transaction
authors to restrict execution to fewer than all blockchain forks where
the transaction would otherwise be valid.


Proposal

Node implementations select a bit from among the upper 8 bits of the
transaction version space to enforce as a hard fork opt-out bit.

To specify that a transaction NOT be mined by nodes that enforce a
particular bit, authors set that bit in the transaction version.
Opt-out is enforced by consensus among nodes enforcing each bit.

An implementation will relay, process and mine transactions that opt out
of other blockchain forks; just not those that opt out of its own fork.


Notes

Example: Via soft fork, all implementations may begin enforcing hard
fork opt-out bit 30.  Post soft fork, setting this bit would make a
transaction invalid, unless a fork emerges that has stopped enforcing
bit 30.

Example: BIP109 implementations may stop enforcing bit 30 and begin
enforcing bit 28 when the BIP109 hard fork is activated for a chain they
are tracking.

Enforcing more than one hard fork opt-out bit would imply that an
implementation is actively participating in building more than one
blockchain fork, and therefore providing a way to opt out of each.




signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Tom Harding via bitcoin-dev]

On May 11, 2016 7:33 PM, "Peter Todd"  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Tom Harding via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[Tom Harding via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

[Tom Harding via bitcoin-dev]

On Nov 17, 2015 5:54 AM, "Tamas Blummer via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Isolating storage from the rest of consensus code is technically
desirable, but implementations using different storage will be unlikely
bug-for-bug compatible,
> hence able to split the network.

The problem with unknown bugs is you don't know how serious they are.  A
serious bug could itself be devastating.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Tom Harding via bitcoin-dev]

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?


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

[Tom Harding via bitcoin-dev]

On 9/29/2015 7:05 PM, Rusty Russell wrote:

Tom Harding via bitcoin-dev 
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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fill-or-kill transaction

[Tom Harding via bitcoin-dev]

On 9/17/2015 8:27 PM, jl2012 via bitcoin-dev wrote:
> However, requiring 100 block maturity will unfortunately make the
> system much less appealing since the recipient may not like it.

The maturity requirement can be dropped if the expiration height is more
that 100 blocks after inclusion height.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

[Tom Harding via bitcoin-dev]

Well let's see.  All else being equal, if everybody uses difficulty to 
buy big blocks during retarget interval 0, blocks and therefore money 
issuance is slower during that interval.  Then, the retargeting causes 
it to be faster during interval 1.  Subsidy got shifted from the 
calendar period corresponding to interval 0, to interval 1.


If you change the reward, you can lower the time-frame of the effect to 
the order of a single block interval, but there is still an effect.


These schemes do not avoid the need for a hard cap, and there are new 
rules for the size of the allowed adjustment, in addition to the main 
rule relating difficulty to block size.  So it seems they generally have 
more complexity than the other blocksize schemes being considered.



On 9/9/2015 11:59 AM, Warren Togami Jr. via bitcoin-dev wrote:
Does it really change the schedule when the next difficulty retarget 
readjusts to an average of 10 minutes again?


On Tue, Sep 8, 2015 at 8:27 PM, Tom Harding via bitcoin-dev 
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:



There is another concern regarding "flexcap" that was not discussed.

A change to difficulty in response to anything BUT observed block
production rate unavoidably changes the money supply schedule, unless
you also change the reward, and in that case you've still changed the
timing even if not the average rate.



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

[Tom Harding via bitcoin-dev]

There is another concern regarding "flexcap" that was not discussed.

A change to difficulty in response to anything BUT observed block
production rate unavoidably changes the money supply schedule, unless
you also change the reward, and in that case you've still changed the
timing even if not the average rate.


On 8/14/2015 8:14 AM, Jakob Rönnbäck via bitcoin-dev wrote:
> Ah, there we go. I should have dug deeper into the mailing list
>
> Thanks
>
> /jakob
>
>> 14 aug 2015 kl. 17:03 skrev Adam Back :
>>
>> There is a proposal that relates to this, see the flexcap proposal by
>> Greg Maxwell & Mark Friedenbach, it was discussed on the list back in
>> May:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html
>>
>> and 
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.html
>>
>> Adam
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] block size - pay with difficulty

[Tom Harding via bitcoin-dev]

On 9/2/2015 9:05 PM, Jeff Garzik via bitcoin-dev wrote:
Schemes proposing to pay with difficulty / hashpower to change block 
size should be avoided.  The miners incentive has always been fairly 
straightforward - it is rational to deploy new hashpower as soon as 
you can get it online.  Introducing the concepts of (a) requiring 
out-of-band collusion to change block size and/or (b) requiring miners 
to have idle hashpower on hand to change block size are both 
unrealistic and potentially corrosive.  That potentially makes the 
block size - and therefore fee market - too close, too sensitive to 
the wild vagaries of the mining chip market.


Pay-to-future-miner has neutral, forward looking incentives worth 
researching.




Another market dependency is even more direct.

Blocksize that can be bought with either difficulty or bitcoin has 
incentives whose strength (though not direction) is subject to the 
exchange rate.  Hence those incentives are subject to the whims of fiat 
holders, who can push the exchange rate around.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unlimited Max Blocksize (reprise)

[Tom Harding via bitcoin-dev]

On 8/30/2015 9:54 AM, Peter R wrote:
> Like Daniele pointed out, the greedy algorithm assumed in the paper is
> asymptotically optimal in such a case.

I'm convinced.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

[Tom Harding via bitcoin-dev]

On 8/21/2015 3:06 PM, Peter Todd via bitcoin-dev wrote:
> On Fri, Aug 21, 2015 at 05:55:58PM +, 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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Tom Harding via bitcoin-dev]

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Tom Harding via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Tom Harding via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Tom Harding via bitcoin-dev]

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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

[Tom Harding via bitcoin-dev]

Nobody mentioned exchange rates.  Those matter to miners too.

Does it make sense for George Soros and every other rich person /
institution to have the power to move difficulty, even pin it to min or
max, just by buying or selling piles of BTC to swing the exchange rate?


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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Tom Harding via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Tom Harding via bitcoin-dev]

On Aug 9, 2015 11:54 AM, "Mark Friedenbach"  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?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] What Lightning Is

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation

[Tom Harding via bitcoin-dev]

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
009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99, 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?

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size following technological growth

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Superluminal communication and the consensus block size limit

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

[Tom Harding via bitcoin-dev]

On 8/5/2015 3:44 PM, Dave Hudson via bitcoin-dev wrote:
I do suspect that if we were to model this more accurately we might be 
able to infer the "typical" propagation characteristics by measuring 
the deviation from the expected distribution. 


The paper models propagation using a single time value that is a 
function of block size.  Modeling the propagation distribution (which is 
totally separate from the poisson model of block production) would add a 
lot of complexity and my guess is the outcome would be little changed.




On 5 Aug 2015, at 15:15, Peter R  wrote:
Although a miner may not orphan his own block, by building on his own block he 
may now orphan two blocks in a row.  At some point, his solution or solutions 
must be communicated to his peers.


Why complicate the analysis by assuming that a miner who finds two 
blocks sequentially does not publish the first, or that other miners 
would orphan miner's first block unless both were very quick?  In 
general you don't consider anything beyond 1 block in the future, which 
seems fine.




I suspect this may well change some of the conclusions as larger block makers 
will definitely be able to create larger blocks than their smaller counterparts.

It will be interesting to see.  I suspect that the main result that "a healthy fee 
market exists" will still hold (assuming of course that a single miner with >50% of 
the hash power isn't acting maliciously).  Whether miners with larger value of h/H have a 
profit advantage, I'm not sure (but that was outside the scope of the paper anyways).


Correcting for non-orphaning of one's own blocks could be as simple as 
adding a factor (1 - h/H) to equation 4, which it appears would leave 
hashpower as an independent variable in the results.  But at worst, the 
discussion can be considered to apply directly only to low-hashpower 
miners right now.


Overall, the paper does not predict big changes to per/kb fees or spam 
costs for the kinds of block sizes being discussed for the immediate 
future (8MB).  But it does conclude that these fees will rise, not fall, 
with bigger blocks.


Also it is welcome that this paper actually mentions the bitcoin 
exchange rate as a factor in relation to block size (it points out that 
a spam attack is much more expensive in fiat terms today than it was 
years ago).


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal

[Tom Harding via bitcoin-dev]

On 8/1/2015 1:45 PM, Pieter Wuille via bitcoin-dev wrote:
>
> Regarding "reasonable", I have a theory. What if we would have had 8
> MB blocks from the start? My guess is that some more people would have
> decided to run their high-transaction-rate use cases on chain, that
> we'd regularly see 4-6 MB blocks,

You've proposed scaling the cap based on technology growth.  There's
still a cap to stop bad things from happening.

Once that is done, why worry so much about whether the uses are
efficient?  Let people work in the space created.  Let them figure out
how to make good things happen in the application space.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Another block size limit solution - dynamic block size limit.

[Tom Harding via bitcoin-dev]

On 7/30/2015 8:03 AM, Максим Божко via bitcoin-dev wrote:
> I propose to implement dynamic block size limit. Its short summary is
> here in doc:
>
> https://docs.google.com/document/d/1ixt0loN7LOF6M_2HXvV0D-3ZCayvcfj0rzVm-h-6ONg/edit
>
>

A dynamic limit based on recent block sizes has been discussed, but with
all the traffic on the list, finding the discussions is bound to be
difficult.

I think the main reason this kind of thing hasn't gotten traction is
that it would allow miners alone to chart the course of block sizes. 
Miners are likely to have more powerful equipment than everybody else,
and with the current network design, that could reduce the population of
nodes able to keep up, with no limit in the loss of decentralization.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader

[Tom Harding via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader

[Tom Harding via bitcoin-dev]

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
>> > <mailto:bitcoin-dev@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).
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Tom Harding via bitcoin-dev]

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?

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Tom Harding via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Tom Harding via bitcoin-dev]

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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Tom Harding via bitcoin-dev]

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



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Tom Harding via bitcoin-dev]

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?


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mempool "Expected Byte Stay" policy

[Tom Harding via bitcoin-dev]

On 7/16/2015 2:38 AM, Thomas Zander via bitcoin-dev wrote:

On Wednesday 15. July 2015 16.15.24 Tom Harding via bitcoin-dev wrote:

On 7/15/2015 12:18 PM, Thomas Zander via bitcoin-dev wrote:

On Tuesday 14. July 2015 17.24.23 Tom Harding via bitcoin-dev wrote:

Rule 2: A transaction and its dependents are evicted on its 2-hour
anniversary, whether space is required or not

Instead of 2 hours, why not a number of blocks?

So users/wallets can know when they should rebroadcast and consider
increasing the fee.


Using 12 blocks, there is a 5% chance he has to wait 3 hours.*

Using 120 minutes, there is only a .23% chance that fewer than 4 blocks
have occurred.**

Using the good old saying; results in the past are no indication of the
future.
I see a logic error in your thinking.

Your assumption that time is a better indicator is false. Naturally time
itself is universal, but blocks are known by wallets too. Its just as good.

This assumption of yours leans heavily on block mining times, and that is
not guaranteed in the future.  Imagine one day half the miners dropping and
blocks take much longer for a week or so.  Your assumptions just broke the
mempool.



It's not a question of right vs. wrong.  Either method has consequences 
for user expectations and behavior.


With fixed-block mempool expiration, the expiration time is variable.  
User can get an alert, but at an unpredictable time.


With fixed-timeout, the likelihood of expiration is more variable 
(expiration occurrence is unpredictable regardless), but any expiration 
will occur at the timeout.



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mempool "Expected Byte Stay" policy

[Tom Harding via bitcoin-dev]

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.99
30.0.29
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.798748
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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions

[Tom Harding via bitcoin-dev]

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. 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Mempool "Expected Byte Stay" policy

[Tom Harding via bitcoin-dev]

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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev