Sergio Demian Lerner [ARCHIVE]

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

Public Key

npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f

Profile Code

nprofile1qqsykwrqxsy0t0sqyzgjzr5xnfx2sm7z4g0l6zr3qd4qv6qx3mnzdmss5fvk8

Author Public Key

npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f

Show more details

Last Notes

2023-06-07 18:28:00

- reply

📅 Original date posted:2020-12-31
📝 Original message:Hi Roben,
It's an interesting proposal, but I have two issues with it, one technical
and one philosophical.
On the technical side, I don't understand how your proposal prevents miners
proposing a peg-out for an invalid sidechain fork which is not made
available to the nodes (there are missing blocks). It seems that the system
would need to allow users to challenge miners to make available full
sidechain blocks that are missing, which really complicates the protocol.
On the philosophical side, as you mentioned, it is very limited in the
types of sidechains it can verify. I won't be able to verify RSK
(merge-mined with Bitcoin, but with different block format and different
functionality). It cannot verify a zCash-like sidechain for the same
reasons. Therefore it is strictly a payment scalability solution.
Drivechains, on the other hand, enable many new use cases apart from
scaling, which have a much lower level of complexity (if implemented
correctly).
Since the inception of RSK sidechain, I suggested in its white-paper that
sidechains should be designed to support an hybrid peg-out system, based on
both a large multisig AND a drivechain, where both groups need to agree for
the peg-out to occur. It's a censorship/security trade-off that most users
would be willing to accept until a trusted-setup-free SNARK-like based
solution is finally available.
Until we have a sidechain-selectable SNARK-like succinct verification of
any block state transition function, having a single succint proof to cover
the whole sidechain validity, as in Coda (now renamed Mina), drivechains
are the low-hanging-fruit.
regards
On Thu, Dec 31, 2020 at 7:01 PM Ruben Somsen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi everyone,
>
> This post describes a fully decentralized two-way peg sidechain design.
> Activating new sidechains requires a soft fork, hence the name softchains.
> The key aspect is that all softchains are validated by everyone via
> Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus
> mechanism that only requires the validation of disputed blocks. This does
> increase the validation burden of mainchain full nodes, but only by a
> minimal amount (~100MB per chain per year). It's similar to drivechains[0],
> but without the major downside of having to rely on miners, since all
> Bitcoin full node users can efficiently validate each sidechain.
>
>
> Proof-of-Work Fraud Proofs
>
> Last year I posted the idea of PoW FP to the Bitcoin mailing list[1][2].
> The idea is that we can use the existence of a fork in Bitcoin's PoW as
> evidence that a block might be invalid (i.e. a proof of potential fraud).
> Whenever this occurs, we download the block in question to verify whether
> it was valid (and available), and reject it if it was not. We forego the
> need for maintaining a UTXO set with UTXO set commitments (such as
> utreexo[3]), by assuming that the commitment inside the last block to exist
> in both forks is valid. As a result, we only need to download as many
> blocks (and their corresponding UTXO set proofs) as there are orphans,
> which lowers the validation costs considerably compared to running a full
> node.
>
> In the past 4 months, Forkmonitor has registered 11 stale and invalid
> blocks[4]. Extrapolating from that data, a PoW FP node verifying Bitcoin
> consensus would have to download and verify a little over 100MB per year in
> order to have consensus guarantees that come close to that of a full node:
> - All PoW headers (~4MB per year)
> - 3 x 11 = 33 full blocks (~2MB x 33 = 66MB)
> - UTXO merkle proofs (~1MB x 33 = 33MB with utreexo)
>
> The reason consensus is considered slow, is because we need to allow time
> for a honest PoW minority to fork away from an invalid chain. If we assume
> only 1% of all miners are honest, this means consensus slows down by 100x.
> If you are normally satisfied waiting for 6 confirmations, you now need to
> wait 600 confirmations. The longer you wait, the less honest miners you
> need.
>
>
> Softchains
>
> In order to have two-way pegged sidechains, you need a succinct method for
> proving to the mainchain that a peg-out is valid. PoW FP provides exactly
> that -- a low-bandwidth way of determining if a chain, and thus a peg-out,
> is valid. The slowness of PoW FP consensus is not an issue, as peg-outs can
> be made arbitrarily slow (e.g. one year).
>
> The safest design would be a set of softchains that shares its consensus
> code with Bitcoin Core, with the addition of UTXO set commitments, and
> disabling non-taproot address types to minimize certain resource usage
> issues[5]. All users validate the mainchain as usual with their full node,
> and all softchains are validated with PoW FP consensus. If a user is
> interested in directly using a specific softchain, they should run it as a
> full node in order to get fast consensus.
>
> Peg-ins occur by freezing coins on the mainchain and assigning them to a
> softchain. Peg-outs occur by creating a mainchain transaction that points
> to a peg-out transaction on a softchain and waiting for a sufficient number
> of mainchain confirmations. If the peg-out transaction remains part of the
> softchain according to PoW FP consensus, the coins become spendable.
>
> The peg-in/peg-out mechanism itself would require a soft fork (the exact
> design is an open question), and subsequently every softchain that gets
> activated will also require a soft fork.
>
>
> Potential dangers
>
> Softchain consensus still requires a form of validation from mainchain
> users, which means that consensus bugs can have an adverse effect. In
> particular, if a softchain suffers from a non-deterministic consensus bug,
> it may be the case that a majority accepts a peg-in, while a minority
> rejects it. This specific scenario could cause a chain split in mainchain
> consensus. This is why it would be safest to base softchain designs on
> Bitcoin Core.
>
> Similarly, it can theoretically be possible that a softchain gets a major
> reorg, invalidating a peg-out right as it would have become accepted on the
> mainchain, thus splitting consensus. The slow peg-out process makes this
> increasingly unlikely, but not impossible. One thing that might help (or
> perhaps only make it worse) is introducing a consensus rule that disallows
> reorgs that are bigger than half the peg-out time (e.g. half a year, if the
> peg-out is one year). This kind of rule does not actually solve this
> consensus problem, but instead pushes the problem forward so it plays out
> first on the softchain, giving time to take action before the problem
> affects the mainchain.
>
> It is also important that each softchain produces a non-trivial amount of
> PoW, because if the difficulty is too low, the cost of creating forks and
> increasing the resource usage of PoW FP consensus goes down. It may
> therefore make sense to have a minimum accepted difficulty for softchain
> blocks (slowing down the chain when fees are not sufficient). Merged Mining
> could also help here, since that would allow the softchains to potentially
> receive the same hashrate as Bitcoin (assuming all miners participate), but
> of course this would also put an additional validation burden on miners.
>
>
> In closing
>
> It may turn out that the consensus risks outlined above make this
> prohibitively risky, but at the very least it seems worth exploring the
> possibilities. At a minimum it would provide more opt-in block space, and
> it could potentially open the door to chains with entirely different
> consensus rules.
>
> Thank you for taking the time to read and comprehend my work. I will
> happily answer any questions and I look forward to any feedback on issues
> that I might have overlooked, and ideas on mitigating problems to ensure
> maximum safety.
>
> Hopefully this will bring decentralized two-way peg sidechains one step
> closer to becoming a reality.
>
> Happy new year, everyone.
>
>
> -- Ruben Somsen
>
>
>
> This post is mirrored and kept up-to-date here:
> https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1
>
>
> [0] Drivechains
> https://www.drivechain.info/
>
> [1] PoW FP
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html
>
> [2] PoW FP without a soft fork
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017287.html
>
> [3]: utreexo
> https://eprint.iacr.org/2019/611.pdf
>
> [4]: Forkmonitor
> https://forkmonitor.info/notifications
>
> [5]: Harding on worst-case utreexo
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017298.html
> _______________________________________________
> 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/20201231/3ee7d3df/attachment-0001.html>

2023-06-07 18:20:06

- reply

📅 Original date posted:2019-08-07
📝 Original message:Seems to be comparable to the proposed "Tick Method" from 2013:
https://bitcointalk.org/index.php?topic=307211.msg3308565#msg3308565
However I remember that someone told me the tick method had a flaw..
On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Does revaulting vault up with the same keys, or new ones?
>
> Are they new derivation paths on the same key?
>
> Would love some expanded explanation on how you’re proposing this would
> work.
>
> Thanks,
> Dustin
>
> On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> One of the biggest problems with the vault scheme (besides all of the
>> setup data that has to be stored for a long time) is an attacker that
>> silently steals the hot wallet private key and waits for the vault's
>> owner to make a delayed-spend transaction to initiate a withdrawal
>> from the vault. If the user was unaware of the theft of the key, then
>> the attacker could steal the funds after the delay period.
>>
>> To mitigate this, it is important to choose a stipend or withdrawal
>> amount per withdrawal period like x% of the funds. This limits the
>> total stolen funds to x% because once the funds are stolen the user
>> would know their hot key is compromised, and the user would know to
>> instead use one of the other clawback paths during all of the future
>> withdrawal delay periods instead of letting the delay timeout all the
>> way to the (stolen) default/hot key.
>>
>> The reason why a loss limiter is the way to go is because there's
>> currently no way (that I am aware of, without an upgrade) to force an
>> attacker to reveal his key on the blockchain while also forcing the
>> attacker to use a timelock before the key can spend the coins. I am
>> curious about what the smallest least invasive soft-fork would be for
>> enabling this kind of timelock. There are so many covenant proposals
>> at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,
>> ....). Or there's crazy things like a fork that enables a transaction
>> mode where the (timelock...) script of the first output is
>> automatically prefixed to any of the other scripts on any of the other
>> outputs when an input tries to spend in the future. A thief could add
>> his key to a new output on the transaction and try to spend (just like
>> a user would with a fresh/rotated key), but the OP_CSV would be
>> automatically added to his script to implement the public observation
>> delay window.
>>
>> Also, there was other previous work that I was only informed about
>> today after posting my proposal, so I should mention these as related
>> work:
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html
>>
>> https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better
>> https://www.youtube.com/watch?v=diNxp3ZTquo
>> https://bitcointalk.org/index.php?topic=5111656
>>
>> - Bryan
>> http://heybryan.org/
>> _______________________________________________
>> 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/20190807/881ebc3d/attachment.html>

2023-06-07 18:14:05

- reply

📅 Original date posted:2018-08-14
📝 Original message:Hi,
While fixing RSK's SPV bridge I came up with an idea to fix the
MERKLEBLOCK command to prevent rogue peers from attacking SPV peers using
Bitcoin's Merkle tree structure flaws. The most annoying attack is the one
that tries to confuse a victim peer into thinking a transaction is an inner
node, extending such node with a new right-sided branch with a fake
transaction (*) .
The old idea to soft-fork Bitcoin to make invalid 64-byte transactions is
attractive, but also a coordination problem that could be avoided with this
new proposal.
The idea is simple, and it's not a fork, but a network protocol improvement.
Let A be the hash digest that must be combined with the hash digest B, such
that the upper node hash is SHA256(SHA256(A | B)).
Therefore A = SHA256(SHA256(X)) and B = SHA256(SHA256(Y)), and X and Y are
either Bitcoin transactions or other inner nodes.
Instead of storing A, the merkleblock structure should store a pre-image of
A, or SHA256(X).
If the block only has the coinbase, nothing is done.
The pre-image change could be done to both left and right hashes, but it's
enough to do it to all left-side hashes that do not have children in the
partial merkle tree structure (let's call them terminal hahes. to avoid
confusion with leaf hashes).
Verifiers (SPV nodes) would apply a single SHA256() operation to the
left-sided terminal hashes before combining them. The cost to the verifier
is in the worse case only 33% more.
This basically limits the attacker's ability to supply chosen-hash digests
in order to build a transaction. Because the left side contains most of the
previn hash, the attacker would need to bruteforce a huge space (about 208
bits) in order to come up with a pre-image that maps to a owned previn.
Meet-in-the-middle attacks would be expensive as UTXOs are not free.
To implement this change, a new command MERKLEBLOCK2 could be implemented
or the protocol version could be used to differentiate between the two
modes of the MERKLEBLOCK command.
If the idea gets community support, I may write the BIP/code or invite
anyone to do it.
regards
(*)
https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180814/51d0f150/attachment.html>

2023-06-07 18:14:04

- reply

📅 Original date posted:2018-08-09
📝 Original message:Hi,
While fixing RSK's SPV bridge I came up with an idea to fix the
MERKLEBLOCK command to prevent rogue peers from attacking SPV peers using
Bitcoin's Merkle tree structure flaws. The most annoying attack is the one
that tries to confuse a victim peer into thinking a transaction is an inner
node, extending such node with a new right-sided branch with a fake
transaction (*) .
The old idea to soft-fork Bitcoin to make invalid 64-byte transactions is
attractive, but also a coordination problem that could be avoided with this
new proposal.
The idea is simple, and it's not a fork, but a network protocol improvement.
Let A be the hash digest that must be combined with the hash digest B, such
that the upper node hash is SHA256(SHA256(A | B)).
Therefore A = SHA256(SHA256(X)) and B = SHA256(SHA256(Y)), and X and Y are
either Bitcoin transactions or other inner nodes.
Instead of storing A, the merkleblock structure should store a pre-image of
A, or SHA256(X).
If the block only has the coinbase, nothing is done.
The pre-image change could be done to both left and right hashes, but it's
enough to do it to all left-side hashes that do not have children in the
partial merkle tree structure (let's call them terminal hahes. to avoid
confusion with leaf hashes).
Verifiers (SPV nodes) would apply a single SHA256() operation to the
left-sided terminal hashes before combining them. The cost to the verifier
is in the worse case only 33% more.
This basically limits the attacker's ability to supply chosen-hash digests
in order to build a transaction. Because the left side contains most of the
previn hash, the attacker would need to bruteforce a huge space (about 208
bits) in order to come up with a pre-image that maps to a owned previn.
Meet-in-the-middle attacks would be expensive as UTXOs are not free.
To implement this change, a new command MERKLEBLOCK2 could be implemented
or the protocol version could be used to differentiate between the two
modes of the MERKLEBLOCK command.
If the idea gets community support, I may write the BIP/code or invite
anyone to do it.
regards
(*)
https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180809/c747d596/attachment-0001.html>

2023-06-07 18:12:58

- reply

📅 Original date posted:2018-06-09
📝 Original message:Here is our internal report, if you want more details on the problem.
(our reported attack complexity may slightly differ from what Peter has
provided, but the attack complexity depends on the funds the attacker is
willing to lock).
regards,
Sergio.
On Sat, Jun 9, 2018 at 2:21 PM Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
> Also it must be noted that an attacker having only 1.3M USD that can
> brute-force 72 bits (4 days of hashing on capable ASICs) can perform the
> same attack, so the attack is entirely feasible and no person should accept
> more than 1M USD using a SPV wallet.
>
> Also the attack can be repeated: once you create the "extension point"
> block, you can attack more and more parties without any additional
> computation.
>
>
> On Sat, Jun 9, 2018 at 1:03 PM Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
>
>> Hi Peter,
>> We reported this as CVE-2017-12842, although it may have been known by
>> developers before us.
>> There are hundreds of SPV wallets out there, without even considering
>> other more sensitive systems relying on SPV proofs.
>> As I said we, at RSK, discovered this problem in 2017. For RSK it's very
>> important this is fixed because our SPV bridge uses SPV proofs.
>> I urge all people participating in this mailing list and the rest of the
>> Bitcoin community to work on this issue for the security and clean-design
>> of Bitcoin.
>>
>> My suggestion is to use in the version bits 4 bits indicating the tree
>> depth (-1), as a soft-fork, so
>> 00=1 depth,
>> 0F = 16 depth (maximum 64K transactions). Very clean.
>>
>> The other option is to ban transaction with size lower or equal to 64.
>>
>> Best regards,
>> Sergio.
>>
>> On Sat, Jun 9, 2018 at 5:31 AM Bram Cohen via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> So are you saying that if fully validating nodes wish to prune they can
>>> maintain the ability to validate old transactions by cacheing the number of
>>> transactions in each previous block?
>>>
>>> On Thu, Jun 7, 2018 at 3:20 PM, Peter Todd <pete at petertodd.org> wrote:
>>>
>>>> On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote:
>>>> > Are you proposing a soft fork to include the number of transactions
>>>> in a
>>>> > block in the block headers to compensate for the broken Merkle
>>>> format? That
>>>> > sounds like a good idea.
>>>> >
>>>> > On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev <
>>>> > bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> >
>>>> > > It's well known that the Bitcoin merkle tree algorithm fails to
>>>> distinguish
>>>> > > between inner nodes and 64 byte transactions, as both txs and inner
>>>> nodes
>>>> > > are
>>>> > > hashed the same way. This potentially poses a problem for tx
>>>> inclusion
>>>> > > proofs,
>>>> > > as a miner could (with ~60 bits of brute forcing) create a
>>>> transaction that
>>>> > > committed to a transaction that was not in fact in the blockchain.
>>>> > >
>>>> > > Since odd-numbered inner/leaf nodes are concatenated with
>>>> themselves and
>>>> > > hashed
>>>> > > twice, the depth of all leaves (txs) in the tree is fixed.
>>>> > >
>>>> > > It occured to me that if the depth of the merkle tree is known, this
>>>> > > vulnerability can be trivially avoided by simply comparing the
>>>> length of
>>>> > > the
>>>> > > merkle path to that known depth. For pruned nodes, if the depth is
>>>> saved
>>>> > > prior
>>>> > > to pruning the block contents itself, this would allow for
>>>> completely safe
>>>> > > verification of tx inclusion proofs, without a soft-fork; storing
>>>> this
>>>> ^^^^^^^^^^^^^^^^^^^
>>>>
>>>> Re-read my post: I specifically said you do not need a soft-fork to
>>>> implement
>>>> this. In fact, I think you can argue that this is an accidental
>>>> feature, not a
>>>> bug, as it further encourages the use of safe full verifiaction rather
>>>> than
>>>> unsafe lite clients.
>>>>
>>>> --
>>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/9f4f5b1f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Vulnerability in Bitcoin Merkle Tree Design.pdf
Type: application/pdf
Size: 402454 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/9f4f5b1f/attachment-0001.pdf>

2023-06-07 18:12:58

- reply

📅 Original date posted:2018-06-09
📝 Original message:Yo can fool a SPV wallet even if it requires a thousands confirmations
using this attack, and you don't need a Sybil attack, so yes, it impacts
SPV wallets also. The protections a SPV node should have to prevent this
attack are different, so it must be considered separately.
It should be said that a SPV node can avoid accepting payments if any
Merkle node is at the same time a valid transaction, and that basically
almost eliminates the problem.
SPV Wallet would reject valid payments with a astonishingly low probability.
On Sat, Jun 9, 2018 at 2:45 PM Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jun 09, 2018 at 02:21:17PM +0200, Sergio Demian Lerner wrote:
> > Also it must be noted that an attacker having only 1.3M USD that can
> > brute-force 72 bits (4 days of hashing on capable ASICs) can perform the
> > same attack, so the attack is entirely feasible and no person should
> accept
> > more than 1M USD using a SPV wallet.
>
> That doesn't make any sense. Against a SPV wallet you don't need that
> attack;
> with that kind of budget you can fool it by just creating a fake block at
> far
> less cost, along with a sybil attack. Sybils aren't difficult to pull off
> when
> you have the budget to be greating fake blocks.
>
> > Also the attack can be repeated: once you create the "extension point"
> > block, you can attack more and more parties without any additional
> > computation.
>
> That's technically incorrect: txouts can only be spent once, so you'll
> need to
> do 2^40 work each time you want to repeat the attack to grind the matching
> part
> of the prevout again.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/567e1527/attachment.html>

2023-06-07 18:12:57

- reply

📅 Original date posted:2018-06-09
📝 Original message:Hi Peter,
We reported this as CVE-2017-12842, although it may have been known by
developers before us.
There are hundreds of SPV wallets out there, without even considering other
more sensitive systems relying on SPV proofs.
As I said we, at RSK, discovered this problem in 2017. For RSK it's very
important this is fixed because our SPV bridge uses SPV proofs.
I urge all people participating in this mailing list and the rest of the
Bitcoin community to work on this issue for the security and clean-design
of Bitcoin.
My suggestion is to use in the version bits 4 bits indicating the tree
depth (-1), as a soft-fork, so
00=1 depth,
0F = 16 depth (maximum 64K transactions). Very clean.
The other option is to ban transaction with size lower or equal to 64.
Best regards,
Sergio.
On Sat, Jun 9, 2018 at 5:31 AM Bram Cohen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> So are you saying that if fully validating nodes wish to prune they can
> maintain the ability to validate old transactions by cacheing the number of
> transactions in each previous block?
>
> On Thu, Jun 7, 2018 at 3:20 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote:
>> > Are you proposing a soft fork to include the number of transactions in a
>> > block in the block headers to compensate for the broken Merkle format?
>> That
>> > sounds like a good idea.
>> >
>> > On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev <
>> > bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > > It's well known that the Bitcoin merkle tree algorithm fails to
>> distinguish
>> > > between inner nodes and 64 byte transactions, as both txs and inner
>> nodes
>> > > are
>> > > hashed the same way. This potentially poses a problem for tx inclusion
>> > > proofs,
>> > > as a miner could (with ~60 bits of brute forcing) create a
>> transaction that
>> > > committed to a transaction that was not in fact in the blockchain.
>> > >
>> > > Since odd-numbered inner/leaf nodes are concatenated with themselves
>> and
>> > > hashed
>> > > twice, the depth of all leaves (txs) in the tree is fixed.
>> > >
>> > > It occured to me that if the depth of the merkle tree is known, this
>> > > vulnerability can be trivially avoided by simply comparing the length
>> of
>> > > the
>> > > merkle path to that known depth. For pruned nodes, if the depth is
>> saved
>> > > prior
>> > > to pruning the block contents itself, this would allow for completely
>> safe
>> > > verification of tx inclusion proofs, without a soft-fork; storing this
>> ^^^^^^^^^^^^^^^^^^^
>>
>> Re-read my post: I specifically said you do not need a soft-fork to
>> implement
>> this. In fact, I think you can argue that this is an accidental feature,
>> not a
>> bug, as it further encourages the use of safe full verifiaction rather
>> than
>> unsafe lite clients.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/b0d55588/attachment-0001.html>

2023-06-07 18:12:57

- reply

📅 Original date posted:2018-06-09
📝 Original message:Also it must be noted that an attacker having only 1.3M USD that can
brute-force 72 bits (4 days of hashing on capable ASICs) can perform the
same attack, so the attack is entirely feasible and no person should accept
more than 1M USD using a SPV wallet.
Also the attack can be repeated: once you create the "extension point"
block, you can attack more and more parties without any additional
computation.
On Sat, Jun 9, 2018 at 1:03 PM Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
> Hi Peter,
> We reported this as CVE-2017-12842, although it may have been known by
> developers before us.
> There are hundreds of SPV wallets out there, without even considering
> other more sensitive systems relying on SPV proofs.
> As I said we, at RSK, discovered this problem in 2017. For RSK it's very
> important this is fixed because our SPV bridge uses SPV proofs.
> I urge all people participating in this mailing list and the rest of the
> Bitcoin community to work on this issue for the security and clean-design
> of Bitcoin.
>
> My suggestion is to use in the version bits 4 bits indicating the tree
> depth (-1), as a soft-fork, so
> 00=1 depth,
> 0F = 16 depth (maximum 64K transactions). Very clean.
>
> The other option is to ban transaction with size lower or equal to 64.
>
> Best regards,
> Sergio.
>
> On Sat, Jun 9, 2018 at 5:31 AM Bram Cohen via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> So are you saying that if fully validating nodes wish to prune they can
>> maintain the ability to validate old transactions by cacheing the number of
>> transactions in each previous block?
>>
>> On Thu, Jun 7, 2018 at 3:20 PM, Peter Todd <pete at petertodd.org> wrote:
>>
>>> On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote:
>>> > Are you proposing a soft fork to include the number of transactions in
>>> a
>>> > block in the block headers to compensate for the broken Merkle format?
>>> That
>>> > sounds like a good idea.
>>> >
>>> > On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev <
>>> > bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >
>>> > > It's well known that the Bitcoin merkle tree algorithm fails to
>>> distinguish
>>> > > between inner nodes and 64 byte transactions, as both txs and inner
>>> nodes
>>> > > are
>>> > > hashed the same way. This potentially poses a problem for tx
>>> inclusion
>>> > > proofs,
>>> > > as a miner could (with ~60 bits of brute forcing) create a
>>> transaction that
>>> > > committed to a transaction that was not in fact in the blockchain.
>>> > >
>>> > > Since odd-numbered inner/leaf nodes are concatenated with themselves
>>> and
>>> > > hashed
>>> > > twice, the depth of all leaves (txs) in the tree is fixed.
>>> > >
>>> > > It occured to me that if the depth of the merkle tree is known, this
>>> > > vulnerability can be trivially avoided by simply comparing the
>>> length of
>>> > > the
>>> > > merkle path to that known depth. For pruned nodes, if the depth is
>>> saved
>>> > > prior
>>> > > to pruning the block contents itself, this would allow for
>>> completely safe
>>> > > verification of tx inclusion proofs, without a soft-fork; storing
>>> this
>>> ^^^^^^^^^^^^^^^^^^^
>>>
>>> Re-read my post: I specifically said you do not need a soft-fork to
>>> implement
>>> this. In fact, I think you can argue that this is an accidental feature,
>>> not a
>>> bug, as it further encourages the use of safe full verifiaction rather
>>> than
>>> unsafe lite clients.
>>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/ee578469/attachment-0001.html>

2023-06-07 18:10:36

- reply

📅 Original date posted:2018-02-12
📝 Original message:When we worked on the extensions for RSK merge mining, I prepared an
internal document with the most up to date Straum protocol description I
could get.
This is the document:
https://docs.google.com/document/d/1ocEC8OdFYrvglyXbag1yi8WoskaZoYuR5HGhwf0hWAY/edit?usp=sharing
Regards
On Fri, Feb 9, 2018 at 10:48 AM, Jules Lamur via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> With two student colleagues of mine (Denis HODZHADZHIKOV,
> Kim-Son PHAM), we are developping a mining pool as an
> academic work.
>
> Currently, most of our work is reverse engineering on existing
> implementations of the protocol because of the lack of
> documentation, especially on edge cases.
>
> Our referent professor suggested us to publish a IETF RFC draft
> of the protocol's specification. However, I think a BIP would be
> more appropriate for this.
>
> I've found that the BIP 40 and the BIP 41 were allocated for
> respectively the wire protocol and the mining protocol since
> at least August 2013 (cf.
> https://github.com/bitcoin/bips/commit/e12d37e6639a4acffa2710ddb6cf81
> e74403b2a1).
>
> It seems that nothing has been done since.
>
> Could we (me and my colleagues) start writing a draft for the
> BIP 41 (mining protocol)?
>
> Regards,
> Jules LAMUR.
> _______________________________________________
> 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/20180212/f731f573/attachment.html>

2023-06-07 18:05:55

- reply

