<unnamed>

Public Key

npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq

Profile Code

nprofile1qqsw3xtk35j57dfh4alzv32edpvrvvks4v9af3uqg302e7sg0tyqmrcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsfmvcz6

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-09 14:43:53 CEST

- reply

📅 Original date posted:2015-08-01
📝 Original message:
> On Jul 30, 2015, at 4:48 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> But I realized yesterday, outsourcing needs a new sighash op mode (or
> normalized txids), so it's not really something to design a deployable
> system around today.
Can you elaborate on this, Rusty?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150801/f828e56a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150801/f828e56a/attachment.sig>

2023-06-07 19:50:10 CEST

- reply

📅 Original date posted:2016-04-21
📝 Original message:In practice the probability of this case triggering is on the order of 2^-128 or something astronomically tiny. I've been using BIP32 for a few years already as have many others...I don't think we've ever had to handle this case. Justifiably, many app developers feel like the additional complexity of properly handling this case is not worth the effort.
Having said that, if the handling of this case is simple to implement and easy to isolate in the program flow, I am in favor of doing something along the lines of what you propose.
- Eric
On April 20, 2016 9:32:25 AM PDT, Jochen Hoenicke via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Hello Bitcoin Developers,
>
>I would like to make a proposal to update BIP-32 in a small way.
>
>TL;DR: BIP-32 is hard to use right (due to its requirement to skip
>addresses). This proposal suggests a modification such that the
>difficulty can be encapsulated in the library.
>
>#MOTIVATION:
>
>The current BIP-32 specifies that if for some node in the hierarchy
>the computed hash I_L is larger or equal to the prime or 0, then the
>node is invalid and should be skipped in the BIP-32 tree. This has
>several unfortunate consequences:
>
>- All callers of CKDpriv or CKDpub have to check for errors and handle
> them appropriately. This shifts the burden to the application
> developer instead of being able to handle it in the BIP-32 library.
>
>- It is not clear what to do if an intermediate node is
> missing. E.g. for the default wallet layout, if m/i_H/0 is missing
> should m/i_H/1 be used for external chain and m/i_H/2 for internal
> chain? This would make the wallet handling much more difficult.
>
>- It gets even worse with standards like BIP-44. If m/44' is missing
> should we use m/45' instead? If m/44'/0' is missing should we use
> m/44'/1' instead, using the same addresses as for testnet?
> One could also restart with a different seed in this case, but this
> wouldn't work if one later wants to support another BIP-43 proposal
> and still keep the same wallet.
>
>I think the first point alone is reason enough to change this. I am
>not aware of a BIP-32 application that handles errors like this
>correctly in all cases. It is also very hard to test, since it is
>infeasible to brute-force a BIP-32 key and a path where the node does
>not exists.
>
>This problem can be avoided by repeating the hashing with slightly
>different input data until a valid private key is found. This would
>be in the same spirit as RFC-6979. This way, the library will always
>return a valid node for all paths. Of course, in the case where the
>node is valid according to the current standard the behavior should be
>unchanged.
>
>I think the backward compatibility issues are minimal. The chance
>that this affects anyone is less than 10^-30. Even if it happens, it
>would only create some additional addresses (that are not seen if the
>user downgrades). The main reason for suggesting a change is that we
>want a similar method for different curves where a collision is much
>more likely.
>
>#QUESTIONS:
>
>What is the procedure to update the BIP? Is it still possible to
>change the existing BIP-32 even though it is marked as final? Or
>should I make a new BIP for this that obsoletes BIP-32?
>
>What algorithm is preferred? (bike-shedding) My suggestion:
>
>---
>
>Change the last step of the private -> private derivation functions to:
>
> . In case parse(I_L) >= n or k_i = 0, the procedure is repeated
> at step 2 with
> I = HMAC-SHA512(Key = c_par, Data = 0x01 || I_R || ser32(i))
>
>---
>
>I think this suggestion is simple to implement (a bit harder to unit
>test) and the string to hash with HMAC-SHA512 always has the same
>length. I use I_R, since I_L is obviously not very random if I_L >= n.
>There is a minimal chance that it will lead to an infinite loop if I_R
>is the same in two consecutive iterations, but that has only a chance
>of 1 in 2^512 (if the algorithm is used for different curves that make
>I_L >= n more likely, the chance is still less than 1 in 2^256). In
>theory, this loop can be avoided by incrementing i in every iteration,
>but this would make an implementation error in the "hard to test" path
>of the program more likely.
>
>The other derivation functions should be updated in a similar matter.
>Also the derivation of the root node from the seed should be updated
>in a similar matter to avoid invalid seeds.
>
>If you followed until here, thanks for reading this long posting.
>
> Jochen
>_______________________________________________
>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/20160421/f6ea5a61/attachment.html>

2023-06-07 19:48:15 CEST

- reply

📅 Original date posted:2016-01-28
📝 Original message:Folks,
I think the current situation with forks could have been avoided with a better process that can distinguish between different layers for bitcoin modification proposals.
For instance, BIP64 was proposed by Mike Hearn, which does not affect the consensus layer at all. Many Core devs disliked the proposal and Mike had lots of pushback. Regardless of whether or not you agree with the merits of Mike’s ideas here, fact is having nodes that support BIP64 would not fundamentally break the Bitcoin network.
This issue prompted Mike to break off from Core and create XT as the applications he was developing required BIP64 to work. With this split, Gavin found a new home for his big block ideas…and the two teamed up.
We need to have a process that clearly distinguishes these different layers and allows much more freedom in the upper layers while requiring agreement at the consensus layer. Many of these fork proposals are actually conflating different features, only some of which would actually be consensus layer changes. When people proposing nonconsensus features get pushback from Core developers they feel rejected and are likely to team up with others trying to push for hard forks and the like.
A while back I had submitted a BIP - BIP123 - that addresses this issue. I have updated it to include all the currently proposed and accepted BIPs and have submitted a PR: https://github.com/bitcoin/bips/pull/311 <https://github.com/bitcoin/bips/pull/311>
I urge everyone to seriously consider getting this BIP accepted as a top priority before we get more projects all trying their hand at stuff and not understanding these critical distinctions.
- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/2e877491/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160128/2e877491/attachment-0001.sig>

2023-06-07 19:47:08 CEST

- reply

📅 Original date posted:2015-12-26
📝 Original message:For simplicity, assume total network hashpower is constant. Also, assume the soft fork activates at the beginning of a retarget period.
At the moment the soft fork activates, the effective difficulty is increased (by adding a second independent PoW check that must also be satisfied) which means more hashes on average (and proportionally more time) are required to find a block. At the end of the retarget period, the difficulty is lowered so that if the second PoW difficulty were to be kept constant the block interval would again average 10 mins.
If we were to keep the second PoW difficulty constant, we would restore the same total PoW-to-time-unit ratio and the retarget difficulty would stabilize again so each block would once more require the same number of hashes (and same amount of time) on average as before.
But we don't keep the second PoW difficulty constant - we increase it so once again more hashes on average are required to find a block by the same proportion as before. And we keep doing this.
Now, the assumption that hashpower is constant is obviously unrealistic. If this is your bone of contention, then yes, I agree my model is overly simplistic.
My larger point was to explore the extent of what's possible with only a soft fork - and we can actually go pretty far and even compensate for these economic shifts by increasing block size and rewards. The whole thing is clearly a huge mess - and I wouldn't recommend actually doing it.
On December 26, 2015 7:33:53 AM PST, "Jorge Timón" <jtimon at jtimon.cc> wrote:
>On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
>bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Unfortunately, this also means longer confirmation times, lower
>throughput, and lower miner revenue. Note, however, that confirmations
>would (on average) represent more PoW, so fewer confirmations would be
>required to achieve the same level of security.
>>
>
>I'm not sure I understand this. If mining revenue per unit of time
>drops,
>total pow per unit of time should also drop. Even if the inter-block
>time
>is increased, it's not clear to me that the pow per block would
>necessarily
>be higher.
>What am I missing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/91406f63/attachment-0001.html>

2023-06-07 19:47:07 CEST

- reply

📅 Original date posted:2015-12-26
📝 Original message:Note: my stupid email client didn't indent Peter Todd's quote correctly.
The first paragraph is his, the second is my response.
------ Original Message ------
From: "Eric Lombrozo" <elombrozo at gmail.com>
To: "Peter Todd" <pete at petertodd.org>; "Emin Gün Sirer"
<el33th4x0r at gmail.com>
Cc: nbvfour at gmail.com; "Bitcoin Dev"
<bitcoin-dev at lists.linuxfoundation.org>
Sent: 12/26/2015 12:23:38 AM
Subject: Re[2]: [bitcoin-dev] We need to fix the block withholding
attack
>Peter Todd wrote:
> Fixing block withholding is relatively simple, but (so far) requires a
>SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should
>do this hard-fork in conjunction with any blocksize increase, which
>will
>have the desirable side effect of clearly show consent by the entire
>ecosystem, SPV clients included.
>
>I think we can generalize this and argue that it is impossible fix this
>without reducing the visible difficulty and blinding the hasher to an
>invisible difficulty. Unfortunately, changing the retargeting algo to
>compute lower visible difficulty (leaving all else the same) or
>interpreting the bits field in a way that yields a lower visible
>difficulty is a hard fork by definition - blocks that didn't meet the
>visible difficulty requirement before will now meet it.
>
>jl2012 wrote:
>>After the meeting I find a softfork solution. It is very inefficient
>>and I am leaving it here just for record.
>>
>>1. In the first output of the second transaction of a block, mining
>>pool will commit a random nonce with an OP_RETURN.
>>
>>2. Mine as normal. When a block is found, the hash is concatenated
>>with the committed random nonce and hashed.
>>
>>3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the
>>block is invalid. That means about 1% of blocks are discarded.
>>
>>4. For each difficulty retarget, the secondary target is decreased by
>>2 ^ 1/64.
>>
>>5. After 546096 blocks or 10 years, the secondary target becomes 2 ^
>>252. Therefore only 1 in 16 hash returned by hasher is really valid.
>>This should make the detection of block withholding attack much
>>easier.
>>
>>All miners have to sacrifice 1% reward for 10 years. Confirmation will
>>also be 1% slower than it should be.
>>
>>If a node (full or SPV) is not updated, it becomes more vulnerable as
>>an attacker could mine a chain much faster without following the new
>>rules. But this is still a softfork, by definition.
>jl2012's key discovery here is that if we add an invisible difficulty
>while keeping the retarget algo and bits semantics the same, the
>visible difficulty will decrease automatically to compensate. In other
>words, we can artificially increase the block time interval, allowing
>us to force a lower visible difficulty at the next retarget without
>changing the retarget algo nor the bits semantics. There are no other
>free parameters we can tweak, so it seems this is really the best we
>can do.
>
>Unfortunately, this also means longer confirmation times, lower
>throughput, and lower miner revenue. Note, however, that confirmations
>would (on average) represent more PoW, so fewer confirmations would be
>required to achieve the same level of security.
>
>We can compensate for lower throughput and lower miner revenue by
>increasing block size and increasing block rewards. Interestingly, it
>turns out we *can* do these things with soft forks by embedding new
>structures into blocks and nesting their hash trees into existing
>structures. Ideas such as extension blocks
>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html]
>have been proposed before...but they add significant complications to
>the protocol and require nontrivial app migration efforts. Old nodes
>would not get forked off the network but backwards compatibility would
>still be a problem as they would not be able to see at least some of
>the transactions and some of the bitcoins in blocks. But if we're
>willing to accept this, even the "sacred" 21 million asymptotic limit
>can be raised via soft fork!
>
>So in conclusion, it *is* possible to fix this attack with a soft fork
>and without altering the basic economics...but it's almost surely a lot
>more trouble than it's worth. Luke-Jr's solution is far simpler and
>more elegant and is perhaps one of the few examples of a new feature
>(as opposed to merely a structure cleanup) that would be better to
>deploy as a hard fork since it's simple to implement and seems to stand
>a reasonable chance of near universal support...and soft fork
>alternatives are very, very ugly and significantly impact system
>usability...and I think theory tells us we can't do any better.
>
>- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/381a45ab/attachment.html>

2023-06-07 19:47:07 CEST

- reply

📅 Original date posted:2015-12-26
📝 Original message:Peter Todd wrote:
Fixing block withholding is relatively simple, but (so far) requires a
SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should
do this hard-fork in conjunction with any blocksize increase, which will
have the desirable side effect of clearly show consent by the entire
ecosystem, SPV clients included.
I think we can generalize this and argue that it is impossible fix this
without reducing the visible difficulty and blinding the hasher to an
invisible difficulty. Unfortunately, changing the retargeting algo to
compute lower visible difficulty (leaving all else the same) or
interpreting the bits field in a way that yields a lower visible
difficulty is a hard fork by definition - blocks that didn't meet the
visible difficulty requirement before will now meet it.
jl2012 wrote:
>After the meeting I find a softfork solution. It is very inefficient
>and I am leaving it here just for record.
>
>1. In the first output of the second transaction of a block, mining
>pool will commit a random nonce with an OP_RETURN.
>
>2. Mine as normal. When a block is found, the hash is concatenated with
>the committed random nonce and hashed.
>
>3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the
>block is invalid. That means about 1% of blocks are discarded.
>
>4. For each difficulty retarget, the secondary target is decreased by 2
>^ 1/64.
>
>5. After 546096 blocks or 10 years, the secondary target becomes 2 ^
>252. Therefore only 1 in 16 hash returned by hasher is really valid.
>This should make the detection of block withholding attack much easier.
>
>All miners have to sacrifice 1% reward for 10 years. Confirmation will
>also be 1% slower than it should be.
>
>If a node (full or SPV) is not updated, it becomes more vulnerable as
>an attacker could mine a chain much faster without following the new
>rules. But this is still a softfork, by definition.
jl2012's key discovery here is that if we add an invisible difficulty
while keeping the retarget algo and bits semantics the same, the visible
difficulty will decrease automatically to compensate. In other words, we
can artificially increase the block time interval, allowing us to force
a lower visible difficulty at the next retarget without changing the
retarget algo nor the bits semantics. There are no other free parameters
we can tweak, so it seems this is really the best we can do.
Unfortunately, this also means longer confirmation times, lower
throughput, and lower miner revenue. Note, however, that confirmations
would (on average) represent more PoW, so fewer confirmations would be
required to achieve the same level of security.
We can compensate for lower throughput and lower miner revenue by
increasing block size and increasing block rewards. Interestingly, it
turns out we *can* do these things with soft forks by embedding new
structures into blocks and nesting their hash trees into existing
structures. Ideas such as extension blocks
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html]
have been proposed before...but they add significant complications to
the protocol and require nontrivial app migration efforts. Old nodes
would not get forked off the network but backwards compatibility would
still be a problem as they would not be able to see at least some of the
transactions and some of the bitcoins in blocks. But if we're willing to
accept this, even the "sacred" 21 million asymptotic limit can be raised
via soft fork!
So in conclusion, it *is* possible to fix this attack with a soft fork
and without altering the basic economics...but it's almost surely a lot
more trouble than it's worth. Luke-Jr's solution is far simpler and more
elegant and is perhaps one of the few examples of a new feature (as
opposed to merely a structure cleanup) that would be better to deploy as
a hard fork since it's simple to implement and seems to stand a
reasonable chance of near universal support...and soft fork alternatives
are very, very ugly and significantly impact system usability...and I
think theory tells us we can't do any better.
- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/5d48d72e/attachment-0001.html>

2023-06-07 19:46:32 CEST

- reply

📅 Original date posted:2015-12-17
📝 Original message:There are no good short-term scaling solutions...this is a very hard problem that necessarily requires a lot of out-of-the-box thinking, something 2015 has seen a LOT of...and I'm optimistic about the ideas presented thus far.
At least SW *is* a scaling solution (albeit most of the important benefits are long term). The issue of fee events has nothing to do with scaling - it has to do with economics...specifically whether we should be subsidizing transactions, who should pay the bill for it, etc. My own personal opinion is that increasing validation costs works against adoption, not for it...even if it artificially keeps fees low - and we'll have to deal with a fee event sooner or later anyhow. You may disagree with my opinion, but please, let's stop confounding the economic issues with actual scaling.
On December 16, 2015 6:21:22 PM PST, Jeff Garzik via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo
><lf-lists at mattcorallo.com>
>wrote:
>
>> A large part of your argument is that SW will take longer to deploy
>than a
>> hard fork, but I completely disagree. Though I do not agree with some
>> people claiming we can deploy SW significantly faster than a hard
>fork,
>> once the code is ready (probably a six month affair) we can get it
>deployed
>> very quickly. It's true the ecosystem may take some time to upgrade,
>but I
>> see that as a feature, not a bug - we can build up some fee pressure
>with
>> an immediate release valve available for people to use if they want
>to pay
>> fewer fees.
>>
>
>That's taking a big risk. "Build up some fee pressure" is essentially
>risking a Fee Event if uptake is slower than planned, or traffic is
>greater
>than expected.
>
>
>
>>
>> On the other hand, a hard fork, while simpler for the ecosystem to
>upgrade
>> to, is a 1-2 year affair (after the code is shipped, so at least
>1.5-2.5
>> from today if we all put off heads down and work). One thing that has
>> concerned me greatly through this whole debate is how quickly people
>seem
>> to think we can roll out a hard fork. Go look at the distribution of
>node
>> versions on the network today and work backwards to get nearly every
>node
>> upgraded... Even with a year between fork-version-release and
>> fork-activation, we'd still kill a bunch of nodes and instead of
>reducing
>> their security model, lead them to be outright robbed.
>>
>
>A hard fork will never achieve 100% There are many credible folks and
>estimates who feel a May hard fork is reasonable and doable.
>
>Further, hard forks restore the full trustless nature of the
>post-hard-fork
>nodes. Soft forks continually erode that. That's why SW should come
>via
>hard fork. The end result is more secure - 100% validation of witness
>transactions.
>
>If regular hard fork plans are proposed in public, many months in
>advance,
>there is plenty of time for the community to react. Hard forks create
>a
>more predictable market and environment for Users, and a more secure
>network.
>
>Further, even if you believe SW makes hard fork unnecessary, it is the
>responsible thing to code and communicate to users the plan for a Fee
>Event
>just in case SW uptake and extension block use does not match
>theoretical
>projections of SW proponents.
>
>Finally, SW does not eliminate and is orthogonal to Short Term Problem
>#1
>(orig. email - drift into ECE)
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/e2c4511c/attachment.html>

2023-06-07 19:45:10 CEST

- reply

📅 Original date posted:2015-11-27
📝 Original message:After reading Rusty's post, I admit there's something to be said for the fact that both the script and the nSequence field play a combined role, and thus, making the interaction between the two more clear in the naming make sense.
It is somewhat unfortunate that currently, we can't just have a dedicated field for the purpose of relative locktime (or minimum age) without having to repurpose the only unused 32 bits in the txin.
HOWEVER...there might be ways around this issue using segwit.
I've been pondering the possibility of adding an extra input vector to the prunable extra data that comprises the witness. Witness structures can provide additional data that is used in transaction validation but does not contribute to the tx hash.
Currently, the signature checking opcodes in the script already do this implicitly for computing the hash that is signed (but not the tx hash used in block merkletrees)...and this is the principal cause of undesirable malleability issues. Clearly the signatures themselves cannot contribute to the hash they are signing. So segwit makes this separation explicit by moving the signatures to a structure external to the script. Pieter Wuille's implementation (https://github.com/sipa/bitcoin/tree/segwit) generalizes this idea using a script witness structure that is a vector of arbitrary inputs. Clearly moving the signatures into such structure is an important feature...but other types of input to the script could be placed here as well.
I had considered the possibility of placing a minimum age (relative locktime) field in the input vector that could be checked for mempool acceptance without having to evaluate the script. Of course, the location of such a field would have to be known by the mempool and cannot be an arbitrary element of a generic input vector, which adds some minor but surmountable complications.
Greg Maxwell pointed out, however, that signing opcodes that sign hashes discarding this data would make it trivial for anyone to change this field without signing anything. The nSequence fields of txins, being part of the tx serialization that gets hashed, is therefore always signed.
This led me to consider the possibility of adding extra opcodes to the script that can incorporate additional data in the hash that gets signed. This data would go in another structure that does not contribute to the tx hash but is outside the witness. Then we could add extra prunable data fields that the signer can commit to.
If I've missed something critical in the above analysis, someone please correct me...but it seems that such a mechanism would allow adding extra prunable signed data fields to transactions, which might ultimately remove scarcity of tx data that we can repurpose via soft forks. If this is the case, I would suggest turning the nSequence field into a dedicated min age/rlt field to simplify the semantics and avoid ugliness in trying to reclaim unused bits.
I may be overlooking something important here, but unless there's a reason such data cannot be made prunable, I haven't been able to poke a hole yet.
- Eric
On November 26, 2015 8:02:45 PM PST, Rusty Russell <rusty at rustcorp.com.au> wrote:
>Eric Lombrozo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>writes:
>>>From an app developer's perspective, I think it is pretty blatantly
>> clear that relative timelock is *the* critical exposed functionality
>> intended here.
>
>As someone who actually developed scripts using CSV, I agree with Mark
>(and Matt). The relative locktime stuff isn't in this opcode, it's in
>the nSequence calculation.
>
>So, I vote to keep CSV called as it is.
>
>Thanks,
>Rusty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151127/73b49c65/attachment-0001.html>

2023-06-07 19:42:45 CEST

- reply

📅 Original date posted:2015-10-06
📝 Original message:I prefer the term "clown".
Can we please move on?
------ Original Message ------
From: "cipher anthem via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org>
To: milly at bitcoins.info
Cc: bitcoin-dev at lists.linuxfoundation.org
Sent: 10/6/2015 12:17:14 AM
Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
technical debate
>> Sent: Monday, October 05, 2015 at 8:21 PM
>> From: "Milly Bitcoin via bitcoin-dev"
>><bitcoin-dev at lists.linuxfoundation.org>
>> To: bitcoin-dev at lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard
>>fork technical debate
>> On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:
>>> It's pretty clear Mike has turned into concern troll and bully.
>
>> "troll" and, even worse, "concern troll" are terms generally used by
>> teenagers on places like Reddit to complain about someone who doesn't
>> agree with them.
>
>They should substitute troll for cultist so they appear more
>professional...
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:41:31 CEST

- reply

📅 Original date posted:2015-09-28
📝 Original message:My initial reaction is just HUH?!?!? Is this some sophisticated form of humor I'm just not getting?
On September 28, 2015 3:48:57 AM PDT, Mike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>There is *no* consensus on using a soft fork to deploy this feature. It
>will result in the same problems as all the other soft forks - SPV
>wallets
>will become less reliable during the rollout period. I am against that,
>as
>it's entirely avoidable.
>
>Make it a hard fork and my objection will be dropped.
>
>Until then, as there is no consensus, you need to do one of two things:
>
>1) Drop the "everyone must agree to make changes" idea that people here
>like to peddle, and do it loudly, so everyone in the community is
>correctly
>informed
>
>2) Do nothing
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/0eabc6d7/attachment.html>

2023-06-07 19:41:29 CEST

- reply

📅 Original date posted:2015-09-29
📝 Original message:Mike,
Insults were not really my intention. Let's set aside our differences regarding SPV security and assume you understand the different implications for soft forks and hard forks.
Other than the fact that doing this as a soft fork requires an extra OP_DROP, how would doing this as a hard fork make any difference to SPV clients? If, as others have suggested, all clients warn the user on unrecognized nVersion and make unknown noops nonstandard, would this satisfy your concerns? The logic seems pretty straightforward.
- Eric
On September 28, 2015 5:54:33 AM PDT, Mike Hearn <hearn at vinumeris.com> wrote:
>>
>> we have NO hard fork mechanism in place that isn't highly prone to
>> systemic consensus failure.
>>
>
>Just use an opcode that isn't currently defined. Done. What about that
>mechanism is prone to failure?
>
>Re: coma. No need for insults. Please read my article and address the
>points raised there, which, by the way, do not include any mention of
>SPV
>wallets. Although your belief that SPV wallets are "inherently
>insecure"
>seems needlessly trollish - I certainly would disagree, but it's a
>different debate.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/f4f3138f/attachment-0001.html>

2023-06-07 19:41:28 CEST

- reply

📅 Original date posted:2015-09-28
📝 Original message:SPV wallets in their current form are inherently insecure. Moreover, while we at least have a soft fork mechanism that is not trivially exploitable (yes, it's got issues...but unlike SPV wallets, it isn't so easily exploitable), we have NO hard fork mechanism in place that isn't highly prone to systemic consensus failure.
But I think pretty much anyone who hasn't been in a coma for the last several years knows this...and I'll stop repeating the obvious.
On September 28, 2015 5:26:17 AM PDT, Mike Hearn <hearn at vinumeris.com> wrote:
>>
>> Go ahead and object to soft forks...but at least try not to make
>arguments
>> based on changing the definitions of terms we all generally agree
>upon.
>>
>
>I don't intend to do that, and I don't think I am - I know what the
>difference between a soft and hard fork is and am not trying to confuse
>or
>blur the two.
>
>To reiterate: this current BIP implements a soft fork. I am not
>debating
>that. I am saying it should use a hard fork instead. This will ensure
>no
>repeat of the P2SH case where invalid blocks were being found for weeks
>(or
>was it months?) after the new rules kicked in, thus exposing SPV
>wallets
>and old nodes to unnecessary risk for no benefit.
>
>Additionally, I am making it clear that there's no consensus for
>rolling
>out the new opcode in this way. As you say, the mechanism has issues.
>If
>you read the comments when I wrote my article, you can see that others
>share the same concerns:
>
>https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/cacc6b6d/attachment.html>

2023-06-07 19:41:28 CEST

- reply

📅 Original date posted:2015-09-28
📝 Original message:Perhaps Adam won't go into the rationale...but I think it is important we clarify this.
For better or worse, the only "voting" system available to Bitcoin that cannot be trivially attacked is hashing power. Soft forks are essentially miner-enforced rule changes...rules they could have decided to enforce without the consensus of anyone else. For instance, as far as old nodes are concerned, a p2sh output can be redeemed by a simple preimage of the hash...with no signatures. The point, however, is that as long as the majority of hashpower enforces the new rule, such attempts to redeem the output will never end up on the blockchain. Therefore, transactions that attempt to redeem the output with a simple preimage are as good as invalid...and effectively have become invalid.
I concede that this mechanism has some issues. Moreover, I agree that it is important that the Bitcoin community be aware of these things. I've been proposing making these rule changes explicit in the BIPs (https://github.com/CodeShark/bips/blob/BIP_Classification/bip-layers.mediawiki). I believe it is important that people weigh in on such rule changes. However, the above stated mechanism does not fall under the definition of "hard fork" we've come to accept.
Go ahead and object to soft forks...but at least try not to make arguments based on changing the definitions of terms we all generally agree upon.
- Eric
On September 28, 2015 4:40:35 AM PDT, Mike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> The rationale for soft vs hard-forks is well known, so I wont go over
>them.
>>
>
>The rationale of "backwards compatibility" is well known, yet wrong.
>I've
>gone over the arguments here and explained why the concept makes no
>sense:
>
>https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
>
>Eric - no, it's not sophisticated humour. I've been objecting to soft
>forks
>since this idea first appeared.
>
>There is no consensus. Now pick. Lose the requirement that everyone
>agree
>for consensus changes, and tell people you've done it. Change the spec.
>Or
>do nothing.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/3812b096/attachment.html>

2023-06-07 19:40:50 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:I love the weekly meeting idea...but timezones might be an issue.
My general preference would be afternoons to late evenings pacific time, but that translates to late night/early morning for those in europe.
On September 18, 2015 12:04:58 AM PDT, Jonas Schnelli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>> On Friday, September 18, 2015 1:07:10 AM Wladimir J. van der Laan
>> via bitcoin-dev wrote:
>>> At Monday's code sprint we had a good idea to schedule a regular
>>> developer meeting in #bitcoin-dev.
>>>
>>> Attendance is of course voluntary, but it may be good to have a
>>> time that many people are expected to be present and current
>>> issues can be discussed.
>>
>> I think it's important to make a point that these meetings are for
>> discussions, and explicitly never decisions, to avoid a repeat of
>> the P2SH events when people have to miss it.
>>
>>> Any preference for days/times?
>>>
>>> What about e.g. every week 15:00-16:00 UTC on Thursday?
>
>+1 for the weekly IRC meetings.
>
>For time and date maybe a Doodle could help:
>http://doodle.com/poll/cihug53sa8u4h2in#table
>
>
>- ---
>jonas
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJV+7eaAAoJECnUvLZBb1PsESgQAIQnHDe7owv3OzMvxwupzGaD
>IkTsRtCTSntIb75Wb/KYc0y1L3ilSENRTfZ4nNc4QquqTstkhjU5t+u9T3Mak4D3
>2/5AOiJhV6OLYav1SC7uSJh0B4halnZlTwclU7NOvmnkg40DUpNxmEbf+RvUZup3
>J0EQFxIuhtjIz0HfZTvw6wmstrP3+UJZTbM5fg0FO3TpgmGybAUoQ3eWgRa7v/gR
>OUxnAV//Mus2O80/Z+c5KycZ1Dqc/iN7cQsQFt7kEIK0epkJhkTjoRrW9MyQW04d
>1jv7d0mjEJt+2EiC8UuwpaW2eFmeFnGR0pL4UCY1QsDzGENyHKNbrVg26v1AzIbB
>SNEYN1+fmsXQYosY5t0Z887Ij+u4/GLHciimh5z7fbI5VB1Ng6Wl84maVmP5Zb3L
>MHtkIqQ00RX7GIXUp5+u7eKOO0pH9S08tqo5Ag6ceynJ2lh4Wr8BCNghHzH+ybNJ
>NG3BaSkQmjxnWjW3XplaYyxz6E4qJ8id7qH4s0iaNKchAfXiCaBtbcMfljlyBSn/
>UbzHJk5jlWZEVpxmiMRctFxusk6GI4P+0eRTJrkffskLEjImUN93A8hOLs5Dy+gI
>mm/PZKT2S2qKKa6dlI2kpyPZuRbN7+WSi/FwI0YsUDGl+IoDSqTX7WqRY8cY40ji
>rUgzYTw3Won3BcjHTe9y
>=JsXj
>-----END PGP SIGNATURE-----
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/7eecad48/attachment.html>

