[Bitcoin-development] Open Bitcoin Privacy Project Spring 2015 Report

2015-05-18 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We're produced the first in what we hope to be a long series of
reviews of Bitcoin wallet privacy features, available here:

http://www.openbitcoinprivacyproject.org/2015/05/spring-2015-wallet-privacy-rating-report/

https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/raw/master/2015-1/OBPP%20Bitcoin%20Wallet%20Privacy%20Rating%20Report%20-%20Spring%202015.pdf

Specifically from the readers of this list, we are very interested in
feedback regarding our privacy threat model and the rating criteria we
derive from it.

Threat model:
https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/2015-1/threat%20model.wiki

Please send any suggestions or corrections via a GitHub issue to the
wallet-ratings repository so that we can incorporate it into future
reports.

- -- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
jus...@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVWhBvAAoJECpf2nDq2eYj3JEP/jw/Xkgq4yZRE4FK8a8kPBqn
3ULyS74KtNyPDdpTK0bdH7//0d1ep+LvNpIkFhWCJ/WQ7T/Ft3iQl1HJvXGC0ZzM
XKd7ptXLpBrKElARAORgUlFPOeKzOrOyP4uvvGAMZ+CXEnKeyxDzK+WzfYnWyDEU
Q4XQ/ndwPqbZm9Nb+GeF186TXcA/KqcQEuOIw7/jFGHfFT6QBKVz1SraVrgdcMky
8KKYOsYJt8lTUjVN1INmLFoRZ0cGUd+IFKweSCibyAu9TdvVQfQSPfSnfZtDLk6X
g1oPYaxX6r9+/1zm2v5ISk97nKrvNslPjeQbuW3vWlROSxGZ9lV+MVNvkqm1jSpF
ip0Il+VJb8hhh9LRJV6euhLQyR+xnLIVJvslJt883rhKIBi3M/OipMuhipIeAbnV
0WQmnpQ9ZgagPoFRxGp86Cz7PWTfj7zllB3yk/M3tA8e64VQFhEnoyJO8hPqfEQh
wPZP3UQ+K3PM/2oe4W5ZkfkqD6tIzGTQeMkGFeCvTsMmsW9+Ml8j4YTwKA0z5vr5
IebJ51Vpaq1noVEl46q8utpLp1wATI8SG5sBwSaR4/REUGkSWjSCeZeLcK8WzdEa
SaZ8t5Rqr1AcwtD6n9rVvYoF26285120jM/YX8XgMldWi0RXrlWD4B4lA1i7eVfZ
hINSIR+QsJsw7yq7Ox3/
=NMNo
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Open Bitcoin Privacy Project Spring 2015 Report

2015-05-18 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Replying to the list because this is a common question.

We rated as many wallets as we could based on the amount of manpower
we had available to perform the ratings.

We will be holding a recruiting drive shortly to solicit additional
volunteers so that we can cover more wallet for the next round of ratings.


On 05/18/2015 11:40 PM, Eric Lombrozo wrote:
 mSIGNA is notably absent from the report despite having some of the
 most advanced security and privacy features and having been on the
 bitcoin.org site longer than some of the other wallets reviewed.
 
 Is there some process to get reviewed I missed? Please add us to
 the report.

- -- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
jus...@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVWmA1AAoJECpf2nDq2eYjXGgP/2CpIYpG49WKAfG/PXmu1zFV
+zzU/7PCz+0ez0mGCz5l3QMc9TCDs6KDx0sPHZngwwLio3C4JMpu+zfnw6gngw/G
6NNtmDZ9xWgWx3kQyBLWBCM/K63rLE1QYJqiIc7QaDuDTk5w0upwkFxLejWeem1j
Z8Zy6ycHNNHE19o5pIYViWaRXojMD70fBFSoU9sAyvnOup7b5Cj4PLx7mbMbaegV
gCHd7zd88AH0f2ilFiVMQJBKf03KzYjarRVrAyvAb/8VLiYMRC8SS3y2tzM+qRKl
ZADAp8FiQ6GOFRssNg+x7tc3DX2ngBljLLKM90kPLR2cvwp8VHi0I0biqM8n2M17
CMjZVRNvXitNnKFc42nk51HsZR5LkDK3Rf9I1E3fBVKJ5feEbDi3tlEg9PCWD2xM
PmSRzXoUBAjpr9xL2kBzlE4aTYZCmmMxAMF1mcSYujdNzQ2IN0gD1urJtCwZ8zZ1
LL2cPimS3GTWEpoQQ/Fu+0NDwiPditDGt+DN16Mi5uioPvaumHMIV6u9ZNdD9ZEv
UTGW8C2Hj+ENzqhpdhlV5YfYUnKo6/ukw+xxTXRxbbLGxA6iRrVnPzsYTZoF0Vrt
T4IsdzPIg5yeF5IQKEV1lLyx+gOIvmDF1RZE36NY8bGn2zusFzUGxiqWa6yw0hfw
l4ytd8pfhIvTkuz1o9aQ
=kWhU
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Block Size Increase

2015-05-09 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/09/2015 02:02 PM, Andrew wrote:
 The nice thing about 1 MB is that you can store ALL bitcoin
 transactions relevant to your lifetime (~100 years) on one 5 TB
 hard drive (1*6*24*365*100=5256000). Any regular person can run a
 full node and store this 5 TB hard drive easily at their home. With
 10 MB blocks you need a 50 TB drive just for your bitcoin
 transactions! This is not doable for most regular people due to
 space and monetary constraints. Being able to review all
 transactions relevant to your lifetime is one of the key important 
 properties of Bitcoin. How else can people audit the financial
 transactions of companies and governments that are using the
 Bitcoin blockchain? How else can we achieve this level of
 transparency that is essential to keeping corrupt
 governments/companies in check? How else can we keep track of our 
 own personal transactions without relying on others to keep track
 of them for us? As time passes, storage technology may increase,
 but so may human life expectancy. So yes, in this sense, 1 MB just
 may be the magic number.

How many individuals and companies do you propose will ever use
Bitcoin (order of magnitude estimates are fine)

Whatever number you select above, please describe approximately how
many lifetime Bitcoin transactions each individual and company will be
capable of performing with a 1 MB block size limit.

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVTgNcAAoJECpf2nDq2eYjM8AP/2kwSF+HMPR1KdaZsATL4rog
xSS97Q5iEX8StA61jUqHQmpXL5pG6z5DeeKT/liwcMnYnVqOEOLvoVctr3gXfgRz
9GJeTOlmN5l9xBeX/nWa0A2ql0kWZpYolBS1FwYadWReAD8R0X9UeBd9YXLZNy33
Ow9JjwRjKHhsuyrlMP8pRDKlGPoa/U+2aW4FwiysMLa0Gu6dbFjTrp3bHw4Fccpi
X0E/aDN68U4FV+lZ4NzkMsBK9VARzmC8KI0DQ540pqfkcnyoYf0VERl/gslPWhfq
t6Rqa7vHHMqFe82lgCd3ji8Qhsz8oBrDS4u4jqwATvgihgImOB6K85JoKmf3y2JS
jByjMGd4Ep0F80Z2MRhi6HuEoRU69uY2u6l9bZxMjzvLX8sG6QTNk3uLMS3ARXcY
JBjZ/g13DXgcRj01fq05CHbCTJYZgTA9pRZTY+ZKH4r0mu86b9ua7hjvyKHS6q54
uaFmRkNcnKlpCY+fvH/JUdvvmwrA0ETUdHhRyk8vzWIMi+aH4//GwrCmBNRrugzv
9JtQ1BC+tQqtSX2VkFEhAVISitgkBqurVVlGk18FvVKPFO8cnFS/6NWoPE0WLLzW
2pTuhEPjdz9UAHD3RW601rb4C0LbuwVlGO4tYBjyqCmk/vBlES2XIjQKctXZLBEy
eLgn3gMwEXUTU6UdGyvb
=RPhK
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 09:54 PM, Jeff Garzik wrote:
 By the time we get to fee pressure, in your scenario, our network 
 node count is tiny and highly centralized.

Again, this assertion requires proof.

Simply saying things is not the same as them being true.

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS8QWAAoJECpf2nDq2eYj+/4P/2JXxo2RDAg0ptd9aUYVvzp9
KhL33cdmK8kbKBFOVcOuIrlQRzZn9iydIPC165Y40Y6Wrtgw2PoXctuqdQdXaSZI
M3bHuM7mweHyb3xBHNaNHIxfwrMjQQAdOTGO7PZusghDYz2QEj44dhIcNOzO7uTD
fXkhzgJfwu0l0Wqn3v/R9amRUWLE5nlM566xJ2sVtlfBMEyzR5L1GwX1lKNhxeO8
qvkgegsF2Usjz9pIUMSGFxSWZQuTSjHbhbh28JaT/wi6DI3pcTV0FPw95IPImqUh
rbIqcPh43omXrHKEHV/FB+XMItD3VvR9dxogYaFZLv1EU2gnF2IM0cw5a/oyHr+L
C920uEbXrvrMEJw1ftvxQyu6NY5c3/5iVMqz773oQSjOihkZ8P1JvxQnldU6mcoU
RaKM13cxgjSkCqJ5R1iIldFQPCLLWUKJDkPEnGlwdLPF/vwhnCt1PZJTB5hqoCgC
ab5yBVLpLgo7sbizOeX/R3WGp3NjGXDQC93Af/Vr37uiu1ZT+1P1Ow86hsZTRx6b
4d25tSGg7Tw3Bs/YOhJ9AKtlN092Y8/WBMscQu6MaFt6I/1OMX9OVH+veEj/VjwB
L/dxWTRdC0HEKiYv+EuESIRoyTLlCHKBUDBgKbYSMjetg6WW64hYrpxNX7TH20o6
00bWPVV2PcEWuCc230UF
=1bK6
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 05:04 PM, Jeff Garzik wrote:
 heh - I tend to think people here want bitcoin to succeed.  My
 statement refers to picking winners and losers from within the
 existing bitcoin community  stakeholders.

Success is not a sufficiently precise term in this context.

There is a large contingent of people for whom the definition of
Bitcoin success means serving as a stable backend which can meet the
needs of their non-Bitcoin platform - and nothing more.

To be extremely specific: should Bitcoin development intenionally
limit the network's capabilities to leave room for other projects, or
should Bitcoin attempt to be the best system possible and let the
other projects try to keep up as best they can?

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS4HiAAoJECpf2nDq2eYj23wP/j4ksm2dgzDkccMRbqFM8Pm8
oV6ImxM26bG3DJB+Rh6ttTY4DrUnZJmzQUUxfZUd3TmH/xOM4Lu35gKKhpvHTdR8
vMQz76CaTba6PzzFKC+GYyHueXLtwJxEHEZjR8m5ijPMfZoImfMbduggDaPLv/sz
AUcTDtYWBoPZ9Matms4NZIOsH1S1pHw5YjcFYgxmY6ErHZPqZjoKzcc4wZnrOU+Q
HCmiHOJ1U87jEge4QEJCXidCJFakyMTWt5P6hjdOFfky3VYmcoivYRA1ZemgyV2Y
YyLtmHBcK7k67Tczep8rjggvK2C2oJArFGPLWHZH9bxXILaNXSpZX5G5rXZjp1vm
1voc6JDaK/slXIlfG+BZ56WyprKkiFbN6u4Wd8LG5W8gKiuCyLYr2IGKz9O3fvor
NYtk6ELPfX1+0JBD0ureI7kV85D/ybNnnmMp/NyfmBKzzmqnANRrrqL5zgILuUP4
YaokcVdPpTqkN0vuAXchehEemF5MtJIYf9BayZ86ck68aMjvVJi0nX3n63f1MulP
IbRbYY/8eu1891lNIPiSzbmT0zjjplo8jYEOTg32mIvEDZAy8sWwTPYS25tPd37l
3kxRCxqS1ALbAqLZprmxQ375PigE2esXZlpBHzyY4Kf+3UD/k/X8D92vdNiF7mkS
HSA+TX4lf310Eq6Mb4LR
=5vaU
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 05:47 PM, Jeff Garzik wrote:
 Bitcoin needs to be the best it can be (Layer 1), but all solutions
 cannot and should not be implemented at Layer 1.

I can provisionally agree with that statement as long as all
solutions cannot and should not be implemented at Layer 1 it taken to
be a hypothesis to be tested in the context of each proposed solution
rather than a law of nature.

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS4nOAAoJECpf2nDq2eYjZGEP/jvk+RNQO+Zoyp0jc6aup5Aa
USUFk1TYBqbu47vvc3jFHc4V3/BjiwkUKp5bZ4iIxr3xWIA35CcjfpSJEIlEj0zM
OHS2j+eS0WkNWCmWgj+3sJpQBNnqLmdBOG1q6z0aBLGwG7uabo+YAhJjlP8isfcn
cBQPGjeTW82ZZLdkNaThbFr53oTYiVPNqMIIq6orUe5vetQS/zfTyowi7Y9+OT+b
FMXOEmXQTzF415LImJNXOcGFx51YkLe3SuEPEqqIX/+gOcT4HMPuKbqyAu6xXRQK
O7uI+6AjN1mX7Cvt19wYkUggJ7ddVKrHINSzOfsZ+pdF8mdY4TrdwJJhfN0+fnvo
KYW+pmEAFRMveV8SVGJpHQ/pWECKbFiz1SRnDfjlbX/C5mHiHM4EmqCxC1pVDxOU
uDukt+ZIIiP7GwPYxqSknR4lcuwsdFFJf9ldxD+ZRNsmz1l+PkaUUpdkCc9u9rUW
2IyfvPmeeVUPLP9N675kfiM3aKNO7LHN8GhSUe+1Nt/zcXg6xg0QWKdXjC8nykCa
eH9gn0QoQZaZbfKnb8DLwLjCO5LiOzQTgqdo0ZSJtV/CipqyGcBJtFYW2olG/BvO
Ns6qJKG6Ck76Tv31cu3YGpVbBjCxsIovchLh72KjQ9LscYg8y29evcFlnyagsewY
5CQJsAY8apmvNvmxAhRf
=oRV/
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 03:35 PM, Jeff Garzik wrote:
 Raising the block size limit then becomes a *human decision* to
 favor some users over others, a *human decision* to prevent an
 active and competitive free fee market developing at 1MB, a *human
 decision* to keep transaction fees low to incentivize bitcoin
 adoption, a *human decision* to value adoption over
 decentralization.

At the moment none of the following assertions have been proven true,
yet are constantly cited as if they have been:

* A competitive fee market will develop when the transaction rate
becomes constrained by the block size limit
* More users of Bitcoin means less decentralization

Furthermore, the term decentralization is frequently used without
being precisely defined in a way that would allow for such proofs to
be debated.

If there's going to be a debate on those points, then the people
presenting points on both sides should take the time to show their
work and explain the methodology they used to reach their conclusions.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVS5BXAAoJECpf2nDq2eYjC3kQAKQ0Jj8r1gjwpl813NiuatjA
nwXJ+Zn7E+cS8bYsXbaPK1uUgcSdpi/g2jgW+VuUPlqCaNo08Pbp/O7pG5ady9st
o7xJnPxttg7NO3IB7GODCJKK85uBO3dOwPp+pfs8KYCAo5PFTflpeOi4Idbd4w/R
+tvLynpSX9LIZTQaJH2KEbrYUibYHZrr8hj0net9lJP8KeqMnCuiesYzjJ4pUXyE
zN0SQ1v9QnpltbTVxRu1TdRBMjAxEHTJPg1jsv0hhGqIOQGHdwNavGq7+LJBen4T
CvT8ooTmuq0IdihOTttl9ody6Eh0tyGPlbVHiI3c2Emm0HTxz8hN9Rl4lvPgcGdi
EUW12h8ailKLg5uJL53Zp1PO6fgl0Z/WCx/zqIKRPg4lJMf5Rk5Ow86xAeIZrsbr
d/+cJZEhqzPnObxkxgTIzqtG8NHcg9dhKw1xkGAkVpMXMM7Bzdku8WCntIYU4+xI
btQQZlbc5h/S+X9Vcu0rJWmmQp2Q8xeEVGRh4hhA8LZLc1P+1eyESjAMWvsuq+rk
Wd1kPopekhOgK0zw2j55Ov+kJXVa2pDFA7TOpcqxbdLU4eauKC4D+YQlTM4qj285
vyRq+c/AwMCPiEhBeEbppgdgwrIQP9fJ7s+2TAHaWICYlTJWkLitUjN9EBwqv3Yp
LRBrgV7giz8UIrJr3hQZ
=+Qmg
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 04:04 PM, Jeff Garzik wrote:
 - This is a major change to the economics of a $3.2B system.  This
 change picks winners and losers.  There is attendant moral hazard.

This is exactly true.

There are a number of projects which aren't Bitcoin that benefit from
filling in the gap left by Bitcoin's restricted transaction rate
capability.

If Bitcoin fills that gap, Bitcoin wins and those other projects lose.

