Odinn Cyberguerrilla [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-12-04 to 2014-08-30
💬 Posted a total of 29 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub18xqykhf26udeq2nyk98ee0a5q4w3s2f75m405a6zswpdy573lxeqmhg6zk

Profile Code

nprofile1qqsrnqztt54dwxus9fjtznuuh76q2hgc9yl2d6h6wapg8qkj20glnvs84vzvy

Author Public Key

npub18xqykhf26udeq2nyk98ee0a5q4w3s2f75m405a6zswpdy573lxeqmhg6zk

Show more details

Last Notes

2023-06-07 15:25:29

- 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:38

- reply

📅 Original date posted:2014-07-07
📝 Original message:Just as an aside to this lengthy convo, the Cryptonote-based BCN recently
had some interesting updates which made it easier for ordinary computers
(nothing special) to handle it.
I realize that's not Bitcoin, but I thought I'd throw it out there.
> Thanks Mike.
>
> Indeed, I am aware of current approach, which is why I was suggesting
> this as an alternative.
> I haven't thought about it enough, and perhaps it was too radical a
> rethinking - just wanted to see what the smarter minds thought.
>
> Thanks again.
>
> -Randi
>
> On 7/5/14, 4:43 AM, Mike Hearn wrote:
>>
>> Is it possible instead to allocate a portion of the reward to " a #
>> of
>> runner up(s)" even though the runner-up(s) block will be orphaned?
>>
>>
>> There's really no concept of a "runner up" because hashing is progress
>> free. It's unintuitive and often trips people up. There's no concept
>> that everyone is 95% of the way to finding a solution and then someone
>> pips you to the post. It's more like playing the lottery over and over
>> again. Doesn't matter how many times you did it before, the next time
>> your chances are the same.
>>
>> A better concept is of rewarding "near miss" solutions which is what
>> we already do of course, via pools, which pay you for shares which
>> don't quite meet the difficulty target but almost do. So the question
>> is how can we implement pools which have this reward structure (which
>> obviously works well) without miners simultaneously giving up their
>> right to block creation either due to technical problems or sheer
>> lazyness.
>
> ------------------------------------------------------------------------------
> 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:23:33

- reply

📅 Original date posted:2014-07-07
📝 Original message:> On Mon, Jul 7, 2014 at 8:34 AM, Odinn Cyberguerrilla
> <odinn.cyberguerrilla at riseup.net> wrote:
>> Wait, I thought SOCKS4 was supposed to help somehow in terms of
>> prevention
>> of leaking of information?
>
> SOCKS4a (unlike SOCKS4) supports doing DNS lookups on the server, but
> it is not supported by bitcoin core. So it is not part of this
> discussion.
>
> And SOCKS5 can do all of that just as well. But if you feel like
> contributing SOCKS4a support that's fine with me.
>
> Wladimir
>
OK, thanks Wladimir.

2023-06-07 15:23:32

- 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:23:06

- reply

📅 Original date posted:2014-06-17
📝 Original message:Hoping that this is the right place for this, I am asking a question as to
what happens with what is in the CoinJoin bounty fund address at:
http://blockchain.info/address/3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk
(a P2SH / multisignature address)
I encouraged people to donate to it in late 2013 (around mid-November)
after seeing some reddit discussions ~ I think the original one I saw was
at
http://www.reddit.com/r/Bitcoin/comments/1qmhkh/coinjoin_fundraising_drive/
Since that time I know it's been implemented in various places, such as
things seen floating about the web with some relation to CoinJoin or
another:
such as:
https://github.com/calafou/coinjoin
and blockchain.info
https://twitter.com/blockchain/status/402224010492006400/ |
https://github.com/blockchain/Sharedcoin
etc..
I'm curious what the CoinJoin bounty fund supports at this point and where
it's intended to go (I assume, CoinJoin related stuff, but I'm interested
to know a bit more detail). And if it will help fund other things I am
curious about what those other things are too.
Again, hopefully the bitcoin-development list is the right place for this
question, I felt it would be better asked here rather than on twitter or
similar.
Respect,
Odinn

2023-06-07 15:22:56

- reply