2023-06-07 19:40:36 CEST

- reply

📅 Original date posted:2015-09-20
📝 Original message:------ Original Message ------
From: "Milly Bitcoin via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org>
To: bitcoin-dev at lists.linuxfoundation.org
Sent: 9/20/2015 3:51:36 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
>>Some of us have also been actively working towards developing
>>a more modular, layered architecture and better implementations that
>>will afford greater decentralization in software development with less
>>need for critical code reviews, less pushback from downstream
>>developers
>>who must continuously rebase, a better process for building consensus
>>in
>>the community, and simpler app migration.
>
>It sounds more efficient but it is not clear to me that it would change
>the level of centralization of how the final decisions are made.
>
>One threat to Bintcoin involves incentive for companies to hire
>developers. The only reason is to change (or not change) Bitcoin Core
>so it is beneficial to their interests. I am not sure anything can be
>done about that risk but it needs to be understood and considered and
>not just ignored.
Core development process and decentralized dev/community consensus
building (in particular for consensus-critical changes) is at the top of
my priorities as issues right now...and one that I'd love to discuss
more in depth...but it probably deserves its own thread. The political
angle seems very difficult right now while the systems architecture
stuff seems a bit more tractable...and it seems that without
architectural changes it will be extremely hard to decentralize
development and easily bring large numbers of new developers in.
>
>>We need to increase the basic infrastructure nodes by a factor much
>>larger than 2 or 3...more like 100 or 1000...and it's entirely doable
>>with properly aligned incentives.
>
>I assume that would mean fees that hike transaction fees and make
>Bitcoin more expensive?
>
Not necessarily. Right now we already pay around 3,600 bitcoins a day in
inflationary subsidies, very little of which goes to the majority of
critical infrastructure nodes and their operators. This is a problem
with the current protocol design, one we'll hopefully be able to fix.
Having more core infrastructure nodes doesn't need to raise costs per
transaction - but it will most likely require abandoning the current
approach of having three basic node classes: miners (which tend towards
centralized pools), full nodes (which must validate each of everyone's
transaction and in return get paid nothing), and thin clients (which
essentially amount to parasitic nodes that do not contribute any
resources back to the network and must be subsidized).

2023-06-07 19:40:36 CEST

- reply

📅 Original date posted:2015-09-20
📝 Original message:------ Original Message ------
From: "Milly Bitcoin via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org>
To: bitcoin-dev at lists.linuxfoundation.org
Sent: 9/20/2015 3:02:32 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
>>Larger user base won't necessarily protect against governments if we
>>still have chokepoints they can go after.
>
>
>Bitcoin will always have chokepoints governments can go after. Hackers
>already targeted routers to divert mining traffic awhile back. Bitcoin
>traffic is easily seen and blocked by ISP's. It has already been
>pointed out that laws against merchants and exchanges cannot be
>defended against any other way than to have many people use the system.
Almost none of these merchants depend on Bitcoin in any significant way
for revenue...and that's likely to remain the case for a good while.
Merchants that have chosen to accept Bitcoin are typically using a
handful of payment processors, again...chokepoints. And almost none of
them are contributing any network resources back to Bitcoin.
Exchanges are indeed serious chokepoints. But increasing the number of
users will probably have relatively little effect on this unless we also
increase the number of exchanges and decentralize the exchanges. If all
we had to do is increase the number of users, the same argument could be
used to claim that banks would be less susceptible to governmental
crackdowns if they just had more account holders.
Exchange decentralization is indeed another thing we must work towards -
but that's probably beyond the scope of the more pressing issue which is
building consensus in Bitcoin development.
>(As a developer you, of course, did not mention the threat of having a
>tiny number of developers who have significant influence over Bitcoin.
>It always amazes me the endless discussion over miners centralization
>and almost zero discussion of developer decentralization.)
I've pointed out this weakness of Bitcoin *numerous* times. That I
failed to mention it here does not mean it hasn't been discussed
elsewhere. Some of us have also been actively working towards developing
a more modular, layered architecture and better implementations that
will afford greater decentralization in software development with less
need for critical code reviews, less pushback from downstream developers
who must continuously rebase, a better process for building consensus in
the community, and simpler app migration.
>
>
>Increasing the nodes by a factor of 2 or 3 or keeping the block size
>small to increase the diversity of miners by a few percent will have
>zero effect if those other government threats were to actually happen.
>
We need to increase the basic infrastructure nodes by a factor much
larger than 2 or 3...more like 100 or 1000...and it's entirely doable
with properly aligned incentives.
>Russ
>
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:40:35 CEST

- reply

📅 Original date posted:2015-09-20
📝 Original message:------ Original Message ------
From: "s7r via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
To: bitcoin-dev at lists.linuxfoundation.org
Sent: 9/20/2015 2:33:38 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
>The general threat model for which we want to scale is: larger user
>base
>(not necessarily by increasing the blocksize - just increase the
>transactions per second using the best way from all points of view),
>more use cases for simple people who only do basic stuff, more
>popularity but all these without the possibility for some actor to
>control more than he should (like a government agency).
Larger user base won't necessarily protect against governments if we
still have chokepoints they can go after. Given that as a currency
Bitcoin currently represents a negligible portion of the world's
economy, even growing the user base by some small factor is at best a
token gesture in our fight against governmental threats. If governments
successfully take down critical pieces of our network infrastructure,
Bitcoin will fail and most people will continue doing business as usual
(using fiat currency), most of them never even noticing anything
noteworthy happened at all.
What we really need to grow is the number of nodes on the network that
participate in its basic infrastructure - namely: miners, validators,
etc...and the more centralized these activities become, the easier it
will be for governments to clamp down.
>

2023-06-07 19:40:27 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:To be quite frank, I'm a little disappointed we've fallen back on arguing over numbers pulled out of a hat rather than discussing far more fundamental issues such as the dev process generally, consensus building, and our basic understanding of what Bitcoin really is, its strengths and weaknesses, where it shows most promise, and communicating a more unified vision to the industry and the public.
On September 18, 2015 10:10:08 AM PDT, Dave Scotese via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>"But if a metric were chosen that addressed my concerns (worst case
>propagation and validation time), then I could be in favor of an
>initial
>bump that allowed a larger number of typical transactions in a block."
>
>+1. A ratio is much more valuable than a simple metric. It seems
>clearly
>difficult to identify a reasonable limit to block size, but the ratio
>between any one of several possible metrics and bytes in a block would
>work
>well and may already have a very good reasonable expected range.
>
>I like BTCDaysDestroyed (BTCDD) best. If it might be time consuming to
>compute, then it need only be computed for all blocks less than or
>equal in
>size to the average size of the largest 200 or so blocks in the
>previous
>difficulty period. To exceed that limit, a miner would have to ensure
>that
>the block has enough BTCDD per byte. "Enough" could be hardcoded in
>each
>release, or if it's simple enough, use the ratio as computed over all
>the
>blocks in the previous difficulty period as the lower limit.
>
>notplato
>
>On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev <
>bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Correction of a correction, in-line:
>>
>> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> > - Many interested or at least willing to accept a "short term
>bump", a
>>> > hard fork to modify block size limit regime to be cost-based via
>>> > "net-utxo" rather than a simple static hard limit. 2-4-8 and
>17%/year
>>> > were debated and seemed "in range" with what might work as a short
>term
>>> > bump - net after applying the new cost metric.
>>>
>>> I would be careful to point out that hard numbers were deliberately
>NOT
>>> discussed. Though some general things were thrown out, they were not
>>> extensively discussed nor agreed to. I personally think 2-4 is "in
>>> range", though 8 maybe not so much. Of course it depends on exactly
>how
>>> the non-blocksize limit accounting/adjusting is done.
>>>
>>> Still, the "greatest common denominator" agreement did not seem to
>be
>>> agreeing to an increase which continues over time, but which instead
>>> limits itself to a set, smooth increase for X time and then requires
>a
>>> second hardfork if there is agreement on a need for more blocksize
>at
>>> that point.
>>>
>>
>> Perhaps it is accurate to say that there wasn't consensus at all
>except
>> that (1) we think we can work together on resolving this impasse
>(yay!),
>> and (2) it is conceivable that changing from block size to some other
>> metric might provide the basis for a compromise on near-term numbers.
>>
>> As an example, I do not think the net-UTXO metric provides any
>benefit
>> with respect to scalability, and in some ways makes the situation
>worse
>> (even though it helpfully solves an unrelated problem of spammy dust
>> outputs). But there are other possible metrics and I maintain hope
>that
>> data will show the benefit of another metric or other metrics
>combined with
>> net-UTXO in a way that will allow us to reach consensus.
>>
>> As a further example, I also am quite concerned about 2-4-8MB with
>either
>> block size or net-UTXO as the base metric. As you say, it depends on
>how
>> the non-blocksize limit accounting/adjusting is done... But if a
>metric
>> were chosen that addressed my concerns (worst case propagation and
>> validation time), then I could be in favor of an initial bump that
>allowed
>> a larger number of typical transactions in a block.
>>
>> But where I really need to disagree is on the requirement for a 2nd
>hard
>> fork. I will go on record as being definitively against this. While
>being
>> conservative with respect to exponentials, I would very much like to
>make
>> sure that there is a long-term growth curve as part of any proposal.
>I am
>> willing to accept a hard-fork if the adopted plan is too
>conservative, but
>> I do not want to be kicking the can down the road to a scheduled 2nd
>hard
>> fork that absolutely must occur. That, I feel, could be a more
>dangerous
>> outcome than an exponential that outlasts conservative historical
>trends.
>>
>> I commend Jeff for writing a Chatham-rules summary of the outcome of
>some
>> hallway conversations that occurred. On the whole I think his summary
>does
>> represent the majority view of the opinions expressed by core
>developers at
>> the workshop. I will caution though that on nearly every issue there
>were
>> those expressed disagreement but did not fight the issue, and those
>who
>> said nothing and left unpolled opinions. Nevertheless this summary is
>> informative as it feeds forwards into the design of proposals that
>will be
>> made prior to the Hong Kong workshop in December, in order that they
>have a
>> higher likelihood of success.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
>--
>I like to provide some work at no charge to prove my value. Do you need
>a
>techie?
>I own Litmocracy <http://www.litmocracy.com> and Meme Racing
><http://www.memeracing.net> (in alpha).
>I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
>which
>now accepts Bitcoin.
>I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
>"He ought to find it more profitable to play by the rules" - Satoshi
>Nakamoto
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/e1bb9ba2/attachment-0001.html>

2023-06-07 19:40:19 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:You're aware that my entire stack was built around this model and I've even built a fully fledged desktop GUI, multisig account manager, and servers supporting pull and event subscription atop it, right?
On September 17, 2015 5:07:20 PM PDT, "Wladimir J. van der Laan via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On Wed, Sep 16, 2015 at 06:29:28PM -0400, Peter Todd via bitcoin-dev
>wrote:
>
>> I've run into a number of cases where companies were maintaining
>forks
>> of Bitcoin Core unnecessarily, where a different, loosely coupled,
>> architecture could do what they needed to do without including the
>new
>> logic in the codebase itself.
>
>This is the same point I have been making to Jeff privately.
>
>Refactors are a means to an end: a more modular, reusable and
>maintainable codebase. This goal is that new functionality can be
>plugged in more easily, and rebase work for e.g. functionality built on
>top can go down, not up, if it just hooks into well-defined interfaces
>here and there.
>
>Although there has been a lot of progress, bitcoind's design is still
>too monolithic. To add a more involved feature, like say a new index
>over the block chain data, code needs to be touched all over the place.
>This change interacts with all other functionality, potentially
>breaking the base node functionality - risk for users that do NOT use
>the functionality. This increases risk and review time.
>
>- *If possible* functionality should be built without changing
>bitcoind's code at all. An external process should be able to keep up
>to date with the chain, notice reorgs, and process block data
>accordingly. If bitcoind's interface does not allow that, or it is too
>difficult, that is what should be fixed.
>- *if not possible* then a change should at least touch the code in as
>few places as possible, and integrate with e.g. signal notification.
>
>To name an example of it done right, IMO: Monero's 'simplewallet'. It
>is a command-line utility wallet that communicates with the node
>software, and remembers where it was in the chain, and processes
>changes to the chain state since its last invocation when it
>'refreshes'.
>What is nice is that one can run an arbitary number of simplewallets
>against one node daemon, and unlike bitcoind's wallet it doesn't need
>to run as always-on daemon itself. It can be invoked when the user
>wants to do something with the wallet, or see if there are new
>transactions.
>
>An index could be implemented entirely externally in a similar way,
>while still fully handling reorgs.
>
>What one needs for that, I think, is a library that communicate with
>the node, and which offers functionality abstractly be similar to 'git
>pull': give me the tree path from my current known tip to the best tip,
>and supply the block hashes (and block data) along the way.
>
>My long-term vision of bitcoind is a P2P node with validation and
>blockchain store, with a couple of data sources that can be subscribed
>to or pulled from.
>
>Wladimir
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/138066de/attachment.html>

2023-06-07 19:40:17 CEST

- reply

📅 Original date posted:2015-09-15
📝 Original message:I basically agree with what has been said here.
Refactoring efforts should be well-coordinated. Their short-term impact can be quite disruptive, although if done correctly, longer-term they make it even easier for downstream developers to add and merge changes.
By scheduling move-only changes, others can avoid making PRs immediately prior to or during these changes (which ironically involve considerable disruption to PRs while changing nothing for endusers). Furthermore, it would be useful to document the changes in ways that help other developers rebase properly.
On September 15, 2015 11:26:50 AM EDT, Jeff Garzik via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Drak,
>
>I would say that the refactoring does actually fulfill some conditions
>you
>mention:
>- move-only is almost always clearly separated out
>- the refactoring is not controversial _in minimis_ - meaning, the
>individual pull request is not controversial.
>
>The problem comes with the impact of an unfocused stream of refactors
>to
>key code.
>
>For example, there is much less long term developer impact if
>refactoring
>were _accelerated_, scheduled to be performed in a one-week sprint.
>There
>is a lot of breakage, yes, but after that week the average level of
>downstream patch breakage is significantly lower. A "rip the band-aid
>off
>quickly rather than slowly" approach.
>
>
>
>
>On Tue, Sep 15, 2015 at 5:55 AM, Btc Drak <btcdrak at gmail.com> wrote:
>
>> I also share a lot of Jeff's concerns about refactoring and have
>voiced
>> them several times on IRC and in private to Jorge, Wladamir and Greg.
>I
>> meant to do a write up but never got around to it. Jeff has quite
>> eloquently stated the various problems. I would like to share my
>thoughts
>> on the matter because we really do need to come up with a plan on how
>this
>> issue is dealt with.
>>
>> Obviously, Bitcoin Core is quite tightly coupled at the moment and
>> definitely needs extensive modularisation. Such work will inevitably
>> require lots of bulk code moves and then finer refactoring. However,
>it
>> requires proper planning because there are lots of effects and
>consequences
>> for other people contributing to Core and also downstream projects
>relying
>> on Core:
>>
>> 1. Refactoring often causes other pull requests to diverge and
>require
>> rebasing. Continual refactoring can put PRs in "rebase hell" and puts
>a big
>> stress on contributors (many of whom are part time).
>>
>> 2. Version to version, Bitcoin Core changes significantly in
>structure.
>> 0.9 to 0.10 is unrecognisable. 0.10 to 0.11 is even more so. This
>makes
>> makes it hard to follow release to release and the net result is less
>> people upgrade (especially think of miners trying to keep their patch
>sets
>> working while trying not to disrupt or risk their mining operations).
>>
>> 3. Continual refactoring increases risk: we're human, and mistakes
>will
>> slip through peer review. This is especially concerning with
>consensus
>> critical code and this makes it difficult to merge such refactoring
>often,
>> which of course exacerbates the problem.
>>
>> The net negative consequence is it is harder to contribute to Core,
>harder
>> for the Core maintainers to merge and harder for downstream/dependent
>> projects/implementations to keep up.
>>
>> Suggested Way Forward
>> ---------------------------------
>>
>> With the understanding that refactored code by definition must not
>change
>> behaviour. There are three major kinds of refactoring:
>>
>> 1. code moves (e.g. separating concerns into different files);
>> 2. code style;
>> 3. structural optimisation and consolidation (reducing LOC,
>separating
>> concerns, encapsulation etc).
>>
>> Code moves(1) and CS(2) are easy to peer review and merge quickly.
>The
>> third kind(3) requires deeper analysis to ensure that while the code
>> changed, the behaviour (including any bugs) did not.
>>
>> We must resist all temptation to fix bugs or tack on minor fixes and
>> tweaks during refactoring: pull requests should only be refactoring
>only,
>> with no net change to behaviour. Keeping discipline makes it much
>easier to
>> verify and peer review and this faster to merge.
>>
>> With respect to Code moves and CS, I believe we should have a
>"refactoring
>> fortnight" where we so the bulk of code move-only refactoring plus CS
>where
>> necessary. This is by fat the most disruptive kind of change because
>it
>> widely affects other PRs mergeability. We should aim to get most of
>this
>> done in one go, so that it's not happening in dribs and drabs over
>months
>> and many releases. Once done, it gives everyone a good idea to the
>overall
>> new structure and where one can expect to find things in the future.
>The
>> idea here is to help orientation and not have to continuously hunt
>for
>> where things have moved to.
>>
>> To be clear, I am strongly suggesting code move-only refactoring PRs
>not
>> be mixed with anything else. Same for CS changes. This makes the PRs
>> extremely easy to vet and thus quick to merge.
>>
>> Towards this end, maybe there should be an IRC meeting to agree the
>> initial moves, then someone who has the stomach for it can get on and
>do it
>> - during that time, we do not merge anything else. We need to bite
>the
>> bullet and break the back out of code moves.
>>
>> With regards to CS, I think we do need to get CS right, because a
>> continual dribble of CS changes also makes diffs between releases
>less easy
>> to follow. Much of CS checking can be automated by the continuous
>> integration so authors can get it right easily. It can be just like a
>> Travis check.
>>
>> With respect to the 3rd kind of refactoring, we need to set some
>standards
>> and goals and aim for some kind of consistency. Refactoring needs to
>fulfil
>> certain goals and criterion otherwise contributors will always find a
>> reason to fiddle over and over forever. Obvious targets here can be
>things
>> like proper encapsulation and separation of concerns.
>>
>> Overall, refactoring should be merged quickly, but only on a schedule
>so
>> it doesn't cause major disruption to others.
>>
>> Obviously the third kind of refactoring more complex and time
>consuming
>> and will need to occur over time, but it should happen in defined
>steps. As
>> Jeff said, one week a month, or maybe one month a release. In any
>case,
>> refactoring changes should be quickly accepted or rejected by the
>project
>> maintainer and not left hanging.
>>
>> Finally, refactoring should *always* be uncontroversial because
>> essentially functionality is not changing. If functionality changes
>(e.g.
>> you try to sneak in a big fix or feature tweak "because it's small")
>the PR
>> should be rejected outright. Additionally, if we break down
>refactoring
>> into the three kinds stated above, peer review will be much more
>> straightforward.
>>
>>
>>
>> On Tue, Sep 15, 2015 at 5:10 AM, Jeff Garzik via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> [collating a private mail and a github issue comment, moving it to a
>>> better forum]
>>>
>>> On libconsensus
>>> ---------------
>>> In general there exists the reasonable goal to move consensus state
>>> and code to a specific, separate lib.
>>>
>>> To someone not closely reviewing the seemingly endless stream of
>>> libconsensus refactoring PRs, the 10,000 foot view is that there is
>a
>>> rather random stream of refactors that proceed in fits and starts
>>> without apparent plan or end other than a one sentence "isolate
>>> consensus state and code" summary.
>>>
>>> I am hoping that
>>> * There is some plan
>>> * We will not see a five year stream of random consensus code
>movement
>>> patches causing lots of downstream developer headaches.
>>>
>>> I read every code change in every pull request that comes into
>>> github/bitcoin/bitcoin with three exceptions:
>>> * consensus code movement changes - too big, too chaotic, too
>>> frequent, too unfocused, laziness guarantees others will inevitably
>>> ACK it without me.
>>> * some non-code changes (docs)
>>> * ignore 80% of the Qt changes
>>>
>>> As with any sort of refactoring, they are easy to prove correct,
>easy
>>> to reason, and therefore quick and easy to ACK and merge.
>>>
>>> Refactors however have a very real negative impact.
>>> bitcoin/bitcoin.git is not only the source tree in the universe.
>>> Software engineers at home, at startups, and at major companies are
>>> maintaining branches of their own.
>>>
>>> It is very very easy to fall into a trap where a project is merging
>>> lots of cosmetic changes and not seeing the downstream ripple
>effects.
>>> Several people complained to me at the conference about all the code
>>> movement changes breaking their own work, causing them to stay on
>>> older versions of bitcoin due to the effort required to rebase to
>each
>>> new release version - and I share those complaints.
>>>
>>> Complex code changes with longer development cycles than simple code
>>> movement patches keep breaking. It is very frustrating, and causes
>>> folks to get trapped between a rock and a hard place:
>>> - Trying to push non-trivial changes upstream is difficult, for
>normal
>>> and reasonable reasons (big important changes need review etc.).
>>> - Maintaining non-trivial changes out of tree is also painful, for
>the
>>> aforementioned reasons.
>>>
>>> Reasonable work languishes in constant-rebase hell, and incentivizes
>>> against keeping up with the latest tree.
>>>
>>>
>>> Aside from the refactor, libconsensus appears to be engineering in
>the
>>> dark. Where is any sort of plan? I have low standards - a photo of
>a
>>> whiteboard or youtube clip will do.
>>>
>>> The general goal is good. But we must not stray into unfocused
>>> engineering for a non-existent future library user.
>>>
>>> The higher priority must be given to having a source code base that
>>> maximizes the collective developers' ability to maintain The Router
>--
>>> the core bitcoin full node P2P engine.
>>>
>>> I recommend time-based bursts of code movement changes. See below;
>>> for example, just submit & merge code movement changes on the first
>>> week of every 2nd month. Code movement changes are easy to create
>>> from scratch once a concrete goal is known. The coding part is
>>> trivial and takes no time.
>>>
>>> As we saw in the Linux kernel - battle lessons hard learned - code
>>> movement and refactors have often unseen negative impact on
>downstream
>>> developers working on more complicated changes that have more
>positive
>>> impact to our developers and users.
>>>
>>>
>>> On Bitcoin development release cycles & process
>>> ------------------------------------------------------------------
>>>
>>> As I've outlined in the past, the Linux kernel maintenance phases
>>> address some of these problems. The merge window into git master
>>> opens for 1 week, a very chaotic week full of merging (and
>rebasing),
>>> and then the merge window closes. Several weeks follow as the "dust
>>> settles" -- testing, bug fixing, moving in parallel OOB with
>>> not-yet-ready development. Release candidates follow, then the
>>> release, then the cycle repeats.
>>>
>>> IMO a merge window approach fixes some of the issues with
>refactoring,
>>> as well as introduces some useful -developer discipline- into the
>>> development process. Bitcoin Core still needs rapid iteration --
>>> another failing of the current project -- and so something of a more
>>> rapid pace is needed:
>>> - 1st week of each month, merge changes. Lots of rebasing during
>this
>>> week.
>>> - remaining days of the month, test, bug fix
>>> - release at end of month
>>>
>>> If changes are not ready for merging, then so be it, they wait until
>>> next month's release. Some releases have major features, some
>>> releases are completely boring and offer little of note. That is
>the
>>> nature of time-based development iteration. It's like dollar cost
>>> averaging, a bit.
>>>
>>>
>>> And frankly, I would like to close all github pull requests that are
>>> not ready to merge That Week. I'm as guilty of this as any, but
>that
>>> stuff just languishes. Excluding a certain category of
>obvious-crap,
>>> pull requests tend to default to a state of either (a) rapid
>merging,
>>> (b) months-long issues/projects, (c) limbo.
>>>
>>> Under a more time-based approach, a better pull request process
>would be
>>> to
>>> * Only open pull requests if it's a bug fix, or the merge window is
>>> open and the change is ready to be merged in the developer's
>opinion.
>>> * Developers CC bitcoin-dev list to discuss Bitcoin Core-bound
>projects
>>> * Developers maintain and publish projects via their own git trees
>>> * Pull requests should be closed if unmerged after 7 days, unless it
>>> is an important bug fix etc.
>>>
>>> The problem with projects like libconsensus is that they can get
>>> unfocused and open ended. Code movement changes in particular are
>>> cheap to generate. It is low developer cost for the developer to
>>> iterate all the way to the end state, see what that looks like, and
>>> see if people like it. That end state is not something you would
>>> merge all in one go. I would likely stash that tree, and then start
>>> again, seek the most optimal and least disruptive set of refactors,
>>> and generate and merge those into bitcoin/bitcoin.git in a
>time-based,
>>> paced manner. Announce the pace ahead of time - "cosmetic stuff
>that
>>> breaks your patches will be merged 1st week of every second month"
>>>
>>> To underscore, the higher priority must be given to having a source
>>> code base and disciplined development process that maximizes the
>>> collective developers' ability to maintain The Router that maintains
>>> most of our network.
>>>
>>> Modularity, refactoring, cleaning up grotty code generates a deep
>>> seated happiness in many engineers. Field experience however shows
>>> refactoring is a never ending process which sometimes gets in the
>way
>>> of More Important Work.
>>> _______________________________________________
>>> 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
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150915/428dad3f/attachment-0001.html>

2023-06-07 19:37:54 CEST

- reply

📅 Original date posted:2015-08-29
📝 Original message:In principle I am sympathetic to dynamic block size proposals...but in
practice it seems we're barking up the wrong tree. Without mechanisms for
incentivizing validators...and checks and balances between the interests of
regular users (who want to reduce fees and confirmation time), miners (who
want to balance hashing and propagation time costs with revenue), and
validator nodes (who currrently lack any direct incentives), I think we're
talking about significant protocol complications with potential benefits
that are hard to model at best.
On Sat, Aug 29, 2015, 3:16 AM Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Ah, then my mistake. It seemed so similar to an idea that was proposed
> > before on this mailing list:
> >
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
> >
> > that my mind just filled in the gaps. I concur -- having miners -- or any
> > group -- vote on block size is not an intrinsically good thing. The the
> > original proposal due to Greg Maxwell et al was not a mechanism for
> "voting"
> > but rather a feedback control that made the maximum block size that which
> > generated the most fees.
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters. Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.
>
> I believe the idea of a hard upper limit has become rather politicised
> but is essential to the security model of bitcoin.
>
> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?". Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.
>
> Whilst the exact number may be up for discussion, I would propose an
> initial upper limit of 8MB, so under my proposal the blocksize would
> be flexible between 1MB and 8MB.
>
> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.
>
> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?
> _______________________________________________
> 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/20150829/ec6361bf/attachment-0001.html>

2023-06-07 19:37:21 CEST

- reply

