Dr Adam Back [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 18:16:01

- reply

📅 Original date posted:2019-01-22
📝 Original message:Brands credentials use this single show, and multiple show
credentials. It's based on the representation problem which is the
generalisation to multiple bases where Schnorr is one base, Pedersen
Commitments are two bases, Representation problem is n>2 bases.
The method used would work for Schnorr or DSA and there was some 2013
era #bitcoin-wizards discussion on this topic, where if you spend
twice miners can take your money, as a strong way to "discourage"
address reuse. One side effect though is you force ACID log oriented
storage on the wallet, and many wallets are low power devices or even
a few in VMs that could be snapshotted or rolled back. Similar risk
model to the lightning penalty for accidentally doing a hostile close
in the current model (where ELTOO has non-penalty based close).
You would have to be careful to not use related nonces (k=nonce
committed to by R=kG), as Schnorr and DSA are highly vulnerable to
that, like simultaneous equation two samples solvable.
What the Brands n-show credential looks like is a precommitment like
single show the address becomes A=H(R,Q) where Q is the public key,
and n-show becomes A=H(R1,...,Rn,Q).
Signing becomes providing i,Ri,Q in the Script to satisfy a
ScriptPubKey that includes the three. You would need to in practice
store the Ri values in a merkle tree probably so that you don't need
to provide n inputs, but log(n) or some other structuring.
Anyway main point being the fragility to related nonces, and cost of
ACID log structured storage levels of reliability in wallets.
Adam
On Tue, 22 Jan 2019 at 15:14, ZmnSCPxj via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good Morning Matt,
>
> > ### ZmnSCPxj,
> >
> > I'm intrigued by this mechanism of using fixed R values to prevent multiple signatures, but how do we derive the R values in a way where they are
> unique for each blockheight but still can be used to create signatures or verify?
>
> One possibility is to derive `R` using standard hierarchical derivation.
> Then require that the staking pubkey be revealed to the sidechain network as actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly with some trivial protection against Taproot).
> To sign for a blockheight `h`, you must use your public key `P` and the specific `R` we get from hierarchical derivation from `parent_R` and the blockheight as index.
>
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:42:59

- reply

📅 Original date posted:2015-10-07
📝 Original message:Micha I think you are correct, I dont think extension blocks (or
sidechains for that matter) can allow soft-fork increase of the total
Bitcoins in the system, because the main chain still enforces the 21m
coin cap. A given extension block could go fractional, but if there
was a run to get out, the last users out will lose, or they'll all
take a hair-cut etc. So presumably users would decline to use an
extension block with fractional bitcoin.
I mean you could view it like say an exchange (mtgox?) that somehow
accidentally or intentionally creates fictional Bitcoin IOUs in it's
system, eg in some kind of pyramid scheme - that doesnt create more
Bitcoins, it just means people who think they have IOUs for real
Bitcoins, are fractional or fake. With an extension block or
sidechain furthermore it is transparent so they will know they are
fractional.
Relatedly it seems possible to implement a sidechain with advertised
demurrage, with an exit or entrance fee to discourage holding outside
of the chain to avoid demurrage. There are apparently economic
arguments for why people might opt in to that (higher velocity
economic activity, gresham's law, merchants offering discounts for
buying with demurrage Bitcoins, maybe lower per transaction fees
because say miners can mine the demurrage). However that is a
different topic, again not changing the number of coins in
circulation.
Adam
On 7 October 2015 at 08:13, Micha Bailey via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Monday, October 5, 2015, Mike Hearn via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> As Greg explained to you repeatedly, a softfork won't cause a
>>> non-upgraded full node to start accepting blocks that create more
>>> subsidy than is valid.
>>
>>
>> It was an example. Adam Back's extension blocks proposal would, in fact,
>> allow for a soft forking change that creates more subsidy than is valid (or
>> does anything else) by hiding one block inside another.
>
>
> Maybe I'm missing something, but wouldn't this turn into a hard fork the
> moment you try to spend an output created in one of these extension blocks?
> So sure, the block that contains the extension would be considered valid,
> but unupgraded validators will not update the UTXO set accordingly, meaning
> that those new TXOs can't be spent because, according to their rules, they
> don't exist.

