Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1

[G. Andrew Stone via bitcoin-dev]

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 hash chain) to themselves.  The # blocks to maturity in your proposal
becomes the classic "embargo period" and every coin spent by anyone between
the fork point and the maturity depth is available to the attacker to
doublespend?

On Thu, Dec 21, 2023, 8:05 PM Yuri S VB via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> You are right to point out that my proposal was lacking defense against
> rainbow-table, because there is a simple solution for it:
> To take nonces from recent blocks, say, T0-6, ..., T0-13, for salting
> LSIG, and ECCPUB to salt LAMPPUB. Salts don't need to be secret, only
> unknown by the builder of rainbow table while they made it, which is the
> case, since here we have 8*32=256 bits for LSIG, and the entropy of ECCPUB
> in the second.
>
> With rainbow table out of our way, there is only brute-force analysis to
> mind. Honestly, Guess I should find a less 'outrageously generous' upper
> bound for adversary's model, than just assume they have a magic wand to
> convert SHA256 ASICS into CPU with the same hashrate for memory- and
> serial-work-hard hashes (therefore giving away hash hardness). That's
> because with such 'magic wand' many mining pools would, not only be capable
> of cracking 2^48 hashes far within the protocol's prescribed 48 hours, but
> also 2^64 within a block time, which would invalidate a lot of what is
> still in use today.
>
> Please, allow me a few days to think that through.
>
> YSVB
>
> Sent with Proton Mail secure email.
>
> On Wednesday, December 20th, 2023 at 10:33 PM, Nagaev Boris <
> bnag...@gmail.com> wrote:
>
>
> > On Tue, Dec 19, 2023 at 6:22 PM yuri...@pm.me wrote:
> >
> > > Thank you for putting yourself through the working of carefully
> analyzing my proposition, Boris!
> > >
> > > 1) My demonstration concludes 12 bytes is still a very conservative
> figure for the hashes. I'm not sure where did you get the 14 bytes figure.
> This is 2*(14-12) = 4 bytes less.
> >
> >
> > I agree. It should have been 12.
> >
> > > 2) Thank you for pointing out that ECCPUB is necessary. That's exactly
> right and I failed to realize that. To lessen the exposure, and the risk of
> miner of LSIG, it can be left to be broadcast together with LAMPPRI.
> > >
> > > 3) I avail to advocate for economizing down the fingerprint to just
> 128 bits for the weakest-link-principle, since 128 bits is a nearly
> ubiquitous standard, employed even by the majority of seeds. Not an
> argument against plain Schnorr, because Schnorr keys could use it too, but,
> compared with current implementations, we have that would be 20-16=4 bytes
> less.
> >
> >
> > I think that the digest size for hash should be 2x key size for
> > symmetric encryption. To find a collision (= break) for a hash
> > function with digest size 128 bits one needs to calculate ~ 2^64
> > hashes because of the birthday paradox.
> >
> > > 4) [Again, argument against plain, because it cuts for both sides:] To
> economize even further, there is also the entropy-derivation cost trade-off
> of N times costlier derivation for log2(N) less bits. If applied to the
> Address, we could shave away another byte.
> > >
> > > 5) T0 is just the block height of burying of LSIG doesn't need to be
> buried. T2 can perfectly be hard-coded to always be the block equivalent of
> T0 + 48 hours (a reasonable spam to prevent innocent defaulting on
> commitment due to network unavailability). T1 is any value such as T0 < T1
> < T2, (typically T1 <= T0+6) of user's choosing, to compromise between, on
> one hand, the convenience of unfreezing UTXO and having TX mining completed
> ASAP and, on the other, avoiding the risk of blockchain forking causing
> LAMPPRI to be accidentally leaked in the same block height as LSIG, which
> allows for signatures to be forged. So this is 16 bytes less.
> > >
> > > Miners would keep record of unconfirmed BL's, because of the reward of
> mining either possible outcome of it (successful transaction or execution
> of commitment). Everything is paid for.
> > >
> > > So, unless I'm forgetting something else, all other variables kept
> equal, we have 20 bytes lighter than Schnorr; and up to 25 bytes less the
> current implementation of Schnorr, if items 3 and 4 are implemented too.
> Already we have a reduction of between 21% and 26%, while, so far, nobody
> in the mailing list has disputed how 'outrageously' conservative the 12
> bytes figure is.
> >
> >
> > 26% reduction of block space utilization would be great, but the price
> > of relying on 12 bytes hashes (only need 2^48 hashes to find a
> > collision) is too much for that, IMHO.
> >
> > Another consideration is about 12 byte hashes. Let's try to figure out