📅 Original date posted:2015-08-22
📝 Original message:One thing it occurs to me (and I don't know if this has been suggested
before) we could do is separate the BIP process into at several distinct
areas:
1) Commit structure changes/consensus rule change proposals
- Consensus-building process (how are proposals debated, improved, vetted,
and selected)
- Update/deployment mechanisms for rule changes
- Specific hard fork proposals
- Specific soft fork proposals
2) Peer policies
- Seeding and discovery mechanisms
- Relay policies
- p2p message support
3) RPC
4) Everything else
On Sat, Aug 22, 2015, 6:28 PM Eric Lombrozo <elombrozo at gmail.com> wrote:
> I've been pushing for greater modularization since I first got into
> bitcoin. I got quickly frustrated when I was only able to get through very
> few things (i.e. moving core structure serialization classes to a separate
> unit not called main). Working on Bitcoin has an added layer of frustration
> that goes beyond most open source projects: even though we're clearly in
> userland working at the application layer, a good layered protocol design
> is still lacking. We have no standards process separate from what basically
> amount to updates to one specific reference implementation. And we all need
> to agree on any major change, since a blockchain that is easily forked in
> contentious ways pretty much defeats its own purpose.
>
> I went off to develop my own stack, where I could more easily avoid
> politics and focus on engineering. But I now understand the politics are
> inevitable. Bitcoin is inherently a cooperative project. Several people
> have poured themselves passionately into the reference codebase, most of
> whom did it (at least initially) purely as unpaid volunteers. There's a lot
> of love that's gone into this. But it's become pretty clear that the
> modularization is no longer merely a matter of good engineering - it is
> essential to resolving serious political challenges.
>
> Perhaps the most frustrating thing of all is watching people pushing for
> relatively superficial yet highly controversial changes while we still lack
> the proper infrastructure to handle these kinds of divergences of opinion
> without either stagnating or becoming polarized.
>
> I could continue working to reimplement an entire stack from scratch, as
> several others have also done - but besides the serious effort duplication
> this entails, it doesn't really seem like it will ultimately be a
> convergent process. It's too easy to let ego and habit dictate one's
> preferences rather than rational engineering considerations.
>
> I know that some might feel I'm just preaching to the choir, but we should
> probably take a step back from implementation hackery and try to specify
> some core protocol layers, focusing on interfaces. Specifically, we need a
> consensus layer that doesn't try to specify networking, storage, wallets,
> UI, etc. Let different people improve upon these things independently in
> their own implementations. What matters is that we all converge on a common
> history and state. At the same time, let's open up more competition on all
> these other things that are separate from the consensus layer.
>
> If only we were to dedicate a fraction of the effort we've put into this
> whole block size circus into what's actually important...and I blame myself
> as well...
>
> On Sat, Aug 22, 2015, 4:05 AM Tamas Blummer via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Aug 21, 2015, at 21:46, Jorge Timón <jtimon at jtimon.cc> wrote:
>>
>> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer <tamas at bitsofproof.com>
>> wrote:
>>
>> Every re-implementation, re-factoring even copy-paste introduces a risk
>> of disagreement,
>> but also open the chance of doing the work better, in the sense of
>> software engineering.
>>
>>
>> But you don't want something better, you want something functionally
>> identical.
>> You may want to watch sipa's explanation on why "the implementation is
>> the specification" and the reasons to separate libconsensus:
>> https://youtu.be/l3O4nh79CUU?t=764
>>
>>
>> I do want something better, but not for the focus you have.
>>
>> Not because what you produce was not high quality, but because quality is
>> achieved at a very
>> high cost and is hard to uphold over generations of developer. You focus
>> on a single use case
>> while there are many out there for distributed ledgers.
>>
>> I think in an infrastructure for enterprise applications, building
>> consensus on the ledger is a
>> cornerstone there, but is only a piece of the solution. I built several
>> commercially successful
>> deployments where I delegated the consensus building to a border router,
>> a Bitcoin Core,
>> then interfaced that trusted peer with my implementation that accepted
>> Core’s decisions
>> in an SPV manner. One might think of this setup as wasteful and
>> unsuitable for “small devices”
>> therefore an example of centralization people here try to avoid.
>>
>> Enterprises have sufficient resources. Solving the business problem is
>> valuable to them even at
>> magnitudes higher cost than a hobbyist would bear.
>>
>> For mainstream adoption you need to get enterprises on board too, and
>> that is what I care of.
>> Enterprises want code that is not only high quality, but is easy to
>> maintain with a development
>> team with high attrition. One has to take whatever help is offered for
>> that, and one is modern
>> languages and runtimes.
>>
>> Bits of Proof’s own implementation of the scripts was not practically
>> relevant in my commercially
>> successful deployments, because of the use of a border router, but it
>> helped development,
>> enabling easier debug and precise error feedback esp. end even after Core
>> had a reject message.
>>
>> I integrated libconsensus only for the hope that is significantly fastens
>> application side tx verification,
>> which it has turned out it does not, until secp265k1 is integrated.
>>
>> I would likely use an other extended libconsensus too, but do not think
>> there was a dependency on
>> that for enterprise development.
>>
>> It would help there more to have a slim protocol server, no wallet, no
>> rpc, no qt but a high
>> performance remoting API.
>>
>> Since you already depend on libconsensus for VerifyScript, wouldn't it
>> be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
>> You would still have complete control over storage, concurrency,
>> networking, policy...
>> My plan is for the C API to interface with the external storage by
>> passing a function pointer to it.
>>
>>
>> Storage and validation is non-trivially interconnected, but I now the
>> separation can be done,
>> since I did it.
>>
>> Excuse me, but function pointers is a pattern I used in the 80’s. I know
>> that they are behind
>> the curtain of modern abstractions with similar use, I still prefer not
>> to see them again.
>>
>> Tamas Blummer
>>
>> _______________________________________________
>> 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/20150823/5c51283b/attachment.html>

2023-06-07 19:37:20 CEST

- reply

📅 Original date posted:2015-08-22
📝 Original message:I've been pushing for greater modularization since I first got into
bitcoin. I got quickly frustrated when I was only able to get through very
few things (i.e. moving core structure serialization classes to a separate
unit not called main). Working on Bitcoin has an added layer of frustration
that goes beyond most open source projects: even though we're clearly in
userland working at the application layer, a good layered protocol design
is still lacking. We have no standards process separate from what basically
amount to updates to one specific reference implementation. And we all need
to agree on any major change, since a blockchain that is easily forked in
contentious ways pretty much defeats its own purpose.
I went off to develop my own stack, where I could more easily avoid
politics and focus on engineering. But I now understand the politics are
inevitable. Bitcoin is inherently a cooperative project. Several people
have poured themselves passionately into the reference codebase, most of
whom did it (at least initially) purely as unpaid volunteers. There's a lot
of love that's gone into this. But it's become pretty clear that the
modularization is no longer merely a matter of good engineering - it is
essential to resolving serious political challenges.
Perhaps the most frustrating thing of all is watching people pushing for
relatively superficial yet highly controversial changes while we still lack
the proper infrastructure to handle these kinds of divergences of opinion
without either stagnating or becoming polarized.
I could continue working to reimplement an entire stack from scratch, as
several others have also done - but besides the serious effort duplication
this entails, it doesn't really seem like it will ultimately be a
convergent process. It's too easy to let ego and habit dictate one's
preferences rather than rational engineering considerations.
I know that some might feel I'm just preaching to the choir, but we should
probably take a step back from implementation hackery and try to specify
some core protocol layers, focusing on interfaces. Specifically, we need a
consensus layer that doesn't try to specify networking, storage, wallets,
UI, etc. Let different people improve upon these things independently in
their own implementations. What matters is that we all converge on a common
history and state. At the same time, let's open up more competition on all
these other things that are separate from the consensus layer.
If only we were to dedicate a fraction of the effort we've put into this
whole block size circus into what's actually important...and I blame myself
as well...
On Sat, Aug 22, 2015, 4:05 AM Tamas Blummer via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Aug 21, 2015, at 21:46, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer <tamas at bitsofproof.com>
> wrote:
>
> Every re-implementation, re-factoring even copy-paste introduces a risk of
> disagreement,
> but also open the chance of doing the work better, in the sense of
> software engineering.
>
>
> But you don't want something better, you want something functionally
> identical.
> You may want to watch sipa's explanation on why "the implementation is
> the specification" and the reasons to separate libconsensus:
> https://youtu.be/l3O4nh79CUU?t=764
>
>
> I do want something better, but not for the focus you have.
>
> Not because what you produce was not high quality, but because quality is
> achieved at a very
> high cost and is hard to uphold over generations of developer. You focus
> on a single use case
> while there are many out there for distributed ledgers.
>
> I think in an infrastructure for enterprise applications, building
> consensus on the ledger is a
> cornerstone there, but is only a piece of the solution. I built several
> commercially successful
> deployments where I delegated the consensus building to a border router, a
> Bitcoin Core,
> then interfaced that trusted peer with my implementation that accepted
> Core’s decisions
> in an SPV manner. One might think of this setup as wasteful and unsuitable
> for “small devices”
> therefore an example of centralization people here try to avoid.
>
> Enterprises have sufficient resources. Solving the business problem is
> valuable to them even at
> magnitudes higher cost than a hobbyist would bear.
>
> For mainstream adoption you need to get enterprises on board too, and
> that is what I care of.
> Enterprises want code that is not only high quality, but is easy to
> maintain with a development
> team with high attrition. One has to take whatever help is offered for
> that, and one is modern
> languages and runtimes.
>
> Bits of Proof’s own implementation of the scripts was not practically
> relevant in my commercially
> successful deployments, because of the use of a border router, but it
> helped development,
> enabling easier debug and precise error feedback esp. end even after Core
> had a reject message.
>
> I integrated libconsensus only for the hope that is significantly fastens
> application side tx verification,
> which it has turned out it does not, until secp265k1 is integrated.
>
> I would likely use an other extended libconsensus too, but do not think
> there was a dependency on
> that for enterprise development.
>
> It would help there more to have a slim protocol server, no wallet, no
> rpc, no qt but a high
> performance remoting API.
>
> Since you already depend on libconsensus for VerifyScript, wouldn't it
> be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
> You would still have complete control over storage, concurrency,
> networking, policy...
> My plan is for the C API to interface with the external storage by
> passing a function pointer to it.
>
>
> Storage and validation is non-trivially interconnected, but I now the
> separation can be done,
> since I did it.
>
> Excuse me, but function pointers is a pattern I used in the 80’s. I know
> that they are behind
> the curtain of modern abstractions with similar use, I still prefer not to
> see them again.
>
> Tamas Blummer
>
> _______________________________________________
> 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/20150823/ce97f084/attachment-0001.html>

2023-06-07 19:36:39 CEST

- reply

📅 Original date posted:2015-08-18
📝 Original message:I’m 100% in favor of attempting a hard fork using a far less controversial, far less risky consensus rule change. We should stop wasting our energy arguing over stuff we don’t really know and understand and can’t predict very well - and we should especially avoid using a highly contentious change as our first hard fork deployment.
I’m also in favor of trying a small block increase before attempting any major jumps. I don’t think we should be focusing so much on long-term block size adjustment rules right now - much more critical is to develop a hard fork mechanism and to make sure we can deploy it. So something along these lines is probably a step in the right direction.
> On Aug 18, 2015, at 2:54 AM, jl2012 via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> As I understand, there is already a consensus among core dev that block size should/could be raised. The remaining questions are how, when, how much, and how fast. These are the questions for the coming Bitcoin Scalability Workshops but immediate consensus in these issues are not guaranteed.
>
> Could we just stop the debate for a moment, and agree to a scheduled experimental hardfork?
>
> Objectives (by order of importance):
>
> 1. The most important objective is to show the world that reaching consensus for a Bitcoin hardfork is possible. If we could have a successful one, we would have more in the future
>
> 2. With a slight increase in block size, to collect data for future hardforks
>
> 3. To slightly relieve the pressure of full block, without minimal adverse effects on network performance
>
> With the objectives 1 and 2 in mind, this is to NOT intended to be a kick-the-can-down-the-road solution. The third objective is more like a side effect of this experiment.
>
>
> Proposal (parameters in ** are my recommendations but negotiable):
>
> 1. Today, we all agree that some kind of block size hardfork will happen on t1=*1 June 2016*
>
> 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will adopt the backup plan
>
> 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
>
> 4. If the backup plan is adopted, we all agree that a better solution should be found before t4=*31 Dec 2017*.
>
> Rationale:
>
> t1 = 1 June 2016 is chosen to make sure everyone have enough time to prepare for a hardfork. Although we do not know what actually will happen but we know something must happen around that moment.
>
> t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2 months after the workshops). If it is successful, we don't need to activate the backup plan
>
> t3 = 30 days is chosen to make sure every full nodes have enough time to upgrade after the actual hardfork date is confirmed
>
> t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate, hopefully we would find a better solution. It is important to acknowledge that the backup plan is not a final solution
>
> m = 80%: We don't want a very small portion of miners to have the power to veto a hardfork, while it is important to make sure the new fork is secured by enough mining power. 80% is just a compromise.
>
> s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all types of technology has since improved by >50%. I don't mind making it a bit smaller but in that case not much valuable data could be gathered and the second objective of this experiment may not be archived.
>
> --------------------
>
> If the community as a whole could agree with this experimental hardfork, we could announce the plan on bitcoin.org and start coding of the patch immediately. At the same time, exploration for a better solution continues. If no further consensus could be reached, a new version of Bitcoin Core with the patch will be released on or before 1 Feb 2016 and everyone will be asked to upgrade immediately.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/2907805f/attachment.sig>

