G. Andrew Stone [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-31 to 2023-05-23
💬 Posted a total of 9 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:21:52

- reply

📅 Original date posted:2023-05-23
🗒️ Summary of this message: A discussion on the potential risks of using Lightning Network and Atomic Swap Protocol (ASP) for Bitcoin transactions without waiting for on-chain confirmations.
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230523/0870c6d9/attachment.html>

2023-06-07 23:15:44

- reply

📅 Original date posted:2022-10-19
📝 Original message: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 at 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 <erik at q32.com>
> 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 at 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 minutes have elapsed and our miner is in a state
>> where N bricks have been produced and the accumulated PoW calculated using
>> mathematics (every brick contains a 'minimum hash found', when a series of
>> 'minimum hashes' is computationally equivalent to the network difficulty is
>> then the full 'brickchain' is valid as a Block.
>>
>> This calculus shall be better defined, but I hope that this idea can
>> serve as a seed to a BIP, or otherwise deemed absurd, which might be
>> possible and I'd be delighted to discover why a scheme like this wouldn't
>> work.
>>
>> If it finally worked, it could completely flush mempools, keep
>> transactions fees low and increase throughput without an increase in the
>> block size that would raise other concerns related to propagation.
>>
>> Thank you.
>> I look forward to your responses.
>>
>> --
>> Marcos Mayorga
>> https://twitter.com/KatlasC
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/335c8792/attachment.html>

2023-06-07 18:26:31

- reply

📅 Original date posted:2020-08-24
📝 Original message: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 at 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 at lists.linuxfoundation.org> wrote:
>
>>
>> > On Aug 21, 2020, at 15:16, Matt Corallo <lf-lists at mattcorallo.com>
>> 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 <jlrubin at mit.edu <mailto:
>> jlrubin at 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><
>> https://twitter.com/JeremyRubin>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200824/3991406e/attachment.html>

2023-06-07 17:56:36

- reply

📅 Original date posted:2017-02-28
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> On Fri, Feb 24, 2017 at 8:12 PM, Peter Todd <pete at petertodd.org> 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 are near each other in memory instead of jumping all over
> the place. The improvements it gets should be much greater than the ones
> gained from insertion ordering, although the two could be accretive.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170228/0d77e5d7/attachment.html>

2023-06-07 17:56:31

- reply

📅 Original date posted:2017-02-23
📝 Original message:Can an insertion ordered MMR allow an efficient nonexistence proof?
On Feb 23, 2017 1:20 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev at 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
> > <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170223/07c5af54/attachment.html>

2023-06-07 17:49:43

- reply

📅 Original date posted:2016-03-09
📝 Original message: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 <luke at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160309/e09b5b92/attachment.html>

2023-06-07 17:49:42

- reply

📅 Original date posted:2016-03-08
📝 Original message:Included at the bottom of this mail is a BIP concerning our impending use
of a particular services bit.
I am making a good-faith effort to notify the community of this use and
follow the BIP submission rules with a correctly formatted BIP sent to Luke
jr. He has informed me that such a BIP should be discussed on the mailing
list (which is this thread) and that the BIP should document the extreme
thin block protocol.
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.
But since Bitcoin Unlimited already has a process, it would be redundant
and time consuming for us to adhere to your process. If a "Core" engineer
would like to spend the time to move this BIP through your process I would
be eternally grateful and be willing to use a different bit or make other
changes that make mutual sense. If not, then it is up to "Core" as a group
to decide whether they would like to preserve interoperability as the
protocol intended by avoiding use of bit 1<<4 (except to indicate the
presence of a compatible Xthin implementation), or whether they will force
clients to take the sub-version field into account when determining client
capabilities.
Regards,
Andrew Stone
Developer, Bitcoin Unlimited
<pre>
BIP: XXX
Title: Extreme thin block service bit
Author: Andrew Stone <g.andrew.stone at gmail.com>
Status:
Type: Standards Track
Created: 2016-03-07
</pre>
==Abstract==
Nodes need to communicate to each other whether or not thin block
communication messages are supported.
==Motivation==
# Ensure Satoshi client interoperability
==Rationale==
Clients will use this functionality to choose peers, so a service bit is
the most appropriate location.
==Specification==
# Bit (1 << 4) of the nServices flags enum located in protocol.h shall
indicate the ability to handle thin block communication messages.
==Backward compatibility==
All older clients are compatible with this change. Users and merchants
should not be impacted.
==Implementation==
/** nServices flags */
enum {
...
// NODE_XTHIN means the node is capable of and willing to handle Xthin
messages.
NODE_XTHIN = (1 << 4),
...
};
==Copyright==
This document is Public Domain.
On Mon, Mar 7, 2016 at 4:10 PM, dagurval <dagurvj+btclist at gmail.com> wrote:
> Hi,
>
> > Does this functionality change peer selection?
>
> This bit will be used for selecting outgoing peers in Bitcoin XT.
>
> On Mon, Mar 7, 2016 at 9:51 PM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > 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.
>>
>> Does this functionality change peer selection? If not, the preferred
>> signaling mechanism is probably the one in BIP 130.
>>
>> Otherwise, I think the standard method for getting numbers has been to
>> write a BIP documenting the usage. I don't know if that is intentional
>> or just how things have previously happened; and I don't have much of
>> an opinion on it.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160307/8f3f62c2/attachment-0001.html>

2023-06-07 17:49:42

- reply

📅 Original date posted:2016-03-07
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160307/e2f1149f/attachment.html>

2023-06-07 15:44:27

- reply

📅 Original date posted:2015-07-31
📝 Original message:There's a large array of solutions that are bigger than the cheapest home
broadband, but smaller then renting hardware in a data center. Every
company with internet service to their location purchases one of these
options. If Bitcoin full node bandwidth requirements ever exceed a
hobbyist's reach, s/he can always pool resources with other individuals to
purchase one of these solutions, and a 1-room office.
How many of you have connected to multiple ISPs and are routing internet
traffic between them? But TCP is still permissionless.
Bitcoin node requirements will grow beyond a hobbyist reach (but not that
of the garage entrepreneur). The truth is that as technologies grow and
mature, the hobbyists move on but anyone who has a real reason to continue
using it stays. This fact does not destroy its decentralization.
I do not think that reasonable scaling will significantly affect full node
quantity (historical downtrends are conflated with the simultaneous
transition from hobbyist to professional).
At the same time the ability to create an independent full node is a
tremendous force keeping existing full nodes honest -- this potential is
more powerful then the fact.
Which would you choose, a 10 thousand node strong bankCoin, or a 1000 node
open source permissionless Bitcoin?
On Fri, Jul 31, 2015 at 12:22 PM, Dave Scotese via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Here are some books that will help more people understand why Adam's
> concern is important:
> Kicking the Dragon (by Larken Rose)
> The State (by Franz Oppenheimer)
>
> Like he said, it isn't much about bitcoin. Our crypto is just one of the
> defenses we've created, and understanding what it defends will help us
> maintain its value.
>
> Dave
>
> On Fri, Jul 31, 2015 at 6:16 AM, Adam Back via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I think trust the data-center logic obviously fails, and I was talking
>> about this scenario in the post you are replying to. You are trusting the
>> data-center operator period. If one could trust data-centers to run
>> verified code, to not get hacked, filter traffic, respond to court orders
>> without notifying you etc that would be great but that's unfortunately not
>> what happens.
>>
>> Data-center operators are bound to follow laws, including NSLs and gag
>> orders. They also get hacked, employ humans who can be corrupt,
>> blackmailed, and themselves centralisation points for policy attack.
>> Snowden related disclosures and keeping aware of security show this is very
>> real.
>>
>> This isn't much about bitcoin even, its just security reality for hosting
>> anything intended to be secure via decentralisation, or just hosting in
>> general while at risk of political or policy attack.
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150731/8b30a557/attachment.html>