Nick ODell [ARCHIVE]

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

Public Key

npub192dh6dprqsvsrdeche436s9xunwnlyzpu7jl5j3d83nz62tgznrsnqwur0

Profile Code

nprofile1qqsz4xmaxs3sgxgpkuutu6cagznwfhfljpq70f06fgknce3d995pf3cdemzyf

Author Public Key

npub192dh6dprqsvsrdeche436s9xunwnlyzpu7jl5j3d83nz62tgznrsnqwur0

Show more details

Last Notes

2023-06-09 12:43:41

- reply

📅 Original date posted:2015-07-18
📝 Original message:
>As to BIP62 being out of date, can you point to specific things? They'll get fixed.
Just one thing, actually. The "Block validity" section references
version 3 blocks, but those are already used by the BIP66 softfork.
On Sat, Jul 18, 2015 at 10:50 AM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jul 18, 2015 at 09:25:54AM -0700, Mark Friedenbach wrote:
>> On Sat, Jul 18, 2015 at 9:19 AM, Nick ODell <nickodell at gmail.com> wrote:
>>
>> > There doesn't seem to be any deployment timeline.
>> >
>>
>> Welcome to bitcoin development.
>>
>> At the moment we have only the capability to push out one soft fork vote at
>> a time. The uncontroversial aspects of BIP62 were rushed out as BIP66 in
>> response to an undisclosed vulnerability, as mentioned. I believe there is
>> consensus now that BIP65: CHECKLOCKTIMEVERIFY has higher deployment
>> priority, so it will be next. There is no deployment timeline for BIP62
>> because it is a low priority in this soft-fork logjam.
>
> A slight clarification: we do have the capability to push out more than
> one soft-fork *upgrade signaling* at a time, but this is very far from a
> vote because if miners decide not to upgrade there is no easy way to
> recover. The nVersion bits mechanism I co-authored with Pieter Wuille
> and Gregory Maxwell is closer to a vote because a soft-fork failing to
> go through has a clear and non-coercive outcome.
>
> For instance, if my own BIP65 had been accepted into v0.11.0 miners who
> had upgraded to v0.10.x/0.9.5 would have been signaling that they
> supported BIP66, while sumultaneously miners running v0.11.0 would be
> signalling that they supported both BIP66 and BIP65. As adoption
> increased BIP66 would trigger first, followed by BIP65. (theoretically
> both could trigger on the same block too)
>
> The problem is if miners had decided they didn't like BIP66 but wanted
> to implement BIP65 there would be no mechanism to do that - it depends
> on the details, but from the point of view of at least some nodes you
> likely would have hard-forked Bitcoin in the process of stopping the
> failed soft-fork.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000b675c4d825a10c278b8d63ee4df90a19393f3b6498fd073

2023-06-09 12:43:40

- reply

📅 Original date posted:2015-07-18
📝 Original message:
I'm pretty sure that BIP62 is abandonded. At least, the PR based on it
was never merged. BIP66 implements some of it, and rules 2-7 have been
nonstandard for a while, but I don't think that rules 2-7 are enforced
against new blocks.
On Fri, Jul 17, 2015 at 2:19 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> http://ozlabs.org/~rusty/ln-deploy-draft-01.pdf
>
> I haven't had time to proofread this properly, nor check the
> script examples. But wanted to post it before the weekend so you all
> have something to chew on :)
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:43:40

- reply

📅 Original date posted:2015-07-18
📝 Original message:
There doesn't seem to be any deployment timeline, and the BIP is
incredibly out of date.
I agree that rules 2-7 are nonstandard, but I don't think they're
applied to blocks.
>(details of that are forthcoming soon now that it has been deployed).
I was under the impression that the changes in BIP66 were only
prioritized because asking OpenSSL to verify DER encoding required
building with a specific version of OpenSSL, not because of any
security vulns.
On Sat, Jul 18, 2015 at 9:46 AM, Mark Friedenbach <mark at friedenbach.org> wrote:
> BIP62 is not in any way abandoned. It just takes time to implement such
> broad changes and to be assured of their safety. BIP66 rushed a subset of
> features that were necessary to close we pretty serious vulnerabilities
> (details of that are forthcoming soon now that it has been deployed).
>
> On Jul 18, 2015 08:15, "Nick ODell" <nickodell at gmail.com> wrote:
>>
>> I'm pretty sure that BIP62 is abandonded. At least, the PR based on it
>> was never merged. BIP66 implements some of it, and rules 2-7 have been
>> nonstandard for a while, but I don't think that rules 2-7 are enforced
>> against new blocks.
>>
>> On Fri, Jul 17, 2015 at 2:19 AM, Rusty Russell <rusty at rustcorp.com.au>
>> wrote:
>> > Hi all,
>> >
>> > http://ozlabs.org/~rusty/ln-deploy-draft-01.pdf
>> >
>> > I haven't had time to proofread this properly, nor check the
>> > script examples. But wanted to post it before the weekend so you all
>> > have something to chew on :)
>> >
>> > Cheers,
>> > Rusty.
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:43:33

- reply

📅 Original date posted:2015-07-14
📝 Original message:
>I like to think of fees in the same way as we pay for Internet access.
>Every physical hop in the Internet has related costs, e.g. in placing
>the cables and upgrading the cables when new technology becomes
>available and when demand grows.
What sort of fee would this be? A percentage fee? A per-transaction fee? Both?
I can see a compelling case for any of the three.
On Tue, Jul 14, 2015 at 12:54 PM, CJP <cjp at ultimatestunts.nl> wrote:
>
>> Fees are a real issue. Without source routing the client is guessing
>> how much fees will be, and there'll be a lot of gaming to decide how
>> much of the pie to take (take too much, you get none as payment fails to
>> route). I think you'll end up asking your provider how you should to
>> pay, and that's a pretty horrible model for privacy.
>>
>> With source routing and onion it's a little better; you can explicitly
>> state what each hop gets. Of course, if your route/payment information
>> is out of date you lose, too.
>
> I like to think of fees in the same way as we pay for Internet access.
> Every physical hop in the Internet has related costs, e.g. in placing
> the cables and upgrading the cables when new technology becomes
> available and when demand grows. Yet it doesn't matter for your Internet
> bill how many hops your packets make, or which route they follow. Your
> ISP will just average out all the costs it has to make on its
> interfaces, and present a fraction of that to each customer. At some
> points in the middle between providers, there are places where both
> sides have an equal interest in maintaining their link, and no fees are
> charged.
>
> One major difference with the Internet is that we already have a
> micro-transaction infrastructure in place, which is something the
> Internet has never had (until now). This means it is possible to do
> instant per-transaction payment of transaction fees. The fact that we
> CAN do it doesn't mean we SHOULD, but I think there are advantages:
> non-immediate payment models always require some form of trust from at
> least one of the sides. Immediate payment of a transaction fee is as
> simple as updating the micro-transaction channel with a slightly larger
> amount than the to-be-forwarded transaction amount.
>
> An interesting question is whether nodes will be prepared to forward
> payments at a net loss (the to-be-paid fee is higher than the
> to-be-received fee); maybe they will, if they can compensate the losses
> with higher profits on other transactions. Fee differences could play a
> role in routing decisions.
>
> That brings me to another point: fees could be used as a way to
> incentivize people to bring channels back to equilibrium. When a
> channel's funds are almost fully assigned to one of its sides, further
> payments towards that side become nearly impossible. Increasing fees in
> that direction and decreasing fees in the opposite direction should
> incentivize people to perform more transactions that bring the channel
> back to equilibrium, and to perform less transactions that bring it
> further out of equilibrium, or find alternative routes for those
> transactions.
>
> You could even offer negative fees for transactions that bring a channel
> back to equilibrium. There could be a market for people making money
> from bringing other peoples' channels back to equilibrium. This would
> require either to step away from "net neutrality" (so, not the same fee
> for every route / destination), or it would require some form of source
> routing and explicitly setting the fees of intermediate nodes.
>
> My "neutral meeting point" routing design, which is effectively a
> two-hop source routing, is already good enough: a node in the middle of
> the network is advertising that it can benefit from a negative fee, and
> it invites people to perform transactions and to share the profit. It
> creates two routable addresses (one for the negative-fee interface (A)
> and one for all other interfaces (B)). Other people can then perform a
> payment-to-self, with payee side routing to A and payer-side routing to
> B. Payee-side can then have a larger payment amount than payer-side, as
> agreed with the meeting point, to transfer a part of the profit to the
> person performing the transaction.
>
> CJP
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 12:43:30

- reply