2023-06-07 19:36:09 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:> On Aug 17, 2015, at 8:03 AM, Levin Keller <post at levinkeller.de> wrote:
>
> Dear Eric,
>
> thank you for sharing your thoughts.
>
> It obviously boils down to political beliefs, not so much technical arguments. I understand that you are in favor of a "guided decentralization" and you are most happily invited to follow this path. I don't want to be on it. I want total decentralisation of bitcoin and many other parts of the current system.
I specifically asked you to stop misrepresenting - I’m NOT in favor of guided decentralization, I never said anything like that. *THIS* is the problem…you’re reading intentions into others that simply are NOT there. If you don’t really understand something, ask.
I want complete decentralization - but for practical reasons, which should be obvious, we cannot start at this point. Bitcoin came into existence because Satoshi wrote a whitepaper and implemented the idea - and it was his rules. There was no voting, no committee, no proof-of-work, no nothing…it was a complete dictatorship in the beginning.
>
> So in the end the hard fork might be perfect, because people like you will not waste so much more energy and time fighting people like me (and others) who are following different dogmata because we are using different coins and talking about different code. Interestingly enough in the end we will probably have a winner - determined by the price - so I am looking forward to the outcome. It is just the time so make some bets, which I embrace.
>
> Another interesting thing is, that you actually fear problems arising from this. What do you have to loose? Just stick with the old bitcoin version and weather this storm. Bitcoin is not going to vanish or break from this. It is just forking. One fork will come stronger out of this. You just have to choose a side and live with it, if you loose it all. But that is the story of bitcoin since the beginning. If you ask me, you fear the choice, not the change.
>
Again, misrepresentation - “you fear the choice, not the change” - why should anyone ask *you* what I fear? Why don’t you ask *me*?
> Cheers
>
> Levin
>
> Adam Back via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> schrieb am Mo., 17. Aug. 2015 um 16:37 Uhr:
> Thank you Eric for saying what needs to be said.
>
> Starting a fork war is just not constructive and there are multiple
> proposals being evaluated here.
>
> I think that one thing that is not being so much focussed on is
> Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on
> Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
> SPV nodes that did not opt-in. It exposes those SPV nodes to loss in
> the likely event that Bitcoin-XT results in a network-split.
>
> The recent proposal here to run noXT (patch to falsely claim to mine
> on XT while actually rejecting it's blocks) could add enough
> uncertainty about the activation that Bitcoin-XT would probably have
> to be aborted.
>
> Adam
>
> On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> > NxtChg,
> >
> > In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here.
> >
> > Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so.
> >
> > This inability is not due to any malice on anyone’s part…it is a feature of Satoshi’s protocol. For better or worse, it is *very hard* to change the rules…and this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone.
> >
> > We’ve managed to have a few soft forks in the past…and for the most part these changes have been pretty uncontroversial…or at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we’ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix.
> >
> > Again, we have NEVER attempted anything even remotely like what’s being proposed - we’ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!?
> >
> > I can understand that some people would like bigger blocks. Other people might want feature X, others feature Y…and we can argue the merits of this or that to death…but the fact remains that we have NEVER attempted any hard forking change…not even with a simple, totally uncontroversial no-brainer improvement that would not risk any sort of ill-will that could hamper remedies were it not to go as smoothly as we like. *THIS* is the fundamental problem - the whole bigger block thing is a minor issue by comparison…it could be any controversial change, really.
> >
> > Would you want to send your test pilots on their first flight…the first time an aircraft is ever flown…directly into combat without having tested the plane? This is what attempting a hard fork mechanism that’s NEVER been done before in such a politically divisive environment basically amounts to…but it’s even worse. We’re basically risking the entire air force (not just one plane) over an argument regarding how many seats a plane should have that we’ve never flown before.
> >
> > We’re talking billlions of dollars’ worth of other people’s money that is on the line here. Don’t we owe it to them to at least test out the system on a far less controversial, far less divisive change first to make sure we can even deploy it without things breaking? I don’t even care about the merits regarding bigger blocks vs. smaller blocks at this point, to be quite honest - that’s such a petty thing compared to what I’m talking about here. If we attempt a novel hard-forking mechanism that’s NEVER been attempted before (and which as many have pointed out is potentially fraught with serious problems) on such a politically divisive, polarizing issue, the result is each side will refuse to cooperate with the other out of spite…and can easily lead to a war, tanking the value of everyone’s assets on both chains. All so we can process 8 times the number of transactions we currently do? Even if it were 100 times, we wouldn’t even come close to touching big payment processors like Visa. It’s hard to imagine a protocol improvement that’s worth the risk.
> >
> > I urge you to at least try to see the bigger picture here…and to understand that nobody is trying to stop anyone from doing anything out of some desire for maintaining control - NONE of us are able to deploy hard forks right now without facing these problems. And different people obviously have different priorities and preferences as to which of these changes would be best to do first. This whole XT thing is essentially giving *one* proposal special treatment above those that others have proposed. Many of us have only held back from doing this out of our belief that goodwill amongst network participants is more important than trying to push some pet feature some of us want.
> >
> > Please stop this negativity - we ALL want the best for Bitcoin and are doing our best, given what we understand and know, to do what’s right.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/9868e4bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/9868e4bd/attachment.sig>

2023-06-07 19:36:07 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:Levin,
The hope is that eventually the network will be sufficiently resilient and robust to be able to handle anything that’s thrown at it. But it’s still a baby…and this is a serious problem indeed, because on the one hand we don’t want any central authority but on the other it still needs some guardians…and we don’t have anything resembling the kind of institution that could possibly be entrusted to nurture and care for this baby until it is ready to go out on its own.
Imagine, when the US Constitution was being written, if suddenly everyone started to just propose their own different version of it and insisting (under threat of fork) on their own versions before any sort of government could be created. Yes, I know the US federal government is not exactly the paragon of decentralization…but regardless of your views on the US government, it’s still a somewhat analogous situation. Until the system was in place, some people (who at the time were unelected) had to bootstrap the process.
For better or worse, Satoshi has left the picture…and no clear succession model was put in place. The Bitcoin Foundation, which for a time attempted to be a guardian institution, ended up self-destructing. It was an utter failure.
We don’t have any sort of institution like this…and we don’t really want one. But the system is still not fully in place. Importantly, we lack any mechanisms to be able to make potentially controversial changes without serious risks.
It would be amazing if despite this trial-by-fire we still survived and managed to pull through. And if we do we’ll be stronger for it. But quite sincerely, I would have wanted the system to be a little more mature before putting it through this trial. At least I would have liked to have gone through a test hard-fork using a far less politically divisive issue.
Anyhow, completely separate from my views on governance, etc…my main point is that we’re ALL trying to do what’s best given our understanding and resources…and we’ve all poured our hearts and souls into this. We might disagree on certain things, but let’s stop this negativity and misrepresentation and try to figure out a way forward that is less likely to lead to a war.
- Eric
>
>
> Eric Lombrozo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> schrieb am Mo., 17. Aug. 2015 um 16:03 Uhr:
> NxtChg,
>
> In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here.
>
> Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so.
>
> This inability is not due to any malice on anyone’s part…it is a feature of Satoshi’s protocol. For better or worse, it is *very hard* to change the rules…and this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone.
>
> We’ve managed to have a few soft forks in the past…and for the most part these changes have been pretty uncontroversial…or at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we’ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix.
>
> Again, we have NEVER attempted anything even remotely like what’s being proposed - we’ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!?
>
> I can understand that some people would like bigger blocks. Other people might want feature X, others feature Y…and we can argue the merits of this or that to death…but the fact remains that we have NEVER attempted any hard forking change…not even with a simple, totally uncontroversial no-brainer improvement that would not risk any sort of ill-will that could hamper remedies were it not to go as smoothly as we like. *THIS* is the fundamental problem - the whole bigger block thing is a minor issue by comparison…it could be any controversial change, really.
>
> Would you want to send your test pilots on their first flight…the first time an aircraft is ever flown…directly into combat without having tested the plane? This is what attempting a hard fork mechanism that’s NEVER been done before in such a politically divisive environment basically amounts to…but it’s even worse. We’re basically risking the entire air force (not just one plane) over an argument regarding how many seats a plane should have that we’ve never flown before.
>
> We’re talking billlions of dollars’ worth of other people’s money that is on the line here. Don’t we owe it to them to at least test out the system on a far less controversial, far less divisive change first to make sure we can even deploy it without things breaking? I don’t even care about the merits regarding bigger blocks vs. smaller blocks at this point, to be quite honest - that’s such a petty thing compared to what I’m talking about here. If we attempt a novel hard-forking mechanism that’s NEVER been attempted before (and which as many have pointed out is potentially fraught with serious problems) on such a politically divisive, polarizing issue, the result is each side will refuse to cooperate with the other out of spite…and can easily lead to a war, tanking the value of everyone’s assets on both chains. All so we can process 8 times the number of transactions we currently do? Even if it were 100 times, we wouldn’t even come close to touching big payment processors like Visa. It’s hard to imagine a protocol improvement that’s worth the risk.
>
> I urge you to at least try to see the bigger picture here…and to understand that nobody is trying to stop anyone from doing anything out of some desire for maintaining control - NONE of us are able to deploy hard forks right now without facing these problems. And different people obviously have different priorities and preferences as to which of these changes would be best to do first. This whole XT thing is essentially giving *one* proposal special treatment above those that others have proposed. Many of us have only held back from doing this out of our belief that goodwill amongst network participants is more important than trying to push some pet feature some of us want.
>
> Yadayadayada.
>
> If someone could threaten the network by releasing a hard-forking bitcoind version, then already all is lost. Bitcoins stability does not (and cannot) depend on the "good will" of anyone. If it would, we should all abandon this silly project. Relying on the good will of people is the worst idea one could have.
>
> So please (please please) go ahead and release your hardforking bitcoinds you have been holding back. Competition is everything.
>
> Cheers
>
> Levin
>
>
> Please stop this negativity - we ALL want the best for Bitcoin and are doing our best, given what we understand and know, to do what’s right.
>
>
>
> > On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >
> >> We should have the highest respect for what these people are doing, and we should try to do something constructive, not waste time with anger and disrespect.
> >
> > Why, exactly, should I have any respect for what these people are doing (and supposedly not have any respect for what the other side is doing)?
> >
> > From my point of view, the XT side _does_ something constructive. It's the Core side that resorts to dirty tactics and tries to sabotage community's free choice instead.
> >
> >
> >> Nobody should be forced to do anything.
> >
> > Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin?
> >
> > Let users decide what Bitcoin is or isn't.
> >
> >
> >> The developers are not telling you what to do, they are trying to do what they consider is best for the ecosystem given their technical abilities.
> >
> > The developers & Co are doing their best to stay in power, so they could continue imposing their will on Bitcoin ecosystem. This is the real power grab, not Gavin and Hearn, who merely provided an alternative.
> >
> > And the fear they show is most telling.
> >
> > _______________________________________________
> > 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/72a1acb8/attachment-0001.sig>

2023-06-07 19:36:06 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:NxtChg,
In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here.
Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so.
This inability is not due to any malice on anyone’s part…it is a feature of Satoshi’s protocol. For better or worse, it is *very hard* to change the rules…and this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone.
We’ve managed to have a few soft forks in the past…and for the most part these changes have been pretty uncontroversial…or at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we’ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix.
Again, we have NEVER attempted anything even remotely like what’s being proposed - we’ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!?
I can understand that some people would like bigger blocks. Other people might want feature X, others feature Y…and we can argue the merits of this or that to death…but the fact remains that we have NEVER attempted any hard forking change…not even with a simple, totally uncontroversial no-brainer improvement that would not risk any sort of ill-will that could hamper remedies were it not to go as smoothly as we like. *THIS* is the fundamental problem - the whole bigger block thing is a minor issue by comparison…it could be any controversial change, really.
Would you want to send your test pilots on their first flight…the first time an aircraft is ever flown…directly into combat without having tested the plane? This is what attempting a hard fork mechanism that’s NEVER been done before in such a politically divisive environment basically amounts to…but it’s even worse. We’re basically risking the entire air force (not just one plane) over an argument regarding how many seats a plane should have that we’ve never flown before.
We’re talking billlions of dollars’ worth of other people’s money that is on the line here. Don’t we owe it to them to at least test out the system on a far less controversial, far less divisive change first to make sure we can even deploy it without things breaking? I don’t even care about the merits regarding bigger blocks vs. smaller blocks at this point, to be quite honest - that’s such a petty thing compared to what I’m talking about here. If we attempt a novel hard-forking mechanism that’s NEVER been attempted before (and which as many have pointed out is potentially fraught with serious problems) on such a politically divisive, polarizing issue, the result is each side will refuse to cooperate with the other out of spite…and can easily lead to a war, tanking the value of everyone’s assets on both chains. All so we can process 8 times the number of transactions we currently do? Even if it were 100 times, we wouldn’t even come close to touching big payment processors like Visa. It’s hard to imagine a protocol improvement that’s worth the risk.
I urge you to at least try to see the bigger picture here…and to understand that nobody is trying to stop anyone from doing anything out of some desire for maintaining control - NONE of us are able to deploy hard forks right now without facing these problems. And different people obviously have different priorities and preferences as to which of these changes would be best to do first. This whole XT thing is essentially giving *one* proposal special treatment above those that others have proposed. Many of us have only held back from doing this out of our belief that goodwill amongst network participants is more important than trying to push some pet feature some of us want.
Please stop this negativity - we ALL want the best for Bitcoin and are doing our best, given what we understand and know, to do what’s right.
> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>> We should have the highest respect for what these people are doing, and we should try to do something constructive, not waste time with anger and disrespect.
>
> Why, exactly, should I have any respect for what these people are doing (and supposedly not have any respect for what the other side is doing)?
>
> From my point of view, the XT side _does_ something constructive. It's the Core side that resorts to dirty tactics and tries to sabotage community's free choice instead.
>
>
>> Nobody should be forced to do anything.
>
> Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin?
>
> Let users decide what Bitcoin is or isn't.
>
>
>> The developers are not telling you what to do, they are trying to do what they consider is best for the ecosystem given their technical abilities.
>
> The developers & Co are doing their best to stay in power, so they could continue imposing their will on Bitcoin ecosystem. This is the real power grab, not Gavin and Hearn, who merely provided an alternative.
>
> And the fear they show is most telling.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/a19448ab/attachment-0001.sig>

2023-06-07 19:35:53 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:FWIW,
I would fully like to see the consensus stuff split off into a separate organization from everything else. Let XT continue to support additional p2p messages or relay policies or whatever. Let Mike and Gavin argue for their improved wallet or whatever - I have absolutely no problem with that.
But the consensus code should NOT be subject to the same commit policies…and we should make an effort to separate the two clearly. And we should find a way to communicate the difference succinctly and clearly to laypeople (which is something I think the XT opponents have been horrible at doing so far).
> On Aug 19, 2015, at 12:58 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Wed, Aug 19, 2015 at 9:48 PM, Eric Lombrozo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> [...]
>> core devs” and relying on the fact that many people out there can’t seem to
>> tell the difference between a source code fork and a blockchain fork.
>
> And this is precisely why we should make perfectly clear that we're
> not against a code fork where Hearn or anyone else acts as a
> "benevolent dictator", just against the controversial hardfork it is
> attempting to deploy.
> Otherwise the PR battle is probably lost (which may mean users sell
> all their BTC for XTBTC [or just forget about their BTC and only care
> about their XTBTC]).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/a80020c5/attachment.sig>

2023-06-07 19:35:52 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:Unfortunately, I think that from a PR angle, removing Gavin from commit privileges right now will probably play into his hand. Sadly.
Say what you will regarding Gavin and Mike’s technical merits, they’ve been quite clever on the PR front. Framing this issue as “obstructionism from the core devs” and relying on the fact that many people out there can’t seem to tell the difference between a source code fork and a blockchain fork.
> On Aug 19, 2015, at 12:32 PM, odinn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Signed PGP part
> re. Gavin and commit access
>
> On 08/19/2015 12:15 PM, Btc Drak via bitcoin-dev wrote:
> > On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd <pete at petertodd.org>
> > wrote:
> >> Normal GitHub users submitting pull-reqs to Bitcoin Core can't
> >> delete other users' comments on their own pull-reqs...
> >>
> >> IMO that's an abuse of the pull-req process, and in turn, Gavin
> >> Andresens's commit access rights for the Bitcoin Core repo.
> >
> > For the avoidance of doubt here's the archive link of my comment
> > https://archive.is/omvSY#40% (call me paranoid) and here's where he
> > tells me he's censored my posts https://archive.is/vym6N#40%
> >
> >> I think this should weigh in favor of Gavin Andresen not having
> >> commit privileges for the Bitcoin Core repository.
> >
> > It's time.
>
> I agree, fwiw. If he's going to censor others then that's
> inconsistent with the responsibility of having commit access.
>
> > _______________________________________________ bitcoin-dev mailing
> > list bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
>
> _______________________________________________
> 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/20150819/7a3d69e9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/7a3d69e9/attachment.sig>

2023-06-07 19:35:30 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:Or can’t you create a transaction that’s still within the op count and sig ops limits but is larger than 1MB?
> On Aug 17, 2015, at 5:29 AM, Andrew LeCody via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Wouldn't that require a fork that lasts for more than 100 blocks?
>
> On Mon, Aug 17, 2015, 01:43 Peter Todd <pete at petertodd.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>>
>>
>> On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> There are a few ways: here is my favorite (for the moment).
>>>
>>> 1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet
>>> 'BitcoinXT'
>>
>> Even more direct: use coinbase outputs of XT blocks to create those
>> outputs, as they can't by definition be on the Bitcoin chain.
>>
>> If you can't get those, using coinbase outputs of Bitcoin blocks to create
>> "definitely Bitcoin-only" outputs, and then spend the inputs to those
>> transactions again on the XT chain. This isn't quite as good, as a big
>> reorg on the XT chain could in theory spend them, but it's a close second.
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YIS
>> AAoJEMCF8hzn9Lnc47AH/R9EaGaa0xmD7qBODGUwX3SsDde7DMgO4t8X5GQ9uoaq
>> qcjdnnvdeXjy5S39QdZFJjlH5bGn+BJy2wIxn0lMciKhEGIFOGeCUsMYEbgnOc03
>> cLuyYpxdfXe4Amoxf2mqADgBqkAckf4cX6bMm3XXg+v3XAby2llydIGIydTwGWYq
>> 2KwXl9U9zm7UV8b5tJ7WmItCAcZAvTcSoX5SerOmPjjrmLtPTHThj8SfLTGAoWfT
>> EXsSGkDBJ/9rJMms56FjciWsXHlB9pYK0a1sxh88PJluebqh99imDisJvATCVp2Z
>> kZX1keZ1nyfG45jibgt6dlY97wU0n919SmQz0Tg6g90=
>> =OD56
>> -----END PGP SIGNATURE-----
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/b131b04c/attachment.sig>

2023-06-07 19:35:19 CEST

- reply

📅 Original date posted:2015-08-15
📝 Original message:Please take the lightning 101 discussion to another thread.
The main point I was trying to make was that Mike is clearly misrepresenting the views of a great number of people who have deep, intimate knowledge of how things work and are almost certainly not primarily motivated by their own potential for profits.
> On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Being an early hub provider would be an obvious place to start capitalizing on lightning. Early lightning adopters would be in the best position to do this.
>
> Long term, Bitcoin needs to scale the blockchain in a reasonable manner and implement things like lightning.
>
> Limiting the blocksize is a blatant conflict of interest because it creates artificial demand for lightning that would not otherwise exist if the blockchain scaled in a reasonable manner.
>
> On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach <mark at friedenbach.org <mailto:mark at friedenbach.org>> wrote:
> I would like very much to know how it is that we're supposed to be making money off of lightning, and therefore how it represents a conflict of interest. Apparently there is tons of money to be made in releasing open-source protocols! I would hate to miss out on that.
>
> We are working on lightning because Mike of all people said, essentially, " if you're so fond of micro payment channels, why aren't you working on them?" And he was right! So we looked around and found the best proposal and funded it.
>
> On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> I know full well who works for Blockstream and I know you're not one of those folks. The Blockstream core devs are very vocal against a reasonable blocksize increase (17% growth per year in Pieter's BIP is not what I consider reasonable because it doesn't come close to keeping with technological increases). I think we can both agree that more on-chain space means less demand for lightning, and vice versa, which is a blatant conflict of interest.
>
> I'm also trying to figure out how things like lightning are not competing directly with miners for fees. More off-chain transactions means less blockchain demand, which would lower on-chain fees. I'm not sure what is controversial about that statement.
>
> The lightning network concept is actually a brilliant way to take fees away from miners without having to make any investment at all in SSH-256 ASIC mining hardware.
>
> On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo <elombrozo at gmail.com <mailto:elombrozo at gmail.com>> wrote:
>
>> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> What are you so afraid of, Eric? If Mike's fork is successful, consensus is reached around larger blocks. If it is rejected, the status quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the only thing that matters, and those that go against network consensus will be severely punished with complete loss of income.
>
> I fully agree that core developers are not the only people who should have a say in this. But again, we’re not talking about merely forking some open source project - we’re talking about forking a ledger representing real assets that real people are holding…and I think it’s fair to say that the risk of permanent ledger forks far outweighs whatever benefits any change in the protocol might bring. And this would be true even if there were unanimous agreement that the change is good (which there clearly IS NOT in this case) but the deployment mechanism could still break things.
>
> If anything we should attempt a hard fork with a less contentious change first, just to test deployability.
>
>> I'm not sure who appointed the core devs some sort of Bitcoin Gods that can hold up any change that they happen to disagree with. It seems like the core devs are scared to death that the bitcoin network may change without their blessing, so they go on and on about how terrible hard forks are. Hard forks are the only way to keep core devs in check.
>
> Again, let’s figure out a hard fork mechanism and test it with a far less contentious change first
>
>> Despite significant past technical bitcoin achievements, two of the most vocal opponents to a reasonable blocksize increase work for a company (Blockstream) that stands to profit directly from artificially limiting the blocksize. The whole situation reeks. Because of such a blatant conflict of interest, the ethical thing to do would be for them to either resign from Blockstream or immediately withdraw themselves from the blocksize debate. This is the type of stuff that I hoped would end with Bitcoin, but alas, I guess human nature never changes.
>
> For the record, I do not work for Blockstream. Neither do a bunch of other people who have published a number of concerns. Very few of the concerns I’ve seen from the technical community seem to be motivated primarily by profit motives.
>
> It should also be pointed out that *not* making drastic changes is the default consensus policy…and the burden of justifying a change falls on those who want to make the change. Again, the risk of permanent ledger forks far outweighs whatever benefits protocol changes might bring.
>
>> Personally, I think miners should give Bitcoin XT a serious look. Miners need to realize that they are in direct competition with the lightning network and sidechains for fees. Miners, ask yourselves if you think you'll earn more fees with 1 MB blocks and more off-chain transactions or with 8 MB blocks and more on-chain transactions…
>
> Miners are NOT in direct competition with the lightning network and sidechains - these claims are patently false. I recommend you take a look at these ideas and understand them a little better before trying to make any such claims. Again, I do not work for Blockstream…and my agenda in this post is not to promote either of these ideas…but with all due respect, I do not think you properly understand them at all.
>
>> The longer this debate drags on, the more I agree with BIP 100 and Jeff Garzik because the core devs are already being influenced by outside forces and should not have complete control of the blocksize. It's also interesting to note that most of the mining hashpower is already voting for 8MB blocks BIP100 style.
>
> I don’t think the concern here is so much that some people want to increase block size. It’s the *way* in which this change is being pushed that is deeply problematic.
>
>> On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> You deeply disappoint me, Mike.
>>
>> Not only do you misrepresent many cogent, well thought out positions from a great number of people who have published and posted a number of articles detailing an explaining in-depth technical concerns…you also seem to fancy yourself more capable of reading into the intentions of someone who disappeared from the scene years ago, before we even were fully aware of many things we now know that bring the original “plan” into question.
>>
>> I ask of you, as a civilized human being, to stop doing this divisive crap. Despite your protestations to the contrary, YOU are the one who is proposing a radical departure from the direction of the project. Also, as several of us have clearly stated before, equating the fork of an open source project with a fork of a cryptoledger is completely bogus - there’s a lot of other people’s money at stake. This isn’t a democracy - consensus is all or nothing. The fact that a good number of the people most intimately familiar with the inner workings of Satoshi’s invention do not believe doing this is a good idea should give you pause.
>>
>> Please stop using Bitcoin as your own political football…for the sake of Bitcoin…and for your own sake. Despite your obvious technical abilities (and I sincerely do believe you have them) you are discrediting yourself and hurting your own reputation.
>>
>>
>> - Eric
>>
>>> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>
>>> Hello,
>>>
>>> As promised, we have released Bitcoin XT 0.11A which includes the bigger blocks patch set. You can get it from
>>>
>>> https://bitcoinxt.software/ <https://bitcoinxt.software/>
>>>
>>> I feel sad that it's come to this, but there is no other way. The Bitcoin Core project has drifted so far from the principles myself and many others feel are important, that a fork is the only way to fix things.
>>>
>>> Forking is a natural thing in the open source community, Bitcoin is not the first and won't be the last project to go through this. Often in forks, people say there was insufficient communication. So to ensure everything is crystal clear I've written a blog post and a kind of "manifesto" to describe why this is happening and how XT plans to be different from Core (assuming adoption, of course).
>>>
>>> The article is here:
>>>
>>> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1 <https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1>
>>>
>>> It makes no attempt to be neutral: this explains things from our point of view.
>>>
>>> The manifesto is on the website.
>>>
>>> I say to all developers on this list: if you also feel that Core is no longer serving the interests of Bitcoin users, come join us. We don't bite.
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <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/20150815/aad22d8e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/aad22d8e/attachment-0001.sig>

2023-06-07 19:35:15 CEST

- reply

📅 Original date posted:2015-08-15
📝 Original message:> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> What are you so afraid of, Eric? If Mike's fork is successful, consensus is reached around larger blocks. If it is rejected, the status quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the only thing that matters, and those that go against network consensus will be severely punished with complete loss of income.
I fully agree that core developers are not the only people who should have a say in this. But again, we’re not talking about merely forking some open source project - we’re talking about forking a ledger representing real assets that real people are holding…and I think it’s fair to say that the risk of permanent ledger forks far outweighs whatever benefits any change in the protocol might bring. And this would be true even if there were unanimous agreement that the change is good (which there clearly IS NOT in this case) but the deployment mechanism could still break things.
If anything we should attempt a hard fork with a less contentious change first, just to test deployability.
> I'm not sure who appointed the core devs some sort of Bitcoin Gods that can hold up any change that they happen to disagree with. It seems like the core devs are scared to death that the bitcoin network may change without their blessing, so they go on and on about how terrible hard forks are. Hard forks are the only way to keep core devs in check.
Again, let’s figure out a hard fork mechanism and test it with a far less contentious change first
> Despite significant past technical bitcoin achievements, two of the most vocal opponents to a reasonable blocksize increase work for a company (Blockstream) that stands to profit directly from artificially limiting the blocksize. The whole situation reeks. Because of such a blatant conflict of interest, the ethical thing to do would be for them to either resign from Blockstream or immediately withdraw themselves from the blocksize debate. This is the type of stuff that I hoped would end with Bitcoin, but alas, I guess human nature never changes.
For the record, I do not work for Blockstream. Neither do a bunch of other people who have published a number of concerns. Very few of the concerns I’ve seen from the technical community seem to be motivated primarily by profit motives.
It should also be pointed out that *not* making drastic changes is the default consensus policy…and the burden of justifying a change falls on those who want to make the change. Again, the risk of permanent ledger forks far outweighs whatever benefits protocol changes might bring.
> Personally, I think miners should give Bitcoin XT a serious look. Miners need to realize that they are in direct competition with the lightning network and sidechains for fees. Miners, ask yourselves if you think you'll earn more fees with 1 MB blocks and more off-chain transactions or with 8 MB blocks and more on-chain transactions…
Miners are NOT in direct competition with the lightning network and sidechains - these claims are patently false. I recommend you take a look at these ideas and understand them a little better before trying to make any such claims. Again, I do not work for Blockstream…and my agenda in this post is not to promote either of these ideas…but with all due respect, I do not think you properly understand them at all.
> The longer this debate drags on, the more I agree with BIP 100 and Jeff Garzik because the core devs are already being influenced by outside forces and should not have complete control of the blocksize. It's also interesting to note that most of the mining hashpower is already voting for 8MB blocks BIP100 style.
I don’t think the concern here is so much that some people want to increase block size. It’s the *way* in which this change is being pushed that is deeply problematic.
> On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> You deeply disappoint me, Mike.
>
> Not only do you misrepresent many cogent, well thought out positions from a great number of people who have published and posted a number of articles detailing an explaining in-depth technical concerns…you also seem to fancy yourself more capable of reading into the intentions of someone who disappeared from the scene years ago, before we even were fully aware of many things we now know that bring the original “plan” into question.
>
> I ask of you, as a civilized human being, to stop doing this divisive crap. Despite your protestations to the contrary, YOU are the one who is proposing a radical departure from the direction of the project. Also, as several of us have clearly stated before, equating the fork of an open source project with a fork of a cryptoledger is completely bogus - there’s a lot of other people’s money at stake. This isn’t a democracy - consensus is all or nothing. The fact that a good number of the people most intimately familiar with the inner workings of Satoshi’s invention do not believe doing this is a good idea should give you pause.
>
> Please stop using Bitcoin as your own political football…for the sake of Bitcoin…and for your own sake. Despite your obvious technical abilities (and I sincerely do believe you have them) you are discrediting yourself and hurting your own reputation.
>
>
> - Eric
>
>> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Hello,
>>
>> As promised, we have released Bitcoin XT 0.11A which includes the bigger blocks patch set. You can get it from
>>
>> https://bitcoinxt.software/ <https://bitcoinxt.software/>
>>
>> I feel sad that it's come to this, but there is no other way. The Bitcoin Core project has drifted so far from the principles myself and many others feel are important, that a fork is the only way to fix things.
>>
>> Forking is a natural thing in the open source community, Bitcoin is not the first and won't be the last project to go through this. Often in forks, people say there was insufficient communication. So to ensure everything is crystal clear I've written a blog post and a kind of "manifesto" to describe why this is happening and how XT plans to be different from Core (assuming adoption, of course).
>>
>> The article is here:
>>
>> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1 <https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1>
>>
>> It makes no attempt to be neutral: this explains things from our point of view.
>>
>> The manifesto is on the website.
>>
>> I say to all developers on this list: if you also feel that Core is no longer serving the interests of Bitcoin users, come join us. We don't bite.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <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/20150815/d2608081/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/d2608081/attachment.sig>

2023-06-07 19:35:14 CEST

- reply

📅 Original date posted:2015-08-15
📝 Original message:You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions from a great number of people who have published and posted a number of articles detailing an explaining in-depth technical concerns…you also seem to fancy yourself more capable of reading into the intentions of someone who disappeared from the scene years ago, before we even were fully aware of many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive crap. Despite your protestations to the contrary, YOU are the one who is proposing a radical departure from the direction of the project. Also, as several of us have clearly stated before, equating the fork of an open source project with a fork of a cryptoledger is completely bogus - there’s a lot of other people’s money at stake. This isn’t a democracy - consensus is all or nothing. The fact that a good number of the people most intimately familiar with the inner workings of Satoshi’s invention do not believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football…for the sake of Bitcoin…and for your own sake. Despite your obvious technical abilities (and I sincerely do believe you have them) you are discrediting yourself and hurting your own reputation.
- Eric
> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hello,
>
> As promised, we have released Bitcoin XT 0.11A which includes the bigger blocks patch set. You can get it from
>
> https://bitcoinxt.software/ <https://bitcoinxt.software/>
>
> I feel sad that it's come to this, but there is no other way. The Bitcoin Core project has drifted so far from the principles myself and many others feel are important, that a fork is the only way to fix things.
>
> Forking is a natural thing in the open source community, Bitcoin is not the first and won't be the last project to go through this. Often in forks, people say there was insufficient communication. So to ensure everything is crystal clear I've written a blog post and a kind of "manifesto" to describe why this is happening and how XT plans to be different from Core (assuming adoption, of course).
>
> The article is here:
>
> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1 <https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1>
>
> It makes no attempt to be neutral: this explains things from our point of view.
>
> The manifesto is on the website.
>
> I say to all developers on this list: if you also feel that Core is no longer serving the interests of Bitcoin users, come join us. We don't bite.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto: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/20150815/5381f7ae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/5381f7ae/attachment.sig>

2023-06-07 19:32:18 CEST

- reply

📅 Original date posted:2015-08-03
📝 Original message:Bah, I don’t know if you’re just trolling me, Hector…but I’ll give you the benefit of the doubt and act like you aren’t.
We already have much more efficient, far more scalable systems that allow this kind of cooperation you speak of without the inconveniences of blockchains and such. These incidents do, fortunately, present some of the better sides of humanity…but…the design of the network *broke* - and for reasons that are now well understood to be only worsened by larger blocks. These incidents are *not supposed to happen* - and if they do, it means we’ve botched something up and need to fix it. And by fix it, I mean fix the protocol so that given our best understanding of things in the present we can significantly reduce the potential for its occurrence in the future.
The correct incentives here were not due to people potentially losing a lot of money. The incentives here were well-intentioned altruism. Some miners lost money as a result of these actions…and they didn’t put up a fight. if you want to design a system around the assumption that this is how all such incidents will be resolved, please don’t spoil this for the rest of us.
- Eric
> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu at gmail.com> wrote:
>
> What's wrong with a little cooperation to resolve things now and then? Man is not an island unto himself, we compete with each other and we cooperate with each other occasionally if it's mutually beneficial.
>
> You said yourself that a lot of money would have been lost if the two hard forks cited weren't resolved - that's the correct incentives at work again.
>
> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo at gmail.com <mailto:elombrozo at gmail.com>> wrote:
> There have already been two notable incidents requiring manual intervention and good-faith cooperation between core devs and mining pool operators that would have either never gotten resolved alone or would have ended up costing a lot of people a lot of money had no action been taken (March 2013 and July 2015). They were both caused by consensus disagreement that directly or indirectly were brought about by bigger blocks. There is *strong* evidence…and a great deal of theory explaining it…that links larger blocks with the propensity for consensus forks that require manual intervention.
>
> Please, can we stop saying this is merely about decentralization and trustlessness? The very model upon which the security of the system is based *broke*…as in, we were only able to recover because a few individuals deliberately manipulated the consensus rules to fix it manually. Shouldn’t we more highly prioritize fixing the issues that can lead to these incidents than trying to increase throughput? Increasing block size cannot possibly make these forking tendencies better…but it very well could make them worse.
>
> - Eric
>
>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> On 3 August 2015 at 08:53, Adam Back <adam at cypherspace.org <mailto:adam at cypherspace.org>> wrote:
>> Again this should not be a political or business compromise model - we
>> must focus on scientific evaluation, technical requirements and
>> security.
>>
>> I will assert that the block size is political because it affects nearly all users to some degree and not all those users are technically inclined or care to keep decentralisation in the current configuration as you do. This debate has forgotten the current and future users of Bitcoin. Most of them think the hit to node count in the short term preferable to making it expensive and competitive to transact.
>>
>> We all need a little faith that the system will reorganise and readjust after the move to big blocks in a way that still has a reasonable degree of decentralisation and trustlessness. The incentives of Bitcoin remain, so everyone's decentralised decision throughout the system, from miners, merchants and users, will continue to act according to those incentives.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/1e3c6257/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/1e3c6257/attachment-0001.sig>

2023-06-07 17:49:18 CEST

- reply

2023-06-07 17:48:48 CEST

- reply

2023-06-07 17:48:47 CEST

- reply

📅 Original date posted:2015-08-21
📝 Original message:Unfortunately we have no way of rigorously proving functional equivalence
other than code review and unit testing. The simpler the consensus code
(and the more we can write it in a style that affords provability of
correctness) the easier it will be in the future to compare implementations.
Prior to swapping out implementations, we should at the least run it
through the gauntlet and perhaps run both implementations side-by-side.
All I/O should be treated abstractly in the API.
In C++ I really like using a nearly bare-bones signal template for most
async message handling, i.e.
https://github.com/ciphrex/mSIGNA/blob/master/deps/Signals/src/Signals.h
This greatly facilitates support for async bidirectional I/O, etc...with
minimal overhead.
But others might have other stylistic preferences.
- Eric
On Fri, Aug 21, 2015, 12:46 PM Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer <tamas at bitsofproof.com>
> wrote:
> > Every re-implementation, re-factoring even copy-paste introduces a risk
> of disagreement,
> > but also open the chance of doing the work better, in the sense of
> software engineering.
>
> But you don't want something better, you want something functionally
> identical.
> You may want to watch sipa's explanation on why "the implementation is
> the specification" and the reasons to separate libconsensus:
> https://youtu.be/l3O4nh79CUU?t=764
>
> >> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon at jtimon.cc> wrote:
> >>
> >>
> >> But the goal is not reimplementing the consensus rules but rather
> >> extract them from Bitcoin Core so that nobody needs to re-implement
> >> them again.
> >
> >
> >
> > My goal is different. Compatibility with Bitcoin is important as I also
> want to deal with Bitcoins,
> > but it is also imperative to be able to create and serve other block
> chains with other rules and for those
> > I do not want to carry on the legacy of an antique tool set and a
> spaghetti style.
> >
> > Bits of Proof uses scala (akka networking), java (api service), c++
> (leveledb and now libconsensus)
> > and I am eager to integrate secp256k1 (c) as soon as part of consensus.
> The choices were
> > made because each piece appears best in what they do.
>
> Since you already depend on libconsensus for VerifyScript, wouldn't it
> be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
> You would still have complete control over storage, concurrency,
> networking, policy...
> My plan is for the C API to interface with the external storage by
> passing a function pointer to 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/20150821/71b04009/attachment.html>

2023-06-07 17:48:41 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:Alex,
With all due respect, right now the biggest challenge facing Bitcoin is not technical but political. I would love to see this list go back to technical discussions, but unfortunately, until this political stuff is resolved, even technical discussion is purely philosophical as there’s little chance of actually making good progress on consensus…which in a space where everything depends on consensus pretty much makes everything else moot.
> On Aug 19, 2015, at 1:08 PM, Alex Morcos via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> This is a message that I wrote and had hoped that all the core devs would sign on to, but I failed to finish organizing it. So I'll just say it from myself.
>
> There has been a valuable discussion over the last several months regarding a hard fork with respect to block size. However the sheer volume of email and proportion of discussion that is more philosophical than technical has rendered this list almost unusable for its primary purpose of technical discussion related to Bitcoin development. Many of us share the blame for letting the discourse run off topic to such a degree, and we hope that an appeal for individual self restraint will allow this list to return to a higher signal-to-noise ratio.
> -Please consider the degree to which any email you send is related to technical development before sending it.
> -Please consider how many emails you are sending to this list regarding the same topic.
> This list is not appropriate for an endless back and forth debate on the philosophical underpinnings of Bitcoin. Although such a debate may be worthwhile it should be taken to another forum for discussion. Every email you send is received by hundreds of developers who value their time as much as you value yours. If your intended audience isn't really the majority of them, perhaps private communication would be more appropriate.
>
> Thanks,
> Alex
>
> _______________________________________________
> 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/20150819/35b4ec1b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/35b4ec1b/attachment.sig>

2023-06-07 17:47:47 CEST

- reply

2023-06-07 17:47:45 CEST

- reply

2023-06-07 17:47:44 CEST

- reply

2023-06-07 17:47:16 CEST

- reply

2023-06-07 17:47:09 CEST

- reply

2023-06-07 17:47:05 CEST

- reply

2023-06-07 17:47:04 CEST

- reply

2023-06-07 17:44:39 CEST

- reply

📅 Original date posted:2015-08-03
📝 Original message:There have already been two notable incidents requiring manual intervention and good-faith cooperation between core devs and mining pool operators that would have either never gotten resolved alone or would have ended up costing a lot of people a lot of money had no action been taken (March 2013 and July 2015). They were both caused by consensus disagreement that directly or indirectly were brought about by bigger blocks. There is *strong* evidence…and a great deal of theory explaining it…that links larger blocks with the propensity for consensus forks that require manual intervention.
Please, can we stop saying this is merely about decentralization and trustlessness? The very model upon which the security of the system is based *broke*…as in, we were only able to recover because a few individuals deliberately manipulated the consensus rules to fix it manually. Shouldn’t we more highly prioritize fixing the issues that can lead to these incidents than trying to increase throughput? Increasing block size cannot possibly make these forking tendencies better…but it very well could make them worse.
- Eric
> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 3 August 2015 at 08:53, Adam Back <adam at cypherspace.org <mailto:adam at cypherspace.org>> wrote:
> Again this should not be a political or business compromise model - we
> must focus on scientific evaluation, technical requirements and
> security.
>
> I will assert that the block size is political because it affects nearly all users to some degree and not all those users are technically inclined or care to keep decentralisation in the current configuration as you do. This debate has forgotten the current and future users of Bitcoin. Most of them think the hit to node count in the short term preferable to making it expensive and competitive to transact.
>
> We all need a little faith that the system will reorganise and readjust after the move to big blocks in a way that still has a reasonable degree of decentralisation and trustlessness. The incentives of Bitcoin remain, so everyone's decentralised decision throughout the system, from miners, merchants and users, will continue to act according to those incentives.
> _______________________________________________
> 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/20150803/3f4ddd21/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/3f4ddd21/attachment.sig>

2023-06-07 17:44:39 CEST

- reply

2023-06-07 17:43:51 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:> On Jul 30, 2015, at 11:02 AM, Mark Friedenbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> It is possible for a decentralized system like bitcoin to scale via distribution in a way that introduces minimal trust, for example by probabilistic validation and distribution of fraud proofs. However changes to bitcoin consensus rules (mostly soft-forks) are required in order to make this possible.
Please, Mark, let’s make this happen.
You can count on my full support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/2d0cb791/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/2d0cb791/attachment.sig>

2023-06-07 17:43:51 CEST

- reply

📅 Original date posted:2015-07-31
📝 Original message:Having said that, I must admit that the complex filtering mechanisms are
pretty clever...they almost make it practical to use SPV...now if only we
were committint to structures that can prove the validity of returned
datasets and miners actually validated stuff, it might also offer some
level of security.
On Jul 31, 2015 1:45 PM, "Eric Lombrozo" <elombrozo at gmail.com> wrote:
> I would love to be able to increase block size. But I have serious doubts
> about being able to do this safely at this time given what we presently
> know about the Bitcoin network. And I'm pretty sure I'm not alone in this
> sentiment.
>
> Had we been working on fixing the known issues that most complicate bigger
> blocks in the last six years, or even in the last three years after many
> issues had already been well-identified, perhaps we'd be ready to increase
> the limit. But other things have seemed more important, like specifying the
> use of X.509 overlay protocols or adding complex filtering mechanisms to
> the p2p protocol to make it practical to use tx merkle trees...and as a
> result we're not ready for safely allowing larger blocks.
>
> - Eric
> On Jul 30, 2015 11:43 PM, "Thomas Zander via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote:
>> > I don’t think it’s really a matter of whether we agree on whether it’s
>> good
>> > to raise the block size limit, Gavin. I think it’s a matter of a
>> difference
>> > in priorities.
>>
>> Having different priorities is fine, using your time to block peoples
>> attempts
>> to increase block size is not showing different priorities, it shows
>> conflicting
>> priorities.
>> Different priorities means you can trust someone else to do things they
>> care
>> about while you do things you care about.
>> --
>> Thomas Zander
>> _______________________________________________
>> 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/ed77d5ee/attachment.html>

2023-06-07 17:43:50 CEST

- reply

📅 Original date posted:2015-07-31
📝 Original message:I would love to be able to increase block size. But I have serious doubts
about being able to do this safely at this time given what we presently
know about the Bitcoin network. And I'm pretty sure I'm not alone in this
sentiment.
Had we been working on fixing the known issues that most complicate bigger
blocks in the last six years, or even in the last three years after many
issues had already been well-identified, perhaps we'd be ready to increase
the limit. But other things have seemed more important, like specifying the
use of X.509 overlay protocols or adding complex filtering mechanisms to
the p2p protocol to make it practical to use tx merkle trees...and as a
result we're not ready for safely allowing larger blocks.
- Eric
On Jul 30, 2015 11:43 PM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote:
> > I don’t think it’s really a matter of whether we agree on whether it’s
> good
> > to raise the block size limit, Gavin. I think it’s a matter of a
> difference
> > in priorities.
>
> Having different priorities is fine, using your time to block peoples
> attempts
> to increase block size is not showing different priorities, it shows
> conflicting
> priorities.
> Different priorities means you can trust someone else to do things they
> care
> about while you do things you care about.
> --
> Thomas Zander
> _______________________________________________
> 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/042f9b6a/attachment-0001.html>

2023-06-07 17:43:50 CEST

- reply

📅 Original date posted:2015-07-31
📝 Original message:I generally agree with this as well. I think it is crucial we avoid
controversial hardforks. The risks greatly outweigh the benefits.
This is a good start to making it less controversial.
- Eric
On Jul 31, 2015 2:31 PM, "Jorge Timón" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > These are the types of things I have been discussing in relation to a
> > process:
> >
> > -A list of metrics
> > -A Risk analysis of the baseline system. Bitcoin as it is now.
> > -Mitigation strategies for each risk.
> > -A set of goals.
> > -A Road map for each goal that lists the changes or possible avenues to
> > achieve that goal.
> >
> > Proposed changes would be measured against the same metrics and a risk
> > analysis done so it can be compared with the baseline.
> >
> > For example, the block size debate would be discussed in the context of a
> > road map related to a goal of increase scaling. One of the metrics
> would be
> > a decentralization metric. (A framework for a decentralization metric
> is at
> >
> http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf
> ).
> > Cost would be one aspect of the decentralization metric.
>
> All this sounds very reasonable and useful.
> And if a formal organization owns this "process", that's fine as well.
> I still think hardforks need to be uncontroversial (using the vague "I
> will know it when I see it" defintion) and no individual or
> organization can be an "ultimate decider" or otherwise Bitcoin losses
> all it's p2p nature (and this seems the point where you, Milly, and I
> disagree).
> But metrics and data tend to help when it comes to "I will know it
> when I see it" and "evidences".
> So, yes, by all means, let's have an imperfect decentralization metric
> rather than not having anything to compare proposals. Competing
> decentralization metrics can appear later: we need a first one first.
> I would add that we should have sets of simulations being used to
> calculate some of those metrics, but maybe I'm just going too deep
> into details.
> _______________________________________________
> 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/632e7277/attachment.html>

2023-06-07 17:43:49 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:> On Jul 30, 2015, at 5:29 AM, Gavin <gavinandresen at gmail.com> wrote:
>
> it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence.
Some of the risks are pretty hard to quantify. But I think this misses the bigger point - it very well *might* be possible to safely raise this limit or even get rid of it by first fixing some serious issues with the protocol. But over six years into the project and these issues continue to be all-but-ignored by most of the community (including at least a few core developers). I don’t think it’s really a matter of whether we agree on whether it’s good to raise the block size limit, Gavin. I think it’s a matter of a difference in priorities.
- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/0873af30/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/0873af30/attachment-0001.sig>

2023-06-07 17:43:47 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:> On Jul 30, 2015, at 1:21 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> I usually avoid troll-infested Dunning-Kruger-gone-wild fests like reddit, so I’ll leave that to others.
>
> But I do want to clarify a couple things here, though, Andrew.
>
> First of all, the issue is not about whether it is affordable for a highly motivated, technically skilled person to continue running a node even if we increase block size by a factor of X. This misses the point for at least a couple reasons:
>
> - Regardless of what that X is, it isn’t really going to be what makes this technology accessible to the masses. We would likely need the X to be in the thousands before we start to really take on players like Visa. Despite what people might have thought in 2009, it turns out Bitcoin is probably pretty ill-suited as a database in which to store the entire transaction history of the entire world. It’s looking to be more of a censorship-resistant dispute resolution mechanism that provides very well-defined settlement guarantees with the potential for encoding complex rules. It’s possible to build higher level tiers on top of it that DO support high volume transaction processing WITHOUT costing thousands of times more, and these approaches are looking quite promising. However, it doesn’t seem very many people in this space quite grasp this paradigm shift yet.
>
> - What matters is not how a relatively small number of well-intentioned people in the network behave. What matters is how the network behaves as a whole…and a number of the people most intimately familiar with the inner workings of the system (some of whom are in this thread) think that given what we now today about the Bitcoin network, increasing block size externalizes costs in dangerous ways. Remember that total cost includes not just equipment costs but also things like block propagation latency and specifically identified security risks. Some of these security risks were only appreciated relatively recently and were completely unknown in 2009.
>
Secondly, there are a few well-identified problems with the protocol design that might be possible to fix that would perhaps allow us to remove the block size limit entirely without sacrificing security. I listed the ones that come to my mind at the beginning of this thread. I EMPHATICALLY state that in no way am I fundamentally opposed to raising or even getting rid of the block size limit. But I believe these problems should be addressed first. And it’s easier to address them and tackle them if we don’t have to worry about potential security risks and higher costs that come from insisting on bigger blocks right now.
- Eric
>> On Jul 29, 2015, at 9:51 PM, Andrew LeCody via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> tl;dr
>> $100 worth of hardware and $1/mo of expenses, should be able to run a full
>> Bitcoin node until 2020 with BIP101-size blocks.
>>
>> ----
>>
>> I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up until
>> recently my profession has been as a server administrator or systems
>> engineer.
>>
>> I'd like to take a second to address the concern that larger blocks would
>> make it harder to run a full node on limited hardware and would therefore
>> hurt decentralization. I run two nodes today, one on server-grade hardware
>> at a datacenter and another on a mini-ITX Atom (dual core) system at my
>> home.
>>
>> I detailed the operational costs of my home node today on reddit:
>> https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls_attempt_to_rewrite/ctkigpr
>>
>> If I was a new user, wanting to run a full node. The most cost effective
>> way would likely be with a Raspberry Pi 2 and a 2TB external HDD. Total
>> cost about $100, including charger, microSD card, etc. That is less than
>> the cost of a TREZOR hardware wallet. As far as home projects go, not
>> terribly expensive.
>>
>> Next, it will need power. According to the Wikipedia article, the rpi 2
>> model B uses 3.5 watts of power max. The 2TB external drive will draw about
>> 5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. In my
>> area (North Texas) power is about $0.10/Kwh, which means my little node
>> costs $0.62 per month in power.
>>
>> Last, lets look at bandwidth. It's difficult to quantify bandwidth cost in
>> the same way because this is a home connection, mainly because I don't know
>> how to price in the loss of enjoyment if the system impacts my Internet
>> usage to a noticeable degree. Luckily, I have some real world data from my
>> existing home node. Here is the last month:
>> http://imgur.com/YmJwQpN
>>
>> This system averages 120 Kbps in and 544 Kbps out. Note, this data is
>> somewhat skewed, because the system is also used for seeding torrents of
>> various open source projects. The Bitcoin node itself is typically
>> connected to about 20 peers at any given time (maxconnections=20).
>>
>> Subjectively, my wife and I have never noticed any degradation of
>> performance due to my home server using too much bandwidth. I think it's
>> safe to say that I can treat the bandwidth is uses as effectively free,
>> since it's piggybacking on a connection I would be paying for even if I was
>> not running a Bitcoin node. The bandwidth usage of this Bitcoin node could
>> increase significantly, without any noticeable impact. If it did, I could
>> always lower maxconnections back to 8.
>>
>> The only real constraint seems to be hard drive space, as the full
>> blockchain and indexes take up about 50GB of space currently. If BIP101 is
>> implemented, 2TB of storage should be enough for me to continue running my
>> hypothetical $100 node until about 2020.
>>
>> It seems to me that at least for the next 5 years, the "small devices" of
>> today can easily run Bitcoin nodes with BIP101-size blocks, with very
>> little operational cost.
>>
>> If anyone would like more detailed data on my existing nodes, please let me
>> know and I'll attempt to provide it (so long as it doesn't impact my
>> privacy of course).
>>
>> On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I dont think people consider other blockchains as a competitive
>>> threat. A PoW-blockchain is a largely singleton data structure for
>>> security reasons (single highest hashrate), it is hard for an
>>> alternative chain to bootstrap or provide meaningful security.
>>> Secondly the world largely lacks expertise to maintain a blockchain to
>>> bitcoin's security level, perhaps you can see a hint of this in the
>>> recently disclosed security vulnerability by Pieter Wuille and Gregory
>>> Maxwell. Calls to this as an argument are not resonating and probably
>>> not helping your argument. Bitcoin has security properties, and a
>>> competing system cant achieve better properties by bypassing security,
>>> any blockchain faces the same fundamental security / decentralisation
>>> limitations.
>>>
>>> Secondly Bitcoin can obviously compete with itself with different
>>> parameters and defacto *does* today. I think it is a safe estimate
>>> that > 99% of Bitcoin transactions right now are happening in Bitcoin
>>> related systems with various degrees of audit, reconciliation,
>>> provable reserves etc. I think we can expect this to continue and
>>> become more secure via more reconciliation, and longer term via
>>> lightning or Bitcoin sidechains with different parameters. It is a
>>> different story to have a single central system (Bitcoin with
>>> parameters changed to the point of centralisation failure) vs having
>>> multiple choices, because some transactions can more easily use
>>> relatively centralised systems (eg micropayments), and more
>>> interestingly the combination of a secure and decentralised layer 1
>>> plus choices of less decentralised layer 2 options, can be interesting
>>> because the layer 2 is provided cover from attack. There is less to
>>> be gained by attacking relatively centralised layer 2 because any
>>> payments at risk of policy abuse (which is typically a small subset)
>>> can easily switch to layer 1. That in itself makes layer 2
>>> transactions also less susceptible to policy abuse. Further lightning
>>> it appears from work so far should add significant scale while
>>> retaining trustlessness and a good degree of decentralisation.
>>>
>>> Finally you seem to be focusing on "artificial" limits where that is
>>> not the issue under consideration. The limits are technical and
>>> relating to decentralisation and security. I wont go over them again
>>> as this topic has been covered many times in recent months. Any chain
>>> that tried to go to extreme parameters (very low block intervals, or
>>> very large blocksizes) would have the same decentralisation problems
>>> as Bitcoin would if it did the same thing. There are a number of alt
>>> coins that have failed as a result of poor parameter choices, there
>>> are inherent security limits.
>>>
>>> Adam
>>>
>>> ps Etiquette note for yourself and others: please dont be repetitive
>>> or attempt to be forceful. Many people have spent many years
>>> understanding this very complex system, from my own experience it is
>>> rare indeed to think of an entirely new concept or analysis, that
>>> hasnt' been long considered and put to bed 3 or 4 years ago.
>>> Thoughtful polite and constructive comments are welcome but I
>>> recommend to not start from an assumption that you have a clear and
>>> better insight than the entire technical community, because I have to
>>> say from my own experience that is very rarely the case. It can be
>>> useful to test theories on #bitcoin IRC channel to find out what has
>>> been already concluded, find the references and avoid having to have
>>> that hashed out on this list which is trying to be focussed on
>>> technical solutions.
>>>
>>>
>>> On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>> Cheapest way to send value? Is this what Bitcoin is trying to do? So
>>>>> all of the smart contract, programmable money, consensus coding and
>>>>> tremendous developer effort is bent to the consumer demand for cheaper
>>>>> fees. Surely thou jests!
>>>>
>>>>
>>>> These other features can be replicated into any alternative blockchain,
>>>> including those with lower fees. In the open-source world of
>>>> cryptocurrency, no feature will remain a value-add for very long after it
>>>> has been identified to be such. Anything adding value will quickly be
>>>> absorbed into competing alternative blockchains. That will leave
>>> economic
>>>> policy as the distinguishing factor.
>>>>
>>>>> ... it is not the case ... that reluctance to concede
>>>>> blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
>>>>> explained in this thread that the protocol's current state of
>>>>> development relies on blocksize for security and, ultimately, as a
>>>>> means of protecting its degree of decentralization.
>>>>
>>>>
>>>> A slow or lack of increase to maximum transaction rate will cause
>>> pressure
>>>> on fees. Whether this is the desired goal is not relevant. Everyone has
>>>> agreed this will be the outcome. As to a smaller block size being needed
>>>> for additional decentralization, one must simply ask how much we are all
>>>> willing to pay for that additional decentralization. It is likely that
>>> the
>>>> benefit thereto will have to be demonstrated by some power attacking and
>>>> destroying a less decentralized currency before the benefit of this
>>> feature
>>>> is given monetary value by the market. Until then, value will bleed to
>>> the
>>>> network with the least friction, because it will have the greatest
>>> ability
>>>> to grow its network effect. That means the blockchain with adequate
>>>> features and cheapest fees will eventually have the largest market share.
>>>>
>>>>
>>>> -----Original Message----- From: Venzen Khaosan
>>>> Sent: Wednesday, July 29, 2015 3:11 PM
>>>> To: Raystonn .
>>>> Cc: bitcoin-dev at lists.linuxfoundation.org
>>>> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
>>>> isn'ttemporary
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Raystonn, I'm aware that you're addressing your question to Greg
>>>> Maxwell, however a point you keep stating as fact calls for reference:
>>>>
>>>> On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
>>>> [snip]
>>>>>
>>>>> How do you plan to address the bleeding of value from Bitcoin to
>>>>> alternative lower-fee blockchains created by the artificially-high
>>>>> bitcoin transaction fees when users begin looking for the cheapest
>>>>> way to send value?
>>>>
>>>> Cheapest way to send value? Is this what Bitcoin is trying to do? So
>>>> all of the smart contract, programmable money, consensus coding and
>>>> tremendous developer effort is bent to the consumer demand for cheaper
>>>> fees. Surely thou jests!
>>>>
>>>>> Modern economic study has shown that liquidity moves to the
>>>>> location of least friction.
>>>>
>>>> Modern economic study? Can you please provide a link or reference to
>>>> the study you are referring to.
>>>>
>>>> "liquidity moves to the location of least friction"
>>>>
>>>> This sounds like "econo-speak" and makes no sense. The definition of
>>>> Liquidity is the degree to which an asset/security can be bought or
>>>> sold in the market without affecting the price.
>>>>
>>>> That is why bitcoin is said to have low liquidity: buying or selling
>>>> only 100 BTC visibly affects the exchange price. You probably mean
>>>> "people like cheap fees", which is true, but as others have said,
>>>> because of Bitcoin's powerful features, they are willing to pay higher
>>>> fees and wait longer for transactions to execute.
>>>>
>>>> As for your public cross-examination of Greg Maxwell, your case seems
>>>> to be made on the assumption that limiting the size of the blockchain
>>>> is an attempt to artificially raise tx fees, but it is not the case
>>>> (as you and others repeatedly argue) that reluctance to concede
>>>> blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
>>>> explained in this thread that the protocol's current state of
>>>> development relies on blocksize for security and, ultimately, as a
>>>> means of protecting its degree of decentralization.
>>>>
>>>> Surely, this is an obvious concern even for those who are campaigning
>>>> for the hare-brained ideal of making Bitcoin a "faster, cheaper
>>>> alternative" to visa or paypal? If we lose decentralization, we lose
>>>> the whole thing, right? Incorrect or correct?
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>>
>>>> iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
>>>> RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
>>>> h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
>>>> Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
>>>> YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
>>>> BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
>>>> =lQvy
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/52d2c365/attachment.sig>

