Does this affect the security model WRT chain reorganizations? In the
classic doublespend attack, an attacker can only redirect UTXOs that they
spent. With this proposal, if I understand it correctly, an attacker could
redirect all funds that have "matured" (revealed the previous preimage in
the
Any chance of a quick tldr to pique our interest by explaining how exactly
this works "and the protocol will reach consensus on whether the state
reported by the oracle is correct" in presumably a permissionless,
anonymous, decentralized fashion, and what caveats there are?
Regards,
Andrew
On
Do you have any write up that presents a fully detailed architecture,
including mechanisms like bitcoin scripts, transactions and L2 protocols,
and then derives claims from that base?
On Tue, May 23, 2023, 5:59 AM Burak Keceli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
Consider that a miner can also produce transactions. So every miner would
produce spam tx to fill their bricks at the minimum allowed difficulty to
reap the brick coinbase reward.
You might quickly respond with a modification that changes or eliminates
the brick coinbase reward, but perhaps that
Since discussion around allowing unknown messages or not allowing them
seems contentious, I'd like to offer up another possibility: create a
single new message, XVERSION, (and bump the protocol rev) which is a
key-value array of arbitrary data. Any protocol extension can then choose
a new key
I can understand how Bram's transaction double sha256 hashed UTXO set
patricia trie allows a client to quickly validate inputs because the inputs
of a transaction are specified in the same manner. So to verify that an
input is unspent the client simply traverses the patricia trie.
It also makes
Can an insertion ordered MMR allow an efficient nonexistence proof?
On Feb 23, 2017 1:20 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Feb 23, 2017 at 09:53:58AM -0800, Chris Priest wrote:
> > On 2/22/17, Peter Todd via bitcoin-dev
> >
of
Bitcoin history.
Andrew
On Tue, Mar 8, 2016 at 12:19 PM, Luke Dashjr <l...@dashjr.org> wrote:
> On Tuesday, March 08, 2016 2:35:21 AM G. Andrew Stone via bitcoin-dev
> wrote:
> > Not an unreasonable request, however while I personally respect the many
> > great accomplishments
The Bitcoin Unlimited client needs a services bit to indicate that the node
is capable of communicating thin blocks. We propose to use bit 4 as AFAIK
bit 3 is already earmarked for Segregated Witness.
Andrew
___
bitcoin-dev mailing list