Should decisions about Bitcoin development take into account the
desires of competing projects?

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS3jeAAoJECpf2nDq2eYj3hMP/0yk8HxypEfNa4vZo0IcKD+p
bn2dftQsOEeOenBh8QT48vS3AhcjNkUsw722YwbKz6Znkyi2iU7njaUM9DV+QHwg
Oytmh8XVZtviLgg3854ujdj4oAWyP4DpppVTRxTDyRdSpRj+D9y6+sGFls6z0q3/
XRcKOY23zx6/qN1k5fqUncpIpYEDhpmE7cGy26Yz0G4MtuYeceHT4LdJAHHr0iFL
OY0WVM32b4F3HfkfJtt8rE0yeB7u5dbeu8KmLB0yqZQkY87sLxtT6qeoyHO6CG+N
8Iu9OWaRIZHfrZK2XlDzDKQIkTnlSxFtj4wY7/Yb4NIDO6mhMjYTSz8lWqN4ofKg
9fFHlwGS3QXXDTB+5d1IzZS5C0qF92n1NJiJjkLqhKqYuVn4U74oslZhVLxHBGHH
ZAvW09obZXi5DVzhuxPzlFkpYaB+XLdmBUPEr5hx5K4I2qiL/Nvu0h031UDcMeLm
x9mEHO5ZODlF9tWAVnM/b0VtwT9h6Q88NWe/OUQQZKp6D/Etcd3JE55GBNtNPDnE
2UubyHkNO4mbrEMluh24TvhZK3BB/lieq+kkHZCP7eC58eRY078lSF8R36XGdbn4
Pili15bYSrRrfmjDz24zhJX8759LPt2Zsf/Irc8Za4SoaEaYAqQU4vAmYlZyCNxj
EvxXAasffnjR2K3cnZxr
=YkTz
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 04:49 PM, Peter Todd wrote:
 
 I think we'll find an basic assumption of civility to be more 
 productive, until proven otherwise. (e.g. NSA ties)

I'm not sure why you'd construe my post as having anything to do with
accusations like NSA ties.

By non-Bitcoin projects I mean any altcoin or off-chain processing
solution.

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS4EeAAoJECpf2nDq2eYj/vcQAIUrD+ejUKHQb0k/pcPyzmvy
rl3spbbdLSFN9cBhBOgh5LaVFkCrv4/gW2X4Ih6GGYG3siXjZ2HPDXt+Zbs+bfQE
nrw+IpGTYlbnJ26cFVhZWehr45qY1kMO+DVdnKufEgfVKUdYeq/d3bwL1uru4RU6
UfWihvgGGQkjEb/5ZIpRbWmb7XRP9piZCHi0pgFSa8tNDVjbb9ucKjIfrRuRe+DK
GMhIAQLvIQK4M30SxOnMQLIe3upsQ6JzY+5M28HkcBNKgd0dpZbwByHIJh6/ELTO
Iaf08S0mCySKoZAJFEkeQ3YOgdIlZvwYsflxiEs62Mz9Mz8uuxTo6E21XyFr6iN/
XndXCzlAZBIQuiayEUL4fUM2cmeHcvhHpGNyYjBuLibuiaIzKMBzFQqEZHGA0QzH
QhptbHjTwXLxIEZy94ELH2FbQnTrnOBxOdYfmxGvlmJ0328hThW6N181L3fPHK0v
6zTChZziMhlIoZPX8AGNNsUYJFKBJs/khlbse/tQhXmm5zuIyq+Lt0nKjbhHkWJw
n9y4PHxLVtmmOvptPMm00l5/w6yb8Qmxo81d6kq75ZEupjxupHH6YwjHWTehT/x2
Pt8iMX2NWVnVwVdsaqE/rH+JrgH1Pvl7TMqXMr8d7tuSWTeTBWlrcmZbS1rl0Z3T
f8K2rBX6sBqmrD1xKDsn
=5pB6
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 03:27 PM, Jeff Garzik wrote:
 On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier
 justusranv...@riseup.net wrote:
 
 To be extremely specific: should Bitcoin development
 intenionally limit the network's capabilities to leave room for
 other projects, or should Bitcoin attempt to be the best system
 possible and let the other projects try to keep up as best they
 can?
 
 
 
 Avoid such narrow, binary thinking.

On 05/07/2015 03:25 PM, Peter Todd wrote:
 Altcoins and non-Bitcoin-blockchain tx systems? Assuming anything 
 other than honest intent isn't productive in this forum.
 


In summary, I asked a question neither you, nor Peter Todd, want to
answer and want to actively discourage people from even asking at all.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVS4XZAAoJECpf2nDq2eYjwZcP/j4ypIBctC4Wt71KJCx4eJ3u
u8DQAJKKr8BfL/zDu5bwVz0qbIX1+Wv9EwkBSYuYQaLDozDCnlttptr7qNWm62QI
d5Z6HUU+g/Zbk2DSgVK57Hf3G7pzcodRq+fp6O/kNgtdE9OyZnv9giApd6F1Yy7l
wgZxjlpKGMA+qKigHSHIQyu1L2JfWjw7eEiirnDtFaCgTpJqPErigX+2eMdpj8/r
jTP3mEN2qStWYydWfYxfcM68gOZsvFiVBfT7qTkFXSeOdigC4bHMDMew9nqP1hlB
9uo/JESNQ4Z0/WHgDSn9fLbc/UX6SIPVn7vDAj7mZAeyaXYBrXhbHpdqhnOGhDmt
R9aUopGHleY44RujES1rQWSo6D8SWlbmpXThgHU5rlRFKKSCu9/s99s7kVdLFqpS
bGg42qs1LwxDiq2TuMV/9TuP10ibB4mSnKwaglcAHcrbo26ZdMF4T9YwKcEmHIrv
0hCUA0qyvKP3fqfQUVzcssJfWdvjx7/bnwLadrxSOur1IZj+2jJdzPYsT1tSiwL/
XChSN5a00LJWW5+b0ka155sEg8XcBdUECXIQtRpFedCURjeinGuMnEf6gM8NbcNS
yVm5Kptf8BO11r154J93nkc3gU4VFcxudg8smaDcq3amPDkyaNBXQm+rcwIApchL
SOzHWwxtA1q+pLHvxnlk
=Fcdg
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 03:49 AM, Peter Todd wrote:
 I'm not sure if you've seen this, but a good paper on this topic
 was published recently: The Economics of Bitcoin Transaction
 Fees

..for some very strange definitions of good.

That paper may present valid game theory, yet game theory has a
well-known limitation when it comes to predicting real world behavior
in that the predictions are only as good as the simplified model those
predictions are based on is accurate.

At the very least, we should wait to draw any conclusions from that
paper until it has been sanity checked by a praxeological review.
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVStYTAAoJECpf2nDq2eYjqzAQAJkLwVq3cJxaP5MirS6j+SkN
NuRIQS8EzJkvojZvHCSRz3xPZpl9Cx2T6/hsLjIfzvMuDHKsaOkkLlL0q95ekv4T
acfami64326DFAxiO0ptspPjCRipagmjSEwZGZwC/QZtTdnt+N9LsH0SFDP6hxbY
Kf11LRd11Ap4v/VnBg/zb4daZnVm0k0nfZxK4rG1zN14r5JEu6eiodUBZc6e4qih
LmopoddIwJS4MY1GoR2kCehAbJseZZyQQmHFEX1Vhc74ETGXWApfgF0tpo6ZMutd
OT0WGhCpj4yG1u5bRaiNnsOy9WcBTKzDOLZUVVh/GhUGHWUulZu8ujYrX7Q6GR5S
VPvOOL6Ts/RGEAE1UWKzHfPjrLZAHKgLAzBjm6o1ZXdBcnV+FsThNvd7fxHvaJsO
pWGSu8qDmN/wH657Tphbthb4T/awnuf4rO6oBP+OGu+ydPIlIlt6rM2E4Bq366yy
CJbzSR3x/P7fRmT2bbSg4rxTDyLFJpNIWOcNaMRBeO69OdNZxlranvFvEl/6FfqK
GO/LPQiYCe/+yhXgUJzzlYpayPiPFWCg0FxwQ+xl1josTsrfPE4BUivkZvIlqOIY
LX1fDHt/IIUNp8OUkY2eERxeB//dlY55nP7VGUEJLNnBkXuoBd70lMtGXxtgvw2M
Wy5VER9CiEOUMMwzWi3Q
=8mit
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Reusable payment codes

2015-04-29 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/27/2015 02:53 PM, Brian Deery wrote:

 1. There will be a 1:1 relationship between a payment code owner
 and their identity.  Presumably the payment code would be strongly
 and publicly tied to the identity.  This makes the notification
 address strongly tied to the user.  An SPV client connecting to a
 full node who has a list of notification address can tie an
 identity to a bloom filter and connecting IP.

I've updated the proposal to provide for alternate methods of
notification that can be used *in addition to* notification transactions.

This frees the sender from constantly monitoring an address known to
be associated with their identity, although they should check it
periodically since not all senders will be capable of using every type
of alternate notification method.

I defined a Bitmessage notification method as an example; more can be
added if required.

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVQWzPAAoJECpf2nDq2eYj8uAP/RsP050K9z8oDGy0KO+zjFwM
iNzlsQaPY8kmR2k2oLXJp1n4QZIQAZly+vxjBZnOWXwAhrBcvnhNBvqdigwZYg3B
oGyvGvArzkve86Ke1WF1hZEAvml3cmQ5jxYKMlwhzRPcHq2kwznw+5jRuTbf1JbE
PxY5pOfnZ9ADVF5FkLR2KwBNvGA83Cle01hKd0eB6Omlb6azKDBXUqfzPPpB4lmp
A8D0P3zkayzBYIiybUExfPJHUthd5wXL/TLwFkysPV7SnJE64C6Q2StD4wUtNQRS
LDOw37RwhMx2Oz2YH3Ywi6w5tqYQP4LEWBuFb+LOqqphpV/FpFDl/Uznos00pz61
V9x2wrfg+MQnYk5/VIjPQxqvRsiu8yg4c2x0v+KIIMsuXKEPRFxaSS3DoaWUa1Jy
+WDobHndIDw1TDqctP8LIiZ7zbWNYKJ4HgUaacHvTiA7TrJXi1KHo2b1pmnTbKhv
fdHbjzd8UiMED6qeyrz1gGhjC2uSTwjZAmbBkCJccOGsrILoV1fifUW+de8qsBMH
6w6RiDwfeY2fHJHBS6O2Nhfk3OE5JaCWvy727ZXEq8lQ6dW0GOZvXg7INaktLagC
tqvg85J5eCm7X8xQ33vgx8q2xt+IriMI2UnTILtb2H8XSiMRQSP7XfWDMfVGu4pb
xbGZKbNS4WS+2FFKM4DK
=6l99
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Reusable payment codes

2015-04-28 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The notification transactions are a pain point when it comes to
privacy, and yet they must exist in order to to ensure that nobody can
lose their money as long as they back up their wallet seed.

They could be treated as a backup, however, that clients would not
normally rely upon
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVP5DDAAoJECpf2nDq2eYjdLsQAJ/nZKFavcJnCMUQ8hKp6dRq
2+7bAVIWYHuOV6sv/hvG2NaP3u24NYZ/Ji0oD3UAmkJxw9lsZuowwBBs+YAs6JAW
KHTl3QtwBh0IP/V90JOZ5Yn72YWXDsNbqy7R3JhEDKOu2wVeiLqWZ2EDgGwiZ0/k
aXFJbcVZEKttWYCNoZi0yRMH+S9gbi0LgOwvK9mRzF9IRz07SM1iKQeKPsW1X1UM
KNeikFROMS7dHTO5HRGyFcTSwhUf8RJq2kea+4sJtj8Vlb5rURuJanL3Fav+ZZjr
RWYubLp9EUrDMm9bciygL8+MKPas8hedHSW2JhjkshWYC/NoCXLBT6SGrrbj2SKL
zGGeLYknjwgLTCstKSQlXW3J/xcSFwBztr//o95SwRoIKI7jpuOE6cPfUZVEuTsU
Zm7IWuRw/1MMDF89gCtDkBJcX2mTARjiii1Hg0+7vCv6Q/fVgTNUvWEKeNtCNZjh
wOiwd4eP1gY4CwX68c+8CfF+NOSXImJTspZJvDQcTge1/bQJNOBn+cMYxjBcJsqL
ZUOvkWJqwiFERW7vjMhOVpqIyO38UluwsWgp7nlMl/npfv0ZDIrOqZrswHSTqfdc
P8gSaqvpc6cMaLL/ijvOtORkVB9ZlLmlTv6mIYWHeKEf6PjIOZEb2B75zPHFAvrz
TKLxjvWgvSJ4l5PrkCFA
=1Id2
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Reusable payment codes

2015-04-27 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/27/2015 04:46 PM, Mike Hearn wrote:
 So that's not quite what is meant normally by identity. It's not a 
 government / real name identity or an email address or phone number
 kind of identity.

I expect that mappings would begin to develop between payment codes
and government / real name identities, at least as far as that
businesses which are required to collect that kind of information
would associate it with the payment code(s) known to be used by their
customers for their own use.

I proposed payment codes in this form because I'd rather see that kind
of mapping be limited to the application layer and kept away from the
blockchain/network layer.

Even if it makes certain kind of application-layer distasteful
behavior easier, it's a good trade if doing so can simultaneously
provide resistance to graph analysis and make transaction-level
censorship more difficult.

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVPmusAAoJECpf2nDq2eYjhxIP/3Jw9f6kcEsdFTXouQ5+D5gb
MjM8AW7EEA6KXj2PqrPv/H/brorW9/Ugcc8KweCjEdJAKOJV/Bl6sP5ydSZT6pmj
A0IFIkbdxKLY9JC3BbmVHuiAFrsL1u2EX5arUC3WNAWeWlVEmAL92cSlAka4BBxy
P/wh8xN0b4hsgA602Y4Btkv2fBHLQI9NMxW3AsujP3/S78mSxwKQZz4lYAMCowu8
NL/3toaFhrUsdHsH301jNAnxEEOodMVGmgjg/ZSdvWeHwdsE2J8Q9AJqiFDswjU5
q2kZuKmuJ6EXcGDlhelUuUpfHO34qS3/dyTydcqFrYB6eynZ8nV6S1SHaSlDEM10
b95+EpfIENtYdgAqJxwfbqpibpSEIW7cxCAopF0sSbQ2qv8rwRrcIah7KeARCrc0
e+HDcyLhYkrWrlK28vVmIxkEiQ/nmkTu9dOfoVJgXxcVl9AkiHGjo7QICOZHqfRB
TOupk9UUHMmdfZC5vpj9rd+VSXJJEF19ZbGF1QsFSMuxjKTb9jAy7Dk6U/9/xK9Q
+mH6QHhKzNKb8GsiowZJq3bF2mEYqmh/BPyQ06gfDLM4yvlTb+k4R6brFzm7tkWG
49hREmHK9w/wZXnH0lMCqMHRY/YqQF5bR3ujq7pB0WHLvbvDoSvyWvGQ9cVrRA24
ASb47sR77R1LlZntoSyy
=b7HG
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Fwd: Reusable payment codes

2015-04-26 Thread Justus Ranvier
Payment codes establish the identity of the payer and allow for simpler
methods for identifying the payee, and automatically provide the payee with
the information they need to send a refund.

If merchants and customers were using payment codes, they would not need
the BIP70 equivalents.

I think the best way to explain payment codes is that they add the missing
from address to transactions which users want, but we've had to tell them
they can't have.

A payment code behaves much more like an email address than a traditional
Bitcoin address.

On Sun, Apr 26, 2015 at 2:58 PM, Mike Hearn m...@plan99.net wrote:

 Could you maybe write a short bit of text comparing this approach to
 extending BIP70 and combining it with a simple Subspace style
 store-and-forward network?

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


[Bitcoin-development] Fwd: Reusable payment codes

2015-04-24 Thread Justus Ranvier
On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com
wrote:

 So this requires making dust payments to a constantly reused address
 in order to (ab)use the blockchain as a messaging layer.

 Indeed, this is more SPV compatible; but it seems likely to me that
 _in practice_ it would almost completely undermine the privacy the
 idea hoped to provide; because you'd have an observable linkage to a
 highly reused address.


I agree that the output associated with notification transactions would
require special handling to avoid privacy leaks. At a minimum they'd
require mixing or being donated to miners as a transaction fee.



 It would also more than double the data sent for the application where
 'stealth addresses' are most important: one-time anonymous donations
 (in other contexts; you have two way communication between the
 participants, and so you can just given them a one off address without
 singling in the public network.)


Communication is only one way, except for the case in which the recipient
wants to send a refund. Assuming no refund and only a single anonymous
donation in the lifetime of the sender's identity, payment codes would
require 65 bytes vs 40 bytes for stealth addresses.

As soon as the sender sends more than one donation to the same recipient,
payment codes show an space advantage over stealth addresses.

This kind of binding was intentionally designed out of the stealth

address proposal;  I think this scheme can be made to work without any
 increase in size by reusing the payment code as the ephemeral public
 key (or actually being substantially smaller e.g. use the shared
 secret as the chain code, but I should give it more thought)


With 97 byte standard OP_RETURN values the ephemeral public
key could be appended to the chain code, but that's undesirable for other
reasons.

This is fundamentally more expensive to compute; please don't specify
 uncompressed.


Taking the SHA512 of something less than 512 bits seemed wrong.


 This appears incompatible with multisignature; which is unfortunate.