📅 Original date posted:2015-07-01
📝 Original message:
>(how would they be discovered?)
Two major ways I can see:
* Each Lightning node keeps track of peers it has seen, and provides part
of this list to anyone who asks. Directory authorities run spiders, like
the one at getaddr.bitnodes.io. This could be overlaid onto the Bitcoin
protocol by setting one of the service bits when the node is an active
lightning processor. (getaddr approach)
* Your node tells all of the directory authorities it knows about itself.
(Tor approach)
>One difference here between Tor and Lightening is that "verifying
connectivity" on the Lightening network is not as simple as connecting to a
Tor node.
I think the two of those are similar. Tor can detect various sorts of
accidental connectivity issues. For example, if you tell Tor in its config
file that it has a gigabit connection, and it doesn't, it will figure that
out by itself. However, the most important kind of intentional misbehavior,
logging connections, cannot be detected remotely.
Lightning is similar. We can detect when someone's internet connection goes
down. We can detect (with some plumbing) when their Bitcoin node is not
synchronized yet. But we can't detect the most important kind of
intentional misbehavior, stealing money, without actually sending money
through the network.
(Or someone else trying to send money, and complaining when it doesn't go
through. That would work better if the sender of the payment had some kind
of log of signed statements made by the nodes involved, though.)
>From a privacy perspective, active scanning (sending money through the
network yourself) is much easier to secure than passive scanning (acting on
an audit log of someone whose payments got stolen.)
>For example, in the ABCD example, what if C decides to attack only
payments that come from B? It could be non-malicious if C just had a
datacenter fire or something that took out the keys and tx data associated
with their channel with B.
It doesn't seem like you can catch everybody who's selectively scamming
through active scanning. For example, if someone stole one out of every
million payments, the directories would never notice. Personally, I'd more
worried about someone trying to defeat active scanning by fingerprinting
wallet software. (e.g. this wallet software always puts zero in this field,
or this directory authority always connects from Tor addresses.)
WRT the non-malicious example: It seems like a non-malicious node would ask
for the channel to be closed ASAP, if it no longer remembered the data that
would show who owned what. This would still leave the payments that it was
processing just before the data loss in limbo, though, so that's not a
cure-all.
>Anyways, if the directory nodes didn't test every possible route through
the network (which has exponential complexity), then I don't think they
could reliably tell you if C is trustworthy or not.
I don't think they need to test every route. In the ABCD example, the only
nodes that C should know about are B and D. Therefore, the routes EBCD and
ABCD are equivalent from C's point of view.
That's still superlinear, though.
On Wed, Jul 1, 2015 at 12:19 PM, Kevin Greene <kgreenek at gmail.com> wrote:
> Interesting. It sounds like Joseph may have a solution already, but as a
> thought experiment I'm curious how directory nodes could work with the
> lightening network. I guess you would have a set of such authorities that
> open payment channels with all known lightening processors (how would they
> be discovered?), and have a protocol for periodically moving money back and
> forth to verify connectivity. One difference here between Tor and
> Lightening is that "verifying connectivity" on the Lightening network is
> not as simple as connecting to a Tor node. For example, in the ABCD
> example, what if C decides to attack only payments that come from B? It
> could be non-malicious if C just had a datacenter fire or something that
> took out the keys and tx data associated with their channel with B.
> Anyways, if the directory nodes didn't test every possible route through
> the network (which has exponential complexity), then I don't think they
> could reliably tell you if C is trustworthy or not.
>
> On Wed, Jul 1, 2015 at 9:55 AM, Nick ODell <nickodell at gmail.com> wrote:
>
>> >There is no such central processor though in this case to enforce the
>> reputation of lightening nodes.
>>
>> There's no reason why there couldn't be.
>>
>> Tor, for example, has nine "directory authorities." They attempt to reach
>> nodes in the Tor network, and record whether they're available. Then, they
>> vote among themselves to produce a directory consensus, and they all sign
>> it. Lightning could use a similar system. Unlike Tor, we don't need to
>> require everyone to use the same directory authorities, either.
>>
>> On Wed, Jul 1, 2015 at 10:53 AM, Nick ODell <nickodell at gmail.com> wrote:
>>
>>> >There is no such central processor though in this case to enforce the
>>> reputation of lightening nodes.
>>>
>>> There's no reason why there couldn't be.
>>>
>>> Tor, for example, has nine "directory authorities." They attempt to
>>> reach nodes in the Tor network, and record whether they're available. Then,
>>> they vote among themselves to produce a directory consensus, and they all
>>> sign it. Lightning could use a similar system. Unlike Tor, we don't need to
>>> require everyone to use the same directory authority, either.
>>>
>>> On Wed, Jul 1, 2015 at 10:31 AM, Kevin Greene <kgreenek at gmail.com>
>>> wrote:
>>>
>>>> Blargh. The dumb solution here is to just shrug and say that you have
>>>> to trust these processors to be highly available, and never try to do
>>>> re-routing. That's pretty much equivalent to what would happen if one of
>>>> the banks in the visa network had networking issues for example.
>>>>
>>>> The big difference here though is that visa will kick you out of the
>>>> network if you're a bank that's consistently not meeting their
>>>> strict SLA's, and that keeps the network honest. There is no such central
>>>> processor though in this case to enforce the reputation of lightening
>>>> nodes.
>>>>
>>>>
>>>>
>>>> On Monday, June 29, 2015, Stephen Morse <stephencalebmorse at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Rusty,
>>>>>
>>>>> On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell <rusty at rustcorp.com.au>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Yes, C can just get the preimage from E and collude to steal the
>>>>>> funds,
>>>>>> which is a nasty failure mode.
>>>>>>
>>>>>>
>>>>> This scenario may even happen non-maliciously, if C has an honest
>>>>> outage and attempts to pick up where it left off on each of its channels.
>>>>> To fix the non-malicious case, C could get a refund from E (a new signed
>>>>> transaction with a lower lock time), if C knows he has been offline for
>>>>> longer than B's willingness to wait before re-routing. But this isn't
>>>>> perfect, or even good, because E cannot know that C isn't just trying to
>>>>> get a refund even though they have taken the payment from B. In fact, C is
>>>>> guaranteed the payment from B, since they have the pre-image.
>>>>>
>>>>>
>>>>>> Delaying the entire payment is a poor option; can anyone see a better
>>>>>> one?
>>>>>>
>>>>>
>>>>> Like you say, delaying the payment seems like a bad way to go, as then
>>>>> the payments wouldn't be quite "Lightning" fast anymore. 99% of the payment
>>>>> could be re-routed though. Perhaps the 99% could be re-routed, while A
>>>>> waits for C to rejoin. Or if multiple paths are being used to process the
>>>>> payment, just redistribute the remaining payments allotted for the broken
>>>>> path among the other functioning paths.
>>>>>
>>>>> The bigger problem here seems to be that the incentives are slightly
>>>>> skewed in favor of dishonestly. One can minimize the impact of that
>>>>> dishonesty by breaking the payment into smaller chunks and across diverse
>>>>> paths, but this comes at the cost of bandwidth and speed. Some sort of a
>>>>> rating system could come into play possibly, if nothing can be
>>>>> cryptographically worked out.
>>>>>
>>>>> Best,
>>>>> Stephen
>>>>>
>>>>
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150701/04e5f863/attachment.html>

2023-06-09 12:43:29

- reply

📅 Original date posted:2015-07-01
📝 Original message:
>There is no such central processor though in this case to enforce the
reputation of lightening nodes.
There's no reason why there couldn't be.
Tor, for example, has nine "directory authorities." They attempt to reach
nodes in the Tor network, and record whether they're available. Then, they
vote among themselves to produce a directory consensus, and they all sign
it. Lightning could use a similar system. Unlike Tor, we don't need to
require everyone to use the same directory authorities, either.
On Wed, Jul 1, 2015 at 10:53 AM, Nick ODell <nickodell at gmail.com> wrote:
> >There is no such central processor though in this case to enforce the
> reputation of lightening nodes.
>
> There's no reason why there couldn't be.
>
> Tor, for example, has nine "directory authorities." They attempt to reach
> nodes in the Tor network, and record whether they're available. Then, they
> vote among themselves to produce a directory consensus, and they all sign
> it. Lightning could use a similar system. Unlike Tor, we don't need to
> require everyone to use the same directory authority, either.
>
> On Wed, Jul 1, 2015 at 10:31 AM, Kevin Greene <kgreenek at gmail.com> wrote:
>
>> Blargh. The dumb solution here is to just shrug and say that you have to
>> trust these processors to be highly available, and never try to do
>> re-routing. That's pretty much equivalent to what would happen if one of
>> the banks in the visa network had networking issues for example.
>>
>> The big difference here though is that visa will kick you out of the
>> network if you're a bank that's consistently not meeting their
>> strict SLA's, and that keeps the network honest. There is no such central
>> processor though in this case to enforce the reputation of lightening
>> nodes.
>>
>>
>>
>> On Monday, June 29, 2015, Stephen Morse <stephencalebmorse at gmail.com>
>> wrote:
>>
>>> Hi Rusty,
>>>
>>> On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell <rusty at rustcorp.com.au>
>>> wrote:
>>>
>>>>
>>>> Yes, C can just get the preimage from E and collude to steal the funds,
>>>> which is a nasty failure mode.
>>>>
>>>>
>>> This scenario may even happen non-maliciously, if C has an honest outage
>>> and attempts to pick up where it left off on each of its channels. To fix
>>> the non-malicious case, C could get a refund from E (a new signed
>>> transaction with a lower lock time), if C knows he has been offline for
>>> longer than B's willingness to wait before re-routing. But this isn't
>>> perfect, or even good, because E cannot know that C isn't just trying to
>>> get a refund even though they have taken the payment from B. In fact, C is
>>> guaranteed the payment from B, since they have the pre-image.
>>>
>>>
>>>> Delaying the entire payment is a poor option; can anyone see a better
>>>> one?
>>>>
>>>
>>> Like you say, delaying the payment seems like a bad way to go, as then
>>> the payments wouldn't be quite "Lightning" fast anymore. 99% of the payment
>>> could be re-routed though. Perhaps the 99% could be re-routed, while A
>>> waits for C to rejoin. Or if multiple paths are being used to process the
>>> payment, just redistribute the remaining payments allotted for the broken
>>> path among the other functioning paths.
>>>
>>> The bigger problem here seems to be that the incentives are slightly
>>> skewed in favor of dishonestly. One can minimize the impact of that
>>> dishonesty by breaking the payment into smaller chunks and across diverse
>>> paths, but this comes at the cost of bandwidth and speed. Some sort of a
>>> rating system could come into play possibly, if nothing can be
>>> cryptographically worked out.
>>>
>>> Best,
>>> Stephen
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150701/83839504/attachment.html>

2023-06-07 18:04:48

- reply

📅 Original date posted:2017-08-16
📝 Original message:What makes this approach better than the prune option of Bitcoin?
On Wed, Aug 16, 2017 at 10:20 AM, Алексей Мутовкин via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Let me describe the possible improvement of the bitcoin blockchain
> database (BBD) size in general terms.
>
> We can implement new routine : annual split of the BBD. Reason is that
> 140gb full wallet unconvinience.
>
> BBD splits in two parts :
> 1) old blocks before the date of split and
> 2) new blocks, starting from first technical block with all rolled totals
> on the date of split.
> (also possible transfer of tiny totals due to their unprofitability to
> the miners, so we cut long tail of tiny holders)
> 3) old blocks packs into annual megablocks and stores in the side archive
> chain for some needs for FBI investigations or other goals.
>
>
> Thanks for your attention,
>
> Alexey Mutovkin
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20170816/394d6a3f/attachment.html>

2023-06-07 18:04:44

- reply

📅 Original date posted:2017-08-09
📝 Original message:Colin,
1) This is a good start for a BIP, but it's missing details. For example,
the nonce is encrypted by the server. What key is it encrypted with?
Clarifying ambiguities like this can sometimes reveal weaknesses that you
wouldn't otherwise think of.
2) What kind of recovery questions are asked? If it's something like "What
was the name of your first pet?" then what prevents the server from
stealing the wallet by trying a dictionary of the most common pet names? Is
there a mitigation to this, besides picking cryptographically secure
identifiers for my pets?
--Nick
On Wed, Aug 9, 2017 at 12:49 PM, Colin Lacina via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I believe I have come up with a structure that allows for trustless use of
> hybrid wallets that would allow for someone to use a hybrid wallet without
> having to trust it while still allowing for emergency recovery of funds in
> the case of a lost wallet. It would run off of this TX script:
>
> IF
> 1 <clientRecoveryPubKey> <serverRecoveryPubKey> 2 CHECKMULTISIGVERIFY
> ELSE
> 2 <userWalletPubKey> <serverWalletPubKey> 2 CHECKMULTISIG
> ENDIF
>
> A typical transaction using this would involve a user signing a TX with
> their userWalletPrivKey, authenticating with the server, possibly with 2FA
> using a phone or something like Authy or Google Authenticator. After
> authentication, the server signs with their serverWalletPrivKey.
>
> In case the server goes rogue and starts refusing to sign, the user can
> use their userRecoveryPrivKey to send the funds anywhere they choose.
> Because if this, the userRecoveryPrivKey is best suited to cold wallet
> storage.
>
> In the more likely event that the user forgets their password and/or
> looses access to their userWalletPrivKey as well as loses their recovery
> key, they rely on the serverRecoveryPrivKey.
>
> When the user first sets up their wallet, they answer some basic identity
> information, set up a recovery password, and/or set up recovery questions
> and answers. This information is explicitly NOT sent to serve with the
> exception of recovery questions (although the answers remain with the user,
> never seeing the server). What is sent to the server is it's 256 bit hash
> used to identify the recovery wallet. The server then creates a 1025 bit
> nonce, encrypts it, stores it, and transmits it to the user's client.
>
> Meanwhile, the user's wallet client generates the serverRecoveryPrivKey.
>
> Once the client has both the serverRecoveryPrivKey, and the nonce, it uses
> SHA512 on the combination of the identity questions and answers, the
> recovery password (if used), the recovery questions and answers, and the
> nonce. It uses the resulting hash to encrypt the serverRecoveryPrivKey.
>
> Finally, the already encrypted key is encrypted again for transmission to
> the server. The server decrypts it, then rencrypts it for long term storage.
>
> When the user needs to resort to using this option, they 256 bit hash
> their information to build their recovery identifier. The server may,
> optionally, request e-mail and or SMS confirmation that user is actually
> attempting the recovery.
>
> Next, the server decrypts the saved nonce, as well as the first layer of
> encryption on the serverRecoveryPrivKey, then encrypts both for
> transmission to the user's client. Then the client removes the transmission
> encryption, calculates the 512 bit hash that was used to originally encrypt
> the serverRecoveryPrivKey by using the provided information and the nonce.
>
> After all of that the user can decrypt the airbitzServerRecoveryPrivKey
> and use it to send a transaction anywhere they choose.
>
> I was thinking this may make a good informational BIP but would like
> feedback.
>
> _______________________________________________
> 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/20170809/684da748/attachment-0001.html>