📅 Original date posted:2014-06-17
📝 Original message:> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/16/2014 07:00 PM, Justus Ranvier wrote:
>> There can be multiple independent transport networks for Bitcoin.
>>
>> There already is: ipv4, ipv6, Tor, and native_i2p (out of tree
>> patch).
>>
>> As long as multihomed hosts that act as bridges then information
>> will propagate across all of them. -- Justus Ranvier
>> ----------------- sent with R2Mail2
>>
>> ----- Original Message ----- From: Matt Whitlock
>> <bip at mattwhitlock.name>
>>> Now another concern: won't this proposal increase the likelihood
>>> of a network split? The free-market capitalist nodes will want to
>>> charge their peers and will kick and ban peers that don't pay up
>>> (and will pay their peers to avoid being kicked and banned
>>> themselves), whereas the socialist nodes will want all of their
>>> peers to feed them transactions out of the goodness of their
>>> hearts and will thus necessarily be relegated to connecting only
>>> to other altrustic peers. Thus, the network will comprise two
>>> incompatible ideological camps, whose nodes won't interconnect.
If the technical development emanating from the proposal follows a design
which ensures that the notion of whether or not someone were to donate
remains voluntary in nature (there's never any requirement that someone
donate to anyone, but incentives can be made), then I don't feel that
network split would be an issue, because it's just an issue of choice.
Justus Ranvier suggested a system which would naturally include
pay-to-play networks, and not just free P2P networks. The question of how
to limit the number of entries the system registers in the framework of
the proposed 'decentralizing lottery' would be fairly straightforward,
there could one entry for a distinct period of time (say 30 days as an
example) for anyone who meets the suggested criteria of:
"those running full nodes (Bitcoin Core (...)), 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,'" for a
chance to receive "the 'award amounts'"
In my mind I imagine that the smart property qualities of Bitcoin may
eventually enable people to represent what sort of time and energy they
are putting into maintaining the network, so that rather solely a currency
aspect, people who have done something collaborative with each other to
help advance or develop Bitcoin would be able to show in their donations
field that they have a smart property, which could be also expressed in
equivalence terms as a value of a certain amount of btc, would also be
able to have the smart property representing their voluntary efforts
represented and given a voice in the blockchain, whether or not they want
to participate in such a 'decentralizing lottery.' In point of fact, I
contemplate that all aspects of this, at least ideally (to me) should be
voluntary, such that if a person is donating through this system, that is
voluntary, if they wish to have their donations result in a chance at
winning the 'decentralizing lottery,' that is voluntary / an option, and
if they win, they would have the option to accept the winnings or return
them (the bitcoin 'award amount') back to the network.
>
> Also consider that currently there are many people have already
> demonstrated a willingness to donate bandwidth and resources to the
> public by running nodes, so those people aren't going to disappear.
>
Those who are already dedicated to running nodes will likely (mostly)
remain, but any ideas reaching technical development and reality as a
result of this concept would be intended to help grow that base by
bringing in persons who might not otherwise be as interested to do so.
> They could operate mixed-mode nodes, with a fraction of the allowed
> incoming connections reserved for free peer, with free connections
> might be limited in terms of time duration. Bitcoin-accepting
> brick-and-mortars would probably allow free access to anyone connected
> to their internal wifi to facilitate people wanting to pay.
That's a great idea. The incentives could certainly go beyond just
pointing to Bitcoin Core. Giving is important to everyone.
>
> Crowdfunded free bridges, assurance contracts, etc are all other ways
> to let people get into the network with no upfront cost.
>
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQEcBAEBAgAGBQJTn1mwAAoJEMP3uyY4RQ21ePwIALpMV/GDpAyD4SeL6hWi32vQ
> 197YD1LPuLWrEbUs/+gl1Sk2gIsWWlq/o86KcP7Cn4fZdBAKEiF5RpQ6iPsO2+bj
> JR0W/EbgUyzIhYaxFysCzQ1HPzQx+0a2vHn/6FsB7YMha8gvxviF7InDEwcfxbok
> o0QS5SeYWryp5mH7IokC6fLYsAPmiueugPVRSD/l8IRFYWVFS9nB+XAR1PWAdYSQ
> Xyzu9oyPwlKAjYKxl4XHYB4DofacS89DpWMVbWHviYiZ7UufmzMgwPtfMCsQAxSb
> q3OMAkcSGJZL8pcy9/9NWpOGAHY2DRtGtu8oSqXcBSW/IQCubmUNmzopt8O/H74=
> =9hrW
> -----END PGP SIGNATURE-----
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:22:53

- 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:21:52

- reply

📅 Original date posted:2014-05-21
📝 Original message:> I completed a whitepaper for Bitcoin a proof-of-stake version which uses a
> single nomadic verifiable mint agent and distributed replication of a
> single blockchain by compensated full nodes to achieve 6-hop, sub-second
> transaction acknowledgement times. Plus it pays dividends to holders
> instead of wasting it on miners. Subsidized transaction fees are thus
> lower.
I look at this and agree of course that the nodes are decreasing, see,
https://getaddr.bitnodes.io/ But when I see stuff in the white paper
like "misbehaving nodes" in the context of an "audit agent," a "single
non-forking blockchain," the notion of "Misbehaving nodes" that would be
"banned from the network" so as to "motivat(e) honest behavior," ~ really,
all of this does sound as though a sort of morality is being formulated
rather than a mathematical solution.
This is not to say that the white paper hasn't addressed a problem that
needs to be addressed, namely... the problem of the nodes disappearing,
and a few other things. But to take that and then layer onto that the
issues associated with proof of stake... There does seem to be a simpler
way to address this and I think first without suggesting the complex issue
of some kind of thing that would involve dividends for those in a
proof-of-stake system, consensus achieved by stake-weighted voting, and so
forth, one would be better off removing all references to voting and
stake, and determining ways simply to incentivize more substantively those
who actually run a full node. Additionally I am hesitant to characterize
behavior as has been described in the white paper, as it would seem that
(in such a system) there would be an inclination or a tendency to exclude
certain patterns or groups of participants rather than determine ways in
which all participants or potential peers can serve the network.
>
> https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE
>
>
> Because the code is not yet written, this idea is half-baked so to speak.
> Comments appreciated on my project thread, which will be a development
> diary. I plan a hard fork of the Bitcoin blockchain in early 2016, after a
> year of public system testing, and conditioned on wide approval.
>
> https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403
>
> -Steve
>
> Stephen L. Reed
> Austin, Texas, USA
> 512.791.7860------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:21:01

- reply

📅 Original date posted:2014-05-05
📝 Original message:I am curious if the Android developer who had been working on two factor
authentication and bitcoin had worked toward an open issue or pull
request? I had been looking around for some sign that this had occurred
but hadn't found it, I am interested to know what is the progress in this
area (in a fully decentralized way that resides fully on one's device or
devices).
For some reason maidsafe keeps rising up in my brain, have bitcoin core
developers touched bases with maidsafe developers on these kind of fine
points?
Just thoughts and questions.
-Odinn
> On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach
> <andreas at schildbach.de> wrote:
>> On 02/18/2014 08:14 PM, Ryan X. Charles wrote:
>>> BitPay is working on a new standard
>>> based on bitcoin-like addresses for authentication. It would be great
>>> if
>>> we could work with the community to establish a complete, decentralized
>>> authentication protocol.
>>
>> Sounds interesting, let us know as soon as you have anything.
>
> SINs. See https://en.bitcoin.it/wiki/Identity_protocol_v1
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&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:19:55