📅 Original date posted:2017-09-22
📝 Original message:The policy seems good with the exception of this paragraph:
* Bitcoin devs will disclose vulnerabilities publically after 99% of the
bitcoin network has upgraded [7], and fixes have been released for
at least 12 months.
99% upgrade may never be reached. Some nodes cannot even be categorized. I
suggest a number close to 95%.
If the 95% of network has upgraded, it means we're pretty secure from the
point of view of consensus. It is supposed that from the time the fix has
been released, all other alt-coins will also have released their fixes.
Remember we must also incentivize security researchers to do the hard and
silent research work. Most of them do not hold Bitcoins. They do research
because of other interests, including getting public acknowledgment for
their findings. They'll be frustrated if they have to wait 2 years.
I propose this paragraph to replace the previous one:
* Bitcoin devs will disclose vulnerabilities publically after 95% of the
bitcoin network has upgraded [7], and fixes have been released for
at least 6 months.
Also I suggest we track vulnerabilities with standard CVE codes. IS there
any drawback of this?
regards
On Thu, Sep 21, 2017 at 11:00 PM, Nathan Wilcox via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> [inline responses]
>
>
> On Thu, Sep 14, 2017 at 2:27 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote:
>> > It would be a good starting point if the current policy could be
>> > clarified, so everyone is on the same page, and there is no confusion.
>>
>> Collecting various commentary from here and reddit, I think current de
>> facto policy is something like:
>>
>> * Vulnerabilities should be reported via security at bitcoincore.org [0]
>>
>> * A critical issue (that can be exploited immediately or is already
>> being exploited causing large harm) will be dealt with by:
>> * a released patch ASAP
>> * wide notification of the need to upgrade (or to disable affected
>> systems)
>> * minimal disclosure of the actual problem, to delay attacks
>> [1] [2]
>>
>> * A non-critical vulnerability (because it is difficult or expensive to
>> exploit) will be dealt with by:
>> * patch and review undertaken in the ordinary flow of development
>> * backport of a fix or workaround from master to the current
>> released version [2]
>>
>> * Devs will attempt to ensure that publication of the fix does not
>> reveal the nature of the vulnerability by providing the proposed fix
>> to experienced devs who have not been informed of the vulnerability,
>> telling them that it fixes a vulnerability, and asking them to identify
>> the vulnerability. [2]
>>
>> * Devs may recommend other bitcoin implementations adopt vulnerability
>> fixes prior to the fix being released and widely deployed, if they
>> can do so without revealing the vulnerability; eg, if the fix has
>> significant performance benefits that would justify its inclusion. [3]
>>
>> * Prior to a vulnerability becoming public, devs will generally recommend
>> to friendly altcoin devs that they should catch up with fixes. But this
>> is only after the fixes are widely deployed in the bitcoin network. [4]
>>
>> * Devs will generally not notify altcoin developers who have behaved
>> in a hostile manner (eg, using vulnerabilities to attack others, or
>> who violate embargoes). [5]
>>
>> * Bitcoin devs won't disclose vulnerability details until >80% of bitcoin
>> nodes have deployed the fixes. Vulnerability discovers are encouraged
>> and requested to follow the same policy. [1] [6]
>>
>> Those seem like pretty good policies to me, for what it's worth.
>>
>>
> I advocate a policy like this, except I propose two modifications:
>
> - Point 4 should include *zero or more* altcoin developers, such that
> those altcoins also deploy mitigations as early as Bitcoin. (Call this
> "early altcoin disclosure".)
>
> - Disclose of vulnerabilities, by social convention, always explicitly
> names which altcoin developers were included in my proposed Early Altcoin
> Disclosure and Point 6.
>
> The rationale is that the policy should allow closer coordination with
> altcoins. If the goal is minimizing economic damage, including altcoins
> earlier may be the better trade-off between inclusiveness and secrecy. At
> the same time, the policy doesn't establish *which* altcoins, which is a
> tricky choice. However it *does* require disclosure of those relationships,
> which provides a form of feedback on the system.
>
> Imagine if altcoin X is compromised, and later disclosure occurs that
> reveals that altcoin X was not contacted early, then this *might* indicate
> leaks, maliciousness in the Bitcoin mitigation organization, or it *might*
> be coincidence or dumb luck. In the other case, if the Bitcoin disclosure
> reveals that X was indeed contacted early, then it probably indicates
> incompetence of the altoin X.
>
> Finally, notice that this kind of loose early disclosure policy can be
> symmetric. For example, Zcash developers may choose to disclose
> vulnerabilities they discover which affect Bitcoin to Bitcoin developers
> *before* Zcash releases fixes, or before those fixes are widely adopted in
> Zcash. We actually have a policy of doing this, since it's obvious that if
> our mitigation process leaks and that's used to attack Bitcoin the
> potential economic damage is very large.
>
>
>
>> I haven't seen anything that indicates bitcoin devs will *ever* encourage
>> public disclosure of vulnerabilities (as opposed to tolerating other
>> people publishing them [6]). So I'm guessing current de facto policy is
>> more along the lines of:
>>
>> * Where possible, Bitcoin devs will never disclose vulnerabilities
>> publically while affected code may still be in use (including by
>> altcoins).
>>
>> rather than something like:
>>
>> * Bitcoin devs will disclose vulnerabilities publically after 99% of the
>> bitcoin network has upgraded [7], and fixes have been released for
>> at least 12 months.
>>
>>
> I advocate for something like the latter case. I'd like to see a timeout
> on disclosure. There's an endless tail of alt-coins that could be affected,
> and no guarantee all will vigilantly upgrade. Meanwhile, deciding which of
> them to disclose to confidentially versus which should just receive hints
> to apply new patches is tricky and political.
>
> Having a global timeout is a reasonable stop-gap. I consider the cost of
> never disclosing, publicly, a known vulnerbility to be very high, even if
> the fix is ubiquitously deployed, because it's a loss of security
> knowledge, a precious public good.
>
>
>>
>> Instinctively, I'd say documenting this policy (or whatever it actually
>> is) would be good, and having all vulnerabilities get publically released
>> eventually would also be good; that's certainly the more "open source"
>> approach. But arguing the other side:
>>
>> - documenting security policy gives attackers a better handle on where
>> to find weak points; this may be more harm than there is benefit to
>> improving legitimate users' understanding of and confidence in the
>> development process
>>
>>
> Publishing a policy *might* increase organizational vulnerability, but so
> might *not publishing* a policy. It seems fairly neutral to me on
> vulnerability impact, whereas the benefit is good for users and developers.
>
>
>
>> - the main benefit of public vulnerability disclosure is a better
>> working relationship with security researchers and perhaps better
>> understanding of what sort of bugs happen in practice in general;
>> but if most of your security research is effectively in house [6],
>> maybe those benefits aren't as great as the harm done by revealing
>> even old vulnerabilities to attackers
>>
>>
> Publishing after a reasonable timeout has many benefits. Many security
> researchers learn from vulnerability disclosures across many disciplines
> and industries. Future protocol designers of things potentially unrelated
> to blockchain altogether may also learn important lessons.
>
>
> If the first of those arguments holds, well, hopefully this message has
>> egregious errors that no one will correct, or it will quickly get lost
>> in this list's archives...
>>
>> Cheers,
>> aj
>>
>>
> regards,
> Nathan Wilcox
> Zcash
>
>
>> [0] http://bitcoincore.org/en/contact
>> referenced from .github/ISSUE_TEMPLATE.md in git
>>
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -September/014986.html
>>
>> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -September/014990.html
>>
>> [3] https://www.reddit.com/r/btc/comments/6zf1qo/peter_todd_nice
>> ly_pulled_away_attention_from_jjs/dmxcw70/
>>
>> [4] https://www.reddit.com/r/btc/comments/6z827o/chris_jeffrey_j
>> j_discloses_bitcoin_attack_vector/dmxdg83/
>>
>> [5] https://www.reddit.com/r/btc/comments/6zb3lp/maxwell_admits_
>> core_sat_on_vulnerability/dmv4y7g/
>>
>> [6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -September/014991.html
>>
>> [7] Per http://luke.dashjr.org/programs/bitcoin/files/charts/branche
>> s.html
>> it seems like 1.7% of the network is running known-vulnerable versions
>> 0.8 and 0.9; but only 0.37% are running 0.10 or 0.11, so that might
>> argue
>> revealing any vulnerabilities fixed since 0.12.0 would be fine...
>> (bitnodes.21.co doesn't seem to break down anything earlier than
>> 0.12)
>>
>> _______________________________________________
>> 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/20170922/cdd9e559/attachment.html>

2023-06-07 18:05:53

- reply

📅 Original date posted:2017-09-12
📝 Original message:Historically people have published vulnerabilities in Bitcoin only after
>80% of the nodes have upgraded. This seems to be the general (but not
publicly stated) policy. If you're a core developer and you know better,
please correct me.
This means that:
- a critical vulnerability, like a remote code execution, will be patched
immediately (without disclosing the actual problem) and all participants
will be notified asap. This is no different from any other open source
project. An example of this case was the OpenSSL Heartbleed vulnerability
that affected Bitcoin.
- a non-critical vulnerability, either because miners only can exploit it
or because it requires vast resources to pull, may require a wait of years
before publication, after a vulnerability was found and reported. This is
because the "natural" node upgrade rate is slow.
It also implies that some times a researcher works hard to investigate a
vulnerability and later he finds out it was previously reported. It also
means that the researcher cannot report to alt-coins which have a different
policy.
This policy has nothing to do with a loyalty to Bitcoin Core (or in fact,
the two or so developers that actually receive the e-mails to
security at bitcoincore.org).
This is a policy that has simply proven to work to protect Bitcoiners. It
began long long ago.
On Tue, Sep 12, 2017 at 12:37 AM, Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote:
> > I don't think I know the right answer here, but I will point out two
> things
> > that make this a little more complicated.
> > 1 - There are lots of altcoin developers and while I'm sure the majority
> would
> > greatly appreciate the disclosure and would behave responsibly with the
> > information, I don't know where you draw the line on who you tell and
> who you
> > don't.
>
> If you can't pick even a small group that's trustworthy (top five by
> market cap as a start [0]? or just major bitcoin wallets / exchanges /
> alt node implementations?), then it still seems better to (eventually)
> disclose publically than keep it unrevealed and let it be a potential
> advantage for attackers against people who haven't upgraded for other
> reasons?
>
> I find it hard to imagine bitcoin's still obscure enough that people
> aren't tracking git commit logs to use them as inspiration for attacks
> on bitcoin users and businesses; at best I would have thought it'd
> only be a few months of development time between a fix being proposed
> as a PR or committed to master and black hats having the ability to
> exploit it in users who are running older nodes. (Or for that matter,
> being able to be exploited by otherwise legitimate bitcoin businesses
> with an agenda to push, a strong financial motive behind that agenda,
> and a legal team that says they'll get away with it)
>
> > 2- Unlike other software, I'm not sure good security for bitcoin is
> defined by
> > constant upgrading. Obviously upgrading has an important benefit, but
> one of
> > the security considerations for Bitcoin is knowing that your definition
> of the
> > money hasn't changed. Much harder to know that if you change software.
>
> Isn't that just an argument for putting more effort into backporting
> fixes/workarounds? (I don't see how you do that without essentially
> publically disclosing which patches have a security impact -- "oh,
> gosh, this patch gets a backport, I wonder if maybe it has security
> implications...")
>
> (In so far as bitcoin is a consensus system, there can sometimes be a
> positive network effect, where having other people upgrade can help your
> security, even if you don't upgrade; "herd immunity" if you will. That
> way a new release going out to other people helps keep you safe, even
> while you continue to maintain the same definition of money by not
> upgrading at all)
>
> If altcoin maintainers are inconvenienced by tracking bitcoin-core
> updates, that would be an argument for them to contribute back to their
> upstream to make their own job easier; either helping with backports,
> or perhaps contributing to patches like PR#8994 might help.
>
> All of those things seem like they'd help not just altcoins but bitcoin
> investors/traders too, so it's not even a trade-off between classes of
> bitcoin core users. And if in the end various altcoins aren't able to
> keep up with security fixes, that's probably valuable information to
> provide to the market...
>
> Cheers,
> aj
>
> [0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin?
> I've no idea which of those might have trustworthy devs to work with,
> but surely at least a couple do?
>
> _______________________________________________
> 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/20170912/78a88c9e/attachment-0001.html>

2023-06-07 18:05:39

- reply

📅 Original date posted:2017-09-22
📝 Original message:>
> There are other solutions to this problem that could have been taken
> instead, such as committing to the number of items or maximum size of
> the stack as part of the sighash data, but cleanstack was the approach
> taken.
The lack of signed maximum segwit stack size was one of the objections to
segwit I presented last year. This together with the unlimited segwit stack
size.
However, committing to the maximum stack size (in bytes) for an input is
tricky. The only place where this could be packed is in sequence_no, with a
soft-fork. E.g. when transaction version is 2 and and only when lock_time
is zero.
For transactions with locktime >0, we could soft-fork so transactions add a
last zero-satoshi output whose scriptPub contains OP_RETURN and followed by
N VarInts, containing the maximum stack size of each input.
Normally, for a 400 byte, 2-input transaction, this will add 11 bytes, or a
2.5% overhead.
> Arguably for a future script version upgrade one of these other
> approaches should be taken to allow for shorter tail-call scripts.
>
> Mark
>
> * Well, almost any. You could end the script with DEPTH EQUAL and that
> is a compact way of ensuring the stack is clean (assuming the script
> finished with just "true" on the stack). Nobody does this however
> and burning two witness bytes of every redeem script going forward
> as a protective measure seems like an unnecessary ask.
> _______________________________________________
> 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/20170922/cc607dfd/attachment-0001.html>

2023-06-07 18:05:39

- reply

📅 Original date posted:2017-09-22
📝 Original message:But generally before one signs a transaction one does not know the
signature size (which may be variable). One can only estimate the maximum
size.
On Fri, Sep 22, 2017 at 6:11 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
>
> On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
>
>
>>
>> There are other solutions to this problem that could have been taken
>> instead, such as committing to the number of items or maximum size of
>> the stack as part of the sighash data, but cleanstack was the approach
>> taken.
>
>
> The lack of signed maximum segwit stack size was one of the objections to
> segwit I presented last year. This together with the unlimited segwit stack
> size.
>
> However, committing to the maximum stack size (in bytes) for an input is
> tricky. The only place where this could be packed is in sequence_no, with a
> soft-fork. E.g. when transaction version is 2 and and only when lock_time
> is zero.
>
> For transactions with locktime >0, we could soft-fork so transactions add
> a last zero-satoshi output whose scriptPub contains OP_RETURN and followed
> by N VarInts, containing the maximum stack size of each input.
> Normally, for a 400 byte, 2-input transaction, this will add 11 bytes, or
> a 2.5% overhead.
>
>
> There’s no need to put it in the transaction itself. You put it in the
> witness and it is either committed to as part of the witness (in which case
> it has to hold for all possible spend paths), or at spend time by including
> it in the data signed by CHECKSIG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170922/87c83dee/attachment.html>

2023-06-07 18:05:39

- reply

📅 Original date posted:2017-09-22
📝 Original message:If the variable size increase is only a few bytes, then three possibilities
arise:
- one should allow signatures to be zero padded (to reach the maximum size)
and abandon strict DER encoding
- one should allow spare witness stack elements (to pad the size to match
the maximum size) and remove the cleanstack rule. But this is tricky
because empty stack elements must be counted as 1 byte.
- signers must loop the generation of signatures until the signature
generated is of its maximum size.
On Fri, Sep 22, 2017 at 6:39 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> You generally know the witness size to within a few bytes right before
> signing. Why would you not? You know the size of ECDSA signatures. You can
> be told the size of a hash preimage by the other party. It takes some
> contriving to come up with a scheme where one party has variable-length
> signatures of their chosing
>
> > On Sep 22, 2017, at 2:32 PM, Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
> >
> > But generally before one signs a transaction one does not know the
> signature size (which may be variable). One can only estimate the maximum
> size.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170922/2f36b74f/attachment-0001.html>

2023-06-07 18:04:06

- reply

📅 Original date posted:2017-07-13
📝 Original message:The BIP has been updated.
Changes:
- The technical spec has been improved: now the block size increase is
specified in terms of weight and not in terms of bytes.
- The increase in the maximum block sigops after HF has been documented.
- Comments added about the worst case block size.
Happy weekend! And don't forget to start signaling something before block
475776 ! It's just 90 blocks away.
Bit 1 or 4,1 or whatever you wish, but please signal something.
To the moon!
On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> > I think anything less than 1 year after release of tested code by some
> > implementation would be irresponsible for any hardfork, even a very
> > simple one.
>
> Good news!
>
> Code to support 2x (the hard fork part of the proposal) has been out and
> tested for much longer than that.
>
>
> Not true. It's different code on top of segwit. The first attempt in btc1
> (very recent) didn't even increased the size (because it changed the
> meaningless "base size" without touching the weight limit. As for the
> current code, I don't think it has been properly tested today, let alone
> "for mucj longer than 1 year.
> Anyway, I said, one year from tested release. Segwitx2 hasn't been
> released, has it? If so, too late to discuss a bip imo, the bip may end up
> being different from what has been released due to feedback (unless it is
> ignored again, of course).
>
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> 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/20170713/03b124d8/attachment.html>

2023-06-07 18:04:04

- reply

📅 Original date posted:2017-07-10
📝 Original message:Thank you for all your comments. I will improve the BIP based on the
technical suggestions received.
On the subjective/political side that has slipped into this discussion.
Skip this part if not interested in politics.
Regarding the timeline, its certainly rather short, but also is the UASF
BIP 148 ultimatum.
If Bitcoin were a democracy and we had somehow a way to securely perform a
referendum, then this will solve easily. But neither is true. At least now.
More than 80% of the miners and many users are willing to go in the
Segwit2x direction. With the support and great talent of the Bitcoin Core
developers, Segwit2x activation will not cause any major disruptions.
Without Core, there will be a temporary split. Both sides will have to
hard-fork.
I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
own vision, is not so bad.
On Sat, Jul 8, 2017 at 6:19 PM, Brian Hoffman <brian at ob1.io> wrote:
> I don't feel threatened by investors. You're full of shit btcdrak.
>
> Proofread your emails. You just declared support for segwit2x.
>
> On Jul 8, 2017, at 9:28 AM, Btc Drak via bitcoin-dev <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
> I am utterly appalled by this proposal both technically, ethically, and by
> the process which it has adopted. Hard forks require consensus from the
> entire ecosystem in order to prevent a fork, funds loss, confusion and harm
> to the robust guarantees of the Bitcoin system has thus far displayed.
>
> I know this is a draft, but you are seeking reviews of a proposal that has
> just a few weeks remaining before deployment (where "technical review" is
> pointless because the is not actually open <https://pastebin.com/kktB1kaw> unless
> you are an approved member
> <https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),
> making it totally unworkable and irresponsible. For example, exactly how
> are other implementations supposed to adopt the BIP in such a short
> timeframe? For all the talk of how important "alternative implementations"
> are, how does this rash and rushed action promote an ecosystem of multiple
> implementors? By encouraging fast upgrades, you are actually centralizing
> the ecosystem even further.
>
> The linked coded doesn't uniquely identify itself on the network by
> user-agent, something all distinct implementations have done to date.
>
> The draft BIP text looks like an afterthought and doesn't actually specify
> the proposal in enough detail to implement from the text. By contrast for
> example, BIP141 has a level of detail which allowed others to implement
> segwit without looking at any reference code (which consequently results to
> more confidence and testing of the specification all round). The Bitcoin
> system has a market cap of over $40bn supported by a robust and reliable
> network and your proposal is an offence to all Bitcoin has achieved because
> due to it's the strong foundations.
>
> I cannot not support this proposal in the current form and timeline, nor
> do I support the coercion that has been used behind closed doors to try and
> gain more support (not limited to, but including approaching company
> investors to twist arms and veiled threats of blacklisting companies from
> further funding/collaboration).
>
> I think the best you can hope for this hard fork proposal is for it to be
> quietly ignored.
>
>
>
> On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello,
>>
>> Here is a BIP that matches the reference code that the Segwit2x group has
>> built and published a week ago.
>>
>> This BIP and code satisfies the requests of a large part of the Bitcoin
>> community for a moderate increase in the Bitcoin non-witness block space
>> coupled with the activation of Segwit.
>>
>> You can find the BIP draft in the following link:
>>
>> https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-
>> draft-sergiolerner-segwit2x.mediawiki
>>
>> Reference source was kindly provided by the Segwit2x group.
>>
>> Best regards,
>> Sergio.
>>
>> _______________________________________________
>> 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/20170710/a72aad85/attachment-0001.html>

2023-06-07 18:04:03

- reply

📅 Original date posted:2017-07-13
📝 Original message:Well, 40 bytes reduction per input is excessive too :)
But 30 bytes reduction will do fine.
On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
> Some responses..
>
>>
>> The proposal adds another gratuitous limit to the system: A maximum
>> transaction size where none existed before, yet this limit is almost
>> certainly too small to prevent actual DOS attacks while it is also
>> technically larger than any transaction that can be included today
>> (the largest possible transaction today is 1mb minus the block
>> overheads). The maximum resource usage for maliciously crafted 1MB
>> transaction is enormous and permitting two of them greatly exacerbates
>> the existing vulnerability.
>>
>>
> I think that limiting the maximum transaction size may not be the best
> possible solution to the N^2 hashing problem, yet it is not a bad start.
>
> There are several viable soft-forking solutions to it:
>
> 1- Soft-fork to perform periodic reductions in the maximum non-segwit
> checksigs per input (down to 20)
> 2- Soft-fork to perform periodic reductions in the number of non-segwit
> checksigs per transaction. (down to 5K)
> 3- Soft-fork to perform periodic reductions in the amount of data hashed
> by non-segwit checksigs.
>
> Regardless which one one picks, the soft-fork can be deployed with enough
> time in advance to reduce the exposure. The risk is still low. Four years
> have passed since I reported this vulnerability and yet nobody has
> exploited it. The attack is highly anti-economical, yet every discussion
> about the block size ends up citing this vulnerability.
>
> ,
>
>> > Assuming the current transaction pattern is replicated in a 2 MB
>> plain-sized block that is 100% filled with transactions, then the
>> witness-serialized block would occupy 3.6 MB
>>
>> But in a worst case the result would be 8MB, which this document fails
>> to mention.
>>
>
> I will mention this worst case in the BIP.
>
> Even if artificially filling the witness space up to 8 MB is
> anti-economical, Segwit exacerbates this problem because each witness byte
> costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper
> than before. I think the guilt lies more in Segwit discount factor than in
> the plain block size increase.
> I would remove the discount factor altogether, and add a fixed (40 bytes)
> discount for each input with respect to outputs (not for certain input
> types), to incentivize the cleaning of the UTXO set. A discount for inputs
> cannot be used to bloat an unlimited number of blocks, because for each
> input the attacker needs to first create an output (without discount).
> There is no need to incentivize removing the signatures from blocks,
> because there is already an incentive to do so to save disk space.
>
>
>>
>> > Deploy a modified BIP91 to activate Segwit. The only modification is
>> that the signal "segsignal" is replaced by "segwit2x".
>>
>> This means that BIP-91 and your proposal are indistinguishable on the
>> network, because the string "segsignal" is merely a variable name used
>> in the software.
>>
>> No, it is exposed to the rpc mining interface (getblocktemplate). It must
> be redefined, even if it's not a consensus change.
>
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/23535924/attachment.html>

2023-06-07 18:04:03

- reply

📅 Original date posted:2017-07-13
📝 Original message:Some responses..
>
> The proposal adds another gratuitous limit to the system: A maximum
> transaction size where none existed before, yet this limit is almost
> certainly too small to prevent actual DOS attacks while it is also
> technically larger than any transaction that can be included today
> (the largest possible transaction today is 1mb minus the block
> overheads). The maximum resource usage for maliciously crafted 1MB
> transaction is enormous and permitting two of them greatly exacerbates
> the existing vulnerability.
>
>
I think that limiting the maximum transaction size may not be the best
possible solution to the N^2 hashing problem, yet it is not a bad start.
There are several viable soft-forking solutions to it:
1- Soft-fork to perform periodic reductions in the maximum non-segwit
checksigs per input (down to 20)
2- Soft-fork to perform periodic reductions in the number of non-segwit
checksigs per transaction. (down to 5K)
3- Soft-fork to perform periodic reductions in the amount of data hashed by
non-segwit checksigs.
Regardless which one one picks, the soft-fork can be deployed with enough
time in advance to reduce the exposure. The risk is still low. Four years
have passed since I reported this vulnerability and yet nobody has
exploited it. The attack is highly anti-economical, yet every discussion
about the block size ends up citing this vulnerability.
,
> > Assuming the current transaction pattern is replicated in a 2 MB
> plain-sized block that is 100% filled with transactions, then the
> witness-serialized block would occupy 3.6 MB
>
> But in a worst case the result would be 8MB, which this document fails
> to mention.
>
I will mention this worst case in the BIP.
Even if artificially filling the witness space up to 8 MB is
anti-economical, Segwit exacerbates this problem because each witness byte
costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper
than before. I think the guilt lies more in Segwit discount factor than in
the plain block size increase.
I would remove the discount factor altogether, and add a fixed (40 bytes)
discount for each input with respect to outputs (not for certain input
types), to incentivize the cleaning of the UTXO set. A discount for inputs
cannot be used to bloat an unlimited number of blocks, because for each
input the attacker needs to first create an output (without discount).
There is no need to incentivize removing the signatures from blocks,
because there is already an incentive to do so to save disk space.
>
> > Deploy a modified BIP91 to activate Segwit. The only modification is
> that the signal "segsignal" is replaced by "segwit2x".
>
> This means that BIP-91 and your proposal are indistinguishable on the
> network, because the string "segsignal" is merely a variable name used
> in the software.
>
> No, it is exposed to the rpc mining interface (getblocktemplate). It must
be redefined, even if it's not a consensus change.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/94c52265/attachment.html>

2023-06-07 18:04:01

- reply

📅 Original date posted:2017-07-07
📝 Original message:Hello,
Here is a BIP that matches the reference code that the Segwit2x group has
built and published a week ago.
This BIP and code satisfies the requests of a large part of the Bitcoin
community for a moderate increase in the Bitcoin non-witness block space
coupled with the activation of Segwit.
You can find the BIP draft in the following link:
https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki
Reference source was kindly provided by the Segwit2x group.
Best regards,
Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170707/d7d45d57/attachment.html>

2023-06-07 18:03:31

- reply

📅 Original date posted:2017-06-27
📝 Original message:Currently the only implementation that fulfills the requirements of the NYA
agreement is the segwit2x/btc1 implementation, which is being finalized
this week.
Segwit2mb does not fulfill the NYA agreement.
I'm asking now the segwit2x development team when a BIP will be ready so
that Core has the opportunity to evaluate the technical proposal.
On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Well, this Saturday's "Chinese roundtable" statement from a bunch of
> miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the
> coinbase as support for "the New York consensus SegWit2x program btc1 (
> https://github.com/btc1)", whose code includes the (accelerated
> 336-block) BIP 91 change. So, other facts or interpretations could come to
> light, but until they do we should probably assume that's what the "NYA"
> (which just broke 80% over the last 24h) means.
>
>
> On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> 80% have set "NYA" in their coinbase string. We have no idea what that
>> means. People are equating it to BIP 91 -- but BIP 91 did not exist at
>> the time of the New York agreement, and differs from the actual text
>> of the NYA in substantive ways. The "Segwit2MB" that existed at the
>> time of the NYA, and which was explicitly referenced by the text is
>> the proposal by Sergio Demian Lerner that was made to this mailing
>> list on 31 March. The text of the NYA grants no authority for
>> upgrading this proposal while remaining compliant with the agreement.
>> This is without even considering the fact that in the days after the
>> NYA there was disagreement among those who signed it as to what it
>> meant.
>>
>> I feel it is a very dangerous and unwarranted assumption people are
>> making that what we are seeing now is either 80% support for BIP-91 or
>> for the code in the btc1 repo.
>>
>> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <erik at q32.com> wrote:
>> > # Jacob Eliosoff:
>> >
>> >> will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
>> split.
>> >
>> > Correct. There are 2 short activation periods in BIP91 either of which
>> > would avoid a split.
>> >
>> > # Gregory Maxwell:
>> >
>> >> unclear to me _exactly_ what it would need to implement to be
>> consistent.
>> >
>> > This is the relevant pull req to core:
>> >
>> > https://github.com/bitcoin/bitcoin/pull/10444
>> >
>> > Seems OK. It's technically running now on testnet5. I think it (or a
>> > -bip148 option) should be merged as soon as feasible.
>> >
>> >> previously debunked "XT" and "Classic" hysteria.
>> >
>> > apples vs oranges, imo. segwit is not a contentious feature. the
>> > "bundling" in segwit2x is, but that's not the issue here. the issue
>> is we
>> > are indirectly requiring miners that strongly support segwit to install
>> > consensus protocol changes outside of bitcoin's standard reference.
>> 80% of
>> > them have signaled they will do so. these are uncharted waters.
>> >
>> >
>> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> I could be wrong, but the latest BIP91 implementation (also included in
>> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This
>> has
>> >> been updated at
>> >> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So
>> if 80%
>> >> of hashpower is actually running that code and signaling on bit 4 by
>> July 25
>> >> or so, then those 80+% will start orphaning non-bit-1 blocks before
>> Aug 1,
>> >> and we avoid a split.
>> >>
>> >> There may still be a few non-bit-1 blocks that get orphaned after Aug
>> 1,
>> >> because they're mined by old BIP141 nodes. But it seems like very few
>> >> miners won't be signaling either Segwit2x *or* BIP141 by then...
>> >>
>> >> Make sense?
>> >>
>> >>
>> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <
>> mark at friedenbach.org>
>> >> wrote:
>> >>>
>> >>> Why do you say activation by August 1st is likely? That would require
>> an
>> >>> entire difficulty adjustment period with >=95% bit1 signaling. That
>> seems a
>> >>> tall order to organize in the scant few weeks remaining.
>> >>>
>> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
>> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> If segwit is activated before Aug 1, as now seems likely, there will
>> be
>> >>> no split that day. But if activation is via Segwit2x (also likely),
>> and at
>> >>> least some nodes do & some don't follow through with the HF 3mo later
>> >>> (again, likely), agreed w/ Greg that *then* we'll see a split -
>> probably in
>> >>> Sep/Oct. How those two chains will match up and how the split will
>> play out
>> >>> is anyone's guess...
>> >>>
>> >>>
>> >>>
>> >>> On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev"
>> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> > Ironically, it looks like most of the segwit2x signaling miners are
>> >>> > faking it (because they're not signaling segwit which it requires).
>> >>> > It'll be unfortunate if some aren't faking it and start orphaning
>> >>> > their own blocks because they are failing to signal segwit.
>> >>>
>> >>> Well, they're doing some kind of "pre-signaling" in the coinbase at
>> the
>> >>> moment, because the segwit2x project is still in alpha-phase
>> according to
>> >>> the timeline. They're just showing commitment.
>> >>> I'm sure they will begin signaling on version bit 4/BIP91 as well as
>> >>> actually running a segwit2x node when the time comes.
>> >>>
>> >>>
>> >>> > As far as prevent a chain split goes, all those things
>> >>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit--
>> so I
>> >>> > don't think that holds.
>> >>>
>> >>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x
>> (or
>> >>> BIP148) node, because they wouldn't have the new consensus rule of
>> requiring
>> >>> all blocks to signal for segwit.
>> >>> I don't believe there would be any long lasting chainsplit though
>> >>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3
>> blocks if we
>> >>> get unlucky.
>> >>>
>> >>> Hampus
>> >>>
>> >>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev
>> >>> <bitcoin-dev at lists.linuxfoundation.org>:
>> >>>>
>> >>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>> > Because a large percentage of miners are indifferent, right now
>> miners
>> >>>> > have
>> >>>> > to choose between BIP148 and Segwit2x if they want to activate
>> Segwit.
>> >>>>
>> >>>> Miners can simply continuing signaling segwit, which will leave them
>> >>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>> >>>> what "segwit2x" is since they keep changing the actual definition and
>> >>>> do not have a specification; but last I saw the near-term behavior
>> the
>> >>>> same as BIP91 but with a radically reduced activation window, so the
>> >>>> story would be the same there in the near term).
>> >>>>
>> >>>> Ironically, it looks like most of the segwit2x signaling miners are
>> >>>> faking it (because they're not signaling segwit which it requires).
>> >>>> It'll be unfortunate if some aren't faking it and start orphaning
>> >>>> their own blocks because they are failing to signal segwit.
>> >>>>
>> >>>> I don't think the rejection of segwit2x from Bitcoin's developers
>> >>>> could be any more resolute than what we've already seen:
>> >>>> https://en.bitcoin.it/wiki/Segwit_support
>> >>>>
>> >>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>> > I think it is very naïve to assume that any shift would be
>> temporary.
>> >>>> > We have a hard enough time getting miners to proactively upgrade to
>> >>>> > recent versions of the reference bitcoin daemon. If miners
>> interpret
>> >>>> > the situation as being forced to run non-reference software in
>> order
>> >>>> > to prevent a chain split because a lack of support from Bitcoin
>> Core,
>> >>>> > that could be a one-way street.
>> >>>>
>> >>>> I think this is somewhat naive and sounds a lot like the repeat of
>> the
>> >>>> previously debunked "XT" and "Classic" hysteria.
>> >>>>
>> >>>> There is a reason that segwit2x is pretty much unanimously rejected
>> by
>> >>>> the technical community. And just like with XT/Classic/Unlimited
>> >>>> you'll continue to see a strong correlation with people who are
>> >>>> unwilling and unable to keep updating the software at an acceptable
>> >>>> level of quality-- esp. because the very founding on their fork is
>> >>>> predicated on discarding those properties.
>> >>>>
>> >>>> If miners want to go off and create an altcoin-- welp, thats
>> something
>> >>>> they can always do, and nothing about that will force anyone to go
>> >>>> along with it.
>> >>>>
>> >>>> As far as prevent a chain split goes, all those things
>> >>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so
>> I
>> >>>> don't think that holds.
>> >>>> _______________________________________________
>> >>>> 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
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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/20170627/3642debc/attachment.html>

2023-06-07 18:02:54

- reply

📅 Original date posted:2017-06-09
📝 Original message:I'm a bit late to this party. I just want to add that there exists an
hybrid model where both a federation and the miners provide acknowledges
(sometimes known as "votes" in drivechain terms and "multi-signatures" in a
federation) of the sidechain state.
My Drivechain proposal (Feb 2016) was tailored to enable this particular
use-case, which I'm not sure Paul's proposal enable.
The proposal is on this list under the following subject: Drivechain
proposal using OP_COUNT_ACKS
BIP (draft):
https://github.com/rootstock/bips/blob/master/BIP-R10.md
Code & Test cases:
https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
In this proposal, the "poll" time is sidechain-configurable, and I proposed
a few days delay was enough.
Some have said that a longer times are needed, such as 2 months.
So if you want to have a 2 month dalay for sidechain->mainchain transfers
in this code, you still can. However a better dynamic cache of acks/nacks
would be needed. However, for the hybrid use-case, one day is more than
enough.
Regards
On Tue, May 30, 2017 at 2:11 AM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Peter,
>
> Responses below.
>
> On 5/28/2017 5:07 PM, Peter Todd wrote:
> > On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> >> Surprisingly, this requirement (or, more precisely, this incentive) does
> >> not effect miners relative to each other. The incentive to upgrade is
> only
> >> for the purpose of preventing a "theft" -- defined as: an improper
> >> withdrawal from a sidechain. It is not about miner revenues or the
> ability
> >> to mine generally (or conduct BMM specifically). The costs of such a
> theft
> >> (decrease in market price, decrease in future transaction fee levels)
> would
> >> be shared collectively by all future miners. Therefore, it would have no
> >> effect on miners relative to each other.
> >
> > That's not at all true. If I'm a miner with a better capability than
> another
> > miner to prevent that theft, I have reasons to induce it to happen to
> give me
> > political cover to pushing that other miner off the network.
>
> Miners can abstain from 'voting', which is politically neutral. Or, if
> they wish, smaller miners could acquiesce to the coercion and just copy
> the votes of the attacking 51% group. For users who are only running
> Bitcoin Core, there is nothing bad about that.
>
> As you say, a 51% group can arbitrarily start orphaning the blocks that
> are mined by non-member rivals. This _may_ be a problem, or it may not,
> but it is not exacerbated by drivechain.
>
> So, what exactly is "not at all true"?
>
>
> >
> > This is a very similar problem to what we had with zeroconf
> double-spending,
> > where entities such as Coinbase tried to pay off miners to guarantee
> something
> > that wasn't possible in a geninely decrentralized system: safe zeroconf
> > transactions.
>
> I don't see what you mean here. You can't stop Coinbase from donating
> BTC to a subset of miners. That will always be possible, and it has
> nothing to do with drivechain (as I see it).
>
>
> >
> >> Moreover, miners have other recourse if they are unable to run the node.
> >> They can adopt a policy of simply rejecting ("downvoting") any
> withdrawals
> >> that they don't understand. This would pause the withdraw process until
> >> enough miners understand enough of what is going on to proceed with it.
> >
> > Why are you forcing miners to run this code at all?
>
> Could we not say the same thing about the code behind CLTV?
>
> The nature of a contract, is that people are happier to be bound by some
> rules that they themselves construct (for example, a nuclear
> non-proliferation treaty).
>
> In this case, miners prefer sidechains to exist (as existence makes the
> BTC they mine more valuable, and provides additional tx fee revenues),
> and so they would like to run code which makes them possible.
>
>
> >
> > Equally, you're opening up miners to huge political risks, as rejecting
> all
> > withdrawals is preventing users' from getting their money, which gives
> other
> > miners a rational for kicking those miners off of Bitcoin entirely.
>
> As I explained above, miners can abstain from voting, which is
> politically neutral, or else they can delegate their vote to an
> aggressive miner. The "51% can orphan" concern could be raised, even in
> a world without drivechain. All that is required, is for the miners to
> be anonymous, or in private 'dark' pools (and to thereby escape censure).
>
> But there is a much bigger issue here, which is that our threat models
> are different.
>
> As you may know, my threat model [1] does not include miners "pushing
> each other off". It only cares about the miner-experience, to the extent
> that it impacts the user-experience.
>
> Moreover, I reject [2] the premise that we can even measure "miner
> centralization", or even that such a concept exists. If someone has a
> definition of this concept, which is both measurable and useful, I would
> be interested to read it.
>
> ( For what it's worth, Satoshi did not care about this, either. For
> example: "If a greedy attacker is able to assemble more CPU power than
> all the honest nodes, he...ought to find it more profitable to play by
> the rules." which implies robustness to 51% owned by one entity. )
>
> [1] http://www.truthcoin.info/blog/mining-threat-equilibrium/
> [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
>
>
> >
> >> Finally, the point in dispute is a single, infrequent, true/false
> question.
> >> So miners may resort to semi-trusted methods to supplement their
> decision.
> >> In other words, they can just ask people they trust, if the withdrawal
> is
> >> correct or not. It is up to users to decide if they are comfortable with
> >> these risks, if/when they decide to deposit to a sidechain.
> >
> > Why do you think this will be infrequent? Miners with a better ability to
> > validate the drivechain have every reason to make these events more
> frequent.
>
> It is part of the spec. These timing parameters must be agreed upon when
> the sidechain is added, ie _before_ users deposit to the sidechain. Once
> the sidechain is created, the timing is enforced by nodes, the same as
> with any other protocol rules. Miner-validation-ability has no effect on
> the frequency.
>
>
> >
> >> It is a matter of comparing the costs and benefits. Ignoring theft, the
> >> costs are near-zero, and the benefits are >0. Specifically, they are: a
> >> higher BTC price and greater transaction fees. Theft is discouraged by
> >> attempting to tie a theft to a loss of confidence in the miners, as
> >> described in the spec/website.
> >> In general the incentives are very similar to those of Bitcoin itself.
> >
> > This is also a very dubious security model - I would argue that Bitcoin
> is much
> > *more* valuable if miners do everything they can to ensure that
> drivechains
> > fail, given the huge risks involved.
>
> I don't see how. Users are free to ignore the sidechain, so it can only
> benefit them.
>
> Fortunately for you, if that is actually what miners believe, then there
> will be no problem, as miners will just filter out drivechains (so that
> Bitcoin will be "much *more* valuable"), which they can easily do.
>
>
> > I would also argue that users
> should do
> > user-activated-soft-forks to ensure they fail.
>
> Again, I don't think that kind of UASF can succeed, because one option
> strictly dominates the other. But the users get the final say, of course.
>
> Empirically, I have observed overwhelming support for sidechains among
> users, business, and other developers. The btc-investors I spoke to were
> all very excited about the prospect of sidechains, even more so than
> they were excited about SegWit.
>
>
> >
> > By comparison, note Adam Back and my own efforts to ensure miners have a
> > smaller part in the ecosystem, with things like committed (encrypted)
> > transactions and my closed-seal-set/truth-list approach(1). We want to
> involve
> > miners as little as possible in the consensus, not more.
>
> I agree that miners should have as little influence as possible (and
> they probably agree, as well). But a 51% group can filter any message
> they like from the blockchain. For sidechains, there will need to be two
> public networks, so concealment is not an option.
>
> And, I repeat, for regular users of Bitcoin Core, drivechain does not
> make a 51% group more dangerous than they already are.
>
> Moreover, there are cases [1] where miner-involvement can make a big
> _positive_ impact. Just as it can be beneficial (essential, in fact) for
> Bitcoin to filter out harmful interactions among txns (in other words,
> good for miners to filter out double spends), I have discovered
> situations where it is beneficial and essential for miners to filter out
> harmful interactions among multiple chains.
>
> So I think I am actually hitting the "as little as possible" target.
>
> [1] http://www.truthcoin.info/blog/wise-contracts/#wise-contracts
>
>
> >
> > I have to ask: What use-cases do you actually see for drivechains? Why
> can't
>
> Here is a tentative project list:
> http://www.drivechain.info/projects/index.html
>
> And, as I say on the FAQ, "If each individual user is free to sell
> his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny
> users the opportunity to move their money between two sidechains."
>
> So, in a strong way, the entire altcoin market makes the case for a
> usefulness of sidechains. Bitcoin is a form of money, and only one form
> of money can exist per currency area. So, if Bitcoin is not the winner,
> it will eventually cease to exist altogether. Altcoin-competition is an
> existential threat to Bitcoin, one which is far more relevant than
> anything you've presented so far.
>
> Secondly, one important value of permissionless innovation is that one
> doesn't really know, today, what cool ideas other people are going to
> come up with tomorrow. If you did, they'd be today's ideas.
>
> Third, Core's review process has two opposite problems: on one hand it
> is slow and grueling, and on the other it is fraught with the
> possibility of catastrophic error. It would be better, for everyone, to
> allow people to try their own (non-aggressive) experiments, and to make
> their own mistakes. Already, I have seen the review process abused to
> create/maintain fiefdoms of expertise, so that the abusers can extract
> money from clients/employers/VCs.
>
> Just think of all of the free time you would have, Peter, if you didn't
> have to spend it all reviewing these projects!
>
>
> > those use-cases be done in the much safer client-side validation fashion?
>
> ? How is drivechain _not_ within the category of client-side validation?
> With BMM, validation is only performed by those users ("clients") who
> opt-in to the new features. The economic model of BMM is directly
> comparable to that of Bitcoin's PoW -- the highest-bid chain should be
> the healthiest one.
>
> Can you post the Github link for your most up-to-date client-side
> validation work so that we can compare the safety and other features?
>
> Thanks,
> Paul
>
> >
> > 1) https://petertodd.org/2016/closed-seal-sets-and-truth-
> lists-for-privacy
> >
> _______________________________________________
> 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/20170609/a377994a/attachment-0001.html>

2023-06-07 18:02:22

- reply

📅 Original date posted:2017-06-02
📝 Original message:I don't see LukeJr 2MB limit to be compatible with the NY agreement. For
the rest, seems fine for me.
On Fri, Jun 2, 2017 at 4:13 PM, Jared Lee Richardson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The above decision may quickly become very controversial. I don't think
> it's what most users had/have in mind when they discuss a "2MB+SegWit"
> solution.
> > With the current 1MB+SegWit, testing has shown us that normal usage
> results in ~2 or 2.1MB blocks.
> > I think most users will expect a linear increase when Base Size is
> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
> With normal usage, the expected results would then be ~4 or 4.2MB blocks.
>
> I think Calvin is correct here, the secondary limit is not what people
> anticipated with the segwit + 2mb agreement. It would not kill the
> agreement for me, but it might for others.
>
> What is the justification for the secondary limitation? Is there hard
> data to back this? The quadratic hashing problem is frequently brought up,
> but that is trivially handled with a hard 1mb transaction limit and on the
> other thread there's talk/suggestions of an even lower limit. Are there
> any other reasons for this limitation, and is there data to justify those
> concerns? If not, this should be left out in favor of a transaction size
> limit. If so, hard data would go a long way to dealing with the conversy
> this will create.
>
>
> > Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included
> to:
> > > cause the existing "segwit" deployment to activate without needing to
> release a new deployment.
> > Both of the aforementioned activation options (“fast-activation” and
> “flag-day activation”) serve to prevent unnecessary delays in the network
> upgrade process, addressing a common criticism of the Scaling Agreement and
> providing an opportunity for cooperation and unity instead.
>
> This is likely to cause more controversy and unfortunately has the
> tightest timelines. Unlike the SW2mb working group's timelines, a
> hard-coded timeline couldn't be changed with mutual agreement from the
> signers.
>
> Given the chance of bit1 accidental activation without clear signaling for
> the required bit4 2mb hard fork, I don't think the fair or acceptable
> tradeoff is for flag day to require bit1 signaling only. *Flag day
> should be modified to accept either bit1 signaling, OR to accept bit4
> signaling IF the 80% threshold hasn't been met.* In this way the
> anti-segwit working group members are not in danger of an activated bit1
> segwit without also getting their portion of the compromise, the bit4
> signaled HF. If flag day accepts bit4 OR bit1, AND bit4 requires both bit1
> and bit4 once 80% is reached, flag day is nearly guaranteed to get its
> stated desire within 1750 blocks (bit4 accepted until block 800; bit4+bit1
> signaled afterwards until 95%), but without the chance that the WG signers
> won't get what they agreed to.
>
> *That seems like a minor compromise for BIP148. Thoughts on this change
> to flag day / BIP148?*
>
> In addition, the aggressiveness of the timelines and the complexity of the
> merged COOP proposal may require the BIP148 flag day to be pushed back. I
> would think some day in September is achievable, but I'm not sure if August
> 1st will be.
>
> Jared
>
>
> On Tue, May 30, 2017 at 3:20 PM, CalvinRechner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> In principle, there is complete flexibility when it comes to the specific
>> consensus details of the hard fork. One common suggestion has been to phase
>> in a gradual blocksize increase beyond the initial 2MB cap included in
>> Luke-Jr's proposal (a la BIP103); this would certainly be a welcome
>> inclusion in the Omnibus Proposal, provided that is what we want. The
>> reasoning behind incorporating Luke-Jr's 2MB limit and discount-rebalancing
>> was to satisfy the conditions of the Scaling Agreement while ensuring
>> maximum safety, minimum code discrepancies, and minimum controversy among
>> the community; these priorities seem imperative, considering the extreme
>> timeline constraints we are working under and the goals of the proposal. To
>> put it more simply, the intent of the proposal was to serve as a template
>> for the minimum viable fork that can achieve true consensus. A gradual
>> increase to a larger size cap, especially if it were reasonably
>> conservative, would be wholly in accordance with the Omnibus Proposal if
>> that is what it takes to achieve the cooperation between community,
>> industry, and developers in this critical moment of Bitcoin's history.
>>
>>
>> The purpose of the Omnibus Proposal is singlefold: to achieve the goals
>> of the Consensus 2017 Scaling Agreement in the most maximally-compatible
>> way. We can minimize disruption and loss potential all around by solving
>> these problems in a compatibility-oriented manner. It is possible to
>> fulfill both the letter and the spirit of the Scaling Agreement, to the
>> complete satisfaction of all involved, while preventing chain-split risks
>> in the meantime.
>>
>>
>> There is no justification for incompatibility with existing deployment
>> approaches, when there is the possibility to work together towards our
>> mutual goals instead. The most rational option is to join forces and avoid
>> any chain-split potential for as long as possible. Under the Omnibus
>> Proposal, once SegWit is activated, the terms of the hard fork are locked
>> in automatically, set to activate 6 months later. The proposal guarantees
>> that a successful SegWit activation is followed by a hard fork. Beyond
>> enforcing the hard fork rules beginning at block height HardForkHeight, the
>> Omnibus Proposal simply represents compatibility with the existing
>> SegWit-activation deployment approaches.
>>
>>
>> By committing to this proposal, we can ensure unity, at least for now.
>> There do not appear to be any arguments to the contrary. Why squander this
>> opportunity for consensus and harmony? We can leverage the momentum of
>> several disparate movements, and perhaps enjoy some much-needed social
>> solidarity. In a way, everyone can get what they want, and through
>> cooperation, we avoid the risk of a costly fracture.
>>
>>
>> The Segwit2x Team has begun work on an implementation of the Consensus
>> Scaling Agreement, their operational timeline including the publication of
>> a BIP on June 16, 2017.[1] I call upon the developers and maintainers of
>> this initiative to consider and honor the Omnibus Proposal, extended or
>> modified as needed, as the guiding approach to your development effort.
>> Almost every component of the code exists, in some form or fashion, in the
>> various constituent proposals' reference implementations, most of which
>> have already undergone a significant degree of peer review.
>>
>>
>> We cannot afford to delay, nor to reimplement; the launch timeline is
>> aggressively optimistic as it is. The quickest and safest approach to
>> achieving the goals set forth at Consensus 2017 is to leverage the existing
>> tools and proposals for the job. We can solve our problems properly,
>> cooperatively.
>>
>>
>> I humbly ask that Jeff Garzik, Barry Silbert, Mike Belshe, and all of the
>> other wonderful, intelligent collaborators on this project step forward and
>> support the cooperative, compatibility-oriented approach of the Omnibus
>> Proposal.
>>
>>
>> This is the best way to maximize value for everyone. We have a real
>> opportunity to collaborate and work together on the same team. The Omnibus
>> Proposal, designed in exact accordance with a powerful industry agreement
>> and incorporating the feedback and suggestions provided from within both
>> the developer community and the community-at-large, stands the best chance
>> of uniting everyone under a common front.
>>
>>
>> Please, for the love of Bitcoin, let us do our best to cooperate.
>>
>>
>>
>> [1] https://imgur.com/a/a2oPs
>>
>>
>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>
>> -------- Original Message --------
>> Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
>> Local Time: May 29, 2017 6:49 PM
>> UTC Time: May 29, 2017 11:49 PM
>> From: opetruzel at gmail.com
>> To: CalvinRechner <calvinrechner at protonmail.com>
>> Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
>>
>> >>if the community wishes to adopt (by unanimous consensus) a 2 MB block
>> size hardfork, this is probably the best way to do it right now... Legacy
>> Bitcoin transactions are given the witness discount, and a block size limit
>> of 2 MB is imposed.<<
>>
>>
>> The above decision may quickly become very controversial. I don't think it's
>> what most users had/have in mind when they discuss a "2MB+SegWit" solution.
>>
>> With the current 1MB+SegWit, testing has shown us that normal usage
>> results in ~2 or 2.1MB blocks.
>>
>> I think most users will expect a linear increase when Base Size is
>> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
>> With normal usage, the expected results would then be ~4 or 4.2MB blocks.
>>
>> Am I missing something here, or does Luke's suggested 2MB cap completely
>> nullify that expected linear increase? If so, why? What's the logic behind
>> this decision?
>>
>> I'd love to be armed with a good answer should my colleagues ask me the
>> same obvious question, so thank you ahead of time!
>>
>> Respectfully,
>> Oliver Petruzel
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170602/6c0a891b/attachment.html>

2023-06-07 18:02:18

- reply

📅 Original date posted:2017-06-02
📝 Original message:By "upgrade" the HF you mean activate 2X and then spoonet 18 months later
or do not activate the 2x HF at all?
On Fri, Jun 2, 2017 at 4:04 PM, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> From me to you ...this proposal doesn't lock in anything. We could just
> merge it with some small pushback - allow segwit to activate in Aug, then
> "upgrade" the hard fork to be "spoonet in 18 months" instead.
>
> On Sat, Apr 1, 2017 at 8:33 AM, Jorge Timón via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
>> segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
>> MAX_BLOCK2_BASE_SIZE.
>> Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
>> mb weight to 8 mb weight.
>>
>> I would also use the hardfork bit (sign bit in block.nNersion) as matt
>> comments.
>>
>> > We're in a deadlock and it seems we can't go forward adding more
>> functionality to segwit without the community approval (which include
>> miners). This is obvious to me.Then we have to go back.
>>
>> If segwit is controversial the way it is (I still don't understand why
>> despite having insistently asking to users and miners who claim to
>> oppose it), adding more consensus rule changes won't make it any less
>> controversial. If anything, it would be removing consensus rule
>> changes, not adding them that could make it less controversial.
>>
>> By no means I want to dissuade you from working on this bip proposal,
>> but I really don't see how it helps getting out of the deadlock at
>> all.
>>
>>
>> On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Some people have asked me for the current implementation of this patch
>> to
>> > review. I remind you that the current patch does not implement the
>> hard-fork
>> > signaling, as requested by Matt.
>> >
>> > The Segwit2Mb patch can be found here:
>> > https://github.com/SergioDemianLerner/bitcoin/commits/master
>> >
>> > For now, the segwit2mb repo has a single test file using the old
>> internal
>> > blockchain building method (test/block_size_tests.cpp). This must be
>> > replaced soon with a better external test using the bitcoin/qa/rpc-tests
>> > tests, which I will begin to work on now after I collect all comments
>> from
>> > the community.
>> >
>> >
>> > regards
>> >
>> >
>> >
>> > On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <
>> jaredr26 at gmail.com>
>> > wrote:
>> >>
>> >> > Remember that the "hashpower required to secure bitcoin" is
>> determined
>> >> > as a percentage of total Bitcoins transacted on-chain in each block
>> >>
>> >> Can you explain this statement a little better? What do you mean by
>> >> that? What does the total bitcoins transacted have to do with
>> >> hashpower required?
>> >>
>> >>
>> >> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> > Hey Sergio,
>> >> >
>> >> > You appear to have ignored the last two years of Bitcoin hardfork
>> >> > research and understanding, recycling instead BIP 102 from 2015.
>> There
>> >> > are many proposals which have pushed the state of hard fork research
>> >> > much further since then, and you may wish to read some of the posts
>> on
>> >> > this mailing list listed at https://bitcoinhardforkresearc
>> h.github.io/
>> >> > and make further edits based on what you learn. Your goal of "avoid
>> >> > technical changes" appears to not have any basis outside of perceived
>> >> > compromise for compromise sake, only making such a hardfork riskier
>> >> > instead.
>> >> >
>> >> > At a minimum, in terms of pure technical changes, you should probably
>> >> > consider (probably among others):
>> >> >
>> >> > a) Utilizing the "hard fork signaling bit" in the nVersion of the
>> block.
>> >> > b) Either limiting non-SegWit transactions in some way to fix the
>> n**2
>> >> > sighash and FindAndDelete runtime and memory usage issues or fix
>> them by
>> >> > utilizing the new sighash type which many wallets and projects have
>> >> > already implemented for SegWit in the spending of non-SegWit outputs.
>> >> > c) Your really should have replay protection in any HF. The clever
>> fix
>> >> > from
>> >> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs
>> to
>> >> > be spent with SegWit's sighash provides this all in one go.
>> >> > d) You may wish to consider the possibility of tweaking the witness
>> >> > discount and possibly discounting other parts of the input - SegWit
>> went
>> >> > a long ways towards making removal of elements from the UTXO set
>> cheaper
>> >> > than adding them, but didn't quite get there, you should probably
>> finish
>> >> > that job. This also provides additional tuneable parameters to allow
>> you
>> >> > to increase the block size while not having a blowup in the
>> worst-case
>> >> > block size.
>> >> > e) Additional commitments at the top of the merkle root - both for
>> >> > SegWit transactions and as additional space for merged mining and
>> other
>> >> > commitments which we may wish to add in the future, this should
>> likely
>> >> > be implemented an "additional header" ala Johnson Lau's Spoonnet
>> >> > proposal.
>> >> >
>> >> > Additionally, I think your parameters here pose very significant
>> risk to
>> >> > the Bitcoin ecosystem broadly.
>> >> >
>> >> > a) Activating a hard fork with less than 18/24 months (and even
>> then...)
>> >> > from a fully-audited and supported release of full node software to
>> >> > activation date poses significant risks to many large software
>> projects
>> >> > and users. I've repeatedly received feedback from various folks that
>> a
>> >> > year or more is likely required in any hard fork to limit this risk,
>> and
>> >> > limited pushback on that given the large increase which SegWit
>> provides
>> >> > itself buying a ton of time.
>> >> >
>> >> > b) Having a significant discontinuity in block size increase only
>> serves
>> >> > to confuse and mislead users and businesses, forcing them to rapidly
>> >> > adapt to a Bitcoin which changed overnight both by hardforking, and
>> by
>> >> > fees changing suddenly. Instead, having the hard fork activate
>> technical
>> >> > changes, and then slowly increasing the block size over the following
>> >> > several years keeps things nice and continuous and also keeps us from
>> >> > having to revisit ye old blocksize debate again six months after
>> >> > activation.
>> >> >
>> >> > c) You should likely consider the effect of the many technological
>> >> > innovations coming down the pipe in the coming months. Technologies
>> like
>> >> > Lightning, TumbleBit, and even your own RootStock could significantly
>> >> > reduce fee pressure as transactions move to much faster and more
>> >> > featureful systems.
>> >> >
>> >> > Commitments to aggressive hard fork parameters now may leave miners
>> >> > without much revenue as far out as the next halving (which current
>> >> > transaction growth trends are indicating we'd just only barely reach
>> 2MB
>> >> > of transaction volume, let alone if you consider the effects of users
>> >> > moving to systems which provide more features for Bitcoin
>> transactions).
>> >> > This could lead to a precipitous drop in hashrate as miners are no
>> >> > longer sufficiently compensated.
>> >> >
>> >> > Remember that the "hashpower required to secure bitcoin" is
>> determined
>> >> > as a percentage of total Bitcoins transacted on-chain in each block,
>> so
>> >> > as subsidy goes down, miners need to be paid with fees, not just
>> price
>> >> > increases. Even if we were OK with hashpower going down compared to
>> the
>> >> > value it is securing, betting the security of Bitcoin on its price
>> >> > rising exponentially to match decreasing subsidy does not strike me
>> as a
>> >> > particularly inspiring tradeoff.
>> >> >
>> >> > There aren't many great technical solutions to some of these issues,
>> as
>> >> > far as I'm aware, but it's something that needs to be incredibly
>> >> > carefully considered before betting the continued security of
>> Bitcoin on
>> >> > exponential on-chain growth, something which we have historically
>> never
>> >> > seen.
>> >> >
>> >> > Matt
>> >> >
>> >> >
>> >> > On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via
>> bitcoin-dev
>> >> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> >>Hi everyone,
>> >> >>
>> >> >>Segwit2Mb is the project to merge into Bitcoin a minimal patch that
>> >> >>aims to
>> >> >>untangle the current conflict between different political positions
>> >> >>regarding segwit activation vs. an increase of the on-chain
>> blockchain
>> >> >>space through a standard block size increase. It is not a new
>> solution,
>> >> >>but
>> >> >>it should be seen more as a least common denominator.
>> >> >>
>> >> >>Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB
>> >> >>block
>> >> >>size hard-fork activated ONLY if segwit activates (95% of miners
>> >> >>signaling), but at a fixed future date.
>> >> >>
>> >> >>The sole objective of this proposal is to re-unite the Bitcoin
>> >> >>community
>> >> >>and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
>> >> >>possible technical solution to solve Bitcoin technical limitations.
>> >> >>However, this proposal does not imply a compromise to the future
>> >> >>scalability or decentralization of Bitcoin, as a small increase in
>> >> >>block
>> >> >>size has been proven by several core and non-core developers not to
>> >> >>affect
>> >> >>Bitcoin value propositions.
>> >> >>
>> >> >>In the worst case, a 2X block size increase has much lower economic
>> >> >>impact
>> >> >>than the last bitcoin halving (<10%), which succeeded without
>> problem.
>> >> >>
>> >> >>On the other side, Segwit2Mb primary goal is to be minimalistic: in
>> >> >>this
>> >> >>patch some choices have been made to reduce the number of lines
>> >> >>modified in
>> >> >>the current Bitcoin Core state (master branch), instead of
>> implementing
>> >> >>the
>> >> >>most elegant solution. This is because I want to reduce the time it
>> >> >>takes
>> >> >>for core programmers and reviewers to check the correctness of the
>> >> >>code,
>> >> >>and to report and correct bugs.
>> >> >>
>> >> >>The patch was built by forking the master branch of Bitcoin Core,
>> >> >>mixing a
>> >> >>few lines of code from Jeff Garzik's BIP102, and defining a second
>> >> >>versionbits activation bit (bit 2) for the combined activation.
>> >> >>
>> >> >>The combined activation of segwit and 2Mb hard-fork nVersion bit is 2
>> >> >>(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
>> >> >>
>> >> >>This means that segwit can still be activated without the 2MB
>> hard-fork
>> >> >>by
>> >> >>signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT).
>> >> >>
>> >> >>The tentative lock-in and hard-fork dates are the following:
>> >> >>
>> >> >>Bit 2 signaling StartTime = 1493424000; // April 29th, 2017
>> >> >>
>> >> >>Bit 2 signaling Timeout = 1503964800; // August 29th, 2017
>> >> >>
>> >> >>HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
>> >> >>
>> >> >>
>> >> >>The hard-fork is conditional to 95% of the hashing power has approved
>> >> >>the
>> >> >>segwit2mb soft-fork and the segwit soft-fork has been activated
>> (which
>> >> >>should occur 2016 blocks after its lock-in time)
>> >> >>
>> >> >>For more information on how soft-forks are signaled and activated,
>> see
>> >> >>https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
>> >> >>
>> >> >>This means that segwit would be activated before 2Mb: this is
>> >> >>inevitable,
>> >> >>as versionbits have been designed to have fixed activation periods
>> and
>> >> >>thresholds for all bits. Making segwit and 2Mb fork activate together
>> >> >>at a
>> >> >>delayed date would have required a major re-write of this code, which
>> >> >>would
>> >> >>contradict the premise of creating a minimalistic patch. However,
>> once
>> >> >>segwit is activated, the hard-fork is unavoidable.
>> >> >>
>> >> >>Although I have coded a first version of the segwit2mb patch (which
>> >> >>modifies 120 lines of code, and adds 220 lines of testing code), I
>> >> >>would
>> >> >>prefer to wait to publish the source code until more comments have
>> been
>> >> >>received from the community.
>> >> >>
>> >> >>To prevent worsening block verification time because of the O(N^2)
>> >> >>hashing
>> >> >>problem, the simple restriction that transactions cannot be larger
>> than
>> >> >>1Mb
>> >> >>has been kept. Therefore the worse-case of block verification time
>> has
>> >> >>only
>> >> >>doubled.
>> >> >>
>> >> >>Regarding the hard-fork activation date, I want to give enough time
>> to
>> >> >>all
>> >> >>active economic nodes to upgrade. As of Fri Mar 31 2017,
>> >> >>https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes
>> (91%)
>> >> >>have upgraded to post 0.12 versions. Upgrade to post 0.12 versions
>> can
>> >> >>be
>> >> >>used to identify economic active nodes, because in the 0.12 release
>> >> >>dynamic
>> >> >>fees were introduced, and currently no Bitcoin automatic payment
>> system
>> >> >>can
>> >> >>operate without automatic discovery of the current fee rate. A
>> pre-0.12
>> >> >>would require constant manual intervention.
>> >> >>Therefore I conclude that no more than 91% of the network nodes
>> >> >>reported by
>> >> >>bitnodes are active economic nodes.
>> >> >>
>> >> >>As Bitcoin Core 0.12 was released on February 2016, the time for this
>> >> >>91%
>> >> >>to upgrade has been around one year (under a moderate pressure of
>> >> >>operational problems with unconfirmed transactions).
>> >> >>Therefore we can expect a similar or lower time to upgrade for a
>> >> >>hard-fork,
>> >> >>after developers have discussed and approved the patch, and it has
>> been
>> >> >>reviewed and merged and 95% of the hashing power has signaled for it
>> >> >>(the
>> >> >>pressure not to upgrade being a complete halt of the operations).
>> >> >>However I
>> >> >>suggest that we discuss the hard-fork date and delay it if there is a
>> >> >>real
>> >> >>need to.
>> >> >>
>> >> >>Currently time works against the Bitcoin community, and so is
>> delaying
>> >> >>a
>> >> >>compromise solution. Most of the community agree that halting the
>> >> >>innovation for several years is a very bad option.
>> >> >>
>> >> >>After the comments collected by the community, a BIP will be written
>> >> >>describing the resulting proposal details.
>> >> >>
>> >> >>If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes
>> should
>> >> >>be
>> >> >>updated to a Segwit2Mb enabled node to prevent them to be forked-away
>> >> >>in a
>> >> >>chain with almost no hashing-power.
>> >> >>
>> >> >>The proof of concept patch was made for Bitcoin Core but should be
>> >> >>easily
>> >> >>ported to other Bitcoin protocol implementations that already support
>> >> >>versionbits. Lightweight (SPV) wallets should not be affected as they
>> >> >>generally do not check the block size.
>> >> >>
>> >> >>I personally want to see the Lightning Network in action this year,
>> use
>> >> >>the
>> >> >>non-malleability features in segwit, see the community discussing
>> other
>> >> >>exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains
>> >> >>and
>> >> >>MAST.
>> >> >>
>> >> >>I want to see miners, developers and industry side-by-side pushing
>> >> >>Bitcoin
>> >> >>forward, to increase the value of Bitcoin and prevent high
>> transaction
>> >> >>fees
>> >> >>to put out of business use-cases that could have high positive social
>> >> >>impact.
>> >> >>
>> >> >>I believe in the strength of a unified Bitcoin community. If you're a
>> >> >>developer, please give your opinion, suggest changes, audit it, and
>> >> >>take a
>> >> >>stand with me to unlock the current Bitcoin deadlock.
>> >> >>
>> >> >>Contributions to the segwit2mb project are welcomed and awaited. The
>> >> >>only
>> >> >>limitation is to stick to the principle that the patch should be as
>> >> >>simple
>> >> >>to audit as possible. As an example, I wouldn't feel confident if the
>> >> >>patch
>> >> >>modified more than ~150 lines of code.
>> >> >>
>> >> >>Improvements unrelated to a 2 Mb increase or segwit, as beneficial as
>> >> >>it
>> >> >>may be to Bitcoin, should not be part of segwit2Mb.
>> >> >>
>> >> >>This proposal should not prevent other consensus proposals to be
>> >> >>simultaneously merged: segwit2mb is a last resort solution in case we
>> >> >>can
>> >> >>not reach consensus on anything better.
>> >> >>
>> >> >>Again, the proposal is only a starting point: community feedback is
>> >> >>expected and welcomed.
>> >> >>
>> >> >>Regards,
>> >> >>Sergio Demian Lerner
>> >> > _______________________________________________
>> >> > 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
>>
>
>
> _______________________________________________
> 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/20170602/40964871/attachment-0001.html>