I agree. I could not find a straightforward way to express a multisignature
payment code in less than 80 bytes.


 I'm disappointed that there isn't any thought given to solving the
 scanning privacy without forcing non-private pure-overhead messaging
 transactions on heavily reused addresses. Are you aware of the IBE
 approach that allows someone to request a third party scan for them
 with block by block control over their delegation of scanning?


I suspect this is a case where we just can't have all the features we want.

In this proposal I optimized for non-reliance on third party services and a
guaranteed ability to recover spendable funds from a seed backup.

Gaining those two features resulted in some tradeoffs as you noted, but I
think there are enough benefits to make them worthwhile.

In particular, payment codes could be the basis for a Heartbleed-free
payment protocol that can positively identify customers and automatically
provide refund capabilities in a merchant-customer relationship. A merchant
only requires one payment code which they can safely use for all their
customers, meaning they only ever need to associate 65 bytes with their
identity to allow customers to make sure they are paying the right entity.

Exchanges could restrict bitcoin withdrawals to a single payment code known
to be associated with their identified customer. This would make thefts
easier (without involving address reuse as in locking withdrawals to a
single P2PKH address).

In some jurisdictions the ability to prove that withdrawals are sent to a
positively-identified party, rather than arbitrary third parties, might
move some Bitcoin businesses out of money transmitter territory into less
onerous regulatory situations.
--
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


[Bitcoin-development] Fwd: Reusable payment codes

2015-04-24 Thread Justus Ranvier
I have pushed an updated version of the proposal which incorporates some of
the received feedback and adds a note about the consequences of sharing a
payment code-enabled walled on multiple devices:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki

https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521

On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier justus.ranv...@monetas.net
 wrote:



 On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com
 wrote:

 So this requires making dust payments to a constantly reused address
 in order to (ab)use the blockchain as a messaging layer.

 Indeed, this is more SPV compatible; but it seems likely to me that
 _in practice_ it would almost completely undermine the privacy the
 idea hoped to provide; because you'd have an observable linkage to a
 highly reused address.


 I agree that the output associated with notification transactions would
 require special handling to avoid privacy leaks. At a minimum they'd
 require mixing or being donated to miners as a transaction fee.



 It would also more than double the data sent for the application where
 'stealth addresses' are most important: one-time anonymous donations
 (in other contexts; you have two way communication between the
 participants, and so you can just given them a one off address without
 singling in the public network.)


 Communication is only one way, except for the case in which the recipient
 wants to send a refund. Assuming no refund and only a single anonymous
 donation in the lifetime of the sender's identity, payment codes would
 require 65 bytes vs 40 bytes for stealth addresses.

 As soon as the sender sends more than one donation to the same recipient,
 payment codes show an space advantage over stealth addresses.

 This kind of binding was intentionally designed out of the stealth

 address proposal;  I think this scheme can be made to work without any
 increase in size by reusing the payment code as the ephemeral public
 key (or actually being substantially smaller e.g. use the shared
 secret as the chain code, but I should give it more thought)


 With 97 byte standard OP_RETURN values the ephemeral public
 key could be appended to the chain code, but that's undesirable for other
 reasons.

 This is fundamentally more expensive to compute; please don't specify
 uncompressed.


 Taking the SHA512 of something less than 512 bits seemed wrong.


 This appears incompatible with multisignature; which is unfortunate.


 I agree. I could not find a straightforward way to express a
 multisignature payment code in less than 80 bytes.


 I'm disappointed that there isn't any thought given to solving the
 scanning privacy without forcing non-private pure-overhead messaging
 transactions on heavily reused addresses. Are you aware of the IBE
 approach that allows someone to request a third party scan for them
 with block by block control over their delegation of scanning?


 I suspect this is a case where we just can't have all the features we want.

 In this proposal I optimized for non-reliance on third party services and
 a guaranteed ability to recover spendable funds from a seed backup.

 Gaining those two features resulted in some tradeoffs as you noted, but I
 think there are enough benefits to make them worthwhile.

 In particular, payment codes could be the basis for a Heartbleed-free
 payment protocol that can positively identify customers and automatically
 provide refund capabilities in a merchant-customer relationship. A merchant
 only requires one payment code which they can safely use for all their
 customers, meaning they only ever need to associate 65 bytes with their
 identity to allow customers to make sure they are paying the right entity.

 Exchanges could restrict bitcoin withdrawals to a single payment code
 known to be associated with their identified customer. This would make
 thefts easier (without involving address reuse as in locking withdrawals to
 a single P2PKH address).

 In some jurisdictions the ability to prove that withdrawals are sent to a
 positively-identified party, rather than arbitrary third parties, might
 move some Bitcoin businesses out of money transmitter territory into less
 onerous regulatory situations.


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


Re: [Bitcoin-development] Fwd: Reusable payment codes

2015-04-24 Thread Justus Ranvier
On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier
 justus.ranv...@monetas.net wrote:
  Taking the hash of the secret would then require an extra step to make
 sure
  the hash is valid for secp256k1.

 The x value may not be a valid member of the group, effectively the
 same as with a hash. Its also very unequally distributed, as only
 about half the possible values are points on the curve.


ack


  With 97 byte standard OP_RETURN values the ephemeral public
  key could be appended to the chain code, but that's undesirable for
 other reasons.

 Can you elaborate?  Storing a ~33 byte (deterministically generated)
 ephemeral key should be all that is required. Everything else,
 including the chain code could be derived from it. What reason do you
 have to include additional data?


The goal of the notification transaction is to send the same payment code
to every recipient, but obscure the identity of the sender of the
notification transaction from third party blockchain observers.

The shared secret is used for that purpose, and the sender's public key
used for ECDH can't be one derived from the payment code since the
recipient doesn't yet know the payment code.

The notification transaction needs to communicate the 65 byte payment code
along with one ephemeral public key used for ECDH. If that ephemeral key is
not located in a signature script, it has to be somewhere else (such as in
the same OP_RETURN output as the payment code.)


  Taking the SHA512 of something less than 512 bits seemed wrong.

 Why should it?  Adding the Y does not increase the entropy at all.  As
 an aside, I think this can be reformulated to only need 256 bits of
 output, and then the need for yet-another-hash-function could be
 avoided in some cases.


Already fixed in
https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
but it would be good to get confirmation of whether the way I fixed it is
valid.

 In this proposal I optimized for non-reliance on third party services

 The requirement for inputs is a guaranteed dependency on third party
 services; so if thats whats being optimized for here it must go (well,
 I think it must go for the reason of avoiding blocking users from
 using other schemes to control their coins too..).


I'm not sure what you mean by the requirement for inputs is a guaranteed
dependency on third party
services

At the proposal currently stands, an SPV wallet will have no trouble
sending or receiving notification transactions without access to a third
party service. The recipient just needs to see the transactions associated
with its notification address.

The point about restricting the types of scripts used as inputs is valid,
but I think workarounds are available. If nothing else, the sender can make
a suitable input using it's own (suitably mixed) coins first.

 I agree. I could not find a straightforward way to express a
 multisignature payment code in less than 80 bytes.

 A prior stealth address proposal here handled them fine with only a
 single ephemeral point in the op_return. It does result in a longer
 address (is that what you're referring to with '80 bytes'?)


I considered defining an additional path level for deterministic m-of-n
multisig and adding a few bytes to the payment code to express those
parameters, but thought it would be too limiting since it would preclude
multisig with truly independent keys. It is a thing that could be done,
however.

 Exchanges could restrict bitcoin withdrawals to a single payment code
 known to be associated with their identified customer.
  In some jurisdictions the ability to prove that withdrawals are sent to
 a positively-identified party, rather than arbitrary third parties, might
 move some Bitcoin businesses out of money transmitter territory into less
 onerous regulatory situations.

 But this mandates horrible key management practices, reliance on a
 single hardcoded private key which you cannot change; even if it
 might be compromised or lost to the wind. It's less horrible than
 sticking to a single address because it doesn't wedge privacy, I
 agree; but care should be taken that a tortured dance for confused
 regulatory cargo-cult reasons doesn't mandate people not engage in
 sound practices like periodic key rotation. :)


Cold storage is still available (if admittedly less convenient than in
traditional wallets).

I would expect exchanges in practice to allow for payment codes to be
changed, just with non-trivial waiting periods and plenty of human
overview. It would be an infrequent event compared to the frequency of
withdrawals.

Various schemes which use public key authentication instead of passwords
for web site authentication could be used to continually verify that the
user hasn't lost access to the key.
--
One dashboard for servers and applications across

[Bitcoin-development] Reusable payment codes

2015-04-24 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-

Hash: SHA1


https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki


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.


-BEGIN PGP SIGNATURE-

Version: GnuPG v1


iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd

JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa

Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz

QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG

NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR

o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo

2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h

/wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9

EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET

n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI

OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+

SGApMBd4Q89fKzL2djae

=Dypr

-END PGP SIGNATURE-
--
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


[Bitcoin-development] Fwd: re Improving resistance to transaction origination harvesting

2015-03-20 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

-  Forwarded Message 
Subject: re [Bitcoin-development] Improving resistance to transaction
origination harvesting
Date: Fri, 20 Mar 2015 14:06:59 +0100
From: Arne Bab. arne_...@web.de
To: justus.ranv...@monetas.net

Hi Justus,

I read your proposal for a bitcoin darknet (friend-to-friend), but I’m
not on that list, so it would be nice if you could relay my message.

Wladimir J. van der Laan wrote:
 Experience with other networks such as Retroshare shows that … in
 practice most people are easily tricked into adding someone as
'friend'

This argumentation does not apply to the friend-to-friend connections
in Freenet, though, because in Retroshare you need friends to be
connected at all, while in Freenet adding Friends is optional. They
were made optional in direct response to seeing people exchange
friend-references with strangers.

An important aspect of friend-to-friend connections is that they have
to provide additional value for the communication with real-life
friends. I had few darknet contacts in Freenet until I started using
messages to friends for confidential communication (in which freenet
traffic provides a cover for the direct communication with friends).

For details on confidential messaging as additional value see “Let us
talk over Freenet, so I can speak freely again”:
- - http://draketo.de/english/freenet/connect-speak-freely

And for a description of capabilities freenet builds on top of the
friend-to-friend connections, see “Freenet: The forgotten cryptopunk
paradise”:
- - http://draketo.de/english/freenet/forgotten-cryptopunk-paradise

Best wishes,
Arne


-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVDDnjAAoJECpf2nDq2eYjgwUP/3fRjH25OcGmG5AS3UE/wTvf
z8DrPieF4wtX4ABZTC6X/Ls9JnWeEhL3jN70SfGLzx2Exat620DVeR7nMHuQhLQj
6vWJSKLX8a0W47LmlAveagKeLMyQdOa1jZWZWJOUwxpoH0sHJwhBvRSiZeoHub2H
PI+WyivRy3aUhhAc4EkFlaFbJVl7JMjdaqEaoHV2l96fKkvuJOYfzKWuxYd0noTI
mgfDrXtm1zTH6H9C+B+AhXlDlaAnBoVr/EC7r4nKGeXGvOBw/UrAd/OHEySQJm6b
Quo8jPBOT8mwZVanJaAbRBDnOYXP4lIxkGaH5aXCWCReiepCPtUqbGF7hHXlAwGQ
LjpLr81Uxd/1TKk709FnSKtprSf6WdYmkzXCNjjPWLfd1bR7Yj71wtmDwPdy5IOS
W9TSD9gszD0BmiZFncD4lyKBFletfGlZaVirXNhwgEKBgRcS48AYc71IjWfjbq0B
P2wzevfdHJqda3Wr04H08pGNO9YeYVqJAvr7sqHaZdn7DyDdDhRehpzbgkphNU3c
Pr1XBTheFqZZTZSya1ufVR4y9c1qFeVx1T5pqVyfUt1nNA0oaHNm0tcCOKafNAyq
+9r9p08IXsjR44STpw/DHMERZ+W/XCJsACwWNo3BK7UumHlvaLoevmdmswghjblb
MQKLKZaKAZA56lvPymbC
=7CQT
-END PGP SIGNATURE-


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


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

2015-03-13 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/13/2015 04:48 PM, Mike Hearn wrote:
 That would be rather new and tricky legal territory.
 
 But even putting the legal issues to one side, there are
 definitional issues.
 
 For instance if the Chainalysis nodes started following the
 protocol specs better and became just regular nodes that happen to
 keep logs, would that still be a violation? If so, what about
 blockchain.info? It'd be shooting ourselves in the foot to try and
 forbid block explorers given how useful they are.

I'm not talking about keeping logs, I mean purporting to be a network
peer in order to gain a connection slot and then not behaving as one
(not relaying transactions), thereby depriving the peers to which
operator actually intends to offer service of the ability to connect.

That someone wants to run a large number of nodes in order to make
their own logs more saleable, does not mean they are entitled to break
the protocol to make other node operators subsidize their log collection.

Especially if a data collection company is deploying nodes that do not
relay and aggressively reconnect after a ban, it seems like they'd
have a hard time arguing that they were not knowingly exceeding
authorized access.
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVA16sAAoJECpf2nDq2eYjxsUP/3ASGcsdGR8IEO7Fk8VghuVp
jwIIM8Bu/WsoWKG76GhuPKs/qC0VC6GXKpGUBVy7bF8uwdhfdSXcyld9MIzIENJF
I0wMX6B3SjqQG/g0rNZ91Dh3xKIF39/TQdDERM3yiQi1oavAc5TPLReN9ZbyRcVw
vCfPWorTvrad5INCn/krcEopbI013aW2ryWnkN6sFGinF5Yf4xhrNQbQeGbhlH15
/XUIBva6/PbUs4HaC+wqJPSUfB4OmcP1ZfXMuPDEmKEWdI+3WqUYF4sNAVOke560
+RL5qMJIxSUMYMAb3p+025Fn6WOc2wupQzpH/ISkuaI+5+ne54Mx/ZHJg7Z7inov
WMKfiUS6R8EHrY8IoNpO9uNqsgC+y0vlU3ELqu+gOhFTpMK7pVX2aAek8Qe7hSHy
GwtG5U6AFubLqyzP9/pBJHnmDG71brsKffAXOePDjXWfLfhy78aeQ3HOnzVhv9QK
snmE2C6Ex/tQDUwT9MKTdw59Hy7E7GdQlSPH+MYQKUBlkpWLDGpi7oriBRwvEy4/
NJCJU9+x7jijD7vrjBE+LSYdIQoZqE240N6teWqVc2wRPM8g+e+kSQqfjdKQdiQY
waeKHBKerqRq2EGffeJWV1RIEFtFND1l8zw/5ZQF4w959zLvhk/QPHzxKyTbCM2f
3DOgEWCJFLsNzpPQ8es2
=MV9D
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


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

