> 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
Credit to Anatole Shaw for discovering.
On Sun, Jul 27, 2014 at 10:12 PM, Jeremy 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 m
tcoin 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
* the general cost of any network-wide change, versus P2SH which is
already analyzed by devs, rolled out and working
* the cost of updating everybody to relay this new transaction type,
whereas P2SH Just Works already
fair -- I think that there may be a big benefit realizable with this kind
of syst
script1
push script2
push script3
push
eval
On Thu, Jul 17, 2014 at 12:52 AM, Jeff Garzik wrote:
> On Wed, Jul 16, 2014 at 1:56 PM, Jeremy wrote:
> > Right now, this could be expressed multiple ways (ie, using an op_dup if
> > then else chain) , but all would incur add
e 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
roofing. I think any additional extension fields should be hashed using the hash function specified in pki_type and signed by X509Certificates.certifcate private key. No extended_certs required -- I'm thinking something like;message PaymentRequest { // new field optional bytes extended_properties = 6; optional bytes ex
e field to the empty string, serialize to
a byte[] 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 certifi
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
med transactions (cumulative average fee/kb?) 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 t
// small 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 t
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 Clo
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
e for 'fuzzy' matching but they
are 'fuzzy' within the scope of Q, not across different Q, so that doesn't
help provide any repudiation. So I see this as only slightly improving
Peter's original proposal of providing 'Q' to the searcher, bu
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.
urned.
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 OpenSS
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
>
estNet I sent out, and see if
that's in line with what you expected?
I would also greatly appreciate if you could review the discussion around doing
two ECDH operations with a single ephemeral key.
Thanks!
--Jeremy
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
otypes:
1) Pay to STL addresses
2) Watcher process to detect and queue STL payments for a given d2/Q2
3) Offline verifier to take output from Watcher and verify spendable given
encrypted d/d2
Obviously extending QT directly for #1 would be ideal, I may even be able
to do that since supporting a ne
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.
>
sers want to know when an upgrade is
available, and ability to click 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:
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
the 'minfee' and broadcasts 1 block before 'expires' but the
payment DOESN'T make the block? Is the merchant liable for too-slow
transactions due to their own insufficient 'minfee' value?
So I see 'allowfee' as extremely useful, but &
ryption key to check, it's too late, and they are guaranteed to lose unless they can out-race the network, e.g. back at t=50%. Of course there 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-
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
justify
the increased code complexity.
TL;DR - Really like the idea of minimizing CS-PRNG 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,
x27; a level in the wallet hierarchy, keep the
'chain of custody' so to speak back to the ParentPubKey intact, without
having to disclose the ChainCode. Meh...
Thanks,
--Jeremy
--
This SF.n
s their
own 'j'. ParentPubKey + Addend gives you the PubKey of [m/i'/j]. With the
ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
increasing 'k'. Again, from the user perspective all transactions under
[m/i'] can be presented in
ge of 'single
address generation' behind us...
Thanks,
--Jeremy
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
__
bably pack the whole message 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___
> 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
in the Subject Alternate Name, and getting PubKey
and InvoiceID 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 Se
igned using the EV cert, but that
requires special validation, since its no longer a standard
certificate chain. I would love 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.
Than
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
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
64 matches
Mail list logo