2023-06-07 18:01:01

- reply

📅 Original date posted:2017-05-10
📝 Original message:I'm not advocating. I'm mediating.
This is out of
On Wed, May 10, 2017 at 1:39 PM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> I highly disagree about the "not shit" part. You're advocating for
> throwing away one of the key features of Segwit, something that is very
> important for Bitcoin's long-term reliability! If you think doing so is
> going to somehow help get support in a divided community, I don't
> understand how - more likely you're only going to make things significantly
> worse.
>
> On May 10, 2017 11:25:27 AM EDT, Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
> >Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It
> >has
> >always been good enough. And at the beginning it was quite simple.
> >Simple
> >enough it allowed gradual improvements that anyone with some technical
> >background could understand. Now we need a full website to explain an
> >improvement.
> >But this is becoming more and more out of topic.
> >
> >
> >On Wed, May 10, 2017 at 11:05 AM, Matt Corallo
> ><lf-lists at mattcorallo.com>
> >wrote:
> >
> >> I'm highly unconvinced of this point. Sure, you can change fewer
> >lines
> >> of code, but if the result is, lets be honest, shit, how do you
> >believe
> >> its going to have a higher chance of getting acceptance from the
> >broader
> >> community? I think you're over-optimizing in the wrong direction.
> >>
> >> Matt
> >>
> >> On 05/09/17 20:58, Sergio Demian Lerner wrote:
> >> > I agree with you Matt.
> >> > I'm artificially limiting myself to changing the parameters of
> >Segwit as
> >> > it is..
> >> >
> >> > This is motivated by the idea that a consensual HF in the current
> >state
> >> > would have greater chance of acceptance if it changes the minimum
> >number
> >> > of lines of code.
> >> >
> >> >
> >> >
> >> > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell <greg at xiph.org
> >> > <mailto:greg at xiph.org>> wrote:
> >> >
> >> > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo
> >> > <lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>>
> >wrote:
> >> > > at beast.
> >> >
> >> > Rawr.
> >> >
> >> >
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170510/cb1623ce/attachment-0001.html>

2023-06-07 18:01:00

- reply

📅 Original date posted:2017-05-09
📝 Original message:I agree with you Matt.
I'm artificially limiting myself to changing the parameters of Segwit as it
is..
This is motivated by the idea that a consensual HF in the current state
would have greater chance of acceptance if it changes the minimum number of
lines of code.
On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell <greg at xiph.org> wrote:
> On Tue, May 9, 2017 at 7:42 PM, Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
> > at beast.
>
> Rawr.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/d8ac393a/attachment.html>

2023-06-07 18:01:00

- reply

📅 Original date posted:2017-05-10
📝 Original message:Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It has
always been good enough. And at the beginning it was quite simple. Simple
enough it allowed gradual improvements that anyone with some technical
background could understand. Now we need a full website to explain an
improvement.
But this is becoming more and more out of topic.
On Wed, May 10, 2017 at 11:05 AM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> I'm highly unconvinced of this point. Sure, you can change fewer lines
> of code, but if the result is, lets be honest, shit, how do you believe
> its going to have a higher chance of getting acceptance from the broader
> community? I think you're over-optimizing in the wrong direction.
>
> Matt
>
> On 05/09/17 20:58, Sergio Demian Lerner wrote:
> > I agree with you Matt.
> > I'm artificially limiting myself to changing the parameters of Segwit as
> > it is..
> >
> > This is motivated by the idea that a consensual HF in the current state
> > would have greater chance of acceptance if it changes the minimum number
> > of lines of code.
> >
> >
> >
> > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell <greg at xiph.org
> > <mailto:greg at xiph.org>> wrote:
> >
> > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo
> > <lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>> wrote:
> > > at beast.
> >
> > Rawr.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170510/6ecb8e46/attachment.html>

2023-06-07 18:00:59

- reply