2015-03-13 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Given the recent news about Chainanalysis
(https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/),
and other companies who are disrupting the Bitcoin network
(https://www.reddit.com/r/Bitcoin/comments/2we0d9/in_an_unrelated_thread_a_bitcoin_dev_claimed/copzt3x)
it might be worth reviewing the terms of the Computer Fraud and Abuse
Act and similar legislation in other countries.

Although it's not possible to stop network attacks by making them
illegal, it's certainly possible to stop traditionally funded
companies from engaging in that activity. Note there exist no
VC-funded DDoS as a service companies operating openly.

It's also worth discussing ways to make the responsibilities of
network peers more explicit in the protocol, so that when an entity
decides to access the network for purposes other than for what full
node operators made connection slots available that behavior will be a
more obvious violation of various anti-hacking laws.
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVA0IFAAoJECpf2nDq2eYjp0IP+wVsW69xOpFIX4yRTHrEQYh7
MCPM7OTkIay/O13TSewbxTRPww9Z6vOpmrDkFlWGYKyrLWyqUGwcKqOscE8r3P3U
xdV5ACppol5HXra/bykxuaXJWF/yTM7PybFNQ2Ary0X41CFrOUITsO8SwWDl8jBu
GtRgbWdALA6IQeeRLVQmMo3zC/uShOplOh/HrS2z9ZtXSm3rNkLzhnUWfznbixb0
9C1yvIM5VOwoNcRKt7uoX6cl4mFsBO3Gfjz4rr5gABerTltBlRk4c3jnUDUlQiFC
cppX9eaEYMLR7y0gHWnmzWcFW7LFwMR2isyJ79O2cpUpYNzbfp0fWetM1WVAMFSK
7hyUlwVx4WgaVRT5hDb6QPHHvzCYjYq+19+9/uChh9P3s3QkKuFJUVYwHQ+wnruK
hPS3/vb7Tmt1eLTUeno4RRyJJ7likHsNA2bxWSG9rDezTownkSVZe2BQh3GIZOBg
H8Nu2IDWK4pHJaCiswW4jfDsucuYiP7978p8ZFbZbymeflsXz1qyUHSVm9kngfZn
sYUK4rgRsdrPpong0nqlmWcQW3VgmNO1tw5gmUqWTxQLnrCxgqnSdT7srzAw1ZaS
YIAaB1rBy8k7QyDCOyIsIV+n1H26ZBa8PrqdRExlz6PuWcywjuEbcIfEl9QSURA+
pLuNJ+uQN+JBjKokmaSQ
=ZO1/
-END PGP SIGNATURE-


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


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

2015-03-13 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/13/2015 05:08 PM, Mike Hearn wrote:
 
 That definition would include all SPV clients?

Don't SPV clients announce their intentions by the act of uploading a
filter?

 I get what you are trying to do. It just seems extremely tricky.

Certainly the protocol could be designed in a way that provides
finer-grained access controls and connection limits, which would make
the situation more clear.

What I'd actually like to see is for network users to pay for the node
resources that they consume, so that anyone who wants to place
increased load on the network would compensate node operators for the
burden:

http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/

Absent that kind of comprehensive solution, problems like this will
continue to recur.
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVA2HLAAoJECpf2nDq2eYjcvYP/iqYBxboMmTPLp9Kx3GlBdR/
IPtCxVoaZQkqrAHlbbED1YHoI7QqaufdPMb9mw8bErFX7E89u4gD93jvx2x+skqW
KtqIyc5fHe4MgbtGypvE5GjSiqZZIqn7EYzLGVE5ydmO4SKpfodXIIRuQRkZ1fTG
j0ovFc/bmigS7Cvf3gsMT5oW26IcEaH6mAZ/YU5oVEi1LGff8hUTq90uddOCpoqp
mIj8MHMdd0yvtihjLwyJPdfT0qTOkbAxHJqwPLoOWzmrN0z1PbU9qcf0aHdDnMlT
+jWHqHzSxjwyB1bmUhi6vZKVFfd1moOTI3BBj+Jqjc+xaOmXCcyAtpfzq97VITZw
qhAnYM4unsC0A1GH3fQEJPvoOy0kwyNNtI7z5YOrRJtihCpFSbtULqN9DUmxwgKL
/0cmOc2SyjgflTiCejazBIJk4Ie+WcV2cbgepdX8USb0tusQs+jn2HMFGUfxywTz
riy9Ex8Wftl12LAYXSbMQl7GnADYG9t0HIY3JqPAhAzEdPynXUduveatiQyNc6SH
IqXraTgHj6IFFWB7eLjWuIleyxcFC81qTFNUYxEajGDLbCX00emKiR3RUpVZ/wP7
8CXcV4zco1y1+va1eD/7eNhTW/Xuf3+KdqJs2reLq23fLV01HA92sRYbgLIxb0Yz
yBsE+PpY06vrHqoVD/4l
=Ofbb
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/22/2015 10:17 AM, Natanael wrote:
 The problem with this approach is that it is worthless as a
 predictor. We aren't dealing with traffic safety and road design -
 we are dealing with adaptive attackers and malicious miners and
 pools.
 
 Anything which does not invalidate blocks carrying doublespends
 WILL allow malicious miners and pools to conspire with thieves to
 steal money. The probability of being hit will then be (their
 proliferation in your business area) * (their fraction of the
 mining power).
 
 That might seem to give small numbers for most sets of reasonable 
 assumptions. But the problem is that's only an average, and the
 people being hit might have small profit margins - one successful
 attack can place hundreds of merchants in red numbers and force
 them to shut down.
 
 You should never expose yourself to attacks which you can't defend
 against and which can be fatal. In particular not if there's
 nothing in the environment that is capable of limiting the size or
 numbers of any attacks. And there's no such thing today in
 Bitcoin.
 
 This is why I sketched out the multisignature notary approach, and
 why some decided to extend that approach with collateral
 (NoRiskWallet) to further reduce trust in the notary. This is the
 single most practical approach I know of today to achieve ACTUAL
 SECURITY for unconfirmed transactions.
 
 Don't like it? See if you can do better!
 
 Just don't rely on zero-confirmation transactions!

You just disproved your own argument.

It is possible to predict risk, and therefore to price the risk.

You also noted that for some Bitcoin users, the price of that risk is
too high for the types of transactions in which wish to engage.

In what way does that translated into a universal requirement for
everybody to use multisignature notaries?

Surely the users who can afford the risk can use zero conf if they
like, and those who can't can use multisig notaries?
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJU6gLmAAoJECpf2nDq2eYj8/AQAJfMtBqjo1Z2Z0A7OhE9iaYD
PqWXdRaCFwyV49RSDrRROrB9Vc7CENQsweHBSnNEmSj6la/YfjyobmaR5BMtTq73
ZaXOFYSGVa9S0j+1qTvz2MorBd6ocxckdunfN7N/uVb4NQRYTHUT8N7AyJgRFYO9
ElQU/8TcNCSRqSQc3z8rnUc8eN1+DgqkMDHM754huOgA0fz0OlxnLCddcCvLr0t7
ZPCtZI94FWQSWhzTK2oa41hh01xG+Eg5GhqGzM7WBqM6+d/CgNcUVeMnVOkkhgav
AmlE81Km9R4AlrsGT/CcGgaC+FvBhqmDYHAGOUG3hLP+MXMe4qA5TRoRKHFvq4Gw
nF6q+leI7z/TkKeiDcyEKKen5cU01SnZlVRnncccIxsjzNjCiBdXOTP6o0pTd34j
5VJQ04mF4sla5AaaSDtsbkZuMdqIZDMn1tWxbmXRQ2cUbCGoi4yYiUlqjetrs4e1
i7NopccLNVDwjGRRnaSs4KkpuW7s23XwKm6WVehrP7S9s1Bqc+84C/rL1G4IF3Ul
vOz+dfxpS+yeGdEDOxb92voKo+fvL/N1sH2+cqTemuYWArDOn1kK/qKdaEfnl9p2
VcPJWuik6Ywomg4fCWmTQWcDxbWiUT/Gb/niONOYQ6iJG7mU4SH9LFBDd8qV+ljN
RqUYrOBf/PaMneNxwJp+
=w36r
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/12/2015 07:15 PM, Alan Reiner wrote:
 I'll add fuel to the fire here, and express that I believe that 
 replace-by-fee is good in the long-term.  Peter is not breaking
 the zero-conf, it was already broken, and not admitting it creates
 a false sense of security.  I don't want to see systems that are
 built on the assumption that zero-conf tx are safe solely because
 it has always appeared safe.  You can argue about rational miner
 behaviors all day, but in a decentralized system you have no idea
 what miners consider rational, or speculate about their incentives.
 
As noted elsewhere in the thread, there are two problems with this
analysis:

1. It asserts that zero-confirmation transactions are in a binary
state of safe/broken instead of recognizing that relying on them is a
non-binary risk analysis on the part of a merchant.

2. Assumptions about what is profitable for miners are based on all
miners having short time horizons for calculating profits.

In addition, I'll add that there is an assumption that honest actors
can not alter their behavior in response to changing conditions.

Since scorched-earth solutions to problems are apparently acceptable
now, what would stop more honest node operators from patching their
nodes to blacklist any peer that relays replace-by-fee transactions,
and maybe even publish an IP address list of those peers?

Punishing Bitcoin users for not adopting somebody's pet solution to a
problem neither responsible nor ethical.

Child-pays-for-parent allows for stuck transactions to be cleared from
the mempool, and allows recipients of zero-conf transactions to adjust
their risk exposure as much or as little as they like.

It's a solution that gives Bitcoin users more freedom, instead of
trying to coerce them into pre-determined directions.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt
vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO
hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99
kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/
F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt
P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh
pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5
sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f
b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd
j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL
LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0
F9dKdL5zCGofvU/U5BVq
=kEMr
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/12/2015 05:24 PM, Oleg Andreev wrote:
 
 I think that is a misdirection on your part. The point of
 replace-by-fee is to make 0-confirms reliably unreliable.
 Currently people can get away with 0-confirms but it's only
 because most people arent actively double spending, and when they
 do it is for higher value targets. Double spend attacks are
 happening a lot more frequently than is being admitted here,
 according to Peter from work with various clients.
 
 Like single address reuse, people have gotten used to something
 which is bad. Generally accepting 0-conf is also a bad idea(tm)
 and instant confirmation solutions should be sought elsewhere.
 There are already interesting solutions and concepts:
 greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment
 channels for example. Rather than supporting and promoting risky
 0-confirms, we need to spend time on better alternative solutions
 that will work for everyone and not during the honeymoon phase
 where attackers are fewer.
 
 Here's value-free assessment of the issue here:
 
 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
 instant payments solution if possible. 3. As a social artifact,
 today zeroconf txs happen to work for some people in some
 situations. 4. Replace-by-fee will break #3 and probably hasten
 development of #2.
 
 The discussion boils down to whether we should make #2 happen
 sooner by breaking remnants of #3 sooner.
 
 I personally would rather not break anything, but work as fast as
 possible on #2 so no matter when and how #3 becomes utterly broken,
 we have a better solution. This implies that I also don't want to
 waste time debating with Peter Todd and others. I want to be ready
 with a working tool when zeroconf completely fails (with that patch
 or for some other reasons).
 
 TL;DR: those who are against the patch are better off building a
 decentralized clearing network rather than wasting time on debates.
 When we have such network, we might all want this patch to be used
 for all the reasons Peter has already outlined.

You've left out of the discussion that many (or all) proposed
solutions for 2 either reduce privacy, or security, or both.

That fact should not be ignored or swept under the rug.

There's also no mention of the degree to which child-pays-for-parent
achieves the stated aims of the original proposal (clearing mempool of
stuck transactions, increasing payee assurance of conformation)
without introducing incentives to double spend or forcing people into
privacy/security sacrifices.


- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5
6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM
HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4
bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF
2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45
RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap
V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232
FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs
G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF
n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM
7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8
XjbkwrkFIuKfUJyfIuR+
=ony0
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/12/2015 07:47 PM, Allen Piscitello wrote:
 Nothing will stop that.  Bitcoin needs to deal with those issues,
 not stick our heads in the sand and pretend they don't exist out of
 benevolence. This isn't a pet solution, but the rules of the
 protocol and what is realistically possible given the nature of
 distributed consensus.  Relying on altruism is a recipe for
 failure.

If there's a risk of fire burning down wooden buildings, pass out fire
extinguishers and smoke detectors, not matches.

The latter makes one an arsonist.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJU3QRrAAoJECpf2nDq2eYjLtwP/3t0uplMwjpt6MP0wrPwOfkJ
tRRyAaSkEsZi3+XjU2GVThG7kAlP2oIGFnoHc1QldhlEeWEJgPZyn7qq+mPx+I5+
OKb0PhSwRpTe0lh+r1dGyVqN+sSfbasJ9RSXYPmw1OW9ud4WOsgOh+oBTQWfuhvc
p32Fxxx5JKjc4AnCVajSzNlPlXrBy3pFfL5F1ek4Wu+H0haz39VE/EYAWlXjyWxT
vhUzv+9bcy3r8pe3eYUAmsXYLZAKb/9hWJdht6SKd509BlV6LVSrUh8Y2SJ3PYKt
z3l4WmiUXkkdk1blqtLDyfUTEZSnBK8X4esj8Sp53WfOXNkgBKe1vr4EhTXaEQMU
KD1e5s12xspPYgJdW9TWacIYKp3Ft3yBODJOTNZL3j0ryzYA+KU5ZumdHIm10J3S
J1IDQBraONESinHybGPKYtUCikTkl6TemW/CpfjRhQONov4708FIg+KQAo6ui56N
otfDGEwqH1qKgbt5DugdEBtxDmYmcYdFjID2+ZLwK6ngat8UAw2dQoCnUtkZ7w+i
Oxz4cm1vIRjv+BYipQjg4IRRZNvpEXSolz6u91qqj8SlXXdY7sZ3B5HwtGSOVX5y
l3NxYVOazA/NA/zcCG9ZPjr/O5sKJ40IjcLbTHvE1POuiF167xF2+U2Sdf/43d9d
cE68utrIaurfJsDA/L/+
=pTe/
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/12/2015 07:45 PM, Peter Todd wrote:
 None of those solutions are compatible with decentralized networks
 for a lot of reasons. Given the inability to prevent sybil attacks
 your suggestions lead to people being unfairly punished for poor
 connectivity that may be entirely out of their control. They also
 make maintaining a Bitcoin node and mining the blockchain require a
 significant amount of hands on maintenance, again incompatible with
 a decentralized system.

So maybe scorched-earth solutions aren't a good idea after all.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJU3QO8AAoJECpf2nDq2eYj4bUP/R8Lwjpdvc8Wu573+cGVRI88
/J8fURgYTxS9yvNNGRRHDYkHiqAcGI4sHIQQkqGs+A6mdDTbq6bJ04RjHoznlYbj
TcpaKQkEynVSD5AjMnZ7Z/zLsc+qjFChNGNgxC3k4AW5UdBgo3VTE8HR1rVXM5C3
JLCSKv8uCRkHJxRlXZwE9/sZTZAAuLFVdTQb6sfi4Kb4Ztn8P2K2IsEnOlFwv1cZ
ZNByxa56iBbNrVQa7hbbNXauIGOkj0fM3MB75JUQK/dHnW5d19bNHRIG0vnTtczH
eoVvEdMtpSF/e7S6Kzx5xfcmCQsBRX7JIHyuZpBYAgr1HxjXOrdvqgWQCWDSUtNO
ybzYwNKUbSCgbp6tbVTQuskm0QKVRcrrqMPZepPcgjQ/FLB8EALqarROkJTop/3p
8YatD3iq77SdnOfmFMZCFGHzn4UaxturRdEYIfeqz2Ia0YyyH3GWs1juhazyH+CM
u6HbXXrq6AJmKWLYbSK1ycUBo9OhFObT9X3XswsWa0uNtSwLveqlvaI77UHkJbnr
U9Ek9V0WznV1H9hn6qJpKyS/d+M64dfGjBSo79b50IxvlKrHKBPZkdHfSUyjnMFW
rl9uE0jB6oLFUcqchypJ89HUeso7fD/8l36w0Z4TkMrcAy9V0RIj6P5nBYBU1U1s
cLblEvdmUqmt4t+D1o4K
=YnGT
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/12/2015 03:20 PM, Natanael wrote:
 Multisignature notaries need to convince people to select them.
 They want to know that even with collateral, their funds won't be
 temporarily locked up and unspendable for days at a time.
 
 What services would miners provide here, do you think?
 
 Well, sure. It's the same model governments use and is why being
 a money
 transmitter in the USA is so difficult: you need to put up large
 sums of money as collateral and have your fingerprints taken 48
 times. Then you can start advertising to get customers!
 
 Obviously you need to have collateral to provide collateral. Can't
 make cryptographic verifiable guarantees if you don't have the
 resources to back them.

tl;dr: Bitcoin users aren't getting very excited about somebody's pet
hub-and-spoke project, so they decide to distribute a patch that will
change Bitcoin's behavior such that people are forced to adopt them.

Scorched earth, indeed.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJU3McnAAoJECpf2nDq2eYjxI8P/iClVQKNhGPr0K4D8KktUDUS
CB8Gu6Rg4VqgjzwhSd1AD1CAhSkxRRgNfHOkxeu2n1wA/fs9V/x66W9G33OyHvf4
1M+BwkiNszxvfxvZVkXyPa/eqa8/alIs1jEhb19dBRn6sJ6EQyca93PG00wDhhRU
JbHeYj2pYYMuu+xRpJWhRdUOpJOsLu5E9XMocS12wun7+zQCs4QfoLVcGhMv3+Ug
iS3/H1NNQJegIFMQzgi5hr7CxClZ+MrsLDO7MBEZknjr0toEJXe7c5Logwc3oF8h
klhFeSnhexCHNeDSGKDhG89hrgWPSDDuuyMRa3e3L4xsT2zAFcsmw0ScCmyNSto4
gUCy1gQsShDJSvsYvqjJkOcL5UfP2WLQiVJecpblf1R/tgjC0SsBoPeRMT/DeSjV
xpcjUrAUzkIBuEcunFarkt7wBvL/4pvGnbYcx3uW2YX50oO7LjCcgwJLMW4ecsvn
zAoc+aXqeORo2SAI3tTJKqpnn5K2k7DVTiFt1vzHVR7OxnKa/+sXk+bCkQi9/dAL
bWjiBUV8hXBVIt0UBgj7Q5wgQSoAXI0D816GIA2Qb9XQfmpRb8QTmf9kQ1DrcV68
Qt1KOHPY1yCynqLMxN3ONWu4JMF+YYwrxx47Gg7wSJr5q70mHNlLljfnfb5PNLtS
J6t2/QfPTMmyN3V6xkbU
=hna5
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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] determining change addresses using the least significant digits

2015-02-06 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/06/2015 03:08 PM, Jeff Garzik wrote:
 Yes.  You can certainly add additional inputs and outputs -- and as
 such you can increase privacy and defrag your wallet at the same
 time.