- reply

📅 Original date posted:2014-04-24
📝 Original message:Thanks for this reminder, I will bring this up with some others who I
think may be able to help in this area and dedicate some time. I may be
able to free up some time with a little language work as well.
> You do not need to be a developer to help in the improvement of Bitcoin.
>
> http://sourceforge.net/p/bitcoin/mailman/message/32255092/
> Bitcoin Core 0.9.2 feature freeze is May 13th, 2014. Now is the time for
> native non-English speakers to join Transifex to clean up the translations
> in all languages. This is important for more than just Bitcoin because
> Litecoin will use these same translations.
>
> *What should volunteer translators do?*
> https://bitcointalk.org/index.php?topic=571414
> Try the nightly builds of Bitcoin Core as it heads toward 0.9.2. Not
> recommended for your production wallet.
>
> https://www.transifex.com/projects/p/bitcoin/
> Join Transifex as a translator and add your account to your language.
>
> https://groups.google.com/forum/#!forum/bitcoin-translators
> Join the Translator mailing list to receive announcements when
> translations
> are needed for Bitcoin. You will also receive notifications if other
> Bitcoin Project things in Transifex need translations (likely
> bitcoin.org).
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:15:53

- reply

📅 Original date posted:2014-03-19
📝 Original message:I wish to state that I fundamentally disagree with this proposal of use
cases for W3C payments workshop. Please read my following explanation and
then do what you will:
At one time I was invited to join the Web Payments conference calls. I
considered it and then declined due to the very CLAs that Brent mentioned
in the message that started this thread.
I was trying to remember the language that I objected to relating to the
W3C CLA. Found it: https://web-payments.org/minutes/ As mentioned, I was
offered to join these calls but I declined due to, in part, the following:
Upon review of the page at web-payments.org, I noticed that it provides
a means to connect with web payments group by teleconference. However,
there is an agreement that the site would require me to accept merely to
join the teleconference and collaborate with others in the web payments
group. I would say "unfortunately," but in my case I will say
fortunately, I don't agree with the required agreement as shown here at
http://www.w3.org/community/about/agreements/cla/ which is shown as
follows at https://web-payments.org/minutes/ "There are no costs
associated with joining the group or limitations on who may join the
teleconference as long as they agree to the Web Payments community "
Some of the things I don't like about the proposed agreement /
"requirement" are fundamental. At the core, it should be understood that
collaborative efforts, or teleconferences involving innovators who strive
to develop concepts for eventual development of a social good, for
example, should not be subject to a "requirement" that anyone agree to a
license in relation to their participation or contribution. Such
"requirements" inhibit innovation and free thought. For example, the web
payments group provides that in order for me to participate, I must first
"agree to license my Essential Claims under the W3C CLA RF Licensing
Requirements" and numerous other requirements.
Although I was interested in some sort of collaboration with the Web
Payments Community Group, these CLAs - lengthy, burdensome, and in my
personal view, highly dubious and potentially restricting with respect to
innovation and free thought - caused me to reconsider, and thus I will not
be entering into web or telephone conferences or related collaborations
with the W3C / Web Payments folks until such time as they remove these
burdensome requirements which are applied merely to join a call.
> Hello Bitcoiners,
>
> I have been working on some use cases for the W3C payments workshop. I'd
> like to include Bitcoin, but I might not have the time:
>
> Here is what I have:
>
> https://www.w3.org/community/webpayments/wiki/WebPaymentsMobileUseCases
>
> Which is editable with a w3c username and password. Just be a member of
> the
> webpayments community group: http://www.w3.org/community/webpayments/
>
> More formally you can submit a pull request to:
>
> https://github.com/w3c-webmob/payments-use-cases
>
> -------------
>
> Due to discussions with others am attempting to apply the following
> template:
>
>
> Name: name of the solution
> Use Cases: Key use cases for the solution
> Regions and currencies: Any SDKs or APIs which are available to developers
>
> with the following things to consider (for use cases):
> (1) add real money to the service
> (2) buy a physical good in the real wold (e.g., a cup of coffee)
> (3) pay for physical service (e.g., gym membership)?
> (4) convert virtual money back into paper money
> (5) transfer money from one person to another (even if the second person
> is
> not signed up for the service)?
> (6) buy product online
> (7) resolve disputes?
> (8) view transactions?
> (9) secure the wallet
> (10) etc.
>
> Thanks for your time and have a great day!
>
> -Brent Shambaugh
> ------------------------------------------------------------------------------
> 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:15:41

- reply

📅 Original date posted:2014-03-14
📝 Original message:Hello,
I see a lot of talk on this topic and get the senst that it is focused on
default display only regarding the mBTC / uBTC questions. However, if the
focus is broader, involving whether or how to express other currencies or
moving further along to what that might even mean (since many people have
different ideas about what a currency is) perhaps there is another issue
to open, or a process BIP to address how to display other concepts, for
example:
other currencies
microdonations
etc.
I sense however that may be outside the scope of this thread, so I'll just
stop here and try to read samples of the other stuff going on here.
-Odinn
http://abis.io
> Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks
> ago, which was disappointing -- it sounded like the consensus was
> uBTC, and moving to uBTC later --which will happen-- may result in
> additional user confusion, thanks to yet another decimal place
> transition.
>
>
>
> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w at grabhive.com> wrote:
>> We're with uBTC too. Been waiting for the signal to do this, let's do it
>> right after the fee system is improved.
>>
>> -wendell
>>
>> grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411
>>
>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>>
>>> Go straight to uBTC. Humans and existing computer systems handle
>>> numbers to
>>> the left of the decimals just fine (HK Dollars, Yen). The opposite is
>>> untrue (QuickBooks really does not like 3+ decimal places).
>>
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> 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:15:07

