I’m not sure I followed John’s proposal fully, why would a user sign TX1
committing funds to the MULTISIG they may never get back? I also don’t see
the problem with getting a signed TX2 back from the AP before releasing
TX1... see the sequence below. But more importantly, we only need exactly
one
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
Payment Protocol uses x509 certs to sign a Payment Request. This
allows wallets to display meta-data from the cert to the payer instead
of the address, which should make it easier to verify where money is
being sent, and make it harder for an attacker to change the address
displayed to a user so
There are definitely ways to keep the pay-to address secure even if the web
server is compromised, just perhaps not perfectly clean standard X.509 ways
under the current ecosystem which would be easier for everyone to agree on.
- If a more trusted cert is an EV end cert, and a less trusted is a
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
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
If you have two parties who want to form a persistent relationship, by
exchanging and verifying public keys beforehand, then I think the canonical way
to do this with BIP32 is for the parties to exchange PubKey and *ChainCode*.
I don’t understand the use case for handing out individual
Hi Alan,
“BIP 32 does not prescribe a way to use multiple chains like you described
with the convenient type-2 derivation (though we could create a variant
that does)”
What do you think is missing from BIP32 for this? A wallet creates a
child-node using the public / type-2 CDF, hands out
BIP 32 already specifies how to use the first three tree levels: M/i/j/k,
i~wallet, j~Internal/External, k~address. The first level is actually
type-1 derived, and thus we cannot create an arbitrary number of them
without pre-computing them from the offline wallet. So it's not free to
which could involve proving something to a third party that has not seen
the communication between payer and payee.
OK - I think I follow now. So a third-party who does not see any of the
communication between the payer and payee only knows the HASH160. Let's say
the payee denies receipt
I personally like the full-measure of eliminating the CS-PRNG entirely
from signing. If the random component is assumed to be untrusted,
keeping it in there adds no value, while eschewing the main benefit of
deterministic signing (ease of testing, auditing)
This just leaves the CS-PRNG at
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.
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
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
Great paper Ittay, thanks for all your work on this.
Today the threshold is 0% with good connectivity.Fig. 2 captures this well, the threshold is only zero if 'y' is 1. In Section 6 and 6.1 you argue y - 1 but the sybil attack you describe, isn't that more like how *all* sophisticated miners
allowfee:
Allow up to allowfee satoshis to be deducted from the amount paid to be
used to pay Bitcoin network transaction fees. A wallet implementation
must not reduce the amount paid for fees more than allowfee, and
transaction fees must be equal to or greater than the amount reduced.
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
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 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
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
So I looked into gitian, the first thing I noticed was the hashes that
people were signing, for example:
https://github.com/bitcoin/gitian.sigs/blob/master/0.8.6-win32/gavinandresen/bitcoin-build.assert
don't match the hash of the file 'bitcoin-0.8.6-win32-setup.exe' actually
hosted by
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.
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
Oh, sorry, I forgot to mention it in my first write-up but you can
easily make stealth addresses include a second pubkey for the purpose of
the communication that either isn't used in the scriptPubKey at all, or
is part of a n-of-m multisig. (n=2) Interestingly that also means you
can give a
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
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
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back a...@cypherspace.org wrote:
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?
Adam
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
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
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
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
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 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
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
Consequently you can now securely and very network/space efficiently
securely delegate searching a block by computing the private key for the
IBE pub key that any sender would use for that block, and sending it as
a query to a random (or node-capture defended random selected node).
The node
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
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
On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik jgar...@bitpay.com wrote:
This PR reduces the size to 40 bytes:
https://github.com/bitcoin/bitcoin/pull/3737
Just quickly GLANCED at it, but if I understand correctly how the template
matching code works, that will change max size of the data to
If I understand correctly, the risk here is this would open a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. I don't know if that's true, but I think that's what Peter is saying makes it different this time.The relay network does
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
From BIP70:
If pki_type is x509+sha256, then the Payment message is hashed using
the
SHA256 algorithm to produce the message digest that is signed. If
pki_type
is x509+sha1, then the SHA1 algorithm is used.
A couple minor comments;
- I think it meant to say the field to be
On Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn m...@plan99.net wrote:3) Whilst these payment processors currently verify merchants so the security risk is low, in future a lighter-weight model or competing sites that allow open signups would give a weak security situation: a hacker who
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
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
47 matches
Mail list logo