A lot could be done to make regular spends resemble CoinJoin
transactions and vice verse.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJU1P7iAAoJECpf2nDq2eYjeXwQAJGdVdYta5CddfL+xyFNG2+l
RMxkSABfgWQF6mDus6ul+EhRhOYEveuuukbK2ibcnY2U4H9ecb8Gttno9+Wi0YfM
zcu1Wt/j5cJyUFjO9owZO5gse5mTCt+1njgNIGMlXHHbFEHc5OavXEgkvh8YcL/j
E8Kk4YNM5Ovp47vh1ihkB4Zo+ihu5oMuY4vbBO7So4BIe8KaSLOTsOAccT17bWGo
jtd6KdjfqsLSjhQoVtuQAsx9AGUS+jfjBRWSnwkeAdd4G4BE87/7DCdYnczFKhds
kVwnHODA0+5dwEwZ/ChipKVzAVLVZ2a7BXUenax70P1QgfG8WwL0tueoKviRBLfc
6Xa80GHGo84qeGEkiste1qnG4XZWwi6pnTSTwP1f5CtVvGvfYRysHsMCm82Mr7vA
pwrQULv6fkhI63xB+kfcXBPr0WIVrilVrEtGcypzIbPbQgRQ6k3Wg66zLoQTc8vA
w2pOZYrEU1Rmfiv27/MLdvSuWzR0kF+nidwCBxUYBuKAA4K0Y8GBH0FApp9JmCEo
LXIY4RU3sCCbP3C1qloN8k99q8+CDTwrZpzi2zi3r0zRorg/1tTXqavicE9KPC2j
ymk+eFFJhqG51o/d6irzA5R+hK/T2JatDhneEwTBetsrbXq0D9jiN3+KB+vME0wf
KJhXhGbElNyz7eA4EOMt
=zcqb
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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] determining change addresses using the least significant digits

2015-02-05 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/04/2015 02:23 PM, Isidor Zeuner wrote:
 Hi there,
 
 traditionally, the Bitcoin client strives to hide which output 
 addresses are change addresses going back to the payer. However, 
 especially with today's dynamically calculated miner fees, this may
 often be ineffective:
 
 A user sending a payment using the Bitcoin client will usually
 enter the payment amount only up to the number of digits which are 
 considered to be significant enough. So, the least significant
 digits will often be zero for the payment. With dynamically
 calculated miner fees, this will often not be the case for the
 change amount, making it easy for an observer to classify the
 output addresses.
 
 A possible approach to handle this issue would be to add a
 randomized offset amount to the payment amount. This offset amount
 can be small in comparison to the payment amount.

Another possible approach is to randomize the number of change outputs
from transaction to transaction.

Doing this, it would be possible to make change outputs that mimic
real spends (low number of s.d.)

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJU1DH9AAoJECpf2nDq2eYjt2gP/3gpojJey2URkWWk0sg9dpHU
OsD37TCbrwUaS/K8UMKsuc45FSJU/EeYpaVz9r1Ifm/IeaFYPIX0tEm17n3hkcAG
QPmt/xAZn9GVyPWYKjmVDmx574pqiJLeZh8bP788sZsGc4Gk7NNJniVGLtsmvFCb
ZOtwS8v7UuJZx6awydrpNhw/+SsQn9Xdb8fcLqmFKWDpG2Mlrv+ds34NMlGbfO2r
PqCMw1Y12J0HXLisOCGQNZNdG9mVjKw3MP0GGjUlOM+ibrrorqoO5Ifo2RGuElgw
LZkzzDzg6kO8iuNOV7Jg1lz5WftRjgLRSCcMq4V+793zGJW9BeISeDcKQ2ZlWMXB
Hu83m4vCYOJeECdKGWlhyTmKNNHshsiPz3SBDLxP8uR80UkS3waDIXwLxGX9Pa63
uleaZ2qHQ/0UdC9opN3Snn33M701dHNJH9iXfhf/MVnUZ0FjzsLXaJ0F0208ZxCX
qGCAv5y1ijrDlCLTvakZJRIruXgxNPqtErzP9GtgXeGeDc8tRv00WiM9Olpu0EXd
yjhAZGydcE3Ec2cNo+teWjeDt4Ga4OYDb7i08eegaDuj5MCDcDtlgfwNjdKbre1x
S7pKKDn8V03/WST1x9fWjM04NxeSjJ0yRjOAxkLV/mlDX6lQEYJL/W+MJLvpOnTC
LtZrkSmSTJ7ZR0tMgpAe
=8EVe
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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] IMPULSE: Instant Payments using the Bitcoin protocol

2015-01-22 Thread Justus Ranvier
On 01/17/2015 08:45 PM, Rune Kjær Svendsen wrote:
 Hi list
 
 Found this on reddit: http://impulse.is/
 
 PDF: http://impulse.is/impulse.pdf
 
 I'd love to hear this list's thoughts.
 
 /runeks

I'm concerned about the silence that always erupts whenever
privacy-hostile products are proposed.


-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

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


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

2015-01-20 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/20/2015 03:46 PM, Peter Todd wrote:
 But ultimately we're not going to know until court cases start 
 happening. In the meantime probably the best advice - other than
 getting out of the wallet business! - is to do everything you can
 to prevent losses through malicious auto-updates. Create systems
 where as many people as possible have to sign off and review an
 update before it has the opportunity to spend user funds. Not
 having auto-updates at all is a (legally) safe way to achieve that
 goal; if you do have them make sure the process by which an update
 happens is controlled by more than one person and there are
 mechanisms in place to create good audit logs of how exactly an
 update happened.
 
 Finally keep in mind that one of the consequences of a custodial 
 relationship is that some legal authority might try to *force* you
 to seize user funds. StrongCoin made it 100% clear to authorities
 that they and sites like them are able to seize funds at will - I
 won't be surprised if authorities use that power in the future. The
 more automatic and less transparent an update is, the higher the
 chance some authority will lean on you to seize funds. So don't
 make it easy for yourself to meet those demands.

One suggestion you didn't mention was jurisdictional arbitrage - don't
be located in the same country as the majority of your users.

Or, from the other perspective, users should be strongly encouraged to
get their wallet software from companies/organizations not located in
the same country as them.


- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJUvpSqAAoJECpf2nDq2eYj0oQQAI62vLPzFrkLZoRw3bIw5GWt
6L8dpLUviRS7ZaQlNB49TT4L4Ky+MJ1PxaHwb4YPxrVcCWDLiJb51CtODduF/9rR
8N4xoQuf/6DhsBHWJE8NDwP+9JUOlY23xdSe/BlLz9N1Ql/EV0HTCu28A9xbhK1L
QHgwX3p5/ZCJo7PCARF3o+EZOif5MsA4MdQ11HhyFWN/fgww9AVOIg/0m+tIqkjR
yoOzFww4AejC7nxi+Q+elljpvp2Q/Nv8cVOVlp9l4+f9P7sg0em9YUCE+iAxoZTT
7b9soUXFUjWlxFITR5RnjlDUnmra9QhBIhogBQbLelt/vdoRInz+kXxroR2x3uKh
EJoet2czRB1oiRKHE4iSAv+1pnavQJDVo5/mUMzeM15zCnQ16Mfu9aOpqvijK0cw
u67E4IAPJ2PmUy4sPPJ/4H4FPLmJrSUkLxxzq/4prmLLmeZZvPwjavnULHir4jyG
aaxFqMkbeJSeK3hLk7hnlrwpQRAEq7om+EpQ7fAx1lmEoA3eOHaeclh7/XzDwIB4
AK/jX+1ylhGvfuKNzwTQVX8dEzaHRwLAfLfHUNnP80WhBzH5ODicwcOwwOanL6/A
qgqwDSSB/Q5aj3VsThQ+PR81u/wA5t/Av9+Wn/g+AEMyzCnJcnHxDe41ZEn4UzYY
+RAX1P8yzF/M2ZQUeMLh
=G0GE
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


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

2015-01-20 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/20/2015 12:48 PM, Tamas Blummer wrote:
 The legal hurdle to force confiscation through a wallet provider
 might also be lower if the target user is not domestic.

Depending on the threat model, the incentive to force confiscation
might also be lower.

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJUvq0CAAoJECpf2nDq2eYjr9kP/RWEg8Az43T+7qMFnrk37+y/
0pyEQ/zisao1d0LouxyGFu704U8Qayk96hUu+2GAQpS8hHVA0CmDW8E1hqKG2nGl
MTTQYp7932NY2NysIvNaQDhVErZZFqMpPYCnsSrnwUrygh+QjWAI8nvrrcgprG5/
zybzs5IJjFQ7QwYJ92D01shkqQJLYYspp2ME3z97AwPCBanN8eG4Iji/V8/aJqcZ
ZqF7yUjAySVUOUzR+Vju1C7N1i9MHzIG9vZA/jkaCiqZ8bvyQTm9LwSK3quoxGAB
lTplIwKjWsEvs0nm0RyurcPIWq1ppfPiWCaMCNDA5Byz3mJbSrRW5ErFgBtpYkgw
CF+WqoWU8fajQjqd8xcsKJmVyQqk4dUWXJQLGnd6pC3DCZGOPhr+6674vgmEQG5A
bXoBAtJfAJkxkDGEsngs4EBGc08iy+t6tJUh7+wI/La8xulM5BgJkQRTnL4Hn6KS
pcgYV9JP1BWMB4fkdL81mKnG98BJ98pj019C0nuPYQtSA0rUsWG9d3NYDPe87I+K
7UJ6NlNxTLxnS7nhr8Wk9UdqkFMsCQxF/RFR6I9vCQ/FMSD+i1786I72kkyf4cWJ
4ZssTX3yo6pN/faU2cBk84PQlA2ziARXqO+jzbxVR7AFpT2BESUtBdirh1CPEMfR
piBBTr6I86R2bpZYv046
=pJvU
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-30 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/30/2014 10:47 AM, Jorge Timón wrote:
 What services? I must be missing something obvious about the
 motivation. I understand the difference between paying to myself
 only when I mine the next block and offering fees to whoever
 mines this tx. But how does allowing miners to pay to themselves
 in this way help with security and future lower subsidies at all?

I don't know what Sergio Lernet meant about miners paying themselves
and future network security.

If miners wanted to offer value-added services, especially if those
services involved adding specific scripts to the outputs of the
generation transaction, the most natural way for their customers to
pay them is to allow inputs to the generation transaction.

It could also be done with pay-to-fee transactions, but that would
make the services more expensive due to risk premium.

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJUoqXIAAoJEMP3uyY4RQ21OZUH/iI9N9bQ3TLPnmCVW6bkIitD
WT6uBUhBREls2NMjyDQ//UN9F9nt+aU7jN/I0AMrdB8ngFb4r1gfxSpld9KVp6Yw
k3jW8Lo3WhTnCCE0a1MbBqomsAfIwDdksZoH73QW+sGYD+cShgFC55QWfE6gy3OF
pge1dsWNPlMSHmWn9+g7g3+FjkhKeZFNSb0MKzIvEBE7iJOf85etJpMs9a/425sx
UcJX33bVdhG51Au3PSs+0jUljoFby28EM717otq8Tkjei2hw1yNNmtws4/NcQlh3
W6TGBZLb188hUrOOH52p2Cckm8gGgw9hTc9nSLSjQS2pPjVRpTRR4smxMTKND9E=
=QBYE
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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] BIP: Voluntary deposit bonds

2014-12-29 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/29/2014 09:10 PM, Mike Hearn wrote:
 How does adding inputs to a coinbase differ from just having
 pay-to-fee transactions in the block?

If a miner includes pay-to-fee transactions in a block, those fees
could be claimed by another miner in the case the first miner's block
is orphaned.

Inputs to a generation transaction can not be similarly poached.

That difference makes some services possible that would can not be
safely achieved with pay-to-fee transactions.

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJUocjPAAoJEMP3uyY4RQ21zrMH/1f3vjac9XqOZbDItjiD6XXU
EkpRUROjyQAs6/tO6dwWAIcXgulYREAJsU/udQNkTYteIDFlDzwkYL+NLXpYtwHs
BiZJEEwmAEHFgOD3QmmqhTx867zIbEYIB/dpHlMOppE6fhTKFr9z6JdqAKlNcHHW
tkW5sq8q9uq7StiUs3/mmZ0XXeEb84N+bPiJ9S7kuTm9QWnrF1oMLhAk4M6yX8hn
7MUowmfc9RZ4uIFkqxk6gkWJSRx7dlnCRP2TRhyABpZwAcZANuPhqBOZ6eJ6T9Fs
DOJ14c5JYachXW5z8GqR+abeq0JPE76kEQt145B4degJ4DTQLLhlfdvjbuJvzy4=
=Kfe2
-END PGP SIGNATURE-


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


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

2014-12-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/12/2014 01:41 PM, odinn wrote:
 I think the Mastercoin devs are doing fine work

I wonder if all the Mastercoin devs would agree with that statement.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJUivkLAAoJEMP3uyY4RQ21r5cIANvabja0i5j79a6KSkKOgEyR
LhBz4mugzTc8Zej2NBeyEtv0pzO4fs5wvQo4N/1BW7aHXuFJsgJpGlV8thkuFhek
UhoPC23i7u3jCPQ30PintqvCBCimse+PJa60KE2QL2DZn7WgRGKrEuo41AROxeit
vfVMcFULc6bB9hxIEBpcU4RuwKJHVgzSHMkO75/uHHtPLJ9TbCfqcxT146cZvSjc
Tc62ukuX1xBj5PhQM8GaUGzkQcfcZ+7d3DD1X22Gk1U6w+zat52dapy/qYgn9oA5
ubk/p/7Kywd8D44rPsr/pbdlDZxG0w77yRJIMboXhFMV7rY3sMRHHQmAUz+I8FY=
=R4pR
-END PGP SIGNATURE-


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


Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Justus Ranvier
On 11/06/2014 04:11 PM, Jeff Garzik wrote:
 RE soft fork vs. hard fork:  It's about this time at Mike Hearn will
 chime in, on the side of hard forks.  Hard forks are in a sense much
 cleaner, and permit solving problems not otherwise solvable with a
 hard fork.  However, hard forks clearly have risks, notably the Big
 Risk akin to a US Constitutional Convention:  once you open the door,
 anything can happen, any rule no matter how sacred can be changed.

Yes, there are risks, but those risks could be managed with appropriate
effort. Major players could publicly commit to a set of ground rules vis
a vis what categories of changes are and are not acceptable.

Maybe at some point there could even be something that resembles project
management for the Bitcoin protocol.

Why not schedule protocol upgrades every two years for the foreseeable
future?

Spend one year achieving broad consensus regarding what changes to make
in the next upgrade, then spend one year in feature freeze (all future
proposals postponed for the next cycle) then execute the upgrade.

The top priority should be fixing bugs that make specifying and
re-implementing the protocol nearly impossible. Those kinds of changes
should have little difficulty achieving near-unanimous consensus.

There shouldn't be any problems separating obviously-needed changes from
the ones that let third parties blacklist coins, or a majority of miners
vote to confiscate block rewards from minority, tamper with the issuance
schedule, etc.

-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k


0x38450DB5.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

2014-10-22 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/20/2014 12:50 PM, Mike Hearn wrote:
 One thing this brings up is the never-resolved issue of whether
 BIPs should document how we'd *like* things to work, or how things
 *actually do* work. BIP32 is an example of the former - it was new
 technology and the spec was finalised before any wallets actually
 implemented it. BIP 44 is an example of the latter, it basically
 documents how myTREZOR works and as such there was minimal or no
 scope for changes to it. Of course both kinds of document are
 valuable.

You also have things like BIP43 that encourage people to reserve BIP
numbers to avoid namespace collisions even if their work does not
affect any other project.

There should be an efficient process for informational BIPs of this type.

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJUR9T1AAoJEMP3uyY4RQ21ADgH/0JUnkrAzKiBrtFcoXNTEkNl
7npCPY90zQDXk0RN0sV49ralMg/j71azHKmdeH3XHPF2BG3mC4+7TejhJkDEoCoB
fzVyQ/a7MSz3Hnxh0iwx/4p+8A3v6oI6h3yDJeCrwdMudGYA2OfyQuFdrSuchHp6
j0yJpdxxEwtc9A/7SKk5R7yrLqeeLs4OCk2Ep8mZfCQyWssXvlJzd0IDvYZiUHrM
jwLgDCAUNIotEqF4sPzxUMCUkQH3okeVhND/WvoDh8EIrE6l48I19CfDax3gJUU+
4eI5Ooba3SRu5a8cf3V/lgtdbpJJ4i1UdpcjeWNAz1w/P1NVrWN4uJgzUilh6zU=
=OWdW
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Something people are forgetting about the Gentoo / Luke-jr censorship issue

2014-10-10 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/10/2014 05:26 PM, Mike Hearn wrote:
 I'm sure this suggestion will go down like a lead balloon, but
 Bitcoin Core is not the first project that's had issues with Linux
 distros silently modifying their software as they package it. In
 this case Luke has changed things to be closer to what users
 expect, which is good to see, but I expect to see the same issue
 crop up with other Linux distributions in future. The temptation to
 improve things when you're a middleman is just too great.
 
 The usual approach to fixing it is trademark the project name and
 use that to enforce clean packaging. Firefox and Chrome both take
 this approach. I'll probably do the same with Lighthouse (need to
 figure out the trademarking process first).
 
 The goal here is not to remove choice, rather to ensure people know
 what they're getting. It's reasonable to assume if you do emerge
 bitcoin then you're getting Bitcoin Core as distributed by
 bitcoin.org, not a highly opinionated fork of it. Renaming a
 project and creating a package under the new name is not only
 better for end users, but lets the fork grow into something else
 and be more usable to people on other distros too.
 
 In this case Bitcoin is already a trademark, though I lost track
 of who owns it at the moment (the foundation?) but I guess Bitcoin
 Core is not.

Regardless of whether this is a good idea or not in general, it won't
work in the case of Gentoo (and similar source-based distributions)
because Gentoo doesn't distribute software - they distribute
instructions which allow end users to download, compile, and install
software (ebuilds).