- 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:44

- reply

📅 Original date posted:2014-03-06
📝 Original message:One wonders also re. bitmessage, though that may not be relevant to this
particular list.
> On Wed, Mar 05, 2014 at 11:21:52AM -0500, Kevin wrote:
>> On 3/5/2014 7:49 AM, Mike Hearn wrote:
>> >A new practical technique has been published that can recover
>> >secp256k1 private keys after observing OpenSSL calculate as little
>> >as 200 signatures:
>>
>> How can we patch this issue?
>
> If you're following good practices you're not particularly vulneable to
> it, if at all, even if you make use of shared hosting. First of all you
> shouldn't be re-using addresses, which means you won't be passing that
> ~200 sig threshold.
>
> More important though is you shouldn't be using single factor Bitcoin
> addresses. Use n-of-m multisig instead and architect your system such
> that that every transaction that happens in your service has to be
> authorized by both the "online" server(s) that host your website as well
> as a second "hardened" server with an extremely limited interface
> between it and the online server. The hardened second factor *should*
> use a separate codebase, ideally even a second language, to authenticate
> actions that withdraw funds or generate new addresses based on data
> given to it by the online server. In the best case your customers are
> PGP-signing requests so you can verify their intent independently and
> cryptographically on both servers. Mircea Popescu's MPEx exchange is an
> example of this model, although I don't think they're doing any multisig
> stuff. Failing that you can at least use the second server to do things
> like limit losses by flagging higher-than-expected withdrawl volumes and
> unusual events.
>
> Since this second-factor server only deals with business logic - not the
> website - you can certainly find a secure hosting arrangement for it
> with physical control. I recommend you stick the machine in your
> apartment and use tor + hidden services to connect to it from your VM
> instances.
>
> Note too that even if all you're doing is accepting Bitcoins from
> customers, perhaps in exchange for goods, all of the above *still*
> applies modulo the fact that the payment protocol is very incomplete.
>
>
> With P2SH (finally!) supported in all the major Bitcoin wallets there
> simply is no excuse not to have such an architecture other than lazyness
> and transaction fees; if you fall into the latter category you're
> business may very well be wiped out anyway by increased fees.
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
> ------------------------------------------------------------------------------
> 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:14:37

- 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:14:34

- reply

📅 Original date posted:2014-03-03
📝 Original message:Hi, you may want to check this out:
http://www.reddit.com/r/Bitcoin/comments/1rh2h0/developers_core_developers_contributors/
Cheers,
-Odinn
http://abis.io
> Hey, folks. Sorry if this is documented somewhere -- if so, just point me
> at it. I couldn't find it, though.
>
> I'm a (non-developer) writer with experience in open-source communities,
> and I'd like to contribute with writing/editing/marketing. What's the
> procedure? Is there someone in charge of that area?
>
> Two examples:
>
> 1) Gavin recently asked for proofreading of 0.9.0rc2, but it was unclear
> how to send the changes. (There are many possibilities, some better than
> others. Git? Google Docs with revisioning? Microsoft Word with Track
> Changes? The Bitcoin wiki?)
>
> 2) The page at https://en.bitcoin.it/wiki/BitcoinPayment says that "the
> wiki receiving wallet (for the wiki itself) is also MtGox". Umm, I rather
> doubt that. :-P But I'm not sure what the current info is, or whom to
> alert.
>
> Off-list replies welcome. Thanks,
>
> ---
> Tom Geller * Oberlin, Ohio * 415-317-1805
> Writer/Presenter * http://www.tomgeller.com
> articles, marketing, videos, user guides, books
>
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&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:14:04

- reply

📅 Original date posted:2014-02-25
📝 Original message:Am suggesting a (possible) mitigation of [possible flooding, etc], via
some kind of discussion (potentially process BIP, related to bundling and
/ or randomization) not now, but down the road. However, needs more
thought and analysis (you mentioned code audit?) before it could be
floated around or acted on in any way shape or form. Thanks for this
discussion, things to think about.... am watching, listening (...)
> There are two possibilities.
>
> One is that the value of transactions with the new lower fee is outweighed
> by increased orphan costs and miners refuse to include them en-masse.
> Wallet authors lose the staring match and go back to setting higher fees
> until such a time as block propagation is optimised and the orphan costs
> go
> down. Nodes that are encountering memory pressure can increase their min
> relay fee locally until their usage fits inside their resources. It's
> annoying to do this by hand but by no means infeasible.
>
> The other is that the total value of transactions even with the lower fee
> is not outweighed by orphan costs. The value of a transaction is higher
> than its simple monetary value - the fact that Bitcoin is useful, growing
> and considered cheap also has a value which is impossible to calculate,
> but
> we know it's there (because Bitcoin does not exist in a vacuum and has
> competitors). In this case miners stop including lots of useful
> transactions that represent desired economic activity and are put under
> pressure by the community to change their policies. If all miners do this
> and making small blocks is considered errant behaviour, then we're back to
> the same situation we're in today.
>
> The possibility you're worried about - that someone does a DoS attack by
> flooding the network with small transactions - is only an issue in the
> first situation, and it is by no means the easiest or cheapest way to DoS
> Bitcoin. We all want to see more DoS resistance but basically any change
> to
> Bitcoin can be objected to on anti-DoS grounds at the moment, and this
> will
> remain the case until someone steps up to spend significant time on
> resource scheduling and code audits.
>

2023-06-07 15:14:02

- reply