2023-06-07 17:43:46 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:I usually avoid troll-infested Dunning-Kruger-gone-wild fests like reddit, so I’ll leave that to others.
But I do want to clarify a couple things here, though, Andrew.
First of all, the issue is not about whether it is affordable for a highly motivated, technically skilled person to continue running a node even if we increase block size by a factor of X. This misses the point for at least a couple reasons:
- Regardless of what that X is, it isn’t really going to be what makes this technology accessible to the masses. We would likely need the X to be in the thousands before we start to really take on players like Visa. Despite what people might have thought in 2009, it turns out Bitcoin is probably pretty ill-suited as a database in which to store the entire transaction history of the entire world. It’s looking to be more of a censorship-resistant dispute resolution mechanism that provides very well-defined settlement guarantees with the potential for encoding complex rules. It’s possible to build higher level tiers on top of it that DO support high volume transaction processing WITHOUT costing thousands of times more, and these approaches are looking quite promising. However, it doesn’t seem very many people in this space quite grasp this paradigm shift yet.
- What matters is not how a relatively small number of well-intentioned people in the network behave. What matters is how the network behaves as a whole…and a number of the people most intimately familiar with the inner workings of the system (some of whom are in this thread) think that given what we now today about the Bitcoin network, increasing block size externalizes costs in dangerous ways. Remember that total cost includes not just equipment costs but also things like block propagation latency and specifically identified security risks. Some of these security risks were only appreciated relatively recently and were completely unknown in 2009.
> On Jul 29, 2015, at 9:51 PM, Andrew LeCody via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> tl;dr
> $100 worth of hardware and $1/mo of expenses, should be able to run a full
> Bitcoin node until 2020 with BIP101-size blocks.
>
> ----
>
> I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up until
> recently my profession has been as a server administrator or systems
> engineer.
>
> I'd like to take a second to address the concern that larger blocks would
> make it harder to run a full node on limited hardware and would therefore
> hurt decentralization. I run two nodes today, one on server-grade hardware
> at a datacenter and another on a mini-ITX Atom (dual core) system at my
> home.
>
> I detailed the operational costs of my home node today on reddit:
> https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls_attempt_to_rewrite/ctkigpr
>
> If I was a new user, wanting to run a full node. The most cost effective
> way would likely be with a Raspberry Pi 2 and a 2TB external HDD. Total
> cost about $100, including charger, microSD card, etc. That is less than
> the cost of a TREZOR hardware wallet. As far as home projects go, not
> terribly expensive.
>
> Next, it will need power. According to the Wikipedia article, the rpi 2
> model B uses 3.5 watts of power max. The 2TB external drive will draw about
> 5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. In my
> area (North Texas) power is about $0.10/Kwh, which means my little node
> costs $0.62 per month in power.
>
> Last, lets look at bandwidth. It's difficult to quantify bandwidth cost in
> the same way because this is a home connection, mainly because I don't know
> how to price in the loss of enjoyment if the system impacts my Internet
> usage to a noticeable degree. Luckily, I have some real world data from my
> existing home node. Here is the last month:
> http://imgur.com/YmJwQpN
>
> This system averages 120 Kbps in and 544 Kbps out. Note, this data is
> somewhat skewed, because the system is also used for seeding torrents of
> various open source projects. The Bitcoin node itself is typically
> connected to about 20 peers at any given time (maxconnections=20).
>
> Subjectively, my wife and I have never noticed any degradation of
> performance due to my home server using too much bandwidth. I think it's
> safe to say that I can treat the bandwidth is uses as effectively free,
> since it's piggybacking on a connection I would be paying for even if I was
> not running a Bitcoin node. The bandwidth usage of this Bitcoin node could
> increase significantly, without any noticeable impact. If it did, I could
> always lower maxconnections back to 8.
>
> The only real constraint seems to be hard drive space, as the full
> blockchain and indexes take up about 50GB of space currently. If BIP101 is
> implemented, 2TB of storage should be enough for me to continue running my
> hypothetical $100 node until about 2020.
>
> It seems to me that at least for the next 5 years, the "small devices" of
> today can easily run Bitcoin nodes with BIP101-size blocks, with very
> little operational cost.
>
> If anyone would like more detailed data on my existing nodes, please let me
> know and I'll attempt to provide it (so long as it doesn't impact my
> privacy of course).
>
> On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I dont think people consider other blockchains as a competitive
>> threat. A PoW-blockchain is a largely singleton data structure for
>> security reasons (single highest hashrate), it is hard for an
>> alternative chain to bootstrap or provide meaningful security.
>> Secondly the world largely lacks expertise to maintain a blockchain to
>> bitcoin's security level, perhaps you can see a hint of this in the
>> recently disclosed security vulnerability by Pieter Wuille and Gregory
>> Maxwell. Calls to this as an argument are not resonating and probably
>> not helping your argument. Bitcoin has security properties, and a
>> competing system cant achieve better properties by bypassing security,
>> any blockchain faces the same fundamental security / decentralisation
>> limitations.
>>
>> Secondly Bitcoin can obviously compete with itself with different
>> parameters and defacto *does* today. I think it is a safe estimate
>> that > 99% of Bitcoin transactions right now are happening in Bitcoin
>> related systems with various degrees of audit, reconciliation,
>> provable reserves etc. I think we can expect this to continue and
>> become more secure via more reconciliation, and longer term via
>> lightning or Bitcoin sidechains with different parameters. It is a
>> different story to have a single central system (Bitcoin with
>> parameters changed to the point of centralisation failure) vs having
>> multiple choices, because some transactions can more easily use
>> relatively centralised systems (eg micropayments), and more
>> interestingly the combination of a secure and decentralised layer 1
>> plus choices of less decentralised layer 2 options, can be interesting
>> because the layer 2 is provided cover from attack. There is less to
>> be gained by attacking relatively centralised layer 2 because any
>> payments at risk of policy abuse (which is typically a small subset)
>> can easily switch to layer 1. That in itself makes layer 2
>> transactions also less susceptible to policy abuse. Further lightning
>> it appears from work so far should add significant scale while
>> retaining trustlessness and a good degree of decentralisation.
>>
>> Finally you seem to be focusing on "artificial" limits where that is
>> not the issue under consideration. The limits are technical and
>> relating to decentralisation and security. I wont go over them again
>> as this topic has been covered many times in recent months. Any chain
>> that tried to go to extreme parameters (very low block intervals, or
>> very large blocksizes) would have the same decentralisation problems
>> as Bitcoin would if it did the same thing. There are a number of alt
>> coins that have failed as a result of poor parameter choices, there
>> are inherent security limits.
>>
>> Adam
>>
>> ps Etiquette note for yourself and others: please dont be repetitive
>> or attempt to be forceful. Many people have spent many years
>> understanding this very complex system, from my own experience it is
>> rare indeed to think of an entirely new concept or analysis, that
>> hasnt' been long considered and put to bed 3 or 4 years ago.
>> Thoughtful polite and constructive comments are welcome but I
>> recommend to not start from an assumption that you have a clear and
>> better insight than the entire technical community, because I have to
>> say from my own experience that is very rarely the case. It can be
>> useful to test theories on #bitcoin IRC channel to find out what has
>> been already concluded, find the references and avoid having to have
>> that hashed out on this list which is trying to be focussed on
>> technical solutions.
>>
>>
>> On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> Cheapest way to send value? Is this what Bitcoin is trying to do? So
>>>> all of the smart contract, programmable money, consensus coding and
>>>> tremendous developer effort is bent to the consumer demand for cheaper
>>>> fees. Surely thou jests!
>>>
>>>
>>> These other features can be replicated into any alternative blockchain,
>>> including those with lower fees. In the open-source world of
>>> cryptocurrency, no feature will remain a value-add for very long after it
>>> has been identified to be such. Anything adding value will quickly be
>>> absorbed into competing alternative blockchains. That will leave
>> economic
>>> policy as the distinguishing factor.
>>>
>>>> ... it is not the case ... that reluctance to concede
>>>> blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
>>>> explained in this thread that the protocol's current state of
>>>> development relies on blocksize for security and, ultimately, as a
>>>> means of protecting its degree of decentralization.
>>>
>>>
>>> A slow or lack of increase to maximum transaction rate will cause
>> pressure
>>> on fees. Whether this is the desired goal is not relevant. Everyone has
>>> agreed this will be the outcome. As to a smaller block size being needed
>>> for additional decentralization, one must simply ask how much we are all
>>> willing to pay for that additional decentralization. It is likely that
>> the
>>> benefit thereto will have to be demonstrated by some power attacking and
>>> destroying a less decentralized currency before the benefit of this
>> feature
>>> is given monetary value by the market. Until then, value will bleed to
>> the
>>> network with the least friction, because it will have the greatest
>> ability
>>> to grow its network effect. That means the blockchain with adequate
>>> features and cheapest fees will eventually have the largest market share.
>>>
>>>
>>> -----Original Message----- From: Venzen Khaosan
>>> Sent: Wednesday, July 29, 2015 3:11 PM
>>> To: Raystonn .
>>> Cc: bitcoin-dev at lists.linuxfoundation.org
>>> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
>>> isn'ttemporary
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Raystonn, I'm aware that you're addressing your question to Greg
>>> Maxwell, however a point you keep stating as fact calls for reference:
>>>
>>> On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
>>> [snip]
>>>>
>>>> How do you plan to address the bleeding of value from Bitcoin to
>>>> alternative lower-fee blockchains created by the artificially-high
>>>> bitcoin transaction fees when users begin looking for the cheapest
>>>> way to send value?
>>>
>>> Cheapest way to send value? Is this what Bitcoin is trying to do? So
>>> all of the smart contract, programmable money, consensus coding and
>>> tremendous developer effort is bent to the consumer demand for cheaper
>>> fees. Surely thou jests!
>>>
>>>> Modern economic study has shown that liquidity moves to the
>>>> location of least friction.
>>>
>>> Modern economic study? Can you please provide a link or reference to
>>> the study you are referring to.
>>>
>>> "liquidity moves to the location of least friction"
>>>
>>> This sounds like "econo-speak" and makes no sense. The definition of
>>> Liquidity is the degree to which an asset/security can be bought or
>>> sold in the market without affecting the price.
>>>
>>> That is why bitcoin is said to have low liquidity: buying or selling
>>> only 100 BTC visibly affects the exchange price. You probably mean
>>> "people like cheap fees", which is true, but as others have said,
>>> because of Bitcoin's powerful features, they are willing to pay higher
>>> fees and wait longer for transactions to execute.
>>>
>>> As for your public cross-examination of Greg Maxwell, your case seems
>>> to be made on the assumption that limiting the size of the blockchain
>>> is an attempt to artificially raise tx fees, but it is not the case
>>> (as you and others repeatedly argue) that reluctance to concede
>>> blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
>>> explained in this thread that the protocol's current state of
>>> development relies on blocksize for security and, ultimately, as a
>>> means of protecting its degree of decentralization.
>>>
>>> Surely, this is an obvious concern even for those who are campaigning
>>> for the hare-brained ideal of making Bitcoin a "faster, cheaper
>>> alternative" to visa or paypal? If we lose decentralization, we lose
>>> the whole thing, right? Incorrect or correct?
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
>>> RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
>>> h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
>>> Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
>>> YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
>>> BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
>>> =lQvy
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/e5b0540c/attachment.sig>

2023-06-07 17:43:45 CEST

- reply