On my system I can compile a modified Firefox that still calls itself
Firefox by setting USE=-bindist. This would put Gentoo in
violation of Mozilla's trademarks if they were distributing that
modified version, but they aren't, so they're not. They just
distribute the instructions that tells my copy of Portage how to
compile the modified version. As long as I don't distribute the
modified binaries I compiled, then neither am I violating Mozilla's
trademarks.

tl;dr: The trademarking approach is only effective with regards to
binary distributions, not source-based distributions.


- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJUOChPAAoJEMP3uyY4RQ21DNoH/0Yb3GpF230UGfQQ7Y2qQ4Sr
QTNW6hwMaLSwRvdnkAxmQf1S2I3da6AJkXcyyUavJuqw+m6lxdiA3OwUQOZblEUS
HkZqajS3gpCCmYJGbHD+DT3YnvDaeIQmuacsxMTXpVWK5QleH6mSdpbomc2TCS+D
JulZuSQJSB997uNKqYvQmwe0b3ImgND6omoOZABjFrLESeYgQWLFBthl9vwBLtFB
DqRbyvrl6+vFzX9yObAt0+iSDkoHHkPbg2/KeUCKuJaIqvFyBo0t9dvx/tvQJupk
TY39a/0MW8z524e2s2SwsZbmYXSBLTlDhkTbWR0lPQH5OOcrmH7cpEG1vsZH9yY=
=tfaE
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
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] BIP43 Purpose code for voting pool HD wallets

2014-09-25 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/26/2014 01:53 AM, Gregory Maxwell wrote:
 On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier
 jus...@monetas.net wrote:
 Two draft information BIPs are attached.
 
 I've pinged some people privately but also pinging the list… no 
 commentary on this proposal?
 

Regarding the BIP process itself, I rather think it's broken in the
case of informational BIPs.

Proposals that require explicit action on the part of others do not
logically belong in the same process as purely information proposals
that do not require any explicit action by others are going to be
carried out regardless.

The only reason we proposed these as BIPs at all was to support the
intent of BIP43.

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJUJMrzAAoJEMP3uyY4RQ217DMH/1oGHayVo4smLM/OKeu1qqXC
Xex4NNh6g7Jsu2ulfJ5ow3g7jHEDzTBp33THhUv6cnV7CpDvTC+Y24LDRrYwOBQo
YuQ9u0NNtrcgoi+6vs8NuGO+yZyTyBYs1emOipsICsg42H8yhEHlrMyfOTJsO6r/
nAiqR+QH6isNOjQerd9Fs0nYQ6VANs8IksL41L8ch9YAvgKx7C8WxdcQrk/S2pNL
JwD7Q729J34x34HPnOb5j5Rfm1gvQInYELBu0YBaCy7D05PZd5nPSYqUC3n35hUA
AMvVf65jdQVBjvjlcqDPAPdBTQ3qjhQ+7EAWKJrwlrzhGXaWA3HpipRDUSyqzBg=
=OhH8
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets

2014-09-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/23/2014 04:16 PM, Alan Reiner wrote:
 P.S. -- No-Collision Mode is not a great name.  Happy to take 
 suggestions for changing it.

I'd call it a voting pool wallet, since that was the original
application for this arrangement.

Would be nice if you'd at least mention our work, since we did share
it with you back in January and have been publicly documenting it ever
since.

Or does the fact that we're implementing it in btcwallet mean what
we're working on is unmentionable here?

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN
Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte
4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5
L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB
88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54
msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM=
=t/xp
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets

2014-09-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/23/2014 04:48 PM, Alan Reiner wrote:
 Please recap/link it here so that it can be part of this
 discussion.

http://sourceforge.net/p/bitcoin/mailman/message/32736455/

http://opentransactions.org/wiki/index.php/Deposit_Address_(voting_pools)

Currently being implemented here:

https://github.com/monetas/btcwallet/commits/vp

- --

Really what's so annoying is how the BIP numbering process is handled in
such a way that proposals can be silently pigeonholed.

Especially so in the case of an *informational* BIP which requires no
action on anyone's part (except for not using the same BIP43 purpose
code).

We resolved this by changing the naming scheme for our proposals, and
their associated purpose codes, to not rely on centrally-allocated
numbers.

https://github.com/Open-Transactions/rfc/tree/master/bips

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJUIajuAAoJEMP3uyY4RQ215dQH/1GNOmZd19/e2Ys7MNFx0gqz
rDmTFBylU3lhJrMY4CDd4Duq5+2U7HgaovqgX8UqxquHWLQUwEzZLqdEPCifLg0c
d/u90cRlClFAaOxPh4HV2/3aZoS2R27N+ZjOfziW7RZySBP/2fMt4/ra+SPbkcAQ
oeplYgqMRDqW52C/o2zm4y4yb0TJPS+lzSNM+JfxHSPRyY55l0KzLJfUNz1RSOze
A8UAwdsLiJROKPKiSrQcqFOejPV7uqSPh10ukm/AI0k8TbvX8ffGQ083394M9IuE
DB/1eyeLQVP5+lQMWNrTHk3BQ75XBEDJoSukaRENcqxtHV2m1JzTWoS2CQBXi2M=
=TwI3
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

2014-09-15 Thread Justus Ranvier
On 09/15/2014 03:08 PM, Jeff Garzik wrote:
 Such guidelines are a perfect example of why PGP WoT is useless and
 stupid geek wanking.
 
 A person's behavioural signature is what is relevant.  We know how
 Satoshi coded and wrote.  It was the online Satoshi with which we
 interacted.  The online Satoshi's PGP signature would be fine...
 assuming he established a pattern of use.

I wrote up an example of how the WoT and the behavior signature might be
combined via a game:

http://bitcoinism.blogspot.ch/2013/09/building-pgp-web-of-trust-that-people.html

tl;dr: Identity is not a name - it's a set of shared experiences with
other people. Identity systems that want to be successful should focus
on those shared experiences rather than names.

-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k


0x38450DB5.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/23/2014 04:17 PM, xor wrote:
 On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote:
 Encryption is of little value if you may deduce the same
 information by observing packet sizes and timings.
 
 Instead of spawning a discussion whether this aspect is a reason to
 NOT encrypt, you should do the obvious:
 
 Fix that as well. X being broken is not a reason for not fixing Y. 
 Pad the then encrypted packets with random bytes. The fact that
 they are encrypted makes them look like random data already, so the
 padding will not be distinguishable from the rest. Also, add some
 random bias to their timing.

The packet size and timing issue will become less of an issue as the
network grows anyway.

One transaction inserted into a 3 transaction-per-second encrypted
stream is more obvious than the same transaction inserted into a 100
or 1000 TPS stream.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJT+MZWAAoJEMP3uyY4RQ21tDoH/0SPYQcUkYJcuDhTkJCFWdyx
ob3H7ITEcqD0UZ3n3QHdxHfCDlP2srL0EcfjbNceRX5inP47jdoGj7uIkY/NRHQ0
4J2WCIrcu1Bj3ZxXG59PtfUzMjxhMGDMSk5eE+6BjVQILrkxxrqSpVjykfoq5s6Y
EBdT2Pf4djQ5k2fQ2PX1dTt5iCvFh0ufq3McrYsciRzguRwlelw1W34tPBqGSv0n
LScgvqYUTGC7otUdA5K/3WBq6SSo7E13hJxiLKQZMQ4CPpSlsiAhI5fuhl0OBljC
hCtS+eugFmvMICQt0ELds++nnA5WN/Yjx1WIrnLA1EmNiAkS9RSEVMcyab0TtdI=
=0sjO
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/19/2014 03:30 PM, Richard Moore wrote:
 Oh, I see. I misread, thinking you wanted the dev team to have a
 private key and share the public key, similar to alerts. But each
 peer would have a public/private key pair and use something akin to
 ECDH for a symmetric key and transport using a block cipher?
 
 How would you share the public key? If I were a man-in-the-middle,
 I could intercept the public key, generate my own and pass that
 along and then decouple the pipe when the other side shares their
 public key.
 
 Also, you should not ignore your SSH fingerprint, as you exactly
 open yourself to mitm attacks.

http://curvecp.org

If that's not acceptable, even using TLS with self-signed certificates
would be an improvement.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJT83Y1AAoJEMP3uyY4RQ21aqUH/3rGvgz3J6UYY2Qb2qzNoucB
QqIj4fByZncX7Fhx5YK6fc6QoLr4Oqxd+zgbJ3ghrLtAJ7dm61iLmmib8MuDz2K1
kQj8xmZhWuUFI26bjK54RlKoWg46XFKNKcaVub6JmVg9dH8mX86mF746KnR5ZqdX
BuehWoEqcHlY3JkrTgOGpHjT/EGScZQxzJHzsBOfUJuX12lFtzcWzBTZyo5K8fD+
6eub3i6Fc4qn/c788UVFsmHeWV+NCeB1/y94V1+peIPWYhrZO+FVm+xEflG4U81Q
MRejqNjFT8ztT5vRHx1qJsmIgnzT0SXfh+FRt0hdqJizjlmyntMmCXjFmtnIeT8=
=9qWl
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP43 Purpose code for voting pool HD wallets

2014-08-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

We'd like to reserve two purpose codes for the HD multisig structure
that will be used for the Bitcoin wallets used for voting pools, so
we've documented the structure in the form of two BIPs. One is used
for the wallets suitable for storing bulk bitcoin deposits, the other
is used for storing colored coin deposits.

The primary difference is that bulk deposit wallets use cold storage
and are allowed to incur significant administrative overhead, where as
colored coin wallets do not use cold storage because they must be
capable of being generated on the fly.

Two draft information BIPs are attached.

- -- 
Justus Ranvier   | Monetas http://monetas.net/
mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJT84VCAAoJEMP3uyY4RQ21LZcH/RYN5dUc5TjOI6Z72I4aNqDL
cZMzIo1WTK6OHsO2GUo+3L4avf+dCb2om/hDJgoLz/Oh9BMY77vF3UTIPIzGmN9X
2Oeyjg+wJG9z2L/B1f7oo4MX9c2ppUNfp2x5zDaURvME9CLkY7hLCBWp/OxU1HHb
MhLn0ICtpw3FnHddVWFwhvBxcCzJm6t2pBlM8mmTr4t52/08gklY1LVdUW0zmf9W
eFe50Y2KQ+uhVZfAga1wmFwY1pJBUmf6fAVqeK6AGDPkLVHDvN8P+mco+Qks++VZ
mTENKXWAmskGViTjd0pb8EdoSoMsDIa1eRHbpwAbbb2PEoc9pdccgwH6CscgN1I=
=R/HX
-END PGP SIGNATURE-

  BIP: BIP-
  Title:   Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
  Authors: Justus Ranvier <jus...@monetas.net>
   Jimmy Song <ji...@monetas.net>
  Status:  Draft
  Type:Informational
  Created: 2014-08-11


==Abstract==

This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).

This BIP is a particular application of BIP43 and is based on BIP44.

==Motivation==

The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed.

==Path levels==

We define the following 7 levels in BIP32 path:


m / purpose' / (5 color definition levels) / address_index


Apostrophe in the path indicates that BIP32 hardened derivation is used.

Each level has a special meaning, described in the chapters below.

===Purpose===

Purpose is a constant set to TBD (or 0xTBD) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification.

Hardened derivation is used at this level.

===Color Definition===

Index values which can be applied to a BIP32 node are limited to 4 bytes (32 bits).

Since this is not sufficient to identify color definitions without a risk of collision, multiple levels are used.

Color definitions are first shortened to 20 bytes using the Bitcoin hash160 function.

The resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels

Public derivation is used at this level.

===Index===

Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.

Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.

Public derivation is used at this level.

==Compatible wallets==

