> On Mar 27, 2015, at 8:16 AM, Matt Whitlock 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 goal is to see if we
On Mon, 16 Mar 2015 09:29:03 -0700, Sergio Lerner
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 publishing this. It could b
On Sat, Dec 20, 2014 at 08:57:53AM +, Matt Corallo wrote:
>> There was recently some discussion around dnsseeds. Currently some
>> dnsseeds are getting blocked by ISPs because the hosts they pick up
>> (which run bitcoin core nodes) often run rather web servers alongside
>> which serve malware
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 Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn 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 compromised your computer
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 ha
On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir 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 have a cert, we have
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 p
>
> So in summary the spec needs daily as an option, and to specify the
> recurring cycle as every n*period >(one of daily, weekly, monthly,
> yearly): and you can drop quarterly since it's just expressed as per
> >3*monthly.
If you're going to go the direction of a {unitType, unitsPerInter
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
On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik 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 to 40 bytes
but does
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
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 at
>
> 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
Please note, responding to Pieter and Chuck concurrently.
On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille
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 alternative route for del
On Jan 27, 2014, at 9:39 AM, Andreas Schildbach 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 BIP
On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
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. Nevertheless, I tried to encode a payment request into
> t
>
>
>
> 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
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 be specified
in
> On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner 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
> encryption
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 wh
On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back 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 not reuse addre
Might I propose "reusable address".I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'.It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly adopted.
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back 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
>
Thanks for re
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd 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
>
> Uh while I'm responding again, what I'd discussed with Peter Todd in
> IRC used two EC points in the stealth address. One for the payment and
> one for the ECDH. The reason to use two is that it makes delegating
> detection possible and so you don't have to have you spending keys
> online to ev
On Mon, 13 Jan 2014 03:18:28 -0800, Mike Hearn 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 it?But of
* Transaction *
I spent 1BTC on TestNet to a stealth address...
TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c
http://blockexplorer.com/testnet/tx/df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c#i8166574
* Code *
Code which generated this transaction
On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman wrote:
> > I think for displaying the payment in the UI after it's been made via
> PP, we have to fully
> > support sending to a new standard address type anyway.
On Sun, 12 Jan 2014 10:26:18 -0800, Mike Hearn wrote:
> Why
You can always just extend the payment protocol with the new fields as well, vs making very long addresses. I should have mentioned that as Task #4. Agree it could be an optional extension and backward compatible. I think for displaying the payment in the UI after it's been made via PP, we have to
> 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 gi
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 key
>
> 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.
>
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 s
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 inst
Merge mining lets Bitcoin miners support or attack an alt-coin without any
additional cost for their proof-of-work.
Since bitcoin miners have to install software to build and claim blocks in
the alt-coin, the percentage of bitcoin hashing power reflected toward the
alt-coin will follow some
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 lea
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 su
Wow there's a lot here to think about. I'm pretty sure I haven't grasped
the full implications yet.
I see it proposes to also introduce additional BIPs describing the use of
the data stucture for stateless validation & mining, the UBC address index
for "SPV+" operating modes, document timest
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 8
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 redu
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 w
Just an aside...
The 1BTC bountry John references below is a 1BTC P2SH output, where the
redeemScript he provided does hash to the expected value, and is itself a
2-of-3 multisig, with the following pubkeys, expressed as addresses:
1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
1FCYd7j4CThTMzts78rh6iQJLB
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 inc
Gavin, can you confirm the best place to read up on the discuss fee estimation changes for v0.9?I think fee estimation at its core is about providing a data point, or even call it an API, which can be used however you see fit.What parameters do I want to see in a 'fee estimation' API? - 30 minut
not a Bad Thing.
TL;DR; The current support systems worked very well for me. I was able to
accomplish all my goals, and I would even say it was a pleasure. Keep a
high bar for assigning BIP numbers. And I hope to be able to jump back in
and do more with Bitcoin soon.
Thanks all, sorry if I
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. wrot
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
> 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
> 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"
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
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 multiplie
> 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 commo
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
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 D
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 th
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
al
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
58 matches
Mail list logo