📅 Original date posted:2017-05-09
📝 Original message:Let n be the non-segwit bytes. Let the seg/noseg ratio be 1.7.
Segwit with 75% discount: (let WITNESS_SCALE_FACTOR=4)
n*WITNESS_SCALE_FACTOR+n*1.7 = 4,000,000
Then n=4,000,000 / 5.7 = 701K
Average block size = 701K*(1+1.7)=1.8 Mbytes
Maximum block size = 4 MBytes
Segwit with 50% discount + 2MB HF: (let WITNESS_SCALE_FACTOR=2)
n*2+n*1.7 = 4,000,000
n = 4,000,000/ 3.7 = 1.08M
Average block size = 1.08M*(1+1.7)=2.9 Mbytes
Maximum block size = 4 MBytes
The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum
block size is the same.
On Tue, May 9, 2017 at 3:58 PM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
>
>>
>> You suggested "If the maximum block weight is set to 2.7M, each byte of
>> non-witness block costs 1.7", but these numbers dont work out - setting
>> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
>> fork), not 2.7MB.
>
>
> Yes. In a soft-fork is true.
> I was thinking about what a HF could do to optimize the balance, and I
> forgot I was in the context of a SF.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/4a3d4465/attachment-0001.html>

2023-06-07 18:00:58

- reply

📅 Original date posted:2017-05-09
📝 Original message:>
>
>
> You suggested "If the maximum block weight is set to 2.7M, each byte of
> non-witness block costs 1.7", but these numbers dont work out - setting
> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
> fork), not 2.7MB.
Yes. In a soft-fork is true.
I was thinking about what a HF could do to optimize the balance, and I
forgot I was in the context of a SF.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/473e88df/attachment.html>

2023-06-07 18:00:57

- reply

📅 Original date posted:2017-05-09
📝 Original message:Thanks Johnson and Hampus for the clarifications.
However, I would rather do the opposite: soft-fork to 50% now, and
soft-fork again to 75% discount later if needed, because it doesn't affect
the max transactions/second.
Segwit as it is today should be activated. However if it is not before
November, then for the next Segwit attempt I would choose a more
conservative 50% discount.
On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
>
> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >
> > So it seems the 75% discount has been chosen with the idea that in the
> future the current transaction pattern will shift towards multisigs. This
> is not a bad idea, as it's the only direction Bitcoin can scale without a
> HF.
> > But it's a bad idea if we end up doing, for example, a 2X blocksize
> increase HF in the future. In that case it's much better to use a 50%
> witness discount, and do not make scaling risky by making the worse case
> block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
> >
>
> As we could change any parameter in a hardfork, I don’t think this has any
> relation with the current BIP141 proposal. We could just use 75% in a
> softfork, and change that to a different value (or completely redefine the
> definition of weight) with a hardfork later.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/e01b3062/attachment-0001.html>

2023-06-07 18:00:56

- reply

📅 Original date posted:2017-05-09
📝 Original message:This [1] article says the current discount prevents witness spam. Witness
spam is free space in the witness part of the block that can be filled by
miners to create bigger blocks with almost no cost for the benefit a
cluster of miners with low latency, increasing centralization.
The 75% discount does not prevent it, but on the contrary leaves a lot of
extra witness space for spam.
If the maximum block weight is set to 2.7M, each byte of non-witness block
costs 1.7, and each byte of witness costs 1, then a normal filled block
would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4
Mbyte block. The worst case would be the average case, and the transaction
rate would be the maximum possible.
The current 75% discount can only achieve more transactions per second if
the type of transactions change. Therefore the current 75% discount only
makes the block size worst case worse (4 Mbytes when it should be 2.7
Mbytes).
80% of all inputs/outputs are P2PKH. The only way to make use of the extra
witness
space If most P2PKH transactions are replaced by multisigs (typically for
LN).
So it seems the 75% discount has been chosen with the idea that in the
future the current transaction pattern will shift towards multisigs. This
is not a bad idea, as it's the only direction Bitcoin can scale without a
HF.
But it's a bad idea if we end up doing, for example, a 2X blocksize
increase HF in the future. In that case it's much better to use a 50%
witness discount, and do not make scaling risky by making the worse case
block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
I've uploaded the code here:
https://github.com/SergioDemianLerner/SegwitStats
[1] https://segwit.org/why-a-discount-factor-of-4-why-not-
2-or-8-bbcebe91721e.
On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Sergio,
>
> I'm not sure what the data you present has to do with the discount. A 75%
> discount prevents witness spam precisely because it is 75%, nothing more.
> The current usage simply gives a guideline on how much capacity is gained
> through a particular discount. With the data you show, it would imply that
> those blocks, with SegWit used where possible, would result in blocks of
> ~1.8MB.
>
>
>
> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have processed 1000 blocks starting from Block #461653.
>>
>> I computed several metrics, including the supposed size of witness data
>> and non-witness data (onchain), assuming all P2SH inputs/outputs are
>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
>>
>> This takes into account that other types of transactions will not be
>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
>> take into account that LN transactions may affect the current state,
>> increasing the segwit/nosegwit ratio.
>>
>> Among a lot of information, I've got the following real world results...
>>
>> acMainChainSpace =352608924
>> acSegwitSpace =599400403
>> Ratio segwit/nosegwit=1.6999
>>
>> This implies that the 75% that discount is not the best option to prevent
>> witness spam in a block of 4 MB, as stated in
>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e
>> .
>>
>> The non-witness data weight factor should not be 4 but 2.35. The closest
>> integer value is 2, which leads to a 50% witness discount.
>>
>> The Bitcoinj source code is available for anyone to review. I encourage
>> anyone to re-compute this with another utility to cross-check. Maybe
>> Antoine Le Calvez (p2sh.info) would like to double-check.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170509/38a4f95e/attachment.html>

2023-06-07 18:00:55

- reply

📅 Original date posted:2017-05-08
📝 Original message:I have processed 1000 blocks starting from Block #461653.
I computed several metrics, including the supposed size of witness data and
non-witness data (onchain), assuming all P2SH inputs/outputs are converted
to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
This takes into account that other types of transactions will not be
modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
take into account that LN transactions may affect the current state,
increasing the segwit/nosegwit ratio.
Among a lot of information, I've got the following real world results...
acMainChainSpace =352608924
acSegwitSpace =599400403
Ratio segwit/nosegwit=1.6999
This implies that the 75% that discount is not the best option to prevent
witness spam in a block of 4 MB, as stated in
https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
The non-witness data weight factor should not be 4 but 2.35. The closest
integer value is 2, which leads to a 50% witness discount.
The Bitcoinj source code is available for anyone to review. I encourage
anyone to re-compute this with another utility to cross-check. Maybe
Antoine Le Calvez (p2sh.info) would like to double-check.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170508/aaeb7ba1/attachment.html>

2023-06-07 18:00:48

- reply

📅 Original date posted:2017-05-08
📝 Original message:Yes you practically can. No proxy can defeat the protocol investing less
money than buying storage space to store the blockchain.
Even with challenge-response delays of minutes. That's why it will be
fully controlled by a RSK smart-contract, with no user intervention.
I'm will post about this soon.
On Mon, May 8, 2017 at 6:44 PM, Natanael <natanael.l at gmail.com> wrote:
>
> Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org>:
>
> I'll soon present a solution to encourage full nodes to store the
> blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)
>
>
> Proving that you're holding your own copy of the blockchain, not shared
> with other nodes? I don't think that's possible to do securely. It falls on
> that the whole blockchain is both public and static, while any such proof
> of independence needs to rely on unique capabilities per node.
>
> All you can do with a challenge-response protocol is to prevent honest
> nodes from being unwitting backends to dishonest transparent proxy nodes
> (by binding the challenge to cryptographic node identities).
>
> Even latency bounding protocols can't stop you from putting multiple
> *seemingly independent* nodes in front of the same backend with one single
> copy of the blockchain.
>
> I believe best you can do is to force somebody to hold multiple copies
> locally on multiple hardware units to not run out of memory I/O when
> creating proofs for multiple remote nodes, through using memory heavy
> functions for the proof of storage, forcing quick random access. However
> somebody willing to put enough RAM in a server rack to hold the full
> blockchain could still easily pretend to be multiple regular nodes with
> independent copies.
>
> Any kind of attempt at forcing the full copy of the blockchain to be in
> memory close to the CPU will either rule out most nodes from passing or
> will be cheatable.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170508/ae0f8ad0/attachment.html>

2023-06-07 18:00:47

- reply

📅 Original date posted:2017-05-08
📝 Original message:A full node provides several services to the network:
1•Broadcasts blocks (public service)
2•Broadcasts transactions (public/private service)
3•Increases privacy by hiding other node’s IPs
4•Increases network security by protecting it from global DoS.
5•Provides information filtering services to SPV nodes.
6•Provides historic blockchain and state information to new nodes.
With your tip idea you only encourages 6, and by increasing the number of
nodes, also 3 and 4.
The services 1 and 2 cannot be encouraged by tips.
However, it's a good way to start.
There was a way to encourage 2 I described in 2013. (
https://bitcointalk.org/index.php?topic=385528.msg4155300#msg4155300)
I'll soon present a solution to encourage full nodes to store the
blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS), a feature
that RSK will add to incentivize Bitcoin and RSK full nodes. This solution
encourages 6.
On Thu, May 4, 2017 at 4:28 PM, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is actually LN’s killer use case - not buying coffees ;)
>>
>
> Yes, micro-payments for online network services is precisely what LN is
> best at.
>
> Establishing a channel with each peer is too expensive. But using LN to
> micro-pay for high-quality peer services seems like it would aggregate very
> well.
>
> It would be great if this protocol was in-place and ready to go in or
> around the same time LN is ready. It would incentivize full nodes even
> further than LN does, and allow the network to be strongly DDOS resistant.
>
>
> _______________________________________________
> 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/20170508/02bf028a/attachment.html>

2023-06-07 18:00:27

- reply

📅 Original date posted:2017-04-17
📝 Original message:I came across O(N) behavior of two scripting opcodes, OP_IF and OP_ROLL. By
exploiting edge cases for each of these two sub-optimal algorithms, I
manage to simulate a Segwit block that takes up to 5.6 seconds to verify on
a Ubuntu VM running on a single Core i5 processor. The simulation is based
on a single thread executing EvalScript(), the Bitcoin script execution
function. The tests were not performed processing actual blocks. These
results should not make anyone worry, because there are worse problems in
Bitcoin block verification, and because Bitcoin employs several worker
threads for verifying scripts in parallel. For example, a Segwit block can
request 80000 signature verifications when all transactions are P2WSH. It
is said that Bitcoin Core (in a modern multi-core machine, using its
multi-threading verification capabilities) can verify 8000 ECDSA signatures
per second. Therefore a malicious miner can create a Segwit block that
requires approximately 10 seconds to be verified. Since the examples
presented in this post consume less than 10 seconds, I don’t consider my
findings as vulnerabilities. However, if the block size is to be increased
in the future, these problems should be considered prior increasing the
block size. The scripts presented here as examples do not leave the value
stack empty, but the Bitcoin protocol does not require it. Bitcoin only
requires the top value to be true to accept the script.
OP_IF abuse
Every time a Bitcoin script executes the OP_IF opcode, a boolean value
indicating if the condition was true, false or the conditional was skipped
(also represented as false) is pushed into the vfExec stack. Every time an
opcode is executed, the number of false values in the vfExec stack is
counted using the following line:
bool fExec = !count(vfExec.begin(), vfExec.end(), false);
If the count is non-zero, all subsequent instructions except OP_ELSE and
OP_ENDIF are skipped. It is clear that the longer the conditional stack is,
the more it takes to count the false elements.
The following scriptPub or ScriptSig exploits this problem:
0
OP_IF { 100 times }
0 { 9798 times }
OP_ENDIF { 100 times }
1
The vfExec vector is filled with 100 elements, and then each element is
scanned 9799 times, totaling more than 979K items scanned. This took 2.5
seconds in my test VM (for a block filled with these scriptSigs).
To re-write this logic with a O(1) algorithm, one simply has to count the
number of true conditions in one variable (trueCount), and the number of
false or skipped conditions following all true conditions in another
(ignoreCount). Detecting if code needs to be executed or not requires just
testing if ignoreCount is zero.
The handling of OP_IF / OP_NOTIF / OP_ELSE should be like the following
pseudo-code:
fExec = (ignoreCount==0);
...
case OP_IF:
case OP_NOTIF:
{
if (fExec)
{
....compute fValue...
if (fValue) trueCount++; else ignoreCount++;
} else
ignoreCount++;
} break;
case OP_ELSE:
{
if ((trueCount==0) && (ignoreCount==0))
return set_error(serror, SCRIPT_ERR_UNBALANCED_CONDITIONAL);
if (ignoreCount==0) { trueCount--; ignoreCount++; } else
if (ignoreCount==1) { trueCount++; ignoreCount--; }
} break;
case OP_ENDIF:
{
if ((trueCount==0) && (ignoreCount==0))
return set_error(serror, SCRIPT_ERR_UNBALANCED_CONDITIONAL);
if (ignoreCount>0) ignoreCount--; else trueCount--;
}
break;
You may have noticed the strange behavior of Bitcoin’s ELSE statement.
Bitcoin allows one to switch between true and false conditions several
times. For example, the following script is valid and leaves the value 2 on
the stack:
1 OP_IF OP_ELSE OP_ELSE 2 OP_ENDIF
OP_ROLL
The second problem lies in the OP_ROLL opcode. This opcode removes a value
at a given index from the value stack, and pushes it on top. As the Bitcoin
Core stack stores a list of char std::vector by value (not by reference),
and because the stack is itself a std::vector (not a linked list), then
removing the first elements requires moving all elements one position in
memory. The value stack can store a maximum of 1000 elements. The following
script fills the stack and then moves each stack element 200 times, so the
number of moved elements is 200K. This took almost 5.6 seconds in my test
VM (for a block filled with these scriptSigs).
1 {999 times}
998 OP_ROLL { 200 times }
I tried other scripts, such as filling the stack with values of size 520
using DUP3, and then performing rolls, but all of them led to a block that
took less time, if the block is to be filled with the scripts.
One solution to this problem is use a linked list data structure instead of
a std::vector, to allow O(1) removal of items, but it still requires O(N)
for element lookup. A balanced tree where each internal node is augmented
with the number of children underneath can be used to provide efficient
indexed access and efficient element removal. However, the overhead of such
data structure may kill its benefits.
So it may be the case that optimizing OP_ROLL will never really be
required.
But these minor issues have to be taken into account if the scripting
system is modified in any way. There are many subtle interactions. For
instance, it may seem that Segwit allows a transaction having a stack
containing 2 million items to verify correctly, by having the witness stack
filled with 2M zero values, and by executing an empty witness script.
However this is prevented by the cleanstack check.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/64f59d8e/attachment.html>

2023-06-07 17:59:57

- reply

📅 Original date posted:2017-04-07
📝 Original message:<pre>
BIP: TBD
Layer: Consensus
Title: Inhibiting a covert optimization on the Bitcoin POW function
Author: Sergio Demian Lerner <sergio.d.lerner at gmail.com>
Status: Draft
Type: Standards Track
Created: 2016-04-07
License: PD
</pre>
==Abstract==
This proposal inhibits the covert use of a known optimization in Bitcoin
Proof of Work function.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
==Motivation==
Due to a design oversight the Bitcoin proof of work function has a potential
optimization which can allow a rational miner to save up-to 30% of their
energy
costs (though closer to 20% is more likely due to implementation overheads).
Timo Hanke and Sergio Demian Lerner applied for a patent on this
optimization. The company "Sunrise Tech Group, Llc" has offered to license
it to any interested party in the past. Sunrise Tech Group has been
marketing their patent licenses under the trade-name ASICBOOST. The
document takes no position on the validity or enforceability of the patent.
There are two major ways of taking advantage of this optimization, as
described
by the patent:
One way which is highly detectable and is not in use on the network
today and a covert way which has significant interaction and potential
interference with the Bitcoin protocol. The covert mechanism is not
easily detected except through its interference with the protocol.
In particular, the protocol interactions of the covert method can block the
implementation of virtuous improvements such as segregated witness.
The use of this optimization could result in a big payoff, but the actual
sum depends on the degree of research, investment and effort put into
designing
the improved cores.
On the above basis the potential for covert use of this optimization
in the covert form and interference with useful improvements presents a
danger to the Bitcoin system.
==Background==
The general idea of this optimization is that SHA2-256 is a merkle damgard
hash
function which consumes 64 bytes of data at a time.
The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while
incriminating a 32-bit nonce which is at the end of this header data. This
means that the processing of the header involves two runs of the compression
function run-- one that consumes the first 64 bytes of the header and a
second which processes the remaining 16 bytes and padding.
The initial 'message expansion' operations in each step of the SHA2-256
function operate exclusively on that step's 64-bytes of input with no
influence from prior data that entered the hash.
Because of this if a miner is able to prepare a block header with
multiple distinct first 64-byte chunks but identical 16-byte
second chunks they can reuse the computation of the initial
expansion for multiple trials. This reduces power consumption.
There are two broad ways of making use of this optimization. The obvious
way is to try candidates with different version numbers. Beyond
upsetting the soft-fork detection logic in Bitcoin nodes this has
little negative effect but it is highly conspicuous and easily
blocked.
The other method is based on the fact that the merkle root
committing to the transactions is contained in the first 64-bytes
except for the last 4 bytes of it. If the miner finds multiple
candidate root values which have the same final 32-bit then they
can use the optimization.
To find multiple roots with the same trailing 32-bits the miner can
use efficient collision finding mechanism which will find a match
with as little as 2^16 candidate roots expected, 2^24 operations to
find a 4-way hit, though low memory approaches require more
computation.
An obvious way to generate different candidates is to grind the
coinbase extra-nonce but for non-empty blocks each attempt will
require 13 or so additional sha2 runs which is very inefficient.
This inefficiency can be avoided by computing a sqrt number of
candidates of the left side of the hash tree (e.g. using extra
nonce grinding) then an additional sqrt number of candidates of
the right side of the tree using transaction permutation or
substitution of a small number of transactions. All combinations
of the left and right side are then combined with only a single
hashing operation virtually eliminating all tree related
overhead.
With this final optimization finding a 4-way collision with a
moderate amount of memory requires ~2^24 hashing operations
instead of the >2^28 operations that would be require for
extra-nonce grinding which would substantially erode the
benefit of the optimization.
It is this final optimization which this proposal blocks.
==New consensus rule==
Beginning block X and until block Y the coinbase transaction of
each block MUST either contain a BIP-141 segwit commitment or a
correct WTXID commitment with ID 0xaa21a9ef.
(See BIP-141 "Commitment structure" for details)
Existing segwit using miners are automatically compatible with
this proposal. Non-segwit miners can become compatible by simply
including an additional output matching a default commitment
value returned as part of getblocktemplate.
Miners SHOULD NOT automatically discontinue the commitment
at the expiration height.
==Discussion==
The commitment in the left side of the tree to all transactions
in the right side completely prevents the final sqrt speedup.
A stronger inhibition of the covert optimization in the form of
requiring the least significant bits of the block timestamp
to be equal to a hash of the first 64-bytes of the header. This
would increase the collision space from 32 to 40 or more bits.
The root value could be required to meet a specific hash prefix
requirement in order to increase the computational work required
to try candidate roots. These change would be more disruptive and
there is no reason to believe that it is currently necessary.
The proposed rule automatically sunsets. If it is no longer needed
due to the introduction of stronger rules or the acceptance of the
version-grinding form then there would be no reason to continue
with this requirement. If it is still useful at the expiration
time the rule can simply be extended with a new softfork that
sets longer date ranges.
This sun-setting avoids the accumulation of technical debt due
to retaining enforcement of this rule when it is no longer needed
without requiring a hard fork to remove it.
== Overt optimization ==
A BIP for avoiding erroneous warning messages when miners use the overt
version
of the optimization was proposed several years ago, in order to deter the
covert
use of the optimization. But that BIP was rejected.
However, in light of the current discoveries, that BIP could be
reconsidered.
The over optimization does not generally interfere with improvements in the
protocol.
==Backward compatibility==
==Implementation==
==Acknowledgments==
Greg Maxwell <greg at xiph.org> for the original report, which contained
several errors that were corrected in the present proposal.
==Copyright==
This document is placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/46d4d476/attachment-0001.html>

2023-06-07 17:58:52

- reply

📅 Original date posted:2017-04-06
📝 Original message:The 95% miner signaling is important to prevent two Bitcoin forks, such as
what happened with Ethereum HF and Ethereum Classic.
Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has
just 95% miner support will initially (for 2016 blocks) be 5% slower (an
average block every 10 minutes and 30 seconds). The transaction capacity of
the new Bitcoin protocol is reduced only 5%.
However the chain with 5% if the hashing power not only has a 20x capacity
reduction, but confirms transactions in 20x more time. So the mempool will
grow 400 times. It must be noted that fees increased 10x from the moment
blocks were half full, to the moment blocks became saturated. I'm sure no
Bitcoin (pre-fork) user will be willing to pay 100x times the transaction
fees to use such a slow and insecure network.
So a 6-block confirmation will take 20 hours in the original chain and the
original chain will be in this almost useless slow state for an average of
2016 blocks, or 280 days.
If the original blockchain hard-forks to re-adjust the difficulty, then it
will just represent an alt-coin having 5% of Bitcoin community, and it
can't affect Bitcoin (the segwit2mb fork).
On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak at gmail.com> wrote:
> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The hard-fork is conditional to 95% of the hashing power has approved the
>> segwit2mb soft-fork and the segwit soft-fork has been activated (which
>> should occur 2016 blocks after its lock-in time)
>>
>
> Miners signalling they have upgraded by flipping a bit in the nVersion
> field has little relevance in a hard fork. If 100% of the hash power
> indicates they are running this proposal, but the nodes don't upgrade, what
> will happen?
>
> For the record, I actually talk a lot about hard forks with various
> developers and am very interested in the research that Johnson in
> particular is pioneering. However, I have failed to understand your point
> about 95% miner signalling in relation to a hard fork, so I am eagerly
> awaiting your explanation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/a91923df/attachment.html>

2023-06-07 17:58:52

- reply

📅 Original date posted:2017-04-06
📝 Original message:Ups. My mistake: the mempool will not grow 400 times, the is no square
there.
I will initially grow 20 times. Multiplied by the number of times a
transaction may need to be replaced with one with higher fees. Maybe 50
times, but not 400.
On Thu, Apr 6, 2017 at 5:42 PM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
> The 95% miner signaling is important to prevent two Bitcoin forks, such as
> what happened with Ethereum HF and Ethereum Classic.
>
> Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has
> just 95% miner support will initially (for 2016 blocks) be 5% slower (an
> average block every 10 minutes and 30 seconds). The transaction capacity of
> the new Bitcoin protocol is reduced only 5%.
> However the chain with 5% if the hashing power not only has a 20x capacity
> reduction, but confirms transactions in 20x more time. So the mempool will
> grow 400 times. It must be noted that fees increased 10x from the moment
> blocks were half full, to the moment blocks became saturated. I'm sure no
> Bitcoin (pre-fork) user will be willing to pay 100x times the transaction
> fees to use such a slow and insecure network.
>
> So a 6-block confirmation will take 20 hours in the original chain and the
> original chain will be in this almost useless slow state for an average of
> 2016 blocks, or 280 days.
> If the original blockchain hard-forks to re-adjust the difficulty, then it
> will just represent an alt-coin having 5% of Bitcoin community, and it
> can't affect Bitcoin (the segwit2mb fork).
>
>
> On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak at gmail.com> wrote:
>
>> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> The hard-fork is conditional to 95% of the hashing power has approved
>>> the segwit2mb soft-fork and the segwit soft-fork has been activated (which
>>> should occur 2016 blocks after its lock-in time)
>>>
>>
>> Miners signalling they have upgraded by flipping a bit in the nVersion
>> field has little relevance in a hard fork. If 100% of the hash power
>> indicates they are running this proposal, but the nodes don't upgrade, what
>> will happen?
>>
>> For the record, I actually talk a lot about hard forks with various
>> developers and am very interested in the research that Johnson in
>> particular is pioneering. However, I have failed to understand your point
>> about 95% miner signalling in relation to a hard fork, so I am eagerly
>> awaiting your explanation.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/3b9044c6/attachment.html>

2023-06-07 17:58:51

- reply

📅 Original date posted:2017-04-06
📝 Original message:Responding between lines...
On Wed, Apr 5, 2017 at 11:27 PM, Erik Aronesty <earonesty at gmail.com> wrote:
> I personally appreciate the minimal changes, and often encourage
> development to be done this way - when it needs to be released quickly.
> But does this need to be released quickly?
>
>
Segwit2mb is a last resort option. It does not need to be released quickly.
Not at all. It just needs to be there in case no other option is chosen. I
put tentative dates. We can move them.
> - maybe the proposal should be renamed segwit 8mb and be discussed solely
> in terms of block weights.
>
The name does not matter much. The name means joining segwit with a 2Mb
hard-fork. It's a grammatical name.
I also disagree with the idea that segwit2mb is a 8mb increase. As stated
by in the Bitcon.org website [1] and backed up by scientific research, “a
block filled with standard single-signature P2PKH transactions would be
about 1.6MB and a block filled with 2-of-2 multisignature transactions
would be about 2.0MB.”. As standard blocks are a combination between P2PKH,
and 2-of-3 multisignatures, the actual average segwit block size will be
close to 2.0MB.
Because Segwit2Mb doubles the maximum size of a block, the average block
size for a block filed with average transactions is 4.0Mb.
[1] https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit-size
I can explain in a following e-mail why creating 8Mb blocks on purpose is
generally is an irrational choice. And in the case where it could provide
an economic benefit, adding parallel block validation to Core nullifies any
adversary advantage.
> a high consensus hard fork is probably preferable to a low consensus soft
fork, however there is nothing to indicate that segwit as it stands isnt
already very high consensus except for a handful of pool operators
protecting fee income.
You and me may never know the reasons why these operators (or many many of
other users) prefer to increase the block-size. I suppose it has to do high
the high current transaction fees as compared to less than a year ago.
Anyway consensus can only be achieved if one understands the others may
have reasons that do not match ours.
Last, if this proposal is rejected by any side, then we'll definitively
learn that side is not looking for any consensual resolution of the
conflict.
> - miners who currently object to segwit while pretending to like larger
> blocks will find some excuse to object to this too.
>
>
If they do, we'll get a lot of public, verifiable information from that
fact. The cost to include this patch is low compared with the benefit it
can bring and the information we can gather in case one of the sides
rejects it.
However, I've received positive feedback from them until now.
> - Given the challenges miners seem to have in flipping bits, I expect any
> fork that requires 95pct hash power to be vaporware.
>
Then we'll learn a lot about hard-forks, the limits of miner "voting" and
the quorums we can expect.
Regards,
Sergio.
>
> On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
>> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> The hard-fork is conditional to 95% of the hashing power has approved
>>> the segwit2mb soft-fork and the segwit soft-fork has been activated (which
>>> should occur 2016 blocks after its lock-in time)
>>>
>>
>> Miners signalling they have upgraded by flipping a bit in the nVersion
>> field has little relevance in a hard fork. If 100% of the hash power
>> indicates they are running this proposal, but the nodes don't upgrade, what
>> will happen?
>>
>> For the record, I actually talk a lot about hard forks with various
>> developers and am very interested in the research that Johnson in
>> particular is pioneering. However, I have failed to understand your point
>> about 95% miner signalling in relation to a hard fork, so I am eagerly
>> awaiting your explanation.
>>
>> _______________________________________________
>> 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/20170406/5c6c4314/attachment-0001.html>

2023-06-07 17:58:48

- reply