2023-06-07 17:57:45

- reply

📅 Original date posted:2017-03-24
📝 Original message:Two concerns:
1) This makes block validity depend on things that aren't in the
blockchain. If you and I have different minrelaytxfee's, we will have
different mempool sizes. Your node will discard a block, but my node will
think it is valid, and our nodes will not come to consensus.
2) This is trivially bypassed. A miner can take some coins they own
already, and create a zero-value transaction that has a scriptPubKey of
OP_1. (i.e. anyone-can-spend.) Then, they create another transaction
spending the first transaction, with an empty scriptSig, and the same
scriptPubKey. They do this over and over until they fill up the block.
The last OP_1 output can be left for the next miner. Since the above
algorithm is deterministic, a merkle tree containing every transaction
except the coinbase can be precomputed. The 'malicious' miners do not need
to store this fake block.
On Fri, Mar 24, 2017 at 10:03 AM, CANNON via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> blocks, the worst case scenario is a hardfork coin split in which
> the non-compliant chain becomes an alt. However the problem is that
> this malicious miner is very recently threatening to not just simply
> fork, but to kill the valid chain to force economic activity to the
> adversary controlled chain. If we can simply defend against attacks
> to the valid chain, we can prevent the valid chain from dying.
>
> While empty or near empty blocks would generally be protected by
> the incentive of miners to make money. The threat is there if the
> malicious miner with majority control is willing to lose out on
> these transaction fees and block reward if their intention is to
> suppress it to force the majority onto their chain.
>
> Proposal for potential solution Update nodes to ignore empty blocks,
> so this way mined empty blocks cannot be used to DOS attack the
> blockchain. But what about defense from say, blocks that are
> not empty but intentionally only have a couple transactions
> in it? Possible to have nodes not only ignore empty blocks,
> but also blocks that are abnormally small compared to number of
> valid transactions in mempool?
>
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example.
>
> What would be any potentials risks
> and attacks resulting from both having such new rulesets and not
> doing anything?
>
> Lets assume that the first problem of blocking empty or near empty
> blocks has been mitigated with the above proposed solution. How
> likely and possible would it be for a malicious miner with lots of
> mining power to orphan the chain after so many blocks even with
> non empty blocks? Is there a need to mitigate this?
> If so is it possible?
>
> Time is running short I fear. There needs to be discussion on various
> attacks and how they can be guarded against along with various
> other contingency plans.
>
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon at cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
> D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
> V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
> WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
> TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
> S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
> z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
> LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
> 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
> DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
> jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
> Gu3oWoE1ld+BC6At28AD
> =SSuj
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20170324/3ff30b51/attachment.html>

2023-06-07 17:57:25

- reply

📅 Original date posted:2017-03-20
📝 Original message:Chain work currently means the expected number of sha256d evaluations
needed to build a chain. Given that these hash functions are not equally
hard, what should the new definition of chain work be?
On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> By doing this you're significantly changing the economic incentives behind
> bitcoin mining. How can you reliably invest in hardware if you have no idea
> when or if your profitability is going to be cut by 50-75% based on a whim?
>
> You may also inadvertently create an entirely new attack vector if 50-75%
> of the SHA256 hardware is taken offline and purchased by an entity who
> intends to do harm to the network.
>
> Bitcoin only works if most miners are honest, this has been known since
> the beginning.
>
> On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I’m very worried about the state of miner centralisation in Bitcoin.
>>
>> I always felt the centralising effects of ASIC manufacturing would
>> resolve themselves once the first mover advantage had been exhausted and
>> the industry had the opportunity to mature.
>>
>> I had always assumed initial centralisation would be harmless since
>> miners have no incentive to harm the network. This does not consider the
>> risk of a single entity with sufficient power and either poor, malicious or
>> coerced decision making. I now believe that such centralisation poses a
>> huge risk to the security of Bitcoin and preemptive action needs to be
>> taken to protect the network from malicious actions by any party able to
>> exert influence over a substantial portion of SHA256 hardware.
>>
>> Inspired by UASF, I believe we should implement a Malicious miner
>> Reactive Proof of Work Additions (MR POWA).
>>
>> This would be a hard fork activated in response to a malicious attempt by
>> a hashpower majority to introduce a contentious hard fork.
>>
>> The activation would occur once a fork was detected violating protocol
>> (likely oversize blocks) with a majority of hashpower. The threshold and
>> duration for activation would need to be carefully considered.
>>
>> I don’t think we should eliminate SHA256 as a hashing method and change
>> POW entirely. That would be throwing the baby out with the bathwater and
>> hurt the non-malicious miners who have invested in hardware, making it
>> harder to gain their support.
>>
>> Instead I believe we should introduce multiple new proofs of work that
>> are already established and proven within existing altcoin implementations.
>> As an example we could add Scrypt, Ethash and Equihash. Much of the code
>> and mining infrastructure already exists. Diversification of hardware (a
>> mix of CPU and memory intensive methods) would also be positive for
>> decentralisation. Initial difficulty could simply be an estimated portion
>> of existing infrastructure.
>>
>> This example would mean 4 proofs of work with 40 minute block target
>> difficulty for each. There could also be a rule that two different proofs
>> of work must find a block before a method can start hashing again. This
>> means there would only be 50% of hardware hashing at a time, and a sudden
>> gain or drop in hashpower from a particular method does not dramatically
>> impact the functioning of the network between difficulty adjustments. This
>> also adds protection from attacks by the malicious SHA256 hashpower which
>> could even be required to wait until all other methods have found a block
>> before being allowed to hash again.
>>
>> 50% hashing time would mean that the cost of electricity in relation to
>> hardware would fall by 50%, reducing some of the centralising impact of
>> subsidised or inexpensive electricity in some regions over others.
>>
>> Such a hard fork could also, counter-intuitively, introduce a block size
>> increase since while we’re hard forking it makes sense to minimise the
>> number of future hard forks where possible. It could also activate SegWit
>> if it hasn’t already.
>>
>> The beauty of this method is that it creates a huge risk to any malicious
>> actor trying to abuse their position. Ideally, MR POWA would just serve as
>> a deterrent and never activate.
>>
>> If consensus were to form around a hard fork in the future nodes would be
>> able to upgrade and MR POWA, while automatically activating on non-upgraded
>> nodes, would be of no economic significance: a vestigial chain immediately
>> abandoned with no miner incentive.
>>
>> I think this would be a great way to help prevent malicious use of
>> hashpower to harm the network. This is the beauty of Bitcoin: for any road
>> block that emerges the economic majority can always find a way around.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
> Andrew Johnson
>
>
> _______________________________________________
> 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/20170320/873357b6/attachment-0001.html>

2023-06-07 17:57:15

- reply

