Peter Todd & Eric Lombrozo,
I also think communicating the UTXO would be increadibly useful. I just made a
writeup called "Synchronization Checkpoints" on github.
"https://github.com/bitcoin/bitcoin/issues/9885"; This idea also doesn't use
commitments.
But... Commitments would be a plus, becau
A Commitment-suitable UTXO set "Balances" file data structure
- Allows pruned nodes to satisfy SPV nodes
- Allows pruned nodes to trustlessly start synchronizing at a Balances file's
block height instead of the genesis block
- Allows all nodes in the network to verify their UTXO set's data integri
Potentially miners could create their own private communication
channel/listening port for submitting transactions that they would not relay to
other miners/the public node relay network. Users could then chose who they
want to relay to. Miners would be incentivized to not relay higher fee
tran
"Activation of segwit is defined by BIP9. After 15 Nov 2016 and before 15 Nov
2017 UTC, if in a full retarget cycle at least 1916 out of 2016 blocks is
signaling readiness, segwit will be activated in the retarget cycle after the
next one"
Just change BIP9 and the code to say "if in a full reta
Bandwidth limits:
Would be nice to specify global and per node up/down bandwidth limits.
Communicate limits to peers.
Monitor actual bandwidth with peers.
Adjust connections accordingly to attain bandwidth goals/limits.
With Lightning Network:
Prepay for bandwidth/data. Continue paying nodes who c
Martin:
Re: Miners not relaying unconfirmed txs... I was saying that this was a good
thing from your perspective in wanting to give users the choice on which miners
would get to confirm the tx. So then like we don't need to implement any kind
of special bloated transaction that is only mine-abl
Martin:
Re: Block Space Authority, or "authority": in general
An authority dictates policy.
Authority arises in 4 cases off the top of my head:
- Authority because entity threats violence/dominance
- Authority because entity's claim to property is respected to maintain
friendship/benefits of sp
I think at least the three following things have to be done before the block
size can be increased by any significant amount:
1. A network protocol defined UTXO snapshot format be defined, UTXO snapshots
being created automatically in a deterministic periodic and low-cost fashion.
Ability to syn
Peter R said: "On that topic, are there any existing proposals detailing a
canonical ordering of the UTXO set and a scheme to calculate the root hash?"
I created such here: "A Commitment-suitable UTXO set "Balances" file data
structure":
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2
TL;DR (In layman terms): Refund any excess fee amounts higher than the lowest
included fee in a block.
=== Proposed Hard Fork Change ===
LIFB: Lowest Included Fee/Byte
Change the fee policy to cause all fee/byte in a block to be reduced to the
lowest included fee/byte. Change transactions to s
> That would have the unfortunate effect of incentivizing miners to not
> completely fill blocks, because low fee marginal transactions could cost them
> money.
Look at the fee distribution. The vast majority of fee income comes from txs w/
fees near the LIFB. The blocks will be full... but I g
Sergio Demian Lerner: Please confirm that you understand that:
The current SegWit being proposed comes bundled with an effective 2MB block
size increase.
Are you proposing the remove this bundled policy change, and then have a
different BIP that increases the block size? Not quite clear if you
Peter Todd,
This MMR structure looks good to me. I really like how wallets keep their MMR
proof and txo index instead of requiring the entire network to maintain an
index on txids w/ plain old utxo snapshots.
Re: "only left or right child of inner node be a fully spent node"... that
sounds fin
gmaxwell told me that most nodes would keep a full copy of the top of the MMR
tree.
Here I am exploring how this could be policy-ized to solve two problems:
- MMR proofs change over time
- How to coordinate nodes to get them to keep different portions of the MMR, so
that everyone can prune most
Bitcoin nodes could also keep a spentness status list, where each bit in the
spentness status list corresponds to whether a txo in the MMR is spent. This
could make it so that disconnected wallets didn't have to guess the pruned
relative spentness status when it reconnects to the network... and
27;t have known about), there's probably bigger problems
going on. You might enjoy the topic on this mailing list on committed
bloom filters however, as this solves a similar issue without needing
an ever-growing list of hundreds of millions of spent outputs.
On 2017-04-02 06:04, praxeology_guy v
Bram Cohen,
In R&D: First its appropriate to explore all interesting ideas, and help each
other improve their ideas. Last, when there is a deadline that needs to be met,
we compare various options and decide on which to go with.
I'm on the First step still.
If you really want to push me to say
Bram Cohen,
My apologies, I guess I glossed over your "The TXO bitfield" because by subject
I thought it just had something to do with changing the txo's data structure.
Yes what you are proposing with "The TXO bitfield" is pretty much exactly the
same as the MMR data structure... EXCEPT yours
TL;DR: using spentness bits scales linearly... vs swapping digest leafs with
empties can scale with logorithmically increasing storage requirements. So if
you are using a 32 byte hash and spentness bits, you are pretty much limited to
only being able to prune 8 to 12 layers. This corresponds to
If this is the underlying reason why SegWit is being delayed... that is pretty
deplorable.
Probably too late now for bitcoin, but maybe it would be good to pre-mix the
block header bits around before it even enters the SHA256 hash. Not sure if
best to use a hardcoded map, or to make the map wit
Praxeological Analysis of PoW Policy Changes, Re: ASICBOOST
=
On the $100M profit claim
=
First I'd like to confirm Gregory Maxwell's assertion that covert use of
ASICBOOST could result in $100 million USD per year profits.
profit = reward - costs
> "... put a damper on advancing the development of more efficient mining
> hardware, which is once again desirable to users as it makes the transaction
> ordering more future proof."
Run on sentence sorry. I meant to say that development of more efficient/mature
mining hardware sooner is desir
Daniele Pinna,
Can you please not forget to supply us more details on the claims made
regarding the reverse engineering of the Asic chip?
gmaxwell told me that back even in S7 chips its possible to set the SHA256
midstate/IV instead of just resetting it to the standard SHA256 IV. This
essentia
shaolinfry,
Not sure if you noticed my comments on your earlier orphaning proposal... but
if you did you should already know that I really like this proposal...
particularly since orphaning valid old blocks is completely unnecessary.
I really like how you pulled out the "lockinontimeout" variab
Ryan Grant,
TLDR Unless I'm missing something, your claim that a misconfiguration would
result in a stop chain is wrong because BIP9 only works on soft forks.
Does BIP9 work with hard forks? Pretty sure it is only for soft forks. If you
want to make a hard fork, there is not much point in waiti
Jimmy Song,
Why would the actual end users of Bitcoin (the long term and short term owners
of bitcoins) who run fully verifying nodes want to change Bitcoin policy in
order to make their money more vulnerable to 51% attack?
If anything, we would be making policy changes to prevent the use of pa
ASICBOOST causes Bitcoin's PoW to become more memory/latency throttled instead
of raw computation throttled.
There is the equation:
Power Cost + Captial Rent + Labor ~= block reward + fees
Capital Rent is a barrier to entry, and hence in desiring a more distributed
system, we would like to mini
Eric Voskuil,
TL;DR: Electrical power is a general purpose consumer good vs PoW mining
equipment is a single purpose consumer good. Hence the mining equipment rent is
the barrier to entry, given if you invest in power generation capital you could
use the power for a different purpose.
Each uni
Gregory Maxwell,
Criticizing 148 without suggesting a specific alternative leaves the community
in disarray.
I know you are emphasizing patience. But at the same time, with your patience
we are allowing ourselves to get dicked for longer than necessary.
I think that core could easily develop c
Chris,
>Food for thought, why are we rejecting *all* blocks that do not signal segwit?
>Can't we just reject blocks that *do not* signal segwit, but *do* contain
>segwit transactions? It seems silly to me that if a miner mines a block with
>all pre segwit txs to reject that block. Am I missing
Natanael,
=== Metal Layers ===
One factor in chip cost other than transistor count is the number of layers
required to route all the interconnects in the desired die area constraint. The
need for fewer layers can result in less patent-able costs of layering
technology. Fewer layers are quicker
Below is a proposal for a wallet data structure that can enable a wallet to be
user friendly.
This is a proposed partial solution to "Pruned wallet support #9409":
https://github.com/bitcoin/bitcoin/issues/9409
It is envisioned to work with "Complete hybrid full block SPV mode #9483":
https://g
Luke,
I can't really advise on your proposed changes... but I have a couple new
suggestions:
=== Future Proof Commitment Extension Methodology ===
1. I'm not a fan of how ambiguous the direction is on handling future
commitment extensions. See
https://github.com/bitcoin/bips/blob/master/bip-01
Johnson Lau,
> not change the commitment structure as suggested by another post
Not sure if you realize my proposal is backwards compatible. We could also
merge the two arrays, which would be harder to compress, but a more simple
format. Below I gave an example of how this would be backwards co
Yann, Unfortunately sybil attacks
[[https://en.wikipedia.org/wiki/Sybil_attack#Description]](https://en.wikipedia.org/wiki/Sybil_attack#Description)
would prevent this from working... even if there was some way to prove that an
entity performed the transaction validation. Proving the relay of tr
35 matches
Mail list logo
