On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote:
> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment
> qr
> codes don't cryptographically commit to the identity of the merchant,
> which
> means a MITM attacker can redirect the payment if they can obtain a S
I would like to propose an efficient UTXO commitment scheme.
A UTXO commitment can be useful for:
1. Fast syncing a full node, by downloading the UTXO-set
2. Proofing (non) existence of a UTXO..
Various schemes have been proposed:
* Merkle/radix trees and variants; all of which have the problem
On Fri, Jun 9, 2017, at 05:50, Olaoluwa Osuntokun wrote:
> Tomas wrote:
> > I don't completely understand the benefit of making the outpoints and
> > pubkey hashes (weakly) verifiable. These only serve as notifications and
> > therefore do not seem to introduce an attack vector.
>
> Not sure what
On Thu, Jun 1, 2017, at 21:01, Olaoluwa Osuntokun via bitcoin-dev wrote:> Hi
y'all,
>
> Alex Akselrod and I would like to propose a new light client BIP for
> consideration:
>* https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki>
>
Very interesting.
I would like to
hat the user agent signalling isn't very important, and I think
that most of us aware that you cannot rely on counting them.
>
> On May 23, 2017 8:03 AM, "Tomas via bitcoin-dev" d...@lists.linuxfoundation.org> wrote:>> I have a proposal that would allow
> each us
I have a proposal that would allow each user to optionally configure the
maximum block weight at a support threshold.
It recognizes that there is no need for off chain bickering, by
providing a mechanism that lets each users freely choose their own
parameters while still maintaining full coordinat
Sorry, I wasn't aware. This is indeed the same proposal.
On Fri, May 5, 2017, at 15:01, Bryan Bishop wrote:
> On Fri, May 5, 2017 at 6:24 AM, Tomas via bitcoin-dev d...@lists.linuxfoundation.org> wrote:>> I propose a method to mark blocks to
> indicate that they were
&g
I propose a method to mark blocks to indicate that they were generated
without verifying the previous block. This can be done by using a bit of
the version field.
This would counter the reduction of security caused by what is known as
"SPV-mining".
The BIP is here:
https://github.com/tomasvdw/bip
I would like some feedback on the idea to use a node type a bit heavier
then SPV (dubbed FSPV) to solve Fraud Proofs.
An FSPV node not only downloads block headers, but also the "spend-tree
blocks", consisting of all TXIDs and all previous output indices and
TXIDs. The latter can be compacted usin
The ones that *could* pay non-mining full nodes are miners/pools, by
outsourcing transaction selection using a different PoW. By doing so
they could buy proof-of-uncensored-selection and proof-of-goodwill for a
small fee.
We would allow full nodes to generate and broadcast a template
block which:
On Tue, Apr 11, 2017, at 11:41, Eric Voskuil wrote:
> It's not the headers/tx-hashes of the blocks that I'm referring to, it
> is the confirmation and spend information relative to all txs and all
> outputs for each branch. This reverse navigation (i.e. utxo
> information) is essential, must be p
On Tue, Apr 11, 2017, at 03:44, Eric Voskuil wrote:
> As I understand it you would split tx inputs and outputs and send them
> independently, and that you intend this to be a P2P network
> optimization - not a consensus rule change. So my comments are based
> on those inferences. If we are talki
Thank you for your elaborate response Eric,
On Sun, Apr 9, 2017, at 00:37, Eric Voskuil wrote:
> My point was that "Using a storage engine without UTXO-index" has been
> done, and may be a useful reference, not that implementation details
> are the same.
I haven't dived into libbitcoin V2/V3 enou
On Sun, Apr 9, 2017, at 00:12, Gregory Maxwell wrote:
> In Bitcoin Core the software _explicitly_ and intentionally does not
> exploit mempool pre-validation because doing that very easily leads to
> hard to detect consensus faults and makes all mempool code consensus
> critical when it otherwise
> Please no conspiracy theory like stepping on someone’s toes. I believe
> it’s always nice to challenge the established model. However, as I’m
> trying to make some hardfork design, I intend to have a stricter UTXO
> growth limit. As you said "protocol addressing the UTXO growth, might not
> be w
> I don’t fully understand your storage engine. So the following deduction
> is just based on common sense.
>
> a) It is possible to make unlimited number of 1-in-100-out txs
>
> b) The maximum number of 100-in-1-out txs is limited by the number of
> previous 1-in-100-out txs
>
> c) Since bitcr
On Sat, Apr 8, 2017, at 20:27, Tom Harding via bitcoin-dev wrote:
>
>
> 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
>> > cl
On Sat, Apr 8, 2017, at 02:44, Gregory Maxwell wrote:
> As you note that the output costs still bound the resource
> requirements.
Resource cost is not just a measure of storage requirement; data that
needs to be accessed during peak load induce more cost then data only
used during base load or o
Hi Eric,
On Fri, Apr 7, 2017, at 21:55, Eric Voskuil via bitcoin-dev wrote:
> Optimization for lower memory platforms then becomes a process of
> reducing the need for paging. This is the purpose of a cache. The seam
> between disk and memory can be filled quite nicely by a small amount
> of cache
Answering both,
On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev
wrote:
>>
>> I'm still lost on this-- AFAICT your proposals long term resource
>> requirements are directly proportional to the amount of
>> unspent output
>> data, which grows over time at some fraction of the
ed to also see comparisons with 0.14 which has some
> improvements for script validation with more cores.
>
> On Fri, Apr 7, 2017 at 4:47 AM, Tomas via bitcoin-dev d...@lists.linuxfoundation.org> wrote:
>> Thank you Marcos,
>>
>> Though written in Rust, bitcrus
Thank you Marcos,
Though written in Rust, bitcrust-db is definitely usable as pluggable
module as its interface will be roughly some queries, add_tx and
add_block with blobs and flags. (Bitcrust internally uses a
deserialize-only model, keeping references to the blobs with the parsed
data).
How
On Fri, Apr 7, 2017, at 03:09, Gregory Maxwell wrote:
>
> How do you deal with validity rules changing based on block height?
I expected that one :). Just like the 100 blocks coinbase rule, changes
by softforks need to be added as metadata to the transaction-index, but
this is not yet in place.
On Fri, Apr 7, 2017, at 02:32, Gregory Maxwell wrote:
> Perhaps a simple question would help:
>
> What is the minimal amount of space your system requires to take a new
> block received from the P2P network and verifying that all its spends
> were valid spends of existing coins unspent coins to
SIGNED MESSAGE-
> Hash: SHA256
>
> On 04/06/2017 03:12 PM, Tomas via bitcoin-dev wrote:
>
> Hi Tomas,
>
> > I have been working on a bitcoin implementation that uses a
> > different approach to indexing for verifying the order of
> > transactions. Instea
I have been working on a bitcoin implementation that uses a different
approach to indexing for verifying the order of transactions. Instead of
using an index of unspent outputs, double spends are verified by using a
spend-tree where spends are scanned against spent outputs instead of
unspent output
> The specification itself looks like an inefficient and bloaty reinvention
> of
> version bits.
The actual assignment of version bits isn't clear from the
specification. Are you saying that any implementation that wants to
propose a change is encouraged to pick a free version bit and use it?
F
In an attempt to reduce developer centralization, and to reduce the risk
of forks introduced by implementation other than bitcoin-core, I have
drafted a BIP to support changes to the protocol from different
implementations.
The BIP can be found at:
https://github.com/tomasvdw/bips/blob/master/dece
28 matches
Mail list logo