📅 Original date posted:2017-03-13
📝 Original message:The problem with modifying Bitcoin to work around community norms is that
it's a two-way street. Other people can do it too.
Let me propose a counter-fork, or a "Double UASF." This is also a BIP9
fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is
1506812400. It enforces every rule that UASF enforces, plus one additional
rule. If 60% of blocks in any retargeting period signal for Double UASF,
any descendant block that creates or spends a segregated witness output is
invalid.
Double UASF signaling never coincides with UASF signaling, because the
signaling periods don't overlap. Full nodes happily validate the chain,
because Double UASF doesn't break any rules; it just adds new ones. Miners
who adopt Double UASF don't need to understand segwit, because all segwit
transactions are banned. Miners don't need to commit to a wtxid structure,
either. Per BIP 141, "If all transactions in a block do not have witness
data, the commitment is optional." Segwit is activated, but useless. Miners
who *do* adopt segwit will lose money, as their blocks are orphaned.
Thanks,
--Nick
On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I recently posted about so called "user activated soft forks" and received
> a lot of feedback. Much of this was how such methodologies could be applied
> to segwit which appears to have fallen under the miner veto category I
> explained in my original proposal, where there is apparently a lot of
> support for the proposal from the economy, but a few mining pools are
> vetoing the activation.
>
> It turns out Bitcoin already used flag day activation for P2SH[1
> <https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283>],
> a soft fork which is remarkably similar to segwit. The disadvantage of a
> UASF for segwit is there is an existing deployment. A UASF would require
> another wide upgrade cycle (from what I can see, around 80% of existing
> nodes have upgraded from pre-witness, to NODE_WITNESS capability[2
> <http://luke.dashjr.org/programs/bitcoin/files/charts/services.html>][3
> <https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/>].
> While absolute node count is meaningless, the uprgrade trend from version
> to version seems significant.
>
> Also it is quite clear a substantial portion of the ecosystem industry has
> put in time and resources into segwit adoption, in the form of upgrading
> wallet code, updating libraries and various other integration work that
> requires significant time and money. Further more, others have built
> systems that rely on segwit, having put significant engineering resources
> into developing systems that require segwit - such as several lightning
> network system. This is much more significant social proof than running a
> node.
>
> The delayed activation of segwit is also holding back a raft protocol of
> innovations such as MAST, Covenants, Schnorr signature schemes and
> signature aggregation and other script innovations of which, much of the
> development work is already done.
>
> A better option would be to release code that causes the existing segwit
> deployment to activate without requiring a completely new deployment nor
> subject to hash power veto. This could be achieved if the economic majority
> agree to run code that rejects non-signalling segwit blocks. Then from the
> perspective of all existing witness nodes, miners trigger the BIP9
> activation. Such a rule could come into effect 4-6 weeks before the BIP9
> timeout. If a large part of the economic majority publicly say that they
> will adopt this new client, miners will have to signal bip9 segwit
> activation in order for their blocks to be valid.
>
> I have drafted a BIP proposal so the community may discuss
> https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full
> text below).
>
> References:
> [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/
> src/main.cpp#L1281-L1283
> [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
> [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/
> evidence_of_widespread_segwit_support_near50_of/
>
> Proposal text:
>
> <pre>
> BIP: bip-segwit-flagday
> Title: Flag day activation for segwit deployment
> Author: Shaolin Fry <shaolinfry at protonmail.ch>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Informational
> Created: 2017-03-12
> License: BSD-3-Clause
> CC0-1.0
> </pre>
>
> ==Abstract==
>
> This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit".
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147.
>
> ==Motivation==
>
> Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017.
>
> ==Specification==
>
> All times are specified according to median past time.
>
> This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates.
>
> While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.
>
> === Reference implementation ===
>
> <pre>
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive
> if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) {
> return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
> </pre>
>
> ==Backwards Compatibility==
>
> This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.
>
> ==Rationale==
>
> Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues
>
> By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment.
>
> ==References==
>
> [https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation].
>
> ==Copyright==
>
> This document is placed in the public domain.
>
>
>
>
> _______________________________________________
> 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/20170312/0838954e/attachment-0001.html>

2023-06-07 17:57:14

- reply

📅 Original date posted:2017-03-13
📝 Original message:>time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
This has a different start time from the first post.
>if (pindex->GetMedianTimePast() >= 1538352000 &&
pindex->GetMedianTimePast() <= 1510704000 ...
Thanks,
--Nick
On Mon, Mar 13, 2017 at 4:36 AM, shaolinfry via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> From: luke at dashjr.org
> On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:
> > // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017
> > inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&
> > pindex->GetMedianTimePast() <= 1510704000 &&
> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
> > if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> > VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,
> > Consensus::DEPLOYMENT_SEGWIT)) != 0) {
> > return state.DoS(2, error("ConnectBlock(): relayed block must
> > signal for segwit, please upgrade"), REJECT_INVALID,
> > "bad-no-segwit");
> > }
> > }
>
> I don't think this is actually BIP 9 compatible. Once activated, the bit
> loses
> its meaning and should not be set. So you need to check that it hasn't
> locked-
> in already...
>
>
> I believe that is handled.
>
> time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
>
> Signalling is only required from October 1st until the BIP9 timeout, or,
> until segwit is activated. The bit becomes free after activation/timeout as
> per BIP9. Also, the default behaviour of BIP9 in Bitcoin Core is to signal
> through the LOCKED_IN period - it would be trivial to add a condition to
> not require mandatory signalling during LOCKED_IN but since miners signal
> by default during this period, I figured I would leave it.
>
> I thought about 5% tolerance. but I don't think it makes sense since
> miners will already have plenty of warning this is coming up and the intent
> of the mandatory signalling period is quite clear. It also seems a bit
> weird to say "it's mandatory but not for 5%". If miners are required to
> signal, they need to signal. It also adds unnecessary complexity to an
> otherwise simple patch.
>
> That said, I have no strong feelings either way on both counts, but I
> chose to present the simplest option first.
>
> _______________________________________________
> 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/20170313/1488d886/attachment.html>

2023-06-07 17:57:03

- reply

📅 Original date posted:2017-03-05
📝 Original message:>I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).
I don't think that's true. Say there are two forks of Blahcoin. Alice
thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
55% chance that Fork B will succeed. Alice trades all of her Fork B coins
for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
fork or the other succeeding. Alice starts spending more time around Fork A
users; Bob starts spending his time with Fork B users.
A year passes, and Alice and Bob meet again. Bob tells Alice that Fork B
has been doing much better than Fork A, and is trading at ten times the
price. Alice replies that it doesn't matter, since Fork B will soon split
into B1 and B2. After all, if Fork B surrendered its principles once, it
can do so again. Bob replies that Fork B represents the true spirit of
Blahcoin. Alice replies that all of the people whose opinion she respects
believe that Fork B violates principles set down by the Founder (peace be
upon him.)
Bob disagrees, and cites an annotated collection of the Founder's writings,
which clearly show that if a situation like what provoked the Great Fork
happens, Fork B is in the right. All of the people Bob knows (except Alice)
agree that this shows Fork A is invalid. Alice replies that Bob is
committing the bandwagon fallacy; even if a thousand people believe that
red is green, that does not make it true. Also, the collection takes
several of the Founder's comments out of context. If one looks at comments
made prior to the release of Blahcoin, they lay out a framework that
envisions Fork A. Bob replies that Alice can't use statements made prior to
the release of Blahcoin to establish original intent; the system hadn't
been designed yet.
Bob points out that Fork B has a higher total chainwork. Alice scoffs. She
posits a Fork C, which is exactly like Fork A, except that chainwork is
defined to be the previous definition plus a quadrillion. Bob finds that
ridiculous. Fork C would transgress upon intrinsic principles of Blahcoin.
No more than Fork B does, Alice replies.
----
Each sentence above is true from some point of view. Each person sincerely
believes in the rightness of their position. Is there some objective
measure, that both Alice and Bob can agree on, that resolves this? I don't
think there is. Bob and Alice will sneer at each other for being idiots
forever. The schism will never resolve.
Satoshi Bless,
--Nick
On Sun, Mar 5, 2017 at 11:10 AM, David Vorick via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I also think that the UASF is a good idea. Hashrate follows coin price. If
> the UASF has the higher coin price, the other chain will be annihilated. If
> the UASF has a lower coin price, the user activated chain can still exist
> (though their coins can be trivially stolen on the majority chain).
>
> The success of the UASF depends entirely on the price. And actually, the
> price is easy to manipulate. If you, as an economically active full node,
> refuse to acknowledge the old chain and demand that incoming coins arrive
> over the UASF chain. In doing so, you drive down the utility of the old
> chain and drive up the utility of the new chain. This ultimately impacts
> the price.
>
> I think it would be pretty easy to get high confidence of the success of a
> UASF. Basically you need all the major economic hubs to agree to upgrade
> and then exclusively accept UASF coins. I don't have a comprehensive list,
> but if we could sign on 75% of the major exchanges and payment processors,
> and get 75% of the wallets to upgrade, then the UASF would be very likely
> to successfully obliterate the old rules, as miners would be unable to sell
> their coins or pay their bills by stubbornly sticking to the old chain.
> It's less risky than a hard fork by far, because there is zero risk of coin
> split if the UASF has majority hashrate, which will follow majority
> economic value.
>
> A serious proposal I think would get all the code ready and merged, but
> without setting a flag day. Then we would get signatures from the major
> institutions promising to use the software and saying that they are ready
> for a flag day. After that, you release a patch with a flag day 12 months
> in the future. People can upgrade immediately, and have a full year to
> transition.
>
> That gives tons of time for people to upgrade, and tons of confidence that
> the UASF will end up as the majority chain.
>
> If we cannot get enough major exchanges, payment processors, and other
> economic hubs to upgrade, the flag day should remain upset, as the risk of
> coin split will be non-zero.
>
> I would suggest that a carefully executed UASF is much riskier than a soft
> fork, but far, far less risky than a hard fork.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170305/59946aef/attachment.html>

2023-06-07 17:55:02

- reply