📅 Original date posted:2017-04-01
📝 Original message:Some people have asked me for the current implementation of this patch to
review. I remind you that the current patch does not implement the
hard-fork signaling, as requested by Matt.
The Segwit2Mb patch can be found here:
https://github.com/SergioDemianLerner/bitcoin/commits/master
For now, the segwit2mb repo has a single test file using the old internal
blockchain building method (test/block_size_tests.cpp). This must be
replaced soon with a better external test using the bitcoin/qa/rpc-tests
tests, which I will begin to work on now after I collect all comments from
the community.
regards
On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <jaredr26 at gmail.com>
wrote:
> > Remember that the "hashpower required to secure bitcoin" is determined
> > as a percentage of total Bitcoins transacted on-chain in each block
>
> Can you explain this statement a little better? What do you mean by
> that? What does the total bitcoins transacted have to do with
> hashpower required?
>
> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Hey Sergio,
> >
> > You appear to have ignored the last two years of Bitcoin hardfork
> > research and understanding, recycling instead BIP 102 from 2015. There
> > are many proposals which have pushed the state of hard fork research
> > much further since then, and you may wish to read some of the posts on
> > this mailing list listed at https://bitcoinhardforkresearch.github.io/
> > and make further edits based on what you learn. Your goal of "avoid
> > technical changes" appears to not have any basis outside of perceived
> > compromise for compromise sake, only making such a hardfork riskier
> > instead.
> >
> > At a minimum, in terms of pure technical changes, you should probably
> > consider (probably among others):
> >
> > a) Utilizing the "hard fork signaling bit" in the nVersion of the block.
> > b) Either limiting non-SegWit transactions in some way to fix the n**2
> > sighash and FindAndDelete runtime and memory usage issues or fix them by
> > utilizing the new sighash type which many wallets and projects have
> > already implemented for SegWit in the spending of non-SegWit outputs.
> > c) Your really should have replay protection in any HF. The clever fix
> from
> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
> > be spent with SegWit's sighash provides this all in one go.
> > d) You may wish to consider the possibility of tweaking the witness
> > discount and possibly discounting other parts of the input - SegWit went
> > a long ways towards making removal of elements from the UTXO set cheaper
> > than adding them, but didn't quite get there, you should probably finish
> > that job. This also provides additional tuneable parameters to allow you
> > to increase the block size while not having a blowup in the worst-case
> > block size.
> > e) Additional commitments at the top of the merkle root - both for
> > SegWit transactions and as additional space for merged mining and other
> > commitments which we may wish to add in the future, this should likely
> > be implemented an "additional header" ala Johnson Lau's Spoonnet
> proposal.
> >
> > Additionally, I think your parameters here pose very significant risk to
> > the Bitcoin ecosystem broadly.
> >
> > a) Activating a hard fork with less than 18/24 months (and even then...)
> > from a fully-audited and supported release of full node software to
> > activation date poses significant risks to many large software projects
> > and users. I've repeatedly received feedback from various folks that a
> > year or more is likely required in any hard fork to limit this risk, and
> > limited pushback on that given the large increase which SegWit provides
> > itself buying a ton of time.
> >
> > b) Having a significant discontinuity in block size increase only serves
> > to confuse and mislead users and businesses, forcing them to rapidly
> > adapt to a Bitcoin which changed overnight both by hardforking, and by
> > fees changing suddenly. Instead, having the hard fork activate technical
> > changes, and then slowly increasing the block size over the following
> > several years keeps things nice and continuous and also keeps us from
> > having to revisit ye old blocksize debate again six months after
> activation.
> >
> > c) You should likely consider the effect of the many technological
> > innovations coming down the pipe in the coming months. Technologies like
> > Lightning, TumbleBit, and even your own RootStock could significantly
> > reduce fee pressure as transactions move to much faster and more
> > featureful systems.
> >
> > Commitments to aggressive hard fork parameters now may leave miners
> > without much revenue as far out as the next halving (which current
> > transaction growth trends are indicating we'd just only barely reach 2MB
> > of transaction volume, let alone if you consider the effects of users
> > moving to systems which provide more features for Bitcoin transactions).
> > This could lead to a precipitous drop in hashrate as miners are no
> > longer sufficiently compensated.
> >
> > Remember that the "hashpower required to secure bitcoin" is determined
> > as a percentage of total Bitcoins transacted on-chain in each block, so
> > as subsidy goes down, miners need to be paid with fees, not just price
> > increases. Even if we were OK with hashpower going down compared to the
> > value it is securing, betting the security of Bitcoin on its price
> > rising exponentially to match decreasing subsidy does not strike me as a
> > particularly inspiring tradeoff.
> >
> > There aren't many great technical solutions to some of these issues, as
> > far as I'm aware, but it's something that needs to be incredibly
> > carefully considered before betting the continued security of Bitcoin on
> > exponential on-chain growth, something which we have historically never
> > seen.
> >
> > Matt
> >
> >
> > On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>Hi everyone,
> >>
> >>Segwit2Mb is the project to merge into Bitcoin a minimal patch that
> >>aims to
> >>untangle the current conflict between different political positions
> >>regarding segwit activation vs. an increase of the on-chain blockchain
> >>space through a standard block size increase. It is not a new solution,
> >>but
> >>it should be seen more as a least common denominator.
> >>
> >>Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB
> >>block
> >>size hard-fork activated ONLY if segwit activates (95% of miners
> >>signaling), but at a fixed future date.
> >>
> >>The sole objective of this proposal is to re-unite the Bitcoin
> >>community
> >>and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
> >>possible technical solution to solve Bitcoin technical limitations.
> >>However, this proposal does not imply a compromise to the future
> >>scalability or decentralization of Bitcoin, as a small increase in
> >>block
> >>size has been proven by several core and non-core developers not to
> >>affect
> >>Bitcoin value propositions.
> >>
> >>In the worst case, a 2X block size increase has much lower economic
> >>impact
> >>than the last bitcoin halving (<10%), which succeeded without problem.
> >>
> >>On the other side, Segwit2Mb primary goal is to be minimalistic: in
> >>this
> >>patch some choices have been made to reduce the number of lines
> >>modified in
> >>the current Bitcoin Core state (master branch), instead of implementing
> >>the
> >>most elegant solution. This is because I want to reduce the time it
> >>takes
> >>for core programmers and reviewers to check the correctness of the
> >>code,
> >>and to report and correct bugs.
> >>
> >>The patch was built by forking the master branch of Bitcoin Core,
> >>mixing a
> >>few lines of code from Jeff Garzik's BIP102, and defining a second
> >>versionbits activation bit (bit 2) for the combined activation.
> >>
> >>The combined activation of segwit and 2Mb hard-fork nVersion bit is 2
> >>(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
> >>
> >>This means that segwit can still be activated without the 2MB hard-fork
> >>by
> >>signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT).
> >>
> >>The tentative lock-in and hard-fork dates are the following:
> >>
> >>Bit 2 signaling StartTime = 1493424000; // April 29th, 2017
> >>
> >>Bit 2 signaling Timeout = 1503964800; // August 29th, 2017
> >>
> >>HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
> >>
> >>
> >>The hard-fork is conditional to 95% of the hashing power has approved
> >>the
> >>segwit2mb soft-fork and the segwit soft-fork has been activated (which
> >>should occur 2016 blocks after its lock-in time)
> >>
> >>For more information on how soft-forks are signaled and activated, see
> >>https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
> >>
> >>This means that segwit would be activated before 2Mb: this is
> >>inevitable,
> >>as versionbits have been designed to have fixed activation periods and
> >>thresholds for all bits. Making segwit and 2Mb fork activate together
> >>at a
> >>delayed date would have required a major re-write of this code, which
> >>would
> >>contradict the premise of creating a minimalistic patch. However, once
> >>segwit is activated, the hard-fork is unavoidable.
> >>
> >>Although I have coded a first version of the segwit2mb patch (which
> >>modifies 120 lines of code, and adds 220 lines of testing code), I
> >>would
> >>prefer to wait to publish the source code until more comments have been
> >>received from the community.
> >>
> >>To prevent worsening block verification time because of the O(N^2)
> >>hashing
> >>problem, the simple restriction that transactions cannot be larger than
> >>1Mb
> >>has been kept. Therefore the worse-case of block verification time has
> >>only
> >>doubled.
> >>
> >>Regarding the hard-fork activation date, I want to give enough time to
> >>all
> >>active economic nodes to upgrade. As of Fri Mar 31 2017,
> >>https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%)
> >>have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can
> >>be
> >>used to identify economic active nodes, because in the 0.12 release
> >>dynamic
> >>fees were introduced, and currently no Bitcoin automatic payment system
> >>can
> >>operate without automatic discovery of the current fee rate. A pre-0.12
> >>would require constant manual intervention.
> >>Therefore I conclude that no more than 91% of the network nodes
> >>reported by
> >>bitnodes are active economic nodes.
> >>
> >>As Bitcoin Core 0.12 was released on February 2016, the time for this
> >>91%
> >>to upgrade has been around one year (under a moderate pressure of
> >>operational problems with unconfirmed transactions).
> >>Therefore we can expect a similar or lower time to upgrade for a
> >>hard-fork,
> >>after developers have discussed and approved the patch, and it has been
> >>reviewed and merged and 95% of the hashing power has signaled for it
> >>(the
> >>pressure not to upgrade being a complete halt of the operations).
> >>However I
> >>suggest that we discuss the hard-fork date and delay it if there is a
> >>real
> >>need to.
> >>
> >>Currently time works against the Bitcoin community, and so is delaying
> >>a
> >>compromise solution. Most of the community agree that halting the
> >>innovation for several years is a very bad option.
> >>
> >>After the comments collected by the community, a BIP will be written
> >>describing the resulting proposal details.
> >>
> >>If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should
> >>be
> >>updated to a Segwit2Mb enabled node to prevent them to be forked-away
> >>in a
> >>chain with almost no hashing-power.
> >>
> >>The proof of concept patch was made for Bitcoin Core but should be
> >>easily
> >>ported to other Bitcoin protocol implementations that already support
> >>versionbits. Lightweight (SPV) wallets should not be affected as they
> >>generally do not check the block size.
> >>
> >>I personally want to see the Lightning Network in action this year, use
> >>the
> >>non-malleability features in segwit, see the community discussing other
> >>exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains
> >>and
> >>MAST.
> >>
> >>I want to see miners, developers and industry side-by-side pushing
> >>Bitcoin
> >>forward, to increase the value of Bitcoin and prevent high transaction
> >>fees
> >>to put out of business use-cases that could have high positive social
> >>impact.
> >>
> >>I believe in the strength of a unified Bitcoin community. If you're a
> >>developer, please give your opinion, suggest changes, audit it, and
> >>take a
> >>stand with me to unlock the current Bitcoin deadlock.
> >>
> >>Contributions to the segwit2mb project are welcomed and awaited. The
> >>only
> >>limitation is to stick to the principle that the patch should be as
> >>simple
> >>to audit as possible. As an example, I wouldn't feel confident if the
> >>patch
> >>modified more than ~150 lines of code.
> >>
> >>Improvements unrelated to a 2 Mb increase or segwit, as beneficial as
> >>it
> >>may be to Bitcoin, should not be part of segwit2Mb.
> >>
> >>This proposal should not prevent other consensus proposals to be
> >>simultaneously merged: segwit2mb is a last resort solution in case we
> >>can
> >>not reach consensus on anything better.
> >>
> >>Again, the proposal is only a starting point: community feedback is
> >>expected and welcomed.
> >>
> >>Regards,
> >>Sergio Demian Lerner
> > _______________________________________________
> > 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/20170401/8b281935/attachment-0001.html>

2023-06-07 17:58:46

- reply

📅 Original date posted:2017-04-01
📝 Original message:Even if the proposal involves a political compromise, any change to the
code must be technically evaluated.
The patch was made to require the least possible time for auditing. I'm
talking about reviewing 120 lines of code (not counting comments or
space) which 30 of them are changes to constants. A core programmer audited
it in less than one hour.
Also you're risking the unique opportunity to see segwit activated for
what?
Maybe we can reach a similar agreement for segwit activation in two years.
That's will be too late. The remaining cryptocurrency ecosystem do move
forward.
On Sat, Apr 1, 2017 at 12:03 AM, Samson Mow <samson.mow at gmail.com> wrote:
> A compromise for the sake of compromise doesn't merit technical
> discussions. There are no benefits to be gained from a 2MB hard-fork at
> this time and it would impose an unnecessary cost to the ecosystem for
> testing and implementation.
>
> On Fri, Mar 31, 2017 at 3:13 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo <lf-lists at mattcorallo.com>
>> wrote:
>>
>>> Hey Sergio,
>>>
>>> You appear to have ignored the last two years of Bitcoin hardfork
>>> research and understanding, recycling instead BIP 102 from 2015. There
>>> are many proposals which have pushed the state of hard fork research
>>> much further since then, and you may wish to read some of the posts on
>>> this mailing list listed at https://bitcoinhardforkresearch.github.io/
>>> and make further edits based on what you learn.
>>
>>
>> I've read every proposal that was published in the last two years and the
>> choice for NOT implementing any of the super cool research you cite is
>> intentional.
>>
>> We're in a deadlock and it seems we can't go forward adding more
>> functionality to segwit without the community approval (which include
>> miners). This is obvious to me.Then we have to go back.
>>
>> If this last resort solution is merged, we could go back to discuss
>> improvements with the
>>
>> Your goal of "avoid
>>> technical changes" appears to not have any basis outside of perceived
>>> compromise for compromise sake, only making such a hardfork riskier
>>> instead.
>>>
>>> You're are totally correct. It's a compromise for the compromise sake. I
>> couldn't have expressed it more clearly. However the only "riskier" element
>> is the hard forking date. We can move the date forward.
>>
>>
>>> At a minimum, in terms of pure technical changes, you should probably
>>> consider (probably among others):
>>>
>> a) Utilizing the "hard fork signaling bit" in the nVersion of the block.
>>>
>>
>> This I could consider, as it requires probably a single line of code.
>> Which BIP specifies this?
>>
>>
>>> b) Either limiting non-SegWit transactions in some way to fix the n**2
>>> sighash and FindAndDelete runtime and memory usage issues or fix them by
>>> utilizing the new sighash type which many wallets and projects have
>>> already implemented for SegWit in the spending of non-SegWit outputs.
>>>
>>
>> The Seghash problem has already been addressed by limiting the maximum
>> size of a transaction to 1 Mb.
>> The FindAndDelete problem has already been solved by the Core Developers,
>> so we don't have to worry about it anymore.
>>
>>
>>> c) Your really should have replay protection in any HF.
>>
>>
>> We could add a simple protection, although if we reach community
>> consensus and 95% of hashing power, does we really need to? Can the old
>> chain still be alive?
>> If more people ask for replay protection, I will merge Spoonet scheme or
>> develop the minimum possible replay protection (a simple signaling bit in
>> transaction version)
>>
>>
>>> d) You may wish to consider the possibility of tweaking the witness
>>> discount and possibly discounting other parts of the input - SegWit went
>>> a long ways towards making removal of elements from the UTXO set cheaper
>>> than adding them, but didn't quite get there, you should probably finish
>>> that job. This also provides additional tuneable parameters to allow you
>>> to increase the block size while not having a blowup in the worst-case
>>> block size.
>>>
>>
>> That is an interesting economic change and would be out of the scope of
>> segwit2mb.
>>
>>
>>> e) Additional commitments at the top of the merkle root - both for
>>> SegWit transactions and as additional space for merged mining and other
>>> commitments which we may wish to add in the future, this should likely
>>> be implemented an "additional header" ala Johnson Lau's Spoonnet
>>> proposal.
>>>
>>> That is an interesting technical improvement that is out of the scope of
>> segwit2mb.
>> We can keep discussing spoonet while we merge segwit2mb, as spoonnet
>> includes most of technical innovations.
>>
>>
>>> Additionally, I think your parameters here pose very significant risk to
>>> the Bitcoin ecosystem broadly.
>>>
>>> a) Activating a hard fork with less than 18/24 months (and even then...)
>>> from a fully-audited and supported release of full node software to
>>> activation date poses significant risks to many large software projects
>>> and users. I've repeatedly received feedback from various folks that a
>>> year or more is likely required in any hard fork to limit this risk, and
>>> limited pushback on that given the large increase which SegWit provides
>>> itself buying a ton of time.
>>>
>>> The feedback I received is slightly different from your feedback. Many
>> company CTOs have expressed that one year for a Bitcoin hard-fork was
>> period they could schedule a secure upgrade.
>>
>>
>>
>>> b) Having a significant discontinuity in block size increase only serves
>>> to confuse and mislead users and businesses, forcing them to rapidly
>>> adapt to a Bitcoin which changed overnight both by hardforking, and by
>>> fees changing suddenly. Instead, having the hard fork activate technical
>>> changes, and then slowly increasing the block size over the following
>>> several years keeps things nice and continuous and also keeps us from
>>> having to revisit ye old blocksize debate again six months after
>>> activation.
>>>
>>> This is something worth considering. There is the old Pieter BIP103
>> proposal has good parameters (17.7% per year).
>>
>> c) You should likely consider the effect of the many technological
>>> innovations coming down the pipe in the coming months. Technologies like
>>> Lightning, TumbleBit, and even your own RootStock could significantly
>>> reduce fee pressure as transactions move to much faster and more
>>> featureful systems.
>>>
>>> RSK sidechain team would have to take very tough decisions if Bitcoin
>> splits, as RSK platform cannot be pegged to two different cryptocurrencies.
>> We could launch two platforms, but RSK value proposition is "supporting the
>> advance of Bitcoin, the cryptocurrecy with highest network effect". You
>> understand that if Bitcoin splits Bitcoin BTC/BTU separately may cease to
>> be the cryptocurrencies with higher volume/market cap/network effect.
>>
>> Therefore all RSK people that I talked too would prefer to avoid a split
>> at all cost, reather that to be the winners of the scaling war.
>>
>>
>>
>>> On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >Hi everyone,
>>> >
>>> >Segwit2Mb is the project to merge into Bitcoin a minimal patch that
>>> >aims to
>>> >untangle the current conflict between different political positions
>>> >regarding segwit activation vs. an increase of the on-chain blockchain
>>> >space through a standard block size increase. It is not a new solution,
>>> >but
>>> >it should be seen more as a least common denominator.
>>> >
>>> >Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB
>>> >block
>>> >size hard-fork activated ONLY if segwit activates (95% of miners
>>> >signaling), but at a fixed future date.
>>> >
>>> >The sole objective of this proposal is to re-unite the Bitcoin
>>> >community
>>> >and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
>>> >possible technical solution to solve Bitcoin technical limitations.
>>> >However, this proposal does not imply a compromise to the future
>>> >scalability or decentralization of Bitcoin, as a small increase in
>>> >block
>>> >size has been proven by several core and non-core developers not to
>>> >affect
>>> >Bitcoin value propositions.
>>> >
>>> >In the worst case, a 2X block size increase has much lower economic
>>> >impact
>>> >than the last bitcoin halving (<10%), which succeeded without problem.
>>> >
>>> >On the other side, Segwit2Mb primary goal is to be minimalistic: in
>>> >this
>>> >patch some choices have been made to reduce the number of lines
>>> >modified in
>>> >the current Bitcoin Core state (master branch), instead of implementing
>>> >the
>>> >most elegant solution. This is because I want to reduce the time it
>>> >takes
>>> >for core programmers and reviewers to check the correctness of the
>>> >code,
>>> >and to report and correct bugs.
>>> >
>>> >The patch was built by forking the master branch of Bitcoin Core,
>>> >mixing a
>>> >few lines of code from Jeff Garzik's BIP102, and defining a second
>>> >versionbits activation bit (bit 2) for the combined activation.
>>> >
>>> >The combined activation of segwit and 2Mb hard-fork nVersion bit is 2
>>> >(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
>>> >
>>> >This means that segwit can still be activated without the 2MB hard-fork
>>> >by
>>> >signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT).
>>> >
>>> >The tentative lock-in and hard-fork dates are the following:
>>> >
>>> >Bit 2 signaling StartTime = 1493424000; // April 29th, 2017
>>> >
>>> >Bit 2 signaling Timeout = 1503964800; // August 29th, 2017
>>> >
>>> >HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
>>> >
>>> >
>>> >The hard-fork is conditional to 95% of the hashing power has approved
>>> >the
>>> >segwit2mb soft-fork and the segwit soft-fork has been activated (which
>>> >should occur 2016 blocks after its lock-in time)
>>> >
>>> >For more information on how soft-forks are signaled and activated, see
>>> >https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
>>> >
>>> >This means that segwit would be activated before 2Mb: this is
>>> >inevitable,
>>> >as versionbits have been designed to have fixed activation periods and
>>> >thresholds for all bits. Making segwit and 2Mb fork activate together
>>> >at a
>>> >delayed date would have required a major re-write of this code, which
>>> >would
>>> >contradict the premise of creating a minimalistic patch. However, once
>>> >segwit is activated, the hard-fork is unavoidable.
>>> >
>>> >Although I have coded a first version of the segwit2mb patch (which
>>> >modifies 120 lines of code, and adds 220 lines of testing code), I
>>> >would
>>> >prefer to wait to publish the source code until more comments have been
>>> >received from the community.
>>> >
>>> >To prevent worsening block verification time because of the O(N^2)
>>> >hashing
>>> >problem, the simple restriction that transactions cannot be larger than
>>> >1Mb
>>> >has been kept. Therefore the worse-case of block verification time has
>>> >only
>>> >doubled.
>>> >
>>> >Regarding the hard-fork activation date, I want to give enough time to
>>> >all
>>> >active economic nodes to upgrade. As of Fri Mar 31 2017,
>>> >https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%)
>>> >have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can
>>> >be
>>> >used to identify economic active nodes, because in the 0.12 release
>>> >dynamic
>>> >fees were introduced, and currently no Bitcoin automatic payment system
>>> >can
>>> >operate without automatic discovery of the current fee rate. A pre-0.12
>>> >would require constant manual intervention.
>>> >Therefore I conclude that no more than 91% of the network nodes
>>> >reported by
>>> >bitnodes are active economic nodes.
>>> >
>>> >As Bitcoin Core 0.12 was released on February 2016, the time for this
>>> >91%
>>> >to upgrade has been around one year (under a moderate pressure of
>>> >operational problems with unconfirmed transactions).
>>> >Therefore we can expect a similar or lower time to upgrade for a
>>> >hard-fork,
>>> >after developers have discussed and approved the patch, and it has been
>>> >reviewed and merged and 95% of the hashing power has signaled for it
>>> >(the
>>> >pressure not to upgrade being a complete halt of the operations).
>>> >However I
>>> >suggest that we discuss the hard-fork date and delay it if there is a
>>> >real
>>> >need to.
>>> >
>>> >Currently time works against the Bitcoin community, and so is delaying
>>> >a
>>> >compromise solution. Most of the community agree that halting the
>>> >innovation for several years is a very bad option.
>>> >
>>> >After the comments collected by the community, a BIP will be written
>>> >describing the resulting proposal details.
>>> >
>>> >If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should
>>> >be
>>> >updated to a Segwit2Mb enabled node to prevent them to be forked-away
>>> >in a
>>> >chain with almost no hashing-power.
>>> >
>>> >The proof of concept patch was made for Bitcoin Core but should be
>>> >easily
>>> >ported to other Bitcoin protocol implementations that already support
>>> >versionbits. Lightweight (SPV) wallets should not be affected as they
>>> >generally do not check the block size.
>>> >
>>> >I personally want to see the Lightning Network in action this year, use
>>> >the
>>> >non-malleability features in segwit, see the community discussing other
>>> >exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains
>>> >and
>>> >MAST.
>>> >
>>> >I want to see miners, developers and industry side-by-side pushing
>>> >Bitcoin
>>> >forward, to increase the value of Bitcoin and prevent high transaction
>>> >fees
>>> >to put out of business use-cases that could have high positive social
>>> >impact.
>>> >
>>> >I believe in the strength of a unified Bitcoin community. If you're a
>>> >developer, please give your opinion, suggest changes, audit it, and
>>> >take a
>>> >stand with me to unlock the current Bitcoin deadlock.
>>> >
>>> >Contributions to the segwit2mb project are welcomed and awaited. The
>>> >only
>>> >limitation is to stick to the principle that the patch should be as
>>> >simple
>>> >to audit as possible. As an example, I wouldn't feel confident if the
>>> >patch
>>> >modified more than ~150 lines of code.
>>> >
>>> >Improvements unrelated to a 2 Mb increase or segwit, as beneficial as
>>> >it
>>> >may be to Bitcoin, should not be part of segwit2Mb.
>>> >
>>> >This proposal should not prevent other consensus proposals to be
>>> >simultaneously merged: segwit2mb is a last resort solution in case we
>>> >can
>>> >not reach consensus on anything better.
>>> >
>>> >Again, the proposal is only a starting point: community feedback is
>>> >expected and welcomed.
>>> >
>>> >Regards,
>>> >Sergio Demian Lerner
>>>
>>
>>
>> _______________________________________________
>> 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/20170401/68144b3e/attachment-0001.html>

2023-06-07 17:58:39

- reply

📅 Original date posted:2017-03-31
📝 Original message:On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> Hey Sergio,
>
> You appear to have ignored the last two years of Bitcoin hardfork
> research and understanding, recycling instead BIP 102 from 2015. There
> are many proposals which have pushed the state of hard fork research
> much further since then, and you may wish to read some of the posts on
> this mailing list listed at https://bitcoinhardforkresearch.github.io/
> and make further edits based on what you learn.
I've read every proposal that was published in the last two years and the
choice for NOT implementing any of the super cool research you cite is
intentional.
We're in a deadlock and it seems we can't go forward adding more
functionality to segwit without the community approval (which include
miners). This is obvious to me.Then we have to go back.
If this last resort solution is merged, we could go back to discuss
improvements with the
Your goal of "avoid
> technical changes" appears to not have any basis outside of perceived
> compromise for compromise sake, only making such a hardfork riskier
> instead.
>
> You're are totally correct. It's a compromise for the compromise sake. I
couldn't have expressed it more clearly. However the only "riskier" element
is the hard forking date. We can move the date forward.
> At a minimum, in terms of pure technical changes, you should probably
> consider (probably among others):
>
a) Utilizing the "hard fork signaling bit" in the nVersion of the block.
>
This I could consider, as it requires probably a single line of code. Which
BIP specifies this?
> b) Either limiting non-SegWit transactions in some way to fix the n**2
> sighash and FindAndDelete runtime and memory usage issues or fix them by
> utilizing the new sighash type which many wallets and projects have
> already implemented for SegWit in the spending of non-SegWit outputs.
>
The Seghash problem has already been addressed by limiting the maximum size
of a transaction to 1 Mb.
The FindAndDelete problem has already been solved by the Core Developers,
so we don't have to worry about it anymore.
> c) Your really should have replay protection in any HF.
We could add a simple protection, although if we reach community consensus
and 95% of hashing power, does we really need to? Can the old chain still
be alive?
If more people ask for replay protection, I will merge Spoonet scheme or
develop the minimum possible replay protection (a simple signaling bit in
transaction version)
> d) You may wish to consider the possibility of tweaking the witness
> discount and possibly discounting other parts of the input - SegWit went
> a long ways towards making removal of elements from the UTXO set cheaper
> than adding them, but didn't quite get there, you should probably finish
> that job. This also provides additional tuneable parameters to allow you
> to increase the block size while not having a blowup in the worst-case
> block size.
>
That is an interesting economic change and would be out of the scope of
segwit2mb.
> e) Additional commitments at the top of the merkle root - both for
> SegWit transactions and as additional space for merged mining and other
> commitments which we may wish to add in the future, this should likely
> be implemented an "additional header" ala Johnson Lau's Spoonnet proposal.
>
> That is an interesting technical improvement that is out of the scope of
segwit2mb.
We can keep discussing spoonet while we merge segwit2mb, as spoonnet
includes most of technical innovations.
> Additionally, I think your parameters here pose very significant risk to
> the Bitcoin ecosystem broadly.
>
> a) Activating a hard fork with less than 18/24 months (and even then...)
> from a fully-audited and supported release of full node software to
> activation date poses significant risks to many large software projects
> and users. I've repeatedly received feedback from various folks that a
> year or more is likely required in any hard fork to limit this risk, and
> limited pushback on that given the large increase which SegWit provides
> itself buying a ton of time.
>
> The feedback I received is slightly different from your feedback. Many
company CTOs have expressed that one year for a Bitcoin hard-fork was
period they could schedule a secure upgrade.
> b) Having a significant discontinuity in block size increase only serves
> to confuse and mislead users and businesses, forcing them to rapidly
> adapt to a Bitcoin which changed overnight both by hardforking, and by
> fees changing suddenly. Instead, having the hard fork activate technical
> changes, and then slowly increasing the block size over the following
> several years keeps things nice and continuous and also keeps us from
> having to revisit ye old blocksize debate again six months after
> activation.
>
> This is something worth considering. There is the old Pieter BIP103
proposal has good parameters (17.7% per year).
c) You should likely consider the effect of the many technological
> innovations coming down the pipe in the coming months. Technologies like
> Lightning, TumbleBit, and even your own RootStock could significantly
> reduce fee pressure as transactions move to much faster and more
> featureful systems.
>
> RSK sidechain team would have to take very tough decisions if Bitcoin
splits, as RSK platform cannot be pegged to two different cryptocurrencies.
We could launch two platforms, but RSK value proposition is "supporting the
advance of Bitcoin, the cryptocurrecy with highest network effect". You
understand that if Bitcoin splits Bitcoin BTC/BTU separately may cease to
be the cryptocurrencies with higher volume/market cap/network effect.
Therefore all RSK people that I talked too would prefer to avoid a split at
all cost, reather that to be the winners of the scaling war.
> On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >Hi everyone,
> >
> >Segwit2Mb is the project to merge into Bitcoin a minimal patch that
> >aims to
> >untangle the current conflict between different political positions
> >regarding segwit activation vs. an increase of the on-chain blockchain
> >space through a standard block size increase. It is not a new solution,
> >but
> >it should be seen more as a least common denominator.
> >
> >Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB
> >block
> >size hard-fork activated ONLY if segwit activates (95% of miners
> >signaling), but at a fixed future date.
> >
> >The sole objective of this proposal is to re-unite the Bitcoin
> >community
> >and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
> >possible technical solution to solve Bitcoin technical limitations.
> >However, this proposal does not imply a compromise to the future
> >scalability or decentralization of Bitcoin, as a small increase in
> >block
> >size has been proven by several core and non-core developers not to
> >affect
> >Bitcoin value propositions.
> >
> >In the worst case, a 2X block size increase has much lower economic
> >impact
> >than the last bitcoin halving (<10%), which succeeded without problem.
> >
> >On the other side, Segwit2Mb primary goal is to be minimalistic: in
> >this
> >patch some choices have been made to reduce the number of lines
> >modified in
> >the current Bitcoin Core state (master branch), instead of implementing
> >the
> >most elegant solution. This is because I want to reduce the time it
> >takes
> >for core programmers and reviewers to check the correctness of the
> >code,
> >and to report and correct bugs.
> >
> >The patch was built by forking the master branch of Bitcoin Core,
> >mixing a
> >few lines of code from Jeff Garzik's BIP102, and defining a second
> >versionbits activation bit (bit 2) for the combined activation.
> >
> >The combined activation of segwit and 2Mb hard-fork nVersion bit is 2
> >(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
> >
> >This means that segwit can still be activated without the 2MB hard-fork
> >by
> >signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT).
> >
> >The tentative lock-in and hard-fork dates are the following:
> >
> >Bit 2 signaling StartTime = 1493424000; // April 29th, 2017
> >
> >Bit 2 signaling Timeout = 1503964800; // August 29th, 2017
> >
> >HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
> >
> >
> >The hard-fork is conditional to 95% of the hashing power has approved
> >the
> >segwit2mb soft-fork and the segwit soft-fork has been activated (which
> >should occur 2016 blocks after its lock-in time)
> >
> >For more information on how soft-forks are signaled and activated, see
> >https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
> >
> >This means that segwit would be activated before 2Mb: this is
> >inevitable,
> >as versionbits have been designed to have fixed activation periods and
> >thresholds for all bits. Making segwit and 2Mb fork activate together
> >at a
> >delayed date would have required a major re-write of this code, which
> >would
> >contradict the premise of creating a minimalistic patch. However, once
> >segwit is activated, the hard-fork is unavoidable.
> >
> >Although I have coded a first version of the segwit2mb patch (which
> >modifies 120 lines of code, and adds 220 lines of testing code), I
> >would
> >prefer to wait to publish the source code until more comments have been
> >received from the community.
> >
> >To prevent worsening block verification time because of the O(N^2)
> >hashing
> >problem, the simple restriction that transactions cannot be larger than
> >1Mb
> >has been kept. Therefore the worse-case of block verification time has
> >only
> >doubled.
> >
> >Regarding the hard-fork activation date, I want to give enough time to
> >all
> >active economic nodes to upgrade. As of Fri Mar 31 2017,
> >https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%)
> >have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can
> >be
> >used to identify economic active nodes, because in the 0.12 release
> >dynamic
> >fees were introduced, and currently no Bitcoin automatic payment system
> >can
> >operate without automatic discovery of the current fee rate. A pre-0.12
> >would require constant manual intervention.
> >Therefore I conclude that no more than 91% of the network nodes
> >reported by
> >bitnodes are active economic nodes.
> >
> >As Bitcoin Core 0.12 was released on February 2016, the time for this
> >91%
> >to upgrade has been around one year (under a moderate pressure of
> >operational problems with unconfirmed transactions).
> >Therefore we can expect a similar or lower time to upgrade for a
> >hard-fork,
> >after developers have discussed and approved the patch, and it has been
> >reviewed and merged and 95% of the hashing power has signaled for it
> >(the
> >pressure not to upgrade being a complete halt of the operations).
> >However I
> >suggest that we discuss the hard-fork date and delay it if there is a
> >real
> >need to.
> >
> >Currently time works against the Bitcoin community, and so is delaying
> >a
> >compromise solution. Most of the community agree that halting the
> >innovation for several years is a very bad option.
> >
> >After the comments collected by the community, a BIP will be written
> >describing the resulting proposal details.
> >
> >If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should
> >be
> >updated to a Segwit2Mb enabled node to prevent them to be forked-away
> >in a
> >chain with almost no hashing-power.
> >
> >The proof of concept patch was made for Bitcoin Core but should be
> >easily
> >ported to other Bitcoin protocol implementations that already support
> >versionbits. Lightweight (SPV) wallets should not be affected as they
> >generally do not check the block size.
> >
> >I personally want to see the Lightning Network in action this year, use
> >the
> >non-malleability features in segwit, see the community discussing other
> >exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains
> >and
> >MAST.
> >
> >I want to see miners, developers and industry side-by-side pushing
> >Bitcoin
> >forward, to increase the value of Bitcoin and prevent high transaction
> >fees
> >to put out of business use-cases that could have high positive social
> >impact.
> >
> >I believe in the strength of a unified Bitcoin community. If you're a
> >developer, please give your opinion, suggest changes, audit it, and
> >take a
> >stand with me to unlock the current Bitcoin deadlock.
> >
> >Contributions to the segwit2mb project are welcomed and awaited. The
> >only
> >limitation is to stick to the principle that the patch should be as
> >simple
> >to audit as possible. As an example, I wouldn't feel confident if the
> >patch
> >modified more than ~150 lines of code.
> >
> >Improvements unrelated to a 2 Mb increase or segwit, as beneficial as
> >it
> >may be to Bitcoin, should not be part of segwit2Mb.
> >
> >This proposal should not prevent other consensus proposals to be
> >simultaneously merged: segwit2mb is a last resort solution in case we
> >can
> >not reach consensus on anything better.
> >
> >Again, the proposal is only a starting point: community feedback is
> >expected and welcomed.
> >
> >Regards,
> >Sergio Demian Lerner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/21fb6e3f/attachment-0001.html>

2023-06-07 17:58:38

- reply

📅 Original date posted:2017-03-31
📝 Original message:Praxelogy_guy,
Yes I understand that segwit2mb represents a "potential" 4Mb block size
increase.
But Segwit does not immediately lead to 2 Mb blocks, but can only achieve
close to a 2Mb increase if all Bitcoin wallets switch to segwit, which will
take a couple of years.
Therefore I don't expect transactions per block to quadruple from one day
to another.
On Fri, Mar 31, 2017 at 6:22 PM, praxeology_guy <
praxeology_guy at protonmail.com> wrote:
> Sergio Demian Lerner: Please confirm that you understand that:
>
> The current SegWit being proposed comes bundled with an effective 2MB
> block size increase.
>
> Are you proposing the remove this bundled policy change, and then have a
> different BIP that increases the block size? Not quite clear if you
> understand what the current proposal is.
>
> Cheers,
> Praxeology
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/f17d5dc2/attachment.html>

2023-06-07 17:58:36

- reply