📅 Original date posted:2014-02-25
📝 Original message:> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obvious
> low-risk DDoS exploit.... right? As we all know, the network bandwidth
> DoS attack mitigation strategy relies on transactions we accept to
> mempools getting mined, and the clearance rate of the new low-fee
> transactions is going to be pretty small; we've already had problems in
> the past with mempool growth in periods of high demand. Equally it
> should be obvious to people how you can create large groups of low-fee
> transactions, and then cheaply double-spend them with higher fee
> transactions to suck up network bandwidth - just like I raised for the
> equally foolish double-spend propagation pull-req.
It's good that the core devs keep doing good work on these topics, thanks.
>
> Of course, there's also the problem that we're basically lying to people
> about whether or not Bitcoin is a good medium for microtransactions.
I don't hear anyone lying.
> It's not.
Actually, it is, and comparatively speaking, Bitcoin is better than the
most common alternatives in use by people around the world. There are
obvious issues (dust, how to handle fee issues moving forward, one could
blather on forever about that), but again, I think core devs have done
fairly well and will probably continue to do so along with many others.
That's just my own 0.00004 BTC though (my way of saying, at time of
posting this, "my own 2 cents").
>Saying otherwise by releasing software that has known and
> obvious DoS attack vulnerabilities that didn't exist in the previous
> version is irresponsible on multiple levels.
That was not very specific. Could you be more specific?
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&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:13:45

- reply

📅 Original date posted:2014-02-18
📝 Original message:> Hey everybody,
>
> here's another question that I have:
>
> I'd like a small bit of clarification about the gettx / getrawtransaction
> (decoded) api call. I understand that I can find the address that a
> transaction output is directed at / available to for future use sits in
> the
> vout array in the scriptPubKey.addresses array. I'm a little uncertain as
> to why that piece of information would be typed as an array when all it
> ever seems to contain is one (not more, not less) address(es).
>
> Are there any cases of transactions right now that don't contain exactly 1
> item in that array, i.e. more or less than a single address (per single
> vout element, not per tx)? Or is the thinking behind this array to somehow
> make the data structure more extensible for potential future use? But then
> I can't think of any use cases where it appears to make any sense to put
> more than 1 address there...
This might be such a use case, just maybe --> https://coinb.in/multisig
Also I recommend checking out http://abis.io
These may be things you are thinking about in the context of this.
> Or am I even asking the wrong questions? For spending those coins, i.e.
> using them in a future transaction it's all about owning the
> public/private
> key that is contained in the vout script, right? So the address doesn't
> really matter and it could be 2 or more (or none at all?) addresses in
> there, and what matters is just that the next guy has the key to spending
> those coins... ?
>
> Once again I'm coming to these questions from a project where I'm trying
> to
> calculate unspent outputs and from that balances for all accounts and I'm
> not sure yet what other special cases there might be in the blockchain
> that
> I need to be aware of and handle properly in order to (re-)produce
> accurate
> data!
>
> Thanks for your help, much appreciated!
> - Denis
>
> "Be the change you want to see in the world." (Mahatma Gandhi)
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&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:13:32

- reply

📅 Original date posted:2014-02-09
📝 Original message:Hello,
I have a request, which is how do developers address the circumstance in
which someone utilizes your code as part of some effort to deprive (or
steal as the case may be) someone of their bitcoin?
This hasn't happened to me, but I have posed a question about it at
bitcointalk:
https://bitcointalk.org/index.php?topic=454903.msg5045596#msg5045596
It was prompted by the apparent use of sx by a malware author who then
generated something called Stealthbit (which is malware, and which no-one
should touch). [fortunately I have not tried to access or use
Stealthbit.) However, this is a question that also touches on bitcoin
development generally, due to that (it's happened before, it will happen
again, etc.) people may end up using bitcoin code (if they haven't
already) to develop something else that would then be used expressly to
deprive someone of their bitcoins (such as steal them, but I am not
thinking only of theft here). My question for developers is: Given that
code is open source and anything can be done with it, good or bad, what
are common development approaches to mitigate or potentially prevent
malware authors from being able to easily appropriate the code you
develop?
I realize this question may sound dumb and out of place being that it is
pretty obvious that code which is developed in a free, open source context
can technically be used for anything. However, beyond suggesting that
people just go to bitcoin.org for wallet technology, what can be done in
the development community that would lessen the likelihood that the code
you develop might be "misappropriated?" Please note: I am not sure how
this issue might be approached from a development perspective, or license
(MIT, Affero GPL, etc.) perspective, or any other perspective.. I'm just
asking the question. I support bitcoin and other decentralized currency
efforts including walled development such as darkwallet, and I appreciate
what you all are doing. Maybe I'm asking the wrong question and it should
be put another way, but I hope you will rephrase my question(s) in a way
that makes more sense in the context of the list discussion here.
Thanks for your work.

2023-06-07 15:12:46

- reply

📅 Original date posted:2014-01-28
📝 Original message:Greatly appreciate seeing this discussion occur. This is something that
potentially could be supported through a bounty - possibly a process BIP?
Possibly related: https://gist.github.com/ABISprotocol/8515891
> Yes, recurring payments and subscriptions is a frequently-requested
> feature. It needs a new BIP. Here is an outline:
>
> The situation is somewhat analogous to HTML5 local storage. The remote
> (merchant) wants to initiate a persistent behavior. This is bitcoin, so
> we
> have a "push" model for payment, and the user has complete control. The
> merchant can, at most, send a "subscription request." The user is
> responsible for making on-time payments after that point.
>
> Centralized services like coinbase.com or blockchain.info will have an
> easy
> time of it. An automated program on their backend, sending payments as
> needed, is easy and direct.
>
> More inventive services might employ multisig transactions, generating and
> signing one signature of a TX, then sending that TX to the human for
> further signing and publishing. A few competing vendors could offer bots
> that provide this signing service.
>
> Decentralized, standalone wallet clients will be somewhat troublesome. We
> can store a local subscription request, and send recurring payments... if
> the wallet app is running. If not, the user will be missing payments,
> that
> perhaps they intended to make (rent!).
>
> Each of these solutions can be cancelled at any time by the user. As
> such,
> a courtesy "subscription cancelled" message sent to the merchant is
> recommended. User controls the usage of their money at all times, the way
> things should be.
>
> And finally, you do not want to make it /too easy/ to send money over and
> over again. From a human-interface perspective, a textual reminder to
> send
> money might be preferred over actual recurring payment automation:
> reminder
> email + manual spend inserts a bit of additional human thought and review
> into the process, with all that entails.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&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:12:17

