Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[odinn]

y.
> 
> 
> 3) Legal contracts give the advantage to non-anonymous miners in 
> Western jurisdictions
> 
> Suppose CoinPayCypher is a US company, and you're a miner with 1% 
> hashing power located in northern China. The barriers to you
> succesfully negotiating a contract with CoinPayCypher are
> significant. You don't speak the same langauge, you're in a
> completely different jurisdiction so enforcing the legal contract
> is difficult, and being just 1%, CoinPayCypher sees you as
> insignificant.
> 
> Who's going to get the profitable hashing power contracts first, if
> at all? Your English speaking competitors in the west. This is
> inherently a pressure towards centralization of mining.
> 
> 
> Why isn't this being announced on the bitcoin-security list first? 
> --
> 
> I've had repeated discussions with services vulnerable to
> double-spends; they have been made well aware of the risk they're
> taking. If they've followed my own and others' advice they'll at
> minimum have constant monitoring of the rate of double-spends both
> on their own services and on the P2P network in general.
> 
> If you choose to take a risk you should accept the consequences.
> 
> 
> How do I actually use full RBF? ---
> 
> First get the full-RBF patch to v0.10.2:
> 
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
> 
> The above implementation of RBF includes additional code to find
> and preferentially connect to other RBF nodes, as well as Bitcoin
> XT nodes. Secondly, try out my replace-by-fee-tools at:
> 
> https://github.com/petertodd/replace-by-fee-tools
> 
> You can watch double-spends on the network here:
> 
> http://respends.thinlink.com/
> 
> 
> References --
> 
> 1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also
> novel variants of existing attacks w/ Bitcoin XT and Android
> Bitcoin Wallet", Peter Todd, May 23rd 2015, Bitcoin-development
> mailing list, 
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/
msg07795.html
>
>  2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds", June
> 2nd, 2014, Erik Voorhees, 
> https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transact
ions-in-8-seconds-7c9edcb3b734
>
>  3) Coinbase Merchant API, Accessed Jun 19th 2015, 
> https://developers.coinbase.com/docs/merchants/callbacks#confirmations
>
>  4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network", 
> March 14th 2015, Grace Caffyn, Coindesk, 
> http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-
on-bitcoin-network/
>
>  5) "First-Seen-Safe Replace-by-Fee", May 25th 2015, Peter Todd,
> Bitcoin-development mailing list, 
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.ne
t/msg07829.html
>
>  6) "Cost savings by using replace-by-fee, 30-90%", May 25th 2015,
> Peter Todd, Bitcoin-development mailing list, 
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/
msg07813.html
>
>  7) "Tampering with the Delivery of Blocks and Transactions in
> Bitcoin", Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame
> and Srdjan Capkun, Cryptology ePrint Archive: Report 2015/578, Jun
> 10th 2015, http://eprint.iacr.org/2015/578
> 
> 
> 
> --
- 
>
> 
> 
> 
> ___ 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

iQEcBAEBAgAGBQJVhcdfAAoJEGxwq/inSG8CVxUH/1E7P/fuAaDaVMGexaW8MVRT
wEPx/sI1IU7S7UC5wXdcm9EufSK4smPLyPuW97LAPRIGnSvTF8BEYW+EW1hLtt0V
p9Vbj7+Ii5CJtarLebjeYKjiNSXF8h2p8oH+eeCjUygnzHt5Hsbc8R0aMRyPDJkT
lNQmzWGxN1rBTjTQZ+FDA2E2AA1Dkv7UXL15MwudxLOCUONTMh3uwUKC5dz9HE+5
dz3iZWx879VLuaQscDz65FBf5axSKFjL+RGkIuPLF8B1ybsSl0ZYEctmPIv5Ld4V
w0bw+oABCFvCKbINdUY+VOdXogDXJDVmCaY/Bbu6sPoZcr0FmHrvHd9KfngjkR4=
=7W68
-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

[odinn]

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

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

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