2023-06-07 15:38:48

- reply

📅 Original date posted:2015-06-19
📝 Original message:A lot of people think a layer2 is needed, that has a higher
(algorithmic) scale in use of layer1 block-space but preserves
functionality and uplifts security from layer1. An example would be
lightning or similar.
But there are many things that could be done. Pure offchain is a weak
form of layer2. Its running today and maybe its handling 90-99% range
of all transactions right now (mostly in exchanges for example). This
layer can be incrementally hardened. It can also have standardised
APIs across vendors of custodians, and opt-in support of those APIs in
wallets. This would provide a convenience choice. Greenaddress also
for low-mid assurances solves the unconfirmed transactions. It's
probably not reasonable to expect bitcoin directly solve fast
unconfirmed transactions. Probably intermediate configurations in
complexity somewhere between greenaddress (2 of 2 + timelocked 1 sig)
and lightning may exist also. The internet doesnt stop at layer1.
(Which would then leave people who are uninterested in changing client
software to handle layer2, as "layer1 will always be enough die-hards"
(in the refusing the future and facing the O(n^2) scaling wall or
centralisation death with perplexing optimism :) Ok, not so
constructive but maybe a gentle reminder that it is not constructive
in the reverse direction either to throw around often false
characterisations. We're here now to improve bitcoin so lets do that.
What I said here seemed like it maybe subject to misinterpretation so
to clarify:
On 19 June 2015 at 11:22, Dr Adam Back <adam at cypherspace.org> wrote:
> For example it could hypothetically allow 10MB blocks on
> one chain and 100kB blocks on the main chain. People say complexity,
> scary. Sure I am talking longer term, but we have to also make
> concrete forward progress to the future or we'll be stuck here talking
> about perilously large constant changes in 5 years time!
I should clarify that I meant there I was assuming we do one increase
within the next 12 months frame that gives buffer for 5 years r&d to
improve things and build layer2.
But if we do no R&D on layer2, and insist that clients can never
change to become layer2 aware, and layer2 is too hard etc then our
risk would be we'd be back in the discussion of kicking the can afresh
again in some years with some even more centralising size change.
Sure we should make the transition and introduction to layer2 and an
intermediate crunch smoother, but "20MB now or else" isn't really
helping. It did help get the conversation revived, but at this point
its a hindrance. Seriously a big hindrance. No offence but please
find a way to gracefully stop and rejoin the constructive process.
You can disagree on factors and points and be collaborative others
disagree frequently and have done productive work cordially for years
under the BIP process.
About scaling again:
Here is what I said before in my TL;DR post about my thoughts on how
we would start on throughput short-term to have space to do layer2
development.
> I think almost everybody is on board with a combination plan:
>
> 1. work to improve decentralisation (specific technical work already
> underway, and education)
> 2. create a plan to increase block-size in a slow fashion to not cause
> system shocks (eg like Jeff is proposing or some better variant)
> 3. work on actual algorithmic scaling
>
> In this way we can have throughput needed for scalability and security
> work to continue.
>
> As I said you can not scale a O(n^2) broadcast network by changing
> constants, you need algorithmic improvements.
>
> People are working on them already. All of those 3 things are being
> actively worked on right now, and in the case of algorithmic scaling
> and improve decentralisation have been worked on for months.
Btw I wonder if Gavin or Mike would be willing to answer another
question I forgot from my TL;DR post which was:
- Did you accept payment from companies to lobby for 20MB blocks? Do
you consider that something appropriate to publicly disclose if so?
Do you consider that user rights should come above or below company
interests in Bitcoin?
FWIW on pondering that last question "should user rights come above or
below company interests" I think my view of the guiding principle is
starkly clear to me: that user rights should be the primary thing to
optimise for. Businesses are providing service to users, their
interests are secondary in so far as if they are enabled to provide
better service thats good.
Bitcoin is a user p2p currency, with a social contract and a strong
user ethos. Importing and forcing company interests would likely be
the start of a slippery slope towards an end to Bitcoin. If we allow
business rights to be paramount it seems likely that we will end back
at the status quo as bitcoin payment processors grow, conglomerate and
become paypal/bank like or actual banks and then their interests and
exposures are the same as the banks and they'll want to import their
business models into Bitcoin and erode the user ethos features that
are actually what gives Bitcoin any meaning and value in the majority.
That wont be good for the companies either, but they may not see that
until they've killed it, many companies operate on a1 or 2 year
time-horizon. They may say screw layer2, I have a runway and I need
micropayments to the wazoo and I dont have the dev resources for that.
Thats a conflict and the resolution isn't to override bitcoin's
meaning, but rather that they should do it at layer2 (eg changeTip
does this.. simple trustme layer2 which is OK given the amounts). The
world needs a neutral social contract enforcing layer1. Layer1 must
be neutral and free from policy and dispute resolution otherwise
dispute resolution costs are imported and you lose viral open
innovation growth vector the internet benefitted from. Jurisdiction
and regulation related things belong at the interfaces and at the
payment protocol layer in my view. (If thats not obvious to some
lurkers I elaborate on that argument amongst other things here:
https://www.youtube.com/watch?v=3dAdI3Gzodo )
Adam
ps the O(n^2) misunderstanding of varying assumptions was explored at
length on reddit
http://www.reddit.com/r/Bitcoin/comments/3a5f1v/mike_hearn_on_those_who_want_all_scaling_to_be/csboslb
if people are interested in that topic. I do not think O( t*n ) is a
useful metric because its predictive but only of the obvious and
internal, the useful predictive thing is resources vs users (for
nodes/users or whole-system).

2023-06-07 15:38:47

- reply

📅 Original date posted:2015-06-19
📝 Original message:Nicely put Eric. Relatedly my initial experience with Bitcoin in
trying to improve bitcoin in fungibility, privacy & decentralisation,
I found some interesting things, like Confidential Transactions (that
Greg Maxwell has now optimised via a new generalisation of the
hash-ring signature construct he invented and with Pieter made part of
the alpha side-chain release) and a few other things.
As I went then to discuss and learn: a) what are the characteristics
needed for inclusion (clearly things need to fit in with how things
work, not demand massive rewrites to accommodate and to not conflict
with existing important design considerations), so that I could make
proposals in a practically deployable way, and then b) the
practicality of getting a proposed change that say people found
clearly useful. Then I bumped into the realisation that this is
actually really high risk to change, and consensus critical coding
security is very complex and there are some billion $ resting on
getting this rigidly correct under live conditions, so that deployment
must be cautious and incremental and rigorously tested.
So then I focussed instead on question of whether we could improve
bitcoins development model: how could we allow bitcoin to more rapidly
and agilely test beta features or try novel things to see how they
would work (as someone might do in a feature branch of a normal FOSS
project, to code and test a proposal for later addition), but with
criteria we want real bticoins so there is economic incentive as that
is actually part of the bitcoin protocol so you've not validated
something unless you're run it in a real network with money. I was
hypothesising therefore we need a way to run bitcoin beta network.
There's a thread about this here stretching back to may 2013.
Or similarly to run in parallel kind of subnets with different
trade-offs or features that are not easy to merge or high risk to
apply all at once to bitcoin with the inflight billions in capital and
transactions on it.
Anyway I thought that was a productive line of thinking, and generally
people seemed to agree and problem statement of 2wp: then 1wp
mechanism was proposed and then Greg extracted a concept from his
SNARK witness idea (which encapsulates a snark variant of a 2wp) but
now without snarks, then 2wp a conservative crypto 2wp proposal was
made. This was dec 2013 I think on wizards channel. The sidechain
alpha release now makes this a (alpha quality and so testnet coin, and
without DMMS peg) reality. I could imagine others who have a desire
to try things could elect to do so and copy that patch-set and make
more side-chains.
This is inherently non-coercive because you largely do not directly
change bitcoin by doing this, people elect to use which ever chain
suits them best given their usecase. If the sidechain is really early
stage it should have test-net coins in it not bitcoins in it, but
still its caveat emptor kind of beta chain, with good testing but
non-trivial to soft-fork on bitcoin but managable refactor a sidechain
to integrate something novel or try some existing feature (like the
segregated witness which robustly addresses malleability for example)
So I dont want to say side-chains are some magical solution to
everything, but its a direction that others may like to consider for
how to test or even run alternative trade-offs bitcoin side-chains in
parallel. For example it could hypothetically allow 10MB blocks on
one chain and 100kB blocks on the main chain. People say complexity,
scary. Sure I am talking longer term, but we have to also make
concrete forward progress to the future or we'll be stuck here talking
about perilously large constant changes in 5 years time!
This approach also avoids the one-size fits all problem.
Extension-blocks are an in-chain sub-net type of thing that has a
security boost by being soft-fork enforced (relative to side-chains
which are looser coupled and so more flexible relative to the simplest
form of extension-blocks)
Adam
On 19 June 2015 at 07:59, Eric Lombrozo <elombrozo at gmail.com> wrote:
> I don’t think the issue is between larger blocks on the one hand and things
> like lightning on the other - these two ideas are quite orthogonal.
>
> Larger blocks aren’t really about addressing basic scalability concerns -
> for that we’ll clearly need architectural and algorithmic improvements…and
> will likely need to move to a model where it isn’t necessary for everyone to
> validate everyone else’s latte purchases. Larger blocks might, at best, keep
> the current system chugging along temporarily - although I’m not sure that’s
> necessarily such a great thing…we need to create a fee market sooner or
> later, and until we do this, block size issues will continue to crop up
> again and again and economic incentives will continue to be misplaced. It
> would be nice to have more time to really develop a good infrastructure for
> this…but without real market pressures, I’m not sure it will happen at all.
> Necessity is the mother of invention, after all. The question is how to
> introduce a fee market smoothly and with the overwhelming consensus of the
> community - and that's where it starts to get tricky.
>
> ——
>
> On a separate note, as several others have pointed out in this thread (but I
> wanted to add my voice to this as well), maintenance of source code
> repositories is NOT the real issue here. The bitcoin/bitcoin project on
> github is a reference implementation of the Satoshi protocol…but it is NOT
> the only implementation…and it wasn’t really meant to be. Anyone is free to
> fork it, extend it, improve upon it, or create an entirely new network with
> its own genesis block…a separate cryptoledger.
>
> The real issue regarding XT is NOT the forking of source code nor issues
> surrounding commit access to repositories. The real issue is the *forking of
> a cryptoledger*.
>
> Open source repositories are meant to be forked - in fact, it is often
> encouraged. It is also encouraged that improvements be submitted for review
> and possibly merged back into the parent repository…although this doesn’t
> always happen.
>
> However, we currently have no mechanisms in place to support merging of
> forked cryptoledgers. Software, and most other forms of digital content,
> generally increases in value with more copies made. However, money is
> scarce…by design. The entire value of the assets of a decentralized
> cryptoledger rests on the assumption that nobody can just unilaterally fork
> it and change the rules. Yes, convincing other people to do things a certain
> way is HARD…yes, it can be frustratingly slow…I’ve tried to push for many
> changes to the Bitcoin network…and have only succeeded a very small number
> of times. And yes, it’s often been quite frustrating. But trying to
> unilaterally impose a change of consensus rules for an existing cryptoledger
> sets a horrendous precedent…this isn’t just about things like block size
> limits, which is a relatively petty issue by comparison.
>
> It would be very nice to have a similar workflow with consensus rule
> evolution as we do with most other open source projects. You create a fork,
> demonstrate that your ideas are sound by implementing them and giving others
> something that works so they can review them, and then merge your
> contributions back in. However, the way Bitcoin is currently designed, this
> is unfortunately impossible to do this with consensus rules. Once a fork,
> always a fork - a.k.a. altcoins. Say what you will about how most altcoins
> are crap - at least most of them have the decency of starting with a clean
> ledger.