On Mar 27, 2015, at 8:16 AM, Matt Whitlock b...@mattwhitlock.name wrote:
Isn't the goal of this exercise to ensure more full nodes on the network?
Basically we're talking about a form of Sybil defense and better quantifying
true blockchain resiliency by proof of storage.
In this case the
On Mon, 16 Mar 2015 09:29:03 -0700, Sergio Lerner
sergioler...@certimix.com wrote:
I proposed a (what I think) is better protocol for Proof of Storage that
I call Proof of Local storage here
https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/
Thanks so much for
traffic
- This is probably pretty expensive to run? Alex suggests that the most
expensive server at the company hosting is 299€/mo with 50TB of traffic
--
Jeremy Rubin
--
Infragistics Professional
Build stunning WinForms apps
Credit to Anatole Shaw for discovering.
On Sun, Jul 27, 2014 at 10:12 PM, Jeremy jlru...@mit.edu wrote:
Hey,
There is a potential network exploit going on. In the last three days, a
node (unnamed) came online and is now processing the most traffic out of
any tor node -- and it is mostly
a=(1 2 0), b=a-1, a | 3 | b
eval
On Thu, Jul 17, 2014 at 12:52 AM, Jeff Garzik jgar...@bitpay.com wrote:
On Wed, Jul 16, 2014 at 1:56 PM, Jeremy jlru...@mit.edu wrote:
Right now, this could be expressed multiple ways (ie, using an op_dup if
then else chain) , but all would incur
.
On Thu, Jul 17, 2014 at 1:59 AM, Jeremy jlru...@mit.edu wrote:
Additional costs would be in terms of A) chance of user error/application
error -- proposed method is much simpler, as well as extra bytes for
control
flow ( 4 per script if I am counting right).
The costs on a normal
allows
for a 500 byte script, only one of the 500 byte scripts has to be
permanently stored on blockchain).
Looking forward to your feedback -- the idea is a bit preliminary, but I
think it could be exciting.
Best,
Jeremy
--
Jeremy Rubin
Payment Protocol would probably be the communication format for any new
meta-data.
What's the likelihood of something like this every making it on the
blockchain?
--
Want fast and easy access to all the code in your
and signed by X509Certificates.certifcate private key. No extended_certs required -- I'm thinking something like;message PaymentRequest { // new fieldoptional bytes extended_properties = 6;optional bytes extended_properties_sig = 7;}Tha
[] and hash.
- SHA1 is retiring, any particular reason to even have it in there at all?
- Should there any way for the end-user to see details like the pki_type
and the certificate chain, like browser do?
Thanks,
Jeremy
We currently have subtle positive feedback of a signed payment request in
the form of the green background. Unsigned requests simply show up without
the green background, as well as requests which provide a certificate but
have a missing or invalid signature.
There's a open bug (#3628) and
On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir laa...@gmail.com wrote:Such a thing would be interesting for a future BIP standard. I see one problem here: for an unsigned payment request there isn't really an "origin". Browser URI handlers don't send the referrer either.Yeah, good point. If you
?) but again in this case, you would want to 'do what miners would do' if you couldThanks,Jeremy--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc
pushdata, = MAX_OP_RETURN_RELAY bytes
if (opcode1 = OP_PUSHDATA1 || vch1.size() MAX_OP_RETURN_RELAY)
break;
}
Thanks,
Jeremy
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor
Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions.
-Allen
One possible work-around to get back trusted transaction chaining
Relocating this conversation to the dev list. Feedback / continued
discussion welcome.
https://github.com/bitcoin/bitcoin/issues/3624
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the
Well the point of the Merkle tree is that if I all you have is the top,
and all I give you is a leaf node and the siblings of all parents of that
leaf, then by simply hashing you can check if the node was actually
present in the tree.
The only reason this works is because it's hard for an
slightly improving
Peter's original proposal of providing 'Q' to the searcher, but if you
want repudiation, not as good as Adam's solution.
Perfunctory disclaimer... Hopefully this is close to correct, but please
don't anyone actually try to implement this!
Thanks,
Jeremy
Please note, responding to Pieter and Chuck concurrently.
On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille
pieter.wui...@gmail.com wrote:
Currently, with the specification and implementation in Bitcoin Core,
if a merchant wants to use the refund or memo feature, they need to
provide an
On Jan 27, 2014, at 9:39 AM, Andreas Schildbach andr...@schildbach.de wrote:
On 01/27/2014 06:11 PM, Jeremy Spilman wrote:
SCAN TO PAY
For scan-to-pay, the current landscape looks different. I assume at
least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
into a QR-code
I think we need to provide users with better options than that.
Perfect privacy without extraordinary computational overhead today means
downloading everything. But we could provide better tools to *shift* bandwidth
requirements rather than try to reduce them.
I've been thinking
On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell gmaxw...@gmail.com
wrote:
I'd point out that regardless of how long the desired prefix is, the
encoded prefix should probably always be constant length in all
reusable addresses.
I might be misunderstanding, but I think prefix length must
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner etothe...@gmail.com wrote:
Isn't there a much faster asymmetric scheme that we can use? I've heard
people talk about ed25519, though I'm not sure it can be used for encryption.
Doing ECDH with our curve is within a factor of ~2 of the fastest
I hear you, and I really don't care that much what it's called, as much as,
does it work and how!
I might even try to enter in a reusable address in blockchain.info, which
won't work, and I'll just figure
must be some new unsupported thing and move on with my life.
Regardless of what it's
Might I propose "reusable address".I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'.It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly
On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back a...@cypherspace.org wrote:
I was meaning to comment on the SPV privacy properties.
For full-node use these unlinkable static addresses have quite nice
properties. It also nicely solves the problem of having to educate users
and wallet authors to
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd p...@petertodd.org wrote:
On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping
one of the pubKeys in the OP-RETURN, to prevent a malicious sender from
.
The multiplication by 'G' that you mention is part of my EC.PointAdd...
I should probably just publish all my code as MIT and be done with it ;-)
Thanks,
Jeremy
public static byte[] PointAdd(byte[] point, byte[] scalar, bool compressed
= true)
{
var point1 = new OpenSSL.Crypto.EC.Point(EcGroup, point
On Mon, 13 Jan 2014 03:18:28 -0800, Mike Hearn m...@plan99.net wrote:Cool!On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman jer...@taplink.co wrote:
I spent 1BTC on TestNet to a stealth address...
TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c... but can you redeem
to bitcoind via RPC.
Thanks,
Jeremy
[1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols
http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf
[2] - Validation of Elliptic Curve Public Keys
http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf
Thanks Peter for the paper!
I'm just going to restate your 'simple explanation' to make sure I got
it...
The payee publishes a public key of theirs, which will be a long-standing
identifier, public key = 'Q', corresponding private key = 'd'.
To pay them, payee generate a keypair, private
2) Common prefixes: Generate addresses such that for a given wallet they
all share a fixed prefix. The length of that prefix determines the
anonymity set and associated privacy/bandwidth tradeoff, which
remainds a fixed ratio of all transactions for the life of the
wallet.
an 'update' button get a binary they can
trust. It's not a problem unique to bitcoind, deterministic builds are
awesome, but I don't think fully solve it.
Thanks,
Jeremy
On Tue, 31 Dec 2013 13:33:54 -0800, Matt Corallo
bitcoin-l...@bluematt.me wrote:
We already have a wonderful system
I didn't know about the dedicated server meltdown, it wasn't any of my infra. Anyway, my previous offer still stands.One less 'security theater' approach would be if we could provide forward-validation of updates using the blockchain. It's always going to be up to the user the first time they
I was reading there are some commands to access a peer's mempool state.
The purpose being to allow miners to recover faster after a reboot, I
think?
Reading peer mempool definitely allows recovering faster after a reboot.
So does persisting mempool in a database locally. But what can you
Some really nice efforts out there to map and analyze the bitcoin P2P
network.
The current protocol apparently recommends returning up to 2500 addresses
from 'getaddr'. I'm not sure how much clients are expected to probe the
address space in order to select 'far-apart' peers, or how much
I can provide the server hardware and colocation (space, power, and bandwidth) if dedicated 50Mbit in 55 S. Market, San Jose, CA data center is acceptable.If it needs more bandwidth than that, in a few months I hope to be getting space in LA with 1Gbit, but I can't commit to that now.On Sun, Dec
, but 'minfee' as somewhat
problematic.
Thanks,
Jeremy
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad
would need to be some way to anti-DDoS this which allows for some amount of these fake-outs without letting them get out of hand.Thanks,Jeremy--
November Webinars for C, C++, Fortran Developers
Accelerate application p
Do you think we're at the point where wallets have to be able to actively
bid the fee using replacement due to block contention?
I think a fee estimation API is just a data point. Depending on the
properties of the estimator, and how that's presented in the UI, it could
serve to either
in
and do more with Bitcoin soon.
Thanks all, sorry if I'm rambling,
Jeremy Spilman
On Thu, 24 Oct 2013 04:11:05 -0700, Christian Decker
decker.christ...@gmail.com wrote:
I'd like to add some historical background about how the protocol
specification came to be in the first place.
A bit
Can this be combined with the ideas on deterministic signing to show matching signatures with OpenSSL's implementation?Not sure if that's worth much, since we would just be testing needles in a very large haystack, but better than nothing?On Wed, 09 Oct 2013 20:50:30 -0700, Warren Togami Jr.
use whenever possible
(deterministic signing) and also would love to learn more best practices
for placing less trust in the so called CS-PRNG when we do have to use
them.
Thanks,
Jeremy
--
Get 100% visibility
to the ParentPubKey intact, without
having to disclose the ChainCode. Meh...
Thanks,
--Jeremy
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
inside a bitcoin:// URI if you wanted
to.
Thanks,
--Jeremy--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin
,
--Jeremy
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development
my feedback is if you are designing for persistent
long-term relationships, you could build in a mechanism for generating
address chains so you don't need any further communication after the initial
exchange, and it need not complicate the wallet.
Thanks,
--Jeremy
1) The risk that the merchant's web server will be compromised and the
attacker will redirect refunds
2) The risk that the merchant will miss payments because they miss a POST
to the payment_url (maybe the customer's machine crashes during the HTTPS
handshake)
If payments are a lot more common
It's neat to use the payment address as an implicit signature by hashing
something and multiplying it into the payee's pubKey.
One downside is that it complicates the merchant's wallet. In this case
the payment is going to a pseudo-random address which the merchant will
have to explicitly add to
in the Payment Request. Gavin, would the best way to work on
this be to just fork your code on Github?
Thanks,
--Jeremy
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance
to hear a better idea.
Any comments if this is something worth pursuing? I think there are
definitely benefits if merchants can keep the key signing the address
offline.
Thanks,--Jeremy
--
Try New Relic Now We'll Send You
I was discussing this with petertodd a couple days ago and we were thinking
the sequence I sent yesterday was usable today. I tried getting it to work
on test-net but the final transaction closing the channel was not being
accepted into the mempool beacause ERROR: CTxMemPool::accept() : inputs
on the
latest TX2-Final which was sent by the user. In this case there is no
TX2-Locked, only a single boardcast version of TX2-Final, and you do not
need transaction replacement at all.
Thanks,
--Jeremy
--
Precog is a next
53 matches
Mail list logo
