Edmund Edgar [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-03-04 to 2017-03-07
💬 Posted a total of 8 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 17:57:05

- reply

📅 Original date posted:2017-03-06
📝 Original message:On 7 March 2017 at 08:23, Gareth Williams <gjw at posteo.net> wrote:
> What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees with.
Well, they'd be censoring transactions to prevent the thing from
activating in the first place. (As opposed to censoring a subset of
those transactions to enforce the new rule, which is the behaviour
that the people promoting the change want.) There would be no point at
which people reasonably expected that something useful would happen if
they sent funds to an address protected by the new scripting rule.
> Bitcoin only works if the majority of hashpower is not hostile to the users.
This is true. But what we're talking about here is hostility to *a
particular proposal to change the network rules* which is (in this
hypothetical case) supported by the economic majority of users. This
doesn't, in itself, break Bitcoin, although the economic majority are
of course always free to hard-fork to something new if they're
unhappy.
Edmund
--
--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp
Reality Keys
@realitykeys
ed at realitykeys.com
https://www.realitykeys.com

2023-06-07 17:57:04

- reply

📅 Original date posted:2017-03-06
📝 Original message:On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> User activated soft forks, or perhaps more accurately called 'economically
> forced soft forks' are a tool to use if the miners are in clear opposition
> to the broader economy.
I don't think they work for that, at least not for new features,
because miners will presumably just head the whole thing off by
orphaning the whole class of non-standard transactions that are the
subject of the fork. In the SegWit case, they'd just orphan anything
that looks like a SegWit transaction, valid or not. That way they
don't need to worry about ending up on the wrong side of the upgrade,
because no transaction affected by the proposed rule change will ever
get into the longest chain. Rational node operators (particularly
exchanges) will likely also adopt their stricter rule change, since
they know any chain that breaks it will end up being orphaned, so you
don't want to act on a payment that you see confirmed in it. So then
you're back where you started, except that your soft-fork is now a
de-facto hard-fork, because you have to undo the new, stricter rule
that the miners introduced to head off your shenannigans.
Where they're interesting is where you can do something meaningful by
forcing some transactions through on a once-off basis. For example, if
the Chinese government identified an address belonging to Uighur
separatists and leaned on Chinese miners to prevent anything from that
address confirming, it might be interesting for users to say, "If
these utxos are not spent by block X, your block is invalid".
They might also be interesting for feature upgrades in a world where
mining is radically decentralized and upgrades are fighting against
inertia rather than opposition, but sadly that's not the world we
currently live in.
--
--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp
Reality Keys
@realitykeys
support at realitykeys.com
https://www.realitykeys.com

2023-06-07 17:55:43

- reply

📅 Original date posted:2017-01-26
📝 Original message:On 26 January 2017 at 18:20, Johnson Lau via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>You can’t anti-replay if you don’t even know a hardfork might happen. And I think your hypothesis (replay reduces the incentive of split) is not supported by the ETC/ETH split.
I agree with the general point you're making, but you *could*
anti-replay without knowing about the fork, at least from a few dozen
blocks into it. For example you could allow transactions to specify a
recent block hash (or some of the bytes thereof) and declare that they
want to be invalid if that block isn't in the parent chain.
This would potentially have benefits beyond economic hard-fork
situations: As a general principle, if the network that you're
transacting with doesn't look like the one you think you're
transacting with, you're going to have a bad day.
--
--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp
Reality Keys
@realitykeys
ed at realitykeys.com
https://www.realitykeys.com

2023-06-07 17:54:36

- reply

📅 Original date posted:2016-11-29
📝 Original message:On 30 November 2016 at 05:56, Erland Lewin via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This proposal describes a consistent way to create s type of p2sh addresses
> (“Boolean addresses”) which can be redeemed by an arbitrary set of keys and
> multi signatures combined with logical and/or operations.
>From our point of view at Reality Keys ( https://www.realitykeys.com )
I can confirm that
1) The pain point this proposal aims to fix is indeed painful.
2) This would be very helpful, if wallet authors actually adopt it.
3) The implementation as described so far looks sensible.
--
--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp
Reality Keys
@realitykeys
ed at realitykeys.com
https://www.realitykeys.com

2023-06-07 15:43:05

- reply

📅 Original date posted:2015-07-23
📝 Original message:> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.
This is a really interesting thread. Since we're no longer talking
about a consensus of the core committers, which would be central
control, but instead something broader, could you say a bit more about
what this consensus might look like, and how we'll know if we've got
one?
In plain language "no controversy" sounds like very high bar for a
diverse community like this; Even bringing in P2SH kicked up a fair
bit of fur and feathers. Do you have a definition in mind where it
isn't an _impossibly_ high one?
--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp
Reality Keys
@realitykeys
support at realitykeys.com
https://www.realitykeys.com

