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
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
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
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":
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
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
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
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
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
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
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
> "... 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
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 -
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
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
f hundreds of millions of spent outputs.
On 2017-04-02 06:04, praxeology_guy via bitcoin-dev wrote:
> 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
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
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
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
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
> 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
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
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
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
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
"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
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
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
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,
29 matches
Mail list logo