📅 Original date posted:2015-07-29
📝 Original message:> On Jul 29, 2015, at 4:15 AM, Mike Hearn <hearn at vinumeris.com> wrote:
>
> Irrelevant what term was used - and as brilliant as Satoshi might have been at some things, he obviously got this one wrong.
>
> I don't think it's obvious. You may disagree, but don't pretend any of this stuff is obvious.
>
> Consider this: the highest Bitcoin tx fees can possibly go is perhaps a little higher than what our competition charges. Too much higher than that, and people will just say, you know what .... I'll make a bank transfer. It's cheaper and not much slower, sometimes no slower at all.
>
> And now consider that in many parts of the world bank transfers are free.
>
> They aren't actually free, of course, but they appear to be free because the infrastructure for doing them is cross subsidised by the fees on other products and services, or hidden in the prices of goods sold.
>
> So that's a market reality Bitcoin has to handle. It's already more expensive than the competition sometimes, but luckily not much more, and anyway Bitcoin has some features those other systems lack (and vice versa). So it can still be competitive.
>
> But your extremely vague notion of a "fee market" neglects to consider that it already exists, and it's not a market of "Bitcoin users buying space in Bitcoin blocks". It's "users paying to move money".
>
> You can argue with this sort of economic logic if you like, but don't claim this stuff is obvious.
100% granted - it was not obvious…and we speak today with the benefit of hindsight.
I’ll clarify my argument, for the sake of anyone who thinks I’m looking to play word games rather than trying to figure out a good way forward.
Point is…processing blocks requires computational resources that someone needs to put up. Unless the people who are putting up these resources are properly incentivized to continue doing it, the network will fail.
Unfortunately, it was unforeseen that most nodes on the network would turn out to not be miners…and that most miners wouldn’t even run full nodes. Yes, I speak with the benefit of hindsight, had I been discussing this in 2008 I very well could have made the same mistake or worse. But it isn’t 2008, it’s 2015…and we’ve learned a thing or two since.
Given that things are what they are, it is clear that larger blocks externalize costs onto the rest of the network.
Waiting until we can no longer count on the altruistic goodwill of volunteers because they suddenly decide that they have better uses for their computers is probably not such a wonderful idea. But even worse is further burdening the network with externalized costs before we’ve solved these important issues…especially given the evidence that larger blocks tend to lead to network forks. No, I’m not talking about regular run-of-the-mill reorgs…I’m talking consensus forks - a network partition that cannot be reconciled without manual intervention, so please don’t distract the issue. Yes, each incident occurred for a very different reason…but you’d have to be blind to miss the correlation between bigger blocks and the propensity for forks.
What Satoshi might have thought in 2008-2009 is fascinating from a historical perspective, but his early pioneering insights don’t appear to be of much help in addressing these particular issues.
> Nobody threatened to start mining huge blocks given how relatively inexpensive it was to mine back then?
>
> Not that I recall. It wasn't a response to any actual event, I think, but rather a growing realisation that the code was full of DoS attacks.
>
>
> Guess what? SPV wallets are still not particularly widespread…and those that are out there are notoriously terrible at detecting network forks and making sure they are on the right one.
>
> The most popular mobile wallet (measured by installs) on Android is SPV. It has between 500,000 and 1 million installs, whilst Coinbase has not yet crossed the 500,000 mark. One of the most popular wallets on iOS is SPV. If we had SPV wallets with better user interfaces on desktops, they'd be more popular there too (perhaps MultiBit HD can recapture some lost ground).
>
> So I would argue that they are in fact very widespread.
>
> Likewise, they are not "notoriously terrible" at detecting chain forks. That's a spurious idea that you and Patrick have been pushing lately, but they detect them and follow reorgs across them according to the SPV algorithm, which is based on most work done. This is exactly what they are designed to do.
>
> Contrast this with other lightweight wallets which either don't examine the block chain or implement the algorithm incorrectly, and I fail to see how this can be described as "notoriously terrible".
>
>
> I understand that initially it was desirable that transactions be free…but surely even Satoshi understood this couldn’t be perpetually self-sustaining…and that the ability to bid for inclusion in blocks would eventually become a crucial component of the network. Or were fees just added for decoration?
>
> Fees were added as a way to get money to miners in a fair and decentralised way.
>
> Attaching fees directly to all transactions is certainly one way to use that, but it's not the only way. As noted above, our competitors prefer a combination of price-hiding and cross subsidisation. Both of these can be implemented with tx fees, but not necessarily by trying to artificially limit supply, which is economically nonsensical.
>
>
> We’re already more than six years into this. When were these mechanisms going to be developed and tested? After 10 years? 20? Perhaps after 1024 years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki>)
>
> Maybe when there is a need? I already discussed this topic of need here:
>
> https://medium.com/@octskyward/hashing-7d04a887acc8 <https://medium.com/@octskyward/hashing-7d04a887acc8>
>
> Right. Turns out the ledger structure is terrible for constructing the kinds of proofs that are most important to validators - i.e. whether an output exists, what its script and amounts are, whether it’s been spent, etc…
>
> Validators don't require proofs. That's why they are validators.
>
> I think you're trying to say the block chain doesn't provide the kinds of proofs that are most important to lightweight wallets. But I would disagree. Even with UTXO commitments, there can still be double spends out there in the networks memory pools you are unaware of. Merely being presented with a correctly signed transaction doesn't tell you a whole lot ..... if you wait for a block, you get the same level of proof regardless of whether there are UTXO commitments or not. If you don't then you still have to have some trust in your peers that you are seeing an accurate and full view of network traffic.
>
> So whilst there are ways to make the protocol incrementally better, when you work through the use cases for these sorts of data structures and ask "how will this impact the user experience", the primary candidates so far don't seem to make much difference.
>
> Remote attestation from secure hardware would make a big difference though. Then you could get rid of the waiting times entirely because you know the sending wallet won't double spend.
>
>
> Yes, let’s wait until things are about to break before even beginning to address the issue…because we can “easily create” anything we haven’t invented yet at the last minute.
>
> bitcoinj already has a micropayment channel implementation in it. There's a bit of work required to glue everything together, but it's not a massive project to start using this to pay nodes for their services.
>
> But it's not needed right now: serving these clients is so darn cheap. And there is plenty of room for optimising things still further!
>
>
> I’m one of the very few developers in this space that has actually tried *hard* to make your BIP37 work. Amongst the desktop wallets listed on bitcoin.org <http://bitcoin.org/>, there are only two that have always supported SPV (or at least I think MultiBit has always supported it, perhaps I’m wrong). One is MultiBit, the other one is mine. I give you credit for your work…perhaps you could be generous enough to extend me some credit too?
>
> MultiBit has always supported it. I apologise for implying you have not built a wallet. I think yours is mSIGNA, right? Did it used to be called something else? I recognise the website design but must admit, I have not heard of mSIGNA before.
>
> Regardless, as a fellow implementor, I would appreciate it more if you designed and implemented upgrades, rather than just trashing the work done so far as "notoriously terrible", Satoshi as "not a systems architect" and so on.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/8e1ccf9c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/8e1ccf9c/attachment.sig>

2023-06-07 17:43:43 CEST

- reply

📅 Original date posted:2015-07-29
📝 Original message:> On Jul 29, 2015, at 2:59 AM, Mike Hearn <hearn at vinumeris.com> wrote:
>
> I do love history lessons from people who weren't actually there.
>
> Let me correct your misconceptions.
>
>
> Initially there was no block size limit - it was thought that the fee market would naturally develop and would impose economic constraints on growth.
>
> The term "fee market" was never used back then, and Satoshi did not ever postulate economic constraints on growth. Back then the talk was (quite sensibly) how to grow faster, not how to slow things down!
Irrelevant what term was used - and as brilliant as Satoshi might have been at some things, he obviously got this one wrong.
>
> But this hypothesis failed after a sudden influx of new uses. It was still too easy to attack the network. This idea had to wait until the network was more mature to handle things.
>
> No such event happened, and the hypothesis of which you talk never existed.
>
Nobody threatened to start mining huge blocks given how relatively inexpensive it was to mine back then?
>
> Enter a “temporary” anti-spam measure - a one megabyte block size limit.
>
> The one megabyte limit was nothing to do with anti spam. It was a quick kludge to try and avoid the user experience degrading significantly in the event of a "DoS block", back when everyone used Bitcoin-Qt. The fear was that some malicious miner would generate massive blocks and make the wallet too painful to use, before there were any alternatives.
I thought I clarified this in an earlier post - I meant DoS. Please don’t digress on such stupid technicalities.
> The plan was to remove it once SPV wallets were widespread. But Satoshi left before that happened.
>
Guess what? SPV wallets are still not particularly widespread…and those that are out there are notoriously terrible at detecting network forks and making sure they are on the right one.
>
> Now on to your claims:
>
> 1) We never really got to test things out…a fee market never really got created, we never got to see how fees would really work in practice.
>
> The limit had nothing to do with fees. Satoshi explicitly wanted free transactions to last as long as possible.
Something has to limit block sizes in practice. Perhaps Satoshi was not constrained by finite computational resources, but the rest of us sure are. The fact that without imposing a hardcoded limit Satoshi couldn’t figure out a way to keep the DoS-block guys away suggests he didn’t have this fully worked out.
I understand that initially it was desirable that transactions be free…but surely even Satoshi understood this couldn’t be perpetually self-sustaining…and that the ability to bid for inclusion in blocks would eventually become a crucial component of the network. Or were fees just added for decoration?
We’re already more than six years into this. When were these mechanisms going to be developed and tested? After 10 years? 20? Perhaps after 1024 years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki>)
>
> 2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do not get compensated…validation cost is externalized to the entire network.
>
> Satoshi explicitly envisioned a future where only miners ran nodes, so it had nothing to do with this either.
And Satoshi was dead wrong. As others have pointed out in this thread, while this is certainly of historical interest, it is irrelevant from an engineering perspective.
> Validators validate for themselves. Calculating a local UTXO set and then not using it for anything doesn't help anyone. SPV wallets need filtering and serving capability, but a computer can filter and serve the chain without validating it.
Right. Turns out the ledger structure is terrible for constructing the kinds of proofs that are most important to validators - i.e. whether an output exists, what its script and amounts are, whether it’s been spent, etc…
Despite Satoshi’s brilliance, software architecture was obviously not his strongest suit. But it didn’t really matter at the beginning since this was really an experiment…and he succeeded in making his point.
> The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining full nodes are needed for with today's network are:
> Filtering the chain for bandwidth constrained SPV wallets (nb: you can run an SPV wallet that downloads all transactions if you want). But this could be handled by specialised nodes, just like we always imagined in future not every node will serve the entire chain but only special "archival nodes"
>
> Relaying validated transactions so SPV wallets can stick a thumb into the wind and heuristically guess whether a transaction is valid or not. This is useful for a better user interface.
>
> Storing the mempool and filtering/serving it so SPV wallets can find transactions that were broadcast before they started, but not yet included in a block. This is useful for a better user interface.
> Outside of serving lightweight P2P wallets there's no purpose in running a P2P node if you aren't mining, or using it as a trusted node for your own operations.
>
> And if one day there aren't enough network nodes being run by volunteers to service all the lightweight wallets, then we can easily create an incentive scheme to fix that.
Yes, let’s wait until things are about to break before even beginning to address the issue…because we can “easily create” anything we haven’t invented yet at the last minute.
>
>
> 3) Miners don’t even properly validate blocks. And the bigger the blocks get, the greater the propensity to skip this step. Oops!
>
> Miners who don't validate have a habit of bleeding money: that's the system working as designed.
>
Erm…most miners just trust mining pool operators to validate blocks for them…and some of the biggest pools have been blatantly cutting corners. Yes, a few pools might have temporarily bled a little…but properly validating is probably not the equilibrium strategy…and as time goes on, they are likely to start cutting corners again. Whether they ultimately bleed money isn’t really the point - many believe that cutting corners is actually a rational strategy. If you want to discuss the game theory behind this, fine…but the fact some of the biggest mining pool operators are on record saying they are likely to continue doing this is enough to seriously put to question one of the most fundamental assumptions behind the network security model.
>
> 4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs for their transactions never materialized.
>
> It did. I designed it. The proofs are short and "reasonably secure" in that it would be a difficult and expensive attack to mount.
You have my respect for BIP37, Mike. I know you can do amazing work. You actually made SPV semi-useful despite inheriting such crappy data structures. This is indeed to be respected.
>
> But as is so often the case with Bitcoin Core these days, someone who came along much later has retroactively decided that the work done so far fails to meet some arbitrary and undefined level of perfection. "Satisfactory" and "reasonably secure" don't mean anything, especially not coming from someone who hasn't done the work, so why should anyone care about that opinion of yours?
Not done the work?
I’m one of the very few developers in this space that has actually tried *hard* to make your BIP37 work. Amongst the desktop wallets listed on bitcoin.org <http://bitcoin.org/>, there are only two that have always supported SPV (or at least I think MultiBit has always supported it, perhaps I’m wrong). One is MultiBit, the other one is mine. I give you credit for your work…perhaps you could be generous enough to extend me some credit too?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/215362e9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/215362e9/attachment.sig>

2023-06-07 17:43:42 CEST

- reply

📅 Original date posted:2015-07-29
📝 Original message:> On Jul 28, 2015, at 7:40 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> Note: many of these ideas are neither my own nor really all that new, but it seems in the past we’ve given up too easily on actually moving forward on them despite their critical importance.
In retrospect I regret not having made this note more emphatic:
GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR YEARS ALREADY…AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED…WTF?!?!?!?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/e5e99247/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/e5e99247/attachment.sig>

2023-06-07 17:43:42 CEST

- reply

📅 Original date posted:2015-07-29
📝 Original message:> On Jul 28, 2015, at 8:46 PM, Milly Bitcoin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR
>> YEARS ALREADY…AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED…
>
> What is the incentive for someone with high level technical skills to spend all their time developing and testing code? Especially since the code is generally the boring task of "fixing the plumbing" and won't benefit the developer directly ... except they will be blamed if something goes wrong.
>
> Russ
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Some of the most highly skilled technical people working on Bitcoin Core have been doing exactly that! The main incentive, of course, is that later on you get to work on something that’s actually pleasant to work on rather than a whole bunch of garbled crap that doesn’t work properly.
However, the great irony is that the devs who have long since recognized the importance of fixing these issues have also tended to be loathe to touching any of the consensus code unless it fixes some critical immediately exploitable security hole…while the devs who most clamor for consensus code changes have tended to all but ignore these issues entirely.
I sometimes wish it were the other way around.
- Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/442ee8be/attachment.sig>

2023-06-07 17:43:41 CEST

- reply

📅 Original date posted:2015-07-28
📝 Original message:> On Jul 28, 2015, at 5:43 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
>
>> Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good…
>>
>
> The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.
>
>
> jp
>
I’m using spam and DoS somewhat synonymously here, although you’re correct - DoS is a more accurate term.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/da5402c9/attachment.sig>

2023-06-07 17:43:41 CEST

- reply

📅 Original date posted:2015-07-28
📝 Original message:I agree that the historical reasons are irrelevant from an engineering perspective. But they still set a context for the discussion…and might help shed some insight into the motivations behind some of the participants. It’s also good to know these things to counter arguments that start with “But Satoshi said that…”
What’s critically important to note is that several of the assumptions that were being made at the time this limit was decided have turned out wrong…and that these other issues should probably be of greater concern and more highly prioritized in any discussion considering the merits of deploying potentially incompatible consensus rule changes. It seems if these other issues were fixed perhaps no block size limit would be required at all (as was originally hoped).
- Eric
> On Jul 28, 2015, at 5:46 PM, Mark Friedenbach <mark at friedenbach.org> wrote:
>
> Does it matter even in the slightest why the block size limit was put in place? It does not. Bitcoin is a decentralized payment network, and the relationship between utility (block size) and decentralization is empirical. Why the 1MB limit was put in place at the time might be a historically interesting question, but it bears little relevance to the present engineering issues.
>
> On Tue, Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> > Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good…
> >
>
> The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.
>
>
> jp
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/d29e0571/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/d29e0571/attachment.sig>

2023-06-07 17:43:41 CEST

- reply

📅 Original date posted:2015-07-28
📝 Original message:In the interest of promoting some constructive discussion on this, let me start by making a few proposals to correct the listed issues.
Note: many of these ideas are neither my own nor really all that new, but it seems in the past we’ve given up too easily on actually moving forward on them despite their critical importance.
——
1) A fee market never really got created, we don’t really know how transaction fees would work in practice.
The only way to see how fees would work in practice is to have scarcity. If the network is still not sufficiently mature to be able to handle actual resource limits securely, the safest way to do this is to artificially impose limits. Some economists might bicker about the problems with production quotas and what not…but how else are we to solve the real, non-trivial engineering problems without risking system collapse? The eventual goal would be to remove these artificial limits once we’re confident that the economic incentives are properly aligned to maintain security. We’re still quite far from this goal, though, and it would be irresponsible, IMHO, to insist on letting the system hit its real limits.
2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do not get compensated…validation cost is externalized to the entire network.
3) Miners don’t even properly validate blocks. And the bigger the blocks get, the greater the propensity to skip this step. Oops!
Issues (2) and (3) are inextricably related so I’ll cover both together.
The obvious problem here is that as long as the cost of checking validators is the same as the cost of validating itself, there’s really little we can do to properly have any sort of division of labor. Requiring, at the very least, random checks might be a start. Perhaps some clever use of SNARKs might eventually be secure and practical.
It might also be possible to directly pay validators for satisfying random checks or providing SNARKs. If only we could trustlessly and securely outsource this work we’d make tremendous progress.
Of all the issues I’ve listed, these are perhaps the ones for which practical solutions seem most tentative at present.
4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs for their transactions never materialized.
The first part of the solution to this issue is the use of better data structures. Satoshi’s SPV can prove that transactions are included in blocks…and that outputs are spent. But it has no mechanism for proving that a given transaction is *not* included in any block…or that some particular output remains unspent. The structures to which we’re committing extremely inefficient for querying some of the most important things required for validation…i.e. whether an output exists and whether it is spent.
The second part is shifting the responsibility for constructing proofs to the parties who already have the greatest incentives to store the necessary data to construct these proofs to allow efficient prunability. Outsourceability of proofs would also be highly desirable.
——
If we want to be able to raise the block size limit…or perhaps get rid of it altogether, I would suggest we start by addressing these specific issues and work to find practical solutions. Since raising the block size limit is already a hard forking consensus rule change, at least the need for hard forks isn’t what’s stopping us.
- Eric
> On Jul 28, 2015, at 5:55 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> I agree that the historical reasons are irrelevant from an engineering perspective. But they still set a context for the discussion…and might help shed some insight into the motivations behind some of the participants. It’s also good to know these things to counter arguments that start with “But Satoshi said that…”
>
> What’s critically important to note is that several of the assumptions that were being made at the time this limit was decided have turned out wrong…and that these other issues should probably be of greater concern and more highly prioritized in any discussion considering the merits of deploying potentially incompatible consensus rule changes. It seems if these other issues were fixed perhaps no block size limit would be required at all (as was originally hoped).
>
> - Eric
>
>> On Jul 28, 2015, at 5:46 PM, Mark Friedenbach <mark at friedenbach.org <mailto:mark at friedenbach.org>> wrote:
>>
>> Does it matter even in the slightest why the block size limit was put in place? It does not. Bitcoin is a decentralized payment network, and the relationship between utility (block size) and decentralization is empirical. Why the 1MB limit was put in place at the time might be a historically interesting question, but it bears little relevance to the present engineering issues.
>>
>> On Tue, Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> > Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good…
>> >
>>
>> The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.
>>
>>
>> jp
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/f797244b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/f797244b/attachment-0001.sig>

2023-06-07 17:43:40 CEST

- reply

📅 Original date posted:2015-07-28
📝 Original message:I only got into Bitcoin in 2011, after the block size limit was already in place. After going through some more of the early history of Bitcoin to better understand the origins of this, things are starting to come into better perspective.
Initially there was no block size limit - it was thought that the fee market would naturally develop and would impose economic constraints on growth. But this hypothesis failed after a sudden influx of new uses. It was still too easy to attack the network. This idea had to wait until the network was more mature to handle things.
Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good…
Except…well:
1) We never really got to test things out…a fee market never really got created, we never got to see how fees would really work in practice.
2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do not get compensated…validation cost is externalized to the entire network.
3) Miners don’t even properly validate blocks. And the bigger the blocks get, the greater the propensity to skip this step. Oops!
4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs for their transactions never materialized.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150728/1dfbd49a/attachment.sig>

2023-06-07 17:43:08 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists at coryfields.com> wrote:
>
> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>> FWIW, I had worked on something similar a while back:
>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>
>> I like the idea in principle…but we should require a new genesis block,
>> different magic bytes, and a different network port at the very least. :)
>>
>
> Not sure if serious, so I'll assume you are :)
Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.
> Why? The idea in this case would be to allow the user to decide
> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
> runtime rather than the likely alternative of "./bitcoind" vs
> "./bitcoin-fork”.
That’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.
> Chain params may be identical other than the value of some future
> event (miner vote for example), in which case the configs would run
> identically until that point.
Yes, indeed - this would be a special case.
> If your concern is about nodes with different configs communicating
> with eachother, I'd like to reiterate: the idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
I do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.
> Cory
>
>> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I'm not sure why Bitcoin Core and the rules and policies that it
>> enforces are being conflated in this thread. There's nothing stopping
>> us from adding the ability for the user to decide what their consensus
>> parameters should be at runtime. In fact, that's already in use:
>> ./bitcoind -testnet. As mentioned in another thread, the chain params
>> could even come from a config file that the user could edit without
>> touching the code.
>>
>> I realize that it'd be opening Pandora's Box, and likely met with very
>> loud and reasonable arguments about the obvious terrible implications,
>> but it's at least an alternative to the current status quo of Core's
>> conflation with the consensus rules. The idea really is no different
>> than suggesting that someone fork the codebase and implement their own
>> changes, it just cuts out most of the work required.
>>
>> With that in place, consensus changes would be more about lobbying and
>> coalitions, and less about pull requests.
>>
>> Cory
>>
>> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> If the developers fail to reflect user consensus, the network will let us
>> know.
>>
>>
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference. If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>>
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I wouldn't go quite that far. The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>>
>> Quoting BC,
>>
>> Upgrading to a version of Bitcoin Core that is incompatible with your
>> ideals is in no way a forced choice, as you have stated in your email;
>> forks, alternative clients, or staying on an older version are all valid
>> choices. If the majority of the network chooses not to endorse a specific
>> change, then the majority of the network will continue to operate just fine
>> without it, and properly structured consensus rules will pull the minority
>> along as well.
>>
>>
>> The developers propose a new version, by publishing a new release. The
>> individual network nodes choose to accept or reject that.
>>
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>>
>> There are checks-and-balances that make the system work. Consensus is most
>> strongly measured by user actions after software release. If the developers
>> fail to reflect user consensus, the network will let us know.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi Pieter,
>>
>> I think a core area of disagreement is this:
>>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>>
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have the authority to set its rules. This is enforced by the reality of
>> ~100% market share and limited github commit access.
>>
>> You may not like this situation, but it is what it is. By refusing to make a
>> release with different rules, people who disagree are faced with only two
>> options:
>>
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>>
>> There are no alternatives. People who object to (2) are inherently
>> suggesting (1) is the only acceptable path, which not surprisingly, makes a
>> lot of people very angry.
>>
>> _______________________________________________
>> 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
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/aedc9049/attachment.sig>

2023-06-07 17:43:07 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:FWIW, I had worked on something similar a while back: https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf <https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/bitcoin.conf>
I like the idea in principle…but we should require a new genesis block, different magic bytes, and a different network port at the very least. :)
> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
>
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>
> Cory
>
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> If the developers fail to reflect user consensus, the network will let us
>>> know.
>>
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference. If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>>
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I wouldn't go quite that far. The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>>
>> Quoting BC,
>>> Upgrading to a version of Bitcoin Core that is incompatible with your
>>> ideals is in no way a forced choice, as you have stated in your email;
>>> forks, alternative clients, or staying on an older version are all valid
>>> choices. If the majority of the network chooses not to endorse a specific
>>> change, then the majority of the network will continue to operate just fine
>>> without it, and properly structured consensus rules will pull the minority
>>> along as well.
>>
>> The developers propose a new version, by publishing a new release. The
>> individual network nodes choose to accept or reject that.
>>
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>>
>> There are checks-and-balances that make the system work. Consensus is most
>> strongly measured by user actions after software release. If the developers
>> fail to reflect user consensus, the network will let us know.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi Pieter,
>>
>> I think a core area of disagreement is this:
>>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>>
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have the authority to set its rules. This is enforced by the reality of
>> ~100% market share and limited github commit access.
>>
>> You may not like this situation, but it is what it is. By refusing to make a
>> release with different rules, people who disagree are faced with only two
>> options:
>>
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>>
>> There are no alternatives. People who object to (2) are inherently
>> suggesting (1) is the only acceptable path, which not surprisingly, makes a
>> lot of people very angry.
>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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/20150722/81ebd82e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/81ebd82e/attachment.sig>

2023-06-07 17:43:05 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:> On Jul 22, 2015, at 3:01 PM, Mike Hearn <hearn at vinumeris.com> wrote:
>
> Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork.
>
> Block chain forks merge in the same way as git forks all the time, that's how the reorg algorithm works. Transactions that didn't make it into the post-reorg chain go back into the mempool and miners attempt to reinclude them: this is the "merge" process. If they now conflict with other transactions they are dropped and this is "resolving merge conflicts".
>
> However you have to want to merge with the new chain. If your software is programmed not to do that out of some bizarre belief that throttling your own user base is a good idea, then of course, no merge happens. Once you stop telling your computer to do that, you can then merge (reorg) back onto the main chain again.
>
Mike, you might be surprized to learn that there are other hard fork proposals out there besides increasing block size.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/f856c464/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/f856c464/attachment.sig>

2023-06-07 17:43:04 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:> On Jul 22, 2015, at 3:01 PM, Mike Hearn <hearn at vinumeris.com> wrote:
>
> Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork.
>
> Block chain forks merge in the same way as git forks all the time, that's how the reorg algorithm works. Transactions that didn't make it into the post-reorg chain go back into the mempool and miners attempt to reinclude them: this is the "merge" process. If they now conflict with other transactions they are dropped and this is "resolving merge conflicts".
>
Blockchain reorgs are part of the consensus rules. We’re talking not about forks caused by network partitions…but forks caused by the use of distinct consensus rules.
> However you have to want to merge with the new chain. If your software is programmed not to do that out of some bizarre belief that throttling your own user base is a good idea, then of course, no merge happens. Once you stop telling your computer to do that, you can then merge (reorg) back onto the main chain again.
>
You cannot merge two chains that have incompatible transactions in them without throwing away one of the two conflicting transactions (along with all dependencies). In the reorg process, this occurs naturally…and we allow for it by using confirmation count as a metric of irreversibility. Until one chain wins (by overwhelming consensus) or all chains include a particular transaction in question, we cannot treat that transaction as irreversible. Propose a model in which we can still reliably measure irreversibility in the presence of multiple chains and you might have a point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/fbddb23c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/fbddb23c/attachment.sig>

2023-06-07 17:43:04 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:> On Jul 22, 2015, at 2:43 PM, Mike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
> Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do have the authority to set its rules. This is enforced by the reality of ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a release with different rules, people who disagree are faced with only two options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently suggesting (1) is the only acceptable path, which not surprisingly, makes a lot of people very angry.
It would be truly awesome to be able to give people more choice on consensus rules. Unfortunately, cryptoledgers do not fork gracefully (yet). Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork.
> _______________________________________________
> 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/20150722/4006ffa5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/4006ffa5/attachment-0001.sig>