Re: [bitcoin-dev] Trustless 2-way-peg without softfork

[G. Andrew Stone via bitcoin-dev]

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 Sun, Sep 10, 2023 at 4:06 PM Dr Maxim Orlovsky via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> Several years ago my team from Pandora Project working on
> censorship-resistant distributed machine learning proposed Prometheus: a
> protocol for high-load computing on top of Bitcoin. The protocol operates
> as a multi-party game setting where an oracle ("worker") is provided with
> an arbitrary computationally complex task (any Turing-complete computing,
> machine learning training or inference etc) and the network is able to
> reach a consensus on whether a result reported by the worker is true. The
> consensus is reached via optional rounds of verification and arbitrage. The
> protocol is cryptoeconomically-safe, i.e. has a proven Nash equilibrium.
> The protocol was later transferred to LNP/BP Standards Association (
> https://lnp-bp.org) and was kept in a backlog of what can be done in a
> future as a layer on top of Bitcoin.
>
> I'd like to emphasize that Prometheus works on Bitcoin, requires just
> several Bitcoin tx per task, and _doesn't require any soft fork_. All
> economic setting is done with Bitcoin as a means of payment, and using
> existing Bitcoin script capabilities.
>
> Link to the paper describing the protocol: <
> https://github.com/Prometheus-WG/prometheus-spec/blob/master/prometheus.pdf
> >
>
> Only today I have realized that Prometheus protocol can be used to build
> cryptoeconomically-safe (i.e. trustless) 2-way-peg on the Bitcoin
> blockchain without any soft-forks: a "worker" in such a case acts as an
> oracle for some extra-bitcoin system (sidechain, client-side-validated
> protocol, zk rollup etc) validating it, and the protocol will reach
> consensus on whether the state reported by the oracle is correct.
>
> In other words, this is an alternative to BIP-300 and other similar
> soft-forks having the only purpose of doing 2-way pegs. It also enables the
> two-way trustless transfer of Bitcoins between Bitcoin blockchain, RGB and,
> in a future, potential new layer 1 called "prime" (to learn more about
> prime you can check my Baltic Honeybadger talk <
> https://www.youtube.com/live/V3vvybsc1A4?feature=shared=23631>).
>
>
> Kind regards,
> Dr Maxim Orlovsky
> Twitter: @dr_orlovsky
> Nostr: npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym
>
> LNP/BP Standards Association
> Twitter: @lnp_bp
>
> ___
> 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] Ark: An Alternative Privacy-preserving Second Layer Solution

[G. Andrew Stone via bitcoin-dev]

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:

> > As the access to Lightning is also by the (same?) ASP, it seems to me
> that the ASP will simply fail to forward the payment on the broader
> Lightning network after it has replaced the in-mempool transaction,
> preventing recipients from actually being able to rely on any received
> funds existing until the next pool transaction is confirmed.
>
> Yes, that's correct. Lightning payments are routed through ASPs. ASP may
> not cooperate in forwarding HTLC(s) AFTER double-spending their pool
> transaction. However, it's a footgun if ASP forwards HTLC(s) BEFORE
> double-spending their pool transaction.
>
> What makes Ark magical is, in the collaborative case, users' ability to
> pay lightning invoices with their zero-conf vTXOs, without waiting for
> on-chain confirmations.
>
> This is the opposite of swap-ins, where users SHOULD wait for on-chain
> confirmations before revealing their preimage of the HODL invoice;
> otherwise, the swap service provider can steal users' sats by
> double-spending their zero-conf HTLC.
> ___
> 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] brickchain

[G. Andrew Stone via bitcoin-dev]

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 exact reward and the major
negative consequence of miners creating spam tx needs careful thought.

See "bobtail" for a weak block proposal that produces a more consistent
discovery time, and "tailstorm" for a proposal that uses the content of
those weak blocks as commitment to what transactions miners are working on
(which will allow more trustworthy (but still not foolproof) use of
transactions before confirmation)... neither of which have a snowball's
chance in hell (along with any other hard forking change) of being put into
bitcoin :-).

Andrew