📅 Original date posted:2016-12-23
📝 Original message:The first issue is that doing two OP_SWAP's in a row will just return
you to the original state. The second issue is that all of them end up
hashing the same key, so anyone on the network can spend this output.
(See https://en.bitcoin.it/wiki/Script for a good resource on opcodes
and what each of them do. There are also a few simulators floating
around, but I can't recommend any in particular.)
Third, if you're concerned about exposing public keys, why not use a
P2SH script? That won't expose your public keys until you spend from
it.
On Thu, Dec 22, 2016 at 11:29 AM, Andrew via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi
>
> Is there a worked out scriptPubKey for doing multisig with just hashes
> of the participants? I think it is doable and it is more secure to a
> compromised ECDSA. I'm thinking something like this for the
> scriptPubKey:
> 2 OP_SWAP OP_SWAP OP_SWAP OP_DUP OP_HASH160 <pubKeyHash1>
> OP_EQUALVERIFY OP_DUP OP_HASH160 <pubKeyHash2> OP_EQUALVERIFY OP_DUP
> OP_HASH160 <pubKeyHash3> OP_EQUALVERIFY 3 OP_CHECKMULTISIG
>
> and <sigs><pubkeys> for the scriptSig
>
> Can anyone confirm or send me a link to the worked out script?
>
> Thanks
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:53:55

- reply

📅 Original date posted:2016-10-14
📝 Original message:Pledging to not use patents offensively defeats the point of owning patents.
The point of owning a patent is so that you can use it offensively, either to
prevent competition, or get licensing fees.
Obtaining a patent for defense doesn't make sense. The litigants you need to
worry about do not produce or make anything. Their 'product' is patent lawsuits.
Unless you have a patent on using a mail-merge program to sue people, your
defensive patents are useless in that situation.
On Fri, Oct 14, 2016 at 4:57 AM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Oct 14, 2016 at 07:38:07AM -0300, Sergio Demian Lerner via bitcoin-dev wrote:
>> 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.
>
> Glad to hear you're taking a conservative approach.
>
> So I assume Rootstock is going to do something stronger then, like
> Blockstream's DPL + binding patent pledge to only use patents defensively?
>
> https://www.blockstream.com/about/patent_pledge/
>
> Because if not, the DPL is still better than the status quo.
>
>> 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.
>
> Indeed. However, you're also free to adopt the DPL irrevocably by additionally
> stating that you will never invoke that 180-day notice provision (or more
> humorously, make it a 100 year notice period to ensure any patents expire!).
>
> If you're concerned about this problem, I'd suggest that Rootstock do exactly
> that.
>
>> 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.
>
> To be clear, modulo the revocability provision, it's a danger mainly to those
> who are unwilling to adopt the DPL themselves, perhaps because they support
> software 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.
>
> 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]. The simple fact is we can't rely solely on voluntary
> disclosure - your own behavior is a perfect example of why not.
>
> [1]: BIP: https://github.com/BlockheaderNonce2/bitcoin/wiki
> [2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=en
> [3]: Extra nonce pull request: https://github.com/bitcoin/bitcoin/pull/5102
>
>> 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.
>
> A serious problem here is the definition of "Bitcoin users". Does Bitcoin
> Classic count? Bitcoin Unlimited? What if Bitcoin forks?
>
> Better to grant _everyone_ a irrevocable license.
>
>
> Along those lines, it'd be reasonable to consider changing the Bitcoin Core
> license to something like an Apache2/LGPL3 dual license to ensure the copyright
> license also has anti-patent protections.
>
> --
> 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
>

2023-06-07 17:53:22

- reply

📅 Original date posted:2016-09-17
📝 Original message:Then you have a new problem. Hash1 must contain Hash2 and the
transaction, but Hash2 must contain Hash1 and the transaction. A
circular dependency.
--Nick
On Sat, Sep 17, 2016 at 3:14 PM, Rune K. Svendsen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I hadn't thought of that... There is a solution, I think, but it makes the
> operation less simple.
>
> If a transaction contains at least two OP_TXHASHVERIFY-protected inputs,
> signed without ANYONECANPAY, their signatures would cover the other input's
> OP_TXHASHVERIFY hash, right?
>
>
> /Rune
>
>
> On Sat, Sep 17, 2016 at 10:56 PM, Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>>
>> (removing the list)
>>
>> Because the tx hash in your construction is not signed, someone wishing to
>> maleate a transaction may do so by also updating the hash in the scriptSig.
>>
>> Matt
>>
>> On September 17, 2016 4:45:17 PM EDT, "Rune K. Svendsen via bitcoin-dev"
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> I would really like to be able to create transactions that are immune to
>>> transaction ID malleability now, so I have been thinking of the simplest
>>> solution possible, in order to get a BIP through without too much trouble.
>>>
>>> An opcode we could call OP_TXHASHVERIFY could be introduced. It would be
>>> defined to work only if added to a scriptSig as the very first operation,
>>> and would abort if the hash of the transaction **with all OP_TXHASHVERIFY
>>> operations (including stack push) removed** does not match what has been
>>> pushed on the stack.
>>>
>>> So, in order to produce a transaction with one or more inputs protected
>>> against tx ID malleability, one would:
>>>
>>> 1. Calculate tx ID of the tx: TX_HASH
>>> 2. For each input you wish to protect, add "0x32 $TX_HASH
>>> OP_TXHASHVERIFY" to the beginning of the scriptSig
>>>
>>> When evaluating OP_TXHASHVERIFY, we make a copy of the tx in question,
>>> and remove the "0x32 <32 bytes> OP_TXHASHVERIFY" sequence from the beginning
>>> of all scriptSigs (if present), and abort if the tx copy hash does not match
>>> the top stack item.
>>>
>>> This is a very simple solution that only adds 34 bytes per input, and
>>> when something better becomes available (eg. Segwit), we will stop using
>>> this. But in the meantime it's very valuable to be able to not worry about
>>> tx ID malleability.
>>>
>>> Please let me know what you think.
>>>
>>>
>>>
>>> /Rune
>>>
>>> ________________________________
>>>
>>> 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
>

2023-06-07 17:51:59

- reply

📅 Original date posted:2016-07-26
📝 Original message:Moral,
Mining the sync flag isn't compatible with the payout structure of non
hot-wallet pools like Eligius or decentralized pools like p2pool.
Those need the ability to split a reward among multiple parties.
Instead of giving an address to send the funds to, you could include
the hash of the transaction allowed to spend the sync flag output.
You'd have to zero the previous outpoint of the transaction before
hashing, since you don't know what the hash of the coinbase ten blocks
from now will be.
On Tue, Jul 26, 2016 at 6:47 AM, Moral Agent via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I posted this to /r/bitcoin yesterday but it got minimal comments. One uses
> suggested I try the mailing list so here it is:
>
> The idea presented here could have the following benefits:
>
> 1. Improve mining decentralization
> 2. Reduce variance in mining profitability
> 3. Reduce or eliminate SPV mined blocks
> 4. Reduce or eliminate empty blocks, smoothing out resource usage
> 5. Reduce or eliminate the latency bottleneck on throughput
> 6. Make transaction stuffing by miners be either obvious or costly
> 7. Gives miners something to do while they wait for attractive transactions
> to appear
> 8. Can be easily done with a soft fork
>
> #Basic idea:
>
> Ideally, all miners would begin hashing the next block at exactly the same
> time. Miners with a head start are more profitable, and the techniques that
> help miners receive and validate blocks quickly create centralization
> pressure.
>
> What if there was something that acted like the starting flag at a race,
> which could suddenly wave and cause all of the miners to simultaneously
> begin hashing the next block?
>
> #Implementation:
>
> Let a sync flag be a message consisting of:
>
> 1. Hash of the previous block.
> 2. Bitcoin address
> 3. Nonce
>
> This tiny message could propagate through the network at maximum speed. If
> miners had to include the hash of this flag in the next block, then all
> miners wait for this flag, and when it suddenly spread through the network,
> all miners could simultaneously begin hashing the next block.
>
> The sync flag should not be produced too quickly. You want to give everyone
> enough time to be ready to hash the next block. Let's say that the hash of
> the sync flag is a proof of work that is targeted for 2 minutes.
>
> To fund this proof of work, the protocol is modified to demand that the
> block produced 10 blocks after the sync flag must allocate 25% of the block
> reward to the address published by the sync flag. In this way, sync flags
> are produced in 2 minutes, and blocks are produced in 8 minutes, with 10
> minutes total.
>
>
> Illustration 1: https://s32.postimg.org/wzg0hs8lx/sync_flag.png)
>
> Illustration 2: https://s32.postimg.org/vc5y9yz4l/sync_flag2.png
>
>
> #Explanation of reasons:
>
> **Improve mining decentralization**
>
> One factor driving centralization is the imperative miners have to achieve
> low latency in receiving and validating blocks. To achieve low latency, it
> helps a lot if you have expensive low-latency internet connections, curated
> network topologies, and large pools that have a plausible chance of finding
> consecutive blocks. If miners are expected (or forced) to validate a block
> prior to mining on top of it, the rational end game would be to outsource
> the validation step to a trusted third party specialist who can choose
> optimal locations on the globe to serve their (multiple?) mining pool
> clients. These are all less decentralized than the mining situation Satoshi
> and others imagined.
>
> **Reduce variance in mining revenue**
>
> Currently, there are about 144 opportunities per day for a pool or solo
> miner to see any revenue at all. With sync flags, that number doubles to
> 288. Sync flags are only worth 25% of what a block is worth, but this still
> represents a significant reduction in variance. This variance is one factor
> causing solo miners to group into pools, and large pools to be more
> attractive than small pools.
>
> **Reduce or eliminate SPV mined blocks**
>
> One way miners have sought to make
> full-block-transmission-and-validation-latency irrelevant has been through
> "SPV" mining or "Head-first" mining. There is some evidence that these
> techniques may be widely used, and that badgering the miners about it is an
> ineffective strategy to stop them.
>
> In SPV mining, a miner would simply accept any block header that shows the
> correct proof of work. All other validation is entrusted to other miners.
> This practice is quite dangerous as the SPV miners can wander off on some
> invalid chain, taking SPV nodes with them. If this occurs during a soft
> fork, these blind miners can also fool unupgraded fully validating nodes
> into following them.
>
> "Head-first" mining means that miners start hashing as soon as they receive
> the block header with the correct POW, but they simultaneously validate the
> block, and abandon it if is not valid. I consider this to be pretty safe, as
> it strictly limits the length of an invalid chain that can result from
> mining without validating. However, "Head-first" mining can plausibly
> generate 2 or 3 confirmations of an invalid block. It would be nice if such
> confirmations did not happen.
>
> The sync flag technique is similar to head-first mining, but rather than
> hashing the next block while they wait for transmission and validation of
> the prior block, they hash the sync flag. Nodes can differentiate between
> sync flags and blocks, and can ignore sync flags when counting
> confirmations.
>
> **Reduce or eliminate empty blocks, smoothing out resource usage**
>
> Empty blocks are another consequence of SPV or Headfirst mining, because the
> miner cannot safely include any transactions in the block they are hashing
> until they have validated the prior block. By delaying the start of hashing
> the next block until after validation, miners would not have this reason to
> mine empty blocks.
>
> **Reduce or eliminate the latency bottleneck on throughput**
>
> Centralization pressure due to latency issues has been a major preoccupation
> over the last year. If latency mattered much less, it could represent a
> scalability improvement that could enable higher throughput.
>
> **Make transaction stuffing by miners be either obvious or costly**
>
> Currently, the entire block reward goes to the miner who mines it. One
> unfortunate consequence of this is that it does not cost the miner anything
> to covertly stuff the block with transactions. These transactions would pay
> fees and be indistinguishable from ordinary transactions, but the fees are
> paid by the miner and then immediately returned to the miner.
>
> With sync flags, the miner must share these transaction fees with the
> address contained in the sync flag 10 blocks prior. This means that if the
> miner gives the transactions a normal looking fee, they will incur a cost
> that will be paid to the sync flag. If the miner wants to avoid this, they
> must give their stuffing transactions a zero fee, which provides evidence
> that they are stuffing.
>
> Also, when miners stuff with transactions using a zero fee, they cannot
> manipulate the perception of how much fee it takes to get into a block.
>
> Note that miners could still try to covertly stuff blocks that will pay a
> sync flag that they themselves created. if this is a big concern, it can be
> addressed by forcing blocks to pay multiple sync flags.
>
> **Gives miners something to do while they wait for attractive transactions
> to appear**
>
> From the Montreal scaling workshop last year, we have [this
> talk](https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf)
> which worried that as the block subsidy reduced and transactions became a
> more important fraction of miner revenue, it would be rational for miners to
> turn off their mining equipment for a "gap" phase after a block is found, to
> allow time to pass as more lucrative transactions entered the mempool.
>
> I don't know whether this will actually happen. The presence of a suitable
> backlog of transactions would help prevent this dynamic from emerging. But
> if such idling behavior was the optima mining strategy, it could create a
> serious vulnerability. Idle hands are the devil's workshop as the saying
> goes, and idle miners represent a pool of inert hashpower that is available
> to rent for all kinds of destabilizing purposes. It would be better to put
> those miners to profitable work mining a sync flag while they wait.
>
> Also, this creates a more efficient price discovery mechanism for
> transactions, because you allow transactions paying high fees time to arrive
> to the marketplace, rather than take whatever anyone is offering because all
> the "good" transactions got gobbled up in the prior block.
>
> **Can be easily done with a soft fork**
>
> Although a hard fork would be more efficient, sync flags could be easily
> implemented using a soft fork by introducing the following rule:
>
> Every block must include a transaction which pays 25% of the block reward to
> the address given by the 10th previous sync flag, and commits to the hash of
> the 1st previous sync flag.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:51:40

- reply

📅 Original date posted:2016-06-28
📝 Original message:>They both require authentication,
Yeah, but not the same *sort* of authentication. As a trivial example,
you could have ten servers that sign long-term keys for nodes. All
that they need to check is that the node requesting a signature owns
the corresponding IP address. On the other hand, 'evil nodes' is a
subjective quality that is hard to assess automatically.
>and if you intend to connect to potentially evil nodes you aren't securing anything
Bitcoin is designed with the assumption that some of the nodes you
connect to might be evil. Sure, if 100% of the nodes you're connected
to are evil, you're screwed. However, we shouldn't avoid protecting
people from someone on the same coffee-shop network, just because the
same mitigation won't work against a nation-state.
On Tue, Jun 28, 2016 at 5:29 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Your description of the two scenarios reduces to one. They both require
> authentication, and if you intend to connect to potentially evil nodes you
> aren't securing anything with link level security except the knowledge that
> your potentially evil node connection remains so.
>
> e
>
> On Jun 29, 2016, at 12:33 AM, Cameron Garnham <da2ce7 at gmail.com> wrote:
>
>
> There are two different topics mixed up here.
>
> 1. Link-level security (secure connection to the node we intended to connect
> to).
>
> 2. Node-level security (aka; don't connect to a 'evil node').
>
> The fist requires link-level encryption and authentication.
>
> The second requires identity authentication.
>
> You described the 'evil node' attack; that indeed needs an identity system
> to stop. However BIP151 doesn't intend to protect against connecting to evil
> Bitcoin Nodes.
>
> It is important not to mixup link-level authentication and node-level
> authentication.
>
> When your client picks random nodes to connect to, you are not considered
> whom in particular runs them. (Rather that you have a good random sample of
> the network).
>
> If you manually add a friends node; at this point you wish to have
> node-level authentication. However, this may (and probably should) happen
> out-of-band.
>
>
> Sent from my iPhone
>
> On 29 Jun 2016, at 01:07, Eric Voskuil <eric at voskuil.org> wrote:
>
> Hi Cameron, good to hear from you!
>
> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7 at gmail.com> wrote:
>
> Unauthenticated link level encryption is wonderful! MITM attacks are
> overrated; as they require an active attacker.
>
>
> This is not really the case with Bitcoin. A MITM attack does not require
> that the attacker find a way to inject traffic into the communication
> between nodes. Peers will connect to the attacker directly, or accept
> connections directly from it. Such attacks can be easier than even passive
> attacks.
>
> Stopping passive attacks is the low hanging fruit. This should be taken
> first.
>
> Automated and secure peer authentication in a mesh network is a huge topic.
> One of the unsolved problems in computer science.
>
> A simple 'who is that' by asking for the fingerprint of your peers from your
> other peers is a very simple way to get 'some' authentication. Semi-trusted
> index nodes also is a low hanging fruit for authentication.
>
>
> It is the implication of widespread authentication that is at issue. Clearly
> there are ways to implement it using a secure side channels.
>
> However, let's first get unauthenticated encryption. Force the attackers to
> use active attacks. (That are thousands times more costly to couduct).
>
> Sent from my iPhone
>
> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> An "out of band key check" is not part of BIP151.
>
>
> It has a session ID for this purpose.
>
> It requires a secure channel and is authentication. So BIP151 doesn't
> provide the tools to detect an attack, that requires authentication. A
> general requirement for authentication is the issue I have raised.
>
>
> One might wonder how you ever use a Bitcoin address, or even why we
> might guess these emails from "you" aren't actually coming from the
> NSA.
> _______________________________________________
> 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
>

2023-06-07 17:50:48

- reply

📅 Original date posted:2016-05-19
📝 Original message:What if two people create transactions from oupoints within the same MMR
tree tip, at the same time?
For example, I create transaction A plus an MMR proof that MMR tip X will
become Y.
On the other side of the planet, someone else creates transaction B, plus
an MMR proof that tip X will become Z.
Can a miner who receives A and B put both into a block, without access to
the outputs that were pruned?
# Motivation
UTXO growth is a serious concern for Bitcoin's long-term decentralization.
To
run a competitive mining operation potentially the entire UTXO set must be
in
RAM to achieve competitive latency; your larger, more centralized,
competitors
will have the UTXO set in RAM. Mining is a zero-sum game, so the extra
latency
of not doing so if they do directly impacts your profit margin. Secondly,
having possession of the UTXO set is one of the minimum requirements to run
a
full node; the larger the set the harder it is to run a full node.
Currently the maximum size of the UTXO set is unbounded as there is no
consensus rule that limits growth, other than the block-size limit itself;
as
of writing the UTXO set is 1.3GB in the on-disk, compressed serialization,
which expands to significantly more in memory. UTXO growth is driven by a
number of factors, including the fact that there is little incentive to
merge
inputs, lost coins, dust outputs that can't be economically spent, and
non-btc-value-transfer "blockchain" use-cases such as anti-replay oracles
and
timestamping.
We don't have good tools to combat UTXO growth. Segregated Witness proposes
to
give witness space a 75% discount, in part of make reducing the UTXO set
size
by spending txouts cheaper. While this may change wallets to more often
spend
dust, it's hard to imagine an incentive sufficiently strong to discourage
most,
let alone all, UTXO growing behavior.
For example, timestamping applications often create unspendable outputs due
to
ease of implementation, and because doing so is an easy way to make sure
that
the data required to reconstruct the timestamp proof won't get lost - all
Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay
use-cases like using the UTXO set for key rotation piggyback on the uniquely
strong security and decentralization guarantee that Bitcoin provides; it's
very
difficult - perhaps impossible - to provide these applications with
alternatives that are equally secure. These non-btc-value-transfer use-cases
can often afford to pay far higher fees per UTXO created than competing
btc-value-transfer use-cases; many users could afford to spend $50 to
register
a new PGP key, yet would rather not spend $50 in fees to create a standard
two
output transaction. Effective techniques to resist miner censorship exist,
so
without resorting to whitelists blocking non-btc-value-transfer use-cases as
"spam" is not a long-term, incentive compatible, solution.
A hard upper limit on UTXO set size could create a more level playing field
in
the form of fixed minimum requirements to run a performant Bitcoin node, and
make the issue of UTXO "spam" less important. However, making any coins
unspendable, regardless of age or value, is a politically untenable economic
change.
# TXO Commitments
A merkle tree committing to the state of all transaction outputs, both spent
and unspent, we can provide a method of compactly proving the current state
of
an output. This lets us "archive" less frequently accessed parts of the UTXO
set, allowing full nodes to discard the associated data, still providing a
mechanism to spend those archived outputs by proving to those nodes that the
outputs are in fact unspent.
Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a
type of deterministic, indexable, insertion ordered merkle tree, which
allows
new items to be cheaply appended to the tree with minimal storage
requirements,
just log2(n) "mountain tips". Once an output is added to the TXO MMR it is
never removed; if an output is spent its status is updated in place. Both
the
state of a specific item in the MMR, as well the validity of changes to
items
in the MMR, can be proven with log2(n) sized proofs consisting of a merkle
path
to the tip of the tree.
At an extreme, with TXO commitments we could even have no UTXO set at all,
entirely eliminating the UTXO growth problem. Transactions would simply be
accompanied by TXO commitment proofs showing that the outputs they wanted to
spend were still unspent; nodes could update the state of the TXO MMR purely
from TXO commitment proofs. However, the log2(n) bandwidth overhead per
txin is
substantial, so a more realistic implementation is be to have a UTXO cache
for
recent transactions, with TXO commitments acting as a alternate for the
(rare)
event that an old txout needs to be spent.
Proofs can be generated and added to transactions without the involvement of
the signers, even after the fact; there's no need for the proof itself to
signed and the proof is not part of the transaction hash. Anyone with
access to
TXO MMR data can (re)generate missing proofs, so minimal, if any, changes
are
required to wallet software to make use of TXO commitments.
## Delayed Commitments
TXO commitments aren't a new idea - the author proposed them years ago in
response to UTXO commitments. However it's critical for small miners' orphan
rates that block validation be fast, and so far it has proven difficult to
create (U)TXO implementations with acceptable performance; updating and
recalculating cryptographicly hashed merkelized datasets is inherently more
work than not doing so. Fortunately if we maintain a UTXO set for recent
outputs, TXO commitments are only needed when spending old, archived,
outputs.
We can take advantage of this by delaying the commitment, allowing it to be
calculated well in advance of it actually being used, thus changing a
latency-critical task into a much easier average throughput problem.
Concretely each block B_i commits to the TXO set state as of block B_{i-n},
in
other words what the TXO commitment would have been n blocks ago, if not for
the n block delay. Since that commitment only depends on the contents of the
blockchain up until block B_{i-n}, the contents of any block after are
irrelevant to the calculation.
## Implementation
Our proposed high-performance/low-latency delayed commitment full-node
implementation needs to store the following data:
1) UTXO set
Low-latency K:V map of txouts definitely known to be unspent. Similar to
existing UTXO implementation, but with the key difference that old,
unspent, outputs may be pruned from the UTXO set.
2) STXO set
Low-latency set of transaction outputs known to have been spent by
transactions after the most recent TXO commitment, but created prior to
the
TXO commitment.
3) TXO journal
FIFO of outputs that need to be marked as spent in the TXO MMR. Appends
must be low-latency; removals can be high-latency.
4) TXO MMR list
Prunable, ordered list of TXO MMR's, mainly the highest pending
commitment,
backed by a reference counted, cryptographically hashed object store
indexed by digest (similar to how git repos work). High-latency ok.
We'll
cover this in more in detail later.
### Fast-Path: Verifying a Txout Spend In a Block
When a transaction output is spent by a transaction in a block we have two
cases:
1) Recently created output
Output created after the most recent TXO commitment, so it should be in
the
UTXO set; the transaction spending it does not need a TXO commitment
proof.
Remove the output from the UTXO set and append it to the TXO journal.
2) Archived output
Output created prior to the most recent TXO commitment, so there's no
guarantee it's in the UTXO set; transaction will have a TXO commitment
proof for the most recent TXO commitment showing that it was unspent.
Check that the output isn't already in the STXO set (double-spent), and
if
not add it. Append the output and TXO commitment proof to the TXO
journal.
In both cases recording an output as spent requires no more than two
key:value
updates, and one journal append. The existing UTXO set requires one
key:value
update per spend, so we can expect new block validation latency to be
within 2x
of the status quo even in the worst case of 100% archived output spends.
### Slow-Path: Calculating Pending TXO Commitments
In a low-priority background task we flush the TXO journal, recording the
outputs spent by each block in the TXO MMR, and hashing MMR data to obtain
the
TXO commitment digest. Additionally this background task removes STXO's that
have been recorded in TXO commitments, and prunes TXO commitment data no
longer
needed.
Throughput for the TXO commitment calculation will be worse than the
existing
UTXO only scheme. This impacts bulk verification, e.g. initial block
download.
That said, TXO commitments provides other possible tradeoffs that can
mitigate
impact of slower validation throughput, such as skipping validation of old
history, as well as fraud proof approaches.
### TXO MMR Implementation Details
Each TXO MMR state is a modification of the previous one with most
information
shared, so we an space-efficiently store a large number of TXO commitments
states, where each state is a small delta of the previous state, by sharing
unchanged data between each state; cycles are impossible in merkelized data
structures, so simple reference counting is sufficient for garbage
collection.
Data no longer needed can be pruned by dropping it from the database, and
unpruned by adding it again. Since everything is committed to via
cryptographic
hash, we're guaranteed that regardless of where we get the data, after
unpruning we'll have the right data.
Let's look at how the TXO MMR works in detail. Consider the following TXO
MMR
with two txouts, which we'll call state #0:
0
/ \
a b
If we add another entry we get state #1:
1
/ \
0 \
/ \ \
a b c
Note how it 100% of the state #0 data was reused in commitment #1. Let's
add two more entries to get state #2:
2
/ \
2 \
/ \ \
/ \ \
/ \ \
0 2 \
/ \ / \ \
a b c d e
This time part of state #1 wasn't reused - it's wasn't a perfect binary
tree - but we've still got a lot of re-use.
Now suppose state #2 is committed into the blockchain by the most recent
block.
Future transactions attempting to spend outputs created as of state #2 are
obliged to prove that they are unspent; essentially they're forced to
provide
part of the state #2 MMR data. This lets us prune that data, discarding it,
leaving us with only the bare minimum data we need to append new txouts to
the
TXO MMR, the tips of the perfect binary trees ("mountains") within the MMR:
2
/ \
2 \
\
\
\
\
\
e
Note that we're glossing over some nuance here about exactly what data
needs to
be kept; depending on the details of the implementation the only data we
need
for nodes "2" and "e" may be their hash digest.
Adding another three more txouts results in state #3:
3
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \
/ \
/ \
3 3
/ \ / \
e f g h
Suppose recently created txout f is spent. We have all the data required to
update the MMR, giving us state #4. It modifies two inner nodes and one leaf
node:
4
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 4
/ \
/ \
/ \
4 3
/ \ / \
e (f) g h
If an archived txout is spent requires the transaction to provide the merkle
path to the most recently committed TXO, in our case state #2. If txout b is
spent that means the transaction must provide the following data from state
#2:
2
/
2
/
/
/
0
\
b
We can add that data to our local knowledge of the TXO MMR, unpruning part
of
it:
4
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 4
/ / \
/ / \
/ / \
0 4 3
\ / \ / \
b e (f) g h
Remember, we haven't _modified_ state #4 yet; we just have more data about
it.
When we mark txout b as spent we get state #5:
5
/ \
/ \
/ \
/ \
/ \
/ \
/ \
5 4
/ / \
/ / \
/ / \
5 4 3
\ / \ / \
(b) e (f) g h
Secondly by now state #3 has been committed into the chain, and transactions
that want to spend txouts created as of state #3 must provide a TXO proof
consisting of state #3 data. The leaf nodes for outputs g and h, and the
inner
node above them, are part of state #3, so we prune them:
5
/ \
/ \
/ \
/ \
/ \
/ \
/ \
5 4
/ /
/ /
/ /
5 4
\ / \
(b) e (f)
Finally, lets put this all together, by spending txouts a, c, and g, and
creating three new txouts i, j, and k. State #3 was the most recently
committed
state, so the transactions spending a and g are providing merkle paths up to
it. This includes part of the state #2 data:
3
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \ \
/ \ \
/ \ \
0 2 3
/ / /
a c g
After unpruning we have the following data for state #5:
5
/ \
/ \
/ \
/ \
/ \
/ \
/ \
5 4
/ \ / \
/ \ / \
/ \ / \
5 2 4 3
/ \ / / \ /
a (b) c e (f) g
That's sufficient to mark the three outputs as spent and add the three new
txouts, resulting in state #6:
6
/ \
/ \
/ \
/ \
/ \
6 \
/ \ \
/ \ \
/ \ \
/ \ \
/ \ \
/ \ \
/ \ \
6 6 \
/ \ / \ \
/ \ / \ 6
/ \ / \ / \
6 6 4 6 6 \
/ \ / / \ / / \ \
(a) (b) (c) e (f) (g) i j k
Again, state #4 related data can be pruned. In addition, depending on how
the
STXO set is implemented may also be able to prune data related to spent
txouts
after that state, including inner nodes where all txouts under them have
been
spent (more on pruning spent inner nodes later).
### Consensus and Pruning
It's important to note that pruning behavior is consensus critical: a full
node
that is missing data due to pruning it too soon will fall out of consensus,
and
a miner that fails to include a merkle proof that is required by the
consensus
is creating an invalid block. At the same time many full nodes will have
significantly more data on hand than the bare minimum so they can help
wallets
make transactions spending old coins; implementations should strongly
consider
separating the data that is, and isn't, strictly required for consensus.
A reasonable approach for the low-level cryptography may be to actually
treat
the two cases differently, with the TXO commitments committing too what data
does and does not need to be kept on hand by the UTXO expiration rules. On
the
other hand, leaving that uncommitted allows for certain types of soft-forks
where the protocol is changed to require more data than it previously did.
### Consensus Critical Storage Overheads
Only the UTXO and STXO sets need to be kept on fast random access storage.
Since STXO set entries can only be created by spending a UTXO - and are
smaller
than a UTXO entry - we can guarantee that the peak size of the UTXO and STXO
sets combined will always be less than the peak size of the UTXO set alone
in
the existing UTXO-only scheme (though the combined size can be temporarily
higher than what the UTXO set size alone would be when large numbers of
archived txouts are spent).
TXO journal entries and unpruned entries in the TXO MMR have log2(n) maximum
overhead per entry: a unique merkle path to a TXO commitment (by "unique" we
mean that no other entry shares data with it). On a reasonably fast system
the
TXO journal will be flushed quickly, converting it into TXO MMR data; the
TXO
journal will never be more than a few blocks in size.
Transactions spending non-archived txouts are not required to provide any
TXO
commitment data; we must have that data on hand in the form of one TXO MMR
entry per UTXO. Once spent however the TXO MMR leaf node associated with
that
non-archived txout can be immediately pruned - it's no longer in the UTXO
set
so any attempt to spend it will fail; the data is now immutable and we'll
never
need it again. Inner nodes in the TXO MMR can also be pruned if all leafs
under
them are fully spent; detecting this is easy the TXO MMR is a merkle-sum
tree,
with each inner node committing to the sum of the unspent txouts under it.
When a archived txout is spent the transaction is required to provide a
merkle
path to the most recent TXO commitment. As shown above that path is
sufficient
information to unprune the necessary nodes in the TXO MMR and apply the
spend
immediately, reducing this case to the TXO journal size question
(non-consensus
critical overhead is a different question, which we'll address in the next
section).
Taking all this into account the only significant storage overhead of our
TXO
commitments scheme when compared to the status quo is the log2(n) merkle
path
overhead; as long as less than 1/log2(n) of the UTXO set is active,
non-archived, UTXO's we've come out ahead, even in the unrealistic case
where
all storage available is equally fast. In the real world that isn't yet the
case - even SSD's significantly slower than RAM.
### Non-Consensus Critical Storage Overheads
Transactions spending archived txouts pose two challenges:
1) Obtaining up-to-date TXO commitment proofs
2) Updating those proofs as blocks are mined
The first challenge can be handled by specialized archival nodes, not unlike
how some nodes make transaction data available to wallets via bloom filters
or
the Electrum protocol. There's a whole variety of options available, and the
the data can be easily sharded to scale horizontally; the data is
self-validating allowing horizontal scaling without trust.
While miners and relay nodes don't need to be concerned about the initial
commitment proof, updating that proof is another matter. If a node
aggressively
prunes old versions of the TXO MMR as it calculates pending TXO
commitments, it
won't have the data available to update the TXO commitment proof to be
against
the next block, when that block is found; the child nodes of the TXO MMR tip
are guaranteed to have changed, yet aggressive pruning would have discarded
that
data.
Relay nodes could ignore this problem if they simply accept the fact that
they'll only be able to fully relay the transaction once, when it is
initially
broadcast, and won't be able to provide mempool functionality after the
initial
relay. Modulo high-latency mixnets, this is probably acceptable; the author
has
previously argued that relay nodes don't need a mempool² at all.
For a miner though not having the data necessary to update the proofs as
blocks
are found means potentially losing out on transactions fees. So how much
extra
data is necessary to make this a non-issue?
Since the TXO MMR is insertion ordered, spending a non-archived txout can
only
invalidate the upper nodes in of the archived txout's TXO MMR proof (if this
isn't clear, imagine a two-level scheme, with a per-block TXO MMRs,
committed
by a master MMR for all blocks). The maximum number of relevant inner nodes
changed is log2(n) per block, so if there are n non-archival blocks between
the
most recent TXO commitment and the pending TXO MMR tip, we have to store
log2(n)*n inner nodes - on the order of a few dozen MB even when n is a
(seemingly ridiculously high) year worth of blocks.
Archived txout spends on the other hand can invalidate TXO MMR proofs at any
level - consider the case of two adjacent txouts being spent. To guarantee
success requires storing full proofs. However, they're limited by the
blocksize
limit, and additionally are expected to be relatively uncommon. For
example, if
1% of 1MB blocks was archival spends, our hypothetical year long TXO
commitment
delay is only a few hundred MB of data with low-IO-performance requirements.
## Security Model
Of course, a TXO commitment delay of a year sounds ridiculous. Even the
slowest
imaginable computer isn't going to need more than a few blocks of TXO
commitment delay to keep up ~100% of the time, and there's no reason why we
can't have the UTXO archive delay be significantly longer than the TXO
commitment delay.
However, as with UTXO commitments, TXO commitments raise issues with
Bitcoin's
security model by allowing relatively miners to profitably mine transactions
without bothering to validate prior history. At the extreme, if there was no
commitment delay at all at the cost of a bit of some extra network bandwidth
"full" nodes could operate and even mine blocks completely statelessly by
expecting all transactions to include "proof" that their inputs are
unspent; a
TXO commitment proof for a commitment you haven't verified isn't a proof
that a
transaction output is unspent, it's a proof that some miners claimed the
txout
was unspent.
At one extreme, we could simply implement TXO commitments in a "virtual"
fashion, without miners actually including the TXO commitment digest in
their
blocks at all. Full nodes would be forced to compute the commitment from
scratch, in the same way they are forced to compute the UTXO state, or total
work. Of course a full node operator who doesn't want to verify old history
can
get a copy of the TXO state from a trusted source - no different from how
you
could get a copy of the UTXO set from a trusted source.
A more pragmatic approach is to accept that people will do that anyway, and
instead assume that sufficiently old blocks are valid. But how old is
"sufficiently old"? First of all, if your full node implementation comes
"from
the factory" with a reasonably up-to-date minimum accepted total-work
thresholdⁱ - in other words it won't accept a chain with less than that
amount
of total work - it may be reasonable to assume any Sybil attacker with
sufficient hashing power to make a forked chain meeting that threshold with,
say, six months worth of blocks has enough hashing power to threaten the
main
chain as well.
That leaves public attempts to falsify TXO commitments, done out in the
open by
the majority of hashing power. In this circumstance the "assumed valid"
threshold determines how long the attack would have to go on before full
nodes
start accepting the invalid chain, or at least, newly installed/recently
reset
full nodes. The minimum age that we can "assume valid" is tradeoff between
political/social/technical concerns; we probably want at least a few weeks
to
guarantee the defenders a chance to organise themselves.
With this in mind, a longer-than-technically-necessary TXO commitment delayʲ
may help ensure that full node software actually validates some minimum
number
of blocks out-of-the-box, without taking shortcuts. However this can be
achieved in a wide variety of ways, such as the author's prev-block-proof
proposal³, fraud proofs, or even a PoW with an inner loop dependent on
blockchain data. Like UTXO commitments, TXO commitments are also potentially
very useful in reducing the need for SPV wallet software to trust third
parties
providing them with transaction data.
i) Checkpoints that reject any chain without a specific block are a more
common, if uglier, way of achieving this protection.
j) A good homework problem is to figure out how the TXO commitment could be
designed such that the delay could be reduced in a soft-fork.
## Further Work
While we've shown that TXO commitments certainly could be implemented
without
increasing peak IO bandwidth/block validation latency significantly with the
delayed commitment approach, we're far from being certain that they should
be
implemented this way (or at all).
1) Can a TXO commitment scheme be optimized sufficiently to be used directly
without a commitment delay? Obviously it'd be preferable to avoid all the
above
complexity entirely.
2) Is it possible to use a metric other than age, e.g. priority? While this
complicates the pruning logic, it could use the UTXO set space more
efficiently, especially if your goal is to prioritise bitcoin value-transfer
over other uses (though if "normal" wallets nearly never need to use TXO
commitments proofs to spend outputs, the infrastructure to actually do this
may
rot).
3) Should UTXO archiving be based on a fixed size UTXO set, rather than an
age/priority/etc. threshold?
4) By fixing the problem (or possibly just "fixing" the problem) are we
encouraging/legitimising blockchain use-cases other than BTC value transfer?
Should we?
5) Instead of TXO commitment proofs counting towards the blocksize limit,
can
we use a different miner fairness/decentralization metric/incentive? For
instance it might be reasonable for the TXO commitment proof size to be
discounted, or ignored entirely, if a proof-of-propagation scheme (e.g.
thinblocks) is used to ensure all miners have received the proof in advance.
6) How does this interact with fraud proofs? Obviously furthering
dependency on
non-cryptographically-committed STXO/UTXO databases is incompatible with the
modularized validation approach to implementing fraud proofs.
# References
1) "Merkle Mountain Ranges",
Peter Todd, OpenTimestamps, Mar 18 2013,
https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md
2) "Do we really need a mempool? (for relay nodes)",
Peter Todd, bitcoin-dev mailing list, Jul 18th 2015,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009479.html
3) "Segregated witnesses and validationless mining",
Peter Todd, bitcoin-dev mailing list, Dec 23rd 2015,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012103.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/20160519/985c4b60/attachment-0001.html>