[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

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

[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

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

[odinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Recently I saw the following video:

https://www.youtube.com/watch?v=8JmvkyQyD8w&t=47m58s

Hadn't seen it until just today, although it was done on June 8, 2015.
So this is a bit dated, but to me it was a bit of a stunner to see the
extreme nature of (some) of the views presented in this video.

Let me be blunt, I have serious concerns regarding threats issued by a
developer in this video, and I think that it is entirely possible that
those of you who are core developers have already seen this and have
been discussing it.  But I am interested in seeing this resolved here
on this list openly and having it resolved.  It's sad and unfortunate
to me, but I feel that it's necessary to do this.  Identify what's
happening, address it squarely, have the person who is threatening
others explain his/her behavior, deal with the problem and move on.
This seems to be very important.  Please tell me if I am wrong about
this or totally flawed in my perspective here.  Go right ahead.

In this video, a particular developer makes the following statement,
stating in part:

"My preferred solution is that Gavin revokes commit access from
everyone else in the project, and then... makes the change himself"

Regardless of how you look at this, and even if we believe that Gavin
will not respond to that developer's request for a so-called
"solution," such a statement (by any developer) is indeed both a
threat and an act of sabotage against the larger bitcoin community.
We should certainly be thankful therefore, for the recent policy
change at bitcoin.org which can be seen here:
https://cloud.githubusercontent.com/assets/61096/8173297/578483f8-1399-1
1e5-8f48-96f33d12b996.png

I firmly believe that any developer who made a statement suggesting
that commit access of others in the project be revoked so that they
can proceed with their personal plan, needs to answer for having made
such a suggestion with a formal apology to this list, followed by an
explanation for why they themselves should not have their commit
access removed.

Overall, however, this sort of bombastic, nuclear suggestion makes me
seriously concerned for the future of bitcoin (as well as any
cryptocurrency which has repositories on Github).

So, you know who you are:  Apologize for your statement ("preferred
solution") and explain to the community why you should still have
commit access in light of the threat you have made to all the other
developers (and indeed to all participants of the bitcoin community).
 These "nuclear options" are unacceptable to us all.

Respectfully,

- -O


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

iQEcBAEBAgAGBQJVgoc3AAoJEGxwq/inSG8C6QYH/1Ag+4ESTSUPkP8PCTj1AJds
J4MmBz4cX7IYsSttTAjyiwd6oTHCU+wAcXtgZYpzr8rWF62bG5/+kAFUfjKwNsGM
WqcdNOR6h8fQulx8niuro8kZF/xOsG5eHtRK2FMCorxj0t6qn4pH5WAQL73J3hXQ
xI831Nt/L7VTa0jlKbr2/VGlqh6CtGrZ9mXp6aV1MBNwHbFryNBJW9ubvUv/IRxZ
GyJ+c3+Br2KKAQTMsyNn3VXMlXJL6kt0pwwk2od3j/+dKE4pAetHvZ5OgIO+qUWd
6R0/AaoW5jk343TaQ5BHaSpNW+OM9Yc1ycZyqE/YV8JwWeA6G/QdmRVYeoLMCZQ=
=zJeO
-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

[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

[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] Reusable payment codes

[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] questions about bitcoin-XT code fork & non-consensus hard-fork

[odinn]

pen, or it happens after quite a long period of people knowing
> it's going to happen - for example because their full node is
> printing "You need to upgrade" messages due to seeing the larger
> block version, or because they read the news, or because they heard
> about it via some other mechanisms.
> 
> Let me flip the question around. Do you have a contingency plan if 
> Bitcoin runs out of capacity and significant user disruption occurs
> that results in exodus, followed by fall in BTC price? The only one
> I've seen is "we can perform an emergency hard fork in a few
> weeks"!
> 
> 
> 
> As you can probably tell I think a unilateral fork without
> wide-scale consensus from the technical and business communities is
> a deeply inadvisable.
> 
> 
> Gavin and I have been polling many key players in the ecosystem.
> The consensus you seek does exist. All wallet developers (except
> Lawrence), all the major exchanges, all the major payment
> processors and many of the major mining pools want to see the limit
> lifted (I haven't been talking to pools, Gavin has).
> 
> This notion that the change has no consensus is based on you
> polling the people directly around you and people who like to spend
> all day on this mailing list. It's not an accurate reflection of
> the wider Bitcoin community and that is one of the leading reasons
> there is going to be a fork. A small number of people have been
> flatly ignoring LOTS of highly technical and passionate developers
> who have written vast amounts of code, built up the Bitcoin user
> base, designed hardware and software, and yes built companies.
> 
> How do you think that makes Bitcoin Core look to the rest of the
> Bitcoin world? How much confidence does that give people?
> 
> 
> 
> Of the overall process, I think you can agree we should not be
> making technical decisions with this level of complexity and
> consensus risk with financial implications of this magnitude under
> duress of haste?
> 
> 
> This debate will never end until a fork makes it irrelevant. There
> is no process for ending it, despite me begging Wladimir to make
> one.
> 
> And there is no haste. We have been debating the block size limit
> for _years_. We have known it must be lifted for _years_. I kicked
> off this current round of debates after realising that Wladimir's
> release timeline wouldn't allow a block size limit to be released
> before the end of the year. The reason we're talking about it now
> and not next year is exactly to ensure there is plenty of time.
> 
> 
> 
> 
> I can sincerely assure you everyone does want to scale bitcoin and 
> shares your long term objective on that
> 
> 
> I really wish you were right, and I definitely feel you are one of
> the more reasonable ones Adam. But the overwhelming impression I
> get from a few others here is that no, they don't want to scale
> Bitcoin. They already decided it's a technological dead end. They
> want to kick end users out in order to "incentivise" (force) the
> creation of some other alternative, claiming that it's still
> Bitcoin whilst ignoring basic details ... like the fact that no
> existing wallets or services would work.
> 
> Scaling Bitcoin can only be achieved by letting it grow, and
> letting people tackle each bottleneck as it arises at the right
> times. Not by convincing ourselves that success is failure.
> 
> 
> 
> --
- 
>
> 
> 
> 
> ___ 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

iQEcBAEBAgAGBQJVf1e3AAoJEGxwq/inSG8C7NwIAIah+HzWKB+aydCgarJB1Tuv
4wK6ffaWP3pzT/D1jNPMoMwL6bp+hi/ixyrV2y9a841Oc/9vgf75ws1l8QH2YtEE
TM5cLnRtScXnbaHKAAQZyewURbmGKTUxhNLMIRlVMMq2uHwbUEqRrDaaBGhwC1HO
+v3u5zK13H1UMKBuUY7yANWvOamjs17FmwZ6MURYdX8qBFVqMoTorhPHTebDGusS
NxDm4uqphW7ylXISOm53v7i3/CPjW63YGB2fyk9J+BqxhOM7yAJSH0Ln/xtu/COa
uXudO+SbMco+x+cKrFLf/5ItxR65aOnWvWPKw0o55f96uSabngs/QozDhaU2BJk=
=gof9
-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

[odinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

What about Gittorrent?

http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decen
tralized-github/

On 06/14/2015 08:19 PM, Warren Togami Jr. wrote:
> On Sun, Jun 14, 2015 at 5:15 AM, Jeff Garzik  <mailto:jgar...@bitpay.com>> wrote:
> 
> * ACK on moving away from SourceForge mailing lists - though only 
> once a community-welcomed replacement is up and running
> 
> * ACK on using LF as a mailing infrastructure provider
> 
> * Research secure mailing list models, for bitcoin-security.  The 
> list is not ultra high security - we all use PGP for that - but it 
> would perhaps be nice to find some spiffy cryptosystem where
> mailing list participants individually hold keys & therefore
> access.
> 
> 
> While I agree this is a good idea, this should not be a
> precondition for moving the public bitcoin-dev list.  The security
> team needs to separately research/write tools needed for this.
> 
>  warren, wanna just go ahead and create
> bitcoin-development @ LF?
> 
> 
> *More Feedback?*  As for going ahead, perhaps we should wait to
> hear from more of the other technical leaders?
> 
> *_More Questions_*
> 
> *List Name?*  Would people prefer "bitcoin-development" for he new
> list name instead of a shorter name like "bitcoin-dev"?  I
> personally like the shorter name, but either is fine. 
> https://lists.linuxfoundation.org/mailman/listinfo currently has 
> "sidechains-dev", and "lightning-dev" is moving there sometime
> soon.
> 
> *Proposed Cut-Off Date?*  Then we also need to agree on a date to
> cut off the old list.  Their sysadmin said we could have the new
> list auto-post from the old list for a short while.  I wonder how
> well that works ... if that will result in double posting if people
> write to the new and CC the old list.  Needs a little research how
> well it would behave to have both lists operating during a
> transition period.  I think we should announce a cut-off date when
> posts to the old list is shut off, July 15th, one month from now.
> Thoughts?
> 
> *Moderators?*  Mailman on the new server allows having separate
> logins for admins and moderators.  I think the admins of the old SF
> project are gavin, jgarzik and sipa... they are kind of busy.
> Perhaps we should identify known trusted community members who can
> help with moderation. Usually this is dealing with "held" messages
> that are flagged by the spam filter
> 
> 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

iQEcBAEBAgAGBQJVfpcfAAoJEGxwq/inSG8CEdsH+weboFo8SCbwgoe68oZLl6Et
r4JtzZRu8jtw5x6AYcpVMBvUo3CHtbYCWREidBhvSU+TlOUjnxZRU5CjLpjHcc61
QV2hIGD1RUdrcj93PBsnNrvuXkLVHd09sKXCIvldY1d1GqTqy9sVY1skExd7zY2h
LmJhLdmNw7I+gLP/r8Ivl7aDqrpzHXr7pnbFXZZ0hxhthncxXTefi/IV+kAt3ptL
qfSRYGPyyUXWLfXF/XW+/DH+scZm+Iu/SSoSa6xnEo4MgY4HzZM2Uy+9Te9aO6wd
xvdpMetZV5A9Ljr8Ww72DPDkvUprk7u55OMgZZ4Fps53PnqwpNOjt3phIUH4iVE=
=6Fxw
-END PGP SIGNATURE-

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

Re: [Bitcoin-development] User vote in blocksize through fees

[odinn]

t;> we’re going to seriously consider this we should look at the
> problem much
>>>> more generally. Using false choices doesn’t really help, 
>>>> though ;)
>>>> 
>>>> - Eric Lombrozo
>>>> 
>>>> 
>>>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik 
>>>>  <mailto:jgar...@bitpay.com>> wrote:
>>>> 
>>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo
> mailto:elombr...@gmail.com>>
>>>> wrote:
>>>> 
>>>>> 2) BIP100 has direct economic consequences…and
>>>>> particularly for
> miners.
>>>>> It lends itself to much greater corruptibility.
>>>>> 
>>>>> 
>>>> What is the alternative?  Have a Chief Scientist or 
>>>> Technical
> Advisory
>>>> Board choose what is a proper fee, what is a proper level of
>>>>  decentralization, a proper growth factor?
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
> --
- 
>
>
> 
>> 
>>> 
>>> 
>>> ___ 
>>> Bitcoin-development mailing list 
>>> Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>>>
>>> 
>> 
>> 
>> 
> ------
- 
>
>
> 
___
>> Bitcoin-development mailing list 
>> Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> --
- 
>
>
> 
___
> Bitcoin-development mailing list 
> Bitcoin-development@lists.sourceforge.net 
> <mailto: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/
> 
> 
> --
- 
>
>
> 
> 
> 
> ___
> 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

iQEcBAEBAgAGBQJVfflFAAoJEGxwq/inSG8CrWoIAJOsZHTWqdILE0IYmmE50E/S
BcbPJJtjodw1liPVJEybyNUKSgq4Ucw9tuQpMVv3hF8bvug6/6HtxAQCptuIKRSw
WigZyvgm79u474YsPULG+2SltMrOFqmA05jTF9vWo0LBSY4xiMXjT4VwVt9xEcFc
qHW5OUa1QoFZkaOf/jtY+H3a9w8cHZFlroTkf4MaJkaMo81oSRfWz3Mj8wOz6f8z
MSEpvQERzETEcV0SqTBnzsoX8toO1s24a9HejMMfbeD7JAy8EvayFb3G1LNzBNVC
1x/yeLBGnE3Z0P80J0oUR5taLbGJl9+7Hb16rEzxivtZF5FWBdDmvwKBOKJ1Alo=
=ubcH
-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

[odinn]

 the point here is
> they are a stable non-profit entity who will competently maintain
> and improve things like their Mailman deployment (a huge
> improvement over the stagnant Sourceforge).  It seems that LF would
> be competent, neutral place to host dev lists for the long-term.
> 
> 
> To be clear, this proposal is only about hosting the discussion
> list. The LF would have no control over the Bitcoin Project, 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_item&px=MTc4Mzg>or 
> 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] User vote in blocksize through fees

[odinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I agree that changes of anything more than trivial are difficult, but
I would disagree that they can't be made.  It seems that the issue is
one of roadblocks and muddling through when a major issue (e.g. the
proposal of a hardfork / XT) is confronting the community and the
question of how to address this issue in a timely manner. That does
not mean that there isn't a process for the community to weigh in or
for the decisions of the participants in the network to be measured
because, of course, there is, but I submit that the larger issues are
having to do with concerns over the problems inherent in the totally
unnecessary XT proposal itself.

My own thoughts on that proposal are written up at
http://www.twitlonger.com/show/n_1smkanp

And have been supported somewhat by various others in the community,
such as GreenAddress (which is opposed at this time to increasing the
blocksize limit as per Gavin's proposal) and Adam Back:
https://twitter.com/adam3us/status/608920099609817088

I think Jeff Garzik had some good thoughts specifically regarding this
subject of user vote in blocksize through fees.  Although I do agree
with you, Aaron, that the "changes more than trivial" are a tough nut
to crack, I won't say that they can't be made in such processes and I
am curious to see how this discussion progresses.

- -O





On 06/13/2015 10:46 PM, Aaron Voisine wrote:
> Yes, it does bother (some) people to see the consensus based
> system because of the difficulties that can be associated with
> implementing it.  But that's the way it is.  If you don't like
> consensus based systems (or decentralized, distributed systems)
> this is probably the wrong space for you.
> 
> 
> If consensus must be reached to make any changes, that just means
> that changes of anything more than trivial consequence simply can't
> be made. Extreme bias toward the status-quo will only work if
> external factors affecting the network also remain static.
> 
> Aaron Voisine co-founder and CEO breadwallet.com
> <http://breadwallet.com/>

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

iQEcBAEBAgAGBQJVffRMAAoJEGxwq/inSG8CGfIH/RkMNeJpcXdG+pC6Cg1XMELQ
wa/fkdKnnkhhxNm4keHeO0YQFw0BL4rQSQ2PfGEXU3keJrWlmxchEQteAGDzL55Y
1dSkQbfxsaEco2m6P0/1+WGuNOn2Sp653+/G/WoeaqMvp+b2ORbVZoqURv7Iz240
sI6GqWxWxuGpJyaW/PwVYfvGAImeQRKgKiB3w001Q3Lc36wDr/EGs4lVWJTSk+g+
60zj4+7jmqpr/Q/+sjQDE0KZSBU/EmrPYEuEdBkOmG4JnFgBqM7civtHis/zu7Uc
1sr/LcqeGm0VB/yt0CfvtsAC5KZyMFQABF0/Q2qX0GtuLbjyKWf7B/KEAPdC+m0=
=3cf3
-END PGP SIGNATURE-

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

Re: [Bitcoin-development] User vote in blocksize through fees

[odinn]

t; 
> 
> 
> 
> 
> --
- 
>
>
> 
> 
> 
> ___
> 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

iQEcBAEBAgAGBQJVfQL0AAoJEGxwq/inSG8CRqMH/0l9tHGA8figVGnIBoMgdpVi
uwMGTQTjLUf12/NFS27vT+OLMWqZRvVXvlxDF25N7la+QImhh67LqmQy8fkwGg5T
kJ6MkkFLgy05aqE/X3ywJUifOKmS3Y/RDDUJhrFjjHrsMGoF4ATtVwTpUBLik+kX
G3XRNlInmyB55UEcpyfBg9kfLz8xiy6sBPeaeGnFLCNWTs5TgJ6DTFqhBAAmE8Hw
k0tN6mW3wYS610FFkS2E3+W8O8KGs4oqAYLX/ZQOhX9oKjBvWWI4ppRpSDyBNcxd
A6VAKyU8HCuDHAEwba6gdlUa+yf4qxuZV1KCNENbvtN1CTsJ6oh0OxnEO6dtogo=
=KZmG
-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

[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

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

[odinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Shizzle's opinion, it would seem, is highly important.  I'm done here.

Thy Shizzle:
> Oh so you're talking about the criminality of one single entity? So
> having a quick look, it seems that the issue is they are collecting
> IPs and that kind of thing as well? So similar to what
> http://getaddr.bitnodes.io is doing but without the funding from
> the bitcoin foundation? If you are worried about your IP getting
> out you're behind a VPN. They can only collect the information made
> available to them. Botnets etc are completely different because you
> are forcing control over something you have no right to do. If
> companies want to sit there and collect publicly available
> information that you are voluntarily making available to them, why
> do you care? I can't see how it could be at all criminal.
> Remembering that most privacy laws relate to information that YOU
> PROVIDE to an entity during an agreement for service, payment, etc.
> You are providing this information publicly and they are collecting
> it from the public domain, not you giving it to them in an
> agreement, therefore the usual provisions of privacy etc don't
> apply. If you connect to their scraper node, of course they can log
> that. How could it possibly be criminal? 
>  From:
> odinn<mailto:odinn.cyberguerri...@riseup.net> Sent: ‎23/‎03/‎2015
> 4:50 PM To: Thy Shizzle<mailto:thyshiz...@outlook.com> Cc:
> bitcoin-development@lists.sourceforge.net<mailto:bitcoin-development@lists.sourceforge.net>
>
> 
Subject: Re: [Bitcoin-development] Criminal complaints against "network
disruption as a service" startups
> 
> 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 get

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

[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"
>  Sent: ‎23/‎03/‎2015 1:48 PM To:
> "bitcoin-development@lists.sourceforge.net"
>  Subject: Re:
> [Bitcoin-development] Criminal complaints against "net

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

[odinn]

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

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] Why Bitcoin is and isn't like the Internet

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

--

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

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

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

[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

[odinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

bleep bloop

Peter Todd:
> On Fri, Dec 12, 2014 at 01:41:34PM +0000, 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=164703151&iu=/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

[odinn]

rice in fees. On the other hand this is
> true of *all* uses of the blockchain, which collectively share the
> limited transaction capacity. For instance Satoshidice and similar
> sites have been widely condemned for doing conventional
> transactions on Bitcoin when they could have potentially used
> off-chain transactions.
> 
> It's unknown what the effect on the Bitcoin price will actually be.
> Some proof-of-publication uses have nothing to do with money at all
> - e.g. certificate transparency. Others are only indirectly
> related, such as securing financial audit logs such as
> merkle-sum-trees of total Bitcoins held by exchanges. Others in
> effect add new features to Bitcoin, such as how colored coins
> allows the trade of assets on the blockchain, or how Zerocash makes
> Bitcoin transactions anonymous. The sum total of all these effects
> on the Bitcoin price is difficult to predict.
> 
> The authors belief is that even if proof-of-publication is a 
> net-negative to Bitcoin as it is significantly more secure than
> the alternatives and can't be effectively censored people will use
> it regardless of effects to discourage them through social
> pressure. Thus Bitcoin must make technical improvements to
> scalability that negate these potentially harmful effects.
> 
> 
> Proof-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=164703151&iu=/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=164703151&iu=/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

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






Wladimir:
> On Thu, Nov 27, 2014 at 5:27 PM, Mem Wallet
>  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=157005751&iu=/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=157005751&iu=/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

[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
> > 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=157005751&iu=/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=157005751&iu=/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=157005751&iu=/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

[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?)

[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

[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
>  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] Bitcoin Core 0.10 release schedule

[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] BIP process

[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

[Odinn Cyberguerrilla]

> On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik  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] Anyone still using SOCKS4?

[Odinn Cyberguerrilla]

> On Mon, Jul 7, 2014 at 8:34 AM, Odinn Cyberguerrilla
>  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

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

[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  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] ASIC-proof mining

[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

[Bitcoin-development] CoinJoin bounty fund question

[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

Re: [Bitcoin-development] Incentivizing the running of full nodes

[Odinn Cyberguerrilla]

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/16/2014 07:00 PM, Justus Ranvier wrote:
>> There can be multiple independent transport networks for Bitcoin.
>>
>> There already is: ipv4, ipv6, Tor, and native_i2p (out of tree
>> patch).
>>
>> As long as multihomed hosts that act as bridges then information
>> will propagate across all of them. -- Justus Ranvier
>> - sent with R2Mail2
>>
>> - Original Message - From: Matt Whitlock
>> 
>>> Now another concern: won't this proposal increase the likelihood
>>> of a network split? The free-market capitalist nodes will want to
>>> charge their peers and will kick and ban peers that don't pay up
>>> (and will pay their peers to avoid being kicked and banned
>>> themselves), whereas the socialist nodes will want all of their
>>> peers to feed them transactions out of the goodness of their
>>> hearts and will thus necessarily be relegated to connecting only
>>> to other altrustic peers. Thus, the network will comprise two
>>> incompatible ideological camps, whose nodes won't interconnect.


If the technical development emanating from the proposal follows a design
which ensures that the notion of whether or not someone were to donate
remains voluntary in nature (there's never any requirement that someone
donate to anyone, but incentives can be made), then I don't feel that
network split would be an issue, because it's just an issue of choice.
Justus Ranvier suggested a system which would naturally include
pay-to-play networks, and not just free P2P networks.  The question of how
to limit the number of entries the system registers in the framework of
the proposed 'decentralizing lottery' would be fairly straightforward,
there could one entry for a distinct period of time (say 30 days as an
example) for anyone who meets the suggested criteria of:
 "those running full nodes (Bitcoin Core (...)), processing their
  change and txouts through Core, would be provided incentives in the form
  of a 'decentralizing lottery' such that all participants who are running
  nodes and donating no matter how infrequently (and no matter who they
  donate to) will be entered in the 'decentralizing lottery,'" for a
  chance to receive "the 'award amounts'"

In my mind I imagine that the smart property qualities of Bitcoin may
eventually enable people to represent what sort of time and energy they
are putting into maintaining the network, so that rather solely a currency
aspect, people who have done something collaborative with each other to
help advance or develop Bitcoin would be able to show in their donations
field that they have a smart property, which could be also expressed in
equivalence terms as a value of a certain amount of btc, would also be
able to have the smart property representing their voluntary efforts
represented and given a voice in the blockchain, whether or not they want
to participate in such a 'decentralizing lottery.'  In point of fact, I
contemplate that all aspects of this, at least ideally (to me) should be
voluntary, such that if a person is donating through this system, that is
voluntary, if they wish to have their donations result in a chance at
winning the 'decentralizing lottery,' that is voluntary / an option, and
if they win, they would have the option to accept the winnings or return
them (the bitcoin 'award amount') back to the network.

>
> Also consider that currently there are many people have already
> demonstrated a willingness to donate bandwidth and resources to the
> public by running nodes, so those people aren't going to disappear.
>

Those who are already dedicated to running nodes will likely (mostly)
remain, but any ideas reaching technical development and reality as a
result of this concept would be intended to help grow that base by
bringing in persons who might not otherwise be as interested to do so.

> They could operate mixed-mode nodes, with a fraction of the allowed
> incoming connections reserved for free peer, with free connections
> might be limited in terms of time duration. Bitcoin-accepting
> brick-and-mortars would probably allow free access to anyone connected
> to their internal wifi to facilitate people wanting to pay.


That's a great idea.  The incentives could certainly go beyond just
pointing to Bitcoin Core.  Giving is important to everyone.

>
> Crowdfunded free bridges, assurance contracts, etc are all other ways
> to let people get into the network with no upfront cost.
>
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQEcBAEBAgAGBQJTn1mwAAoJEMP3uyY4RQ21ePwIALpMV/GDpAyD4SeL6hWi32vQ
> 197YD1LPuLWrEbUs/+gl1Sk2gIsWWlq/o86KcP7Cn4fZdBAKEiF5RpQ6iPsO2+bj
> JR0W/EbgUyzIhYaxFysCzQ1HPzQx+0a2vHn/6FsB7YMha8gvxviF7InDEwcfxbok
> o0QS5SeYWryp5mH7IokC6fLYsAPmiueugPVRSD/l8IRFYWVFS9nB+XAR1PWAdYSQ
> Xyzu9oyPwlKAjYKxl4XHYB4DofacS89DpW

[Bitcoin-development] Incentivizing the running of full nodes

[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

[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] Bug in key.cpp

[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 (rec<0 || 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:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • 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:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• 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] BIP70 proposed changes

[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
>  wrote:
>> On 02/18/2014 08:14 PM, Ryan X. Charles wrote:
>>> BitPay is working on a new standard
>>> based on bitcoin-like addresses for authentication. It would be great
>>> if
>>> we could work with the community to establish a complete, decentralized
>>> authentication protocol.
>>
>> Sounds interesting, let us know as soon as you have anything.
>
> SINs.  See https://en.bitcoin.it/wiki/Identity_protocol_v1
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
> --
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@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:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• 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] Translators Needed for Bitcoin Core

[Odinn Cyberguerrilla]

Thanks for this reminder, I will bring this up with some others who I
think may be able to help in this area and dedicate some time.  I may be
able to free up some time with a little language work as well.

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



--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[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

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

[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  wrote:
>
>> On Tue, Mar 11, 2014 at 7:43 AM, Drak  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

[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=122218951&iu=/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=122218951&iu=/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)

[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:
>   + 
> ...and another with:
>   + 
>
> 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:
>   + 
> ...or
>   + 
>
> 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 
> before he has to produce , I'm wondering if there's something Bob
> could do with  to intentionally weaken the resulting ( +
> ) so that he could sign a transaction with it without
> needing to know .
>
> 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=122218951&iu=/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=122218951&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Procedure for non-tech contributions

[Odinn Cyberguerrilla]

Hi, you may want to check this out:

http://www.reddit.com/r/Bitcoin/comments/1rh2h0/developers_core_developers_contributors/

Cheers,

-Odinn
 http://abis.io

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

[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=126839071&iu=/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

[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=126839071&iu=/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=126839071&iu=/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)

[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=121054471&iu=/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=121054471&iu=/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

[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=121051231&iu=/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

[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=123612991&iu=/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=123612991&iu=/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

[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:
>
>> 
>>
>> 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=119420431&iu=/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

[Odinn Cyberguerrilla]

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



>   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  wrote:
>> On Friday, January 17, 2014 11:44:09 AM Wladimir wrote:
>>> On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr  wrote:
>>> > https://github.com/bitcoin/bitcoin/pulls/luke-jr
>>> >
>>> > These are pretty much all well-tested and stable for months now.
>>>
>>> #3242: Autoconf improvements needs rebase, and comment from jgarzik and
>>> me
>>> taken into account (about -enable-frontends=).
>>
>> I'll try to get this done over the weekend.
>>
>>> The others appear to be more controversial as they affect
>>> mining/consensus.
>>> I'd really like to see ACKs from more reviewers and testers there
>>> before
>>> merging.
>>
>> Can you elaborate on this? I can see how Proposals might, if buggy,
>> affect
>> consensus, but the rest shouldn't. I don't think there's anything
>> controversial in any of these (does someone disagree with CPFP?).
>>
>> Luke
>>
>> --
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[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 
> wrote:
>> "static address" seems like a reasonable attempt at describing intended
>> use/direction.
>>
>> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell 
>> wrote:
>>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
>>>  wrote:
 But may I suggest we consider changing the name "stealth address" to
 something more neutral?
>>>
>>> ACK.  Regardless of the 'political' overtones, I think stealth is a
>>> little cringe-worthy.
>>>
>>> "Private address" would be fine if not for confusion with private-keys.
>>>
>>> "Static address" is perhaps the best in my view. (also helps improve
>>> awareness that normal addresses are intended to be more
>>> one-use-ness)--
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[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 PaymentRequest>PaymentDetails is expecting 'output' containing
>> one or more TxOuts with script and amount. I believe the general
>> approach
>> is to put a fallback address into 'output' for backward compatibility,
>> and
>> put Q and Q2 into an extension field.
>>
>> So we add a new optional field to PaymentDetails which contains the one
>> or
>> two PubKeys. Not sure if we want different protobuf tags, or if the
>> difference in length of the value makes it obvious enough which approach
>> is being used;
>>
>> optional bytes stealthOnePubKey = 1000
>> optional bytes stealthTwoPubKey = 1001
>
> I think you're missing the bigger picture here, not least of which is
> that backwards compatibility is a bit of a misnomer for an unreleased
> standard. :)
>
> Why put this into the PaymentDetails? That a stea

[Bitcoin-development] Bitcoin strengthening, giving, more - Re: Stealth Addresses

[Odinn Cyberguerrilla]

Hello,

My apologies, to start with, as I am temporarily unable to reply directly
to the thread.  I am remembering this conversation due to a few things:

1) the discussion re. extending the payment protocol with new fields
2) discussions about "long addresses"
3) bitcoin strengthening / decentralization / cex.io,ghash.io growth etc.
4) microdonation / giving / microtransaction development, e.g.
coinbase-bitmonet Android SDK,
http://blog.coinbase.com/post/72785739620/android-sdk-released-accept-bitcoin-payment-in-your
5) multisignature via browser, e.g. https://coinb.in/multisig/

Different thoughts are running through my head here, so I will make a
sincere effort to coagulate them into a couple of meaningful and coherent
questions, and perhaps as time goes on, an issue or BIP.  However, I will
precede this with a "scenario" and with some "possibilities" (all of which
are hypothetical - I think) before presenting the "questions" below.

  |
  |
  V

"Scenario(s)"

Suppose that there were to exist a method of extending the payment
protocol such that either "very long addresses" or multiple addresses were
presented by default from within the bitcoin client.  In the scenario
being imagined here, the standard option would exist to enter a payment
address directly.  However, coupled with this would be an option to enable
microdonations (or put another way, multiple transactions associated with
each instance of use of the protocol to facilitate a purchase) as a
default (as background activity automatically corresponding to any given
transaction). Whether or not this process is engaged in would be entirely
voluntary, in other words, users' choice.

The addresses to which this giving or microdonation would occur would be
stipulated by the user but also would be limited to the ability of the
network to support this microdonation process.

So, for example:

1) Let us say that you are to buy a piece of gum and the price of that
piece of gum is 0.8 BTC.
1)a.  The user has the ability to support additional (individuals,
organizations, causes, etc) for each transaction (instance of use of
the protocol to facilitate a purchase).
1)b.  The user has set as a default to be "microdonated" each time a
transaction occurs, the following:
  1)b.1 0.0003 BTC to Sean's Outpost
  1)b.2 0.0004 BTC to a cousin who has a medical debt
  1)b.3 0.6 BTC to a multisignature account which is intended
to "give youth a future and old age a security"
( Re: https://www.youtube.com/watch?v=qLci5DoZqHU&feature=youtu.be&t=2m38s )
  1)b.4 0.5 BTC to a future US gov't-run Social Security address
  1)b.5 0.0002 BTC to an anarchist collective's donation address
  1)b.6 0.0002 BTC to a personal investment or retirement account
 1)c. The user then purchases a compound bow for 0.17 BTC.  The
purchase occurs the day after the gum purchase was initiated.  The
user has left the default microdonation settings in place, so Sean's
Outpost, the cousin, the multisignature account, the US gov't run
Social Security address, the anarchist collective, and the personal
investment / retirement account all receive something (automatically)
again as per the user's settings.

"Possibilities"

2) Some Possibilities (depending on implementation):
2)a. The transaction completes for the purchase of gum but the
microtransactions are not allowed to complete until the compound bow
purchase is complete due to that the gum price is lower than the
collective microdonations which are set by the user as default.
2)b. The transaction for the purchase of gum is not completed due to
the user realizing that the fee will be larger than the price of gum,
but the microdonations are completed (the user has opted to allow them
to occur anyway) and transaction(s) confirmed.  Subsequently, the
compound bow purchase occurs and the microdonations are given again.
2)c.  The transaction for the purchase of gum is completed and the
microdonations are completed, everything is confirmed, the next day
the same thing happens with the compound bow purchase, more
microdonations arrive.
2)d.  The microdonations are interpreted by the system as part of a
very long address created for the transaction.  Due to the tiny price
of the gum the microtransactions are held until another larger
purchase is completed.  The microtransactions occur "times 2" at the
time of the compound bow purchase, since they could not be completed
during the gum purchase, they are completed / confirmed at the time of
the compound bow purchase.  The user is alerted that the ordinary
microdonations will be multiplied by two for the transaction and is
offered an option to either run the default microdonation or the
micronation "times two."  The user confirms the "times two" option and
the microdonations are completed.
2)e.  The microdonations are each handled as seperate micr

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

[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=111408631&iu=/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=111408631&iu=/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?

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

[Bitcoin-development] ABIS protocol introduction

[Odinn Cyberguerrilla]

Hello,

This concept, 'ABIS protocol,' has been many years in the making and is
presented here as a basic concept.  It is sent to you for you review and
possible consideration.  There will be further additions in the near
future.  Looking forward to your reply and any contributions you may
provide.

Cheers

https://github.com/ABISprotocol/ABIS#abis



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development