📅 Original date posted:2017-03-31
📝 Original message:Hi everyone,
Segwit2Mb is the project to merge into Bitcoin a minimal patch that aims to
untangle the current conflict between different political positions
regarding segwit activation vs. an increase of the on-chain blockchain
space through a standard block size increase. It is not a new solution, but
it should be seen more as a least common denominator.
Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block
size hard-fork activated ONLY if segwit activates (95% of miners
signaling), but at a fixed future date.
The sole objective of this proposal is to re-unite the Bitcoin community
and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
possible technical solution to solve Bitcoin technical limitations.
However, this proposal does not imply a compromise to the future
scalability or decentralization of Bitcoin, as a small increase in block
size has been proven by several core and non-core developers not to affect
Bitcoin value propositions.
In the worst case, a 2X block size increase has much lower economic impact
than the last bitcoin halving (<10%), which succeeded without problem.
On the other side, Segwit2Mb primary goal is to be minimalistic: in this
patch some choices have been made to reduce the number of lines modified in
the current Bitcoin Core state (master branch), instead of implementing the
most elegant solution. This is because I want to reduce the time it takes
for core programmers and reviewers to check the correctness of the code,
and to report and correct bugs.
The patch was built by forking the master branch of Bitcoin Core, mixing a
few lines of code from Jeff Garzik's BIP102, and defining a second
versionbits activation bit (bit 2) for the combined activation.
The combined activation of segwit and 2Mb hard-fork nVersion bit is 2
(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
This means that segwit can still be activated without the 2MB hard-fork by
signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT).
The tentative lock-in and hard-fork dates are the following:
Bit 2 signaling StartTime = 1493424000; // April 29th, 2017
Bit 2 signaling Timeout = 1503964800; // August 29th, 2017
HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
The hard-fork is conditional to 95% of the hashing power has approved the
segwit2mb soft-fork and the segwit soft-fork has been activated (which
should occur 2016 blocks after its lock-in time)
For more information on how soft-forks are signaled and activated, see
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
This means that segwit would be activated before 2Mb: this is inevitable,
as versionbits have been designed to have fixed activation periods and
thresholds for all bits. Making segwit and 2Mb fork activate together at a
delayed date would have required a major re-write of this code, which would
contradict the premise of creating a minimalistic patch. However, once
segwit is activated, the hard-fork is unavoidable.
Although I have coded a first version of the segwit2mb patch (which
modifies 120 lines of code, and adds 220 lines of testing code), I would
prefer to wait to publish the source code until more comments have been
received from the community.
To prevent worsening block verification time because of the O(N^2) hashing
problem, the simple restriction that transactions cannot be larger than 1Mb
has been kept. Therefore the worse-case of block verification time has only
doubled.
Regarding the hard-fork activation date, I want to give enough time to all
active economic nodes to upgrade. As of Fri Mar 31 2017,
https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%)
have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can be
used to identify economic active nodes, because in the 0.12 release dynamic
fees were introduced, and currently no Bitcoin automatic payment system can
operate without automatic discovery of the current fee rate. A pre-0.12
would require constant manual intervention.
Therefore I conclude that no more than 91% of the network nodes reported by
bitnodes are active economic nodes.
As Bitcoin Core 0.12 was released on February 2016, the time for this 91%
to upgrade has been around one year (under a moderate pressure of
operational problems with unconfirmed transactions).
Therefore we can expect a similar or lower time to upgrade for a hard-fork,
after developers have discussed and approved the patch, and it has been
reviewed and merged and 95% of the hashing power has signaled for it (the
pressure not to upgrade being a complete halt of the operations). However I
suggest that we discuss the hard-fork date and delay it if there is a real
need to.
Currently time works against the Bitcoin community, and so is delaying a
compromise solution. Most of the community agree that halting the
innovation for several years is a very bad option.
After the comments collected by the community, a BIP will be written
describing the resulting proposal details.
If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should be
updated to a Segwit2Mb enabled node to prevent them to be forked-away in a
chain with almost no hashing-power.
The proof of concept patch was made for Bitcoin Core but should be easily
ported to other Bitcoin protocol implementations that already support
versionbits. Lightweight (SPV) wallets should not be affected as they
generally do not check the block size.
I personally want to see the Lightning Network in action this year, use the
non-malleability features in segwit, see the community discussing other
exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains and
MAST.
I want to see miners, developers and industry side-by-side pushing Bitcoin
forward, to increase the value of Bitcoin and prevent high transaction fees
to put out of business use-cases that could have high positive social
impact.
I believe in the strength of a unified Bitcoin community. If you're a
developer, please give your opinion, suggest changes, audit it, and take a
stand with me to unlock the current Bitcoin deadlock.
Contributions to the segwit2mb project are welcomed and awaited. The only
limitation is to stick to the principle that the patch should be as simple
to audit as possible. As an example, I wouldn't feel confident if the patch
modified more than ~150 lines of code.
Improvements unrelated to a 2 Mb increase or segwit, as beneficial as it
may be to Bitcoin, should not be part of segwit2Mb.
This proposal should not prevent other consensus proposals to be
simultaneously merged: segwit2mb is a last resort solution in case we can
not reach consensus on anything better.
Again, the proposal is only a starting point: community feedback is
expected and welcomed.
Regards,
Sergio Demian Lerner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/c55dafa8/attachment-0001.html>

2023-06-07 17:56:15

- reply

📅 Original date posted:2017-02-13
📝 Original message:On Mon, Feb 13, 2017 at 8:58 AM, John Hardy <john at seebitcoin.com> wrote:
> Hi Sergio,
>
>
> Thanks for your response, interesting work, very excited for RSK.
>
>
> I like the ephemeral payload, I suppose that aspect of my proposal could
> be described as ephemeral blockspace.
>
>
> I'm curious about the challenge phase, what incentive do nodes to have to
> check other nodes' responses?
>
The reward is split between all full nodes. Therefore each full node has an
incentive to check at least some other full nodes responses because there
is a competition for the full node reward. At the end, each full node
response will be checked by more than other node with high probability.
Also each full node does a small pre-deposit, that is consumed if the node
cheats.
Is any validation of responses mandatory, or does policing the system rely
> on altruism?
>
>
> As previously said, validation is not mandatory.
> I also wondered how time-based responses are enforced? What prevents a
> miner censoring challenge responses so they do not get included in a block
> 'in time' - if inclusion within a block is the mechanism used?
>
There is not many defenses against censorship but try to hide your identity
until the end of the protocol. But if somebody knows that your transactions
belong to you, then there is little defense. We just wait more than a
single block for the commitments, so several miners must collude in order
to censor a transaction.
>
> I saw your tweet on Lumino - sounds very promising. Would be keen to take
> a look at the paper if you're looking for any additional review at this
> stage.
>
I'm keeping it private against all my desire because I want it to be
reviewed before I publish it. Credibility is very easily lost.
The same idea (Ephemeral Data) has been used to design the Lumino Network.
>
> Regards,
>
>
> John Hardy
>
>
> ------------------------------
> *From:* Sergio Demian Lerner <sergio.d.lerner at gmail.com>
> *Sent:* Sunday, February 12, 2017 8:22 PM
> *To:* John Hardy; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method to
> trustlessly reward nodes for storing and verifying the blockchain
>
> Hi John,
> RSK platform (a Bitcoin sidechain) is already prepared to do something
> similar to this, although very efficiently. We set apart 1% of the block
> reward to automatically reward full nodes.
>
> We have two systems being evaluated: the first is based on PoUBS (Proof of
> Unique Blockchain Storage) which uses asymmetric-time operations to encode
> the blockchain based on each user public key such that decoding is fast,
> but encoding is slow. The second is more traditional proof of
> retrievability, but it requires some ASIC-resistance assumptions.
>
> In both cases, a special smart contract is being called at every block
> that creates periodic challenges. Every full node that wants to participate
> can submits a commitment to the Merkle hash root of a pseudo-random
> sequence of encoded blocks. Then the smart contract chooses random elements
> from the committed dataset, and each full node has a period to submit
> Merkle-proofs that such random elements belong to the commitment.
>
> To prevent blockchain bloat we designed a very cool new type of
> transaction payload: Ephemeral Payload. Ephemeral payload is a payload in a
> transaction that gets discarded after N blocks if no smart contract does
> reference it. If is does, it's solidified forever in the blockchain.
> Then there is a challenge phase where other full nodes can inform the
> smart contract if they find an error in the submitted responses. Then the
> smart contract ONLY evaluates the responses which have been questioned by
> users.
>
> This way the smart contract does very little computation (only when a user
> misbehaves) and the blockchain normally does not store any proof forever
> (only the ones created by misbehaving users).
>
> Because RSK/Rootstock has a very short block interval (10 seconds), all
> this happens very quickly and does not require much computation.
>
> Best regards,
> Sergio Lerner
> Chief Scientist RSK (aka Roostock)
>
>
> On Tue, Feb 7, 2017 at 8:27 AM, John Hardy via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Proof of Nodework (PoNW) is a way to reward individual nodes for keeping
>> a full copy of and verifying the blockchain.
>>
>> Hopefully they also do useful ‘traditional’ node activities too like
>> relay transactions and blocks, but there isn’t really any way I can think
>> of to trustlessly verify this also.
>>
>> PoNW would require a new separate area of block space, a nodeblock,
>> purely concerned with administering the system. A nodeblock is committed to
>> a block as with SegWit. A recent history of nodeblocks needs to be stored
>> by nodes, however the data eventually becomes obsolete and so does not need
>> to be retained forever.
>>
>> In order to prevent Sybil, a node must register an Bitcoin address by
>> submitting an addNode transaction - along with a security deposit to
>> prevent cheating.
>>
>> This transaction will be stored in the nodeblock. Once a node can see
>> that its addNode transaction has been added it can begin the PoNW process.
>> The node’s registered address will be hashed with the block header of the
>> block it wants to work on. This will determine exactly where within the
>> blockchain to begin the PoNW.
>>
>> The PoNW method could be as simple as creating a Merkle tree from the
>> randomly generated point on the blockchain, though a method that is
>> CPU/Memory heavy and less likely to be replaced by dedicated hardware like
>> ASICs would be better. This process could not begin until the most recent
>> block has been fully verified, and while being carried out should still
>> enable normal relay activities to proceed as normal, since it shouldn’t tie
>> up network at all. The data processed should also be mixed with data from
>> the latest block so that it cannot be computed in advance.
>>
>> A node can do as much PoNW for a block as it likes. Once finished it will
>> then create a nodeWorkComplete transaction for that block with its final
>> proof value, add how much ‘work’ it did - and create a couple of assertions
>> about what it processed (such as there were x number of pieces of data
>> matching a particular value during calculating). These assertions can be
>> accurate or inaccurate.
>>
>> The system will run in epochs. During each epoch of say 2016 blocks,
>> there will be an extended window for PoNW transactions to be added to
>> nodeblocks to limit minor censorship.
>>
>> The random hash generated from a node’s address and blockhash will also
>> be used to determine nodeWorkComplete transactions from a previous block
>> that the node must also verify, and correctly calculate whether the
>> assertions it made were true or false. The average PoNW that a node
>> performed in its previous x nodeblocks will be used to determine the target
>> PoNW for the node to verify - and this will randomly be a large number of
>> smaller PoNW transactions, or a smaller number of large PoNW. This process
>> will be deterministic based on that block and address hash. All the data
>> will be put together in a transaction and then signed by the node addresses
>> private key.
>>
>> If a nodeWorkComplete transaction contains any incorrect information in
>> an attempt to cheat the validation process a challenge transaction can be
>> created. This begins a refereeing process where other nodes check the
>> challenge and vote whether it is to be upheld or not. The losing node is
>> punished by losing their accrued PoNW for that epoch and a percentage of
>> their security deposit.
>>
>> Nodes will also be punished if they broadcast more than one signed
>> transaction per block.
>>
>> In order to prevent nodes from having multiple keys registered - which
>> would enable them choose to perform PoNW on a subset of the data that they
>> hold - the share of reward that the node gets will be multiplied based on
>> the number of blocks within an epoch that the node performs PoNW on. The
>> share of reward is limited based on how much security deposit has been
>> staked. The higher the PoNW the higher the deposit needed in order to claim
>> their full allocation of any reward.
>>
>> At the end of an epoch, with a wait period for any delayed or censored
>> transactions or challenges to be included and settled up, the process of
>> calculating the reward each node is due can begin. This will then be then
>> paid in a regular block, and means for all the data involved in PoNW, the
>> only permanent mark it makes on the main blockchain is for a transaction
>> that pays all addresses their share of the reward at the end of epoch. Any
>> miner who creates a block without correctly calculating and paying the due
>> reward will have mined an invalid block and be orphaned.
>>
>> The question of where and how much the reward comes from is a different
>> one. It could come from the existing miner reward, or a special new tx
>> donation fee for nodes. If there was some way for users to ‘donate’ to the
>> reward pool for nodes this would increase the incentive for additional
>> nodes to participate on the network in the event of centralisation.
>>
>> This is a relatively effective way to create a reward for all nodes
>> participating on a network. I’d be keen to field any questions or critiques.
>>
>> Thanks,
>>
>>
>> John Hardy
>>
>> john at seebitcoin.com
>>
>> _______________________________________________
>> 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/20170213/2d644e4a/attachment-0001.html>

2023-06-07 17:56:14

- reply

📅 Original date posted:2017-02-12
📝 Original message:Hi John,
RSK platform (a Bitcoin sidechain) is already prepared to do something
similar to this, although very efficiently. We set apart 1% of the block
reward to automatically reward full nodes.
We have two systems being evaluated: the first is based on PoUBS (Proof of
Unique Blockchain Storage) which uses asymmetric-time operations to encode
the blockchain based on each user public key such that decoding is fast,
but encoding is slow. The second is more traditional proof of
retrievability, but it requires some ASIC-resistance assumptions.
In both cases, a special smart contract is being called at every block that
creates periodic challenges. Every full node that wants to participate can
submits a commitment to the Merkle hash root of a pseudo-random sequence of
encoded blocks. Then the smart contract chooses random elements from the
committed dataset, and each full node has a period to submit Merkle-proofs
that such random elements belong to the commitment.
To prevent blockchain bloat we designed a very cool new type of transaction
payload: Ephemeral Payload. Ephemeral payload is a payload in a transaction
that gets discarded after N blocks if no smart contract does reference it.
If is does, it's solidified forever in the blockchain.
Then there is a challenge phase where other full nodes can inform the smart
contract if they find an error in the submitted responses. Then the smart
contract ONLY evaluates the responses which have been questioned by users.
This way the smart contract does very little computation (only when a user
misbehaves) and the blockchain normally does not store any proof forever
(only the ones created by misbehaving users).
Because RSK/Rootstock has a very short block interval (10 seconds), all
this happens very quickly and does not require much computation.
Best regards,
Sergio Lerner
Chief Scientist RSK (aka Roostock)
On Tue, Feb 7, 2017 at 8:27 AM, John Hardy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Proof of Nodework (PoNW) is a way to reward individual nodes for keeping a
> full copy of and verifying the blockchain.
>
> Hopefully they also do useful ‘traditional’ node activities too like relay
> transactions and blocks, but there isn’t really any way I can think of to
> trustlessly verify this also.
>
> PoNW would require a new separate area of block space, a nodeblock, purely
> concerned with administering the system. A nodeblock is committed to a
> block as with SegWit. A recent history of nodeblocks needs to be stored by
> nodes, however the data eventually becomes obsolete and so does not need to
> be retained forever.
>
> In order to prevent Sybil, a node must register an Bitcoin address by
> submitting an addNode transaction - along with a security deposit to
> prevent cheating.
>
> This transaction will be stored in the nodeblock. Once a node can see that
> its addNode transaction has been added it can begin the PoNW process. The
> node’s registered address will be hashed with the block header of the block
> it wants to work on. This will determine exactly where within the
> blockchain to begin the PoNW.
>
> The PoNW method could be as simple as creating a Merkle tree from the
> randomly generated point on the blockchain, though a method that is
> CPU/Memory heavy and less likely to be replaced by dedicated hardware like
> ASICs would be better. This process could not begin until the most recent
> block has been fully verified, and while being carried out should still
> enable normal relay activities to proceed as normal, since it shouldn’t tie
> up network at all. The data processed should also be mixed with data from
> the latest block so that it cannot be computed in advance.
>
> A node can do as much PoNW for a block as it likes. Once finished it will
> then create a nodeWorkComplete transaction for that block with its final
> proof value, add how much ‘work’ it did - and create a couple of assertions
> about what it processed (such as there were x number of pieces of data
> matching a particular value during calculating). These assertions can be
> accurate or inaccurate.
>
> The system will run in epochs. During each epoch of say 2016 blocks, there
> will be an extended window for PoNW transactions to be added to nodeblocks
> to limit minor censorship.
>
> The random hash generated from a node’s address and blockhash will also be
> used to determine nodeWorkComplete transactions from a previous block that
> the node must also verify, and correctly calculate whether the assertions
> it made were true or false. The average PoNW that a node performed in its
> previous x nodeblocks will be used to determine the target PoNW for the
> node to verify - and this will randomly be a large number of smaller PoNW
> transactions, or a smaller number of large PoNW. This process will be
> deterministic based on that block and address hash. All the data will be
> put together in a transaction and then signed by the node addresses private
> key.
>
> If a nodeWorkComplete transaction contains any incorrect information in an
> attempt to cheat the validation process a challenge transaction can be
> created. This begins a refereeing process where other nodes check the
> challenge and vote whether it is to be upheld or not. The losing node is
> punished by losing their accrued PoNW for that epoch and a percentage of
> their security deposit.
>
> Nodes will also be punished if they broadcast more than one signed
> transaction per block.
>
> In order to prevent nodes from having multiple keys registered - which
> would enable them choose to perform PoNW on a subset of the data that they
> hold - the share of reward that the node gets will be multiplied based on
> the number of blocks within an epoch that the node performs PoNW on. The
> share of reward is limited based on how much security deposit has been
> staked. The higher the PoNW the higher the deposit needed in order to claim
> their full allocation of any reward.
>
> At the end of an epoch, with a wait period for any delayed or censored
> transactions or challenges to be included and settled up, the process of
> calculating the reward each node is due can begin. This will then be then
> paid in a regular block, and means for all the data involved in PoNW, the
> only permanent mark it makes on the main blockchain is for a transaction
> that pays all addresses their share of the reward at the end of epoch. Any
> miner who creates a block without correctly calculating and paying the due
> reward will have mined an invalid block and be orphaned.
>
> The question of where and how much the reward comes from is a different
> one. It could come from the existing miner reward, or a special new tx
> donation fee for nodes. If there was some way for users to ‘donate’ to the
> reward pool for nodes this would increase the incentive for additional
> nodes to participate on the network in the event of centralisation.
>
> This is a relatively effective way to create a reward for all nodes
> participating on a network. I’d be keen to field any questions or critiques.
>
> Thanks,
>
>
> John Hardy
>
> john at seebitcoin.com
>
> _______________________________________________
> 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/20170212/71eb46b5/attachment.html>

2023-06-07 17:54:34

- reply

📅 Original date posted:2016-11-25
📝 Original message:On Fri, Nov 25, 2016 at 12:25 PM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via
> bitcoin-
> dev wrote:
> > Without a detailed analysis, unlimited block size seems a risky change to
> > Bitcoin, to me.
>
> What exactly do you think is a ‘change’ in bitcoin here?
>
> A change is anything that modifies with a HF the current state of the
Bitcoin Core implementation of the consensus protocol. Sadly (or happily,
for some) there is no "abstract" definition of Bitcoin.
> The concept of proof-of-work is that the longer a chain, the higher
> probability that that one will be extended for the simple reason that
> another chain will have to show a higher amount of proof of work to ‘win’.
>
> We know what Bitcoin the protocol dictates, but if what the protocol
dictates is not in the best interest of miners or full-nodes? then they
will simply choose a rule that maximizes their revenue (or any other
measure of performance, such as lower latency, or less transaction reversal
probability).
As far as I understand the document from Peter, there is no change there at
> all. Only chains with more POW will win.
>
I haven't gone to the code to check, but the video Peter sent does not say
that. It says that miners will mine on top of a block ONLY if the "gate"
has been opened for that block (e.g. there is additional blocks to push a
big block). So a miner having a preferring low block sizes will choose to
mine on top of the A1,A2,A3 chain (3 units of work), while miners
supporting bigger sizes will mine on top of the chain B1,S2,S3,S4 (4 units
of work).
Saying that the chain starting with B1 is not considered by a node X does
not mean that the node X is blind to the information that can be extracted
from the fact that there is a chain of 4 blocks starting from B1.
If there is more information, there may be a better local choice. If there
are better local choices, there is probably a better global equilibrium (or
not equilibrium at all).
> Or, to answer your example, miners will prefer to extend the chain with the
> most POW.
>
Clearly this is not universal: some miners will, and some other miners
won't, because some miners have postponed adding some blocks.
>
> The other fact stays the same as well, if you protect from reorgs by
> expecting more confirmations. Nothing changes here either. The
> common-sense 6
> confirmations for things like exchange-deposits keep having the same
> security.
>
Suppose that I provide a service that accepts payments with 2
confirmations, and in certain time I have the information that the network
is at the same time considering the forks B1 S2 and A1 A2. Then the best I
can do is NOT to accept the 2-confirmation and wait for a resolution of the
fork. Choosing either fork may put me at the risk of immediate reversal.
The existence of fork information changes equilibrium decision to choose
the longest-chain. This is the same that happens with the GHOST protocol:
the information on the existence of uncles changes the local incentives to
choose the longest chain to some different strategy, and when all nodes
change their strategy, then the supposedly last equilibrium state is that
all follow the GHOST strategy for choosing the heaviest chain.
>
> The basic idea that we have a 3 or 4 deep fork is a huge problem in
> Bitcoin.
> It hasn’t happened for ages, and we like it that way. The miners like it
> that way too. Its disruptive.
> The is a problem that is not created by the ‘excessive block’ concept. It
> does, however, provide a possible solution to this very far-fetched
> problem.
>
> You should also realize that the policy of a miner is stored in the
> coinbase.
>
> This is important, but yet the full node does not use this information
automatically. The amount of confirmations that a node accepts is not
affected by the miner's policies or the size of the blocks mined, but it
should.
> That said, I’m sure there are improvements to be made to the policy that BU
> uses.
Probably a simple wise addition would be to estimate the accepted block
size for the majority of the miners (S), and only count block confirmations
for wallet transactions taking into account only blocks whose size is lower
or equal than S. So for example, if Alice receives a transaction T in block
B1 and it is confirmed by block B2, but size(B1)>S and size(B2)>S, then the
wallet should tell Alice that transaction T has 0 confirmations. This local
strategy reduces the chances that Alice accept T but is then easily
reversed for the opposite fork growing one block ahead.
Regards,
Sergio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161125/677ee30f/attachment-0001.html>

2023-06-07 17:54:34

- reply

📅 Original date posted:2016-11-25
📝 Original message:I now think my reasoning and conclusions are based on a false premise: that
BU block size policies for miners can be heterogeneous.
There can't be short forks because forks are not in the best interest of
the honest miner majority. All miners need to announce and follow the same
block size policy to prevent short forks.
The incentives are established so that all block size negotiations will be
carried between miners in a off-chain manner, not by modifying the policy
nor by announcing anything in the coinbase,
If block size negotiations are meant to be open and carried on on-chain,
then it's much better to let miners increase or decrease the block size
limit by 1% per block (such as what Ethereum does with the gas limit).
On Fri, Nov 25, 2016 at 7:31 PM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
>
>
> On Fri, Nov 25, 2016 at 12:25 PM, Tom Zander via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via
>> bitcoin-
>> dev wrote:
>> > Without a detailed analysis, unlimited block size seems a risky change
>> to
>> > Bitcoin, to me.
>>
>> What exactly do you think is a ‘change’ in bitcoin here?
>>
>> A change is anything that modifies with a HF the current state of the
> Bitcoin Core implementation of the consensus protocol. Sadly (or happily,
> for some) there is no "abstract" definition of Bitcoin.
>
>
>
>> The concept of proof-of-work is that the longer a chain, the higher
>> probability that that one will be extended for the simple reason that
>> another chain will have to show a higher amount of proof of work to ‘win’.
>>
>> We know what Bitcoin the protocol dictates, but if what the protocol
> dictates is not in the best interest of miners or full-nodes? then they
> will simply choose a rule that maximizes their revenue (or any other
> measure of performance, such as lower latency, or less transaction reversal
> probability).
>
>
> As far as I understand the document from Peter, there is no change there at
>> all. Only chains with more POW will win.
>>
>
> I haven't gone to the code to check, but the video Peter sent does not say
> that. It says that miners will mine on top of a block ONLY if the "gate"
> has been opened for that block (e.g. there is additional blocks to push a
> big block). So a miner having a preferring low block sizes will choose to
> mine on top of the A1,A2,A3 chain (3 units of work), while miners
> supporting bigger sizes will mine on top of the chain B1,S2,S3,S4 (4 units
> of work).
>
> Saying that the chain starting with B1 is not considered by a node X does
> not mean that the node X is blind to the information that can be extracted
> from the fact that there is a chain of 4 blocks starting from B1.
> If there is more information, there may be a better local choice. If there
> are better local choices, there is probably a better global equilibrium (or
> not equilibrium at all).
>
>
>> Or, to answer your example, miners will prefer to extend the chain with
>> the
>> most POW.
>>
>
> Clearly this is not universal: some miners will, and some other miners
> won't, because some miners have postponed adding some blocks.
>
>
>
>>
>> The other fact stays the same as well, if you protect from reorgs by
>> expecting more confirmations. Nothing changes here either. The
>> common-sense 6
>> confirmations for things like exchange-deposits keep having the same
>> security.
>>
>
> Suppose that I provide a service that accepts payments with 2
> confirmations, and in certain time I have the information that the network
> is at the same time considering the forks B1 S2 and A1 A2. Then the best I
> can do is NOT to accept the 2-confirmation and wait for a resolution of the
> fork. Choosing either fork may put me at the risk of immediate reversal.
>
> The existence of fork information changes equilibrium decision to choose
> the longest-chain. This is the same that happens with the GHOST protocol:
> the information on the existence of uncles changes the local incentives to
> choose the longest chain to some different strategy, and when all nodes
> change their strategy, then the supposedly last equilibrium state is that
> all follow the GHOST strategy for choosing the heaviest chain.
>
>
>>
>> The basic idea that we have a 3 or 4 deep fork is a huge problem in
>> Bitcoin.
>> It hasn’t happened for ages, and we like it that way. The miners like it
>> that way too. Its disruptive.
>> The is a problem that is not created by the ‘excessive block’ concept. It
>> does, however, provide a possible solution to this very far-fetched
>> problem.
>>
>> You should also realize that the policy of a miner is stored in the
>> coinbase.
>>
>> This is important, but yet the full node does not use this information
> automatically. The amount of confirmations that a node accepts is not
> affected by the miner's policies or the size of the blocks mined, but it
> should.
>
>
>> That said, I’m sure there are improvements to be made to the policy that
>> BU
>> uses.
>
>
> Probably a simple wise addition would be to estimate the accepted block
> size for the majority of the miners (S), and only count block confirmations
> for wallet transactions taking into account only blocks whose size is lower
> or equal than S. So for example, if Alice receives a transaction T in block
> B1 and it is confirmed by block B2, but size(B1)>S and size(B2)>S, then the
> wallet should tell Alice that transaction T has 0 confirmations. This local
> strategy reduces the chances that Alice accept T but is then easily
> reversed for the opposite fork growing one block ahead.
>
> Regards,
> Sergio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161125/f5679767/attachment-0001.html>

2023-06-07 17:54:33

- reply

📅 Original date posted:2016-11-24
📝 Original message:Hi Peter,
How would a person or exchange decide to accept a payment in BU if it does
not know the gate policy of 51% of the miners?
Suppose that the exchange receives B1,S2,S3,S4 (a big block at height 1,
and 3 small blocks at height 2, 3 and 4), and an alternate chain A1,A2,A3
(three small blocks). The first is the longest, but the second may be the
one 51% of the miners will extend.
Without knowing the policy of at least 51% of the miners (the maximum
acceptance depth) it's unclear if the exchange has to obey the longest
chain or the chain with higher probability of being extended.
If the maximum acceptance depth of the majority of miners is higher than 6
blocks, accepting a transaction with 6 confirmations is risky.
So BU would set a lower bound on the number of confirmations equal to the
maximum acceptance depth of the majority of miners.But miners do not
publish their acceptance depth, so basically users are clue-less. I think
miners should at least advertise their gate block size and acceptance depth
in their coinbase field.
Is there a game-theoretic analysis of confirmation blocks and their
probabilities in BU ?
Without a detailed analysis, unlimited block size seems a risky change to
Bitcoin, to me.
Regards, Sergio.
On Tue, Nov 22, 2016 at 1:31 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Dear all,
>
> Bitcoin Unlimited’s market-based solution to the block-size limit is
> slowly winning support from node operators and miners. With this increased
> attention, many people are asking for a better explanation of how Bitcoin
> Unlimited actually works. The article linked below describes how Bitcoin
> Unlimited’s excessive-block logic works from the perspective of a single
> node. (I’m hoping to do a follow-up article that describe how this
> “node-scale” behavior facilitates the emergence of a fluid and organic
> block size limit at the network scale.)
>
> https://medium.com/@peter_r/the-excessive-block-gate-how-
> a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4
>
> Best regards,
> Peter R
>
> _______________________________________________
> 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/20161124/7c1166cd/attachment.html>

2023-06-07 17:53:55

- reply

📅 Original date posted:2016-10-14
📝 Original message:Oh God... here we go again..
>
> Again, lets remember that you personally proposed a BIP[1] that had the
> effect
> of aiding your ASICBOOST patent[2] without disclosing that fact in your
> BIP nor
> your pull-req[3].
>
> This is false. The first sentence of the BIP states: "There are incentives
for miners to find cheap, non-standard ways to generate new work which are
not in the best interest of the protocol".
The BIP actually PROTECTS the network from stealth Shared-Nonce mining and
the fact you rejected it made the Bitcoin network LESS secure because now
we just don't know at what extent it is in use.
Shared-nonce mining can be done with or without that BIP/pull-req.
We didn't disclose more in the BIP because it was not clear if shared-nonce
mining (the fact that Bitcoin had a design flaw) would have a negative
affect on Bitcoin price.
ASICBoost patent may be a patent that protects Bitcoiners from mining
centralization: ASICBoost is the only company that at this point showed
interest in licensing the technology. But I do not control ASICBoost nor
the patent so I cannot do anything about it.
I propose we as a community do a crowdfund to try to license it from that
company (or any other that wants to put theirs in the deal) and put all in
public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161014/e46d79fe/attachment.html>

2023-06-07 17:53:54

- reply

