<unnamed>

Public Key

npub18xqykhf26udeq2nyk98ee0a5q4w3s2f75m405a6zswpdy573lxeqmhg6zk

Profile Code

nprofile1qqsrnqztt54dwxus9fjtznuuh76q2hgc9yl2d6h6wapg8qkj20glnvspz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqwgxxnf

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:25:29 UTC

- reply

📅 Original date posted:2014-08-30
📝 Original message:> On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>> It would be nice if the issues and git repo for Bitcoin Core were not
>> on such a centralized service as github, nice and convenient as it is.
>
> Despite my complaining about github, I don't like the idea of moving
> somewhere else. The current way of working - to use github for storing
> the tree, and use a custom script for signing+merging - is fine with
> me.
>
> Github has a low barrier to contribution. Almost every open source
> developer already has a github account. Switching to something
> self-hosted makes it more difficult for people to contribute.
>
> Plus if we have to take the hosting upon ourselves, we have to handle
> sysadmin work ourselves as well. That's not a good use of the limited
> manpower available.
>
> Also it will be a lot of work to migrate over all the current issues
> and pulls. I don't look forward to that. I don't see the point of
> this, sorry.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
I agree with Wladimir, keep it simple. There being many other more urgent
questions to address, imho.

2023-06-07 15:23:32 UTC

- reply

📅 Original date posted:2014-07-07
📝 Original message:Wait, I thought SOCKS4 was supposed to help somehow in terms of prevention
of leaking of information?
Or maybe I am misremembering. Here's what I'm thinking of...
1) https://trac.torproject.org/projects/tor/wiki/doc/Preventing_Tor_DNS_Leaks
2) More regarding TOR,
"
I keep seeing these warnings about SOCKS and DNS information leaks. Should
I worry?
The warning is:
Your application (using socks5 on port %d) is giving Tor only an IP
address. Applications that do DNS resolves themselves may leak
information. Consider using Socks4A (e.g. via Polipo or socat) instead.
https://www.torproject.org/docs/faq#WarningsAboutSOCKSandDNSInformationLeaks
I'm not sure that means I'm screaming fire or anything, but isn't there
some good reason for SOCKS4 and SOCKS4A?
Or maybe another way to ask this is: Looking at an example in which
someone is running Tor, Privoxy, I2P, and FoxyProxy together while running
Bitcoin Core, would there be a problem with having a setting for SOCKS4A
for traffic in such a setup given the changes proposed to remove SOCKS4 as
suggested in bitcoin-development?
Probably there is just a simple answer to that last question, like "no."
But I thought I'd ask.
> On Wed, Jun 11, 2014 at 5:39 PM, Wladimir <laanwj at gmail.com> wrote:
>
>> If no one screams fire, we plan on removing support for it in the next
>> major release, for two reasons:
>>
>> - It would remove some crufty, hardly tested code paths
>>
>> - SOCKS5 offers better privacy as it allows DNS redirection
>
> Another one:
>
> - SOCKS5 supports IPv6
>
> Last call...
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community
> Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:22:53 UTC

- reply