2023-06-07 17:47:32

- reply

📅 Original date posted:2016-01-04
📝 Original message:How are you collecting fees from the transactions in the block?
On Sat, Jan 2, 2016 at 8:51 PM, joe2015--- via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 2016-01-03 02:46, Marco Falke wrote:
>>
>> 2015-12-30 17:27 GMT+01:00 <joe2015 at openmailbox.org>:
>>>
>>> On 2015-12-30 18:33, Marco Falke wrote:
>>>>
>>>>
>>>> This is an interesting approach but I don't see how this is a soft
>>>> fork. (Just because something is not a hard fork, doesn't make it a
>>>> soft fork by definition)
>>>> Softforks don't require any nodes to upgrade. [1]
>>>> Nonetheless, as I understand your approach, it requires nodes to
>>>> upgrade. Otherwise they are missing all transactions but the coinbase
>>>> transactions. Thus, they cannot update their utxoset and are easily
>>>> susceptible to double spends...
>>>>
>>>> Am I missing something obvious?
>>>>
>>>> -- Marco
>>>>
>>>>
>>>> [1] https://en.bitcoin.it/wiki/Softfork#Implications
>>>
>>>
>>>
>>> It just depends how you define "softfork". In my original write-up I
>>> called
>>> it a "generalized" softfork, Peter suggested a "firm" fork, and there are
>>> some suggestions for other names. Ultimately what you call it is not
>>> very
>>> important.
>>>
>>> --joe.
>>
>>
>> joe, indeed it is not important how you call it, but please, let's not
>> call it "soft fork".
>
>
> This kind of fork (whatever it is called) has all the traditional properties
> of a softfork except meaningful backwards compatibility for non-upgraded
> clients. So I think it is reasonable to call it a softfork with some
> qualification.
>
>> Besides my initial question about the coinbase
>> tx, I was also wondering how non-updated nodes would verify the
>> collected fees without the actual txs at hand. (They only have the
>> coinbase tx, don't they?)
>
>
> Yes this appears to be an oversight in my proof-of-concept implementation.
> The unintended consequence being that all transactions would have to be
> zero-fee...
>
> The simplest fix would be make the new rules add the fees implicitly. There
> are other solutions.
>
>> Moreover, I can't see the benefits over a hard fork. A hard fork is
>> much cleaner in regard to code changes. As one of the intends of
>> "generalized soft forks" is to force user to update, at least a hard
>> fork doesn't lie about the fact. Am I missing any obvious advantages
>> of a "generalized soft fork" over a "clean" hard fork?
>
>
> A "firm soft fork" also does not lie about that fact -- you must upgrade. I
> don't see it dishonest if it was never claimed otherwise.
>
> I agree that hardforks can be "cleaner".
>
> However the obvious disadvantage of a hardfork is the risk of the network
> splitting between upgraded and non-upgraded clients. This is not a problem
> if there is 100% consensus behind the hardfork, but I am not sure if 100% is
> realistically achievable for contentious issues such as the blocksize limit.
>
> If 100% consensus is never achieved, then the options are:
> 1. Never upgrade and keep the blocksize limit unchanged forever.
> 2. Use a firm softfork to resolve the deadlock.
> 3. Hardfork anyway and split the network.
>
> My argument is simply that 2 is better than 3 and possibly 1.
>
> --joe
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:47:30

- reply

📅 Original date posted:2015-12-30
📝 Original message:Emin,
I have two technical criticisms of your proposal, and one economic criticism.
>Unified miners would make sure that they mine transactions on Dum first, then on Dee. Recall that Dee miners can always just take Dum transactions and stick them in their blocks.
This seems to contradict a later section that says that users can use
Dee natively, without paying fees necessary to get a transaction into
Dum. You can't have this both ways - either you can get a transaction
into Dee without getting it into Dum first, or you can't.
>Such an attack would be quite visible, and it would leave Dum vulnerable. Unified clients could counter this launching a 51% counterattack on Dum.
What if some other group that wants to hurt both Dum and Dee were to
make a false-flag attack against Dee? Mutually assured destruction
doesn't work if you can't accurately attribute attacks.
>This would create some gentle pressure to explicitly unify the two chains (by merging Dee and Dum at some compromise and doing away with Unified)
I don't think a compromise would be reachable at that point - suppose
one had a market cap of 1.2 billion, and the other had a market cap of
0.8 billion. How would the coins on the unified chain be distributed?
You could give each chain an equal number of coins, but that's not
fair to the people holding the more valuable coins. You could give
each chain a number of coins proportional to the market cap, but that
invites price manipulation. In any case, if you had a way of reaching
compromise, why not use it instead of creating two chains?
Overall, I think this proposal is a bad idea.
>You seem to not be familiar with how multisig transactions on Bitcoin work - 99.9% of the time theyre hidden behind p2sh and there is no way to know what keys are involved. Equally, multisig is just one of many complex scripts possible.
That doesn't end up mattering, though, as I understand his proposal.
The unified client would just see that both validly spend an output
with a scriptPubKey of OP_HASH160 0xabcdef... OP_EQUAL.
On Wed, Dec 30, 2015 at 1:32 PM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 30 December 2015 12:22:43 GMT-08:00, "Emin Gün Sirer" <el33th4x0r at gmail.com> wrote:
>>On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd <pete at petertodd.org> wrote:
>>
>>> Note how transaction malleability can quickly sabotage naive notions
>>of
>>> this idea.
>>>
>>
>>Bitcoin-United relies on a notion of transaction equivalence that
>>doesn't
>>involve the transaction hash at all, so it should be immune to
>>malleability
>>issues and compatible with segwit.
>>
> >From the post, two transactions are equal if they "consume the same
>>inputs
>>and result in the same outputs, not counting the miner fee. Simple
>>pay-to-pubkey-hash and pay-to-script-hash transactions are
>>straightforward.
>>Multikey transactions are evaluated for equivalency by their inputs and
>>outputs, so it is allowable for a 2-out-of-3 payment to be signed by
>>one
>>set of two keys on Dum and another set of two keys on Dee, as long as
>>the
>>transaction consumes the same coins and produces the same outputs. Not
>>that
>>we'll ever encounter such a case, but making this point helps
>>pedagogically
>>with getting across the notion of transaction equivalence. What counts
>>are
>>the consumed inputs and the destination and amounts of the outputs."
>
> You seem to not be familiar with how multisig transactions on Bitcoin work - 99.9% of the time theyre hidden behind p2sh and there is no way to know what keys are involved. Equally, multisig is just one of many complex scripts possible.
>
> Look into what a segwit transaction hashes - that's a better notion of non-malleable transaction. But even then lots of transactions are malleable, and its easy to trigger those cases intentionally by third parties.
>
> Most likely any Bitcoin United scheme would quickly diverge and fail; much simpler and more predictable to achieve convincing consensus, e.g. via proof of stake voting, or Adam Bank's extension blocks suggestions. (or of course, not trying to force controversial forks in the first place)
>
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N
> AAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g
> w9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH
> Egye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl
> nmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df
> dQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN
> Ac15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY=
> =FfK1
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:44:17

- reply

📅 Original date posted:2015-11-06
📝 Original message:Your suggested modification seems sound.
Though, a script author could do something similar right now by
prefacing his IF with this:
OP_DUP OP_DUP OP_0 OP_EQUAL OP_SWAP OP_1 OP_EQUAL OP_BOOLOR
OP_NOTIF OP_RETURN OP_ENDIF [actual OP_IF goes here]
That checks whether the input is 0 or 1, and runs OP_RETURN if not.
Your way is cleaner, though.
On Fri, Nov 6, 2015 at 1:13 AM, jl2012 via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have a new BIP draft for fixing OP_IF and OP_NOTIF malleability. Please
> comment:
> https://github.com/jl2012/bips/blob/master/opifmalleability.mediawiki
>
> Copied below:
>
> BIP: x
> Title: Dealing with OP_IF and OP_NOTIF malleability
> Author: jl2012 <jl2012 at xbt.hk>
> Status: Draft
> Type: Standards Track
> Created: 2015-11-06
>
> Abstract
>
> As an supplement to BIP62, this document specifies proposed changes to the
> Bitcoin transaction validity rules in order to make malleability of
> transactions with OP_IF and OP_NOTIF impossible.
>
> Motivation
>
> OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The
> programme flow is decided by whether the top stake value is 0 or not.
> However, this behavior opens a source of malleability as a third party may
> alter a non-zero flow control value to any other non-zero value without
> invalidating the transaction.
>
> As of November 2015, OP_IF and OP_NOTIF are not commonly used in the
> blockchain. However, as more sophisticated functions such as
> OP_CHECKLOCKTIMEVERITY are being introduced, OP_IF and OP_NOTIF will become
> more popular and the related malleability should be fixed. This proposal
> serves as a supplement to BIP62 and should be implemented with other
> malleability fixes together.
>
> Specification
>
> If the transaction version is 3 or above, the flow control value for OP_IF
> and OP_NOTIF must be either 0 or 1, or the transaction fails.
>
> This is to be implemented with BIP62.
>
> Compatibility
>
> This is a softfork. To ensure OP_IF and OP_NOTIF transactions created before
> the introduction of this BIP will still be accpeted by the network, the new
> rules only apply to transactions of version 3 or above.
>
> For people who want to preserve the original behaviour of OP_IF and
> OP_NOTIF, an OP_0NOTEQUAL could be used before the flow control code to
> transform any non-zero value to 1.
>
> Reference
>
> BIP62: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:31:19

- reply