On Wed, Oct 19, 2022 at 12:05 PM mm-studios via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thanks all for your responses.
> so is it a no-go is because "reduced settlement speed is a desirable
> feature"?
>
> I don';t know what weights more in this consideration:
> A) to not increase the workload of full-nodes, being "less difficult to
> operate" and hence reduce the chance of some of them giving up which would
> lead to a negative centralization effect. (a bit cumbersome reasoning in my
> opinion, given the competitive nature of PoW itself, which introduce an
> accepted centralization, forcing some miners to give up). In this case the
> fact is accepted because is decentralized enough.
> B) to not undermine L2 systems like LN.
>
> in any case it is a major no-go reason, if there is not intention to speed
> up L1.
> Thanks
> M
> --- Original Message ---
> On Wednesday, October 19th, 2022 at 3:24 PM, Erik Aronesty 
> wrote:
>
> > currently, a miner produce blocks with a limited capacity of
> transactions that ultimately limits the global settlement throughput to a
> reduced number of tx/s.
>
> reduced settlement speed is a desirable feature and isn't something we
> need to fix
>
> the focus should be on layer 2 protocols that allow the ability to hold &
> transfer, uncommitted transactions as pools / joins, so that layer 1's
> decentralization and incentives can remain undisturbed
>
> protocols like mweb, for example
>
>
>
>
> On Wed, Oct 19, 2022 at 7:34 AM mm-studios via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Bitcoin devs,
>> I'd like to share an idea of a method to increase throughput in the
>> bitcoin network.
>>
>> Currently, a miner produce blocks with a limited capacity of transactions
>> that ultimately limits the global settlement throughput to a reduced number
>> of tx/s.
>>
>> Big-blockers proposed the removal of limits but this didn't come with
>> undesirable effects that have been widely discussed and rejected.
>>
>> The main feature we wanted to preserve is 'small blocks', providing
>> 'better network effects' I won't focus on them.
>>
>> The problem with small blocks is that, once a block is filled
>> transactions, they are kept back in the mempool, waiting for their turn in
>> future blocks.
>>
>> The following changes in the protocol aim to let all transactions go in
>> the current block, while keeping the block size small. It requires changes
>> in the PoW algorithm.
>>
>> Currently, the PoW algorithm consists on finding a valid hash for the
>> block. Its validity is determined by comparing the numeric value of the
>> block hash with a protocol-defined value difficulty.
>>
>> Once a miner finds a nonce for the block that satisfies the condition the
>> new block becomes valid and can be propagated. All nodes would update their
>> blockchains with it. (assuming no conflict resolution (orphan blocks, ...)
>> for clarity).
>>
>> This process is meant to happen every 10 minutes in average.
>>
>> With this background information (we all already know) I go on to
>> describe the idea:
>>
>> Let's allow a miner to include transactions until the block is filled,
>> let's call this structure (coining a new term 'Brick'), B0. [brick=block
>> that doesn't meet the difficulty rule and is filled of tx to its full
>> capacity]
>> Since PoW hashing is continuously active, Brick B0 would have a nonce
>> corresponding to a minimum numeric value of its hash found until it got
>> filled.
>>
>> Fully filled brick B0, with a hash that doesn't meet the difficulty rule,
>> would be broadcasted and nodes would have it on in a separate fork as usual.
>>
>> At this point, instead of discarding transactions, our miner would start
>> working on a new brick B1, linked with B0 as usual.
>>
>> Nodes would allow incoming regular blocks and bricks with hashes that
>> don't satisfy the difficulty rule, provided the brick is fully filled of
>> transactions. Bricks not fully filled would be rejected as invalid to
>> prevent spam (except if constitutes the last brick of a brickchain,
>> explained below).
>>
>> Let's assume that 10 

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

[G. Andrew Stone via bitcoin-dev]

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 (with a 32 or 64 bit keyspace you can basically hand out prefixes
to any implementation that wants one)  and publish custom data via this
message without needing to bump the protocol rev field.  Typical "custom
data" would be the min and max supported version of some specific extended
protocol, but any data is possible since the "value" field can be
serialized via the same network serialization format.  It therefore doubles
as a "configuration" message as well as protocol extension negotiation.
For example, we use it to communicate the maximum unconfirmed chain a node
will commit to the mempool, and peers don't bother to send transactions
that exceed this limit.

You can find a specification here:
https://gitlab.com/bitcoinunlimited/BCHUnlimited/-/blob/dev/doc/xversionmessage.md