- reply

📅 Original date posted:2014-01-18
📝 Original message:clarification, I am not a doge dev. It was intended just as a joke, to
make you laugh.
regarding pull requests improving these issues I am under the impression
that the developers will take care of what needs to be taken care of in
that regard. Am presently in collaboration on a bitcoin project that may
implement aspects of the ABIS concept as presented, but it is in very very
early stage(es).
I hope you had a good laugh, that was my intent. good morning / afternoon
/ evening
> On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla <
> odinn.cyberguerrilla at riseup.net> wrote:
>
>> <ABISprotocol hat: on>
>>
>> regarding:
>> stuff not getting into blockchain in a day's time,
>> microdonations not facilitated as much as they could be,
>>
>
> Please point to your pull requests improving these issues.
>
> If your organization didn't contribute anything to further these issues
> then there can't be much surprise that they didn't make it in, either.
>
> that would be:
>>
>> very bad
>> much news
>> such fail
>>
>> Seriously, that would not be so good.
>>
>> Hope I made you laugh a bit
>>
>
> So it's more like a jester's hat then :)
> How did I end up on the dogecoin-development list?!?
>
> Wladimir
>

2023-06-07 15:12:16

- reply

📅 Original date posted:2014-01-18
📝 Original message:<ABISprotocol hat: on>
regarding:
stuff not getting into blockchain in a day's time,
microdonations not facilitated as much as they could be,
that would be:
very bad
much news
such fail
Seriously, that would not be so good.
Hope I made you laugh a bit
> <vendor hat: on> BitPay sure would like to see CPFP in upstream.
>
> I think the main hurdle to merging was that various people disagreed
> on various edge case handling and implementation details, but no
> fundamental objections.
>
>
> On Fri, Jan 17, 2014 at 1:41 PM, Luke-Jr <luke at dashjr.org> wrote:
>> On Friday, January 17, 2014 11:44:09 AM Wladimir wrote:
>>> On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr <luke at dashjr.org> wrote:
>>> > https://github.com/bitcoin/bitcoin/pulls/luke-jr
>>> >
>>> > These are pretty much all well-tested and stable for months now.
>>>
>>> #3242: Autoconf improvements needs rebase, and comment from jgarzik and
>>> me
>>> taken into account (about -enable-frontends=).
>>
>> I'll try to get this done over the weekend.
>>
>>> The others appear to be more controversial as they affect
>>> mining/consensus.
>>> I'd really like to see ACKs from more reviewers and testers there
>>> before
>>> merging.
>>
>> Can you elaborate on this? I can see how Proposals might, if buggy,
>> affect
>> consensus, but the rest shouldn't. I don't think there's anything
>> controversial in any of these (does someone disagree with CPFP?).
>>
>> Luke
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> 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:12:03

- reply

📅 Original date posted:2014-01-12
📝 Original message:Hello,
My apologies, to start with, as I am temporarily unable to reply directly
to the thread. I am remembering this conversation due to a few things:
1) the discussion re. extending the payment protocol with new fields
2) discussions about "long addresses"
3) bitcoin strengthening / decentralization / cex.io,ghash.io growth etc.
4) microdonation / giving / microtransaction development, e.g.
coinbase-bitmonet Android SDK,
http://blog.coinbase.com/post/72785739620/android-sdk-released-accept-bitcoin-payment-in-your
5) multisignature via browser, e.g. https://coinb.in/multisig/
Different thoughts are running through my head here, so I will make a
sincere effort to coagulate them into a couple of meaningful and coherent
questions, and perhaps as time goes on, an issue or BIP. However, I will
precede this with a "scenario" and with some "possibilities" (all of which
are hypothetical - I think) before presenting the "questions" below.
|
|
V
"Scenario(s)"
Suppose that there were to exist a method of extending the payment
protocol such that either "very long addresses" or multiple addresses were
presented by default from within the bitcoin client. In the scenario
being imagined here, the standard option would exist to enter a payment
address directly. However, coupled with this would be an option to enable
microdonations (or put another way, multiple transactions associated with
each instance of use of the protocol to facilitate a purchase) as a
default (as background activity automatically corresponding to any given
transaction). Whether or not this process is engaged in would be entirely
voluntary, in other words, users' choice.
The addresses to which this giving or microdonation would occur would be
stipulated by the user but also would be limited to the ability of the
network to support this microdonation process.
So, for example:
1) Let us say that you are to buy a piece of gum and the price of that
piece of gum is 0.00008 BTC.
1)a. The user has the ability to support additional (individuals,
organizations, causes, etc) for each transaction (instance of use of
the protocol to facilitate a purchase).
1)b. The user has set as a default to be "microdonated" each time a
transaction occurs, the following:
1)b.1 0.0003 BTC to Sean's Outpost
1)b.2 0.0004 BTC to a cousin who has a medical debt
1)b.3 0.00006 BTC to a multisignature account which is intended
to "give youth a future and old age a security"
( Re: https://www.youtube.com/watch?v=qLci5DoZqHU&feature=youtu.be&t=2m38s )
1)b.4 0.00005 BTC to a future US gov't-run Social Security address
1)b.5 0.0002 BTC to an anarchist collective's donation address
1)b.6 0.0002 BTC to a personal investment or retirement account
1)c. The user then purchases a compound bow for 0.17 BTC. The
purchase occurs the day after the gum purchase was initiated. The
user has left the default microdonation settings in place, so Sean's
Outpost, the cousin, the multisignature account, the US gov't run
Social Security address, the anarchist collective, and the personal
investment / retirement account all receive something (automatically)
again as per the user's settings.
"Possibilities"
2) Some Possibilities (depending on implementation):
2)a. The transaction completes for the purchase of gum but the
microtransactions are not allowed to complete until the compound bow
purchase is complete due to that the gum price is lower than the
collective microdonations which are set by the user as default.
2)b. The transaction for the purchase of gum is not completed due to
the user realizing that the fee will be larger than the price of gum,
but the microdonations are completed (the user has opted to allow them
to occur anyway) and transaction(s) confirmed. Subsequently, the
compound bow purchase occurs and the microdonations are given again.
2)c. The transaction for the purchase of gum is completed and the
microdonations are completed, everything is confirmed, the next day
the same thing happens with the compound bow purchase, more
microdonations arrive.
2)d. The microdonations are interpreted by the system as part of a
very long address created for the transaction. Due to the tiny price
of the gum the microtransactions are held until another larger
purchase is completed. The microtransactions occur "times 2" at the
time of the compound bow purchase, since they could not be completed
during the gum purchase, they are completed / confirmed at the time of
the compound bow purchase. The user is alerted that the ordinary
microdonations will be multiplied by two for the transaction and is
offered an option to either run the default microdonation or the
micronation "times two." The user confirms the "times two" option and
the microdonations are completed.
2)e. The microdonations are each handled as seperate microdonations -
each has a distinct transaction
2)f. A fee is collected for some microdonations but not for others
depending upon their size of the microdonation and other factors
2)g. Microtransactions are conducted over mobile with zero fees, the
fees are applied only to the item purchased, unless the value of the
microdonations is at a certain threshold value where fees will apply.
2)h. The user has the microdonations set by default in the user's
bitcoin client, but also uses 'donation services' (that operate
through a website) apart from the user's client, for example, flattr,
which can provide small bitcoin donations to persons or entities that
the user selects without having to also commit to the "microdonation
default" (Sean's outpost, the cousin, etc) when that 'donation
service' is used. In other words, the user can commit to a
transaction for the purpose of donation to some person or entity, with
the option of not having the default microdonations occur (user's
option) for that transaction.
(I could go on with all sorts of scenarios here but I think those will
suffice to describe _some_ possibilities)
"Possibilities - continued"
3) The system uses the microdonation process to limit possibility of a 50%
+ 1 attack. At the user's option, microdonations are routed to different
pools when certain thresholds are reached, to decentralize mining. This
would occur either as distinct microtransaction (materially, no different
than the microdonation to Sean's Outpost that the user has set as a
default for every purchase) or would occur as part of a "very long
address."
"Questions"
1) What are (some) obstacles to this sort of suggestion to decentralize
the giving process?
2) Would donations be identified as donations or just as another
transaction in the Bitcoin network? Maybe there is another question
flowing from this question:
2)a. Where the user wants the ability to decide to make a donation
'anonymously' or not, could this occur as a default setting for either
one (or all) of the microdonations that the user has set?
3) What would be the simplest possible form of a prototype implementation?
References / things being reflected upon in background / note(s):
a) 'ABIS' - protocol concept to enable decentralization and expansion of a
giving economy and a new social good (ABISprotocol)
https://github.com/ABISprotocol/ABIS
b) 'BitHub' - An experiment in funding privacy OSS (WhisperSystems /
moxie0) https://github.com/WhisperSystems/BitHub
c) 'coinbase-android-sdk' - Coinbase Android SDK developed in
collaboration with Bitmonet Open-source project (coinbase / bitmonet)
https://github.com/coinbase/coinbase-android-sdk
d) 'bitcoin' (bitcoin) https://github.com/bitcoin/bitcoin
Finally: My apologies in advance for any obvious omissions,
inconsistencies, poorly constructed statements, or whatever malformed
thing you perceive that you have just endured reading. (If you liked it,
though, you are most welcome. I'm happy to contribute.) This is an
initial stab by me in this list to generate discussion about these issues.
-----this message is in reply to the below-------
From: Mike Hearn <mike at plan99.net>
To: Jeremy Spilman <jeremy at taplink.co>
Cc: "bitcoin-development at lists.sourceforge.net"
<bitcoin-development at lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Stealth Addresses
Date: Sun, 12 Jan 2014 13:51:54 +0100
You can always just extend the payment protocol with the new fields as
well, vs making very long addresses. If this technique can be made to work
well, it would have applicability in both fixed textual address context,
and for a fixed/upload-once payment protocol file. That has the advantage
of backwards compatibility as well - the new addresses would not be
clickable or acceptable by old wallets, but with the payment protocol you
can always craft a bitcoin URI that contains a regular current style
address, and a link to a fixed payment protocol file (uploaded to a
pastebin type site), and modern wallets would ignore the address and use
the ECDH based system instead.
On Sun, Jan 12, 2014 at 11:33 AM, Jeremy Spilman <jeremy at taplink.co> wrote:
> > Oh, sorry, I forgot to mention it in my first write-up but you can
> > easily make stealth addresses include a second pubkey for the purpose of
> > the communication that either isn't used in the scriptPubKey at all, or
> > is part of a n-of-m multisig. (n>=2) Interestingly that also means you
> > can give a third-party that key and out-source the effort of scanning
> > the blockchain for you.
>
> Great point. Even if it's not a 3rd party, I think it's really important
> to be able to scan for transactions with a key which can't actually spend
> the funds.
>
> The first approach is just one-pass ECDH. I think you're saying the second
> approach is two rounds of ECDH but re-using the same e/P (usually referred
> to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key
> for signing operations.
>
> Payee: Publish Q, Q2 [d, d2 are privkeys, Q, Q2 are
> pubkeys]
> Payer: 1) Generate ephemeral key: e / P [e is privkey, P is pubkey]
> 2) S = e * Q [first shared secret]
> 3) S2 = e * Q2 [second shared secret, reusing
> 'e']
> 4) Q' = Q + H(S) [pay-to stealth address]
> 5) Q2' = Q2 + H(S2) [stealth 'marker']
>
> Watch: 1) Look for TxOut with OP_RETURN <P>
> 2) Q2' = Q2 + H(d2 * P)
> 3) Check for Q2' elsewhere in the Tx
>
> S/MIME for example, allows reuse of the ephemeral keypair. When reusing an
> ephemeral keypair where A reuses (x, X) to encrypt different messages to
> more than one user, A should verify the static public keys to prevent
> small-subgroup attacks.[1][2]
>
> Let's say you pay-to Q' and then Q2' value has to be somewhere else in the
> transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN
> <P> <Q2'> would be 66 bytes.
>
> But then Mallory could generate transactions with the right Q2' but with
> his own pubkey in Step 2 instead of Q. So your scanner would detect a
> payment, but you wouldn't be able to spend it, and Mallory could.
>
> That's a good argument for putting Q2' in a 2-of-2 multisig so that
> pulling this trick would at least make the transaction unspendable for
> both parties, which may be good enough deterrent, but you're still going
> to want to check it against your 'd' before fulfilling a large order. Your
> online watch process could queue the matching transactions, which you
> could move to your offline machine, decrypt your key, and verify the
> transactions are spendable.
>
> Now, you would need to get two pubkeys to the payer, throw in a prefix to
> help standardize it, and end up with addresses that could look like (for
> example):
>
>
> xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX
>
> tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba
>
> Those addresses are 74 bytes:
> <Prefix><CompressedPubKey1><CompressedPubKey2><Checksum>
>
> xSTL Prefix = 0xC0CB9270
> tSTL Prefix = 0xB2E27D50
> NOTE: I do NOT have the corresponding privkeys for these four pubkeys!
>
> Those just happened to be the first matching prefixes I found for 74 byte
> addresses. I could try to find ones which start with a specific byte if
> that's somehow better, like 0x04 to match BIP32.
>
> Unfortunately, I don't think you can just derive a second public key from
> the first to keep the address shorter, and still keep the first private
> key secure, even if the second private key is stolen. You only get
> equivalent security as BIP32 public derivation, where you can't lose a
> child private key.
>
> Do we also want xSTL (or whatever user friendly string) prefixes for
> single pubkey (41 byte) stealth addresses?
>
> I'll wait a couple days for feedback, then I'll try to implement the
> following prototypes:
>
> 1) Pay to STL addresses
> 2) Watcher process to detect and queue STL payments for a given d2/Q2
> 3) Offline verifier to take output from Watcher and verify spendable given
> encrypted d/d2
>
> Obviously extending QT directly for #1 would be ideal, I may even be able
> to do that since supporting a new address type should be fairly contained.
> But if not I'll punt to writing a node.js or python script which connects
> to bitcoind via RPC.
>
> Thanks,
> Jeremy
>
> [1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols
> http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf
>
> [2] - Validation of Elliptic Curve Public Keys
> http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf
>
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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:44

- 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

- 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

- 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
>

2023-06-07 15:10:24

- reply

📅 Original date posted:2013-12-08
📝 Original message:Hello, re. the dedicated server for bitcoin.org idea, I have a few thoughts
1) I have commented in a blogpost of August 2013 at
https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
issues with CA related to bitcoin.org - where I mentioned something
relative to the DigiCert certificate,
"DigiCert “may revoke a Certificate, without notice, for the reasons
stated in the CPS, including if DigiCert reasonably believes that” (…)
“Applicant is added to a government list of prohibited persons or entities
or is operating from a prohibited destination under the laws of the United
States” (…) “the Private Key associated with a Certificate was disclosed
or Compromised”"
In the same post I mentioned
"Bitcoin.org has no certificate, no encryption — a situation which has its
own obvious problems. Bitcoin.org currently sends users to download the
bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
certificate based on GeoTrust:
https://www.geotrust.com/resources/repository/legal/"
(Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
encrypted' examining it in a cursory fashion w/ Chrome)
Not sure how this would work, but it would be nice to see the content at
bitcoin.org encrypted, of course, but also further decentralized? how many
mirrors are there of bitcoin.org - not sure, but a few things that come to
mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin).
There are many ways to decentralize something but that is just something
that comes to mind.
This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
of certain content
Some things to think about.
> I would like to know what are your thoughts on moving bitcoin.org on a
> dedicated server with a SSL certificate?
>
> I am considering the idea more seriously, but I'd like some feedback
> before taking steps.
>
> Saïvann
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 15:10:17

- reply

📅 Original date posted:2013-12-03
📝 Original message:Hello,
This concept, 'ABIS protocol,' has been many years in the making and is
presented here as a basic concept. It is sent to you for you review and
possible consideration. There will be further additions in the near
future. Looking forward to your reply and any contributions you may
provide.
Cheers
https://github.com/ABISprotocol/ABIS#abis