📅 Original date posted:2016-10-14
📝 Original message:I read the DPL v1.1 and I find it dangerous for Bitcoin users. Current
users may be confident they are protected but in fact they are not, as the
future generations of users can be attacked, making Bitcoin technology
fully proprietary and less valuable.
If you read the DPL v1.1 you will see that companies that join DPL can
enforce their patents against anyone who has chosen not to join the DPL.
(http://defensivepatentlicense.org/content/defensive-patent-license)
So basically most users of Bitcoin could be currently under threat of being
sued by Bitcoin companies and individuals that joined DPL in the same way
they might be under threat by the remaining companies. And even if they
joined DPL, they may be asked to pay royalties for the use of the
inventions prior joining DPL.
DPL changes nothing for most individuals that cannot and will not hire
patent attorneys to advise them on what the DPL benefits are and what
rights they are resigning. Remember that patten attorneys fees may be
prohibitive for individuals in under-developed countries.
Also DPL is revocable by the signers (with only a 180-day notice), so if
Bitcoin Core ends up using ANY DPL covered patent, the company owning the
patent can later force all new Bitcoin users to pay royalties.
Because Bitcoin user base grows all the time with new individuals, the sole
existence of DPL licensed patents in Bitcoin represents a danger to Bitcoin
future almost the same as the existence of non-DPL license patents.
If you're publishing all your ideas and code (public disclosure), you
cannot later go and file a patent in most of the world except the US, where
you have a 1 year grace period. So we need to do something specific to
prevent the publishers filing a US patent.
What we need much more than DPL, we need that every BIP and proposal to the
Bitcoin mailing list contains a note that grants all Bitcoin users a
worldwide, royalty-free, no-charge, non-exclusive, irrevocable license for
the content of the e-mail or BIP.
I'm not a lawyer and this is not an advise of any kind. Please check
yourself the DPL v1.1 and get your own idea. I'm speaking on behalf of
myself, and not any company.
(http://defensivepatentlicense.org/content/defensive-patent-license)
Best regards,
Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161014/095eb988/attachment.html>

2023-06-07 17:53:48

- reply

📅 Original date posted:2016-10-02
📝 Original message:One side benefit of OP_COUNT_ACKS is that it enables a completely different
use case:
It allow users to pay for any service miners can provide as group for the
common good (e.g. fee payment smoothing over many blocks). For instance,
users could pay miners to jointly buy better Internet service to improve
bandwidth or reduce latency between them.
By sending bitcoins to a script containing OP_COUNT_ACKS requiring 51% of
miners approval and adding a special text tag to such outputs such as
"FOR-MINERS-TO-BUY-X", users can send bitcoins to miners and ask the
majority of them to vote on the proposal, if accepted create a transaction
to redeem those funds. This could help to address the so-called tragedy of
the commons problem that Bitcoin may face in in long-term, by users
crowdfunding mining of the following n blocks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/bbc97441/attachment.html>

2023-06-07 17:53:47

- reply

📅 Original date posted:2016-10-02
📝 Original message:It's good you bring that point, and it's very interesting to analyze what
happened then.
We shared our findings with some core developers much earlier than the BIP
proposal. Wether they kept it secret or they shared it with some ASIC
manufacturers is something I don't know. I even mentioned my wishes to try
to give the patent to public domain.
I remember the reason we proposed the BIP is because ASICBoost actually
does NOT require that BIP at all. And that BIP was not a consensus change,
but just a semantic re-interpretation.
ASICBoost can roll the nVersion field or the Merkle root hash. Doing the
former currently generates a strange warning message on nodes and can be
confusing, but doing the later makes ASICBoost completely stealthy. That
BIP could help the community to monitor its use in non-confusing way to the
users. What is worse? I think forcing it to be stealthy is worse.
I never opposed changing Bitcoin to be more decentralized, but hard-forking
a change to the PoW function may be contentious and that path of thought
must be walked very carefully.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/3104f53a/attachment.html>

2023-06-07 17:53:46

- reply

📅 Original date posted:2016-10-02
📝 Original message:Please Peter Todd explain here all what you want to say about a patent of a
hardware design for an ASIC.
Remember that ASICBoost is not the only patent out there, there are at
least three similar patents, filed by major Bitcoin ASIC manufacturers in
three different countries, on similar technologies.
That suggest that the problem is not ASICBoot's: you cannot blame any
company from doing lawful commerce in a FREE MARKET.
It is a flaw in Bitcoin design that could be corrected if the guidelines I
posted in [1] had been followed.
[1]
https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/9364fb1b/attachment-0001.html>

2023-06-07 17:53:44

- reply

📅 Original date posted:2016-10-25
📝 Original message:Responding between lines...
On Mon, Oct 24, 2016 at 2:37 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
> Some comments and questions
>
> 1. In the BIP you mentioned scriptSig 3 times, but I don't think you are
> really talking about scriptSig. Especially, segwit has aborted the use of
> scriptSig to fix malleability. From the context I guess you mean
> redeemScript (see BIP141)
>
You're right.I will change the naming asap.
>
> 2. It seems that 51% of miners may steal all money from the peg, right?
> But I think this is unavoidable for all 2-way-peg proposals. To make it
> safer you still need notaries.
>
Correct, that's inherently a technical limitation. However, there can be
many deterrents from miners stealing money (legal contracts,
mutual-assured-destruction states). Aslo as you mention, you can combine
OP_COUNT_ACK with notary sigantures as AND/OR or a more complex acknowledge
weight distribution.
>
> 3. Instead of using a OP_NOPx, I suggest you using an unused code such as
> 0xba. OP_NOPx should be reserved for some simple "VERIFY"-type codes that
> does not write to the stack.
>
Ok. I'm not sure, but if everyone agrees to it, I will. Also Segwit
versioning allows to create new opcode multiplexing opcodes, so I was
thinking about adding an "opcode index" to a more generic OP_OPERATE. But
that prevents using all NOP space, but prevents easily counting
OP_ACK_COUNT for checksig block limit.
> 4. I don't think you should simply replace "(witversion == 0)" with
> "((witversion == 0) || (witversion == 1))". There are only 16 available
> versions. It'd be exhausted very soon if we use a version for every new
> opcode. As a testing prototype this is fine, but the actual softfork should
> not waste a witversion this way. We need a better way to coordinate the use
> of new witness version. BIP114 suggests an additional field in the witness
> to indicate the script version (https://github.com/bitcoin/
> bips/blob/master/bip-0114.mediawiki)
>
> Good. But currently that version is not enforced, so this BIP cannot make
use of it. I can use (witversion == 1) but add the BIP114 version field so
that the next BIP can make use of it.
> 5. It seems this is the first BIP in markdown format, not mediawiki (but
> this is allowed by BIP1)
>
> 6. The coinbase space is limited to 100 bytes and is already overloaded by
> many different purposes. I think any additional consensus critical message
> should go to a dummy scriptPubKey like the witness commitment. You may
> consider to have a new OP_RETURN output like BIP141, with different magic
> bytes. However, please don't make this output mandatory (cf. witness
> commitment output is optional if the block does not have witness tx)
>
> 6a. "..........due to lack of space to include the proper ack tag in a
> block": this shouldn't happen if you use a OP_RETURN output
>
> I'm not sure about this. The fact that the space for acknowledge and
proposal is short has been seen by other developers a benefit and not a
drawback. It prevent hundreds of sidechains to be offered, which might hurt
solo miners. 70 bytes allows for approximately 10 active polls.
> 7. "It can be the case that two different secondary blockchains specify
> the same transaction candidate, but **at least** one of them will clearly
> be unauthentic."
>
> thnks.
8. Question: is an ack-poll valid only for 1 transaction? When the
> transaction is confirmed, could full nodes prune the corresponding ack-poll
> data? (I think it has to be prunable after spending because ack-poll data
> is effectively UTXO data)
>
> Yes, there is no ack-poll data stored except for the coinbase field cache,
which periodically cleans itself by using a FIFO approach.
> 9. No matter how you design a softfork, "Zero risk of invalidating a
> block" couldn't be true for any softfork. For example, even if a miner does
> not include any txs with OP_COUNT_ACKS, he may still build on top of blocks
> with invalid OP_COUNT_ACKS operations.
>
> I'm not sure. I assumed that transactions redeeming a script using
OP_COUNT_ACKS would be non-standard, so the the problem you point out
would only happen if the block including the transaction would be mined
specifically for the purpose to defeat subsequent miners. A honest pre-fork
miner would never include a redeemScript that that verifies an
OP_COUNT_ACKS, since that transaction would never be received by the p2p
protocol (it could if the miner accepts non-standard txs by a different
channnel).
But I must check this in the BIP source code if OP_COUNT_ACKS is really
non-standard as I designed it to be.
(Thanks Jonhson Lau for taking the time to analyze the BIP.)
Sergio.
> ---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote ----
> > Since ScalingBitcoin is close, I think this is a good moment to publish
> our proposal on drivechains. This BIP proposed the drivechain we'd like to
> use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it
> implemented in Bitcoin. Until that happens, we're using a federated
> approach.
> > I'm sure that adding risk-less Bitcoin extensibility through
> sidechains/drivechains is what we all want, but it's of maximum importance
> to decide which technology will leads us there.
> > We hope this work can also be the base of all other new 2-way-pegged
> blockchains that can take Bitcoin the currency to new niches and test new
> use cases, but cannot yet be realized because of current
> limitations/protections.
> >
> > The full BIP plus a reference implementation can be found here:
> >
> > BIP (draft):
> > https://github.com/rootstock/bips/blob/master/BIP-R10.md
> >
> > Code & Test cases:
> > https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
> > (Note: Code is still unaudited)
> >
> > As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked
> opcode that counts acks and nacks tags in coinbase fields, and push the
> resulting totals in the script stack.
> >
> > The system was designed with the following properties in mind:
> >
> > 1. Interoperability with scripting system
> > 2. Zero risk of invalidating a block
> > 3. No additional computation during blockchain management and
> re-organization
> > 4. No change in Bitcoin security model
> > 5. Bounded computation of poll results
> > 6. Strong protection from DoS attacks
> > 7. Minimum block space consumption
> > 8. Zero risk of cross-secondary chain invalidation
> >
> > Please see the BIP draft for a more-detailed explanation on how we
> achieve these goals.
> >
> > I'll be in ScalingBitcoin in less than a week and I'll be available to
> discuss the design rationale, improvements, changes and ideas any of you
> may have.
> >
> > Truly yours,
> > Sergio Demian Lerner
> > Bitcoiner and RSK co-founder
> >
> > _______________________________________________
> > 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/20161025/c738134c/attachment.html>

2023-06-07 17:53:43

- reply

📅 Original date posted:2016-10-02
📝 Original message:I'm not a lawyer, and my knowledge on patents is limited. I guess RSK WILL
endorse DPL or will make the required actions to make sure the things
developed by RSK remain free and open. This was not a priority until now,
but coding was. For me, coding always is the priority.
I will discuss prioritizing this with the team. Remember it took several
years to BlockStream to decide for DPL and not just publish everything as
they were doing. I suppose the decision it was not a simple one, involving
lawyers advise and all. I guess DPL needs to actually patent the things in
order to open them later, and patenting has a very high cost.
Give us time to decide which open source strategy is the best and cheaper
for RSK. At this point I can assert that RSK has not filed any patent not
is planing to. This proposal is not encumbered by any patents, and
drivechains is actually not RSK's idea, but Paul Sztorc's.
On Sun, Oct 2, 2016 at 2:11 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sun, Oct 02, 2016 at 02:00:01PM -0300, Sergio Demian Lerner wrote:
> > Peter, are you really going to try to down vote a decent free and
> > open-source proposal that benefits all the Bitcoin community including
> > you and your future children because a personal attack to me without any
> > logic or basis?
>
> I've suggested a way that you can rectify this situation so we can
> continue to
> collaborate: Have Rootstock adopt a legally binding patent pledge/license.
> I'd
> suggest you do as Blockstream has done and at minimum adopt the Defensive
> Patent License (DPL); I personally will be doing so in the next week or
> two for
> my own consulting company (I'm discussing exactly how to do so with my
> lawyer
> right now).
>
> If Rootstock is not planning on getting any patents for offensive purposes,
> then there is no issue with doing so - the DPL in particular is designed
> in a
> minimally intrusive way.
>
> Please fix this issue so we can in fact continue to collaborate to improve
> Bitcoin.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/d3052c9d/attachment.html>

2023-06-07 17:53:43

- reply

📅 Original date posted:2016-10-02
📝 Original message:On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> But I would argue that in this scenario, the only way it
>> would become invalid is the equivalent of a double-spend... and therefore
>> it
>> may be acceptable in relation to this argument.
>>
>
> The values returned by OP_COUNT_ACKS vary in their exact value depending
> on which block this transaction ends up in. While the proposed use of this
> operation is somewhat less objectionable (although still objectionable to
> me), nothing stops users from using OP_EQUALVERIFY and and causing their
> transaction fluctuate between acceptable and unacceptable, with no party
> doing anything like a double spend. This is a major problem with the
> proposal.
>
Transactions that redeem an output containing (or referencing by means of
P2WSH) an OP_COUNT_ACKS are not broadcast by the network. That means that
the network cannot be DoS attacked by flooding with a transaction that will
not verify due to being too late.
The only parties that can include the redeem transaction are the miners
themselves.
Therefore I see no problem that an OP_COUNT_ACKS scriptSig transaction is
invalidated after the liveness times expires.
If there is no expiration, then polls can last forever and the system fails
to provide DoS protection for block validation since active polls can
accumulate forever.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/c6349d29/attachment-0001.html>

2023-06-07 17:53:41

- reply

📅 Original date posted:2016-10-02
📝 Original message:Peter, are you really going to try to down vote a decent free and
open-source proposal that benefits all the Bitcoin community including
you and your future children because a personal attack to me without any
logic or basis?
Is that the way you collaborate to improving Bitcoin?
I just can't believe it.
Let's open another thread elsewhere to discuss hardware and software
patents, and that particular one, if you wish, this is NOT the place.
On Sun, Oct 2, 2016 at 1:17 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sun, Oct 02, 2016 at 12:49:08PM -0300, Sergio Demian Lerner via
> bitcoin-dev wrote:
>
> I think your history of patenting(1) Bitcoin consensus relevant technology
> is
> sufficient by itself to be extremely dubious of any proposals coming from
> you
> or your colleagues; patents on Bitcoin consensus technology are a serious
> threat to decentralization. Personally, I'm NACKing this proposal on that
> basis
> alone.
>
> You need to rectify this dangerous and unethical behavior in a convincing,
> legally binding way. I'd suggest looking into Blockstream's patent pledges
> as a
> way forward:
>
> https://www.blockstream.com/about/patent_pledge/
>
> I see no reason to have any further discussion of your proposal until this
> is
> rectified.
>
> 1) "AsicBoost is a patent-pending method to improve the efficiency and
> cost of Bitcoin mining by approximately 20%"
> http://www.asicboost.com/single-post/2016/03/24/AsicBoost-Press-Release
>
> > Since ScalingBitcoin is close, I think this is a good moment to publish
> our
> > proposal on drivechains. This BIP proposed the drivechain we'd like to
> use
> > in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it
> implemented
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/67b00718/attachment.html>

2023-06-07 17:53:41

- reply

📅 Original date posted:2016-10-02
📝 Original message:Since ScalingBitcoin is close, I think this is a good moment to publish our
proposal on drivechains. This BIP proposed the drivechain we'd like to use
in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented
in Bitcoin. Until that happens, we're using a federated approach.
I'm sure that adding risk-less Bitcoin extensibility through
sidechains/drivechains is what we all want, but it's of maximum importance
to decide which technology will leads us there.
We hope this work can also be the base of all other new 2-way-pegged
blockchains that can take Bitcoin the currency to new niches and test new
use cases, but cannot yet be realized because of current
limitations/protections.
The full BIP plus a reference implementation can be found here:
BIP (draft):
https://github.com/rootstock/bips/blob/master/BIP-R10.md
Code & Test cases:
https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
(Note: Code is still unaudited)
As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked opcode
that counts acks and nacks tags in coinbase fields, and push the resulting
totals in the script stack.
The system was designed with the following properties in mind:
1. Interoperability with scripting system
2. Zero risk of invalidating a block
3. No additional computation during blockchain management and
re-organization
4. No change in Bitcoin security model
5. Bounded computation of poll results
6. Strong protection from DoS attacks
7. Minimum block space consumption
8. Zero risk of cross-secondary chain invalidation
Please see the BIP draft for a more-detailed explanation on how we achieve
these goals.
I'll be in ScalingBitcoin in less than a week and I'll be available to
discuss the design rationale, improvements, changes and ideas any of you
may have.
Truly yours,
Sergio Demian Lerner
Bitcoiner and RSK co-founder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/b654e8f3/attachment.html>

2023-06-07 17:53:11

- reply

📅 Original date posted:2016-08-26
📝 Original message:Because there was a discussion on reddit about this topic, I want to
clarify that Johnson Lau explained how a check in the code prevents this
attack.
So there is no real attack.
Also note that the subject of this thread has a question mark, which means
that I'm asking the community for clarification, not asserting the
existence of a vulnerability.
The segwit code is complex, and some key parts of the consensus code are
spread over the source files (such as state.CorruptionPossible() relation
to DoS banning, IsNull() check in witness program serialization, etc.).
Thanks again Johnson for your clarifications.
On Wed, Aug 24, 2016 at 10:49 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
> Adding witness data to a non-segwit script is invalid by consensus:
>
> https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5e
> b919a87907/src/script/interpreter.cpp#L1467
>
>
> This PR will detect such violation early and ban the peer:
>
> https://github.com/bitcoin/bitcoin/pull/8499
>
>
> Another approach is to run the scripts of all incoming transactions.
> That's not too bad as you have already fetched the utxos which is a major
> part of validation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160826/aa2ad6dd/attachment.html>

2023-06-07 17:53:11

- reply

📅 Original date posted:2016-08-24
📝 Original message:In a previous thread ("New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH") it was briefly discussed what happens if someone
modifies segwit data during transmission. I think the discussion should
continue.
What worries me is what happens with non-segwit transactions after segwit
is activated. I've followed the code from transaction arrival to
transaction relay and it seems that a malicious node could receive a
non-segwit tx, and re-format it into a segwit tx having as high as 400
Kbytes of segwit witness program data, and then relay it. Both transaction
would have the same hash.
The MAX_SCRIPT_ELEMENT_SIZE limit is only enforced on segwit execution, not
in old non-segwit execution, so witness program stack elements could be as
large as 400 Kbytes (MAX_STANDARD_TX_WEIGHT prevents increasing more).
Such large modified transaction will probably not be properly relayed by
the network due too low fee/byte, so the honest miner will probably win and
forward the original transaction through the network.
But if the attacker has better connectivity with the network and he
modifies the original transaction adding segwit witness program data only
up to the point where the transaction is relayed but miners are discouraged
to include it in blocks due to low fees/byte, then the attacker has
successfully prevented a transaction from being mined (or at least it will
take much more).
Also an attacker can encode arbitrary data (such as virus signatures or
illegal content) into passing non-segwit transactions.
One solution would be to increase the transaction version to 3 for segwit
transactions, so a non-segwit transaction cannot be converted into a segwit
transaction without changing the transaction hash. But this seems not to be
a good solution, because it does not solve all the problems. Transactions
having a mixture of segwit and non-segwit inputs could suffer the same
attack (even if they are version 3).
I proposed that a rule is added to IsStandardTX() that prevents witness
programs of having a stack elements of length greater than
MAX_SCRIPT_ELEMENT_SIZE. (currently this is not a rule)
That's a simple check that prevents most of the problems.
A long term solution would be to add the maximum size of the witness stack
in bytes (maxWitnessSize) as a field for each input, or as a field of the
whole transaction.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/1158ef31/attachment.html>

2023-06-07 17:52:59

- reply

📅 Original date posted:2016-08-17
📝 Original message:I think that we're not attacking the real source of the problem: that the
witness data size is not signed. It may be the case that a new source of
malleability is detected in witness programs later, or related to new
opcodes we'll soft-fork in the future.
The problem is real, as some systems (such as hardware wallets or other
low-memory IoT embedded systems) may have hard limits in the size of the
witness program they can accept. So we need a solution for all current and
future segwit extension problems.
We could soft-fork to add an opcode OP_PROGSIZE using segwit script
versioning that pushes in the stack the size of the segwit program being
evaluated, and then the script can take any action it wishes based on that.
Example:
<0x50> OP_PROGSIZE OP_GREATERTHAN OP_VERIFY ..... OP_CHECKSIG
Then an attacker cannot create a clone of the transaction having a witness
ECDSA signature longer than 0x50 bytes. (many details omitted in this
example)
On Wed, Aug 17, 2016 at 7:15 AM, Johnson Lau via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On August 17, 2016 at 12:40 AM Luke Dashjr <luke at dashjr.org> wrote:
> >
> >
> > On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev
> wrote:
> > > To completely replicate the original behaviour, one may use:
> > > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if
> script}
> > > ELSE DROP {else script} ENDIF"
> >
> > This is much uglier than expected. IMO if that's the best workaround for
> the
> > current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if
> they
> > need to avoid malleability issues.
>
> It is ugly only if you want to faithfully replicate the behaviour. I'd
> argue that in no real use case you need to do this. For example, "OP_SIZE
> OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_SIZE must
> return a valid MINIMALDATA number.
>
> And your workaround does not fix malleability, since any non-0x01 values
> are valid FALSE
>
> However, in some case, enforcing MINIMALIF does require 1 more witness
> byte: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/
> 013036.html
>
> I think the best strategy is to make it a relay policy first, and decide
> whether we want a softfork later.
>
> _______________________________________________
> 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/20160817/7e9c664e/attachment-0001.html>

2023-06-07 17:52:59

- reply

📅 Original date posted:2016-08-17
📝 Original message:On Wed, Aug 17, 2016 at 9:19 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Thu, Aug 18, 2016 at 12:11 AM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I think that we're not attacking the real source of the problem: that the
> > witness data size is not signed.
>
> It's not possible to do that for the general case, since you may not
> even know the witness size in advance (even for checksig's ECDSA, the
> encoding is variable sized).
>
> That's why scripts can check a maximum witness size, and not necessarily
an exact value.
I think that is overly focusing on "someone might change the feerate",
> yes that is an example of an undesirable witness tampering, but it's
> not the only one.
>
> I don't think fees are the problem. There is another problem. Let me
re-explain.
If I send a transaction to an IoT device (say to an OpenDime or to the old
Firmcoin), and the OpenDime must verify that the transaction has been mined
(SPV verification), then it may expect the witness program to be of certain
maximum size (an implementation-imposed limit). If a Miner modifies the
witness size and makes it too large, then the device may not be able to
accept the transaction and the bitcoins may be lost. Lost because the
private key is in the device, and because the device cannot accept that
cloned transaction, never ever.
The same is true (although less strict) for side-chains and drive-chains:
they may have certain restrictions on the size of transactions they accept
to lock bitcoins.
That's why I'm proposing that a transaction becomes INVALID if the witness
size is higher than the expected size (by the sender).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/8a7bc92b/attachment.html>

2023-06-07 17:50:56

- reply

📅 Original date posted:2016-05-24
📝 Original message:Bitcoin Beacon paper relevant here
Basically is suggest using deciding a random bit on the majority 1s or 0s
of lsb bits taken from last block hashes.
Iddo Bentov∗ Technion, Ariel Gabizon, David Zuckerman
We examine a protocol πbeacon that outputs unpredictable and publicly
verifiable randomness, meaning that the output is unknown at the time that
πbeacon starts, yet everyone can verify that the output is close to uniform
after πbeacon terminates. We show that πbeacon can be instantiated via
Bitcoin under sensible assumptions; in particular we consider an adversary
with an arbitrarily large initial budget who may not operate at a loss
indefinitely.
In case the adversary has an infinite budget, we provide an impossibility
result that stems from the similarity between the Bitcoin model and
Santha-Vazirani sources. We also give a hybrid protocol that combines
trusted parties and a Bitcoin-based beacon.
On Sun, May 22, 2016 at 10:30 AM, Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> nack -- not secure.
>
> OP_PRANDOM also adds extra validation overhead on a block potentially
> composed of transactions all spending an OP_PRANDOM output from all
> different blocks.
>
> I do agree that random numbers are highly desirable though.
>
> I think it would be much better for these use cases to add OP_XOR back and
> then use something like Blum's fair coin-flipping over the phone. OP_XOR
> may have other uses too.
>
> I have a write-up from a while back which does Blum's without OP_XOR using
> OP_SIZE for off-chain probabilistic payments if anyone is interested. No
> fork needed, but of course it is more limited and broken in a number of
> ways.
>
> (sorry to those of you seeing this twice, my first email bounced the list)
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Matthew,
>>
>> You should take a look at OP_DETERMINISTICRANDOM [1] from the Elements
>> Project. It aims to achieve a similar goal.
>>
>> Code is in the `alpha` branch [2].
>>
>> [1]: https://www.elementsproject.org/elements/opcodes/
>> [2]:
>> https://github.com/ElementsProject/elements/blob/alpha/src/script/interpreter.cpp#L1252-L1305
>>
>> On Fri, May 20, 2016 at 8:29 AM Matthew Roberts via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Good point, to be honest. Maybe there's a better way to combine the
>>> block hashes like taking the first N bits from each block hash to produce a
>>> single number but the direction that this is going in doesn't seem ideal.
>>>
>>> I just asked a friend about this problem and he mentioned using the hash
>>> of the proof of work hash as part of the number so you have to throw away a
>>> valid POW if it doesn't give you the hash you want. I suppose its possible
>>> to make it infinitely expensive to manipulate the number but I can't think
>>> of anything better than that for now.
>>>
>>> I need to sleep on this for now but let me know if anyone has any better
>>> ideas.
>>>
>>>
>>>
>>> On Fri, May 20, 2016 at 6:34 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
>>>
>>>> Using the hash of multiple blocks does not make it any safer. The miner
>>>> of the last block always determines the results, by knowing the hashes of
>>>> all previous blocks.
>>>>
>>>>
>>>> == Security
>>>>
>>>> Pay-to-script-hash can be used to protect the details of contracts that
>>>> use OP_PRANDOM from the prying eyes of miners. However, since there is also
>>>> a non-zero risk that a participant in a contract may attempt to bribe a
>>>> miner the inclusion of multiple block hashes as a source of randomness is a
>>>> must. Every miner would effectively need to be bribed to ensure control
>>>> over the results of the random numbers, which is already very unlikely. The
>>>> risk approaches zero as N goes up.
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> 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/20160524/2251ddba/attachment.html>

2023-06-07 17:50:56

- reply

📅 Original date posted:2016-05-24
📝 Original message:Missing link to paper: https://arxiv.org/abs/1605.04559
Another relevant paper:
On Bitcoin as a public randomness source
Joseph Bonneau, Jeremy Clark, and Steven Goldfeder
https://eprint.iacr.org/2015/1015.pdf
On Tue, May 24, 2016 at 11:30 AM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
> Bitcoin Beacon paper relevant here
>
> Basically is suggest using deciding a random bit on the majority 1s or 0s
> of lsb bits taken from last block hashes.
>
> Iddo Bentov∗ Technion, Ariel Gabizon, David Zuckerman
>
> We examine a protocol πbeacon that outputs unpredictable and publicly
> verifiable randomness, meaning that the output is unknown at the time that
> πbeacon starts, yet everyone can verify that the output is close to uniform
> after πbeacon terminates. We show that πbeacon can be instantiated via
> Bitcoin under sensible assumptions; in particular we consider an adversary
> with an arbitrarily large initial budget who may not operate at a loss
> indefinitely.
> In case the adversary has an infinite budget, we provide an impossibility
> result that stems from the similarity between the Bitcoin model and
> Santha-Vazirani sources. We also give a hybrid protocol that combines
> trusted parties and a Bitcoin-based beacon.
>
> On Sun, May 22, 2016 at 10:30 AM, Jeremy via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> nack -- not secure.
>>
>> OP_PRANDOM also adds extra validation overhead on a block potentially
>> composed of transactions all spending an OP_PRANDOM output from all
>> different blocks.
>>
>> I do agree that random numbers are highly desirable though.
>>
>> I think it would be much better for these use cases to add OP_XOR back
>> and then use something like Blum's fair coin-flipping over the phone.
>> OP_XOR may have other uses too.
>>
>> I have a write-up from a while back which does Blum's without OP_XOR
>> using OP_SIZE for off-chain probabilistic payments if anyone is interested.
>> No fork needed, but of course it is more limited and broken in a number of
>> ways.
>>
>> (sorry to those of you seeing this twice, my first email bounced the list)
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>
>> <https://twitter.com/JeremyRubin>
>>
>> On Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Matthew,
>>>
>>> You should take a look at OP_DETERMINISTICRANDOM [1] from the Elements
>>> Project. It aims to achieve a similar goal.
>>>
>>> Code is in the `alpha` branch [2].
>>>
>>> [1]: https://www.elementsproject.org/elements/opcodes/
>>> [2]:
>>> https://github.com/ElementsProject/elements/blob/alpha/src/script/interpreter.cpp#L1252-L1305
>>>
>>> On Fri, May 20, 2016 at 8:29 AM Matthew Roberts via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Good point, to be honest. Maybe there's a better way to combine the
>>>> block hashes like taking the first N bits from each block hash to produce a
>>>> single number but the direction that this is going in doesn't seem ideal.
>>>>
>>>> I just asked a friend about this problem and he mentioned using the
>>>> hash of the proof of work hash as part of the number so you have to throw
>>>> away a valid POW if it doesn't give you the hash you want. I suppose its
>>>> possible to make it infinitely expensive to manipulate the number but I
>>>> can't think of anything better than that for now.
>>>>
>>>> I need to sleep on this for now but let me know if anyone has any
>>>> better ideas.
>>>>
>>>>
>>>>
>>>> On Fri, May 20, 2016 at 6:34 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
>>>>
>>>>> Using the hash of multiple blocks does not make it any safer. The
>>>>> miner of the last block always determines the results, by knowing the
>>>>> hashes of all previous blocks.
>>>>>
>>>>>
>>>>> == Security
>>>>>
>>>>> Pay-to-script-hash can be used to protect the details of contracts
>>>>> that use OP_PRANDOM from the prying eyes of miners. However, since there is
>>>>> also a non-zero risk that a participant in a contract may attempt to bribe
>>>>> a miner the inclusion of multiple block hashes as a source of randomness is
>>>>> a must. Every miner would effectively need to be bribed to ensure control
>>>>> over the results of the random numbers, which is already very unlikely. The
>>>>> risk approaches zero as N goes up.
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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/20160524/ce08f20a/attachment-0001.html>

2023-06-07 17:50:37

- reply

📅 Original date posted:2016-05-11
📝 Original message:Jorge Timón said..
> What do you mean by "embrace" in the context of a patented optimization
that one miner can prevent the rest from using?
Everyone seems to assume that one ASIC manufacturer will get the advantage
of AsicBoost while others won't. If a patent license is non-exclusive, then
all can.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/63abfd40/attachment.html>

2023-06-07 17:50:34

- reply

📅 Original date posted:2016-05-10
📝 Original message:On Tue, May 10, 2016 at 3:57 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As part of the hard-fork proposed in the HK agreement(1) we'd like to make
> the
> patented AsicBoost optimisation useless, and hopefully make further similar
> optimizations useless as well.
>
>
> You say that you want to make patented optimization useless, but you point
to a link that doesn't say anything about ASIC improvements or patents,
which means that you have been planning to change the protocol rules with
some miners (but not all the community).
All changes to the protocol should be discussed in public here. If you want
to make "further similar optimizations useless as well" then maybe you
should propose a switch to EquiHash.
>
> 1)
> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>
> 2)
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/a24f3b78/attachment.html>

2023-06-07 17:50:30

- reply

📅 Original date posted:2016-05-11
📝 Original message:On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
sergio.d.lerner at gmail.com> wrote:
>
>
> You can find it here:
> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
>
> Basically, the idea is to put in the first 64 bytes a 4 byte hash of the
> second 64-byte chunk. That design also allows increased nonce space in the
> first 64 bytes.
>
> My mistake here. I didn't recalled correctly my own idea. The idea is to
include in the second 64-byte chunk a 4-byte hash of the first chunk, not
the opposite.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160511/b0e9c92b/attachment.html>

2023-06-07 17:50:29

- reply

📅 Original date posted:2016-05-10
📝 Original message:Your idea of moving the Merkle root to the second chunk does not work.
The AsicBoost can change the version bits and it does not need to find a
collision.
(However *Spondoolies patent *only mentions Merkle collisions:
https://patentscope.wipo.int/search/docservicepdf_pct/id00000032873338/PAMPH/WO2016046820.pdf
)
Back in 2014 I designed a ASIC-compatible block header that prevents
AsicBoost in all its forms.
You can find it here:
https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
Basically, the idea is to put in the first 64 bytes a 4 byte hash of the
second 64-byte chunk. That design also allows increased nonce space in the
first 64 bytes.
But it you want to do a simpler change, you can more easily use the first
32 bits of the Parent Block Hash (now currently zero) to store the first 4
bytes of the SHA256 of the last 16 bytes of the header. That way to "tie"
the two header chunks. It's a minimal change (but a hard-fork)
But some ASIC companies already have cores that are better (on power, cost,
rate, temperature, etc.) than competing companies ASICs. Why do you think a
10% improvement from AsicBoost is different from many of other improvements
they already have (secretly) added? Maybe we (?) should only allow ASICs
that have a 100% open source designs?
If we change the protocol then the message to the ecosystem is that ASIC
optimizations should be kept secret. It is fair to change the protocol
because we don't like that certain ASIC manufacturer has better chips, if
the chips are sold in the market and anyone can buy them? And what about
using approximate adders (30% improvement), or dual rail asynchronous
adders (also more than 10% improvement) ? How do we repair those?
Disclaimer: I have stake in AsicBoost, but I'm not sure about this.
On Tue, May 10, 2016 at 5:27 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The various chunks in the double SHA256 are
>
> Chunk 1: 64 bytes
> version
> previous_block_digest
> merkle_root[31:4]
>
> Chunk 2: 64 bytes
> merkle_root[3:0]
> nonce
> timestamp
> target
>
> Chunk 3: 64 bytes
> digest from first sha pass
>
> Their improvement requires that all data in Chunk 2 is identical except
> for the nonce. With 4 bytes, the birthday paradox means collisions can be
> found reasonable easily.
>
> If hard forks are allowed, then moving more of the merkle root into the
> 2nd chunk would make things harder. The timestamp and target could be
> moved into chunk 1. This increases the merkle root to 12 bytes in the 2nd
> chunk. Finding collisions would be made much more difficult.
>
> If ASIC limitations mean that the nonce must stay where it is, this would
> mean that the merkle root would be split into two pieces.
>
> On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> As part of the hard-fork proposed in the HK agreement(1) we'd like to
>> make the
>> patented AsicBoost optimisation useless, and hopefully make further
>> similar
>> optimizations useless as well.
>>
>> What's the best way to do this? Ideally this would be SPV compatible, but
>> if it
>> requires changes from SPV clients that's ok too. Also the fix this should
>> be
>> compatible with existing mining hardware.
>>
>>
>> 1)
>> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>>
>> 2)
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> 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/20160510/e98fa60e/attachment-0001.html>

2023-06-07 17:49:59

- reply

📅 Original date posted:2016-03-23
📝 Original message:It seems that every message must be signed (the protocols lacks MACs). This
can be very resource consuming in terms of CPU and bandwidth since most p2p
messages are small.
On Wed, Mar 23, 2016 at 5:36 PM, Tom via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:
> > Hi
> >
> > I have just PRed a draft version of two BIPs I recently wrote.
> > https://github.com/bitcoin/bips/pull/362
>
> I suggest running a spellchecker ;)
>
> Some questions;
>
> * why would you not allow encryption on non-pre-approved connections?
> * we just removed (ssl) encryption from the JSON interface, how do you
> suggest
> this encryption to be implemented without openSSL?
> * What is the reason for using the p2p code to connect a wallet to a node?
> I suggest using one of the other connection methods to connect to the node.
> This avoids a change in the bitcoin protocol for a very specific usecase.
> * Why do you want to do a per-message encryption (wrapping the original)?
> Smaller messages that contain predictable content and are able to be
> matched
> to the unencrypted versions on the wire send to other nodes will open this
> scheme up to various old statistical attacks.
>
> > Responding peers must ignore (banning would lead to fingerprinting) the
> requesting peer after 5 unsuccessfully authentication tries to avoid
> resource
> attacks.
>
> Any implementation of that kind would itself again be open to resource
> attacks.
> Why 5? Do you want to allow a node to make a typo?
>
>
> > To ensure that no message was dropped or blocked, the complete
> communication
> must be hashed (sha256). Both peers keep the SHA256 context of the
> encryption
> session. The complete <code>enc</code> message (leaving out the hash
> itself)
> must be added to the hash-context by both parties. Before sending a
> <code>enc</code> command, the sha256 context will be copied and finalized.
>
> You write "the complete communication must be hashed" and every message
> has a
> hash of the state until it is at that point.
> I think you need to explain how that works specifically.
>
>
> _______________________________________________
> 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/20160323/adfd13d4/attachment.html>