Code has been deployed for a long time.

Regards,
Andrew


On Mon, Aug 24, 2020 at 5:44 AM Suhas Daftuar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Thanks for the helpful discussion.
>
> My primary motivation in starting this thread was to establish what the
> expectations are for new feature deployment (particularly whether the
> protocol version should continue to be bumped or not), and I think I have
> that answer -- different from what I proposed when I started this thread,
> but not in a way that I think meaningfully hinders future work.  So I'm
> happy to leave it at that and withdraw my suggestion.
>
> Cheers,
> Suhas
>
>
> On Sun, Aug 23, 2020 at 1:51 PM Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> > On Aug 21, 2020, at 15:16, Matt Corallo 
>> wrote:
>> >
>> > Hmm, could that not be accomplished by simply building this into new
>> messages? eg, send "betterprotocol", if you see a verack and no
>> "betterprotocol" from your peer, send "worseprotocol" before you send a
>> "verack".
>> >
>> > Matt
>> >
>> >> On 8/21/20 5:17 PM, Jeremy wrote:
>> >> As for an example of where you'd want multi-round, you could imagine a
>> scenario where you have a feature A which gets bugfixed by the introduction
>> of feature B, and you don't want to expose that you support A unless you
>> first negotiate B. Or if you can negotiate B you should never expose A, but
>> for old nodes you'll still do it if B is unknown to them.
>>
>> This seems to imply a security benefit (I can’t discern any other
>> rationale for this complexity). It should be clear that this is no more
>> than trivially weak obfuscation and not worth complicating the protocol to
>> achieve.
>>
>> >> An example of this would be (were it not already out without a feature
>> negotiation existing) WTXID/TXID relay.
>> >> The SYNC primitve simply codifies what order messages should be in and
>> when you're done for a phase of negotiation offering something. It can be
>> done without, but then you have to be more careful to broadcast in the
>> correct order and it's not clear when/if you should wait for more time
>> before responding.
>> >> On Fri, Aug 21, 2020 at 2:08 PM Jeremy > jlru...@mit.edu>> wrote:
>> >>Actually we already have service bits (which are sadly limited)
>> which allow negotiation of non bilateral feature
>> >>support, so this would supercede that.
>> >>--
>> >>@JeremyRubin <
>> https://twitter.com/JeremyRubin>
>> ___
>> 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] A Better MMR Definition

[G. Andrew Stone via bitcoin-dev]

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 sense that if transaction inputs were specified by a [block
height, tx index, output index] triple we'd have a much more size-efficient
transaction format.  This format would make look up pretty simple in
Peter's pruned time-ordered TXO merkle mountain range, although you'd have
translate the triple to an index, which means we'd have to at a minimum
keep track of the number of TXOs in each block, and then probably do a
linear search starting from the location where the block's TXOs begin in
the MMR.  (The ultimate option I guess is to specify transaction inputs by
a single number which is essentially the index of the TXO in a (never
actually created) insertion-ordered TXO array...)

But since transactions' prevouts are not specified by [block height, tx
index, output index] or by TXO index, I don't understand how an insertion
ordered TXO tree can result in efficient lookups.  Can you help me
understand this?