* [[https://github.com/conformal/btcd|btcd]] is the reference Bitcoin wallet for voting pools.

==Reference==

* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
* [[bip-TBD.mediawiki|BIP44 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]]
* [[http://opentransactions.org/wiki/index.php?title=Voting_Pools|Voting Pools]]

  BIP: BIP-
  Title:   Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
  Authors: Justus Ranvier <jus...@monetas.net>
   Jimmy Song <ji...@monetas.net>
  Status:  Draft
  Type:Informational
  Created: 2014-08-11


==Abstract==

This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).

This BIP is a particular application of BIP43 and is based on BIP44.

==Motivation==

The hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed.

==Path levels==

We define the following 4 levels in BIP32 path:


m / purpose' / coin_type' / series' / address_index


Apostrophe in the path indicates that BIP32 hardened derivation is used.

Each level has a special meaning, described in the chapters below.

===Purpose===

Purpose is a constant set to TBD (or 0xTBD) following the BIP43 reco

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/19/2014 11:38 PM, J Ross Nicoll wrote:
 That's not great, certainly, but how many nodes actually require
 that level of security

All of them.

While the rest of the 'net is busy deprecating HTTP and all other
unencrypted transport methods, why is it(*) even a debate?

Security should be on by default. Make users who don't want it jump
through hoops to turn it off instead of the other way around.


(*) where it is the desirability of blocking passive surveillance,
not the particular algorithm to use.
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJT8+AdAAoJEMP3uyY4RQ21kv8IANDkveCGJX5b5c+waXTHcEf0
MgrGlkUZgZaP+fNNME32MEeQMywkyHohZly1KKYyqf+Qi2YkZ7rFiZj5e16EtGVK
zBQCrvOyMZVv/tWPfRxrZV+jC5dUBPryaCV3XwyK3w8u5WpDhpC1be6uBjY6qtTB
58MzdMBEEwceUwDezAIpGxsr5fKw+by4WyL23HQybSgUSHWh9S9hSp4dY1L8sDdr
atdFOvjiwY7zQe9V4mrtSv2pwmWIfOJE3RBhwSdPBtsMqO0PAnUEmxKYANQjh8qV
W147aQT97DYkWb3TucY+gVbsfKSzvNoiXwvWMpmXT1Kz8wia0vX7MoPBtO6+uOk=
=6tJk
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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] [ANN] Armory 0.92 with Decentralized Multi-sig and Simulfunding

2014-07-31 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2014 09:50 PM, Alan Reiner wrote:
 (though, in the future, we hope to provide an optional service to 
 help synchronize the data between parties)


Before rolling your own service, it might be a good idea to add
Bitmessage integration to provide the P2P communication layer.

Even if you resolved to create such a service without creating any
negative privacy or confidentially side effects, I'd be more inclined
to trust Bitmessage to get that right in the long term, because the
service you'd create isn't your primary product or core competency.


- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJT2ovhAAoJEMP3uyY4RQ21zw4H/3vjcZXP6e0/5IG745PDy/AC
Br1ChlyQjBpU7X9CQfrxDmUUGs7HDrwLjd/SZAV1/PUUXXfE3nDr24hsF8+PlGex
AiZhO7k92xfwRMWxMmcVVt/kuaOldHZUqHDUenT3drJ/bPnV+R3FJ9O6Ougu/YVy
H2BRjpdPGrZx9NP/hE/7evA7rPF8pcshpMBiwq6RiHFdu/+2jcThFZoMIaJsAcif
1vZOzP6vTUKkr3E7tRt5ZQrdb4vvGxX+xMomm8fzPmV3GkpJ/Kyyypx+ovaH74V5
oXXg62XRz4lSziWV5Sp4p/18VjRyUkxwvfXXMt9sW6vNvRDxtJNP8/ZKpkMjO3s=
=ClEd
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/24/2014 09:07 AM, Wladimir wrote:
 My main argument for the split is that full nodes and wallets have 
 completely different usage scenarios:
 
 - A wallet should be online as little as possible, ideally only
 when you do transactions or want to check for them.
 
 - A full node should be online 24/7 or it is virtually useless to
 the network.

I think btcd has done this right.

A wallet is a daemon that runs constantly in the background, just like
the full node.

The GUI (which is distinct from the wallet) runs as little as
possible. Presumably there's no need for a 1:1 relationship between
wallets and GUIs.


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

iQEcBAEBAgAGBQJTqZpVAAoJEMP3uyY4RQ21E48H/0XNYBzR8QZjfku/MeL5IbwL
A56jrlWe2EZTabwfKdGx12L5oeBXe3DOeLsTizqIu0vijcl7qQryU49AjrVe91Rx
OdEi4lmaiXdkM3lWeWUxLoLLHR1B+1f8T18Mrnzo+yasyrywPb+6H79VN5KERdA2
5yHYCZyHXdNoXpzyf38GC2PdYJmAZdrRfAGyC5+OXSwE3XLhpRBrSBh/mrx0ct5M
ghkCKtsmJCJJ6sR2TbFxaj71kPp0J0tp8JVvjVEqC2uB4Ih0NY+79kz8L81TaNmw
ol1o6p7TypIk7QRQ4ES3Fq0ALh2aQ/tX4rc0GC0ed+xLi+dHJ2wGBI37HoyGIyg=
=Nn9X
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

2014-06-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/19/2014 05:11 PM, Kevin wrote:
 Why do you want to punish pools?

It's part of a general trend wherein people look at all the things
that can be accomplished in an economy that has a division of labor*,
and see some misbehavior at the edges, and decide that rather than
fixing the misbehavior we should throw out the entire concept of labor
specialization.

Hating on labor specialization as a concept, rather than simply
finding solutions for specialist misbehavior, was the basis for scrypt
mining, PoS, and MaidSafe.


(*) http://www.econlib.org/library/Essays/rdPncl1.html

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

iQEcBAEBAgAGBQJTox/JAAoJEMP3uyY4RQ216F0IAKo26MEK/IrIlHMw4UYsWBWK
LWWLe4mfUb+I74ZHPzC2ZE7u6Lf6vAeeG/mLe8K/ls1qBJk9ae7bsA+DVvRn8LfW
Ir/seYtCCnLpxhHGbVtYOeWaS+WyOWMKBz1moOTJcgWwPPiL5BLk9SvaLqgy2GDV
fJeniqtkZ96Vzif1DNdQtiLfn9aJRL2Er0EO7VL4ojmaM3Bv6Z6l+e0eLVVh8DKe
u1Sp4UOpqJmVHJq+9EeMhdfmOqNWGUA5wFRiDsWfzUDHLkAlISM+sFFSD0CzO0RK
P5whGxo58bSMigbQYOfoTZqgKQefQeXAqtlnrLOLq9/EOZ/34cJET5Z0S/K/F5E=
=3KMH
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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

2014-06-16 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/16/2014 04:25 PM, Matt Whitlock wrote:
 How can there be any kind of lottery that doesn't involve proof of
 work or proof of stake? Without some resource-limiting factor,
 there is no way to limit the number of lottery tickets any given
 individual could acquire. The very process of Bitcoin mining was
 invented specifically to overcome the Sybil problem, which had
 plagued computer scientists for decades, and now you're proposing a
 system that suffers from the same problem. Or am I wrong about
 this?

If you allow the solution set to include pay-to-play networks, and not
just free P2P networks, then it's easier to find a solution

Imagine every node is competing with its peers in terms of relevancy.
Relevancy is established by delivering newly-seen transactions first.

Each node keeps track of which of its peers send it transactions that
it hadn't seen and forwarded to them yet (making sure that the
transactions do make it into a block) and uses that information to
determine whether or not it should be paying that peer, or if that
peer should be paying it, or if they are equal relevancy and no net
payment is required.

Once any given pair of nodes can establish who, if anyone, should be
paying they could use micropayment channels to handle payments.

Nodes that are well connected, and with high uptimes would end up
being net recipients of payments. Mobile nodes and other low-uptime
nodes would be net payers.

Now that you've established a market for the service of delivering
transaction information, you can rely on price signals to properly
match supply and demand.

People who hate market-based solutions could always run these nodes
and configure them to refuse to pay anyone, and to charge nothing to
their peers, if that's what they wanted.


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

iQEcBAEBAgAGBQJTnyRMAAoJEMP3uyY4RQ21XwgH/RPlhgR63XF9/Sm+z0EBxVtO
0hzDngD0iTO1v5LRmas9P5ZuQ97j8169pui+EJO8clXjV41yEu96jc0BiOQTnfMR
rzPfgeZqfnVNDvIfJnLRMeVCJMiu9Tjdqx83S28Tz9sx/sgy1uw9INX7M7wOIHFR
7GLA16k4g8qcmnX89XXM3Uf7/3fhL2kiN/E59V2n6qYJAnYTUEb+uehclzR+T4v4
93oAF3TjgLU6J0VleDrvgFcyLriGBjOmkTAvmOJQF1H/s4gzHol5kbOb9vqQ7BJX
QQ/mEYHEdCHTxU59FdZ5CmFYZrINHj+mNnu1RorYYF1FLbBDTDpq4zjrJpngayI=
=9qQJ
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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

2014-06-16 Thread Justus Ranvier
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 b...@mattwhitlock.name
Sent: 2014/06/16 - 13:10
To: Mike Hearn m...@plan99.net, Justus Ranvier justusranv...@gmail.com
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes

 On Monday, 16 June 2014, at 7:59 pm, Mike Hearn wrote:
 
  This is a cool idea, but doesn't it generate some perverse incentives? If
  I'm running a full node and I want to pay CheapAir for some plane tickets,
  I'll want to pay in the greatest number of individual transactions possible

 Peers can calculate rewards based on number of inputs or total kb used:
 you're paying for kilobytes with either coin age or fees no matter what. So
 I think in practice it's not a big deal.

 So effectively, if you pay for your bandwidth/storage usage via fees, then 
 the reward system is constrained by proof of burn, and if you pay for your 
 usage via coin age, then the reward system is constrained by proof of stake.

 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.




signature.asc
Description: PGP/MIME digital signature
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-06-16 Thread Justus Ranvier
-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
 b...@mattwhitlock.name
 Now another concern: won't this proposal increase the likelihood
 of a network split? The free-market capitalist nodes will want to
 charge their peers and will kick and ban peers that don't pay up
 (and will pay their peers to avoid being kicked and banned
 themselves), whereas the socialist nodes will want all of their
 peers to feed them transactions out of the goodness of their
 hearts and will thus necessarily be relegated to connecting only
 to other altrustic peers. Thus, the network will comprise two
 incompatible ideological camps, whose nodes won't interconnect.

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.

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.

Crowdfunded free bridges, assurance contracts, etc are all other ways
to let people get into the network with no upfront cost.


- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJTn1mwAAoJEMP3uyY4RQ21ePwIALpMV/GDpAyD4SeL6hWi32vQ
197YD1LPuLWrEbUs/+gl1Sk2gIsWWlq/o86KcP7Cn4fZdBAKEiF5RpQ6iPsO2+bj
JR0W/EbgUyzIhYaxFysCzQ1HPzQx+0a2vHn/6FsB7YMha8gvxviF7InDEwcfxbok
o0QS5SeYWryp5mH7IokC6fLYsAPmiueugPVRSD/l8IRFYWVFS9nB+XAR1PWAdYSQ
Xyzu9oyPwlKAjYKxl4XHYB4DofacS89DpWMVbWHviYiZ7UufmzMgwPtfMCsQAxSb
q3OMAkcSGJZL8pcy9/9NWpOGAHY2DRtGtu8oSqXcBSW/IQCubmUNmzopt8O/H74=
=9hrW
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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] About the small number of bitcoin nodes

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/19/2014 09:11 AM, Jeff Garzik wrote:
 Meh.  I like example configs, perhaps tuned by the distro.  If the 
 distro (_not_ Bitcoin Core upstream) chooses to install a
 bitcoin.conf in the proper location, that's up to them.
 
 
 - bitcoind and Bitcoin Core should be in Linux repos:
 
 Agreed with conditions: 1) The distro MUST let bitcoin devs dictate
 which dependent libs are shipped with / built statically into the
 bitcoin binaries/libs. 2) The distro MUST permit fresh updates even
 to older stable distros. 2) The maintainer(s) MUST be active, and
 follow bitcoin development, release status, etc. on a near-daily
 basis, be able to respond quickly if security issues arise, etc.

If we're talking about making bitcoind behave like a proper daemon,
then syslog support should be on the list.

Also, the option to store things in FHS-compliant directories (not
somewhere/.bitcoin)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTebHTAAoJEMP3uyY4RQ2170IIAMDcx5rj/ZlCTJTOJ2sFttFM
miK9t7oewJ73UpgvFniCUngfjk9Tt5knmskQYEMQ5C9Do/P3Deh1gF6MBBuuai5G
kDNDv51zMEqhwGcqGrPYFMV3NEnBEjullTMgJFvKJf1kZRo7uplwp+eUhILjgSY5
mZjLIUK8iKDNn+Pi8/2UetAvyaRibHAsAnkJnEeOoKAhxUbtzjgZsj08loCCmJrs
RleOTLgArdc33e1bwTTwsS9DDvF18RNTACglsc75Oz0ohHyc5U1A1hBfaRuyu6Fv
8BK+0KPg/zdBCnM1m3aueVukg9p3kIfB2VUVFBHBTo4CPMi91k6oldbfRHy8dXw=
=SjxO
-END PGP SIGNATURE-

--
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] Paper Currency

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/19/2014 02:21 PM, Mike Hearn wrote:
 Submitted with humility and some fear of getting laughed out of
 here...
 
 
 Off topic aside, a bunch of us have lately started to think about
 the atmosphere on this list and how to improve it. Nobody should
 have to fear getting flamed or laughed at for proposing ideas, even
 if they turn out to be silly ones. Gavin talked about this in his
 Bitcoin 2014 keynote and asked for someone to solve the forum
 trolling problem.

You and Gavin could do a lot better by working on a Bitcoin social
contract - a promise of what features will *never* be added (or taken
away) from Bitcoin, because despite what you say it's not acceptable
to propose anything at all.

Maybe start with things like how the Bitcoin protocol will never be
changed to allow for confiscation of funds, regardless of who might
demand such a feature.

You are willing to promise all users of Bitcoin that you'll never
propose to steal their coins, aren't you?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTekt4AAoJEMP3uyY4RQ214QgIAM3DdtAUTG63FG/r9Yg4dWb+
TXWoXRd9AYDg/SAirF6qV+r6K0vohMv8UJhCpX0OnNSOfxKcgVt2CnG8i3iWBRu1
V+LRFmaHkJ+vJLaR2lEdFKMc2DVuZUIXGH6jEgVo/dzFJGZ/GcoUwTBrZztjCHDy
WbpuuIfV2ya1bqkhMOn78pDgkDfXBD7qWQsz0MTzSkPitT0AnUEPxCl3KBWizkdH
shGwE4YNhRSX+yTBaFHVMqFb9LzExEWgIgkgghddKfJzj9REcw6wiotD3DvYaDl7
LPegCttg0vdG4YTVlTH0iMwFYC3qrw/Ab43uqLjTy7aWyFjhsPtKceTE3KpGDrk=
=dRhy
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/19/2014 09:41 PM, Gavin Andresen wrote:
 Now I'm really confused.
 
 Why would Mike or I have the authority to write a social contract
 to promise anything about future-Bitcoin?

YOU can make promises about YOUR future behavior. So can everyone else.

The rest of the community can keep track of which developers will and
will not make promises about what changes they will and will not
attempt to implement in Bitcoin, and they can use that information to
make informed decisions about which software they will choose to support.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTemMNAAoJEMP3uyY4RQ21KJMH/1MbnPxZ42sjVjEiGSQBkGfE
E3jt8aAf2DTza8xtybSmT/pHVhx/VUT4UNj9oBZayqJ1eUNr6YMgGCP8J+DxBtN+
mYH4lTnCiR4+hjO9aux0AWFV+hfZSq7A41QH6wymLa5CyywOtc+i7i3qU5ZGrbtX
9yBrQpFilvMIlrAOBDlXUwb06FDK17ZHHX4V5sI8PSRYJvoiWCrk12Vqj1Z95UOy
ayzWGwbO30ky6lGirBXfpu2e2WJADE9sc43ecNCDplUMR4D4n9jwAUldEiMSBKg2
pwUNcfj1gaKkscj4QmGKMbq6yug+lrSa8qq/jFsbQq+2pqT4VjlQlrN52wz7Yeg=
=Jafe
-END PGP SIGNATURE-

--
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] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/19/2014 10:06 PM, Mike Hearn wrote:
 Sorry. I will never agree to the concept of a relevant idea so
 dangerous it cannot be discussed. That's medieval thinking. If you
 would like to create a parallel development forum where people have
 to swear an oath not to think bad thoughts, go right ahead and do
 so.
 
 But I'm glad to see you correctly identified yourself as one of the
 people causing problems on this list. Your vicious attacks are one
 of the reasons we're now seeing threads that start with I hope I
 don't get flamed or laughed at for this idea but  which is
 totally unacceptable. I would prefer you just unsubscribe, in the
 hope we get a second chance from some of the potential developers
 we've lost.
 

I'm glad to see you correctly identified yourself as well.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTemXNAAoJEMP3uyY4RQ21KNUH/12vTPOPNjQQIunTkNCSqV6P
hub7mrW/hS4NSlK7P3Laq5qj+qB9ou/uIRCPP6uIhk6scicbukn31nw1p/er0YoQ
XGFE+SmF+Z5Ysz/5uA1OP9VdjBKggbI6rFVZKbt5DwrFK0gCDMtgcxO2y6CFGR+U
mFhD9ORf/NdAozFanXSEk81p5OfZqhhnxaPPpPnwQeojtLwE20reLrEcCKy6XMEs
Mtfan+qgPJYTmWiWmDHsrFsz+5HwpkR5giDf4hzW5J1F8Vj+LTPXjGz9Txldk89t
0dRmYFAtE74QgXsIRvWny9ho4YL/Nn+WHf0Qf3HKh31wrzSea0KFKpPaa32xpKA=
=jIov
-END PGP SIGNATURE-

--
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] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/19/2014 11:07 PM, Gregory Maxwell wrote:
 I promise that if bad people show up with a sufficient pointy gun
 that I'll do whatever they tell me to do. I'll make bad proposals,
 submit backdoors, and argue with querulous folks on mailing lists,
 diverting them from real development and review work, all as
 commanded. Maybe I'll try to sneak out a warning of some kind,
 maybe... but with my life or my families or friends lives on the
 line— probably not.
 
 ... and I think that anyone who tells you otherwise probably just 
 hasn't really thought it through.  So what is the point of
 commitments like that?  People change, people go crazy, people are
 coerced. Crap happens, justifications are made, life goes on— or so
 we hope.

I presume you're familiar with the concept of a warrant canary, so
presumably you'd also see why public statements such as I was
discussing would be similarly useful.

Social contracts make it more difficult to hide coercion, which serves
no one except the attackers.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTenU+AAoJEMP3uyY4RQ21P1UH/2fvYa7Hfv53eXA0k9appRVI
8KWpH2D95zCo/s6kIeKZtmEzhFWFkKxOHwiHZbD5JokG+U/vUeR8p+SxF1/xUc1X
1tTNAjfAALz0/KzjPKmlMQCqM5vT4yumHsDusqPuzbPFnJnwFufrAW9vWu9OJacs
JEv4yoRGNZhR+eM8hCUkDfTtj7D8J3gMYyYds7K4kppiHN2UPRgZT6TCVyCRlThe
8w9MzYoTAf1WXPmzvSfPhzKMfNV9Y+tjt6ZV+KyLG1ZGLw2EDCxJR1O23QQE8IfK
53I2RgeFnvcdceoExSfYJj+kNpbPQ/WDVszswO5esoMWJ/E3j5PCBsLdGt+8e7I=
=BysA
-END PGP SIGNATURE-

--
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] Coinbase reallocation to discourage Finney attacks

2014-04-29 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/29/2014 02:13 PM, Mike Hearn wrote:
 I do think we need to move beyond this idea of Bitcoin being some
 kind of elegant embodiment of natural mathematical law. It just
 ain't so.
 

I think everybody understands that Bitcoin has a positive net present
value exactly because it, unlike every other digital currency which
came before, does not include a feature that allows for balances to be
confiscated. Implementing any such feature, to any degree at all,
would render Bitcoin completely valueless.

There are two possibilities here:

If you understand this, then your proposal is a malicious attempt to
undermine Bitcoin.

If you don't understand this then you suffer from a very serious case
of economic illiteracy, a case so bad that your continued
participation in Bitcoin represents a clear and present danger to all
Bitcoin users. If you can't even get the easy questions right, then
god help us all if you're ever faced with a difficult one.

I don't have enough evidence to distinguish between the incompetence
hypothesis and the malice hypothesis, but it doesn't matter.
Regardless of your abilities or motives your proposal is unacceptable.
If you want a currency where miners can vote to steal from other
miners then implement it in Hearncoin and leave Bitcoin alone.


- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTX/2dAAoJECoisBQbQ4v0jAoH/R1oNZ1tVp6DJ5BuPg0ZTav0
Dvzq8EfX/uRbRgmxotCHMwY6FJCoXqJTLyOnl2p670t7l5ZXqd91MdKKP2z7jYPY
GsVbqfGreF0dWKCd0mKTG5DM8pxndNWteGIsw9/sYvY/3p2Vopzp6N7fpl8TEf6p
2nyIzEqTD4aK5QkhM+sNnP1Cyh/l5AjJTES23GqSQIMG6vzLgqE8kyze+ANFVg1U
yka6bz4DX7DO7meyJyyOFaMJu6mgY+m6dSVaR7j/QmQMu22SwlSiPgqe6iO//os3
zcmwe/x4+5CmqJOO/PL5Or28iw/Qdf6vNePiaEIFtBzoKnHBhS2nAtL6jnOL928=
=4yIu
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/24/2014 03:37 PM, Jorge Timón wrote:


The 21 million bitcoin limit is not important because of its exact
value, nor is it important because Satoshi picked it.

The 21 million limit is important because users hold bitcoin based on
the promise that the block reward will never be adjusted ex post
facto. The behavior users are relying on is The bitcoins you hold are
forever a calculable fraction of all the bitcoins that will ever be
issued.

That's what bitcoin holders agreed to, and that's what can never be
changed.

The fact that the number is arbitrary is not relevant. We can agree to
meet for lunch at some arbitrarily chosen time, and the fact that the
time was chosen arbitrary in no way means that one party arbitrarily
choosing not to show up doesn't break the agreement.

- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTWUTWAAoJECoisBQbQ4v0JiwIALQtf4GrNaIdEidJr+f3z8G3
smDgU5xXhN4+1Eo5xU/ZmQy03tU5E00/PRiMTHz1RNXeO+w/iu4PlAJN7pk5oy75
QzDtaCzDjKMCN+1PCQ5VNCL04ws8JifU6QLxSgXgsShBnv19FlxiejgvjNWg+Lzc
uHxyP0PlvfF5BWTiEV68KYcfQPbamOH7Vb8v4tQ4/j/ioA7mYso+Q0jX0Y4ae1FN
XNs4KnTsIFTsXWzBIYFlFPwQ5d+mdG84W7FpmwwcXaRWQxMwdJq8QjlUuFng439B
6OgQqtq4wmvwoPjKS5nOesfdrdH9Scx2zg6uwhaY0zKMtPW/CEzzLFUfq+cZ6q0=
=r+t0
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/23/2014 07:55 AM, Mike Hearn wrote:

 2. Miners can vote to reallocate the coinbase value of bad blocks
 before they mature. If a majority of blocks leading up to maturity
 vote for reallocation, the value goes into a pot that subsequent
 blocks are allowed to claim for themselves. Thus there is no risk
 to voting no on a block, the work done by the Finney attacker is
 not wasted, and users do not have to suffer through huge reorgs.

If enough miners don't like a block that has been mined, they can all
work to orphan it without any change to the protocol whatsoever.

Why are proposing this a change to the network that allows miners to
vote to disregard output scripts, instead of creating an out of band
network via which miners can coordinate actions using the capabilities
the protocol already allows?

Once you've changed the network such that it is no longer a machine
that faithfully processes scripts, and instead is a machine via which
a set of controllers can decide which valid scripts will be honored
and which ones will not, what will be the next proposed condition
under which the miners can confiscate and redistribute balances?

- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTV9OUAAoJECoisBQbQ4v0XE8H+QGcOc3JiYsS2/xoR8SqpyEx
gDChDFvhaao9qMPhfxBG0bso+4ITZ5c3mJawkqdBm3ZZPeygt1fLqvxe4c1AWocH
YCf9CyZJlm8KsDJOqorja5o/6oXjH5xiGgVi042Jhb9wj/aGNPFvL9X6DGhEeFKQ
uXFN4wTSPViEOryVqo3vEFh3md9Y1AIqcvc/b5M+EAtvaAD33/ALnzY9CNKymQZE
o0JGLEfwamKkZ+QA0mTfeDheJe9kj0KOQhXqOG/x3NlKCFVpmGz3daWZHJCFMDb4
+RmDwoxOKvXxgveXu9w4d3bc3SQZ75hygmeMvVQwZggia31wqrHtsWLqIiFhVnU=
=hpdg
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/23/2014 03:07 PM, Mike Hearn wrote:
 On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier
 justusranv...@gmail.comwrote:
 
 If enough miners don't like a block that has been mined, they can
 all work to orphan it without any change to the protocol
 whatsoever.
 
 
 As was already pointed out, yes. However this requires them to
 immediate establish a majority consensus and be absolutely sure it
 really is the majority. You suggest an out of band mechanism for
 that, but why is this better than using the actual consensus
 mechanism you're trying to measure?
 
 
 Once you've changed the network such that it is no longer a
 machine that faithfully processes scripts
 
 
 Bitcoin imposes far more rules than just execution of the
 scripting language, many of which are entirely arbitrary and the
 result of (controversial) human judgement, like the inflation
 schedule. You can't claim Bitcoin implements only some kind of
 natural law.
 

I've formulated my replies to you and this proposal in a more public
venue, where such discussions of existential changes to the protocol
more rightfully belong:

http://bitcoinism.blogspot.com/2014/04/dirty-deals-in-smoke-filled-rooms.html

- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTV/Y0AAoJECoisBQbQ4v08NcH/RfkaBAcS5eAKmwePqFuqIUN
xJKyIWo+tyY1vPYgArCVNsYr3YM8Wc5fkpqLNxCaM7S0/UmO8YaOdiD7XJyl7bF9
xAveyRt1mfHhx9x6hnPLYbe8WKqtjssSt6MglN8OXtf0EDO+eIxPj6Ya8OZ5YJrL
N8SMHaDs2J+qy3Qfec9keE5dyhYLNRC6PjYPVvrRAyqFSjt/8r4Z2a4r0oqvv3Yt
mYU1Tx+WoXMKXWY/Dwql1NLbuspZsOhPx/ncROZ5KVryCdrcW/GEIEQ6P0AIdHvT
TKYJzh1bdRDYDmVS5z8nUG6waxJwuWPStQo7UYdg26daRUw5qPzjO9SMLLFZPCU=
=OOck
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/23/2014 05:47 PM, Gavin Andresen wrote:
 And why do you think your blog is more public than this open,
 publicly archived mailing list???
 

Non-developers are more comfortable using social media tools. Blog
posts can be shared, Tweeted, and commented upon using nothing more
than a web browser.

The barrier to participation on a mailing list is higher, and the
visibility is lower.

- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTV/0yAAoJECoisBQbQ4v0Fm8H/j0fG7s/iEQUDlV2+5mxeiBO
eoPY2gwuDSTjXc74/3olPHrL/BTGtGg90zwFmlwruUJOaW2m3xvbTD78S8e3HmCC
fqqFKQLg+gOQYud2oiHVNW6H++QqKgSJXu4Lr87ZTkpiRGTgr5PWyhe+4sLeXxam
InqcFmtTHiUMKlmiPj/FUaPHxYT+n+FaPuiZRUYt0Wfxcc9b1n6gEpV7r36Wh8gl
e3rMeDwTfsj/0R4+E+oFEgPl7XBGIJWAf4Nzebuog4ABlqzm4B/RlclZ/5N3W2zZ
6ym6dGpFwN+RuDY2/S2kah6dAeKyk2mAsAChoSOj+vfhCW9wKzclVyM2FNV6lwE=
=djWj
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/23/2014 06:37 PM, Mike Hearn wrote:
 If you want to try and argue that the development list is the wrong
 place to discuss development, please do so on another thread (or
 your blog). Let's keep this thread for discussion of the original
 proposal - ideally, discussed with the dryness that a topic as
 nerdy as distributed consensus algorithms deserves ;)
 

Is that what you say to yourself to quiet your conscience at night
(assuming you're one of the non-sociopathic humans who does indeed
have one)? It's just a nerdy distributed consensus problem?

The things you're talking about fucking around with have real life
implications for quite a few people and your casual dismissal of this
is precisely why I responded in the way that I did.

What you're doing is reckless endangerment and you're not got to get
away with brushing it off as a mere technical detail.

Sunlight is the best disinfectant, and this episode is demonstrating
to the world exactly how averse you are do that kind of transparency.

- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd
3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1
V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY
QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N
aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU
ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ=
=L5nX
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/09/2014 06:19 PM, Wladimir wrote:
 If no one wants to volunteer resources to support the network
 anymore, we'll have failed.

If the security of the network depends on a broken incentive model,
then fix the design of the network so that economics works for you
instead of against you.



- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTRZLiAAoJECoisBQbQ4v0RRMIAKL84ju4b9XAls9sOxQGrLMr
xifQDhThCQKC4/qkOmGU8zseIdKRgXEq4auMF9/0BlgoSxsBcKynlRH2fFtYY7ol
sdjCy/5dk+MBu3K1GCvNn/cuGkpIJJxrom/9riSiaPtivE5ncl7cyW5hFqf2MzRd
dF6q937ocgBd8d2VuOQleQ9N5gue1+du77soxfp8oY7dXNdwk5ZrngeYxz1umsjQ
lBAI/3JYkKVhU5Rte3deJcMHe6xA+neIzvcfWbOZYrkdwWE+jLSKnDkDkCOXJnuP
vOI8CAteaFctV2mfgXX2CmNDWVeFsyCwoQwbnCmuE/uiM5y235PcTrsyr6U+Zzs=
=oQPK
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/09/2014 06:50 PM, Gregory Maxwell wrote:
 Who says anything about a broken incentive model. You've made past 
 claims about resource requirements that I think made no sense and
 then failed to defend them when they were challenge.

Anyone reading the archives of the list will see about triple the
number of people independently confirming the resource usage problem
than they will see denying it, so I'm not particularly worried.


- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTRZhsAAoJECoisBQbQ4v0iD8H/A1RZyLJN6f+zt5x78CFgRdp
zqZua3NBwUN2L9mI/PU1NADtxoXgkq49XusHRc+bjLu17VxGMUOsmB+AeK3VU4sN
BVC1qIcWCa+OPMkgnMFrdydz4OGxX5xiJoCNsqveZIEYc8nQoCDfsn/fwqL50/Ct
NfmPzh/cW7uUZ+h2bBgduGD3fzpQBlnnswAbHHX3FbBh9MvcaCfROeXXqUCedWj9
H2qVCNWTkIFJksJkqyF3f+KfedOTIyUwflx/0niBvzXcP9w4oK+WpBApHACWxiSA
H3KHYNF0s2/fs+mIkabPLRX1PIUk15ln29FapoDvlHW9jzDE92x6JFnMppI4rEs=
=ILks
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/2014 05:16 PM, Gregory Maxwell wrote:
 When I read resource requirements of a full node are moving
 beyond I didn't extract from that that there are implementation
 issues that need to be improved to make it work better for low
 resource users due to the word requirements.

In order to prevent future confusion: whenever I talk about
requirements (or generally use the present tense) , I'm talking about
reality as it currently exists.

If I ever decide to talk about hypothetical future requirements in
some imaginary world of Platonic forms, as opposed to the requirements
imposed by the software that's actually available for casual users to
download today, I'll mention that specifically.

- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTQuRkAAoJECoisBQbQ4v07zUH/2wNQ7+0211+wm5oQP/ABHg7
kQVeQcRz8/BhOp3hzv6HiQ9Oaekfz7QhClbJYPUPE3aR2gxGoCgT6B1G2N75q0pG
piGVgCeogaBA3Ny91sOPRMv92cGWpbTeyO+rhIIIlYWPiZobTaYttYYm1zF6oc6K
CdYzCW9X12/NIXxEkbPnAFJ01Uty0HKccTP+9jex7+gobzl2yCo4MyywwtWF9XEk
K9aZ3+3i+12+F4nDMAAimD02SV6dI8GMpahMf4kNXn0CcMefC9A28FdhhApPh7Nx
1phQnMPZMPdYt0aHgjgzt4N+SR/1EOUZaoqk9ccyXh+khBR84tiUEo6NuOIfTGM=
=Mr12
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/2014 05:40 PM, Mike Hearn wrote:
 The primary resources it needs are disk space and bandwidth, after
 an intensive initial day or two of building the database.

Check out the kind of hardware causal users are running these days.

The bottleneck is not bulk disk space, but rather IOPS.

Most users don't have spare machines to dedicate to the task of
running a full node, nor is it acceptable for them to not be able to
use their device for other tasks while the node is bootstrapping.

- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTQuVNAAoJECoisBQbQ4v004EIAMPpQLrVlzCoGjcgALyHV4xK
6JDnlCHXTR72mTlKwcbD6Dpyr/Dl6tcXtdbQi0m3gsbOcAZI/eHtrswgunaq7c1y
mTOM2klPE4M8+B/4Ecp+2iK2UM/swlL3z8ryx/HPhgOZ+Rr7AENe3WUYOKiVNE4O
YQP1x9c0l09ma3ZU0sLmz2VTyqVzI7yV3mu/+HKcwYnqNrK9i/c8MRhOLdZ0gcUL
b2PtjjCdnSNLelZvwSLcqqR5+1oejAVwgt1Aq4RGyZzD9DVdCXUR9c9HWLAs0MEU
WPU5gU03YmrE5mkgGHRO3YnDbky0gdAGEw2Phzqd2upud4CLqdhEqA4v6/tQhpk=
=BVpU
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Okay, time to bring up bitcoin/bitcoin

2014-04-02 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/02/2014 03:41 PM, Laszlo Hanyecz wrote:
 www.githubb.com resolves to addresses announced by AS53665
 
 Some basic info about AS53665 can be seen at
 http://bgp.he.net/AS53665 They probably have a dedi or VPS at
 Cogent.  They didn't even create an IRR record for their AS or
 their only route.
 
 Let's see what google has to say about malware from AS53665 (TL;DR
 - it's a malware site) 
 http://www.google.com/safebrowsing/diagnostic?site=AS:53665

Be careful out there.

https://www.techdirt.com/articles/20140124/10564825981/nsa-interception-action-tor-developers-computer-gets-mysteriously-re-routed-to-virginia.shtml


- -- 
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)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTPDMBAAoJECoisBQbQ4v0SrgIAJIHBmYbWCmZhQqt0trfrjDk
GT5jQmQwo7yUzhgan/3Bx0BFD9t0EL65iK6e4RZei5EK7tXvWeaAYztQsfuEybxc
+sm6B5w1497Tdj1PwqrfS/OITasY7+CJKLurYn0e/01sZp2STMR0d/rjYxtgUAnI
9hf6FOi/KbXRj7AUoUm3Ut1J9xxIv3GgP3oZVtWNBdWFgk0KcoNVtMxZMARz1OUd
OnUCQnyLLfNVT79HdQiHmYMDkPXttLNS4VMfryx9gccCZfJK1ES58YpZA31EFEe7
zsWOYRV4H124upD4fog2KBASyQj5e7dHjqWSjxcitX6kt8Sbf7WzSC2lKwaJPZ0=
=Awk+
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 70 and OP_RETURN

2014-03-29 Thread Justus Ranvier
On 03/29/2014 01:30 PM, Mike Hearn wrote:
 They would just encode the OP_RETURN script into an Output structure. I'm
 not sure about the question - you seem to give the answer yourself in the
 first paragraph?
 

I guess what I was asking is whether or not all BIP70 compatible clients
will support the creation of all standard output types, including
OP_RETURN outputs.

-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k


0x1B438BF4.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Best practices for dust remining

2014-03-29 Thread Justus Ranvier
Suppose am m-of-n multisig wallet receives a bunch of dust deposits due
to somebody advertising the Olympics, or any other reason, and the users
of the wallet don't want the few satoshis involved.

What is the best way to allow all these dust outputs to be re-mined in
order to clean up the utxo set, keeping in mind the scripts may include
large values of n?

-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k


0x1B438BF4.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Dust recycling

2014-03-29 Thread Justus Ranvier
On 03/29/2014 07:55 PM, Goss, Brian C., M.D. wrote:
 Could you collect the dust into a transaction with no outputs (thus making it 
 all tx fees) or putting in to an anyone can spend tx?
 
 The large number of signatures (for large n) would make the tx size 
 large...but, if enough dust were out there, it might be worth propagating to 
 a pools hash power. 

What would make it easier is if there was a standard output type for
sending the entire transaction to miner fees, that would make even large
transactions propagate that would normally be dropped by fee/kB rules.

-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k


0x1B438BF4.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Dust recycling

2014-03-29 Thread Justus Ranvier
On 03/29/2014 08:05 PM, Gregory Maxwell wrote:
 Use dust-b-gone and make it someone elses problem to get it relayed. :)
 

That's a sub-optimal solution, as it introduces a third party. What if
his server goes down?

An universal solution is preferable.

-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k


0x1B438BF4.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP 70 and OP_RETURN

2014-03-28 Thread Justus Ranvier
The description of the Output message states that the payment request
can specify any standard TxOut script, and that OP_RETURN is a standard
transaction type that would imply the ability to specify OP_RETURN
outputs in BIP 70 payment requests.

If the creator of a payment request wanted the sender to include a small
amount of data as an OP_RETURN output, how would they specify this?

-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k


0x1B438BF4.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

2014-02-28 Thread Justus Ranvier
On 02/28/2014 07:25 PM, Mark Friedenbach wrote:
 Transaction fees are a DoS mitigating cost to the person making the
 transaction, but they are generally not paid to the people who
 actually incur costs in validating the blockchain. Actual transaction
 processing costs are an externality that is completely unpaid for.

What that means is the network layer is broken and needs to be fixed.

Bitcoin is the blockchain, not the P2P network. If the existing network
is not incentive compatible, then that's the root cause which should be
addressed.

There's no reason to enshrine the broken behavior and use it as a
roadblock to stop progress.


-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k


0x1B438BF4.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Framework for modular input selection policy for Bitcoin wallets

2014-02-10 Thread Justus Ranvier
One of the areas that isn't as well developed as it could be in terms of
wallet design is fine-grained control over input selection policy.

Coin control is great when a human is manually crafting transactions,
but that's not really a very scalable solution.

The attached image is a possible way to stack different independent
selection algorithms. If wallets implemented something like this, it
would be easy for other programs to implement new application-specific
algorithms that would not need to completely reinvent the wheel.

As an example, voting pools in Open-Transactions will implement cold
storage in a FIFO manner, meaning that UTXOs will be clustered into
groups which should be consumed in a specific sequence. Within that
constraint, however, they still want to minimize transaction size.

If wallets were designed to make selection policy modular, they'd only
need to implement their FIFO algorithm and stack it in before the
default algorithm. Surely this capability would be useful to other
projects as well.

It would also allow people who want to prioritize privacy over
transaction cost to easily modify the behavior of their clients and
would make it easier to incorporate new tx construction algorithms like
CoinJoin.

Link to the image in case attachment is stripped:
http://i.imgur.com/Fkkq7pI.png
-- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k



0x1B438BF4.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development