📅 Original date posted:2014-06-16
📝 Original message:I have been noticing for some time the problem which Mike H. identified as
how we are bleeding nodes ~ losing nodes over time.
This link was referenced in the coindesk article of May 9, 2014:
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CANEZrP2rgiQHpekEpFviJ22QsiV%2Bs-F2pqosaZOA5WrRtJx5pg%40mail.gmail.com/#msg32196023
(coindesk article for reference: http://www.coindesk.com/bitcoin-nodes-need/)
The proposed solution is noted here as a portion of an issue at:
https://github.com/bitcoin/bitcoin/issues/4079
Essentially that part which has to do with helping reduce
the loss of nodes is as follows:
"a feature similar to that suggested by @gmaxwell that would process small
change and tiny txouts to user specified donation targets, in an
incentivized process. Those running full nodes (Bitcoin Core all the
time), processing their change and txouts through Core, would be provided
incentives in the form of a 'decentralizing lottery' such that all
participants who are running nodes and donating no matter how infrequently
(and no matter who they donate to) will be entered in the 'decentralizing
lottery,' the 'award amounts' (which would be distinct from 'block
rewards' for any mining) would vary from small to large bitcoin amounts
depending on how many participants are involved in the donations process.
This would help incentivize individuals to run full nodes as well as
encouraging giving and microdonations. The option could be expressed in
the transactions area to contribute to help bitcoin core development for
those that are setting up change and txouts for donations, regarding the
microdonation portion (which has also has been expressed conceptually at
abis.io"
This addresses the issue of how to incentivize more
interested individuals to run full nodes (Bitcoin Core). The lottery
concept (which would be applicable to anyone running the full node
regardless of whether or not they are mining) is attractive from the point
of view that it will complement the block reward concept already in place
which serves those who mine, but more attractive to the individual who
doesn't feel the urge to mine, but would like to have the chance of being
compensated for the effort they put into the system.
I hope that this leads to additional development discussion on these
concepts regarding incentivizing giving. This may also involve a process
BIP. I look forward to your remarks.
Respect,
Odinn

2023-06-07 15:15:07 UTC

- reply

📅 Original date posted:2014-03-11
📝 Original message:Hello,
I wanted to just add a very brief note to this discussion, that presently
for multisignature creation and management (new transaction etc) I've been
using this: https://coinb.in/multisig/
There were some initial bumps in the road but they were worked out,
see full thread more or less beginning from here:
https://bitcointalk.org/index.php?topic=390046.msg4687868#msg4687868
Curious as to what wallets actually support multisig / P2SH at this point?
Unsure. Am assuming more than previously.
> On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
>> On Tue, Mar 11, 2014 at 7:43 AM, Drak <drak at zikula.org> wrote:
>> > I very much like the idea of assuming each party uses HD wallets, that
>> > certainly simplifies things greatly.
>>
>> It also assumes a reality different from our current one.
>>
>
> Multisig wallets are a different reality from our current one, so when we
> move to that new reality we should do it correctly from the beginning.
>
> --
> --
> Gavin Andrese
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:14:37 UTC

- reply

📅 Original date posted:2014-03-04
📝 Original message:Nothing is safe.
Take risks. Engage one trouble at a time.
Perform unexpected actions.
Observe the results.
Rinse and repeat.
Ignore the lions. They too shall pass.
"Do not sleep under a roof. Carry no money or food. Go alone to places
frightening to the common brand of men. Become a criminal of purpose. Be
put in jail, and extricate yourself by your own wisdom."
-- Miyamoto Musashi (Niten Ichi-ryū)
> 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
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:11:44 UTC

- reply

📅 Original date posted:2014-01-15
📝 Original message:Yes. Good idea(s).
> Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>
> It definitely packs a marketing punch which could help drive adoption. The
> feature is only useful if/when broadly adopted.
>
> I think it meets all the criteria required:
>
> - Communication between parties is a single message from the payee,
> which may be public
> - Multiple payments to the same address are not publicly linkable on
> the
> blockchain
> - The payee has explicitly designated they expect to receive more than
> one payment at that address
> - Payer can publicly prove they made a payment to the reusable address
> by revealing a secret
>
> I have high hopes for this feature. The war *against* address reuse may
> soon be a distant memory.
>
> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik at bitpay.com>
> wrote:
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>>
>> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell at gmail.com>
>> wrote:
>>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
>>> <bendavenport at gmail.com> wrote:
>>>> But may I suggest we consider changing the name "stealth address" to
>>>> something more neutral?
>>>
>>> ACK. Regardless of the 'political' overtones, I think stealth is a
>>> little cringe-worthy.
>>>
>>> "Private address" would be fine if not for confusion with private-keys.
>>>
>>> "Static address" is perhaps the best in my view. (also helps improve
>>> awareness that normal addresses are intended to be more
>>> one-use-ness)------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:11:38 UTC

- reply

📅 Original date posted:2014-01-14
📝 Original message:Hello Peter et. al.
As I read more into this stealth discussion I am curious to know what you
think of the background microdonation concept I posted recently.
It is shown in full here
http://sourceforge.net/mailarchive/message.php?msg_id=31837430
Given the lengthy nature of the concept as presented I would be happy to
distill it further, but I am interested in your thoughts as to the idea
generally and how to further present it.
-Odinn
> On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote:
>> It's a given this will be implemented for Payment Protocol. The question
>> is whether it's also usable outside of PP.
>
> I think what stealth addresses is showing is that the concept of an
> address being "instructions on how to generate a txout/tx that results
> in me getting Bitcoins" is actually quite valuable; it and
> BIP32-derivation addresses with chaincodes are pretty clear cases where
> just replacing address with scriptPubKey isn't sufficient.
>
>> I was kind of imagining that we could encourage people to replace all
>> their static address text that live on Github pages, and README.me, and
>> forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention
>> could be to require only transporting xSTL addresses within a URI, even
>> going so far as to not support them copy/pasted. 101 characters is not
>> much longer (and sometimes shorter) than PaymentRequest URIs end up
>> being.
>
> Yeah, I don't see anything wrong with stealth addresses whatever length
> they wind up being. It's a good intermediate step, and without them
> people will just pass around unsigned payment requests and other stuff.
>
>> I think there are ways to make stealth addresses easy enough to use that
>> people actually prefer using them for P2P payments which do not involve
>> a
>> full-stack merchant. In that case, if it was a PaymentRequest it would
>> almost certainly not be signed, and would be more easily shared over
>> email
>> or SMS as a URI than as a file attachment or, even worse, putting the
>> unsigned PR file up on a third-party server which probably won't do a
>> good
>> job securing it.
>
> At the DarkWallet hackathon we had discussed how to integrate stealth
> addresses into OpenPGP keys as a new user id type for instance, and
> similarly into x.509 certs.
>
> The big advantage here is the identity of *who* you are paying is
> important, not just "I got this signed payment request". Basically the
> concept becomes "identity signed payment address" and the signature
> binding the identity to the address is a one time and offline thing; an
> issue with the payment protocol as it stands is that it encourages
> signing keys to be kept online to issue payment requests. If you have a
> scheme where the private keys that bound the identity to the address can
> be kept offline you're much better off, because the attacker can only
> create a fake payment request, they can't divert the funds to
> themselves.
>
> So with that in mind, I strongly suggest sticking with defining a
> reasonable stealth address spec. But when you do, keep in mind that you
> may want to upgrade it in the future, preferably in a backwards
> compatible way. Also, it shouldn't be limited to exactly 2-of-2
> CHECKMULTISIG, there's no reason why n and m can't be picked as needed.
> Sure, it means the addresses are not fixed length, but for something
> that is mostly an internal detail and only occasionally visible to
> advanced users, I see no issues there.
>
> Along those lines: what would a BIP32 chain code address look like? What
> happens when you want to use that with a multisig-protected wallet?
>
>> * PP Implementation Overview *
>>
>> The basic PaymentRequest>PaymentDetails is expecting 'output' containing
>> one or more TxOuts with script and amount. I believe the general
>> approach
>> is to put a fallback address into 'output' for backward compatibility,
>> and
>> put Q and Q2 into an extension field.
>>
>> So we add a new optional field to PaymentDetails which contains the one
>> or
>> two PubKeys. Not sure if we want different protobuf tags, or if the
>> difference in length of the value makes it obvious enough which approach
>> is being used;
>>
>> optional bytes stealthOnePubKey = 1000
>> optional bytes stealthTwoPubKey = 1001
>
> I think you're missing the bigger picture here, not least of which is
> that backwards compatibility is a bit of a misnomer for an unreleased
> standard. :)
>
> Why put this into the PaymentDetails? That a stealth address is to be
> used for the payment is a property of the outputs being requested, not
> the payment itself. We're better off if that goes into the Output
> message, and further more it suggests that the Output message shouldn't
> contain raw scriptPubKey's but rather addresses. After all, IsStandard()
> means we have to inspect the scriptPubKey to see if we can even pay to
> what the sender is requesting.
>
> Once you establish that it's addresses that Outputs specify, then it's
> easy enough to make a stealth address type, or a BIP32-chain-code
> address type, or whatever else comes up in the future.
>
>
>> Also, ideally I think I would want multiple different stealth payments
>> within a single wallet to the same merchant / pubkeys to be identifiable
>> as such.
>
> Agreed.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:10:28 UTC

- reply

📅 Original date posted:2013-12-10
📝 Original message:I've been lurking on this convo since it began, but I wanted to say
thanks, theymos
cheers to you all and yay for decentralization, wherever it leads.
-odinn
muh latest: http://github.com/ABISprotocol/ABIS
> On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:
>
> It's not just about trust, there is the robustness factor: what if he
> becomes sick, unavailable, hit by a bus? Others need the ability to
> pickup and run with it. The control over the domain (including ability
> to renew registration, alter nameservers) needs to be with more than
> one person. That's why I suggest using the same people who have control
> over the software project at sf,github
>
>
> The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
>
> SSL is probably a good idea, and it's probably also a good idea to
> separate bitcoin.org from Github. I don't know that I trust Github. I'm
> sure that you can find a sponsor for a dedicated server. Let us know if
> DNS changes to bitcoin.org are required.
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>