On Sat, Feb 25, 2017 at 1:23 AM, Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Feb 24, 2017 at 8:12 PM, Peter Todd  wrote:
>
>>
>> So to be clear, what you're proposing there is to use the insertion order
>> as
>> the index - once you go that far you've almost entirely re-invented my
>> proposal!
>>
>
> I'm not 'proposing' this, I'm saying it could be done simply but I'm
> skeptical of the utility. Probably the most compelling argument for it is
> that the insertion indexed values are much smaller so they can be compacted
> down a lot resulting in using less memory and more locality and fewer
> hashes, but your implementation doesn't take advantage of that.
>
>
>> Your merkle-set implementation is 1500 lines of densely written Python
>
>
> The reference implementation which is included in those 1500 lines is less
> than 300 lines and fairly straightforward. The non-reference implementation
> always behaves semantically identically to the reference implementation, it
> just does so faster and using less memory.
>
>
>> with
>> almost no comments,
>
>
> The comments at the top explain both the proof format and the in-memory
> data structures very precisely. The whole codebase was reviewed by a
> coworker of mine and comments were added explaining the subtleties which
> tripped him up.
>
>
>> and less than a 100 lines of (also uncommented) tests.
>
>
> Those tests get 98% code coverage and extensively hit not only the lines
> of code but the semantic edge cases as well. The lines which aren't hit are
> convenience functions and error conditions of the parsing code for when
> it's passed bad data.
>
>
>> By
>> comparison, my Python MMR implementation is 300 lines of very readable
>> Python
>> with lots of comments, a 200 line explanation at the top, and 200 lines of
>> (commented) tests. Yet no-one is taking the (still considerable) effort to
>> understand and comment on my implementation. :)
>>
>
> Given that maaku's Merkle prefix trees were shelved because of performance
> problems despite being written in C and operating in basically the same way
> as your code and my reference code, it's clear that non-optimized Python
> won't be touching the bitcoin codebase any time soon.
>
>
>>
>> Fact is, what you've written is really daunting to review, and given it's
>> not
>> in the final language anyway, it's unclear what basis to review it on
>> anyway.
>
>
> It should reviewed based on semantic correctness and performance.
> Performance can only be accurately and convincingly determined by porting
> to C and optimizing it, which mostly involves experimenting with different
> values for the two passed in magic numbers.
>
>
>> I
>> suspect you'd get more feedback if the codebase was better commented, in a
>> production language, and you have actual real-world benchmarks and
>> performance
>> figures.
>>
>
> Porting to C should be straightforward. Several people have already
> expressed interest in doing so, and it's written in intentionally C-ish
> Python, resulting in some rather odd idioms which is a bit part of why you
> think it looks 'dense'. A lot of that weird offset math should be much more
> readable in C because it's all structs and x.y notation can be used instead
> of adding offsets.
>
>
>> In particular, while at the top of merkle_set.py you have a list of
>> advantages,
>> and a bunch of TODO's, you don't explain *why* the code has any of these
>> advantages. To figure that out, I'd have to read and understand 1500
>> lines of
>> densely written Python. Without a human-readable pitch, not many people
>> are
>> going to do that, myself included.
>>
>
> It's all about cache coherence. When doing operations it pulls in a bunch
> of things which 

Re: [bitcoin-dev] A Better MMR Definition

[G. Andrew Stone via bitcoin-dev]

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
> >  wrote:
> > > Reposting something that came up recently in a private discussion with
> some
> > > academics:
> > >
> > > Concretely, let's define a prunable MMR with the following grammar.
> This
> > > definition is an improvement on whats in the python-proofmarshal by
> > > committing
> > > to the number of items in the tree implicitly; an obvious
> max-log2(n)-sized
> > > proof-of-tree-size can be obtained by following the right-most nodes:
> >
> > What problem does this try to solve, and what does it have to do with
> bitcoin?
>
> See the discussion on TXO commitments for how MMR's could be used; a
> better MMR
> makes for a better TXO commitment.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> ___
> 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] Services bit for xthin blocks

[G. Andrew Stone via bitcoin-dev]

Thanks for your offer Luke, but we are happy with our own process and,
regardless of historical provenance, see this mailing list and the BIP
process as very Core specific for reasons that are too numerous to describe
here but should be obvious to anyone who has been aware of the last year 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 of individual engineers loosely affiliated with
> > "Core", Bitcoin Unlimited has our own process for documentation and
> > discussion on an uncensored forum located here:
> > https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/. We
> > would love to have any interested engineer join us there with ideas and
> > criticisms.
>
> Bitcoin-dev and the BIP process are not affiliated with Core at all. In
> fact,
> the BIP process was created by Amir Taaki, who was a libbitcoin developer
> (libbitcoin is not Core).
>
> I encourage Bitcoin Unlimited to use the BIP process for
> cross-implementation
> standards like this, as do other implementations, so that you can benefit
> from
> peer review from the wider Bitcoin development community, as well as have a
> common repository for these standards.
>
> Many BIPs are discussed on reddit in addition to this mailing list, and you
> would certainly remain free to discuss your own proposals on any forum you
> like - it isn't restricted to only this mailing list.
>
> If this is of interest, I will be happy to try to go over and assign BIP
> numbers to the current (15?) BUIPs assuming they meet the basic
> requirements
> for such assignment (see BIP 1:
> https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki). Is there
> an
> easy way to get links to each of the BUIPs? I couldn't find BUIP 1 at all,
> for
> example.
>
> Thanks,
>
> Luke
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Services bit for xthin blocks

[G. Andrew Stone via bitcoin-dev]

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