2023-06-07 17:43:03 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:> On Jul 22, 2015, at 10:33 AM, Jeff Garzik via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> Some people have called the prospect of limited block space and the development of a fee market a change in policy compared to the past. I respectfully disagree with that. Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules. Change in economics is always happening, and should be expected. Worse, intervening in consensus changes would make the ecosystem more dependent on the group taking that decision, not less.
>
>
>
> This completely ignores reality, what users have experienced for the past ~6 years.
>
> "Change in economics is always happening" does not begin to approach the scale of the change.
>
> For the entirety of bitcoin's history, absent long blocks and traffic bursts, fee pressure has been largely absent.
This is only because of the fact that only a negligible portion of miner income comes from fees - the vast majority still continues to be subsidized by block rewards. The original design of the protocol was such that this subsidy would be decreased over time to let fees become the predominant source of income for miners. Until we have fee pressures, there’s no incentive for the industry to find solutions to real problems that need solving. I think you underestimate the ingenuity of people when pressed for real solutions. The main barrier to Bitcoin adoption is NOT this issue…and I believe the priorities are misplaced here. We’ve had over six years to start working on solutions but we keep “kicking the can down the road” - until when?!?! I believe unless there’s a strong need to find a solution no solutions will really be found.
>
> Moving to a new economic policy where fee pressure is consistently present is radically different from what users, markets, and software have experienced and lived.
>
> Analysis such as [1][2] and more shows that users will hit a "painful" "wall" and market disruption will occur - eventually settling to a new equilibrium after a period of chaos - when blocks are consistently full.
>
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin <http://hashingit.com/analysis/34-bitcoin-traffic-bulletin>
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent <http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent>
>
> First, users & market are forced through this period of chaos by "let a fee market develop" as the whole market changes to a radically different economic policy, once the network has never seen before.
>
> Next, when blocks are consistently full, the past consensus was that block size limit will be increased eventually. What happens at that point?
>
> Answer - Users & market are forced through a second period of chaos and disruption as the fee market is rebooted again by changing the block size limit.
>
> The average user hears a lot of noise on both sides of the block size debate, and really has no idea that the new "let a fee market develop" Bitcoin Core policy is going to raise fees on them.
>
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted upon them
>
The current userbase and market is still tiny - we have to think bigger than this. We already go through loads of pain to use the current system…and quite frankly, there are a number of other significant issues that I think are far bigger obstacles to widespread adoption than “I have to pay a fee”. For example, the current cost of verification is too high to continue to ensure the security of the network (as the July 4th fork clearly illustrated)…and places huge centralization pressures on validation…and simply will not support hundreds of millions of users or billions of users. Increasing block size actually worsens the scaling properties, it does not improve them. We need better scaling solutions - almost certainly this will require avoiding the need for global consensus for the vast majority of transactions (nested consensus or off-chain direct party-to-party contract negotiation, the lightning network, etc. The focus on reducing fee pressure by increasing block size is a distraction from far more fundamental issues, IMHO.
>
> So to point out what I consider obvious: if Bitcoin requires central control over its rules by a group of developers, it is completely uninteresting to me. Consensus changes should be done using consensus, and the default in case of controversy is no change.
>
>
> False.
>
> All that has to do be done to change bitcoin to a new economic policy - not seen in the entire 6 year history of bitcoin - is to stonewall work on block size.
>
> Closing size increase PRs and failing to participate in planning for a block size increase accomplishes your stated goal of changing bitcoin to a new economic policy.
>
Wrong - the economic policy of bitcoin has always been, from the beginning, to subsidize blocks initially and transition to fees. Artificially continuing to rely on block reward subsidies is what is a new economic policy. We’re already six years in, pretty soon another halving is coming - how long are we going to wait to start transitioning? The lower block reward subsidies are, the more pain fee pressures will cause.
> "no [code] change"... changes bitcoin to a brand new economic policy, picking economic winners & losers. Some businesses will be priced out of bitcoin, etc.
>
> Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC move as increasing the hard limit by hard fork.
>
>
> My personal opinion is that we - as a community - should indeed let a fee market develop, and rather sooner than later, and that "kicking the can down the road" is an incredibly dangerous precedent: if we are willing to go through the risk of a hard fork because of a fear of change of economics, then I believe that community is not ready to deal with change at all. And some change is inevitable, at any block size. Again, this does not mean the block size needs to be fixed forever, but its intent should be growing with the evolution of technology, not a panic reaction because a fear of change.
>
> But I am not in any position to force this view. I only hope that people don't think a fear of economic change is reason to give up consensus.
>
>
> Actually you are.
>
> When size increase progress gets frozen out of Bitcoin Core, that just increases the chances that progress must be made through a contentious hard fork.
>
> Further, it increases the market disruption users will experience, as described above.
>
> Think about the users. Please.
>
I think about the billions of people out there in the world that could be using this technology that simply have no access to it right now. The majority or them which are unbanked, etc…
More the reason to go through the steps needed while we’re still small to correct the core issues.
>
> _______________________________________________
> 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/20150722/e4c83d05/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/e4c83d05/attachment-0001.sig>

2023-06-07 17:43:00 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
> Quality of service as in:
>
>> X satoshi / kb = included in block currently worked on;
>
>> Y satoshi / kb = included in next block;
>
>> Z satoshi / kb = included in block after that, etc.
>
> Block count starts when transaction is first seen. Miners can set X, Y, Z.
>
> Market develops when miners start setting different values and adding more transactions to blocks as opposed to other miners with higher settings.
>
> It basically comes down to the miners themselves if they want a healthy fee market. If they stick to their guns, their influence on the fees will be proportional to their hashing power.
>
> jp
The scheme I’ve been considering is the use of services (separate from miners) that guarantee inclusion for you for some predetermined price and then do the bidding on your behalf. Via contracts you can guarantee you get included within a certain number of blocks or you receive a full refund…or even possibly receive compensation for failure to deliver.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/c498890b/attachment-0001.sig>

2023-06-07 17:43:00 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:I agree that the fewer the necessary parties the better - however, some entities are much better positioned to offer certain services on the network than others - and the fact we can trustlessly negotiate smart contracts with them is one of the most significant developments in the cryptospace - it’s one of the most revolutionary aspects of this technology…it accomplishes something we’ve never really been able to do before.
Notice that third parties can encapsulate complex tasks and provide a far simpler interface. Crypto contracts provide the incentives for them to do this. And by having competition and transparency, these services automatically get optimized via human ingenuity. We don’t need to design top-down for it.
> On Jul 23, 2015, at 6:42 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
> Miners could include their fee tiers in the coinbase, but this is obviously open to manipulation, with little recourse (unless they are a pool and miners move away because of it).
>
> In any event, I think that trying out a solution that is both simple and involves the least number of parties necessary is preferable.
>
> Have miners set their tiers, have users select the level of quality they want, ignore the block size.
>
> Miners will adapt their tiers depending on how many transactions actually end up in them. If for example they set the first tier to be $1 to be included in the current block and no user chooses that level of service, they've obviously priced themselves out of the market. The opposite is also true; if a tier is popular they can choose to increase the cost of that tier.
>
> jp
>
>> On Jul 24, 2015, at 9:28 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>
>> I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote.
>>
>>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>>>
>>> I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>>>
>>> jp
>>>
>>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>>
>>>> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>>>>
>>>> Negotiating directly with miners via smart contracts seems difficult at best.
>>>>
>>>>
>>>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>
>>>>> Doesn't matter.
>>>>>
>>>>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>>>>
>>>>> jp
>>>>>
>>>>>
>>>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete at petertodd.org> wrote:
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA256
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>>
>>>>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>>>>> start excluding transactions.
>>>>>>
>>>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>>>
>>>>>>
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>
>>>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>>>> =LY1+
>>>>>> -----END PGP SIGNATURE-----
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/79d0ce0e/attachment.sig>

2023-06-07 17:42:59 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote.
> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
> I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>
> jp
>
>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>
>> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>>
>> Negotiating directly with miners via smart contracts seems difficult at best.
>>
>>
>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Doesn't matter.
>>>
>>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>>
>>> jp
>>>
>>>
>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete at petertodd.org> wrote:
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>>
>>>>
>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>
>>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>>> start excluding transactions.
>>>>
>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>>
>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>> =LY1+
>>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/e7496cfa/attachment-0001.sig>

2023-06-07 17:42:58 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
Negotiating directly with miners via smart contracts seems difficult at best.
> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Doesn't matter.
>
> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>
> jp
>
>
>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete at petertodd.org> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>>
>>
>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>> start excluding transactions.
>>
>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>> =LY1+
>> -----END PGP SIGNATURE-----
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/569da4c2/attachment.sig>

2023-06-07 17:42:57 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:Are you referring to mining contracts?
> On Jul 23, 2015, at 5:32 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>
>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>>
>> You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion.
>>
>> A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. In fact it will only highlight what the cap is actually for; to prevent monster blocks.
>>
>> Add better QoS tools for miners and extend the cap (when possible) and there's your fee market.
>>
>> jp
>
> Not sure what you mean by QoS here. Either your transaction is included or it isn’t. It’s not like you can upgrade to a master suite with a view or anything.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/e5292776/attachment.sig>

2023-06-07 17:42:57 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
> You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion.
>
> A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. In fact it will only highlight what the cap is actually for; to prevent monster blocks.
>
> Add better QoS tools for miners and extend the cap (when possible) and there's your fee market.
>
> jp
Not sure what you mean by QoS here. Either your transaction is included or it isn’t. It’s not like you can upgrade to a master suite with a view or anything.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/2d67e8c5/attachment-0001.sig>

2023-06-07 17:42:56 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:I should also add that I think those who claim that fee pressure will scare away users and break the industry are *seriously* underestimating human ingenuity in the face of a challenge. We can do this - we can overcome this obstacle…we can find good solutions to a fee market. Unless someone can come up with another way to pay for the operation of the network, we NEED to do this. What makes anyone think it will be easier to do later rather than now? The longer we wait, the lower block rewards get, the larger the deployed infrastructure, the larger our userbase, the HARDER it will be to solve it. We should solve it now - we will be much better off for it…and so will our users.
> On Jul 23, 2015, at 4:57 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>
>> On Jul 23, 2015, at 4:42 PM, Benedict Chan <bencxr at fragnetics.com <mailto:bencxr at fragnetics.com>> wrote:
>>
>> Scaling the network will come in the form of a combination of many
>> optimizations. Just because we do not know for sure how to eventually
>> serve 7 billion people does not mean we should make decisions on
>> global validation that impact our ability to serve the current set of
>> users.
>
> Agreed. But I believe the economic and security arguments I gave regarding fees and incentives still hold and are largely separate from the scalability issue. Please correct me if I overlooked something.
>
>
>> Also, blocking a change because it's "more important to address issues
>> such as..." other improvements will further slow down the discussion.
>> I believe an increase will not prevent the development of other
>> improvements that we need - in contrast, the sooner we can get over
>> the limit (which, as you agree, needs to be changed at some point),
>> the sooner we can get back to work.
>
> An increase in block size at this time will exacerbate security concerns around nodes relying on other nodes to validate (particularly miners and wallets). It’s not really a matter of having limited developer resources that need to be budgeted, as you seem to suggest.
>
> Regarding developments on properly handling fees, there must exist the economic need for it before there’s an earnest effort to solve it. Increasing the block size right now will, in all likelihood, delay this effort. I’d much prefer to first let the fee market evolve because it’s a crucial component to the protocol’s design and its security model…and so we can get a better sense for fee economics. Then we might be able to figure out better approaches to block size changes in the future that makes sense economically…perhaps with mechanisms that can dynamically adjust it to reflect resource availability and network load.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/2a0f074c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/2a0f074c/attachment-0001.sig>

2023-06-07 17:42:55 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:> On Jul 23, 2015, at 4:42 PM, Benedict Chan <bencxr at fragnetics.com> wrote:
>
> Scaling the network will come in the form of a combination of many
> optimizations. Just because we do not know for sure how to eventually
> serve 7 billion people does not mean we should make decisions on
> global validation that impact our ability to serve the current set of
> users.
Agreed. But I believe the economic and security arguments I gave regarding fees and incentives still hold and are largely separate from the scalability issue. Please correct me if I overlooked something.
> Also, blocking a change because it's "more important to address issues
> such as..." other improvements will further slow down the discussion.
> I believe an increase will not prevent the development of other
> improvements that we need - in contrast, the sooner we can get over
> the limit (which, as you agree, needs to be changed at some point),
> the sooner we can get back to work.
An increase in block size at this time will exacerbate security concerns around nodes relying on other nodes to validate (particularly miners and wallets). It’s not really a matter of having limited developer resources that need to be budgeted, as you seem to suggest.
Regarding developments on properly handling fees, there must exist the economic need for it before there’s an earnest effort to solve it. Increasing the block size right now will, in all likelihood, delay this effort. I’d much prefer to first let the fee market evolve because it’s a crucial component to the protocol’s design and its security model…and so we can get a better sense for fee economics. Then we might be able to figure out better approaches to block size changes in the future that makes sense economically…perhaps with mechanisms that can dynamically adjust it to reflect resource availability and network load.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/7bcddf71/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/7bcddf71/attachment.sig>

2023-06-07 17:42:54 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:> On Jul 23, 2015, at 12:35 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
>
>
> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo at gmail.com <mailto:elombrozo at gmail.com>> wrote:
> Mainstream usage of cryptocurrency will be enabled primarily by direct party-to-party contract negotiation…with the use of the blockchain primarily as a dispute resolution mechanism. The block size isn’t about scaling but about supply and demand of finite resources. As demand for block space increases, we can address it either by increasing computational resources (block size) or by increasing fees. But to do the former we need a way to offset the increase in cost by making sure that those who contribute said resources have incentive to do so.
>
> There are so many things wrong with this paragraph I just can't let it slide.
>
> "Mainstream usage will be enabled primarily by..." Maybe. Maybe not, we don't know what use case(s) will primarily take cryptocurrency mainstream. I believe it is a big mistake to pick one and bet "THIS is going to be the winner".
>
> "we can address it either by... or..." False dichotomy. There are lots of things we can do to decrease costs, and a lot of things have ALREADY been done (e.g. running a pruned full node). I HATE the "it must be this or that" "us or them" attitude, it fosters unproductive bickering and negativity.
>
> (and yes, I'm human, I'm sure you can find instances in the recent past where I did it, too... mea culpa)
>
> --
> --
> Gavin Andresen
>
Regarding rhetoric, fair enough, Gavin - I’m human and I could be wrong. It is my educated best guess, a conclusion I’ve drawn given my understanding of computer science, economics, and what’s been happening in this space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/a2e0c0b4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/a2e0c0b4/attachment.sig>

2023-06-07 17:42:54 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:> On Jul 23, 2015, at 12:35 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
>
> There are lots of things we can do to decrease costs, and a lot of things have ALREADY been done (e.g. running a pruned full node).
I also wanted to point out I fully agree with you that there are still many optimizations we could do to reduce costs, and think many of these things are certainly worth doing. However, there’s only so much we can do in this regard. Sooner or later we still run up against theoretical limitations. These optimizations can reduce costs by some factor…but they are highly unlikely to overcome the Ω(n) validation complexity barring some major algorithmic breakthrough (and perhaps allowing for nondeterminism, perhaps accepting a negligible but finite error probability).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/8b4fd65c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/8b4fd65c/attachment-0001.sig>

2023-06-07 17:42:53 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:> On Jul 23, 2015, at 11:10 AM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
>
> Larger block sizes don't scale the network, they merely increase how much load we allow the network to bear.
Very well put, Jameson. And the cost of bearing this load must be paid for. And unless we’re willing to accept that computational resources are finite and subject to the same economic issues as any other finite resource, our incentive model collapses the security of the network will be significantly at risk. Whatever your usability concerns may be regarding fees, when the security model’s busted usability issues are moot.
Larger blocks support more transactions…but they also incur Ω(n) overhead in bandwidth, CPU, and space. These are finite resources that must be paid for somehow…and as we all already know miners are willing to cut corners on all this and push the costs onto others (not to mention wallets and online block explorers). And who can really blame them? It’s rational behavior given the skewed incentives.
> On the flip side, the scalability proposals will still require larger blocks if we are ever to support anything close to resembling "mainstream" usage. This is not an either/or proposition - we clearly need both.
Mainstream usage of cryptocurrency will be enabled primarily by direct party-to-party contract negotiation…with the use of the blockchain primarily as a dispute resolution mechanism. The block size isn’t about scaling but about supply and demand of finite resources. As demand for block space increases, we can address it either by increasing computational resources (block size) or by increasing fees. But to do the former we need a way to offset the increase in cost by making sure that those who contribute said resources have incentive to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/6b2ba5e8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/6b2ba5e8/attachment.sig>

2023-06-07 17:42:53 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'd really like to move from "IMPOSSIBLE because... (electrum hasn't been optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning disks),
> what if the network is attacked? (attacked HOW???), current p2p network is using
> the simplest, stupidest possible block propagation algorithm...)"
>
> ... to "lets work together and work through the problems and scale it up."
Let’s be absolutely clear about one thing - block size increases are *not* about scaling the network. Can we please stop promoting this falsehood? It doesn’t matter by what number we multiply the block size…we can NEVER satisfy the full demand if we insist on every single transaction from every single person everywhere in the world being on the blockchain…it’s just absurd.
Increasing block size only temporarily addresses one significant issue - how to postpone having to deal with transaction fees, which by design, are how the cost of operating the Bitcoin network (which is already very expensive) is supposed to be paid for ultimately. Suggesting we avoid dealing with this constitutes a new economic policy - dealing with it is the default economic policy we’ve all known about from the beginning…so please stop claiming otherwise.
> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Why not help on a project that actually seems to offer great scalability like the lightning network? There have been great progress there.
Exactly. There’s been tremendous progress here in addressing scalability, yet I don’t see you participating in that discussion, Gavin.
> On Jul 23, 2015, at 5:17 AM, Jorge Timón via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> But it seems to me that the "not now side" has no centralization
> concerns at all and their true position is "not ever hit the blocksize
> limit", that's the only explanation I can find to their lack of
> answers to the "when do you think we should allow users to notice that
> there's a limit in the blocksize to guarantee that the system can be
> decentralized?".
I agree with what you’re saying, Jorge…but It’s even worse than that. The July 4th fork illustrated that the security model of the network itself could be at risk from the increasing costs in validation causing people to rely on others to validate for them…and increasing block size only makes the problem worse.
- Eric Lombrozo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/0f431ef8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/0f431ef8/attachment-0001.sig>

2023-06-07 17:42:52 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:> On Jul 23, 2015, at 10:14 AM, Robert Learney via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> That’s not exactly what’s happened though, is it Cipher? Gavin put forward 20Mb then after analysis and discussion has moved to 8Mb, whereas the other camp of core developers is firmly stuck in the ‘1Mb or bust’ group.
The issue isn’t really whether it’s 1MB or 2MB or 4MB or 8MB or whatever. First of all, the burden of justifying this change should be on those proposing a hardfork. The default is to not have a hard fork. Second of all, it’s not really about *whether* the block size is increased…but about *when* and *how* it is increased. There’s a good argument to be made that right now it is more important to address issues such as the fact that validation is so expensive (which as others and myself have pointed out has led to a collapse of the security model in the past, requiring manual intervention to temporarily “fix”)…and the fact that we don’t yet have great solutions to dealing with fees, which are a crucial component of the design of the protocol.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/262a77d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/262a77d2/attachment-0001.sig>

2023-06-07 17:40:58 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:The Lightning network is essentially a contract negotiation scheme that rewards cooperation. Defection amounts to either broadcasting early or not responding to signature requests. If done right, either of these situations incurs a bigger cost to the uncooperative party than cooperation. This is why I say blockchains are like a fix to the prisoner’s dilemma.
The blockchain becomes essentially a dispute resolution mechanism and a way to anchor stuff. There’s no use case covered by the current method of “flood the entire network and confirm on blockchain” that can’t be covered by a method of “participate in a contract which guarantees me payment on the blockchain if anyone is uncooperative but which rarely requires touching the blockchain” methinks.
- Eric Lombrozo
> On Jun 28, 2015, at 3:07 PM, Adam Back <adam at cypherspace.org> wrote:
>
> On 28 June 2015 at 23:05, Gavin Andresen <gavinandresen at gmail.com> wrote:
>> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam at cypherspace.org> wrote:
>>>
>>> This is probably going to sound impolite, but I think it's pertinent.
>>>
>>> Gavin, on dwelling on the the fact that you appear to not understand
>>> the basics of the lightning network, I am a little alarmed about this
>>
>> If I don't see how switching from using the thousands of fully-validating
>> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better in
>> terms of decentralization (or security, in terms of Sybil/DoS attacks),
>
> Its a source routed network, not a broadcast network. Fees are
> charged on channels so
> DoS is just a way to pay people a multiple of bandwidth cost.
>
> in terms of trustlessness Andrew Lapp explained it pretty well:
>> I don't mind a set of central authorities being part of an option IF the central authority
>> doesn't need to be trusted. On the blockchain, the larger miner is, the more you have
>> to trust them to not collude with anyone to reverse your payments or destroy the trust
>> in the system in some attack. On the Lightning network, a large hub can't steal my
>> money.
>>
>> I think most people share the sentiment that trustlessness is what matters and
>> decentralization is just a synonym for trustlessness when talking about the blockchain
>> and mining, however decentralization isn't necessarily synonymous with trustlessness
>> nor is centralization synonymous with trust-requiring when you're talking about
>> something else.
>
> Gavin wrote:
>> then I doubt other people do, either. You need to do a better job of explaining it.
>
> I gave it a go a couple of posts up. I didnt realise people here
> proposing mega-blocks were not paying attention to the whole lightning
> concept and detail.
>
> People said lots of things about how it's better to work on lightning,
> to scale algorithmically, rather than increasing block-size to
> dangerously centralising proportions.
> Did you think we were Gish Galloping you? We were completely serious.
>
> The paper is on http://lightning.network
>
> though it is not so clearly explained there, however Joseph is working
> on improving the paper as I understand it.
>
> Rusty wrote a high-level blog explainer: http://rusty.ozlabs.org/?p=450
>
> though I don't recall that he got into recirculation, negative fees
> etc. A good question
> for the lightning-dev mailing list maybe.
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/
>
> There are a couple of recorded presentation videos / podcasts from Joseph Poon.
>
> sf bitcoin dev presentation:
>
> https://www.youtube.com/watch?v=2QH5EV_Io0E
>
> epicenter bitcoin:
>
> https://www.youtube.com/watch?v=fBS_ieDwQ9k
>
> There's a related paper from Christian Decker "Duplex Micropayment Channels"
>
> http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
>
>> But even if you could convince me that it WAS better from a
>> security/decentralization point of view:
>
> We don't need to convince people, we just have to code it and
> demonstrate it, which people are working on.
>
> But Lightning does need a decentralised and secure Bitcoin network for
> anchor and reclaim transactions, so take it easy with the mega-blocks
> in the mean-time.
>
>> a) Lightning Network is nothing but a whitepaper right now. We are a long
>> way from a practical implementation supported by even one wallet.
>
> maybe you want to check in on
>
> https://github.com/ElementsProject/lightning
>
> and help code it.
>
> I expect we can get something running inside a year. Which kind of
> obviates the burning "need" for a schedule into the far future rising
> to 8GB with unrealistic bandwidth growth assumptions that will surely
> cause centralisation problems.
>
> For block-size I think it would be better to have a 2-4 year or one
> off size bump with policy limits and then re-evaluate after we've seen
> what lightning can do.
>
> I have been saying the same thing ad-nauseam for weeks.
>
>> b) The Lightning Network paper itself says bigger blocks will be needed even
>> if (especially if!) Lightning is wildly successful.
>
> Not nearly as big as if you tried to put the transactions it would
> enable on the chain, that's for sure! We dont know what that limit is
> but people have been imagining 1,000 or 10,000 transactions per anchor
> transaction. If micro-payments get popular many more.
>
> Basically users would park Bitcoins a on a hub channel instead of the
> blockchain. The channel can stay up indefinitely, and the user has
> assurances analogous to greenaddress time-lock mechanism
>
> Flexcap maybe a better solution because that allows bursting
> block-size when economically rational.
>
> Note that the time-locks with lightning are assumed to be relative
> CTLV eg using the mechanism as Mark Friedenbach described in a post
> here, and as implemented in the elements sidechain, so there is not a
> huge rush to reclaim funds. They can be spread out in time.
>
> If you want to scale Bitcoin - like really scale it - work on
> lightning. Lightning + a decentralised and secure Bitcoin, scales
> further and is more trustless than Bitcoin forced into centralisation
> via premature mega-blocks.
>
> To my mind a shorter, more conservative block-size increase to give a
> few years room is enough for now. We'll be in a better position to
> know what the right next step is after lightning is running.
>
> Something to mention is you can elide transactions before reclaiming.
> So long as the balancing transaction is correct, someone online can
> swap it for you with an equal balance one with less hops of
> intermediate payment flows.
>
>
> It's pretty interesting what you can do already. I'm fairly confident
> we're not finished algorithmically optimising it either. It's
> surprising how much new territory there is just sitting there
> unexplored.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/a8c34cc4/attachment-0001.sig>

2023-06-07 17:40:58 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:There’s no question that a flooding mesh network requiring global consensus for every transactions is not the way. It’s also clear that a routable protocol capable of compensating hubs is basically the holy grail.
So what’s there to discuss?
- Eric
> On Jun 28, 2015, at 3:07 PM, Adam Back <adam at cypherspace.org> wrote:
>
> On 28 June 2015 at 23:05, Gavin Andresen <gavinandresen at gmail.com> wrote:
>> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam at cypherspace.org> wrote:
>>>
>>> This is probably going to sound impolite, but I think it's pertinent.
>>>
>>> Gavin, on dwelling on the the fact that you appear to not understand
>>> the basics of the lightning network, I am a little alarmed about this
>>
>> If I don't see how switching from using the thousands of fully-validating
>> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better in
>> terms of decentralization (or security, in terms of Sybil/DoS attacks),
>
> Its a source routed network, not a broadcast network. Fees are
> charged on channels so
> DoS is just a way to pay people a multiple of bandwidth cost.
>
> in terms of trustlessness Andrew Lapp explained it pretty well:
>> I don't mind a set of central authorities being part of an option IF the central authority
>> doesn't need to be trusted. On the blockchain, the larger miner is, the more you have
>> to trust them to not collude with anyone to reverse your payments or destroy the trust
>> in the system in some attack. On the Lightning network, a large hub can't steal my
>> money.
>>
>> I think most people share the sentiment that trustlessness is what matters and
>> decentralization is just a synonym for trustlessness when talking about the blockchain
>> and mining, however decentralization isn't necessarily synonymous with trustlessness
>> nor is centralization synonymous with trust-requiring when you're talking about
>> something else.
>
> Gavin wrote:
>> then I doubt other people do, either. You need to do a better job of explaining it.
>
> I gave it a go a couple of posts up. I didnt realise people here
> proposing mega-blocks were not paying attention to the whole lightning
> concept and detail.
>
> People said lots of things about how it's better to work on lightning,
> to scale algorithmically, rather than increasing block-size to
> dangerously centralising proportions.
> Did you think we were Gish Galloping you? We were completely serious.
>
> The paper is on http://lightning.network
>
> though it is not so clearly explained there, however Joseph is working
> on improving the paper as I understand it.
>
> Rusty wrote a high-level blog explainer: http://rusty.ozlabs.org/?p=450
>
> though I don't recall that he got into recirculation, negative fees
> etc. A good question
> for the lightning-dev mailing list maybe.
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/
>
> There are a couple of recorded presentation videos / podcasts from Joseph Poon.
>
> sf bitcoin dev presentation:
>
> https://www.youtube.com/watch?v=2QH5EV_Io0E
>
> epicenter bitcoin:
>
> https://www.youtube.com/watch?v=fBS_ieDwQ9k
>
> There's a related paper from Christian Decker "Duplex Micropayment Channels"
>
> http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
>
>> But even if you could convince me that it WAS better from a
>> security/decentralization point of view:
>
> We don't need to convince people, we just have to code it and
> demonstrate it, which people are working on.
>
> But Lightning does need a decentralised and secure Bitcoin network for
> anchor and reclaim transactions, so take it easy with the mega-blocks
> in the mean-time.
>
>> a) Lightning Network is nothing but a whitepaper right now. We are a long
>> way from a practical implementation supported by even one wallet.
>
> maybe you want to check in on
>
> https://github.com/ElementsProject/lightning
>
> and help code it.
>
> I expect we can get something running inside a year. Which kind of
> obviates the burning "need" for a schedule into the far future rising
> to 8GB with unrealistic bandwidth growth assumptions that will surely
> cause centralisation problems.
>
> For block-size I think it would be better to have a 2-4 year or one
> off size bump with policy limits and then re-evaluate after we've seen
> what lightning can do.
>
> I have been saying the same thing ad-nauseam for weeks.
>
>> b) The Lightning Network paper itself says bigger blocks will be needed even
>> if (especially if!) Lightning is wildly successful.
>
> Not nearly as big as if you tried to put the transactions it would
> enable on the chain, that's for sure! We dont know what that limit is
> but people have been imagining 1,000 or 10,000 transactions per anchor
> transaction. If micro-payments get popular many more.
>
> Basically users would park Bitcoins a on a hub channel instead of the
> blockchain. The channel can stay up indefinitely, and the user has
> assurances analogous to greenaddress time-lock mechanism
>
> Flexcap maybe a better solution because that allows bursting
> block-size when economically rational.
>
> Note that the time-locks with lightning are assumed to be relative
> CTLV eg using the mechanism as Mark Friedenbach described in a post
> here, and as implemented in the elements sidechain, so there is not a
> huge rush to reclaim funds. They can be spread out in time.
>
> If you want to scale Bitcoin - like really scale it - work on
> lightning. Lightning + a decentralised and secure Bitcoin, scales
> further and is more trustless than Bitcoin forced into centralisation
> via premature mega-blocks.
>
> To my mind a shorter, more conservative block-size increase to give a
> few years room is enough for now. We'll be in a better position to
> know what the right next step is after lightning is running.
>
> Something to mention is you can elide transactions before reclaiming.
> So long as the balancing transaction is correct, someone online can
> swap it for you with an equal balance one with less hops of
> intermediate payment flows.
>
>
> It's pretty interesting what you can do already. I'm fairly confident
> we're not finished algorithmically optimising it either. It's
> surprising how much new territory there is just sitting there
> unexplored.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/acaaaf6f/attachment.sig>

2023-06-07 17:40:40 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:Either one branch wins overwhelmingly in a relatively short period of time…or both branches lose, I think.
- Eric
> On Jun 28, 2015, at 6:51 AM, Ivan Brightly <ibrightly at gmail.com> wrote:
>
> On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon at jtimon.cc <mailto:jtimon at jtimon.cc>> wrote:
>
> No, this is very important. The majority has no right to dictate on
> the minority.
>
> While an interesting philosophical question, I don't think that this is accurate. First off, bitcoin doesn't imbue any 'rights' on individuals - it provides the choice of participating or not, nothing more.
>
> Secondly, from a technical perspective, how is it that the majority (or super-majority) are prevented from imposing their will? The best answer is that they are incentivized to not override a minority group since that reduces the inherent value in the system. However, presuming that the majority calculate that the reward for imposing a change is greater than the value lost in such disruption, I don't see how there would be any stopping this change. The longest chain with the greatest number of users valuing the token on that chain "wins".
>
> _______________________________________________
> 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/20150628/6def6860/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/6def6860/attachment.sig>

2023-06-07 17:40:40 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:Furthermore, the actual way in which the conflict is resolved sets a precedent for how such disagreements are to be “resolved” in the future.
So the means are also important to consider.
- Eric
> On Jun 28, 2015, at 6:51 AM, Ivan Brightly <ibrightly at gmail.com> wrote:
>
> On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon at jtimon.cc <mailto:jtimon at jtimon.cc>> wrote:
>
> No, this is very important. The majority has no right to dictate on
> the minority.
>
> While an interesting philosophical question, I don't think that this is accurate. First off, bitcoin doesn't imbue any 'rights' on individuals - it provides the choice of participating or not, nothing more.
>
> Secondly, from a technical perspective, how is it that the majority (or super-majority) are prevented from imposing their will? The best answer is that they are incentivized to not override a minority group since that reduces the inherent value in the system. However, presuming that the majority calculate that the reward for imposing a change is greater than the value lost in such disruption, I don't see how there would be any stopping this change. The longest chain with the greatest number of users valuing the token on that chain "wins".
>
> _______________________________________________
> 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/20150628/739cefdc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/739cefdc/attachment.sig>

2023-06-07 17:40:39 CEST

- reply

📅 Original date posted:2015-06-27
📝 Original message:The economic policy’s status quo has been to avoid fee pressure. But the consensus status quo obviously is not to have a hard fork.
There’s clearly a contradiction between these two policies, which is a big part of the reason this issue has come to this point. These two policies are fundamentally at odds.
- Eric Lombrozo
> On Jun 27, 2015, at 4:04 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Sat, Jun 27, 2015 at 12:29 PM, NxtChg <nxtchg at hush.com> wrote:
>>
>> On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" <laanwj at gmail.com> wrote:
>>
>>> Then you won't risk the other 'passengers' who don't consent to it.
>>
>> But you can look at it the other way: what about risking the 'passengers' when the plane suddenly doesn't fly anymore?
>>
>> Increasing block limit increases the risk of centralization, but it also keeps the current status quo of blocks not being filled, rather then risking an unknown option of hitting the limit hard.
>
> But that option is not unknown, that's the point of this thread.
> "Doing nothing" would require to fix the mempool to scale with the
> number of unconfirmed transaction. This is something that we will
> eventually have to fix unless the plan is to eventually remove the
> blocksize limit.
> What will happen with full blocks is that fees will likely rise and
> the transactions with bigger fees will get confirmed first. This is
> something that will eventually happen unless the blocksize limit is
> removed before ever being hit.
> What this thread is saying is that this option (the so-called "doing
> nothing" option, which actually requires more work than any of the
> current proposals for increasing the blocksize) is perfectly valid,
> which is in contradiction to a perceived "need to increase the
> blocksize limit soon". Increasing the block size is only an option,
> not a "need". And changing the consensus rules and forcing everybody
> to adapt their software to the changes is certainly not "maintaining
> the status quo", I'm getting tired of hearing that absurd notion.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/8faed6e6/attachment-0001.sig>