2023-06-07 15:14:38

- reply

📅 Original date posted:2014-03-08
📝 Original message:On 8 March 2014 17:10, Alan Reiner <etotheipi at gmail.com> wrote:
> I create a new keypair, <c_pub> with <c_priv> which I know (it can be any
> arbitrary key pair). But I don't give you <c_pub>, I give you <b_pub> =
> <c_pub> minus <a_pub> (which I can do because I've seen <a_pub> before
> doing this).
>
> Sure, I don't know the private key for <b_pub>, but it doesn't matter...
> because what
>
> <b_pub> + <a_pub> = <c_pub> (mine)
>
> You have no way to detect this condition, because you don't know what
> c_pub/c_priv I created, so you can only detect this after it's too late
> (after I abuse the private key)
>
Thanks Alan and Forrest, that makes sense. So to salvage the situation in
the original case, we have to make sure the parties exchange their public
keys first, before they're allowed to see the public keys they'll be
combining them with.
--
--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp
Reality Keys
@realitykeys
ed at realitykeys.com
https://www.realitykeys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140308/ef8e3571/attachment.html>

2023-06-07 15:14:37

- reply

📅 Original date posted:2014-03-08
📝 Original message:On 4 March 2014 14:07, Odinn Cyberguerrilla <odinn.cyberguerrilla at riseup.net
> wrote:
> Nothing is safe.
>
This is true. To rephrase, imagine I gave you an ECC public key <ed_pub>,
you gave me back a public key <odinn_pub> of your own devising, then I paid
some money to the address resulting from add_pubkeys(<ed_pub>,<odinn_pub>)
[1]. Can anyone either:
a) Think of a way that Odinn could make an <odinn_pub> such that they could
spend the resulting money without having <ed_priv>.
b) Opine, somewhat knowledgeably, that this probably wouldn't be an easy
thing to do, and they wouldn't be alarmed to see people running software
that did this kind of thing.
[1]
https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/main.py#L173
--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp
Reality Keys
@realitykeys
ed at realitykeys.com
https://www.realitykeys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140308/5bc2b0c7/attachment.html>

2023-06-07 15:14:36

- reply

📅 Original date posted:2014-03-04
📝 Original message:Some people may have seen my service Reality Keys, which can perform a role
a bit like an External State Oracle as described previously by Mike Hearn
and others. (I like to think of it as a Certificate Authority for
propositions, doing for facts what Verisign do for identities.) You
register a possible outcome with us, we publish a public key for "yes" and
another for "no", and once the outcome happens or fails to happen, we
publish the appropriate private key.
A few people have been asking for advice on the best way to use our keys to
make m-of-n contracts, where each party locks up their stake in a
transaction, then the winner gets their private key from Reality Keys and
uses it to release the funds. Peter Todd suggested what seems like a very
nice way to do this without needing non-standard transactions or refund
transactions. I've had a go at implementing it and it seems to work, but I
don't know enough about this to distinguish the ECC bit of it from magic,
so I'm wondering if people who do understand it could comment on whether
it's a safe thing to be doing.
What I'm trying to do here is to combine the public key of each party with
the public key of the outcome they're representing, eg I make a public key
with:
<alice-pub> + <reality-key-yes-pub>
...and another with:
<bob-pub> + <reality-key-no-pub>
That goes into a 1/2 P2SH address (in the simplest possible case), which is
spendable by one of Alice or Bob after the outcome occurs with either:
<alice-priv> + <reality-key-yes-priv>
...or
<bob-priv> + <reality-key-no-priv>
I'm making the transaction with add_pubkeys, then spending it with
add_privkeys, both from:
https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/main.py#L173
What's worrying my superstitious mind is that knowing <reality-key-no-pub>
before he has to produce <bob-pub>, I'm wondering if there's something Bob
could do with <bob-pub> to intentionally weaken the resulting (<bob-pub> +
<reality-key-no-pub>) so that he could sign a transaction with it without
needing to know <reality-key-no-priv>.
My example script (and specifically the bit that's scaring me) is here:
https://github.com/edmundedgar/realitykeys-examples/blob/master/realitykeysdemo.py#L247
PS. I hope I'm not too far off-topic. Peter Todd suggested it might be
worth talking about here as it potentially has implications for other
protocols. If people prefer to respond at bitcointalk instead, we've been
discussing it here:
https://bitcointalk.org/index.php?topic=260898.60
--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp
Reality Keys
@realitykeys
ed at realitykeys.com
https://www.realitykeys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140304/868b6814/attachment.html>