2023-06-07 17:49:54

- reply

📅 Original date posted:2016-03-21
📝 Original message:The BIP147 reads:
*Sigop cost* is defined. The cost of a sigop in traditional script is 4,
while the cost of a sigop in witness program is 1.
The new rule is total *sigop cost* ≤ 80,000.
But the code implements:
if (nSigOps + (nWitSigOps + 3) / 4 > MAX_BLOCK_SIGOPS)
... error....
Which is not the same.
For example:
nSigOps = 1
nWitSigOps =79999
Is not an error by BIP definition but it's an error by the implemented code.
Regards, Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160320/74fe80fb/attachment.html>

2023-06-07 17:49:54

- reply

📅 Original date posted:2016-03-22
📝 Original message:My mistake.
El mar 22, 2016 3:49 AM, <jl2012 at xbt.hk> escribió:
> Do you mean BIP141?
>
>
>
> Your example is an error by BIP141:
>
>
>
> 1*4 + 79999*1 = 80003 > 80000
>
>
>
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:
> bitcoin-dev-bounces at lists.linuxfoundation.org] *On Behalf Of *Sergio
> Demian Lerner via bitcoin-dev
> *Sent:* Monday, 21 March, 2016 10:51
> *To:* bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* [bitcoin-dev] BIP147 minor error
>
>
>
> The BIP147 reads:
>
> *Sigop cost* is defined. The cost of a sigop in traditional script is 4,
> while the cost of a sigop in witness program is 1.
>
> The new rule is total *sigop cost* ≤ 80,000.
>
> But the code implements:
>
> if (nSigOps + (nWitSigOps + 3) / 4 > MAX_BLOCK_SIGOPS)
>
> ... error....
>
> Which is not the same.
>
>
> For example:
>
> nSigOps = 1
> nWitSigOps =79999
>
> Is not an error by BIP definition but it's an error by the implemented
> code.
>
> Regards, Sergio.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160322/9d37efef/attachment.html>

2023-06-07 17:49:20

- reply

📅 Original date posted:2016-02-26
📝 Original message:Congratulations!
It a property of the SKCP system that the person who performed the trusted
setup cannot extract any information from a proof?
In other words, is it proven hard to obtain information from a proof by the
buyer?
On Fri, Feb 26, 2016 at 6:42 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I am happy to announce the first successful Zero-Knowledge Contingent
> Payment (ZKCP) on the Bitcoin network.
>
> ZKCP is a transaction protocol that allows a buyer to purchase
> information from a seller using Bitcoin in a manner which is private,
> scalable, secure, and which doesn’t require trusting anyone: the
> expected information is transferred if and only if the payment is
> made. The buyer and seller do not need to trust each other or depend
> on arbitration by a third party.
>
> Imagine a movie-style “briefcase swap” (one party with a briefcase
> full of cash, another containing secret documents), but without the
> potential scenario of one of the cases being filled with shredded
> newspaper and the resulting exciting chase scene.
>
> An example application would be the owners of a particular make of
> e-book reader cooperating to purchase the DRM master keys from a
> failing manufacturer, so that they could load their own documents on
> their readers after the vendor’s servers go offline. This type of sale
> is inherently irreversible, potentially crosses multiple
> jurisdictions, and involves parties whose financial stability is
> uncertain–meaning that both parties either take a great deal of risk
> or have to make difficult arrangement. Using a ZKCP avoids the
> significant transactional costs involved in a sale which can otherwise
> easily go wrong.
>
> In today’s transaction I purchased a solution to a 16x16 Sudoku puzzle
> for 0.10 BTC from Sean Bowe, a member of the Zcash team, as part of a
> demonstration performed live at Financial Cryptography 2016 in
> Barbados. I played my part in the transaction remotely from
> California.
>
> The transfer involved two transactions:
>
> 8e5df5f792ac4e98cca87f10aba7947337684a5a0a7333ab897fb9c9d616ba9e
> 200554139d1e3fe6e499f6ffb0b6e01e706eb8c897293a7f6a26d25e39623fae
>
> Almost all of the engineering work behind this ZKCP implementation was
> done by Sean Bowe, with support from Pieter Wuille, myself, and Madars
> Virza.
>
>
> Read more, including technical details at
>
> https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/
>
> [I hope to have a ZKCP sudoku buying faucet up shortly. :) ]
> _______________________________________________
> 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/20160226/09f83fe6/attachment.html>

2023-06-07 17:43:29

- reply

📅 Original date posted:2015-10-14
📝 Original message:I'm reading it.
First comment: since a Bitcoin block time is only greater than the median
of the last 11 blocks, a miner could choose the key block time in order to
generate about 400 miniblocks, instead of the average 60 blocks. Not very
bad, but should be taken into account.
On Wed, Oct 14, 2015 at 3:02 PM, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi everyone,
>
> We just released the whitepaper describing Bitcoin-NG, a new technique for
> addressing some of the scalability challenges faced by Bitcoin.
> Surprisingly, Bitcoin-NG can simultaneously increase throughput while
> reducing latency, and do so without impacting Bitcoin's open architecture
> or changing its trust model. This post illustrates the core technique:
> http://hackingdistributed.com/2015/10/14/bitcoin-ng/
> while the whitepaper has all the nitty gritty details:
> http://arxiv.org/abs/1510.02037
>
> Fitting NG on top of the current Bitcoin blockchain is future work that we
> think is quite possible. NG is compatible with both Bitcoin as is, as well
> as Blockstream-like sidechains, and we currently are not planning to
> compete commercially with either technology -- we see NG as being
> complementary to both efforts. This is pure science, published and shared
> with the community to advance the state of blockchains and to help them
> reach throughputs and latencies required of cutting edge fintech
> applications. Perhaps it can be adopted, or perhaps it can provide the
> spark of inspiration for someone else to come up with even better solutions.
>
> We would be delighted to hear your feedback.
> - Ittay Eyal and E. Gün Sirer.
>
>
> _______________________________________________
> 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/20151014/7b921e1f/attachment-0001.html>

2023-06-07 17:42:53

- reply

📅 Original date posted:2015-10-06
📝 Original message:Hi Venzen,
I don't know you and I never said "for fuck's sake" to anyone on IRC. I
don't use IRC, and almost never say 4 letter words.
I wonder how technically savvy people trust IRC ids. Could you send me the
link where such an impostor said something to you in my name?
Your e-mail reads like a TV plot. To me, agent Hearn is just Mike. Agent
Lerner is just an Argentinian dude with some spare time to write here. But
maybe you know something I don't....
Best regards!
Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151006/011abf61/attachment-0001.html>

2023-06-07 17:42:37

- reply

📅 Original date posted:2015-10-05
📝 Original message:Some of the people on this mailing list are blindly discussing the
technicalities of a soft/hard fork without realizing that is not Mike's
main intention. At least I perceive (and maybe others too) something else
is happening.
Let me try to clarify: the discussion has nothing to do with technical
arguments. I generally like more hard forks than soft forks (but I won't
explain why because this is not a technical thread), but for CLTV this is
quite irrelevant (but I won't explain why..), and I want CLTV to be
deployed asap.
Mike's intention is to criticize the informal governance model of Bitcoin
Core development and he has strategically pushed the discussion to a
dead-end where the group either:
1) ignores him, which is against the established criteria that all
technical objections coming from anyone must be addressed until that person
agrees, so that a change can be uncontroversial. If the group moves forward
with the change, then the "uncontroversial" criteria is violated and then
credibility is lost. So a new governance model would be required for which
the change is within the established rules.
2) respond to his technical objections one after the other, on never ending
threads, bringing the project to a standstill.
As I don't want 2) to happen, then 1) must happen, which is what Mike
wants. I have nothing for or against Mike personally. I just think Mike
Hearn has won this battle. But having a more formal decision making process
may not be too bad for Bitcoin, maybe it can actually be good.
Best regards
from a non-developer to my dearest developer friends,
Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/4d07e31d/attachment.html>

2023-06-07 17:40:25

- reply

📅 Original date posted:2015-09-16
📝 Original message:One possible way to incentivize the existence of more Bitcoin network nodes
is by paying peers when they provide data in the blokcchain. One of the
problems is that it is not easy to tell if the peer is really providing a
useful service by storing the blockchain or it is just relying the request
to some other peers as a proxy.
In this post I review the use of asymmetric-time functions to be able to
prove unique (IP-tied) blockchain storage and propose improvements to make
it fully practical.
Full post here:
https://bitslog.wordpress.com/2015/09/16/proof-of-unique-blockchain-storage-revised/
Best regards, Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/4d9dfc3c/attachment.html>

2023-06-07 17:38:20

- reply

📅 Original date posted:2015-08-27
📝 Original message:Guys,
I strongly think the original prabhat e-mail is a parody.
And I find very funny that important people have responded.
But maybe I'm wrong!
*:)*
El jue., 27 ago. 2015 a las 11:04, Chris Pacia via bitcoin-dev (<
bitcoin-dev at lists.linuxfoundation.org>) escribió:
>
>
> On 08/27/2015 09:39 AM, prabhat via bitcoin-dev wrote:
>
> Fine point.
>
> So where is the solution? What to do?
>
>
> How about nothing.
> _______________________________________________
> 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/20150827/cba7d874/attachment.html>

2023-06-07 17:37:10

- reply

📅 Original date posted:2015-08-21
📝 Original message:Hector,
I can only say 2 things in the brief time I have now:
1. There is a solution that I proposed for proving you own a copy of the
block-chain. It's using aymmetric-time functions:
https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/
2. I'm finishing a paper on a transaction system (DAGCoin) which relies on
proof-of-work per transactions, and no per blocks. Actually it has no
blocks.
This has been explored in the past, but I came up with some basic ideas
that make this work a few months ago. I will forward a draft to you while
at the same time I try to analyze your proposal. Or I may publish the draft
altogether.
Best regards,
Sergio
On Fri, Aug 21, 2015 at 5:50 PM, Tamas Blummer via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Jameson,
>
> I like your thinking about the implicit reward of full nodes. It was not
> perceived as sufficient by many, hence full node counts were falling.
>
> This might reverse now as the implicit value of validating yourself
> however becomes higher in a heterogenous environment, that is if there are
> hard forks in the wild.
>
> Actually pooled mining became an option through the homogenous nature of
> the network.
>
> Tamas Blummer
>
> On Aug 19, 2015, at 13:42, Jameson Lopp via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> The incentives for running a node may not be obvious to the average user,
> but they are there. Rather than direct monetary incentives, they are
> indirect. For one, it allows you to have a local copy of the blockchain
> that you validated yourself - trustlessness is the entire point of this
> system. Having local self-validated blockchain data is also essential for
> any enterprise that needs to quickly access large volumes of it. The other
> incentive is it supports the network. Users may feel that this is necessary
> out of altruism or they may feel incentivized to protect their investments
> in Bitcoin.
>
>
>
> _______________________________________________
> 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/842df401/attachment-0001.html>

2023-06-07 17:36:00

- reply

📅 Original date posted:2015-08-16
📝 Original message:In these shocking forking times, nothing more relaxing that to immerse
yourself in a pure technical reading about cryptocurrency design, letting
aside Bitcoin politics for a moment. This message is about cryptocurrencies
design in general, so you're free to skip my message if you think it will
never apply to Bitcoin.
[ full article copied from my blog:
https://bitslog.wordpress.com/2015/08/16/how-decor-can-eradicate-selfish-mining-incentive-by-design/
]
A year ago I proposed the DECOR protocol
<https://bitslog.wordpress.com/2014/05/02/decor/>, a new rule for
cryptocurrencies to reduce significantly the amount of orphan blocks and
then allow block rate to be as high as one block every 5 seconds, and at
the same time it promised to address the problem of selfish mining
<http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/>. After one
year, I’ve received very little feedback about it. Yet the selfish mining
<http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/> problem has
been argued over and over against certain changes in Bitcoin, as if selfish
mining were something inevitable to all POW-based cryptocurrencies. But it
is not.
In a nutshell, DECOR is a protocol that permits miners to share the block
reward if both mine competing blocks. This is done by publishing block
header siblings (sometime called uncles) into child blocks, and modifying
the cryptocurrency protocol to pay some amount to the miners of uncles. If
all miners are honest, this strategy increases slightly the probability of
1-block reversals, but reduces considerably the probability of longer
reversals, as all miners choose the same parent. A few months after my
post, Ethereum <https://www.ethereum.org/>adopted a similar strategy of
paying a certain amount of ether to uncles, but the amount paid was created
out of thin ear, and at that time there could be any amount of uncles, so
basically it distorted the money supply function into a uncapped
inflationary one, if all miners decided to collude. After I reported this
issue, they restricted the number of uncles that can be included, but still
it leaves an incentive for all miners to collude to increase miner revenue.
DECOR does reward sharing, so the supply function cap is maintained. But it
does not solve the Selfish mining problem: miners withholding a block get
paid a full reward but the remaining miners are working (without knowing
it) for a half of the block reward. So my original strategy does not work
for rational (but not necessarily honest) miners. A few posts later I
presented DECOR+ <https://bitslog.wordpress.com/2014/05/07/decor-2/> to try
to address the problem of unbalanced rewards: what happens if there are two
competing blocks, but one has a 12.5 BTC reward, but the other has a 20 BTC
reward due to additional fees? But again, if miners are dishonest, the
proposed scheme does not solve the underlying problem, as miners can
artificially increase their fees to win the conflict resolving rule, at
least in all cryptocurrencies that do not burn transaction fees. How can we
fix it?
*DECOR++*
We’ll fix DECOR by doing three changes. The first is by paying full rewards
to all competing blocks, either the parent or the uncles. To prevent
increasing the money supply, first we set a maximum number of uncles U than
can be included over a period of N blocks. For example we can set U=100 and
N=1000 (a maximum orphan rate of 10%). Then we create rule to decrease the
money supply per time interval in case it previously was increased. So to
prevent miners colluding to increase the money supply in U/N, we either
decrease the subsidies of the following N blocks by the excess amount in
the previous period or we make N coincident with block difficulty re-target
interval and we consider uncles in the rate computation, so mining
afterward simply gets more difficult. If all miners collude to try to
increase their revenue by U/N, they will see their revenue decrease by the
same amount in the following re-target interval.
Miners could start switching between two cryptocurrencies to mine only
during the low difficulty interval and avoid the high difficulty interval.
But here are no competing valuable non-merged mined cryptocurrency using
SHA256D, so this is no problem for Bitcoin. Also the cryptocurrency left
without mining power would become insecure and its price will fall to near
zero. So increasing the immaturity lock time for coinbases to at least N
blocks destroys any miner earnings if all decide to switch all at once.
The second change is to choose the parent block in case of conflict based
on a deterministic random selection in case of deciding between several
chains with the same accumulated difficulty but different tip: we order the
competing tip blocks by their hash digest values, we hash the hashes and we
use the resulting hash digest as seed to a PRNG to choose an index in the
sorted list of the block to choose as parent.
The third change is to process the transactions of all competing blocks
(the actual block and its siblings) in case of a conflict. The transactions
on the parent block will be processed first as normal. The others will be
processed in the order they are referenced in following child blocks.
Conflicting transactions (double-spends) present in uncle blocks with
respect to the main block are skipped, while obviously internal conflicts
in the uncle blocks make them invalid, as usual. Now, as long as the
subsidy dominates the fees, miners have no incentive to withhold blocks.
Let’s analyze what can happen in the long term, when fees dominate the
block reward. In the future there may be two kinds of transactions: public
transactions and private transactions. Public transactions are the current
standard transactions: they pay a fee in the standard way and are broadcast
over the public network. Private transactions may appear if miners decide
to negotiate inclusion in blocks directly with web wallets or gateways:
private transactions will pay fees as an output to the miner’s public key.
Blocks with high rewards competing with blocks with low rewards due to
public transactions will be rare, since for the benefit of the miner most
transactions included in blocks should be present in all other miners
memory pools to accelerate propagation, so all miners are exposed to the
same reward pool. If it happens (by the mistake of a user) that a public
transaction pays an extremely high fee, the withholding incentive may
reappear. But in a far future, when subsidy disappears and miners receive
the payment mainly because of fees, they may adopt the more competitive
commercial strategy of rely mainly in private transactions (or maybe using Mike
Hearn’s assurance contracts
<https://en.bitcoin.it/wiki/Funding_network_security>). As fees from
private transactions are not shared between competing blocks, they won’t
affect selfish mining. I conclude that DECOR++ is currently incentive
compatible and it is highly probable that remains incentive compatible in
the future.
To summarize, DECOR++ main protocol properties are:
- Choose a parent by a deterministic pseudo-random coin toss based on
competing block headers
- Give standard subsidy to all competing blocks by including uncles in
following blocks
- Give small monetary incentive to include uncle blocks in blocks
(miners including blocks can get a small share of included blocks rewards).
- Give small monetary incentive to choose deterministically one of the
competing blocks as the main block (this can be done by burning some reward
share if other parent is chosen).
- Process all transactions in uncle blocks, quietly skipping the ones
that conflict with existing ones.
- Pay fees to original miners for all non-conflicting transactions in
uncle blocks
- Decrease the money supply in blocks following blocks including uncles
to compensate for the increase in money supply.
- Limit the amount of uncles that can be included over an interval of
blocks, and make that interval long enough to capture normal variances in
orphan rates.
- Increase the coinbase immaturity period to at least the period of
money supply compensation.
Best regards, Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/a101786f/attachment.html>

2023-06-07 17:35:43

- reply

📅 Original date posted:2015-08-18
📝 Original message:Just to add some superfluous and unessential spice to this discussion,
there were two Satoshi users originally registered in sourceforge, one
registered very soon after the other. So I say Satoshi were at least two
people, so it may be the case that one Satoshi re-appeared, but the other
did not.
Ore maybe one Satoshi is for Bitcoin XT, and the other Satoshi is against
it.
Satoshi wars!
On Tue, Aug 18, 2015 at 5:59 PM, Anon Moto via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> And this is how the powers that be compromise bitcoin. They can't stop
> TCP/IP, but they sure can take over the development team. It's a good thing
> that no one from the CIA has had any conversations with anyone from the
> bitcoin development team. Phew...
>
>
> On Tue, Aug 18, 2015 at 11:57 AM, Oliver Egginger via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Am 18.08.2015 um 11:15 schrieb Warren Togami Jr.:
>> > I honestly don't understand your position, but I get the sense that you
>> > are suggesting Satoshi wouldn't be welcome to return if he wanted to be
>> > active in development again?
>>
>> Who am I? Personally I have zero objection if the creator steps in. I
>> think he would be highly welcome by the most people. At first I had the
>> impression that the email was a fake, but maybe I was wrong. At the
>> moment I think: Maybe it's even the best if we do not know exactly
>> whether it was Satoshi or not.
>>
>> Unanimity is mission critical for Bitcoin and must be an absolute
>> priority. If not the vast majority is in favor for a fork, then the fork
>> should be avoided until a consensus is found. Even if it takes until the
>> cows come home.
>>
>> But it is very likely now that it will come to a fork. No matter which
>> site will win, this will produce a lot of humiliated people at the end.
>> That's not good and leads to bitterness on both sites.
>>
>> - oliver
>>
>>
>> _______________________________________________
>> 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/20150818/8de0e558/attachment.html>

2023-06-07 17:34:19

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Mon, Aug 10, 2015 at 6:01 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > b. Reduce the block rate to a half (average 5 minute blocks)
> >
> > Suppose this is a one time hard fork. There no drastic technical
> problems with any of them: "SPV" mining and the relay network has shown
> that block propagation is not an issue for such as small change. Mining
> centralization won't radically change for a 2x adjustment.
>
> I don't understand this. All problems that result from propagation delay
> are literally doubled by doing so. Centralization pressure results from the
> ratio between propagation time and interblock time. Efficient propagation
> algorithms like the relay network make this presumably grow sublinear with
> larger blocks, but changing the interblock time affects it exactly
> proportionally.
>
What I'm saying is that this ratio may have improved 20x since miners began
using the TheBlueMatt relay network, so deteriorating the ratio 2x does not
put miners in a unknown future, but in an future which is far better than
the state they were a year ago.
But SPV mining has improved the ratio another 2x (because headers can be
pushed even faster, fit in a single network packet, and can do without
inv/getdata round-trips because they basically "pay" for the bandwidth
usage by its own proof of work).
With a better wire protocol you can "propagate" a 10 MB block faster that
the time it takes currently to propagate an empty block.
So 10x deterioration of the ratio would be still something acceptable.
All problems that result from propagation delay are literally doubled by
> doing this. Doubling the block size has a smaller effect. You may argue
> that these centralization effects are small, but reducing the interblock
> time has a stronger effect on them than the block size.
>
> Also, you seem to consider SPV mining a good thing?
>
I'm not saying it's a good thing. I'm saying that it's impossible to avoid.
It's a real incentive. It must exists so Bitcoin is incentive compatible.
We can talk for hours and hours and we won't prevent miners from doing it.
I predicted it back in 2013, without even being a miner myself. It's here
to stay. Forever. It's a pity Greg chose that awful name of "SPV" mining
instead some cool name like "Instant" mining that we could market as
Bitcoin latest feature :)
Do you consider the TheBlueMatt relay network a "good thing". NO! It's a
very bad centralization thing, but it is unavoidable. I would like the
relay network to be embedded on the standard network protocol, using local
route optimizations to reduce latency for block propagation (there is one
old paper on this, and it says that with local prioritization you can have
a lower bound to get a propagation latency of at most two times the optimal
value (possibly generated by the minimum spanning tree)).
It requires trust between miners that know eachother, and fundamentally
> breaks the security assumption of SPV clients...
>
No is does not. The incentive follows directly from the cheating cost (the
subsidy). Even if I don't know you, I know you wouldn't waste 25 BTC to try
to cheat me for 25 BTC with a probability of 1/100, that's for sure. On
average, you loose 24.75 BTC per cheat attempt.
"SPV" mining is safe as long as it is done for a certain bounded period of
time and bounded number of blocks (e.g: 30 seconds from that last validated
block, and no more than 1 non-validated block). SPV clients that accept a
transaction with 1 confirmation are already in danger of orphaning, and
long invalid "SPV" mining chain forks (as occurred last month) should never
had occurred if limits were in-place.
SPV mining incentive will stay until there is no subsidy, as many other
incentives. SPV mining also must be there to prevent malicious actors from
DoS-ing the relay network. If it's there, then the DoS incentive disappears.
Let's code "instant" mining into Bitcoin Core, and do it right.
Also as Michael Rudy points out, higher block rate means lower variance,
and that's good for miners. Last, as I already said, having a lower average
block interval strengthens Bitcoin value proposition, so miners would be
delighted that their bitcoins are more worthy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/3e2830e1/attachment-0001.html>

2023-06-07 17:34:17

- reply

📅 Original date posted:2015-08-07
📝 Original message:In some rare occasions in everyday life, what matters is seconds. Like when
paying for parking in the car while some other cars are behind you in the
line. You don't want them to get upset.
I takes me tens of minutes to shop. But once you choose your merchandise
and your payment starts processing, if the payment system allows several
payments to be pending simultaneously and you're not blocking the next
person to pay, then I don't care waiting some minutes for confirmation. But
saving 10 minutes of confirmation is a lot.
I ague that our time is mostly measured in minutes (but I don't have any
sociological, cultural, genetic or anthropological evidence). It takes
minutes to read an e-mail, minutes to correct a bug, minutes to have lunch,
minutes to drive to the office, minutes to talk to your kids. A payment
taking 1 minute is much better than a payment taking 10. If I could choose
a single thing to change to Bitcoin, I would lower the payment time, even
within the minute scale.
Sergio
On Fri, Aug 7, 2015 at 7:46 PM, Natanael <natanael.l at gmail.com> wrote:
> Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org>:
> >
> > Mark,
> > It took you 3 minutes to respond to my e-mail. And I responded to you 4
> minutes later. If you had responded to me in 10 minutes, I would be of out
> the office and we wouldn't have this dialogue. So 5 minutes is a lot of
> time.
> >
> > Obviously this is not a technical response to the technical issues you
> argue. But "minutes" is a time scale we humans use to measure time very
> often.
>
> But what's more likely to matter is seconds. What you need then is some
> variant of multisignature notaries (Greenaddress.it, lightning network),
> where the combination of economic incentives and legal liability gives you
> the assurance of doublespend protection from the time of publication of the
> transaction to the first block confirmation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/5dad20a3/attachment.html>

2023-06-07 17:34:16

- reply

📅 Original date posted:2015-08-07
📝 Original message:Mark,
It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have this dialogue. So 5 minutes is a lot of
time.
Obviously this is not a technical response to the technical issues you
argue. But "minutes" is a time scale we humans use to measure time very
often.
:)
On Fri, Aug 7, 2015 at 6:27 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> Because halving the block interval comes with costs to SPV proofs (which
> double the number of headers) and mining centralization (doubles the
> selfish mining effect of latency) for the questionable benefit of a block
> expectation time that is still measured in minutes, not seconds.
>
> Doubling the block size is safer than halving the block interval, for the
> same effect in aggregate transactions per second.
>
> On Fri, Aug 7, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> What would you do?
>>
>> a. Double the block size
>> b. Reduce the block rate to a half (average 5 minute blocks)
>>
>> Suppose this is a one time hard fork. There no drastic technical problems
>> with any of them: "SPV" mining and the relay network has shown that block
>> propagation is not an issue for such as small change. Mining centralization
>> won't radically change for a 2x adjustment.
>>
>> So what would be best for Bitcoin?
>>
>> I suspect some (if not most of you) would choose b. Because reducing the
>> block interval saves us real time. Waiting 30 minutes for a 3-block
>> confirmation is... such a long time! Time that we value. Time that
>> sometimes we waste waiting. Time that makes a difference for us. Doubling
>> the block size does not change the user perception of Bitcoin in any way.
>>
>> Then why most discussions go around doubling the block size?
>>
>> Each change require less than 20 lines of code (*) in the reference code,
>> and minimum change in other wallets.
>>
>> Currently there is no idle mining hardware for hire, so the security of
>> six 10-minute block confirmation is equivalent to the security of six
>> 5-minute block confirmations, as described in Satoshi's paper (if there
>> were 51% spare mining hardware for hire, then obviously hiring that
>> hardware for 30 minutes would cost less than hiring it for 1 hour).
>>
>> Why we discuss a 2x block size increase and not a 1/2 block interval
>> reduction? Aren't we Bitcoin users after all?
>>
>> Best regards,
>> Sergio.
>>
>> (*) b requires increasing the transaction version number, to support the
>> old nLockTime rate.
>>
>>
>>
>> _______________________________________________
>> 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/20150807/7ed74a86/attachment-0001.html>

2023-06-07 17:34:15

- reply

📅 Original date posted:2015-08-07
📝 Original message:What would you do?
a. Double the block size
b. Reduce the block rate to a half (average 5 minute blocks)
Suppose this is a one time hard fork. There no drastic technical problems
with any of them: "SPV" mining and the relay network has shown that block
propagation is not an issue for such as small change. Mining centralization
won't radically change for a 2x adjustment.
So what would be best for Bitcoin?
I suspect some (if not most of you) would choose b. Because reducing the
block interval saves us real time. Waiting 30 minutes for a 3-block
confirmation is... such a long time! Time that we value. Time that
sometimes we waste waiting. Time that makes a difference for us. Doubling
the block size does not change the user perception of Bitcoin in any way.
Then why most discussions go around doubling the block size?
Each change require less than 20 lines of code (*) in the reference code,
and minimum change in other wallets.
Currently there is no idle mining hardware for hire, so the security of six
10-minute block confirmation is equivalent to the security of six 5-minute
block confirmations, as described in Satoshi's paper (if there were 51%
spare mining hardware for hire, then obviously hiring that hardware for 30
minutes would cost less than hiring it for 1 hour).
Why we discuss a 2x block size increase and not a 1/2 block interval
reduction? Aren't we Bitcoin users after all?
Best regards,
Sergio.
(*) b requires increasing the transaction version number, to support the
old nLockTime rate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/16d23adc/attachment.html>

2023-06-07 17:33:18

- reply

📅 Original date posted:2015-08-06
📝 Original message:Is there any up to date documentation about TheBlueMatt relay network
including what kind of block compression it is currently doing? (apart from
the source code)
Regards, Sergio.
On Wed, Aug 5, 2015 at 7:14 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 5, 2015 at 9:19 PM, Arnoud Kouwenhoven - Pukaki Corp
> <arnoud at pukaki.bz> wrote:
> > Thanks for this (direct) feedback. It would make sense that if blocks
> can be
> > submitted using ~5kb packets, that no further optimizations would be
> needed
> > at this point. I will look into the relay network transmission protocol
> to
> > understand how it works!
> >
> > I hear that you are saying that this network solves speed of transmission
> > and thereby (technical) block size issues. Presumably it would solve
> speed
> > of block validation too by prevalidating transactions.
>
>
> Correct. Bitcoin Core has cached validation for many years now... if
> not for that and other optimizations, things would be really broken
> right now. :)
>
> > Assuming this is all
> > true, and I have no reason to doubt that at this point, I do not
> understand
> > why there is any discussion at all about the (technical) impact of large
> > blocks, why there are large numbers of miners building on invalid blocks
> > (SPV mining, https://bitcoin.org/en/alert/2015-07-04-spv-mining), or why
> > there is any discussion about the speed of block validation (cpu
> processing
> > time to verify blocks and transactions in blocks being a limitation).
>
> I'm also mystified by a lot of the large block discussion, much of it
> is completely divorced from the technology as deployed; much less what
> we-- in industry-- know to be possible. I don't blame you or anyone in
> particular on this; it's a new area and we don't yet know what we need
> to know to know what we need to know; or to the extent that we do it
> hasn't had time to get effectively communicated.
>
> The technical/security implications of larger blocks are related to
> other things than propagation time, if you assume people are using the
> available efficient relay protocol (or better).
>
> SPV mining is a bit of a misnomer (If I coined the term, I'm sorry).
> What these parties are actually doing is blinding mining on top of
> other pools' stratum work. You can think of it as sub-pooling with
> hopping onto whatever pool has the highest block (I'll call it VFSSP
> in this post-- validation free stratum subpooling). It's very easy to
> implement, and there are other considerations.
>
> It was initially deployed at a time when a single pool in Europe has
> amassed more than half of the hashrate. This pool had propagation
> problems and a very high orphan rate, it may have (perhaps
> unintentionally) been performing a selfish mining attack; mining off
> their stratum work was an easy fix which massively cut down the orphan
> rates for anyone who did it. This was before the relay network
> protocol existed (the fact that all the hashpower was consolidating on
> a single pool was a major motivation for creating it).
>
> VFSSP also cuts through a number of practical issues miners have had:
> Miners that run their own bitcoin nodes in far away colocation
> (>100ms) due to local bandwidth or connectivity issues (censored
> internet); relay network hubs not being anywhere near by due to
> strange internet routing (e.g. japan to china going via the US for ...
> reasons...); the CreateNewBlock() function being very slow and
> unoptimized, etc. There are many other things like this-- and VFSSP
> avoids them causing delays even when you don't understand them or know
> about them. So even when they're easily fixed the VFSSP is a more
> general workaround.
>
> Mining operations are also usually operated in a largely fire and
> forget manner. There is a long history in (esp pooled) mining where
> someone sets up an operation and then hardly maintains it after the
> fact... so some of the use of VFSSP appears to just be inertia-- we
> have better solutions now, but they they work to deploy and changing
> things involves risk (which is heightened by a lack of good
> monitoring-- participants learn they are too latent by observing
> orphaned blocks at a cost of 25 BTC each).
>
> One of the frustrating things about incentives in this space is that
> bad outcomes are possible even when they're not necessary. E.g. if a
> miner can lower their orphan rate by deploying a new protocol (or
> simply fixing some faulty hardware in their infrastructure, like
> Bitcoin nodes running on cheap VPSes with remote storage) OR they can
> lower their orphan rate by pointing their hashpower at a free
> centeralized pool, they're likely to do the latter because it takes
> less effort.
> _______________________________________________
> 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/20150806/0321960d/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply