Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Regarding this proposal from Mike Hearn to remove consensus process
from the BIP, which I think is unsound philosophy.  I will address
this briefly below.

On 06/18/2015 09:05 AM, Mike Hearn wrote:
 So then: make a proposal for a better process, post it to this
 list.
 
 
 Alright. Here is a first cut of my proposal. It can be inserted
 into an amended BIP 1 after What belongs in a successful BIP?.
 Let me know what you think.
 
 
 
 The following section applies to BIPs that affect the block chain 
 consensus rules or the peer to peer protocol and thus require
 changes to Bitcoin Core.
 
 Once a draft BIP has been submitted to bitcoin-development for 
 consideration, the Bitcoin Core maintainer will deliver a
 preliminary yes/no verdict within three weeks.

For many things, that will simply be too fast. It is better to allow
the primary maintainer to collaborate with other people who normally
work on the code and determine what the schedule will be based on
life, volume of work, and so on.


 This verdict may be informed by the debate that has taken part in
 the previous three weeks. If more time is required, the maintainer
 is required to request an extension from the BIP author, who may
 then elect to force an immediate decision (risking a no), or
 choosing to allow more time.

Again, this three week thing doesn't work.  But assume for a moment
that there is a certain amount of time that is such and so and it is
set by the maintainer.  The notion that the maintainer would be
required to request an extension from the BIP author is sheer
lunacy.  There is no need to codify the actions of the project
maintainer such that he/she would be needing to be subject to the
whims of whatever BIP author.  In like manner, a BIP author should not
have to be subject to forever delay of a BIP due to inaction of a
maintainer, but should have an answer regarding whether it can be
assigned a number, published as draft and so forth after a reasonable
time.  To me, a reasonable time is something that should be
discussed amongst the maintainer, those who work regularly on code,
and the BIP author.

 
 The verdict will meet the following criteria:
 
 * It will address the latest version of the BIP at the time the 
 verdict is rendered.
 
 * In case of a rejection, it will spell out and describe the
 technical rationale for this decision. Opinions held by other
 people are not considered technical rationales: if the maintainer
 agrees with a technical point made during discussion, he must own
 that opinion for himself. Therefore no BIP will be rejected on
 grounds of controversy, disagreement, lack of consensus or
 otherwise.

No, this is ridiculous, because the notion that no BIP will be
rejected on grounds of controversy, disagreement, lack of consensus,
or otherwise, is clearly an attempt to do away with consensus models
of business, and it is also not a very logical statement because
controversy and disagreement are a natural part of... coming to what
eventually is an agreement.

 
 * In case of rejection, the maintainer will provide a clear,
 specific list of actionable steps the BIP author can take next. For
 example, a list of what changes would address the technical
 objections raised.

This above section I agree with.


 In case the maintainer believes no change could ever make
 the BIP acceptable, the list must consist of instructions for how
 to create a patch set and, in the case of changes to the consensus 
 rules, how to initiate a hard fork.

This above section I do not agree with because of the obvious bias in
favor of the hard fork.  Everything here seems to be aligned to push
for hard fork, hard fork, hard fork.  It's like the author can't tear
his mind off it.

 
 A BIP, even once rejected, may live on in the BIPS repository,
 though its entry in the index may be sorted below others. The BIP
 author may update the BIP with a summary of any resulting
 discussion. As such a summary may be inherently contentious in case
 of a dispute, the authors wording of that summary is final and may
 not be subject to meta-debate.
 
 
This doesn't seem right at all.

 
 
 --
- 

 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVg0sHAAoJEGxwq/inSG8CuFcH/0tzRWWyy3wmDegNx463xoaq
EhG/dNqoIvavMlyJrKfKWPK6Mndgo9BtxkYbvOlO40Y51SW4SaisWGzHRg4HyIbJ
0Orp+C0jXhvnrJ7hRwKhrdZQUIRAI19NLVthSb9W6mHnXWJC8ilhlK9Ei9ILRjGl
tM5pZ28SkyJ/b+CnltnYW8t6AvE4zlggC4QsCuUwA2cFoFWjQeESpqjy4kJNv464
yKlsrqoIzs2vNnoLIx1B0aLX9mNTQUwB1yMXtu8IVcAQe/G1LEEnNO56LGf8O0yJ

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I maintain that you should apologize to those who traverse this list.
 What you are saying is digging yourself a deeper hole and is not
merely embarrassing but is crossing a threshold in which you have used
words, albeit subtly, to attack a community.

If you refuse to apologize, I get it.  You have not apologized thus
far, and pressing for an apology is unlikely to get an (authentic)
one.  But then, you should voluntarily step back and let others do the
hard work of coming to the consensus that you seem to think is
impossible to accomplish based on how bitcoin is run.

I believe this matter will be resolved, but not with the help of
those who make threatening statements (and who are unable to apologize
for having made them).

- -O

On 06/18/2015 03:00 AM, Mike Hearn wrote:
 Dude, calm down. I don't have commit access to Bitcoin Core and
 Gavin already said long ago he wouldn't just commit something, even
 though he has the ability to do so.
 
 So why did I say it? Because it's consistent with what I've always
 said: you cannot run a codebase like Wikipedia. Maintainers have to
 take part in debates, and then make a decision, and anyone else who
 was delegated commit access for robustness or convenience must then
 respect that decision. It's the only way to keep a project making
 progress at a reasonable pace.
 
 This is not a radical position. That's how nearly all coding
 projects work. I have been involved with open source for 15 years
 and the 'single maintainer who makes decisions' model is normal,
 even if in some large codebases  subsystems have delegated
 submaintainers.
 
 This is also how all my own projects are run. Bitcoinj has
 multiple people with commit access. Regardless, if there were to be
 some design dispute or whatever, I wouldn't tolerate the others
 with commit access starting some kind of Wiki-style edit war in the
 code if they disagreed. Nor would I ever expect to get my own way
 in other people's projects by threatening to revert the maintainers
 changes.
 
 Core is in the weird position where there's no decision making
 ability at all, because anyone who shows up and shouts enough can
 generate 'controversy', then Wladimir sees there is disagreement
 and won't touch the issue in question. So it just runs and runs and
 /anyone/ with commit access can then block any change.
 
 I realise some people think this anti-process leads to better
 decision making. I disagree. It leads to no decision making, which
 is not the same thing at all.

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVg0HiAAoJEGxwq/inSG8CXOwIAKSGRJPtSx+untgMERwE7lW7
9p0gWz4jvKhyO+RrGPXlofckvp4Fp/7Yxa+TDLcXbzGi6OesX9yIyN7e06LJW4DP
h7V2PwzS49ZyB/krd03HjvWMFnhoGy7zB7M1okq5myIvx+h1htX9TirNbDl7PU9Z
SWyNNw+GXPsIV/xuPu81LP5GrR3gIxwwhhopOq2qcm08AUiuIJ8EA31mT2ZgwMWB
RxrnktFRzMbW2fD7Z7njTz1gjw1duPyGApJ+xpqtcjjS2idPNuw1nESZTCE3+TwG
Dk1AKmYt8TvZzFWyo/0ly7vYFFW27Yh7SC3oeDJBoWkvySuIFrevux7ekfKxPOc=
=wc2m
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread odinn
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVg1OFAAoJEGxwq/inSG8COpAIAJrH9Uj9bcKr+UUR7ePV6/Yj
MmNTY2VKAtiQhwHM+Mqk2VvQANs7/uRBdZjzGnw1NRcca/m8Q0yZUHQiP8avCUOE
3MHqGviYjfeJdu1pcf+PO2pAImM5FCFdrfbbiWUt+ZoOKTxZjsLtF4RE+mc13AXJ
dktvy6SFdvQUgEx8pdXEDpmaUSYUr7syFP4sgHZmyMlhvCsXyE/8dC3sZTzEpVnC
xy1dyBmXHPW3W4FfBSblwwWgJWMcIcGJn8OLQKK5pni/iSVL6IMoRI/MLwOJdRr4
lr83g9FR/qxMqAT9UIZtATnePlkkWPU1szvak/tU/49fGioyYOF4b4KPg/bHYSc=
=hBcE
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Scope narrowing for proposals to address block size limit debate, an inquiry

2015-06-18 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The purpose of this post is to present an inquiry related to the
possible narrowing of scope of what sort of proposals are likely to
bear fruit at this stage.  The inquiry or question is, Are there
some proposals that are more likely to succeed, in addressing the
whole block size limit debate meaningfully?

The flip side of this inquiry, is that if you think that an attempt to
do such scope narrowing _at this time_ is foolhardy, inappropriate,
wrong, or otherwise flawed, please say so and explain.  I'm not
religious about this notion.  I throw out proposals below which I
think would be likely to advance further ~ and thus I ask the question
again, and rephrase, Are there some proposals (some shown below as
examples, not all-inclusive) that are more likely to succeed, in
addressing the whole block size limit debate meaningfully?

~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of
Huobi's mining project Digcoin, clarified that the big Chinese mining
pools consider further adjustments to the protocol beyond the
suggested 8 MB block size limit adjustment — such as the Bitcoin core
developer Jeff Garzik's BIP-100 draft — to be feasible)
   ~ Adam Back, with a simplified soft-fork one-way peg
   ~ Gavin Andresen, developing an 8 MB block size limit adjustment in
the context of Core (as an example) with one or more of the above
authors rather than focusing on XT. (This is a big assumption but,
roll with it)

All of this assumes that developer(s) are willing to abandon
intentionally contentious proposals such as the hard fork to XT w/ 20
MB, remain within the context of Core and be reasonable.

Here I am being aware of the fact that Pushing a hard fork in the
face of such controversy is a folly, a danger to the network, and that
deserves to be said. - Wladimir J. van der Laan
https://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917

And if I'm lucky, this thread may get comments from DumbFruit, who
writes stuff like this:
https://bitcointalk.org/index.php?topic=1085436.msg11643203#msg11643203

So now... your thoughts?


- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVgnLuAAoJEGxwq/inSG8CchMH/0zm+A7Uqp8SpU+CsJr3lF2+
0re+5Ql4qVVmOI560918BtkdFjcq33jsKU9cYUDXqZ4wHfJTAGLGDqNgUZGpGkmJ
bqGgSvdF64P52Vb9PVnz1I9+aClas8Mjvl8XUYoD0yEA14XVBakYDRbVqZ5yPM8n
hBi6EpWLUnkFvvEj2dkgwddvPCvrnhVL/aRfmhet1pfOELfIrXtXI7hs2F1RyaqK
sbR/Qg3SFlyHzbxSzRVcZQ0G81exq/fxHqxc5kSLMiR7TODIJxCl6cJDCjf8LbeS
n6tL/I8vWN2zraYfb0cWu5uIjz5XnXpsitu951109zoS8IYle3uTfCF+6xdG3tY=
=HQ9R
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Reusable payment codes

2015-06-16 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is very well done.

Have you seen this discussion that I started regarding BIP 63?

https://bitcointalk.org/index.php?topic=1083961.0

I have no response from Peter Todd back on it other than my time is
better spent focusing on more fundemental issues and I've also got
no-one interested in funding stealth address development right now,
when several people (myself included) offered to send donations to see
the BIP (63) advance, no donation address was posted, so... waiting
for him to act on that.

I'm definitely supportive of seeing what you've written up here as
Reusable payment codes move to draft in https://github.com/bitcoin/bips
When you can, please write up something on bitcointalk as well.


On 04/24/2015 01:00 PM, Justus Ranvier wrote:
 Hash: SHA1
 
 
 https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.m
ediawiki

 
 
 This link contains an RFC for a new type of Bitcoin address called
 a payment code
 
 
 Payment codes are SPV-friendly alternatives to DarkWallet-style
 stealth addresses which provide useful features such as positively
 identifying senders to recipients and automatically providing for
 transaction refunds.
 
 
 Payment codes can be publicly advertised and associated with a
 real-life identity without causing a loss of financial privacy.
 
 
 Compared to stealth addresses, payment codes require less
 blockchain data storage.
 
 
 Payment codes require 65 bytes of OP_RETURN data per
 sender-recipient pair, while stealth addresses require 40 bytes per
 transaction.
 
 
 
 
 
 --
- 

 
One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications 
 Performance metrics, stats and reports that give you Actionable
 Insights Deep dive visibility with transaction tracing using APM
 Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVgE4fAAoJEGxwq/inSG8CjgkH/i0aX4aJaOjrbI2xzWbPeL1T
/APSvSqV0D610ljbw/MuRRFVagnK3lCs73fYolKw9uFG0cnwhIWJ53mCqPWhM5nL
kIejDTHr9jQ2tbXrU2L481Oat1Z6vtdQj7LolXFfD3Ktqz+sqp//gBaC9EEZ5nOq
4oz71Am58pf8+XGhtJk0+4XDXzFNd71bKKY+nMf9f3bwqNX93jHiF48hXwijFPC4
MOZmYRh3Sf5LAVP5p1JY3aJRQv4M/W0L2RDC+GW8Ol997etQSGGLhESihNNPw1m8
GEqJLBmUBkavzsRpZ009czfzL7EiCwsMbOrVw918o2Y9NnVpY9a9cBNB+UJgCmk=
=wAGz
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Reusable payment codes

2015-06-16 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter, my response below

On 06/16/2015 10:46 AM, Peter Todd wrote:
 On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote:
 This is very well done.

 Have you seen this discussion that I started regarding BIP 63?

 https://bitcointalk.org/index.php?topic=1083961.0

 I have no response from Peter Todd back on it other than my time is
 better spent focusing on more fundemental issues and I've also got
 no-one interested in funding stealth address development right now,
 when several people (myself included) offered to send donations to se
e
 the BIP (63) advance, no donation address was posted, so... waiting
 for him to act on that.
 
 Sorry, but I'm looking at the huge amount of work that I'll likely hav
e
 responding to the blocksize issue, so I think I'm inclined to shelve
 work on BIP63 for now.


I seriously find this pretty sad... you said that paying rent was an
issue and your time was better spent on more fundamental issues... but
the very least you could do is post a donation address... Is there
someone who was working with you closely on the concept who could take
it up since you are not going to be working on it?

 
 Feel free to take it up; a (=2)-part standard describing the resuable
 codes aspect, and separately how the ephemeral key is transmitted to t
he
 recipient makes sense to me.
 

I don't want to camp on Justus's thread on reusable payment codes ~ but
on the subject of BIP 63, it just did make sense to mention... so if
someone does have interest in working on it... please go to
https://bitcointalk.org/index.php?topic=1083961.0
and reply there.


- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVgQbMAAoJEGxwq/inSG8CD8gH/3jV+mLO9qv3t6JFxIvLMPtr
slGbymQtuqfAC09b6ybx3p6u9I1o1Nb3IgK1riu/Z3AzHxlnuYVUxN3N5ns0zGnx
F2WXs2suEa20YJkQ6dxZWLdNBjnUIEGGgXAit8X21LqVsqPfeZcocOWSeRDlePhk
/HRFLVtMehqfqjbuFAaAewVZUyT4Bn+3IU74krqR3e3YA00/ym1C5xCE3/kHvKIL
UF8EW9GgVYKuoyQdH3ICDwjiudwPOwIC4Ry0huaJgla43122RkwqYB+5kVr1583u
dx3VW8vW8HyQZJF+vb8d3F57R6FC6zYtFhCe0IzDIh+6xQxStk5zosMNIrtPKp4=
=h8Ib
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

2015-06-14 Thread odinn
, as no
 single entity should.
 
 
 Proposed Action Plan
 
 
 *
 
 Discuss this openly within this community.  Above is one example
 of a great neutral and competent host.  If the technical leaders
 here can agree to move to a particular neutral host then we do it.
 
 *
 
 Migration: The current list admins become the new list admins.  We 
 import the entire list archive into the new host's archives for
 user convenience.
 
 *
 
 http://sourceforge.net/p/bitcoin/mailman/  Kill bitcoin-list and 
 bitcoin-test.  Very few people actually use it.  Actually, let's 
 delete the entire Bitcoin Sourceforge project as its continued 
 existence serves no purpose and it only confuses people who find 
 it.  By deletion, nobody has to monitor it for a repeat of the
 Sept 2014 hacking incident 
 https://www.phoronix.com/scan.php?page=news_itempx=MTc4Mzgor 
 GIMP-type hijacking https://lwn.net/Articles/646118/?
 
 *
 
 The toughest question would be the appropriateness of
 auto-importing the subscriber list to another list server, as mass
 imports have a tendency to upset people.
 
 
 Thoughts?
 
 
 Warren Togami
 
 
 --
- 

 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVffgcAAoJEGxwq/inSG8COOsH/jC5TAjec1ridg9Ww/1+SW26
QvTaZ79PrK4+/5rvt3qXtCicOidGLTGpk/ixrgVN64nOiquaQm8JM/BrOrtZbYN0
/lXjhR6N8AEKYYvtjCQdD/JjNZ8Z0QvRZ4+XKUblBagm4BkRt4OtaVkctechscbM
WiMh+SfUPPlGiuucotiBFliF4TprFTCw0w/+WY521yKE5qgTPc6ZKBHI5TzYROoF
aAz7i6GlAZR0qlbV91IzakszZWF/Im6KHG30CYbU4eTb6Ic9tVHogC2EuW2zePd3
NxRXE4M0FunnVX61Eg3Bglm73h6SuzsL9x79Ckp0UXpZ8sJ7+mYCDKTZSUEWeJs=
=Xje2
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposed alternatives to the 20MB step

2015-06-13 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 06/02/2015 04:03 AM, Mike Hearn wrote:
(...)
 
 If you really believe that decentralisation is, itself, the end,
 then why not go use an ASIC resistant alt coin with no SPV or web
 wallets which resembles Bitcoin at the end of 2009? That'd be a
 whole lot more decentralised than what you have now.
 
 The *percentage* of the community that mines is totally
 irrelevant, it's the absolute number of (independent) people that
 matters.
 
 
 So usage does matter, then? You'd rather have a coin that has
 power concentrated in a far smaller elite, proportionally, but has
 overall more usage? If there are say, 5000 full nodes today, and in
 ten years there are 6000, and they all run in vast datacenters and
 are owned by large companies, you'll feel like Bitcoin is more
 decentralised than ever?   (n.b. I do not think this situation will
 ever happen, it's just an example).
 

Something you said about power concentrated, made me think I should
post this here:

https://twitter.com/adam3us/status/608920099609817088

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVe8gvAAoJEGxwq/inSG8CcykH/0d+WuPnzFWooCRJR+FwaI4w
Ad0z5GSLfYKGnmMMbbqkLsIA2GsfRAvivrsfZYd4slF5C7HEDGa3J/NC72U46dk6
qVm07UNBO3V+loLJtStIQQkg3tVGWjXeiySf4E4b8wlaZiBMS9WW0sAOWUJiGMDQ
jKNRpjXobkQGd8C+VJXDpgtmiY60bS4l6j7bbYv+mU6LxhLwCVCqjRJSEN08BH4E
AOwJg1qlORHPnrepfeJrB6TVxeHuLjCjWodXQ0jHbNchVQw7zc81gKrD40BJTzyO
TTtGPu3JUkcHtx7MVLbIdYNVElqxMS5Li+j9j3h+m9eGSaNgOOl3+8VGJexKPKI=
=j5Fh
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Address Expiration to Prevent Reuse

2015-06-12 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm way late to this one, I guess, but adding some thoughts here... it
seems that anything which mitigates the problem of reuse should be to
the maximum extent possible, the user's option... if a person wants to
have an address that lasts forever they should be able to have it...
if they want to have an address that expires they should be able to
have it.

The reuse problem is, I think, better solved by the presentation of
stealth address proposals, and would be handled by a stealth BIP (BIP
63) which has been recently re-discussed here:
https://bitcointalk.org/index.php?topic=1083961.0

On 03/26/2015 02:44 PM, Gregory Maxwell wrote:
 On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding t...@thinlink.com 
 wrote:
 I should have been clearer that the motivation for address 
 expiration is to reduce the rate of increase of the massive pile 
 of bitcoin addresses out there which have to be monitored
 forever for future payments.  It could make a significant dent
 if something like this worked, and were used by default someday.
 
 Great, that can be accomplished by simply encoding an expiration 
 into the address people are using and specifying that clients 
 enforce it.
 
 --
- 


 
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
 by Intel and developed in partnership with Slashdot Media, is your 
 hub for all things parallel software development, from weekly 
 thought leadership blogs to news, videos, case studies, tutorials 
 and more. Take a look and join the conversation now. 
 http://goparallel.sourceforge.net/ 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVe7cJAAoJEGxwq/inSG8C2uwH/2UfTX+6CEssv5ZhiwwqVNWk
bmlODZulsJK0FIIcz2oVtMvnMR7L8DX/XtFOdiVTk/wOn7vc7X/DZ9UVKSixKCLJ
IJLzBKEzFzMmNhxXv9fPsefuMsMlTkhifykl2BOp0T2gMEr5GweKSqn9XpQuo9mb
LhS5vqNCRw0X3eQ5sIalSfmK3ghP5yaU+orhFjvb3QJ/JN3mxgXyl3xLx9diPVdu
2I1QoxzCyE/tlEnxZGPrCtGe3d93mPhEFGGeiP+7eW8TkJa5AGCg3QWbzniC3Nsv
gjg6rCbLKtj300hH0glbPT96YO+r9l5itox+aArkCtNnR+/HlUb6zubgqebzPuc=
=KZQe
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups

2015-03-23 Thread odinn
.
 But I have a feeling that will be a different thread which is more 
 technical and so won't comment on it here, except to say it will 
 likely involve working toward giving the user an anonymity option 
 which can be exercised as part of any transaction.
 
 Thy Shizzle:
 I don't believe that at all. Analyzing information publicly 
 available is not illegal. Chainalysis or whatever you call it
 would be likened to observing who comes and feeds birds at the
 park everyday. You can sit in the park and observe who feeds the
 birds, just as you can connect to the Bitcoin P2P network and
 observe the blocks being formed into the chain and transactions
 etc. Unless there is some agreement taking place where it is
 specified that upon connecting to the Bitcoin P2P swarm you agree
 to a set of terms, however as every node is providing their own
 entry into the P2P swarm it becomes really up to the node
 providing the connection to uphold and enforce the terms of the
 agreement. If you allow people to connect to you without terms of
 agreement, you cannot cry foul when they record the data that
 passes through. To say Chainalysis needs to cease is silly, the
 whole point of the public blockchain is for Chainalysis, whether
 it be for the verification of transactions, research or
 otherwise.
 
 -Original Message- From: odinn 
 odinn.cyberguerri...@riseup.net Sent: ‎23/‎03/‎2015 1:48 PM
 To: bitcoin-development@lists.sourceforge.net 
 bitcoin-development@lists.sourceforge.net Subject: Re: 
 [Bitcoin-development] Criminal complaints against network 
 disruption as a service startups
 
 If you (e.g. Chainalysis) or anyone else are doing surveillance
 on the network and gathering information for later use, and
 whether or not the ultimate purpose is to divulge it to other
 parties for compliance purposes, you can bet that ultimately the
 tables will be turned on you, and you will be the one having your
 ass handed to you so to speak, before or after you are served, in
 legal parlance. Whether or not the outcome of that is meaningful
 and beneficial to any concerned parties and what is the upshot of
 it in the end depends on on what you do and just how far you
 decide to take your ill-advised enterprise.
 
 Chainalysis and similar operations would be, IMHO, well advised
 to cease operations.  This doesn't mean they will, but guess
 what:
 
 Shot over the bow, folks.
 
 Jan Møller:
 What we were trying to achieve was determining the flow of
 funds between countries by figuring out which country a
 transaction originates from. To do that with a certain accuracy
 you need many nodes. We chose a class C IP range as we knew
 that bitcoin core and others only connect to one node in any
 class C IP range. We were not aware that breadwallet didn't
 follow this practice. Breadwallet risked getting tar-pitted,
 but that was not our intention and we are sorry about that.
 
 Our nodes DID respond with valid blocks and merkle-blocks and 
 allowed everyone connecting to track the blockchain. We did 
 however not relay transactions. The 'service' bit in the
 version message is not meant for telling whether or how the
 node relays transactions, it tells whether you can ask for
 block headers only or full blocks.
 
 Many implementations enforce non standard rules for handling 
 transactions; some nodes ignore transactions with address
 reuse, some nodes happily forward double spends, and some nodes
 forward neither blocks not transactions. We did blocks but not 
 transactions.
 
 In hindsight we should have done two things: 1. relay 
 transactions 2. advertise address from 'foreign' nodes
 
 Both would have fixed the problems that breadwallet
 experienced. My understanding is that breadwallet now has the
 same 'class C' rule as bitcoind, which would also fix it.
 
 Getting back on the topic of this thread and whether it is 
 illegal, your guess is as good as mine. I don't think it is 
 illegal to log incoming connections and make statistical
 analysis on it. That would more or less incriminate anyone who
 runs a web-server and looks into the access log. At lease one
 Bitcoin service has been collecting IP addresses for years and
 given them to anyone visiting their web-site (you know who) and
 I believe that this practise is very wrong. We have no
 intention of giving IP addresses away to anyone, but we believe
 that you are free to make statistics on connection logs when
 nodes connect to you.
 
 On a side note: When you make many connections to the network 
 you see lots of strange nodes and suspicious patterns. You can 
 be certain that we were not the only ones connected to many 
 nodes.
 
 My takeaway from this: If nodes that do not relay transactions
 is a problem then there is stuff to fix.
 
 /Jan
 
 On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn m...@plan99.net 
 wrote:
 
 That would be rather new and tricky legal territory.
 
 But even putting the legal issues to one side, there are 
 definitional issues.
 
 For instance

Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups

2015-03-22 Thread odinn
 with Slashdot Media, is your
 hub for all things parallel software development, from weekly
 thought leadership blogs to news, videos, case studies, tutorials
 and more. Take a look and join the conversation now.
 http://goparallel.sourceforge.net/
 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVD34mAAoJEGxwq/inSG8CvrQH/28Rt26oGdo9rS+PaR1fIQ1p
Jwks11Axsmu5x3emTgIz0xUJ6zz/4ERM0LeNLBpfSFwZyLbuCgw1uiJplT+9uPgY
hPXb9OTNejfWZJjYc3i6rNjf2SNc5E3/4PtgeOI6lI/SsGQ6ineNm6gFjwe8xVpt
wCLOPetzCukQegXluFZZdALnPDf4H9yAeSsrfX2h2iCBAJ3qd9f1DP7+e6hvr+xr
POVBjlRYtnSd/viKJ2IhMbRvnqd86pRNAKEWrjZp0CIkGyY7wh4nqtYErZi4TcOK
H7yhU8o4/mgTNSIYdLTOSMlRi+nTMPWUD2jvO/Z9i9VTR9afn8E7j7iHD6QPMB0=
=vdbG
-END PGP SIGNATURE-

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups

2015-03-22 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Back to what is Chainalysis and country of their origin, so criminal
complaints against them would likely relate to violation of Swiss
laws, as is described here:
https://bitcointalk.org/index.php?topic=978088.msg10774882#msg10774882

It is fairly obvious that Chainalysis is not merely doing what
blockchain.info etc. is. Let's not delude ourselves here.

As stated, it would be advisable for such a firm to cease operations,
and it would seem that plenty of polite shots over the bow have been
given to Chainalysis, which should now fold up its operation, pack its
bags, and go back to its hole before trying to serve its masters again
in another way. Etc.

Corporations similar to Chainalysis which are domiciled in other
countries which conduct collection of information in ways that violate
countries' laws (there are many countries and each have their own ways
of interpreting user privacy and what constitutes permissible breach
and in what circumstances) can indeed be held to legal standards that
may result in minimal or severe legal penalties.  It is true that
analyzing information that is publicly available, such as that which
is in a library, is not illegal. But the act of surveillance is.
(Then there is the question of what sort of surveillance, targeted or
general, and whether it is limited to the bitcoin network or if it
moves beyond that to attempts to correlate with usernames, IDs, IPs,
and other information available on fora and apparent from services,
but I won't get into that here.)  Even if you argue that the manner in
which you are performing your actions is not actually surveillance,
or you argue that it is legally permissible, someone else will
certainly come along and make a reasonable argument that you are
indeed engaging in illegal surveillance.  They may even suggest to a
judge that you are in the process of constructing a botnet and demand
that your domains be seized, and may successfully obtain an ex parte
temporary restraining order (TRO) against Chainalysis and similar
corporations to have domain(s) seized.  Any and all arguments may be
added in here, there are 196 countries in the world today - each with
their own unique laws - (maybe less by the time you read this) and a
shit-ton of possible legal arguments that can be made by creative
minds that might want to sue you if you have been surveilling people,
each different depending on where your surveillance corporation is
domiciled.  There are plenty of legal processes available for people
to do exactly that.  You are indeed subject to having that happen to
you if you continue to surveill the network even if you are doing so
on behalf of the state for the purpose of gathering information for a
state's compliance initiative.

So, don't delude yourself, and be happy if all that happens is your
little surveillance initiative has to close its doors (or gets sued if
it stays open).  Because that is the legal side of things.  The
extralegal stuff is far worse.  The community is helping you by asking
you gently to close up shop and go away. It is a helpful suggestion
and I believe also a fair warning, again, a shot off the bow.

On the development side, developers are certainly responsible for
doing what they can to resist this kind of surveillance activity.  But
I have a feeling that will be a different thread which is more
technical and so won't comment on it here, except to say it will
likely involve working toward giving the user an anonymity option
which can be exercised as part of any transaction.

Thy Shizzle:
 I don't believe that at all. Analyzing information publicly
 available is not illegal. Chainalysis or whatever you call it would
 be likened to observing who comes and feeds birds at the park
 everyday. You can sit in the park and observe who feeds the birds,
 just as you can connect to the Bitcoin P2P network and observe the
 blocks being formed into the chain and transactions etc. Unless
 there is some agreement taking place where it is specified that
 upon connecting to the Bitcoin P2P swarm you agree to a set of
 terms, however as every node is providing their own entry into
 the P2P swarm it becomes really up to the node providing the
 connection to uphold and enforce the terms of the agreement. If you
 allow people to connect to you without terms of agreement, you
 cannot cry foul when they record the data that passes through. To
 say Chainalysis needs to cease is silly, the whole point of the
 public blockchain is for Chainalysis, whether it be for the
 verification of transactions, research or otherwise.
 
 -Original Message- From: odinn
 odinn.cyberguerri...@riseup.net Sent: ‎23/‎03/‎2015 1:48 PM To:
 bitcoin-development@lists.sourceforge.net
 bitcoin-development@lists.sourceforge.net Subject: Re:
 [Bitcoin-development] Criminal complaints against network
 disruption as a service startups
 
 If you (e.g. Chainalysis) or anyone else are doing surveillance

Re: [Bitcoin-development] Why Bitcoin is and isn't like the Internet

2015-01-21 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

3rd party / web wallets are no longer viable except as means to burn
customers and divulge (or be forced to divulge) their data to
governments and corporations.

Rather than restate what I have already posted on this matter I'll
leave it there. It's time also for those who are managing bitcoin.org
to reconsider what's posted there (the criteria for what's posted there

 - at present the web wallet section should be excluded, that is to
say, Removed! from bitcoin.org

 with the possible exception of CoinKite to remain, which has a
reasonable argument for having made such privacy advances as to merit
usage by people (and to remain at bitcoin.org)

Additionally, I see no point in recommending any of the other wallets
except Electrum, Mycelium, Core, and in the hardware side, the ones
that appear (Trezor and HW1).

Furthermore, I believe those of you who are working for Coinbase
customer operations or Bitpay (I will not name names, you know who you
are) should resign from your employment.  I will bring this point up
regularly.  You can easily find employment elsewhere, your skills are
in high demand.

- -O

Alon Muroch:
 Bitcoin has a major crossroad ahead regarding a suitable platform
 for the average non technical main stream user. Until now the
 majority of the available solutions were at two extremes, or DIY
 your security and privacy *OR* let a 3rd party service do it for
 you. The DIY solution is obviously not scalable, but it seems that
 3rd party solutions are not scalable as well. If we compare for a
 second a 3rd party services with traditional banks, it seems banks
 have two major advantages over them. Entry costs for creating a
 bank are HUGE so a priori very few people can actually create such
 a service, second, their physical and IT security infrastructure
 are heavily regulated which insures a minimum of security level to
 the end user (and even so money is stolen frequently). Entry costs 
 and regulation do not exist in the bitcoin space, meaning two
 programers in their spare time can create a wallet/ platform and
 the non technical end user cannot know if his money is safe, did
 they hire the right security expert, did they invest enough in
 protecting and backing up his keys, etc.
 
 Many services tried to tackle those problems with multisig (2 of 2
 and 2 of 3) to create a syntactical 2 factor authentication/
 authorisation mechanism but in reality those solutions didn't
 really increase security and their failure point is always a single
 device. Coupling those said problems with the fact that bitcoin
 transactions are irreversible and are a scarce commodity, trying to
 insure them the way our money is insured by the government when we
 deposit it in the bank becomes a huge problem. Premiums will be
 very high and will only grow as the appetite of hackers to steal 
 coins increase.
 
 I personally believe we have the tools for creating a platform that
 is both secure and private but most importantly it does it in a
 decentralised way. Creating true 2 (or more) factor authentication/
 authorisation schemes can improve dramatically personal security to
 a point where 3rd party wallet services will become a thing of the
 past. Succeeding in that will mean the next billion non technical
 bitcoin users will have a platform to use securely and a base line
 for building cool services on top.
 
 Alon Muroch bitcoinauthenticator.org
 
 
 
 
 
 
 --

 
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in
 Ashburn. Choose from 2 high performing configs, both with 100TB of
 bandwidth. Higher redundancy.Lower latency.Increased
 capacity.Completely compliant. http://p.sf.net/sfu/gigenet
 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUwAGjAAoJEGxwq/inSG8CJoAIAMDR0h40IhFQNa8BW4AFeKUR
7tg84e752c7wY153GY/P7MOFL6w3E9h4tXzxdohTMMfF5Q6Ip6HaaifYmMpegFSS
WEHK0a3C2F+4sQMmMBtWbfyPsG5sJYtldY5hboSbh/6vXJJLXLSd+Sz3WHYx1Qjs
qn6sw5CA2Q0fborTxcsNZixUXD/OF5tTjDozp+KfnZ0imvBoKfhfJFlaNUXNon7U
zdPfahOrRIM5o70pjo6VwoutKRXr49JIoi47r9Uc3ujckUbLA5CVBApj4FApayb5
sXk8Ks+p6IvBr6Q0ycxXOKmPwbSALC5pLa7Ncb1MFFBGzxKFsMjoRwOLTXHlLUE=
=WgO4
-END PGP SIGNATURE-

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Um ~ jurisdiction of wallet provider?

If that's the (perhaps ot) bit you want to run on this thread then my
comments are:

Get out of web wallet businesses now.  It's not a jurisdictional
question anymore, although I think there used to be very valid long
running debates on where it would be best to do business.  Now it just
feels like you will be bouncing from one place to another -
determining where your exit is as soon as you establish a (physical)
presence, because jurisdictions sense a serious threat from the
advancement of financial cryptography as it will evolve in the next
several years. So you have to be mobile, or do something like what
they are establishing at blueseed (see http://blueseed.com which is
just off coast of San Francisco).  Please perk up and don't just swipe
to delete, read the whole e-mail.  There are some configurations (e.g.
the zero knowledge bit) you can do to mitigate the issues but if you
are asking users to log in and log out of a service that relies on a
web site then in the end you doom them (and any service you provide)
to mandatory storage of customer data and ultimately loss of customer
resources due to identification of the customer.

I think you need to stop quibbling about the details and just get over
it and understand that the problem of web wallet users and
corporations that serve web wallet customers being forced to give up
information constantly to governments means that web wallets are
certainly no longer a viable solution.  And post-cromnibus with the
extra financial surveillance provisions now passed on 3rd party
matters, it's even worse.  This is not subject to debate, it's just a
fact.  Period.  Web wallet corps exist now only on a model that exists
to burn the users.  Convenient?  Yes.  But is it good for the users in
the long haul?  Absolutely not.  Do alternative to the web wallets
exist? Absolutely.

Back off.. Go to p2p.  Stop advocating for webby solutions.  In fact,
I don't think that anyone working for coinbase or bitpay should be,
anymore.  I think that on principle you should withdraw and end your
employment from such services.

Core?  Good.  Electrum Wallet?  good.  Mycelium? Local Trader? Open
Bazaar?  Could be better, but great.  These are the kind of things we
need.  No signups, avoids centralizations, no grabbing your data, no
ID collection and requirements.

As to the issue of auto-updating itself... I think the simplest answer
to this question (personally) is that (go ahead and attack me here)
there shouldn't be auto-updates... but that there should be
auto-notifications for update when (a) update is available, but that
(b) this notification should never push the user to update (e.g. the
notification should never say oh hey user if you don't update by such
and such a date, your wallet will not work or satoshis will die
because of your inaction
(stays quiet while likely 100-e-mail thread is spawned from this)

- -O

Tamas Blummer:
 Justus,
 
 In contrary.
 
 Not being in the jurisdiction of the wallet provider makes it
 harder for the user to reclaim funds taken by the wallet provider. 
 The legal hurdle to force confiscation through a wallet provider
 might also be lower if the target user is not domestic.
 
 Tamas Blummer
 
 
 
 --

 
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in
 Ashburn. Choose from 2 high performing configs, both with 100TB of
 bandwidth. Higher redundancy.Lower latency.Increased
 capacity.Completely compliant. http://p.sf.net/sfu/gigenet
 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUvsnBAAoJEGxwq/inSG8CGekIAJH4lUdk81sVfQqxZ4sKOKFM
5iAvCD4JNuV+xcCZBiNNr1GxIZEVoDRQYupo7wB1A5uGW+STLHDGsEMuDNyiOcNl
oSsJQFZJabxL7dIn8g89Gw+8J8LtYKEkHHZLk5J5QF0DkRljXjEcOV4KL6WXhdl5
ToV01POMUBbSJsQt2lLznmCvQ+4QW5/GJ9Hk04HIub+kzuil0R23CgRH9QFevC9S
2/RT3NnfGFu+jU5+K/o8RbuUuzExq94x4w266IEmJc0NsLHxnxsg2PefabQbfdzp
P7FU7+D9NsIOaBGTXnQK80kpgRCJ49Gf9HXHKFYg2KCFuqgJYa8DnHm1Xlfo7DQ=
=yS8H
-END PGP SIGNATURE-

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-11 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please comment if possible on some of the techno-cultural implications
of ongoing development of bi-directional micropayment channels?

For example, consider zakat example(s):
www[dot]hidaya[dot]org/publications/zakat-information/10-what-is-zakat-obligatory-charity
That involves a system based on trust and which is somewhat circular
in nature (such funds as are going in one direction may also be going
simultaneously on balance in another direction somewhere else), where
the trustless bitcoin utilizes math, rather than personal trust in
order to keep the system going.
Here is some more on zakat:
en[dot]wikipedia[dot]org/wiki/Zakat
en[dot]wikipedia[dot]org/wiki/Ridda_wars (Discusses in depth some
differences between Sunni and Shiite on the subject of Zakat)

A sort of traditional philanthropic historic overview in the USA from
the 1900s forward is seen here, but it is fairly minimal and not too
revealing:
www[dot]nptrust[dot]org/history-of-giving/timeline/1900s/

A general microgiving example(s) (not yet fully modeled but for which
some prototype software ideas and concepts are in process today):
abis[dot]io

Cheers,

- -O

Mike Hearn:
 The original design is documented at the bottom of here:
 
 https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party



 
In this design, time locked transactions can be broadcast across
 the network and replaced by broadcasting a new transaction that 
 uses higher sequence numbers. That's what the sequence number field
 is for. It was intended to allow arbitrary high frequency trading
 between a set of parties, though the channel notion is a simple
 way to think about the two party case.
 
 The issue is that you can broadcast transactions with a lock time 
 far in the future to fill up memory, and keep broadcasting 
 replacements to use up CPU time and bandwidth.
 
 Additionally, there is a school of thought that says Bitcoin must 
 work even if lots of miners are malicious and willing to break 
 arbitrary things in order to try and get more money. I don't think
  Bitcoin can really be a mainstream success under such a threat 
 model, for a whole bunch of reasons (e.g. the economy relies pretty
 heavily on unconfirmed transactions), but under such a threat model
 there's nothing that forces miners to actually include the latest
 version in the block chain. They could pick any version. In the
 2-of-2 channel model it takes both parties to sign, so clients can
 enforce that all versions have the same fee attached.
 
 I disagree with Gregory that people refuse to use protocols that 
 are affected by malleability. There aren't any user-friendly apps 
 that use refunds currently, so we have no idea whether people would
 refuse to use them or not. It's an open question. The answer would
 probably depend on the real prevalence of attacks, which is 
 currently unknowable and likely application specific.
 
 
 
 --



 
Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot 
 Media, is your hub for all things parallel software development, 
 from weekly thought leadership blogs to news, videos, case studies,
 tutorials and more. Take a look and join the conversation now.
 http://goparallel.sourceforge.net
 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUsj9+AAoJEGxwq/inSG8Cvu8H/RutYcVPdN+GrtAYxNkm2x7n
v/NtBIZwGs7iN6g14Te/ynEfBQRzYwVABL+d1nEuNdlYl6IB4mCXkFrz7hlFJNgK
2WOq4iKApS1tV9MFAcaxnYy6W8z5T8VpQRqxNbbFEG145cGP2l/5CYwXOmPOBdp7
qTnLs9oVyhixcfb/piFhd/4xRvlvwxVyvCamrAXBUIpgpW/VB/kfG8ikCazvcJB6
lSY+CogSGqObjlO7PhKcsZz/gTNrSIp40upyktfqZvQxWLp4WR7+GYz7vUXoofQO
Obt3ya6lZBLLL0EHYkJzAiKRy4aoIgIUzyshIHTdiQIwZC6HWnv2++sJdneng8g=
=+e6h
-END PGP SIGNATURE-

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-16 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

bleep bloop

Peter Todd:
 On Fri, Dec 12, 2014 at 01:41:34PM +, odinn wrote:
 Peter... It kind of sounds to me that (as fine of a position
 paper as this is) on _certain_ points, you're falling prey to the
 but it's inefficient, but it's a scamcoin, but luke-jr told me
 so argument...
 
 I prefer to make robust arguments; if I can start with accepting
 that 95% of what my opponents say is true, yet still end up being
 correct, all the better!
 
 I think the Mastercoin devs are doing fine work and I consider
 the zerocash devs to have developed (in v2, mint and pour) to
 have developed something that will really turn the world on its
 ear, but what do I know? Nothing.  Nothing at all.
 
 My personal opinion is that what Mastercoin has started will turn
 the world on its ear, but I'd be surprised if the succesful
 implementations of the underlying ideas come from that team. But
 there's nothing surprising about that - when was the last time you
 used Netscape Navigator, let alone NCSA Mosaic?
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUkNluAAoJEGxwq/inSG8CKy0IAJmCUmDbaCx33/km0J2mP7ha
kxX3fxiPpicD8hXa4FXBsrYqj7ZFu0OmFOU/ei0AXMOuu94rQdIp6hon3f5GO73J
WVT2Toqd2GTCXhmddyqtOzZ5mYOyZhlJUYlNjbwTmlk+U2hQbZC1aJ4AKdmjQn5v
9DFkZfqBSsNhcoLCKoVqY3l4qzw0XqeL6fOYkz2H9AssWdcUV9JB5C0wm8rI70AX
qcxABgrKDwhThWgHyHGZXHLCvRRpMUFFVbzO67BPZA2R+gXYtOAVDozl7jdx7PLl
x3nyzZK3pX1bqcT2T5fD8wQtu4yJ3RCBVWzHfrA5MF6q4Yh6DEh7DnO8ccOnPlk=
=1os7
-END PGP SIGNATURE-

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread odinn
-of-publication systems are inefficient 
 
 
 If you're talking about inefficient from the perspective of a
 full-node that does full validation, they are no different than
 (merge)-mined sidechain and altcoin alternatives. If you're talking
 about efficiency from the perspective of a SPV client, then yes,
 proof-of-publication systems will often require more resources than
 mining-based alternatives.
 
 However it must be remembered that the cost of mining is the 
 introduction of a trusted third party - miners. Of course, mined 
 proof-of-publication has miners already, but trusting those miners
 to determine the meaning of that data places significantly more
 trust in them than mearly trusting them to create consensus on the
 order in which data is published.
 
 Many usecases involve trusted third-parties anyway - the role of 
 proof-of-publication is to hold those third-parties to account and
 keep them honest. For these use-cases - certificate transparency,
 audit logs, financial assets - mined alternatives simply add new
 trusted third parties and points of failure rather than remove
 them.
 
 Of course, global consensus is inefficient - Bitcoin itself is 
 inefficient. But this is a fundemental problem to Bitcoin's
 architecture that applies to all uses of it, a problem that should
 be solved in general.
 
 
 Proof-of-publication needs scamcoins like Mastercoin and
 Counterparty 
 ---

  First of all, whether or not a limited-supply token is a scam is
 not a technical question. However some types of embedded consensus
 systems, a specific use-case for proof-of-publication, do require
 limited-supply tokens within the system for technical reasons, for
 instance to support bid orders functionality in decentralized
 marketplaces.
 
 Secondly using a limited-supply token in a proof-of-publicaton
 system is what lets you have secure client side validation rather
 than the alternative of 2-way-pegging that requires users to trust
 miners not to steal the pegged funds. Tokens also do not need to
 be, economically speaking, assets that can appreciate in value
 relative to Bitcoin; one-way-pegs where Bitcoins can always be
 turned into the token in conjunction with decentralized exchange to
 buy and sell tokens for Bitcoins ensure the token value will always
 closely approximate the Bitcoin value as long as the protocol
 itself is considered valuable.
 
 Finally only a subset of proof-of-publication use-cases involve
 tokens at all - many like colored coins transact directly to and
 from Bitcoin, while other use-cases don't even involve finance at
 all.
 
 
 
 --

 
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and
 Dashboards with Interactivity, Sharing, Native Excel Exports, App
 Integration  more Get technology previously reserved for
 billion-dollar corporations, FREE 
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk

 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUivCNAAoJEGxwq/inSG8ChVUH/26zj2pj7AF+oa2RDkPZN980
qFTY7x2s9w97bEuCiFfFpYjIP26mY4+snuoTWBa8yCp7gLVVsk9JKkN0dmXIboXf
ocoJY9s/wT7QLqJMRRwWb/8XPKwjXB10PNawCRoUk++8E0Y+W6mxiH5Gs1UnYKwI
2DHHh/hTh35mR5burwdLGEMLaVtK4BFLJTZwW+4xlWESsoWeQnxEuty799HldOaN
+wms8dvtZlzJElLUPjBGBZT6DRTaPsvqSvQ0CnHI84LYwuUObMcV89mkBcfTHlMt
MczwaO7CCc/jmoOoQKDyIVuW1eJeXggln+LOS34qwH8rCgjdOZeT3y4PgUTZ+AM=
=Sm96
-END PGP SIGNATURE-

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoind as a library

2014-11-27 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



A recent comment on this (I think)...

https://github.com/bitcoin/bitcoin/issues/4564#issuecomment-49558760

Reflecting on an approach from a different but related project, as a
result of an issue discussion in DW, stealth and coinjoin from that
project were broken out as distinct repositories - see:

https://github.com/darkwallet/stealth.js
and
https://github.com/darkwallet/coinjoin.js

installable using npm


I'm probably missing something here, but it seems to me like breaking
things out as distinct repositories might be a good approach.  The
question is what would be in a distinct repository or repositories?
Currently if someone is looking at core, everything is seen here:
https://github.com/bitcoin/bitcoin/

slips away for holidays




Wladimir:
 On Thu, Nov 27, 2014 at 5:27 PM, Mem Wallet
 memwallet.i...@gmail.com wrote:
 
 Is there an intention that the various internal libraries
 could/should be strengthened and heirachicalized such that they
 would be suitable for 3rd party development of bitcoin related
 services and tools, or is that not a goal, and some other project
 would have to fill such a role ?
 
 The plan is to provide the consensus functionality as a library,
 the essential parts that make bitcoin bitcoin. 0.10 will have a
 basic transaction/script verifier available. In the version after
 that, I expect this will be extended to further utxo set
 management, but no API has been worked out for that yet. There are
 also plans to add a library for transaction signing.
 
 However there is no goal to expose *everything* as a library. 
 Certainly not wallet- or user interface related functionality. 
 Specialized utility libraries would fill this purpose better. See
 for example https://github.com/bitcoin/libbase58 for base58
 processing.
 
 Wladimir
 
 --

 
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and
 Dashboards with Interactivity, Sharing, Native Excel Exports, App
 Integration  more Get technology previously reserved for
 billion-dollar corporations, FREE 
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk

 
___
 Bitcoin-development mailing list 
 Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUd4SAAAoJEGxwq/inSG8Che8H/3PMt0NQSrVSqnC6WC9scXdD
aqGnsdZkhnLRs0szJSTjiQm+xCk6aUcEsKCGu298Xhkv38S4DSfWa+OhFZGPKmOZ
wlfnXAz3SprQ8xzy/NVqavtFRk+pGDRxgBIzzgBfbz3BdPKxMywi9BNnaK0YA6UA
08giKmtqblHTKmKuguK23YIYjAAk3Csg0Vg4BgN2MgeEXl9PJI6vh4+jNckXWtAT
/gKjPXG/Q+f9wl5pxSY/+ZfmRUtjHye3f8hHjpSEmxjpB9QzeeDg63DzAhOH0ip5
vXaIePZED//SmN3eH+S22vAx/a83URkr5B2+8Cffx/oO5laYRthoMHLi/2+XkO4=
=UWhs
-END PGP SIGNATURE-

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-26 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please see also the following:

https://cpunks.org//pipermail/cypherpunks/2014-November/005971.html

Respect,

- -Odinn

Jeff Garzik:
 I don't recall being contacted directly, but the attack has been 
 discussed.  It relies on a number of conditions.  For example, if
 you are over Tor, they try to kick the machine off Tor, _assuming_
 that it will fall back to non-Tor.  That's only true for dual stack
 nodes, which are not really 100% anonymous anyway -- you're
 operating from your public IP anyway.
 
 
 On Wed, Nov 26, 2014 at 2:47 AM, Jean-Paul Kogelman
 jeanpaulkogel...@me.com
 wrote:
 
 This paper was just posted on reddit that describes how an
 attacker can de-anonymize clients on the bitcoin network. It
 mentions that the core devs were contacted prior to publication.
 I was just wondering, how many of these issues have already been
 addressed?
 
 
 Paper (University of Luxembourg): 
 http://orbilu.uni.lu/handle/10993/18679
 
 
 Kind regards,
 
 Jean-Paul
 
 
 --

 
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and
 Dashboards with Interactivity, Sharing, Native Excel Exports, App
 Integration  more Get technology previously reserved for
 billion-dollar corporations, FREE
 
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk

 
___
 Bitcoin-development mailing list 
 Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 
 
 
 
 --

 
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and
 Dashboards with Interactivity, Sharing, Native Excel Exports, App
 Integration  more Get technology previously reserved for
 billion-dollar corporations, FREE 
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk

 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUdgpQAAoJEGxwq/inSG8CBCMIAI8IyyzxbhC0NVY8wyLXaHnW
um0HkmrP0bknL0ugjXDXHIBJmadH9uwOT5g1WpJ1siJbjm7nTNn2EXui8EKaX133
SkdZu0IVV5wDZB0OnIDxxx4cyuwNBWbxLh0boVCzydUlZaxQCx88SriKLNj4NrAT
oPBuOSL9Z/EsscO8PIh73+t7rdsAQo7koFcwVB8OgjKKATZpAgu4/hwBDoSnhv/U
F/X1EcQifg5j2DPmPmJo2/u9PmfHjgDUevw7qJOYNDFMPq4zhi6IC+x2aAXZg0rk
jHF79loJ5vueMaU6APVcIQ4izbyzU0y0JaY4Rukq0YkuXCMgZB8BJlS/BPntZdY=
=K2tn
-END PGP SIGNATURE-

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Running a full node

2014-11-06 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

If you are considering running a full node (or think you are running
one), you should read the comments here:

https://www.reddit.com/r/Bitcoin/comments/1scd4z/im_running_a_full_node_and_so_should_you/cdw38ve

Thomas Zander wrote:
 On Thursday 6. November 2014 10.51.38 Francis GASCHET wrote:
 Dear all,
 
 I'm currently discovering the Bitcoin's universe. I installed
 bitcoind on my PC and I'm currently testing different things on
 testnet. I just read an article saying that the risk for Bitcoin
 in the future is the decreasing number of full nodes, with
 appropriate resources. There are only few of them in France !
 
 My company operates a dual homed Internet access and has some
 capacity to host an HA server in a secured environment. So I'm
 thinking about setting up a full node. But I'd like to know what
 storage, RAM  and bandwidth resources are needed. I guess that
 the problem is not the CPU.
 
 There is a stats script running on this node;
 
 http://213.165.91.169/
 
 more peoples opinions; 
 https://bitcointalk.org/index.php?topic=760094.0
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUW+pWAAoJEGxwq/inSG8CMOEH/jLElWVYTepe0kwnHiguvM2T
Y16fSfLuptdpHU0+2du0U7zO14UvhL7mA2cQxDPxvC72hqRfMld3x5+Pz1mM8aik
Xgot1XrFEo2fQn4CRyaEdwIj0SG5+dcnNSPWJcAf/aLSmw6BFaFgVbG9Qenzrvfn
wgJBaqP0RWTox6ctsDZAHbVTo1+t4/ERwX1YMcQJkAKLN4IZmYqFIaRV6TRU5jSy
af1Smnn+2GmryYlAH+DDJ/4C7BxfCCMnWuItjne7AxMUI/4aDJO1lv/s5lkQYCJU
2dYFV5ZYyS+Ff9895eI9GDu2N+b/QuiiKWsX8leshmCB8/XrPjHqjfP0eABnBKM=
=Augd
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)

2014-11-03 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Possibly relevant...

https://www.iacr.org/archive/eurocrypt2002/23320001/euro02.ps

Some interesting stuff here too
http://des.cse.nsysu.edu.tw/asiacrypt2014/accepted/index.htm


Andrew Poelstra wrote:
 false proof

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUV9mzAAoJEGxwq/inSG8C0qwIAJZdOmeSK7pIw2KTj0lQlPIp
MIc1w2KL+qIVXSrlqyNlcIhlW4gK+/cuYD+PZ7wSGHV2k9OD6AcOo3JfGYgk4LP/
3GIrY/+TQVoTRKVgTGvR2uqUILuwCPTtr/7Uy2s2y2mveyFda6ZA7sMeoeiTsQQe
9aPS6tLK0W7g+gbqM2QwC3G521iPJ9RE9JOsxCVxGplVUuOLpPzovQjFO3MKYdeu
eBq5ORr4ICvphk+yVygkQvw/AuYZjqTuKEjRfK0v5EryZM9Qsj/1pEhYAH8tdLrV
4NB5lDXIo3rt58wPqyeacMF6WW2LShb1VDl6Hnvi35GXURpBgxXM/N4pO+l444k=
=9q9h
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-26 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Q., re. transaction fee changes / txconfirmtarget described at
https://github.com/bitcoin/bitcoin/blob/c8a25189bcb1381eddf46b9a9743ba48e929439e/doc/release-notes.md

(for Core 0.10)

~ does this include the floating fees for 0.10 as described at
https://bitcoinfoundation.org/2014/07/floating-fees-for-0-10/ ?

thanks in advance for clarifications

Wladimir wrote:
 Now that headers-first is merged it would be good to do a 0.10
 release soon. Not *too* soon as a major code change like that takes
 some time to pan out, but I'd like to propose the following:
 
 - November 18: split off 0.10 branch, translation message and
 feature freeze - December 1: release 10.0rc1, start Release
 Candidate cycle
 
 That leaves three weeks until the freeze. After the release and
 branch split-off, the RC cycle will run until no critical problems
 are found. For major releases this is usually more painful than for
 stable releases, but if we can keep to these dates I'd expect the
 final release no later than January 2015.
 
 Let's aim to have any pending development for 0.10 merged before 
 November 18. Major work that I'm aware of is:
 
 - BIP62 (#5134, #5065) - Verification library (#5086, #5118,
 #5119) - Gitian descriptors overhaul, so that Gitian depends =
 Travis depends (#4727) - Autoprune (#4701) - Add warmup mode for
 RPC server (#5007) - Add unauthenticated HTTP REST interface
 (#2844)
 
 Let me know if there is anything else you think is ready (and not
 too risky) to be in 0.10. You can help along the development
 process by participating in testing and reviewing of the mentioned
 pull requests, or just by testing master and reporting bugs and
 regressions.
 
 Note: I intended the 0.10 release to be much sooner. The reason
 that this didn't pan out is that I insisted on including
 headers-first, and this took longer than expected. There seems to
 be a preference to switch to a fixed (instead of feature-based)
 6-month major release schedule, ie
 
 - July 2015: 0.11.0 (or whatever N+1 release is called) - January
 2016: 0.12.0 (or whatever N+2 release is called) - July 2016:
 0.13.0 (or whatever N+3 release is called)
 
 Wladimir
 
 --

 
___
 Bitcoin-development mailing list 
 Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUTLbyAAoJEGxwq/inSG8CzkgH/jqh3+RxdFR1sFn8PENbUvKN
M3GUF3otRDenuVOY6Gbs1Sv3IBToC1zAR1RdktYeTrfQlCgO89ybASJapqQ6H8XP
7STY99dtZgRxkSwsE5bMHceVlHlSrtCBoPCZpPte9+8KVZUpQ/WNNPhjU84sQTj5
n2wkG7GdtD4vEoLHgLo1yEMoeRcwS8eb7kUeYAdRQbAOdNBqUkcs0FW2yvAnk//M
/ubtWoWr7c+Ksozp45I7rtB6UL1YrYMBJURwKsCc62mpnc1rkvedRmQVC1KO/em1
8nAvobRUbrExPtNO8+AkWZsyiSIR+PANV4h3IOHbERC6L8iGrD/QiUjuAjXXwSw=
=tplQ
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-26 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks,

Followup question on https://github.com/bitcoin/bitcoin/pull/3959 :

This describes current dust change handling:

(gavinandresen)
https://github.com/bitcoin/bitcoin/pull/3959/files#r13494256

Related Question:  This describes how wallets would let you know a
transaction is 'precious' with a flag --
(jgarzik)
https://github.com/bitcoin/bitcoin/pull/3753#issuecomment-49464772

- -- however, it doesn't appear to be part of 0.10 anymore ~ what is it
that would keep it from being incorporated into 0.10?
(or was that addressed by a later commit?)

Possibly also related (suggested dusting feature):
https://github.com/bitcoin/bitcoin/issues/4079#issuecomment-41010593

Thanks in advance for your responses.


Wladimir wrote:
 On Sun, Oct 26, 2014 at 9:55 AM, odinn
 odinn.cyberguerri...@riseup.net wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 Q., re. transaction fee changes / txconfirmtarget described at 
 https://github.com/bitcoin/bitcoin/blob/c8a25189bcb1381eddf46b9a9743ba48e929439e/doc/release-notes.md


 
(for Core 0.10)
 
 ~ does this include the floating fees for 0.10 as described at 
 https://bitcoinfoundation.org/2014/07/floating-fees-for-0-10/ ?
 
 thanks in advance for clarifications
 
 Yes, floating/smart fees has been merged a while ago
 
 - https://github.com/bitcoin/bitcoin/pull/3959 -
 https://github.com/bitcoin/bitcoin/pull/4250
 
 Wladimir
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUTTq8AAoJEGxwq/inSG8C8PYH/jrZIgecpEiwUYdRGT/dxvrE
qHrlsJz8aPY/E/ojNE4MY4Con5seH2IRL+qg14pZvIQNJSipRYejh0BeqQ2YkfAF
leEt8PlpblNqV0Ieq1VmdJK5wnF3crNZsNdPv73Z7UXplXo8sG+lYGENgC11s+wN
QI29F3Kkrqk66aa6VmRbNzRIgL1JYfTkZLba9ApZNxJsugeOgmlOQw6+q5hgChKy
lxN5s+P/wohH0n047ksYdiMnXbZwPL2scUEN87D74KYqYdCa6AB7vMkLETO2msSg
ndC9ge8LfTODlEuFA9rQ8CgLAkwVWCaCbqph7iqTt6Cvdnqeo9XvlrpcB2B31hI=
=xn6P
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP process

2014-10-19 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Earlier in the discussion I suggested Discourse so that the BIP page
would be able to look smoother and draw more input.
Unsystem forum is run on Discourse and has twitter, github, and e-mail
integration.
For those who haven't explored it, here is what that looks / feels like:
https://forum.unsystem.net/

I'm curious as to why this sort of solution should or should not be
considered from someone else's perspective. In the end, whatever
works best for all concerned, I'm fine with it, but I'd like to hear
more about people's thoughts on Discourse. (I kind of like the feel
of it.)

xor wrote:
 On Wednesday, October 15, 2014 10:29:43 AM Wladimir wrote:
 B) I also think it makes sense to move the BIP discussion (both 
 about the BIP process and individual BIPs) to a separate mailing
  list.
 
 bitcoin-development currently has a dual function: discussion of 
 Bitcoin Core implementation concerns, as well as global changes 
 to Bitcoin (in the form of BIPs).
 
 This makes the list too busy for some people, but it is critical
  that everyone writing a Bitcoin node or client is up-to-date 
 with proposals and can comment on them.
 
 I joined the list when Bitcoin was already in the 10-billions of 
 market capitalization, and it actually really surprised me how low
  the traffic is here given the importance of Bitcoin.
 
 So as a random stranger to the project, I would vote against that 
 if I was allowed to. There really should be *more* discussion here,
 and splitting the list up won't help with that.
 
 Greetings
 
 
 
 --



 
Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month. Get alerted through email, SMS, 
 voice calls or mobile push notifications. Take corrective actions 
 from your mobile device. http://p.sf.net/sfu/Zoho
 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJURFhXAAoJEGxwq/inSG8Cpc0H+wZauz7iOj4XZJSI3VBv+5WL
YAe8kDSOpa5ZprFntsFfKVU+cmSjXckPjCRI9+LsrfTR2L+VjAimjQTct1m6oRAo
+5ZQ8Tn2CLEVRJRUzd8zbW8QPMuQCdzvwjs1oq8anaAPdwseEC/QhTZY6Av1MB8y
nH+05mMu4YeF3RRIyjXgvxDiBBK3knoaBkbsORkVbIb7MojUBy7FnsS1JFmSs8wv
XwWnkmFjVlhC8wSQYohcTWdJablxjpKRFq1ZNgDtIoXEi0dsC+G9Gc+8xub4hA/Y
nDk85ihX17TBbB47SOJEAdpGrJjkb8OvdX2ubLnQPYth82wX/MWJTTdv2a4JGik=
=uYGH
-END PGP SIGNATURE-

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Reconsidering github

2014-08-29 Thread Odinn Cyberguerrilla
 On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik jgar...@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@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.


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] ASIC-proof mining

2014-07-07 Thread Odinn Cyberguerrilla
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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Anyone still using SOCKS4?

2014-07-07 Thread Odinn Cyberguerrilla
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 laa...@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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Anyone still using SOCKS4?

2014-07-07 Thread Odinn Cyberguerrilla
 On Mon, Jul 7, 2014 at 8:34 AM, Odinn Cyberguerrilla
 odinn.cyberguerri...@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.


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] CoinJoin bounty fund question

2014-06-17 Thread Odinn Cyberguerrilla
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


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Odinn Cyberguerrilla
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


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper

2014-05-21 Thread Odinn Cyberguerrilla
 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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70 proposed changes

2014-05-05 Thread Odinn Cyberguerrilla
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
 andr...@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=121054471iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bug in key.cpp

2014-05-05 Thread odinn . cyberguerrilla
You are right there is a bug in there.

But the value is not 25% I think.  Tinker some more. :-)

 I think i see a bug:

 line 273 of key.cpp

 if (rec0 || rec=3)
 return false;

 Afaict, 3 is a perfectly valid value, meaning 25% of sig- key recoveries
 would fail erroneously...
 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin for W3C Payments Workshop, March 24-25

2014-03-19 Thread Odinn Cyberguerrilla
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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2014-03-14 Thread Odinn Cyberguerrilla
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...@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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Multisign payment protocol?

2014-03-11 Thread Odinn Cyberguerrilla
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 jgar...@bitpay.com wrote:

 On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

2014-03-05 Thread Odinn Cyberguerrilla
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
 000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
 --
 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=122218951iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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=122218951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)

2014-03-03 Thread Odinn Cyberguerrilla
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
 e...@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=122218951iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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=122218951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Fee drop

2014-02-25 Thread Odinn Cyberguerrilla
 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.4 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
 b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2
 --
 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=126839071iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Fee drop

2014-02-25 Thread Odinn Cyberguerrilla
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.




--
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=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoind json API (gettx/raw) (newbie questions #2)

2014-02-18 Thread Odinn Cyberguerrilla
 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=121054471iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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=121054471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Malware authors and best practices for addressing the issue from development / licensing perspective or other

2014-02-09 Thread Odinn Cyberguerrilla
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.


--
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=121051231iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

2014-01-27 Thread Odinn Cyberguerrilla
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=123612991iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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=123612991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

2014-01-18 Thread Odinn Cyberguerrilla
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 l...@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 l...@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=119420431iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@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=119420431iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@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=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

2014-01-18 Thread Odinn Cyberguerrilla
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.cyberguerri...@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




--
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=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Stealth Addresses

2014-01-15 Thread Odinn Cyberguerrilla
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 jgar...@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 gmaxw...@gmail.com
 wrote:
 On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
 bendavenp...@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=119420431iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@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=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Stealth Addresses

2014-01-14 Thread Odinn Cyberguerrilla
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 PaymentRequestPaymentDetails 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

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-10 Thread Odinn Cyberguerrilla
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=111408631iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-07 Thread Odinn Cyberguerrilla
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=111408631iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
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=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development