2023-06-07 17:40:36 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:I should add that a strategy of “let’s avoid fee pressure as much as possible. let’s avoid even thinking about how we’ll transition as much as possible.” strikes me as at least a tad bit myopic.
- Eric Lombrozo
> On Jun 26, 2015, at 7:18 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> I’ve been pondering this whole scale issue considerably…and am left with the conclusion that blockchains are ultimately dispute resolution mechanisms. The vast majority of crypto negotiation will be taking place at levels lesser than global consensus in the future - global consensus is just far too expensive to require for every single cappuccino. There really is little need to take most cases globally…unless the participants disagree. I’ve commented in other places that blockchains are essentially a “fix” to the prisoner’s dilemma - they make cooperation the equilibrium strategy.
>
> Regardless of whatever linear factor we scale the blockchain by, it is simple math to see that any exponential growth (even if for a short time) in usage will overwhelm the current network. If we ever intend to take bitcoin mainstream, we will most likely experience at least a short time of exponential growth…at least until we either reach an inherent limitation or until we saturate. As Pieter said earlier, FAPP right now the demand for payments might as well be infinite. We’re nowhere near the ability to service it all.
>
> The block size issue is really a usability issue at this point. There are two fundamental things we need to solve:
>
> 1) There’s no model for how we’ll introduce a fee market, even though the design of Bitcoin fundamentally depends on fees for its survival (at least in the current form of the design.)
>
> 2) There’s no mechanism for how to perform fee bidding and estimation. Most wallets simply have no way to do this without serious usability problems.
>
>
>
> If we’re going to talk about block fees, let’s keep it in the context of these relevant issues and not confound it with the scalability issue…these are two very different issues.
>
>
> - Eric Lombrozo
>
>
>> On Jun 26, 2015, at 1:44 PM, Owen Gunden <ogunden at phauna.org> wrote:
>>
>> On 06/26/2015 02:23 PM, Jeff Garzik wrote:
>>> Failure to plan now for a hard fork increase 6(?) months in the future
>>> produces that lumpy, unpredictable market behavior.
>>>
>>> The market has baked in the years-long behavior of low fees. From the
>>> market PoV, inaction does lead to precisely that, a sudden change over
>>> the span of a few months.
>>
>> Which market participants are you referring to?
>>
>> I entered the bitcoin market with open eyes, aware that it faces hard scalability challenges by design. I was also aware that because of these challenges, eventually transaction fees would have to rise.
>>
>> Nevertheless, I made the decision to invest because of the utility I gain from the anti-censorship, privacy, control, store of value, and security aspects of bitcoin -- many of which stem from decentralization, which others have demonstrated to be linked to the block size.
>>
>> On the other hand, there are undoubtedly other market participants who heard hype about "zero fee transactions to anywhere in the world", believed it would scale, and made (mal)investments as a result.
>>
>> As for how many market participants of each flavor, and how deep their respective pockets, who knows? My experience in markets has lead me to realize that it's never wise to assume I know what "the market" does and doesn't know. If Jeff Garzik is right about what the market has priced in, then yes, filled blocks will be rocking the boat. But who's to say that the smartest, biggest investors and traders don't already see this scaling problem, and have already priced it in? In this case, a sudden large increase in the block size is actually rocking the boat. The point is, you can't know either way, so trying to pre-empt the market in this way is erroneous.
>>
>> Regarding entrepreneurial investment specifically, why should we favor the entrepreneurs who require a more centralized bitcoin over those who were more considerate of the possibility of rising transaction fees when making their business models?
>>
>> In my mind, we should favor neither, which is why I'm basically in agreement with Pieter that this sense of "emergency" shouldn't really be a part of the debate.
>>
>> Not that I'm taking a stand on the specific block size issue either way. I just think this particular line of reasoning (presupposing what information the market has and has not already baked in) is unsound.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/3e1b7436/attachment.sig>

2023-06-07 17:40:35 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:I’ve been pondering this whole scale issue considerably…and am left with the conclusion that blockchains are ultimately dispute resolution mechanisms. The vast majority of crypto negotiation will be taking place at levels lesser than global consensus in the future - global consensus is just far too expensive to require for every single cappuccino. There really is little need to take most cases globally…unless the participants disagree. I’ve commented in other places that blockchains are essentially a “fix” to the prisoner’s dilemma - they make cooperation the equilibrium strategy.
Regardless of whatever linear factor we scale the blockchain by, it is simple math to see that any exponential growth (even if for a short time) in usage will overwhelm the current network. If we ever intend to take bitcoin mainstream, we will most likely experience at least a short time of exponential growth…at least until we either reach an inherent limitation or until we saturate. As Pieter said earlier, FAPP right now the demand for payments might as well be infinite. We’re nowhere near the ability to service it all.
The block size issue is really a usability issue at this point. There are two fundamental things we need to solve:
1) There’s no model for how we’ll introduce a fee market, even though the design of Bitcoin fundamentally depends on fees for its survival (at least in the current form of the design.)
2) There’s no mechanism for how to perform fee bidding and estimation. Most wallets simply have no way to do this without serious usability problems.
If we’re going to talk about block fees, let’s keep it in the context of these relevant issues and not confound it with the scalability issue…these are two very different issues.
- Eric Lombrozo
> On Jun 26, 2015, at 1:44 PM, Owen Gunden <ogunden at phauna.org> wrote:
>
> On 06/26/2015 02:23 PM, Jeff Garzik wrote:
>> Failure to plan now for a hard fork increase 6(?) months in the future
>> produces that lumpy, unpredictable market behavior.
>>
>> The market has baked in the years-long behavior of low fees. From the
>> market PoV, inaction does lead to precisely that, a sudden change over
>> the span of a few months.
>
> Which market participants are you referring to?
>
> I entered the bitcoin market with open eyes, aware that it faces hard scalability challenges by design. I was also aware that because of these challenges, eventually transaction fees would have to rise.
>
> Nevertheless, I made the decision to invest because of the utility I gain from the anti-censorship, privacy, control, store of value, and security aspects of bitcoin -- many of which stem from decentralization, which others have demonstrated to be linked to the block size.
>
> On the other hand, there are undoubtedly other market participants who heard hype about "zero fee transactions to anywhere in the world", believed it would scale, and made (mal)investments as a result.
>
> As for how many market participants of each flavor, and how deep their respective pockets, who knows? My experience in markets has lead me to realize that it's never wise to assume I know what "the market" does and doesn't know. If Jeff Garzik is right about what the market has priced in, then yes, filled blocks will be rocking the boat. But who's to say that the smartest, biggest investors and traders don't already see this scaling problem, and have already priced it in? In this case, a sudden large increase in the block size is actually rocking the boat. The point is, you can't know either way, so trying to pre-empt the market in this way is erroneous.
>
> Regarding entrepreneurial investment specifically, why should we favor the entrepreneurs who require a more centralized bitcoin over those who were more considerate of the possibility of rising transaction fees when making their business models?
>
> In my mind, we should favor neither, which is why I'm basically in agreement with Pieter that this sense of "emergency" shouldn't really be a part of the debate.
>
> Not that I'm taking a stand on the specific block size issue either way. I just think this particular line of reasoning (presupposing what information the market has and has not already baked in) is unsound.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/0d541784/attachment.sig>

2023-06-07 17:40:13 CEST

- reply

📅 Original date posted:2015-06-25
📝 Original message:Wladimir is doing an amazing job under difficult circumstances. Give the guy a break, please.
- Eric Lombrozo
> On Jun 25, 2015, at 6:36 AM, s7r <s7r at sky-ip.org> wrote:
>
> I guess you mean Wladimir here. You are wrong, Wladimir does decide and
> if you look at the commit history on github.com for bitcoin core you
> will see, that he does actually decide and does it really good.
>
> He just does not want to decide (and he really should not) on CONSENSUS
> changes or protocol changes. This is totally different.
>
> Stop the analogy with "other open source projects". This is an open
> source project (the code part) but unlike any other open source projects
> which can just be forked, without affecting the other users, in bitcoin
> we need all the users to trust a single blockchain, so it'll have value.
> If some users fork the blockchain and change consensus rules, they are
> not just harming themselves, they are affecting ALL the users, since
> such a thing would have strong impact over the BTC/FIAT rate, affecting
> everyone in the ecosystem. There is economics involved here and human
> element, things which are hard to fix via code, even if the code is
> developed in open source style.
>
> It's one thing to decide to merge some patches, improve the code, etc.
> and another thing to decide for consensus rules when you literary play
> with 4 billion united states dollars of other people's money. This
> shouldn't be Wladimir's responsibility, it's just unfair for people to
> throw this on his shoulders.
>
> I do not under any circumstances suggest that the consensus should
> remain as it is now forever. We need to improve it, but this should not
> be on the maintainer. I've seen smart suggestions on this mail list
> where consensus changes can be made during a long period of time,
> through soft forks, where all users/miners/exchangers/merchants get the
> chance to choose / take action.
>
> On 6/25/2015 3:07 AM, Milly Bitcoin wrote:
>> I have seen this question asked many times. Most developers become
>> defensive and they usually give a very vague 1-sentence answer when this
>> question is asked. It seems to be it is based on personalities rather
>> than any kind of definable process. To have that discussion the
>> personalities must be separated out and answers like "such-and-such
>> wouldn't do that" don't really do much to advance the discussion. Also,
>> the incentive for new developers to come in is that they will be paid by
>> companies who want to influence the code and this should be considered
>> (some developers take this statement as an insult when it is just a
>> statement of the incentive process).
>>
>> The other problem you are having is the lead developer does not want to
>> be a "decider" when, in fact, he is a very significant decider. While
>> the users have the ultimate choice in a practical sense the chief
>> developer is the "decider." Now people don't want to get him upset so
>> nobody wants to push the issue or fully define the process. Now you are
>> left with a broken, unwritten/unspoken process. While this type of
>> thing may work with a small group of developers businesses/investors
>> looking in from the outside will see this as a risk.
>>
>> Until you get passed all the personality-based arguments you are going
>> to have a tough time defining a real process.
>>
>> Russ
>>
>>
>>
>>
>>
>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>> I would like to start a civil discussion on an undefined, or at least
>>> unwritten, portion of the BIP process. Who should get to vote on
>>> approval to commit a BIP implementation into Bitcoin Core? Is a
>>> simple majority of these voters sufficient for approval? If not, then
>>> what is?
>>>
>>> Raystonn
>>> _______________________________________________
>>> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/79673426/attachment.sig>

2023-06-07 17:39:15 CEST

- reply

📅 Original date posted:2015-06-20
📝 Original message:> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>>
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>> The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…
>>
>> I disagree with this premise. Please, don't take this as an argument
>> from authority fallacy, but I will cite Satoshi to express what I
>> think the assumptions while using the system should be:
>>
>> "As long as a majority of CPU power is controlled by nodes that are
>> not cooperating to attack the network, they'll generate the longest
>> chain and outpace attackers."
>>
>> I can't say for sure what was meant by "attacking the network" in this
>> context but I personally mean trying to rewrite valid and
>> proof-of-work-timestamped history.
>> Unconfirmed transactions are simply not part of history yet. Ordering
>> unconfirmed transactions in a consensus compatible way without a
>> universal clock is impossible, that's why we're using proof of work in
>> the first place.
>>
>> Alternative policies are NOT attacks on the network.
>
> Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.
>
> - Eric Lombrozo
I think the misunderstanding was in perhaps my earlier statement seemed like I was suggesting that it’s the protocol’s responsibility to protect merchants from double-spends. On the contrary - I think we agree - the protocol CANNOT make any guarantees to ANYONE until we do converge on a history. The “design” I speak of here is more on the merchant side.
- Eric Lombrozo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/1ecc0abe/attachment.sig>

2023-06-07 17:39:15 CEST

- reply

📅 Original date posted:2015-06-20
📝 Original message:> On Jun 20, 2015, at 4:16 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>> The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…
>
> I disagree with this premise. Please, don't take this as an argument
> from authority fallacy, but I will cite Satoshi to express what I
> think the assumptions while using the system should be:
>
> "As long as a majority of CPU power is controlled by nodes that are
> not cooperating to attack the network, they'll generate the longest
> chain and outpace attackers."
>
> I can't say for sure what was meant by "attacking the network" in this
> context but I personally mean trying to rewrite valid and
> proof-of-work-timestamped history.
> Unconfirmed transactions are simply not part of history yet. Ordering
> unconfirmed transactions in a consensus compatible way without a
> universal clock is impossible, that's why we're using proof of work in
> the first place.
>
> Alternative policies are NOT attacks on the network.
Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.
- Eric Lombrozo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/a7c74859/attachment.sig>

2023-06-07 17:39:15 CEST

- reply

📅 Original date posted:2015-06-20
📝 Original message:I should also add that I think many in this space believe they have assessed the risk as acceptable but haven’t really considered how to cap potential losses nor made contingency plans for when the inevitable attacks *do* come.
- Eric Lombrozo
> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>>
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>> The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…
>>
>> I disagree with this premise. Please, don't take this as an argument
>> from authority fallacy, but I will cite Satoshi to express what I
>> think the assumptions while using the system should be:
>>
>> "As long as a majority of CPU power is controlled by nodes that are
>> not cooperating to attack the network, they'll generate the longest
>> chain and outpace attackers."
>>
>> I can't say for sure what was meant by "attacking the network" in this
>> context but I personally mean trying to rewrite valid and
>> proof-of-work-timestamped history.
>> Unconfirmed transactions are simply not part of history yet. Ordering
>> unconfirmed transactions in a consensus compatible way without a
>> universal clock is impossible, that's why we're using proof of work in
>> the first place.
>>
>> Alternative policies are NOT attacks on the network.
>
> Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.
>
> - Eric Lombrozo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/bb11155c/attachment.sig>

2023-06-07 17:39:12 CEST

- reply

📅 Original date posted:2015-06-21
📝 Original message:> On Jun 21, 2015, at 1:41 AM, Btc Drak <btcdrak at gmail.com> wrote:
>
> Eric,
>
> BitPay clearly do understand the risks of 0-conf. In case you were not aware BitPay does not particularly "accept zero confirm transactions". When a payment is seen on the network the payment screen reports the invoice has been paid, but that's front-end user facing. On the back end it's marked as paid but the API exposes the the confirmation status allowing the merchant to make business decisions about when to progress to fulfilment. A good example of this is Neteller (a sort of paypal variant) which allows one to fund the account with fiat using Bitcoin, via Bitpay. When you pay the bitpay invoice, your account is marked as payment pending until there are some confirmations.
>
I am glad to hear that. Yes, it absolutely makes sense to let the merchant to make business decisions still pending confirmation (i.e. should I actually ship?)
> Coinbase does not expose the confirmation status and from what I understand (not checked myself) they guarantee payment to merchants for 0-confirm, regardless of whether they confirm or not.
Then Coinbase is essentially taking on the role of an insurer…are they taking the appropriate precautions to limit potential losses? Can they make up for these losses with fees? And if not (or if they don’t really have a quantifiable risk model) could they survive a worst-case scenario with at most a surface wound? (i.e. a systemic attack involving many machines in many different places all attacking at once).
It would be absolutely the height of idiocy to guarantee payment on merchandise that has yet to ship, i.e. So I hope these reports are wrong :)
- Eric Lombrozo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/e71b8a85/attachment.sig>

2023-06-07 17:39:11 CEST

- reply

📅 Original date posted:2015-06-21
📝 Original message:> On Jun 21, 2015, at 12:42 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>
>> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgarzik at bitpay.com <mailto:jgarzik at bitpay.com>> wrote:
>>
>> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo at gmail.com <mailto:elombrozo at gmail.com>> wrote:
>> but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient
>>
>> Can you be specific? What precise technical steps would you have BitPay and Coinbase do? We upgrade our stuff to... what exactly?
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/ <https://bitpay.com/>
> Thanks for asking *the* question, Jeff. We often get caught up in these philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the security policy.
>
> If you must accept zero confirmation transactions, there are a few concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do not accept them for very high priced goods…especially if they require physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…) the ability to shut the user out if a double-spend is detected.
> 4) collect legal information on purchasers (or have the merchants collect this information) so you have someone to go after if they try to screw you
> 5) create a risk profile for users…and flag suspicious behavior (i.e. someone trying to purchase a bunch of stuff that totally doesn’t fit into their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is probably pretty hard to obtain since statistics are generally of little use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to see an attack you can immediately disable all zero confirmation transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple network nodes…check them against one another.
>
>
> As for software tools to accomplish these things, we can talk about that offline :)
>
>
> - Eric Lombrozo
>
>
>
>
I should also point out that pretty much all of these suggestions (except for maybe 8) would apply to ANY payment system…they are NOT specific to Bitcoin whatsoever. Any serious payment processor should have these sorts of policies engrained as part of company culture…or else one day (probably not too long from now) you’ll be out of business. The mere suggestion that changing relay policy would pose significant threats to the bottom line of a payment processor is about the height of amateurishness, IMHO.
- Eric Lombrozo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/02d84c3a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/02d84c3a/attachment.sig>

2023-06-07 17:39:11 CEST

- reply

📅 Original date posted:2015-06-21
📝 Original message:> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo at gmail.com <mailto:elombrozo at gmail.com>> wrote:
> but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient
>
> Can you be specific? What precise technical steps would you have BitPay and Coinbase do? We upgrade our stuff to... what exactly?
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/ <https://bitpay.com/>
Thanks for asking *the* question, Jeff. We often get caught up in these philosophical debates…but at the end of the day we need something concrete.
Even more important than the specific software you’re using is the security policy.
If you must accept zero confirmation transactions, there are a few concrete things you can do to reduce your exposure:
1) limit the transaction amounts for zero confirmation transactions - do not accept them for very high priced goods…especially if they require physical shipping.
2) limit the total amount of unconfirmed revenue you’ll tolerate at any given moment - if the amount is exceeded, require confirmations.
3) give merchants of subscription services (i.e. servers, hosting, etc…) the ability to shut the user out if a double-spend is detected.
4) collect legal information on purchasers (or have the merchants collect this information) so you have someone to go after if they try to screw you
5) create a risk profile for users…and flag suspicious behavior (i.e. someone trying to purchase a bunch of stuff that totally doesn’t fit into their purchasing habits).
6) get insurance (although right now reasonably-priced insurance is probably pretty hard to obtain since statistics are generally of little use…we’re entering uncharted territory).
7) set up a warning system and a “panic” button so that if you start to see an attack you can immediately disable all zero confirmation transactions system-wide.
8) independently verify all inbound transactions and connect to multiple network nodes…check them against one another.
As for software tools to accomplish these things, we can talk about that offline :)
- Eric Lombrozo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/95ab06d4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/95ab06d4/attachment.sig>

2023-06-07 17:39:11 CEST

- reply

📅 Original date posted:2015-06-20
📝 Original message:One more thing I would like to add to this thread: I want to make it unequivocally clear that I believe what is making double-spends easier has relatively little to do with the protocol and almost everything to do with poor software and poor security policy on the merchant end. Perhaps it isn’t prudent to push out changes to the relay policy that make these exploits even easier right now - but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient so that we have more room for changes on things like relay policy without significant disruption to the network.
- Eric Lombrozo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/2a4ae83e/attachment.sig>

2023-06-07 17:39:10 CEST

- reply

📅 Original date posted:2015-06-20
📝 Original message:> On Jun 20, 2015, at 5:27 PM, justusranvier at riseup.net wrote:
>
> Signed PGP part
> On 2015-06-20 19:19, Eric Lombrozo wrote:
> >> On Jun 20, 2015, at 4:37 PM, justusranvier at riseup.net wrote:
> >>
> >> Signed PGP part
> >> On 2015-06-20 18:20, Jorge Timón wrote:
> >> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo at gmail.com>
> >> > wrote:
> >> >> If we want a non-repudiation mechanism in the protocol, we should
> >> >> explicitly define one rather than relying on “prima facie”
> >> >> assumptions. Otherwise, I would recommend not relying on the existence
> >> >> of a signed transaction as proof of intent to pay…
> >> >
> >> > Non-repudiation can be built on top of the payment protocol layer.
> >>
> >>
> >> Non-repudiation is an intrinsic property of the ECDSA signatures which
> >> Bitcoin uses - it's not a feature that needs to be built.
> >>
> >> There's no way to accidentally sign a transaction and accidentally
> >> announce it publicly. There is no form of third-party error that can
> >> result in a payee receiving an erroneous contract.
> >>
> >>
> >
> > Justus,
> >
> > We don’t even have a concept of identity in the Bitcoin protocol, let
> > alone non-repudiation. What good is non-repudiation if there’s no way
> > to even associate a signature with a legal entity?
> >
> > Sure, we could use the ECDSA signatures in transactions as part of a
> > non-repudiation scheme - but the recipient would have to also have a
> > means to establish the identity of the sender and associate it with
> > the the transaction.
> >
> >
> > Furthermore, in light of the fact that there *are* fully legitimate
> > use cases for sending conflicting transactions…and the fact that
> > determination of intent isn’t always entirely clear…we should refrain
> > from attaching any further significance transaction signatures other
> > than that “the sender was willing to have it included in the
> > blockchain if a miner were to have seen it and accepted it…but perhaps
> > the sender would have changed their mind before it actually did get
> > accepted.”
>
> Bitcoin has no concept of identity, but in any type of commercial
> transaction the parties involved must know some minimal amount of
> identity information in order to transact at all.
>
> Except for some identifiable special cases, I think a payee is perfectly
> justified in treating a double spend of a payment sent to them as part
> of a commercial transaction as a fraud attempt and employing whatever
> non-Bitcoin recourse mechanisms, if any, they have access to.
>
> From the perspective of the network, the obviously correct action for
> any node or miner is to relay the first version of any transaction they
> see. The primary purpose of mining is to resolve this
> otherwise-unresolvable problem of determining which transaction among a
> set of conflicting transactions happened first.
>
> If a node or miner wants to deviate from the obviously correct
> behaviour, and if they want to avoid harming the value of the network,
> they should be particularly careful to make sure their deviation from
> "first seen" doesn't introduce harmful unintended side effects, like
> making fraud easier.
>
The contract between the buyer and seller is actually outside the Bitcoin network. Yes, a merchant that gets cheated could seek some other recourse in such an event…but the behavior you’re claiming as “obviously correct” is NOT obviously correct. In fact, there are arguments against this “obviously correct” way even if we were to accept the premise that the signature implies a promise to pay (which I think many reasonable individuals would also dispute). For instance, by relaying conflicting transactions it makes it potentially easier for others to discover the double-spend attempt (of course, this requires wallets to not be lazy about this…perhaps such relays could be flagged or placed in a special message type).
- Eric Lombrozo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/ccb0176e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/ccb0176e/attachment.sig>

2023-06-07 17:39:10 CEST

- reply

📅 Original date posted:2015-06-20
📝 Original message:> On Jun 20, 2015, at 4:37 PM, justusranvier at riseup.net wrote:
>
> Signed PGP part
> On 2015-06-20 18:20, Jorge Timón wrote:
> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo at gmail.com>
> > wrote:
> >> If we want a non-repudiation mechanism in the protocol, we should
> >> explicitly define one rather than relying on “prima facie”
> >> assumptions. Otherwise, I would recommend not relying on the existence
> >> of a signed transaction as proof of intent to pay…
> >
> > Non-repudiation can be built on top of the payment protocol layer.
>
>
> Non-repudiation is an intrinsic property of the ECDSA signatures which
> Bitcoin uses - it's not a feature that needs to be built.
>
> There's no way to accidentally sign a transaction and accidentally
> announce it publicly. There is no form of third-party error that can
> result in a payee receiving an erroneous contract.
>
>
Justus,
We don’t even have a concept of identity in the Bitcoin protocol, let alone non-repudiation. What good is non-repudiation if there’s no way to even associate a signature with a legal entity?
Sure, we could use the ECDSA signatures in transactions as part of a non-repudiation scheme - but the recipient would have to also have a means to establish the identity of the sender and associate it with the the transaction.
Furthermore, in light of the fact that there *are* fully legitimate use cases for sending conflicting transactions…and the fact that determination of intent isn’t always entirely clear…we should refrain from attaching any further significance transaction signatures other than that “the sender was willing to have it included in the blockchain if a miner were to have seen it and accepted it…but perhaps the sender would have changed their mind before it actually did get accepted.”
- Eric Lombrozo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/9dd48b8f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/9dd48b8f/attachment.sig>

2023-06-07 17:39:08 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay…
> On Jun 19, 2015, at 9:36 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
>
> On Friday, 19 June 2015, at 3:53 pm, justusranvier at riseup.net wrote:
>> I'd also like to note that "prima facie" doesn't mean "always", it means
>> that "the default assumption, unless proven otherwise."
>
> Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/d461c2f9/attachment.sig>

2023-06-07 17:39:07 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:OK, a few things here:
The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…and relaxing this assumption without adequately assessing the risk (i.e. I’ve never been hacked before so I can assume it’s safe) is extremely dangerous at best and just horrid security practice at worst. Your users might not thank you for not getting hacked - but they surely will not like it when you DO get hacked…and lack a proper recovery plan.
Furthermore, the protocol itself makes no assumptions regarding the intentions behind someone signing two conflicting transactions. There are many potential use cases where doing so could make a lot of sense. Had the protocol been designed along the lines of, say, tendermint…where signing multiple conflicting blocks results in loss of one’s funds…then the protocol itself disincentivizes the behavior without requiring any sort of altruistic, moralistic assumptions. That would also mean we’d need a different mechanism for the use cases that things like RBF address.
Thirdly, taken to the extreme, the viewpoint of “signing a conflicting transaction is fraud and vandalism” means that if for whatever reason you attempt to propagate a transaction and nobody mines it for a very long time, you’re not entitled to immediately reclaim those funds…they must remain in limbo forever.
- Eric Lombrozo
> On Jun 19, 2015, at 8:11 AM, Peter Todd <pete at petertodd.org> wrote:
>
> On Fri, Jun 19, 2015 at 03:00:57PM +0000, justusranvier at riseup.net wrote:
>> On 2015-06-19 10:39, Peter Todd wrote:
>>
>> Yesterday F2Pool, currently the largest pool with 21% of the hashing
>> power, enabled full replace-by-fee (RBF) support after discussions
>> with
>> me. This means that transactions that F2Pool has will be replaced if
>> a
>> conflicting transaction pays a higher fee. There are no requirements
>> for
>> the replacement transaction to pay addresses that were paid by the
>> previous transaction.
>>
>>
>> Intentional fraud is a bad thing to add to a financial protocol.
>>
>> A user who creates conflicting transactions, one that pays someone else
>> and another which does not pay them, and broadcasts both of them, has
>> just self-incriminated themselves by producing prima facie evidence of
>> fraud.
>
> Depends.
>
> If you ask me to pay you 1BTC at address A and I create tx1 that pays
> 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
> that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
> defrauding you, I'm just reducing the value of my change address to pay
> a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
> tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
>
> Yet from the point of view of an external observer they have no idea why
> the transaction outputs reduced in size, nor any way of knowing if fraud
> did or did not occur.
>
> Equally, maybe you tell me "Actually, just give me 0.5BTC to cancel out
> that debt", in which case I'm not breaking any contract at all by giving
> you less money than I first promised - the contract has changed.
>
> Again, none of this can or should be observable to anyone other than the
> parties directly involved.
>
>> It may be the case that since Bitcoin spans multiple legal jurisdictions
>> and can be use anonymously that the victims of such fraud can not rely
>> on legal recourse, and it may also be the case that proof of work is how
>> Bitcoin deals with the aforementioned factors, but regardless
>> un-prosecutable fraud is still fraud and anyone who encourages it should
>> be recognied as a bad actors.
>>
>> Committing vandalism and encouraging fraud to prove a point may be
>> something the network can't stop on a technical level, but there's no
>> reason not to call it out for what it is.
>
> What do you think of Bitcoin XT then? It relays double-spends, which
> makes it much easier to get double-spends to miners than before. In
> particular you see a lot of zero-fee transactions being replaced by
> fee-paying transactions, relayed through Bitcoin XT nodes and then
> mined. Is that encouraging fraud?
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000003932458055c68d4ee2b6d68441c4764efbdf6b0b1683717
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/7b6748ec/attachment.sig>